Toon posts:

[Search] Toch wel een bug...?

Pagina: 1
Acties:
  • 50 views sinds 30-01-2008

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Eerder vandaag postte Glaanieboy over search results die steeds meer werden als je naar de volgende pagina gaat. Dat werd afgedaan met 'da's geen bug: 't gaat om x resultaten: de search weet het gewoon nog niet'. Nou, bug of geen bug, het maakt de search hopeloos nutteloos.

Ik heb net gezocht op operation flashpoint... En ja hoor, elke keer als ik naar een volgende pagina wil komen er steeds meer resultaten. Bovendien staan er steeds maar weer resultaten bij die op de vorige pagina ook al stonden! Op zo'n manier komt er geen eind aan! Onbruikbaar dus. Het loopt in dit geval van 75 naar 676 resultaten (als je steeds op de laatste beschikbare pagina klikt: zie hier). Als je vervolgens naar de eerste pagina gaat staan er gewoon weer 75 hits! Zo is het dus onmogelijk op een logische wijze alle hits te lezen.

Bovendien (wat anders maar in dit geval ook erg lastig) werkt het sorteren op datum laatste poging ook niet.

Ik heb zo dus echt helemaal niets aan de search... :(

Bug of geen bug: dit is niet echt zo als het hoort, volgens mij... Zo heeft niemand er toch wat aan...? Wordt hier nog aan gewerkt of is dit het...?

[ Voor 18% gewijzigd door Verwijderd op 24-03-2003 22:59 ]


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op 24 March 2003 @ 22:57:
Eerder vandaag postte Glaanieboy over search results die steeds meer werden als je naar de volgende pagina gaat. Dat werd afgedaan met 'da's geen bug: 't gaat om x resultaten: de search weet het gewoon nog niet'. Nou, bug of geen bug, het maakt de search hopeloos nutteloos.
Ik snap niet hoe het de search nutteloos maakt :?
Als jouw gezochte topic niet in de eerste tien pagina's staat moet je je query aanpassen, niet doorbladeren :)
Bovendien staan er steeds maar weer resultaten bij die op de vorige pagina ook al stonden!
Kijk, dat is dus wel een bug, overigens niet van react maar van omega waar wij dus niet zo heel makkelijk wat aan kunnen doen.
Neemt niet weg dat als je gezochte topic niet in de eerste paar pagina's is je je query moet aanpassen, dan was ie blijkbaar niet goed :)
bovendien (wat anders maar in dit geval ook erg lastig) werkt het sorteren op datum laatste poging ook niet.
Daar kon je wel eens gelijk in hebben.
Ik heb zo dus echt helemaal niets aan de search... :(
Arme jongen :)
Leer eerst eens zoeken en ga dan de search de schuld geven :)
Zelfs als ie vervelend is, zoals blijkt, kan je er nog veel meer uithalen dan je nu doet. Domweg zoeken op 'operation flashpoint' zal je niet helpen te vinden wat je zoekt, simpelweg omdat de engine dan _alle_ topics met 'operation' en 'flashpoint' erin teruggeeft, zonder dat nou dat topic perse daarover gaat over wat jij zoekt.
Bug of geen bug: dit is niet echt zo als het hoort, volgens mij... Zo heeft niemand er toch wat aan...? Wordt hier nog aan gewerkt of is dit het...?

Er wordt regelmatig wat aan gedaan, alleen momenteel ligt het wel op een lager pitje omdat ie in principe goed werkt.
Als jij niet kan zoeken, dan zal het ook nooit vinden wat je wilt. Echter ben ik wel met je eens dat er een paar bugs nog inzitten, deze zal ik opsturen naar de makers van omega, maar hoe snel daar een fix voor is en of die er uberhaupt komt?

Het veranderen van het aantal gevonden topics zal denk ik niet als bug gezien worden door hen.

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Die sorteren op laatste posting heb ik maar weggehaald, dat werkt idd niet. En het toevoegen ervan kost weer aardig wat tijd (zou weer een herindexatie van de database kosten) dus dat gebeurt voorlopig niet :)

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op 24 March 2003 @ 22:57:
Bovendien staan er steeds maar weer resultaten bij die op de vorige pagina ook al stonden!

