Solr-Suchrelevanztests

Viele Leute konzentrieren sich ausschließlich auf die Geschwindigkeit der Suche und vernachlässigen dabei oft die Qualität der vom System erzeugten…

Viele Leute konzentrieren sich ausschließlich auf die Geschwindigkeit der Suche und vernachlässigen dabei oft die Qualität der vom System erzeugten Ergebnisse. In den meisten Fällen testen sie eine kleine Anzahl von Abfragen, sehen sich die fünf oder zehn besten an und erklären das System dann für gut genug. In anderen Fällen haben sie eine Reihe von Testabfragen, wissen aber nicht, wie sie auftretende Probleme beheben sollen.

Um diese Probleme zu lösen, bedarf es eines systematischen Ansatzes, einer Reihe von nützlichen Tools und einer Portion Geduld. In diesem Artikel werden verschiedene Ansätze und Hilfsmittel vorgestellt. Die Geduld ergibt sich aus dem Wissen, dass das Problem auf eine pragmatische Art und Weise angegangen wird, die zu einer Lösung und nicht in eine Sackgasse führt.

Irgendwann während der Entwicklung, dem Testen oder der Bereitstellung einer Suchanwendung wird jeder Entwickler auf das „Relevanzproblem“ stoßen. Einfach ausgedrückt: Eine Person, die das System benutzt, gibt ihre Lieblingsabfrage (ja, jeder hat eine) in das System ein, und die Ergebnisse sind, um es nett auszudrücken, nicht besonders gut. Sie fordern nun, dass dieses Problem behoben wird.

Ich war zum Beispiel bei einem Kunden vor Ort, um seine Entwickler zu schulen und sein System zu beurteilen, als ich eine Abfrage vorschlug, die mit meiner Heimatstadt Buffalo, MN, zu tun hatte (sehen Sie, ich habe Ihnen gesagt, dass wir alle Lieblingsabfragen haben), da ich wusste, dass diese Information in ihrem System vorhanden sein sollte. Wie Sie sich denken können, kam das gewünschte Ergebnis nicht zustande und wir mussten einige der Techniken anwenden, die ich gleich beschreiben werde. Der Vollständigkeit halber sei gesagt, dass das Problem auf fehlerhafte Daten zurückzuführen war, die beim Datenimport erzeugt wurden, und dass es am nächsten Tag behoben war.

Sie fragen sich vielleicht, wie es zu diesen schlechten Ergebnissen kommen kann, da das System immer wieder mit einer Vielzahl von Abfragen (wahrscheinlich Ihren „Favoriten“) getestet wurde und die Ergebnisse immer schön waren. Sie fragen sich vielleicht auch, ob die gesamte Anwendung fehlerhaft ist und wie man sie reparieren kann. Woher wissen Sie, ob die Behebung dieser einen Abfrage nicht alles andere kaputt macht?

Keine Sorge: Das Relevanzproblem kann direkt und systematisch angegangen werden, um all diese Fragen zu beantworten. In diesem Artikel erfahren Sie, wie Sie die Relevanzleistung einer Suchanwendung testen und die Ursache des Problems ermitteln können. In einem zweiten Artikel werde ich Techniken zur Behebung von Relevanzproblemen erörtern.

Für den Anfang sind ein paar Definitionen angebracht. In erster Linie misst die Relevanz im Zusammenhang mit der Suche, wie gut eine Reihe von Ergebnissen den Bedürfnissen des Benutzers, der das System abfragt, entspricht. Leider sind Definitionen der Relevanz aufgrund der Benutzerinteraktion immer mit einem gewissen Maß an Subjektivität verbunden. Daher sollten Relevanztests immer mit so vielen Benutzern wie möglich durchgeführt werden, damit die Subjektivität eines einzelnen Benutzers durch die Objektivität der Gruppe als Ganzes ersetzt wird. Außerdem muss es bei Relevanztests immer um den gesamten Nettogewinn des Systems gehen und nicht um eine einzelne Verbesserung für eine Anfrage oder einen Benutzer.

Um die Relevanz weiter zu definieren, sind zwei weitere Konzepte hilfreich:

Die Präzision ist der Prozentsatz der Dokumente in den zurückgegebenen Ergebnissen, die relevant sind.
Recall ist der Prozentsatz der relevanten Ergebnisse, die von allen relevanten Ergebnissen im System zurückgegeben werden. Eine perfekte Trefferquote zu erzielen ist trivial: Geben Sie einfach jedes Dokument in der Sammlung für jede Anfrage zurück.

Anhand der Definitionen von Präzision und Recall können wir nun die Relevanz einer Sammlung über Benutzer und Abfragen hinweg quantifizieren. Ein perfektes System würde für jeden Benutzer und jede Abfrage eine Genauigkeit von 100 % und einen Wiedererkennungswert von 100 % erreichen. Mit anderen Worten, es würde alle relevanten Dokumente abrufen und sonst nichts. In der Praxis ist es üblich, dass man sich bei einer bestimmten Anzahl von Ergebnissen auf die Präzision und den Wiedererkennungswert konzentriert, wobei zehn Ergebnisse am häufigsten (und sinnvollsten) sind.

In der Praxis gibt es viele Faktoren, die über die Definitionen hinaus zur Relevanz beitragen. Wenn Sie Ihr System auf Relevanz ausrichten, sollten Sie Folgendes berücksichtigen:

