Verwaltete Synonyme mit mehreren Wörtern in Solr mit Unterstützung für Abfragen in Echtzeit

Tutorial und Beispiele für die Abfrageunterstützung von Mehrwortsynonymen in Apache Solr mit den eDismax- und Standard/Lucene-Abfrageparsern.

Solr hat in den Abfrageparsern edismax und standard/“lucene“ Unterstützung für die Verwaltung von Synonymen mit mehreren Wörtern zur Abfragezeit erhalten.

Cool, oder? Aber warum sollte Sie das interessieren?

Index-Zeit-Synonymerweiterung hat Probleme

Die Synonymerweiterung zur Indexzeit ist eine Alternative zur Erweiterung zur Abfragezeit, aber die Erweiterung von Synonymen zur Indexzeit hat zwei große Probleme. An dieser Stelle kommen die von Solr verwalteten Synonyme ins Spiel.

Erstens können Phrasenabfragen, die erweiterte Mehrwortsynonyme umfassen, fehlschlagen. Da das Indexformat von Lucene Positionsinformationen pro Token speichert, um Phrasenabfragen zu unterstützen, aber keine Positionslängeninformationen speichert, können Mehrwortsynonyme nicht richtig mit den umgebenden Wörtern ausgerichtet werden, was dazu führt, dass einige Synonyme enthaltende Phrasenabfragen, die passen sollten, nicht passen und einige, die nicht passen sollten, nicht passen. (Aufgrund der Art und Weise, wie überlappende Begriffe dargestellt werden, wird dies als „Verwurstung“ bezeichnet – vergleichen Sie dazu das „Wortgitter“ in der Abbildung oben auf dieser Seite).

Wenn zum Beispiel die Index-Zeit-Synonymerweiterung „US, Vereinigte Staaten“ wird für ein Dokument ausgeführt, das den Satz „US-Umsatz gestiegen„, wird es mit “ indiziert.Vereinigte“ und „US„, die eine Position einnimmt, und „Staaten“ und"sales “ den nächsten (siehe unten). Infolgedessen wird die Phrasenabfrage"Verkäufe in den Vereinigten Staaten “ nicht mit diesem Dokument übereinstimmen und die Phrasenabfrage"Verkäufe in den Vereinigten Staaten “ wird nicht korrekt übereinstimmen.

Position:	1	2	3
Original:	`US`	`Verkauf`	`mehr`
Synonyme:	`Vereinigte`	`Staaten`

Zweitens müssen Sie, um die Synonymerweiterung zur Indexzeit zu ändern, die Indexierung komplett neu erstellen. Dies kann für Indizes, deren Erstellung viel Zeit in Anspruch nimmt, oder für Indizes, die Probleme mit dem Zugriff auf die Quelle haben, ein entscheidender Nachteil sein.

Solr Geschichte: F: Mehrwort-Synonyme zur Abfragezeit? A: Nein.

Die Abfrageparser von Solr haben ein langjähriges Problem: Das Abgleichen von Mehrwortsynonymen zur Abfragezeit war nicht direkt möglich^[1]. Man hat sich sehr viel Mühe gegeben^[2]^[3]^[4]^[5] um dieses Problem zu beheben, aber keine dieser indirekten Lösungen wurde bisher in Solr integriert, so dass die Anwender gezwungen waren, sich mit abgehackten Upgrade-Pfaden auseinanderzusetzen.

Die Ursache: Query Parser teilen sich auf Leerzeichen auf

Die Wurzel des Problems ist eine Parsing-Strategie, die von den Abfrageparsern von Solr verwendet wird: Bevor der Abfragetext zur Analyse gesendet wird, wird er zunächst an Leerzeichen gesplittet. Wenn Sie zum Beispiel die Abfrage “ Vereinigte Staaten„, sehen die Textanalyse-Komponenten immer nur ein Wort auf einmal: zuerst „Vereinigte„, und dann in einer separaten Analysesitzung, „Staaten„. Wenn ein Synonymfilter so konfiguriert ist, dass er „USA“ als ein Synonym für „Vereinigte Staaten“ für jedes einzelne Wort in der Abfrage aufgerufen wird, werden weder"United “ noch"States “ vollständig mit dem Quellensynonym"United States “ übereinstimmen, so dass die Abfrage niemals das Zielsynonym USA enthält.

Die Lösung (Teil 1): `sow=false`

Solr 6.5 enthält eine direkte Out-of-the-Box-Lösung: Die Parser für Abfragen von edismax und standard/“lucene“ unterstützen jetzt das „säen“ (kurz für Split On Whitespace), die, wenn sie auf “ falsch“ bewirkt, dass der Abfragetext als eine Einheit erhalten bleibt, wenn er an das Analysegerät gesendet wird. Fahren Sie mit dem Beispiel der „Vereinigte Staaten, USA„Synonymfilter mit Abfragezeit-Analysator: In der folgenden Abfrage werden Dokumente, die nur „USA“ übereinstimmen, auch wenn die Synonymexpansion zur Indexzeit nicht durchgeführt wurde:

http://localhost:8983/solr/mycollection/select?q=United+States&df=myfield&sow=false

Alternativ dazu:

http://localhost:8983/solr/mycollection/select?q={!lucene sow=false df=myfield}United+States

Und mit edismax:

http://localhost:8983/solr/mycollection/select?q={!edismax sow=false df=myfield}United+States

Sobald Sie jedoch sow=false verwenden, stellt sich heraus, dass SynonymFilter seine eigenen Probleme mit der Behandlung falscher Positionslängen hat, die die oben beschriebenen Probleme mit der Synonymerweiterung zur Indexzeit widerspiegeln.

Die Lösung (Teil 2): SynonymGraphFilter für die Abfragezeit

SynonymFilter wurde zugunsten von SynonymGraphFilter veraltet, der die Positionslänge korrekt behandelt und korrekte Graphdarstellungen von Token-Streams erzeugt, die sich überschneidende Synonyme mit unterschiedlicher Wortanzahl enthalten.

In Solr 6.6 werden die mit Solr ausgelieferten Beispielschemata solr.SynonymGraphFilterFactory an der Stelle haben, an der bisher solr.SynonymFilterFactory war. In der Zwischenzeit müssen Sie Ihre Feldtypen so ändern, dass die Synonymerweiterung nur zur Abfragezeit durchgeführt wird, z.B.:

<fieldType name="text_general" class="solr.TextField"
           positionIncrementGap="100" multiValued="true">
  <analyzer type="index">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true"
            words="stopwords.txt"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true"
            words="stopwords.txt"/>
    <filter class="solr.SynonymGraphFilterFactory" synonyms="synonyms.txt"
            ignoreCase="true" expand="true"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>

Die Lösung (Teil 3): Graph-basierter `QueryBuilder`

Die Infrastruktur für die Erstellung von Lucene-Abfragen, die von den Abfrageparsern von Solr verwendet wird, wurde aktualisiert, um Graph-Token-Streams, z.B. die von SynonymGraphFilter erzeugten, automatisch zu erkennen und sie bei der Erstellung von Abfragen richtig zu interpretieren. Dies behebt ein weiteres Problem, das in der Vergangenheit bei Mehrwortsynonymen in Lucene und Solr auftrat: Abfragen wurden mit allen möglichen Kombinationen von sich überschneidenden Begriffen erstellt, was zu unbeabsichtigten Übereinstimmungen führen konnte. (Siehe Nolan Lawsons Blog ^[2] finden Sie einige Beispiele für den Wahnsinn der Überschneidungen, wenn Sie neugierig sind).

Vorbehalte und verbleibende Fragen