Zou je me hier voorbeelden van kunnen geven, ik heb het wel gezien als de resultaten gesorteerd werden, maar eigenlijk niet als dat niet gedaan werd.
Het zou me iig flink helpen als ik ook voor dat geval de developers van omega een goed 'fout' voorbeeld kan laten zien :)

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik weet dat mijn zoekterms niet erg exact waren en dus veel hits opleveren. Maar het ging mij even om het principe.
Dat de resultaten door elkaar staan komt inderdaad door het sorteren op datum (wat je nu hebt weggehaald: heeft mijn post toch nog nut gehad... ;) ) Omdat er vervolgens steeds meer hits werden gevonden, kreeg je dus vanzelf dubbele hits die ook al op de vorige pagina stonden maar waren doorgeschoven.

Dat heb je nu nog steeds als je probeert te sorteren op datum topicstart. Zoek maar een naar 'operation flashpoint' en sorteer op datum topicstart. Op de eerste pagina krijg je dan bijvoorbeeld ergens in het midden het topic 'Operation Flashpoint mod, hoax or tha bomb?'. Klik vervolgens op 2 om naar de volgende pagina te gaan. Dan staat datzelfde topic er weer (in mijn geval bovenaan). Op dat moment heeft de search dus meer hits gevonden (122 i.p.v. 77 of zo) dus staan er op dat moment meer ongelezen hits op pagina 1. Maar als je weer klikt op 1 krijg je weer dezelfde pagina als eerst en de melding dat er maar 77 hits zijn. Het systeem 'leert' dus niet, of beter gezegd onthoudt niet wat gevonden is. Het is alsof elke klik op een pagina cijfer een nieuwe search inzet en elke pagina levert meer hits op. Zo kun je dus niet te lezen krijgen wat er echt te lezen valt. Als ik op pagina 2 ben, staan er schijnbaar op pagina 1 andere hits. Maar die krijg je nooit te zien want op pagina 1 is alles weer als vanouds.

En hoe hoger het paginacijfer, hoe meer hits je krijgt. Dat klopt toch niet?!?

Klinkt erg ingewikkeld, al zeh ik het zelf... Snap je wat ik bedoel...?


P.S. Ik heb het net ff geschekt, maar dit werkt altijd zo: ook bij sorteren op relevantie: elke volgende pagina heeft meer hits. En als je teruggaat worden het weer minder. Dat noem ik toch een bug.

Boven pagina 1 staat dit:

Er zijn ongeveer 73 resultaten, verdeeld over 5 pagina's.
  Er is gezocht op: operation flashpoint
  Woord frequenties: operation: 4490, flashpoint: 894
  Database van 705678 documenten doorzocht in 0,076s.

Boven 2 staat dit:

Er zijn ongeveer 117 resultaten, verdeeld over 8 pagina's.
  Er is gezocht op: operation flashpoint
  Woord frequenties: operation: 4490, flashpoint: 894
  Database van 705678 documenten doorzocht in 0,070s.

Pagina 3:

 Er zijn ongeveer 163 resultaten, verdeeld over 11 pagina's.
  Er is gezocht op: operation flashpoint
  Woord frequenties: operation: 4490, flashpoint: 894
  Database van 705678 documenten doorzocht in 0,072s.

P.S. 2
BELANGRIJK!
Ik ben weer even verder gaan testen en ben er achter gekomen dat dit alleen gebeurt bij ALLE TREFWOORDEN (EN)! Daar ligt dus schijnbaar een fout! Als je 'gewoon' zoekt op alle woorden vind 'ie WEL steeds een vast aantal hits. Misschien kunnen jullie wat hiermee...

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op 25 March 2003 @ 14:17:
Omdat er vervolgens steeds meer hits werden gevonden, kreeg je dus vanzelf dubbele hits die ook al op de vorige pagina stonden maar waren doorgeschoven.
Nee, dat staat los van elkaar. De sortering en de gevonden documenten hebben niks met elkaar te maken, ook het vinden van meer hits zou niet dezelfde documenten dubbel op mogen leveren.