Ist es besser, genau zu sein oder so viele mögliche Treffer wie möglich zu liefern?
Wie wichtig ist es, peinliche Ergebnisse zu vermeiden?
Welche Faktoren spielen neben den reinen Schlüsselwortübereinstimmungen eine Rolle? Wollen die Benutzer beispielsweise Ergebnisse für Artikel, die sich in ihrer Nähe befinden (auch „lokale“ Suche genannt), oder bevorzugen sie neuere Ergebnisse gegenüber älteren? Im ersten Fall kann eine räumliche Suche helfen, während im zweiten Fall eine Sortierung nach Datum hilfreich ist.

Mit diesen Faktoren im Hinterkopf können Sie dann die Tests und die daraus resultierende Arbeit auf das Erreichen dieser Ziele ausrichten.

Nachdem ich nun die Relevanz und einige Möglichkeiten zu ihrer Messung definiert habe, ist es an der Zeit zu lernen, wie man sie in einer konkreten Anwendung ermittelt. Danach werde ich erörtern, wie Sie herausfinden können, woher die Probleme mit der Relevanz kommen, und ich werde einige gängige Beispiele für das Debugging der Relevanz durchgehen.

Qualität der Relevanz bestimmen

Es gibt viele Möglichkeiten, die Relevanz in einer Suchanwendung zu bestimmen, die von kostengünstig bis teuer reichen. Einige sind besser als andere, aber keine ist absolut. Um die Relevanz zu bestimmen, benötigen Sie mindestens drei Dinge:

Eine Sammlung von Dokumenten
Eine Reihe von Abfragen
Eine Reihe von Relevanzbeurteilungen

Der erste Punkt in der Liste ist der einfachste, während die Einholung von Beurteilungen oft schwierig ist, da sie am meisten Zeit in Anspruch nimmt. In den Optionen für Relevanztests werden einige der Möglichkeiten erörtert, wie diese drei Punkte zu einer Relevanzbewertung kombiniert werden können.

Tabelle 1. Optionen für Relevanztests

Name	Beschreibung	Pro	Nachteile
Ad-hoc	Entwickler, QA und Geschäftsleute denken sich Abfragen aus, geben sie in das System ein und sehen sich die Ergebnisse an. Das Feedback ist in der Regel allgemein und unspezifisch, wie z.B. „diese Abfrage war gut“ oder „die Ergebnisse sind schlecht“.	Niedrige Anfangskosten, niedrige Startkosten, gibt einen allgemeinen Überblick über das System. Besser als nichts?	Nicht wiederholbar und nicht zuverlässig. Erzeugt keine Präzisions-/Erinnerungsinformationen.
Fokusgruppen	Versammeln Sie eine Reihe echter Benutzer und lassen Sie sie über einen gewissen Zeitraum mit dem System interagieren. Protokollieren Sie alles, was sie tun, und bitten Sie sie ausdrücklich um Feedback.	Geringe Kosten, wenn online durchgeführt. Feedback und Protokolle sind sehr nützlich, vor allem, wenn sich die Benutzer in den Prozess eingebunden fühlen. Es könnte möglich sein, Präzisions-/Erinnerungsdaten zu erstellen, wenn die Benutzer Feedback geben.	Die Ergebnisse lassen sich möglicherweise nicht auf ein breiteres Publikum übertragen, je nachdem, wie gut die Nutzer Ihre Zielgruppe repräsentieren.
TREC und andere öffentliche Beurteilungen	Führen Sie eine Relevanzstudie mit einer Reihe von Abfragen, Dokumenten und Relevanzbeurteilungen durch, die von einer dritten Gruppe erstellt wurden. Das bekannteste Beispiel hierfür ist die Text Retrieval Evaluation Conference (TREC), die vom National Institute of Standards and Technologies (NIST) veranstaltet wird.	Relativ einfach zu verwenden, zu testen und mit früheren Läufen zu vergleichen. Vollständig wiederholbar. Gut als Teil einer größeren Bewertung, sollte aber nicht das einzige Mittel zum Testen sein.	Die Sammlung ist nicht kostenlos oder offen. Wenn Sie bei TREC gut abschneiden, heißt das nicht unbedingt, dass Sie auch im wirklichen Leben gut abschneiden.
Online Bewertungen	Lassen Sie Benutzer Dokumente mit einem numerischen oder „Sterne“-System bewerten.	Ähnlich wie bei der Klickverfolgung, jedoch werden die Dokumente explizit als relevant markiert und somit Zweifel an der Absicht des Nutzers ausgeräumt. Kann in das System zurückgespeist werden, um die Bewertung zu beeinflussen.	Die Benutzer können das System austricksen, aber im Laufe der Zeit sollte das Kollektiv jeden spezifischen Benutzereingriff überwiegen.
Protokollanalyse auf einer Beta-Produktionsseite	Setzen Sie ein Live-System für ein großes Publikum ein und lassen Sie es die Reifen testen. Das sollten Sie erst tun, wenn Sie sich einigermaßen sicher sind, dass die Dinge gut funktionieren. Das bedeutet, dass Sie sich Gedanken über die Dinge machen müssen, die Sie protokollieren möchten, z. B. Abfragen, Ergebnisse, Klickraten usw. Und schließlich sollten Sie Feedback von Ihren Nutzern einholen. Kombinieren Sie diese Faktoren und achten Sie auf Trends und rote Fahnen.	Was ist besser als echte Benutzer? Dieser Ansatz ist im Wesentlichen eine vergrößerte Version der Fokusgruppe.	Was ist schlimmer als echte Benutzer? Es ist beängstigend und teuer, aber irgendwann muss man es sowieso tun, oder? Außerdem ist es in nicht gehosteten Umgebungen schwer zu bewerkstelligen.
A/B-Tests	Weisen Sie einen Prozentsatz der Benutzeranfragen einem Suchsystem zu, während der andere Prozentsatz in einem anderen System sucht. Nach einer angemessenen Zeitspanne werten Sie die Entscheidungen der Gruppe A und der Gruppe B aus, um festzustellen, ob eine Gruppe bessere Ergebnisse erzielt hat als die andere. Wenn möglich, lassen Sie die Benutzer in jeder Gruppe die Ergebnisse bewerten.	Kombinieren Sie dies mit einer Protokollanalyse, um ein gutes Bild davon zu erhalten, was die Benutzer bevorzugen.	Erfordert die Einrichtung und Pflege von zwei Systemen in der Produktion. Schwierig bei nicht serverbasierten Anwendungen.
Empirische Prüfung	Wählen Sie aus einer Reihe von Abfragen aus Beta-Tests oder einem bestehenden System die X wichtigsten Abfragen in Bezug auf das Volumen und Y zufällig ausgewählte Abfragen, die nicht zu den X wichtigsten gehören. Lassen Sie Ihr QA- oder Geschäftsteam die Abfragen gegen das System ausführen und die fünf oder zehn wichtigsten Ergebnisse als relevant, einigermaßen relevant und nicht relevant bewerten. Alternativ können Sie sie bitten, binäre Entscheidungen zu treffen (relevant oder nicht) oder eine vierte Option hinzuzufügen: peinlich. X liegt in der Regel zwischen 25-50 und Y oft zwischen 10 und 20, aber Sie sollten je nach verfügbarer Zeit und Ressourcen auswählen.	Echte Abfragen, echte Dokumente, echte Ergebnisse. Konzentrieren Sie sich wie ein Laser auf die Abfragen, die für Ihr System am wichtigsten sind, ohne die anderen zu vernachlässigen. Außerdem können unzufriedene Benutzer direkt und quantifizierbar aufzeigen, warum das System ihre Erwartungen nicht erfüllt.	Zeitaufwendig, abhängig von der Wahl von X und Y. Urteile sind immer noch subjektiv und nicht unbedingt auf andere übertragbar.