Die Abfrageparser dismax und complexphrase usw. trennen immer noch nach Leerzeichen und unterstützen den Abfrageparameter sow=false nicht.
In Solr 6.5 ist die Feldtypoption autoGeneratePhraseQueries=true mit dem Abfrageparameter sow=false nicht zulässig, da der Code zur Implementierung von autoGeneratePhraseQueries=true davon abhängt, dass Abfrageparser Leerzeichen aufspalten. Dies kann z.B. bei einer Abfrage"wi-fi„, die mittels WordDelimiterFilter zu"wi fi“ erweitert wird, oder bei einem einzelnen Wort, das in ein Mehrwortsynonym umgewandelt wird (und das ursprüngliche Wort ausschließt, d.h. die Synonymfilteroption expand="false" verwendet), ein Problem darstellen. In Solr 6.6 wurde dieses Verbot aufgehoben, indem die Option autoGeneratePhraseQueries für Graphabfragen (z.B. solche, die von SynonymGraphFilter erzeugt werden) aktiviert wurde, aber der WordDelimiterFilter-Fall"wi-fi => wi fi“ ist immer noch ein Problem.
Der Abfrageparameter sow=false kann verwendet werden, um alle Arten von Mehrwort-Analyseprozessen zu ermöglichen, nicht nur Mehrwort-Synonyme. In Solr 6.5 lösen sow=false-Abfragen über ein Feld, das so konfiguriert ist, dass es über ShingleFilter Schindeln unterschiedlicher Größe erzeugt, zwar die Verarbeitung von Graph-Abfragen aus, führen aber aufgrund der Art und Weise, wie Graph-Abfragen konstruiert werden, zu einem falschen Abgleich der Dokumente. Mit Solr 6.5.1 wurde eine neue Feldtypoption"enableGraphQueries=false“ eingeführt, die zusammen mit ShingleFilter verwendet werden kann, um die Konstruktion von Graphabfragen zu deaktivieren und so das Problem zu vermeiden.
Dokumente mit seltenen Synonymen werden höher bewertet als solche mit häufigen Synonymen. Dies kann das Treffer-Ranking verzerren. (Obwohl dieses Problem nicht spezifisch für die Verwendung von Mehrwortsynonymen ist, ist die Synonymerweiterung bei Abfragen ohne Unterstützung von Mehrwortsynonymen nur eingeschränkt möglich). Einige der alternativen Lösungen für die Synonymerweiterung bei Abfragen mit mehreren Wörtern^[2]^[3]^[4]^[5] sind in der Lage, Synonyme getrennt von der ursprünglichen Abfrage zu erweitern, wodurch die Auswirkungen seltener Synonyme auf die Bewertung reduziert werden. Eine Abhilfe mit OOTB Solr könnte darin bestehen, eine Abfrage über ein Feld ohne Synonymerweiterung zur Abfragezeit, die höher geboostet wird, mit einer Abfrage über ein Feld mit Kopierfeldern mit Synonymerweiterung zur Abfragezeit, die niedriger geboostet wird, zu kombinieren.
Wie Doug Turnbull auf der Mailingliste solr-user anmerkte^[6] (empfohlene Lektüre, insbesondere für seine Diskussion der Einschränkungen des neuen Abfrageparameters sow=false ), ändert sow=false die Abfragen, die Edismax über mehrere Felder erstellt, wenn sich die Abfragezeitanalyse eines der Felder von der der anderen Felder unterscheidet, z.B. wenn der Anlyzer eines Feldes Stoppwörter entfernt, während der eines anderen Feldes dies nicht tut. In diesem Fall wird anstelle einer dismax-Abfrage pro durch Leerzeichen getrennten Begriff (das Verhalten von edismax bei sow=true) eine dismax-Abfrage pro Feld erstellt. Dies kann die Ergebnisse im Allgemeinen verändern, aber in Kombination mit dem Abfrageparameter mm (min-should-match) ganz erheblich: Da min-should-match pro Feld und nicht pro Begriff angewendet wird, disqualifizieren fehlende Begriffe in der Analyse eines Feldes die Dokumente nicht vom Abgleich. Eine Abfrage"Terminator 100“ mit dem Abfrageparameter"mm=100%“ gegen ein title (Text)-Feld und ein run_length (Integer)-Feld ergibt z.B. folgende Abfragen:Wenn sow=true:
+(DisjunctionMaxQuery((title:terminator)) DisjunctionMaxQuery((run_length:[100 TO 100] | title:100)))~2Wenn sow=false:
+DisjunctionMaxQuery((run_length:[100 TO 100] | ((title:terminator title:100)~2)))Im obigen Szenario muss bei sow=true (und in Versionen von Solr vor 6.5)"terminator“ in den Dokumenten vorkommen, um einen Treffer zu erzielen. Bei sow=false hingegen kann ein Dokument einen Treffer erzielen, wenn sein run_length-Feld 100 ist, auch wenn der Titel kein „terminator“ enthält.

Zusammenfassung und Empfehlungen

Verwenden Sie den Abfrageparameter sow=false mit Standard/“lucene“ und edismax Abfrageparsern, um Mehrwortsynonyme zur Abfragezeit zu aktivieren.
Wechseln Sie zu SynonymGraphFilter in Ihrem Abfragezeit-Analysator. In den meisten Fällen werden Sie keine Synonymerweiterung in Ihren Index-Time Analyzer aufnehmen wollen.
Geben Sie die Option expand="true" für SynonymGraphFilter an (oder belassen Sie es bei der Standardeinstellung, was dasselbe ist), damit alle Alternativen zur Abfrage hinzugefügt werden.
Beachten Sie, dass sich bei der Verwendung von sow=false mit edismax über Felder mit unterschiedlicher (ausreichender) Abfragezeitanalyse die Form der Abfrage von derjenigen unterscheidet, die bei sow=true erzeugt wird.

[1] Der„einfache“ Abfrageparser ist in der Lage, Leerzeichen nicht aufzuspalten und somit Synonyme für mehrere Wörter zur Abfragezeit zu ermöglichen, wenn Sie den Operator WHITESPACE deaktivieren, z.B. mit q.operators= (leerer Wert deaktiviert alle Operatoren) – siehe https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-SimpleQueryParser.

[2] Lucene/Solr Synonym-erweiternder EDisMax-Parser

JIRA: https://issues.apache.org/jira/browse/SOLR-4381
Blog: https://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/
Code: https://github.com/healthonnet/hon-lucene-synonyms

[3] Automatischer Phrasierungs-TokenFilter

[4] SOLR-5379: Mehrwort-Synonymerweiterung bei Abfragen

JIRA: https://issues.apache.org/jira/browse/SOLR-5379

[5] Der Match Query Parser

[6] Doug Turnbulls Beitrag auf der Solr-User Mailingliste„Die Nachteile der Nichtaufteilung bei Leerzeichen in Edismax (das alte Albino-Elefanten-Problem)„: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3cCALG6HL8W_cPeXCYnVKs2eSpDsTtcZ8_RbcYqWr+ZPoXwU5APPQ@mail.gmail.com% 3e

Credits: Das Bild basiert zum Teil auf einer Vektorzeichnung von Vecteezy.com.

Mehr über die automatische Synonym-Erkennung

LEVEL UP: Erklären Sie dem Unternehmen die Vorteile der automatischen Synonymerkennung

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...