De uitleg (in het engels) van de developers zelf:
"The matcher uses estimates how many matches would have been found if it had considered every document (which it usually can avoid doing thanks to various optimisations). When you look at the first page, it needs to find hits 1-10 (assuming 10 hits per page); for page 2, it needs to find hits 1-20. Thus more documents need to be considered, and the matcher's estimate of the total number of matches may change."

Het komt er dus op neer dat om een hoop werk te besparen niet alle documenten bekeken worden. Aangezien je met een and-search niet zomaar van te voren kan bepalen welke documenten er nou precies beide termen bevatten is het wat lastiger controleren. Hoe verder je dan naar achteren bladert, hoe meer je al weet over de voorgaande resultaten en dus hoe meer je ook kan zeggen over het "waarschijnlijke vervolg". Sowieso weet je van steeds meer documenten dat ze zeker weten voldoen.
Dat heb je nu nog steeds als je probeert te sorteren op datum topicstart. Zoek maar een naar 'operation flashpoint' en sorteer op datum topicstart. Op de eerste pagina krijg je dan bijvoorbeeld ergens in het midden het topic 'Operation Flashpoint mod, hoax or tha bomb?'. Klik vervolgens op 2 om naar de volgende pagina te gaan. Dan staat datzelfde topic er weer (in mijn geval bovenaan).
Dit gedrag is iig een bug, wat ook de aandacht heeft van de omega-developers nu :)
Op dat moment heeft de search dus meer hits gevonden (122 i.p.v. 77 of zo) dus staan er op dat moment meer ongelezen hits op pagina 1. Maar als je weer klikt op 1 krijg je weer dezelfde pagina als eerst en de melding dat er maar 77 hits zijn. Het systeem 'leert' dus niet, of beter gezegd onthoudt niet wat gevonden is. Het is alsof elke klik op een pagina cijfer een nieuwe search inzet en elke pagina levert meer hits op. Zo kun je dus niet te lezen krijgen wat er echt te lezen valt. Als ik op pagina 2 ben, staan er schijnbaar op pagina 1 andere hits. Maar die krijg je nooit te zien want op pagina 1 is alles weer als vanouds.
Als ik de uitleg van de ontwikkelaars goed begrijp doet ie exact hetzelfde voor de eerste 10 documenten wanneer je op pagina 2 bent, dan wanneer je op pagina 1 bent. Het zou natuurlijk wat wezen als dat niet zo was :)
De reden dat het getal toeneemt is niet omdat ie meer documenten overgeslagen heeft, maar de hoeveelheid nog te volgen documenten anders inschat.
En hoe hoger het paginacijfer, hoe meer hits je krijgt. Dat klopt toch niet?!?
Wel dus, hoe meer informatie ie over de voorgaande reeks documenten heeft, hoe beter ie in kan schatten hoeveel het er nou precies zijn.
Klinkt erg ingewikkeld, al zeh ik het zelf... Snap je wat ik bedoel...?
Ik geloof het wel :P
Ik ben weer even verder gaan testen en ben er achter gekomen dat dit alleen gebeurt bij ALLE TREFWOORDEN (EN)! Daar ligt dus schijnbaar een fout! Als je 'gewoon' zoekt op alle woorden vind 'ie WEL steeds een vast aantal hits. Misschien kunnen jullie wat hiermee...

Wist ik al ;)
Ik heb trouwens wel nog even om uitleg gevraagd waarom het alleen bij EN-searches gebeurd. :)
Wellicht komt het omdat bij een OR-search elk document valide is dat maar aan één van de termen voldoet, terwijl bij een EN-search alle termen erin moeten zitten en dat die controle dan weer wat lastiger uit te voeren is.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Tjonge, dit wordt een gezellig uitgebreid topic zo met z'n tweetjes. ;)

Ik begin het in ieder geval te begrijpen... Nou ja, begrijpen... Al met al is dit toch heel wat anders dan een 'normale' standaard search engine... Ik vraag me eigenlijk alleen maar af wat het voordeel is van deze...De snelheid...? Het is niet bepaald een inzichtelijke search engine, als je het mij vraagt. Maar ach, wie vraagt me wat... ;)