In der Realität werden Sie wahrscheinlich mehrere der in der obigen Tabelle aufgeführten Ansätze anwenden wollen. Von diesen Evaluierungsmethoden liefern Beta-Tests mit Protokollanalyse, A/B-Tests mit Bewertungen und empirische Tests die qualitativ hochwertigsten Ergebnisse, da es sich dabei um direkte Tests Ihrer Anwendung und ihrer Alternativen handelt. Online-Bewertungen können ebenfalls sehr nützlich sein, erfordern aber, dass Sie zunächst eine gewisse Zeit lang in Produktion sind. In den nächsten beiden Abschnitten werde ich ausführlicher auf die Protokollanalyse und empirische Tests eingehen. Letztendlich wollen Sie einen Prozess, der wiederholbar und überprüfbar ist und den Ihr Team über die gesamte Lebensdauer der Anwendung durchhalten kann.

TREC-ähnliche Tests sind oft gut geeignet, um zwei verschiedene Suchmaschinen oder zugrunde liegende Suchalgorithmen zu vergleichen. Es ist auch ein guter Ausgangspunkt, da es relativ billig ist, es zum Laufen zu bringen. Oft ist es ebenso nützlich, die zugehörige TREC-Literatur zu lesen und darüber nachzudenken, wie andere ähnliche Probleme gelöst haben. Schließlich erhalten Sie mit den TREC-Tests schöne, leicht verständliche Zahlen, die die Ergebnisse zusammenfassen. Vermeiden Sie jedoch die Tendenz, viel Zeit damit zu verbringen, Ihr System für TREC zu optimieren. Es ist oft möglich, marginale Verbesserungen in TREC auf Kosten der Systemkomplexität und des realen Bedarfs zu erzielen.

Log-Analyse

Bei der Protokollanalyse werden Ihre Protokolle analysiert und Abfragen, die Anzahl der Ergebnisse, die Klickrate auf die Ergebnisse, Seitenaufrufe und, wenn möglich, die auf jeder Seite verbrachte Zeit verfolgt. All dies sollte sowohl insgesamt als auch für jeden einzelnen Benutzer durchgeführt werden. Bei den Suchanfragen sollten Sie auch die Anzahl der Suchanfragen pro Ergebnis (achten Sie besonders auf die Suchanfragen, die keine Ergebnisse lieferten) sowie die beliebtesten Suchanfragen und die beliebtesten Begriffe und Phrasen verfolgen. Setzen Sie dann für eine Stichprobe von Suchanfragen (wahrscheinlich die Top 50 und einige andere zufällige Suchanfragen, wie bei empirischen Tests) die Anzahl der angeklickten Ergebnisse mit der Zeit, die auf diesen Ergebnissen verbracht wurde, in Beziehung (sofern dies feststellbar ist). Das Ziel ist es, ein Gefühl dafür zu bekommen, wie erfolgreich die Benutzer bei der Suche nach den gewünschten Informationen sind. Wenn sie viel blättern oder viele Ergebnisse anklicken, sich aber nicht die Zeit nehmen, sie zu lesen, ist es wahrscheinlich, dass sie nicht finden, was sie brauchen.

Darüber hinaus kann die Analyse von Suchanfragen hilfreich sein, um ähnliche Suchanfragen zu korrelieren. Wenn ein Benutzer beispielsweise ein oder zwei Schlüsselwörter eingibt und diese Suchanfrage dann mehrmals ändert, besteht die Möglichkeit, dass er nicht findet, was er braucht, oder dass er zu viele Ergebnisse erhält. Es ist auch nützlich, die Klickrate auf andere Anzeigefunktionen wie Facetten, Rechtschreibkorrekturen, automatische Auswahlvorschläge, verwandte Suchvorschläge und „mehr davon“-Anfragen zu verfolgen.

