Ich habe erfolgreich einen tschechischen Lemmatizer für Lucene implementiert. Ich teste es mit Solr und es klappt schön zur Indexzeit. Aber es funktioniert nicht so gut, wenn es für Abfragen verwendet wird, da der Abfrageparser dem Lemmatizer keinen Kontext (Wörter davor oder danach) zur Verfügung stellt.
Zum Beispiel wird die Phrase %code% zur Indexzeit anders ausgewertet als zur Abfragezeit. Es verwendet das mehrdeutige Wort %code% , was %code% (z. B. Kettensäge) oder %code% (die Vergangenheitsform des Verbs "zu trinken") bedeuten könnte.
%code% - & gt;
.. also das Wort %code% wurde nicht gefunden und nicht in einem Dokumentschnipsel hervorgehoben.
Dieses Verhalten ist dokumentiert im solr Wiki (zitiert unten) ) und ich kann es bestätigen, indem ich meinen Code debugge (nur isolierte Zeichenfolgen "pila" und "vodu" werden an den Lemmatizer übergeben).
... Der Lucene QueryParser tokentisiert auf Leerraum, bevor er dem Analyzer Text gibt. Wenn also eine Person nach den Wörtern %code% sucht, erhält der Analysator die Wörter "sea" und "biscit" getrennt. .
Ist es möglich, den Abfrage-Parser irgendwie zu ändern, zu konfigurieren oder anzupassen, so dass der Lemmatizer die gesamte Abfrage-Zeichenfolge oder zumindest einen Kontext einzelner Wörter sehen würde? Ich hätte gerne eine Lösung auch für verschiedene Solr-Abfrageparser wie dismax oder edismax .
Ich weiß, dass es bei Phrasenabfragen wie %code% (Anführungszeichen) kein solches Problem gibt, aber dann würde ich die Dokumente ohne den genauen Satz verlieren (zB Dokumente mit "pila víno" oder gar) "pila dobrou vodu" ).
Bearbeiten - versuchen, die folgende Frage zu erklären / zu beantworten (Danke @femtoRgon):
Wenn die beiden Begriffe keine Phrase sind und daher nicht notwendigerweise zusammenkommen, warum werden sie dann im Zusammenhang miteinander analysiert?
Sicher wäre es besser, nur zusammenkommende Begriffe zu analysieren. Zum Beispiel erkennt der Lemmatizer zur Indexierungszeit Sätze im Eingabetext und analysiert zusammen nur Wörter aus einem einzigen Satz. Aber wie erreicht man eine ähnliche Sache zur Abfragezeit? Ist die Implementierung meines eigenen Abfrageparsers die einzige Option? Ich mag die Optionen %code% und %code% des %code% Parsers, müsste ich sie im Fall meines eigenen Parsers erneut implementieren?
Die dahinter stehende Idee ist tatsächlich ein bisschen tiefer, weil der Lemmatizer Wort-Sinn macht -Debambiguation auch für Wörter, die die gleiche lexikalische Basis haben. Zum Beispiel hat das Wort %code% etwa 7 verschiedene Sinne in Englisch (siehe wikipedia ) und der Lemmatizer unterscheidet solche Sinne. Deshalb möchte ich dieses Potenzial nutzen, um die Suche präziser zu machen - nur Dokumente zurückgeben, die das Wort %code% im konkreten Sinne enthalten, die für die Abfrage erforderlich sind. Also könnte meine Frage erweitert werden auf: Wie bekomme ich das richtige %code% -pair für einen Suchbegriff? Der Lemmatizer ist sehr oft in der Lage, den korrekten Sinn zuzuweisen, wenn das Wort in seinem gemeinsamen Kontext präsentiert wird, aber es hat keine Chance, wenn kein Kontext vorhanden ist.
Schließlich habe ich meinen eigenen Abfrageparser implementiert.
Dank der %code% -Quellen war dies nicht so schwierig als Leitfaden und Referenzimplementierung. Ich könnte meine Parser-Ergebnisse leicht mit den Ergebnissen von %code% ...
vergleichenLösung:
Zuerst analysiere ich die gesamte Abfragekette zusammen. Dies gibt mir die Liste der "Tokens".
Es gibt einen kleinen Konflikt mit Stoppwörtern - es ist nicht so einfach Tokens für Stoppwörter zu erhalten, da sie vom Analysator weggelassen werden, aber Sie können sie von %code% erkennen.
Von "Tokens" konstruiere ich die Abfrage auf die gleiche Weise wie %code% (z. B. alle 2-Token- und / oder 3-Token-Phrasenabfragen in %code% Instanzen kombiniert).