Ik moet wel zeggen dat ik liever een search had die gewoon in 1 keer huplakee alle resultaten liet zien, zoals het voor de 'verhuizing' nog het geval was... Maar dat is eigenlijk weer een nieuw topic...

O ja, nog ff dit:
Als ik de uitleg van de ontwikkelaars goed begrijp doet ie exact hetzelfde voor de eerste 10 documenten wanneer je op pagina 2 bent, dan wanneer je op pagina 1 bent. Het zou natuurlijk wat wezen als dat niet zo was :)
Eh... dit is dus precies wat jij zelf daarvoor nog "iig een bug" noemde (lees het nog maar eens)... Het IS dus niet zo... >:)

[ Voor 3% gewijzigd door Verwijderd op 25-03-2003 15:29 ]


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op 25 March 2003 @ 15:29:
Tjonge, dit wordt een gezellig uitgebreid topic zo met z'n tweetjes. ;)
:P
Ik begin het in ieder geval te begrijpen... Nou ja, begrijpen... Al met al is dit toch heel wat anders dan een 'normale' standaard search engine... Ik vraag me eigenlijk alleen maar af wat het voordeel is van deze...De snelheid...? Het is niet bepaald een inzichtelijke search engine, als je het mij vraagt. Maar ach, wie vraagt me wat... ;)
De mysql-based searchengine die je zo graag terug wilt zien heeft nooit goed gewerkt met React, maar ook het laatste (half?) jaar werkte het niet goed met Topix.
Simpelweg omdat onze te doorzoeken database te groot geworden is.

Dus ja, performance is er een reden voor. Ook de schaalbaarheid. Maar ook de functionaliteit, je kon niet op woorden kleiner dan drie tekens zoeken, je kon niet op zinnen zoeken (niet dat dat zo snel gaat hiermee, maar dat kan gewoon niet snel). Bij topix gingen we zelfs zo ver dat ie niet in topics ouder dan 100 dagen kon zoeken, om het enigszins handelbaar te houden.
Ik moet wel zeggen dat ik liever een search had die gewoon in 1 keer huplakee alle resultaten liet zien, zoals het voor de 'verhuizing' nog het geval was... Maar dat is eigenlijk weer een nieuw topic...
Ik heb er liever een die vind wat ik zoek en als ik daarvoor de zoektermen iets moet wijzigen of een beetje moet nadenken vind ik dat niet erg ;)
O ja, nog ff dit:

Eh... dit is dus precies wat jij zelf daarvoor nog "iig een bug" noemde (lees het nog maar eens)... Het IS dus niet zo... >:)

Neehoor.
Als je pagina 1 opent moet de engine documenten 1 - 10 ophalen.
Als je pagina 2 opent, moet ie diezelfde 1-10 ophalen _en_ 11-20.
etc :)

Dat ie dan tussen die 11-20 blijkbaar een document tussenvoegt die ook al in 1-10 stonden is wat vervelend.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb er liever een die vind wat ik zoek en als ik daarvoor de zoektermen iets moet wijzigen of een beetje moet nadenken vind ik dat niet erg ;)
Okay, okay, I got the message... ;)

Over en uit.

Edit:
En nog bedankt voor je snelle en zeer uitgebreide reacties!

[ Voor 14% gewijzigd door Verwijderd op 25-03-2003 16:50 ]


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Ach, geen dank :)

Ik zal een keertje de uitleg in de manual wijzigen/plaatsen, het staat daar verder niet echt in natuurlijk.

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

De bug is trouwens gefixed in de laatste development-versie van omega/xapian. Wanneer die precies hier beschikbaar komt weet ik nog niet :)

(met 'de bug' bedoel ik dat vage dubbele vertonen en nog een andere die Jaymz had gevonden maar uiteindelijk dezelfde bug bleek te zijn)

Ow en die versie van omega is ook iets beter met het berekenen van de resultaten lijkt het
Er zijn ongeveer 656 resultaten, verdeeld over 44 pagina's.
Er is gezocht op: operation flashpoint
Woord frequenties: operation: 4479, flashpoint: 892
Voor de eerste pagina, ipv 77 resultaten (bij mij) :)
Pagina: 1

Dit topic is gesloten.