Sobald Sie all diese Informationen haben, können Sie sie speichern und dann mit anderen Zeiträumen in Ihren Protokollen vergleichen, um zu sehen, ob Sie nützliche Trends erkennen. Verbringen die Benutzer beispielsweise mehr oder weniger Zeit mit den Ergebnissen? Gibt es weniger Abfragen mit null Ergebnissen und weniger Abfragen, bei denen nicht geklickt wurde? Die Analyse sollte Ihnen auch Aufschluss darüber geben, auf welche Bereiche Sie sich konzentrieren sollten, die unterdurchschnittlich abschneiden oder von denen Sie zumindest vermuten, dass sie unterdurchschnittlich abschneiden, wie z. B. die Null-Ergebnis-Abfragen oder die Abfragen ohne Klick. Denken Sie jedoch daran, dass eine Abfrage mit null Ergebnissen das Fehlen relevanter Informationen in der Sammlung widerspiegeln kann oder dass es durchaus möglich ist, die gesuchte Antwort allein aus den Titeln und Ausschnitten der Suchergebnisse zu erhalten, ohne auf etwas zu klicken. Und schließlich sollten Sie bedenken, dass die Protokollanalyse keine tatsächliche Relevanzbewertung ermöglicht. Sie haben bestenfalls Schätzungen darüber, was Ihre Nutzer für relevant halten. Die Log-Analyse wird im Laufe der Zeit zweifellos eine Menge Daten liefern und kann sich schnell verselbstständigen.

Empirische Prüfung

Ähnlich wie bei der Protokollanalyse werden beim empirischen Testen echte Daten und echte Benutzeranfragen verwendet, aber man geht noch einen Schritt weiter und fügt echte Relevanzurteile hinzu. In den meisten Fällen sollten die empirischen Tests mit mindestens den 50 beliebtesten Abfragen und etwa 20 zufälligen Abfragen durchgeführt werden. Wenn Ihre Anwendung eine besonders breite Streuung von Abfragen erhält, sollten Sie die Anzahl der ausgewählten Zufallsabfragen erhöhen. Sobald die Abfragen ausgewählt sind, sollte mindestens eine Person (idealerweise zwei oder drei, die alle keine Entwickler sind) die Abfragen durch das System laufen lassen. Für jede Abfrage sollten sie die fünf oder zehn besten Ergebnisse entweder als relevant oder nicht relevant einstufen. In vielen Fällen kann es sinnvoller sein, sie wie folgt einzustufen: relevant, einigermaßen relevant, nicht relevant, peinlich, denn Relevanz ist selten schwarz oder weiß. Das Ziel ist es, die Relevanz zu maximieren und die Zahl der peinlichen und nicht relevanten Ergebnisse zu minimieren.

Sobald die Einstufung erfolgt ist, können Sie die Ergebnisse durchgehen und feststellen, wo Sie gut abgeschnitten haben und wo Sie sich verbessern müssen, einschließlich der Generierung von Präzisions-/Recall-Informationen, wie bei TREC-Tests. In manchen Fällen können Sie aus den guten Ergebnissen genauso viel lernen wie aus den schlechten Ergebnissen. Schließlich sollten Sie diese Art von empirischen Tests so oft durchführen, wie Sie es aushalten können, oder zumindest dann, wenn Sie wesentliche Änderungen am System vornehmen oder neue Trends bei Ihren Top-Abfragen feststellen. Im Laufe der Zeit und mit Ihren Verbesserungen können Sie beginnen, die Beurteilungen als halbautomatischen Regressionstest zu verwenden.

Bei jeder der oben beschriebenen Methoden werden Sie am Ende eine Reihe von Abfragen haben, die Ihrer Meinung nach nicht gut genug sind. Anhand dieser Abfragen können Sie mit der Fehlersuche beginnen, die ich im nächsten Abschnitt erläutern werde.

Beseitigung von Relevanzproblemen

Die Behebung von Relevanzproblemen ist ähnlich wie Edisons Genie-Gleichung: 1% Inspiration und 99% Transpiration. Das Debuggen von Suchsystemen ist zeitaufwändig, aber notwendig. Es kann innerhalb weniger Minuten sowohl frustrierend als auch unterhaltsam sein. Wenn es richtig gemacht wird, sollte es zu besseren Ergebnissen und einem tieferen Verständnis der Funktionsweise Ihres Systems führen.

Wenn Sie eine oder mehrere Abfragen haben, die mit den oben beschriebenen Methoden ermittelt wurden, beginnen Sie mit einer Bewertung der Abfragen. Achten Sie dabei auf Rechtschreibfehler, Fachausdrücke, Abkürzungen, falsche Groß- und Kleinschreibung und die mögliche Verwendung häufigerer Synonyme. Verfolgen Sie auch, welche Abfragen keine Ergebnisse lieferten, und legen Sie sie beiseite. Wenn Sie Urteile haben, lassen Sie die Abfragen laufen und sehen Sie, ob Sie mit den Urteilen übereinstimmen oder nicht. Wenn Sie keine Einschätzungen haben, nehmen Sie Ihre eigenen auf. Dabei geht es nicht so sehr darum, den Richter zu hinterfragen, sondern vielmehr darum, ein besseres Gefühl dafür zu bekommen, wo Sie Ihre Zeit verbringen sollten oder ob Sie Systemkenntnisse anwenden können, die der Richter nicht hat. Machen Sie sich Notizen zu Ihren ersten Eindrücken von den Abfragen und deren Ergebnissen. Priorisieren Sie Ihre Arbeit danach, wie beliebt die Abfrage in Bezug auf das Abfragevolumen ist. Auch wenn es gut ist, Probleme mit seltenen Abfragen zu untersuchen, sollten Sie die meiste Zeit zunächst auf die größeren Abfragen verwenden. Mit zunehmender Erfahrung wird Ihnen diese vorläufige Bewertung eine gute Vorstellung davon vermitteln, wo Sie tiefer graben und wo Sie aussetzen sollten.

Probieren Sie für alle Abfragen, bei denen die Rechtschreibung oder Synonyme (Fachausdrücke, Abkürzungen usw.) ein Problem darstellen, einige alternative Abfragen aus, um zu sehen, ob sie bessere Ergebnisse liefern (am besten bitten Sie Ihre Tester, dies zu tun), und führen Sie eine Liste mit dem, was geholfen hat und was nicht, da diese später bei der Behebung der Probleme verwendet werden kann. Sie können auch versuchen, eine Reihe von Abfragen systematisch durchzuarbeiten und Wörter zu entfernen, Wörter hinzuzufügen, Operatoren zu ändern und Term-Boosts zu ändern.

Schauen Sie sich als nächstes an, wie die Abfragen analysiert wurden. Welche Arten von Abfragen wurden erstellt? Suchen sie in den erwarteten Feldern? Werden die richtigen Begriffe geboostet? Weisen Phrasenabfragen einen entsprechenden Slop auf? Vergewissern Sie sich außerdem, dass Ihre Analyse der Abfragezeit mit Ihrer Indexierungsanalyse übereinstimmt. (Für Entwickler, die ihre eigenen Abfragen programmatisch erstellen, ist eine nicht übereinstimmende Analyse ein subtiler Fehler, der schwer aufzuspüren sein kann. Sehen Sie sich außerdem an, welche Operatoren verwendet werden und ob Begriffsgruppierungen falsch sind. Und schließlich: Ist die Abfrage übermäßig komplex? Manchmal scheint es vorteilhaft zu sein, immer mehr Abfrage-„Features“ hinzuzufügen, um jeden noch so kleinen Eckfall abzudecken. Dies führt jedoch nicht immer zu den erwarteten Ergebnissen, da es manchmal schwer ist, die Auswirkungen vorherzusagen, und es macht die Fehlersuche viel komplexer. Analysieren Sie stattdessen sorgfältig, was das Ziel der neuen Funktion ist, und lassen Sie sie dann durch Ihre Tests laufen, um die Auswirkungen zu sehen.

Notiz

In Solr können Sie die endgültige Abfrage erhalten, indem Sie &debugQuery=true zu Ihrer Eingabeabfrage hinzufügen. In Lucene müssen Sie die endgültige Abfrage protokollieren, um sie zu sehen.

Erklärungen prüfen

Wenn Sie wissen, dass niedriger eingestufte Ergebnisse besser sind als höher eingestufte Ergebnisse oder wenn Sie einfach nur neugierig sind, warum etwas so eingestuft wurde, wie es eingestuft wurde, dann ist es an der Zeit, einen Blick auf Lucene und die explain-Funktion von Solr zu werfen, um zu verstehen, warum Lucene es niedriger einstuft. In Lucene ist explain eine Methode auf Searcher mit der folgenden Signatur:

              public Explanation explain(Query query, int doc) throws IOException

Geben Sie einfach die Query und die interne Lucene-Dokumenten-ID (die von TopDocs/Hits zurückgegeben wird) ein und zeigen Sie die Ergebnisse von Explanation an. In Solr fügen Sie den Parameter debugQuery=true hinzu, um eine Reihe von Informationen über die Suche zu erhalten, einschließlich Erklärungen für alle Ergebnisse.

Um die Erklärungen in Aktion zu sehen, verwenden Sie das Solr-Tutorial-Beispiel und die Daten und versuchen Sie dann die Abfrage
http://localhost:8983/solr/select/?q=GB&version=2.2&start=0&rows=10&indent=on&debugQuery=true&fl=id,score.
In meinem Fall liefert Solr die folgenden sechs Ergebnisse:

<str name=“id“>VS1GB400C3</str>
</doc>
<doc>
<float name=“score“>0.14651334</float>
<str name=“id“>TWINX2048-3200PRO</str>
</doc>
<doc>

<float name=“score“>0.12950073</float>
<str name=“id“>VDBDB1A16</str>
</doc>
<doc>
<float name=“score“>0.103600584</float>
<str name=“id“>SP2514N</str>
</doc>

Nehmen wir an, ich halte das sechste Ergebnis für besser als das erste (beachten Sie, dass dies nur ein Beispiel ist. Ich würde mir nie Gedanken über die Reihenfolge der Ergebnisse innerhalb der Top Ten machen, es sei denn, die Anforderungen sehen ausdrücklich vor, dass ein Beispiel aus redaktionellen Gründen an einer bestimmten Stelle erscheinen muss). Da die Punktzahl für das sechste Element 0,07 (gerundet) beträgt, verglichen mit 0,18 für das erste, würde ich mir die Erklärungen der beiden ansehen, um die Gründe für die Punktzahlen zu erfahren. In diesem Fall lautet die Erklärung für Ergebnis eins:

<str name=“6H500F0″>
0.18314168 = (MATCH) Summe von:
0.18314168 = (MATCH) weight(text:gb in 1), Produkt von:
0.35845062 = queryWeight(text:gb), Produkt von:
2.3121865 = idf(docFreq=6, numDocs=26)
0.15502669 = queryNorm
0.5109258 = (MATCH) fieldWeight(text:gb in 1), Produkt aus:
1.4142135 = tf(termFreq(text:gb)=2)
2.3121865 = idf(docFreq=6, numDocs=26)
0.15625 = fieldNorm(field=text, doc=1)
</str>

während das sechste Ergebnis ergibt:

<str name=“MA147LL/A“>
0.07770044 = (MATCH) Summe von:
0.07770044 = (MATCH) weight(text:gb in 4), Produkt von:
0.35845062 = queryWeight(text:gb), Produkt von:
2.3121865 = idf(docFreq=6, numDocs=26)
0.15502669 = queryNorm
0.21676749 = (MATCH) fieldWeight(text:gb in 4), Produkt aus:
1.0 = tf(termFreq(text:gb)=1)
2.3121865 = idf(docFreq=6, numDocs=26)
0.09375 = fieldNorm(field=text, doc=4)
</str>

Eine Prüfung dieser Ergebnisse zeigt, dass die meisten Werte gleich sind, mit Ausnahme der TF- (Termfrequenz) und fieldNorm-Werte. Im ersten Dokument kommt „gb“ zweimal im Feld „text“ vor, was einen TF-Wert von 1,414… (2^0.5), während im anderen Dokument „gb“ nur einmal vorkommt, was einen TF-Wert von 1 ergibt. Der fieldNorm-Wert ist etwas schwieriger zu interpretieren, da er mehrere Faktoren zusammenfasst: Dokumentverstärkung, Feldverstärkung und Längennormalisierung. Um diesen Wert zu vergleichen, bin ich zu jedem der Dokumente zurückgegangen und habe festgestellt, dass keines von ihnen während der Indizierung erhöht wurde, was bedeutet, dass der einzige Faktor in der fieldNorm auf die Längennormalisierung zurückzuführen ist.

Notiz

Die Längennormalisierung ist ein gängiger Suchmechanismus, um die Tatsache auszugleichen, dass längere Dokumente höchstwahrscheinlich mehr Erwähnungen eines Wortes aufweisen als kürzere Dokumente, aber das bedeutet nicht, dass sie relevanter sind als das kürzere Dokument. Wenn alles andere gleich ist, lesen die meisten Menschen lieber ein kurzes Dokument als ein langes. Die Standardberechnung der Längennormalisierung lautet:
len norm = 1/(num terms) ^0.5

In diesem Fall ist das erste Dokument kürzer, was zu einem größeren fieldNorm-Wert führt. Die Kombination der größeren fieldNorm mit dem größeren TF-Wert führt dazu, dass das erste Dokument höher eingestuft wird. Wenn ich das sechste Ergebnis wirklich verbessern wollte, könnte ich eine oder mehrere der Ideen ausprobieren, die ich in meinem Artikel über Auffindbarkeit bespreche.

Je komplexer die Abfragen werden, desto komplexer werden auch die Erklärungen. Der Schlüssel zum Umgang mit der Komplexität liegt darin, sich auf die Faktoren zu konzentrieren, die unterschiedlich sind. Sobald Sie ein Gefühl für die Unterschiede bekommen haben, sollten Sie sich die beteiligten Faktoren genauer ansehen. Eines der häufigsten Dinge, die Sie sich ansehen sollten, ist die Analyse eines Dokuments, die wir im Abschnitt über die Tools weiter unten behandeln.

Finden von Inhaltsproblemen

Viele Relevanzprobleme lassen sich einfach dadurch lösen, dass Sie überprüfen, ob die Eingabedokumente indiziert wurden und ob die indizierten Dokumente die richtigen Felder und Analyseergebnisse enthalten. Prüfen Sie auch, ob die Abfragen die erwarteten Felder durchsuchen. Bei bestehenden Indizes können Sie auch Ihren Index durchgehen und eine Bestandsaufnahme der vorhandenen Felder vornehmen. Es ist zwar nicht schlimm, wenn ein Dokument kein Feld enthält, aber es kann ein Hinweis darauf sein, dass etwas nicht stimmt, wenn in vielen Dokumenten ein Feld fehlt, nach dem Sie häufig suchen.

Andere Herausforderungen bei der Fehlersuche

Zwar können Erklärungen und andere Debugging-Tools dabei helfen, Relevanzprobleme zu erkennen, aber es gibt viele subtile Erkenntnisse, die sich nur durch die Arbeit mit Ihrer spezifischen Anwendung ergeben. Insbesondere der Umgang mit Abfragen, die keine Ergebnisse liefern, kann problematisch sein, da nicht klar ist, ob die Probleme auf Probleme in der Engine (Analyse, Abfragekonstruktion usw.) zurückzuführen sind oder ob wirklich keine relevanten Dokumente verfügbar sind. Um Probleme mit Null-Ergebnissen zu beheben, erstellen Sie alternative Formen der Abfrage, indem Sie Synonyme hinzufügen, die Schreibweise ändern oder andere Änderungen auf Wortebene ausprobieren. Es kann auch hilfreich sein, in den Protokollen nachzuschauen, welche anderen Abfragen der Benutzer zum Zeitpunkt der fehlerhaften Abfrage gestellt hat, und diese auszuprobieren, vor allem, wenn sie zu Click-Throughs geführt haben. Als nächstes könnte ich versuchen festzustellen, ob es Facetten oder andere Navigationshilfen gibt, die der Suche nach relevanten Dokumenten nahe kommen könnten. Wenn die Abfrage z.B. nach einem „Flusskondensator“ sucht und keine Ergebnisse liefert, enthalten die Facetten vielleicht so etwas wie „Zeitmaschinenkomponenten“, die dann untersucht werden können, um zu sehen, ob diese viel kleinere Menge von Dokumenten ein relevantes Dokument enthält. Ist dies der Fall, können die Dokumente, wie oben beschrieben, daraufhin untersucht werden, warum sie nicht übereinstimmen.

Tools für die Fehlersuche

Es gibt mehrere hilfreiche Tools zur Behebung von Relevanzproblemen, von denen einige in den folgenden Abschnitten beschrieben werden.

TREC-Tools

Wenn Sie mit TREC arbeiten, stehen Ihnen Tools zur Verfügung, mit denen Sie Experimente durchführen (siehe Lucene’s contrib/benchmark code) und die Auswertungen überprüfen können. Insbesondere das Programm trec_eval gibt es schon seit geraumer Zeit. Es liefert Informationen über die Genauigkeit und den Wiedererkennungswert für TREC-artige Experimente.

Analyse-Tools

In vielen Fällen können Suchprobleme durch Analysetechniken gelöst werden. Um Analyseprobleme besser zu verstehen, lohnt es sich, das Ausspucken der Analyseergebnisse zu erleichtern. In Lucene kann dies durch einen einfachen Code geschehen, wie zum Beispiel:

Analyzer analyzer = new StandardAnalyzer();//replace with your analyzer
TokenStream stream = analyzer.tokenStream("foo", new StringReader("Test String Goes here"));
Token token = new Token();
while ((token = tokenStream.next(token)) != null) {
 System.out.println("Token: " + token);
}

Natürlich möchten Sie dies generisch gestalten, um mit jeder Eingabezeichenkette und einer Vielzahl von Analyzern umgehen zu können.

Der obige Code ist zwar ziemlich einfach, aber mit Solr ist die Prüfung der Analyseausgabe kinderleicht. Und selbst wenn Sie sonst nichts von Solr verwenden, können Sie mit Solr bei der Fehlersuche in der Analyse viel Zeit sparen.

Um das Solr-Analysetool aufzurufen, starten Sie Solr und zeigen Sie mit einem Browser auf http://localhost:8983/solr/admin/analysis.jsp?highlight=on. Sie sollten etwas sehen, das dem Screenshot der Solr-Analyse entspricht:

Abbildung 1. Screenshot Solr-Analyse

Ein Beispiel für das Analyse-Tool von Solr

Über den Verwaltungsbildschirm können sowohl Dokumente als auch Abfragen eingegeben und die Ergebnisse analysiert werden. Wenn Sie die Option „Übereinstimmungen hervorheben“ aktivieren, wird angezeigt, wo eine Abfrage möglicherweise mit einem Dokument übereinstimmt. Wenn ich zum Beispiel untersuchen möchte, wie sich der WordDelimiterFilter von Solr auf Abfragen auswirkt, könnte ich die Optionen in der Abbildung unten eingeben. Beachten Sie, dass der WordDelimiterFilter verwendet wird, um Wörter anhand von Übergängen innerhalb des Wortes wie Bindestrichen, Groß- und Kleinschreibung, alphanumerischen Übergängen und anderen Dingen aufzuteilen.

Abbildung 2. WordDelimiterFilter Beispiel

Ein Beispiel für Analysetext mit wortinternen Begrenzungszeichen wie Bindestrichen und Zahlen

Wenn Sie den Text im WordDelimiterFilter-Beispiel übermitteln, werden sowohl die Abfrage als auch der Text durch das Feld „text“ geleitet. Das Textfeld im Solr-Schema im Beispiel ist wie im Solr-Tutorial konfiguriert:

Die Teilergebnisse dieses Vorgangs können Sie unter Ergebnisse der Probenanalyse sehen.

Abbildung 3. Ergebnisse der Probenanalyse

Die Teilergebnisse der Übermittlung einer Beispielabfrage und eines Dokuments an das Analyse-Tool von Solr.

Beachten Sie in der Ergebnisabbildung die lila hervorgehobenen Bereiche. Diese Bereiche zeigen an, wo die Suchbegriffe und die Dokumentbegriffe übereinstimmen und somit eine Analyseübereinstimmung ergeben. Obwohl ich also zwei ähnliche, aber unterschiedliche Begriffe eingegeben habe, konnte ich eine Übereinstimmung erzielen.

Diese Art der Analyse kann mühsam sein, wenn Sie eine große Anzahl von Dokumenten haben, aber sie ist sehr nützlich, wenn es sich um gezielte Fälle handelt. Wenn Sie den Verdacht haben, dass Sie ein Analyseproblem haben, sollten Sie sich die Zeit dafür nehmen. Andernfalls gehen Sie weiter und probieren Sie einige der anderen Ideen und Tools aus.

Luke zum Debuggen verwenden

Luke, ein von Lucid-Berater Andrzej Bialecki geschriebenes Tool, ist ein allgemeines Debugging-Tool für Lucene-Indizes, mit dem Sie auf einfache Weise die Begriffe und Dokumente in einem Index inspizieren sowie Beispielabfragen ausführen und andere Lucene-Teile untersuchen können.

Oftmals, insbesondere bei Dokumenten in anderen Sprachen, zeigt ein kurzer Blick auf Luke, dass Dokumente nicht korrekt indiziert wurden oder dass Dokumente gefunden werden können, wenn Sie die Eingabeabfrage ändern oder einen anderen Analyzer verwenden.

Die Zusammenfassung von Luke ist ebenfalls sehr hilfreich. Sie informiert Sie darüber, ob Sie die erwartete Anzahl von Dokumenten in Ihrem Index haben und wie viele eindeutige Begriffe indiziert wurden. Wenn einer der beiden Werte nicht stimmt, sollten Sie Ihren Indexierungsprozess noch einmal überprüfen.

Umgang mit Konflikten zwischen Präzision und Rückruf

Wenn Sie sich mit Relevanzproblemen befassen und Ihre Verbesserungen durch Wiederholung Ihrer empirischen Tests (TREC oder Ihre eigenen) überprüfen, werden Sie wahrscheinlich auf einige Probleme stoßen. Erstens führen Änderungen, die die Genauigkeit verbessern sollen, wie z.B. die vermehrte Verwendung des Operators AND, oft zu einem Rückgang der Trefferquote. Ebenso führen Änderungen zur Verbesserung des Recall oft zu einem Rückgang der Präzision. Versuchen Sie in diesen Fällen, bestimmte Abfragen zu identifizieren, die zum Besseren oder Schlechteren verändert wurden (trec_eval kann die Leistung einzelner Abfragen ausgeben), und sehen Sie nach, ob es einen offensichtlichen Kompromiss gibt. Letztendlich ist in den meisten Fällen die Genauigkeit wichtiger als der Rückruf, da die Benutzer selten über die erste oder zweite Seite der Ergebnisse hinausgehen. Gehen Sie jedoch noch einmal auf die wichtigsten Relevanzziele Ihres Systems ein, um zu bestimmen, welchen Kompromiss Sie wählen sollen.

Schlussfolgerungen

Es gibt zwar eine große Anzahl von Dingen, die bei der Relevanz falsch laufen können, aber die meisten sind relativ leicht zu erkennen. Viele davon stehen in direktem Zusammenhang mit fehlerhaften Daten oder damit, dass das richtige Feld nicht auf die richtige Weise durchsucht wird (oder das Feld überhaupt nicht durchsucht wird). Die meisten dieser Probleme lassen sich schnell beheben, indem Sie die Annahme, dass die Daten korrekt sind, in Frage stellen und sich die Mühe machen, zu überprüfen, ob sie tatsächlich korrekt sind.

Achten Sie außerdem auf einen systematischen Ansatz beim Testen und Debuggen. Insbesondere beim Stapeltest einer großen Anzahl von Abfragen neigen die Experimente dazu, zusammenzulaufen. Machen Sie sich zu jedem Experiment genaue Notizen und widerstehen Sie der Versuchung, Namen und Beschreibungen zwischen den Durchläufen auszuschneiden und einzufügen. Wenn möglich, verwenden Sie eine Datenbank oder ein Versionskontrollsystem, um die Experimente im Laufe der Zeit zu verfolgen.

Und schließlich sollten Sie sich auf die Relevanz als Makro- und nicht als Mikroproblem konzentrieren, um eine bessere Erfahrung für alle Beteiligten zu erreichen.

Ressourcen

Nutzen Sie die folgenden Ressourcen, um mehr über Relevanztests und andere verwandte Themen zu erfahren

Probieren Sie das Solr-Tutorial aus.
Erfahren Sie mehr über die Schulungsangebote von Lucid
Laden Sie Luke zum Debuggen von Lucene herunter.
Erfahren Sie mehr über die Theorie der Relevanz.
Erfahren Sie mehr über die Leistung von Lucene, einschließlich der Qualität, in meinem Vortrag auf der ApacheCon Europe 2007.
Lesen Sie das Solr-Tutorial.
Verwenden Sie das TREC Eval-Programm, um die Präzision und den Recall in TREC-ähnlichen Experimenten zu bewerten.
Lesen Sie die vollständige Zuschreibung für das geniale Zitat von Thomas Edison.
Verfolgen Sie die neueste Forschung im Bereich Relevanz und Information Retrieval bei SIGIR

Analytics Studio: Verwandeln Sie Ihre E-Commerce-Daten in verwertbare Einblicke

Entdecken Sie, wie Analytics Studio Teams in die Lage versetzt, datengestützte Entscheidungen...

Wenn KI schief geht: Fehlschläge in der realen Welt und wie man sie vermeidet

Lassen Sie nicht zu, dass Ihr KI-Chatbot einen 50.000 Dollar teuren Tahoe...

Lucidworks Kernpakete: Branchenoptimierte KI-Such- und Personalisierungslösungen

Entdecken Sie unsere umfassenden Core Packages, die Analytics Studio, Commerce Studio und...

Solr-Suchrelevanztests

Viele Leute konzentrieren sich ausschließlich auf die Geschwindigkeit der Suche und vernachlässigen dabei oft die Qualität der vom System erzeugten…

Qualität der Relevanz bestimmen

Log-Analyse

Empirische Prüfung

Beseitigung von Relevanzproblemen

Notiz

Erklärungen prüfen

Notiz

Finden von Inhaltsproblemen

Andere Herausforderungen bei der Fehlersuche

Tools für die Fehlersuche

TREC-Tools

Analyse-Tools

Luke zum Debuggen verwenden

Umgang mit Konflikten zwischen Präzision und Rückruf

Schlussfolgerungen

Ressourcen

You Might Also Like

Analytics Studio: Verwandeln Sie Ihre E-Commerce-Daten in verwertbare Einblicke

Wenn KI schief geht: Fehlschläge in der realen Welt und wie man sie vermeidet

Lucidworks Kernpakete: Branchenoptimierte KI-Such- und Personalisierungslösungen