Elasticsearch-Perkolator zur Steuerung der Suche im E-Commerce: Übersetzung mehrdeutiger Anfragen in kontrollierte Abrufstrategien

Dieser Beitrag ist ein technischer Einblick in die Elasticsearch-Implementierung der in Teil 3 beschriebenen Steuerungsebenenarchitektur und zeigt, wie sie mit dem Elasticsearch-Perkolator erstellt wird. Er skizziert die Muster, die zur Implementierung einer deterministischen, gesteuerten Richtlinien-Engine in der Produktion verwendet werden.

Von der Architektur bis zur Implementierung

Teil 3 beschrieb die Architektur der Steuerungsebene: Reverse Matching als Suchprimitiv, Richtliniendokumente, die Treffer von Aktion trennen, und kaskadierende Transformationen, die mehrere Richtlinien zu einem einzelnen Ausführungsplan zusammensetzen. Dieser Beitrag befasst sich praktisch mit der Elasticsearch-Funktion, die die Richtlinienabfrage ermöglicht: der Perkolator-Abfrage.

Der Perkolator eignet sich hervorragend für die Steuerung, da er die Suchrichtung genau so umkehrt, wie es eine Steuerungsebene benötigt. Dieser Beitrag führt Schritt für Schritt durch die Implementierung, beginnend mit einer klaren Erklärung, was der Perkolator tut und warum er wichtig ist, und dann weiter durch Indexdesign, Richtlinien-Speicher, Auswertung zur Abfragezeit und die Kombination mehrerer Richtlinien.

Wie normale Suche funktioniert

Ein E-Commerce-System kann Hunderttausende oder Millionen von Produktdokumenten enthalten, die Felder wie title, category und price umfassen. Wenn ein Nutzer nach passenden Dokumenten sucht, fordern Sie Elasticsearch auf, die Suchfolge des Nutzers mit einem oder mehreren gespeicherten Feldern in diesen Produktdokumenten zu vergleichen. Der Standardanalysator von Elasticsearch, der Standardanalysator, schreibt Text in Kleinbuchstaben und teilt ihn in Token auf. Eine Suche nach „orangen“ entspricht aufgrund der Kleinschreibung „Orangen“. Mit einem sprachbewussten Analysator, der Wortstämme einbezieht, wird auch „Orange“ gefunden, da beide Formen auf den gleichen Stamm zurückgehen. Beispielsweise liefert die folgende Suchabfrage Dokumente zurück, die im Feld “title” „Orange“ oder „Orangen“ enthalten.

Für die obige Abfrage gibt Elasticsearch die Produktdokumente an, deren Feld title mit „Orangen“ übereinstimmt. Dazu gehören beispielsweise Ergebnisse wie „Orangenaufstrich“, „Orangensaft“, „Saftige Orangen“, „Orangenmarmelade“ und so weiter. Wichtig ist, dass Elasticsearch üblicherweise dazu verwendet wird, eine Suchzeichenfolge mit Dokumenten zu vergleichen und die Dokumente anzugeben, die mit der Suchzeichenfolge übereinstimmen.

Das Governance-Problem: Relevante Richtlinien finden, bevor nach Produkten gesucht wird

Wie in Teil 1 bis 3 dargelegt, sendet ein gesteuertes Suchsystem die Suchzeichenfolge des Nutzers nicht direkt an den Produktkatalog. Zunächst wird geprüft, ob Richtlinien für diese Suchzeichenfolge gelten.

Ein Händler hat entschieden, dass, wenn jemand exakt nach „Orangen“ sucht, die Ergebnisse auf die Kategorie „Orangen“ beschränkt werden sollen und Orangensaft, Orangenmarmelade und Orangenlimonade ausgeschlossen werden. Diese Geschäftsentscheidung wird als Richtlinie gespeichert. Wenn ein Nutzer „Orangen“ eingibt, muss die Steuerungsebene diese Richtlinie finden, ihre Anweisungen lesen und die Suche im Produktkatalog entsprechend modifizieren. Um dies zu erreichen, muss die Steuerungsebene herausfinden, welche gespeicherten Richtlinien für diese Suchzeichenfolge relevant sind.

Ein Unternehmenssystem kann Hunderte oder Tausende solcher Richtlinien umfassen. Deren Einzelüberprüfung per Wenn/Sonst-Logik ist das Antimuster auf Anwendungsebene, das in Teil 2 beschrieben wird. Was wir brauchen, ist eine Möglichkeit, all diese Richtlinien in einem Index zu speichern und sofort diejenigen zu finden, die zu einer bestimmten Suchzeichenfolge passen. Hier kommt der Perkolator ins Spiel.

Umkehr der Richtung: Der Perkolator

Wir haben bereits erwähnt, dass Elasticsearch bei einer normalen Suche üblicherweise verwendet wird, um eine Suchzeichenfolge mit Dokumenten zu vergleichen und die Dokumente zurückzugeben, die diese Suchzeichenfolge enthalten.

Der Perkolator kehrt diesen Vorgang um. Mit einem Perkolator verfügt man über einen Index, in dem jedes Dokument ein Abfragemuster speichert. Eine eingehende Suchzeichenfolge wird mit diesen gespeicherten Abfragen abgeglichen, um zu bestimmen, welches dieser gespeicherten Abfragemuster ausgelöst wurde.

Für die Steuerung stellen die „gespeicherten Abfragemuster“ Richtlinien dar. Jede Richtlinie enthält ein Muster, das die Art der Suchzeichenfolge beschreibt, mit der sie übereinstimmen soll. Stimmt zum Beispiel die Suchzeichenfolge genau mit „Orangen“ überein oder enthält sie „Olivenöl“? Die eingehende Zeichenfolge ist der Suchtext des Nutzers, der zum Abfragezeitpunkt eintrifft und mit allen gespeicherten Richtlinienmustern abgeglichen werden muss. Dies wird in einem zugehörigen PRISM-Video bei Minute 4:09 behandelt.

Schritt für Schritt: Wie eine Suche nach „Orangen“ ihre Richtlinie findet

Die Richtlinie

Ein Händler hat eine Richtlinie erstellt, die zutrifft, wenn ein Nutzer exakt nach „Orangen“ sucht, ohne weitere Wörter anzugeben. Sobald der Perkolator übereinstimmt, enthält der Rest des Dokuments die Regeln, die die Steuerungsebene zum Erstellen der Produktabfrage verwendet; in diesem Beispiel besteht eine der Regeln darin, die Ergebnisse auf die Kategorie „Früchte“ zu beschränken (zu filtern).

Das percolator -Feld enthält das Muster, das definiert, wann diese Richtlinie ausgelöst werden soll. In diesem Fall entspricht sie dem Ausdruck "START oranges END". Die Felder rule_type und rule_args definieren, was die Richtlinie tun soll, wenn sie ausgelöst wird. Die Token START und END sind Grenzmarkierungen, die wir im Weiteren erläutern werden.

Sie können sehen, wie eine Richtlinie in der PRISM Studio-Benutzeroberfläche bei 2:52 des zugehörigen PRISM-Videos erstellt wird.

Der Nutzer sucht

Ein Käufer gibt „Orangen“ in die Suchleiste ein.

Die Steuerungsebene prüft auf übereinstimmende Richtlinien

Bevor der Produktkatalog durchsucht wird, fängt die Kontrollebene die Suchzeichenfolge des Nutzers ab, umschließt sie mit Begrenzungsmarkierungen und sendet sie an den Perkolator:

Die Zeichenfolge "START oranges END" wird gegen alle gespeicherten Richtlinienmuster überprüft. Intern führt Elasticsearch die gespeicherten Richtlinienmuster gegen diese Zeichenfolge aus und gibt die übereinstimmenden wieder. Das ist der Perkolator. Die Suchzeichenfolge des Nutzers wurde mit allen gespeicherten Richtlinienmustern abgeglichen, und die übereinstimmenden Muster wurden angezeigt. Keine Wenn/Sonst-Ketten. Keine sequentielle Auswertung. Der Index übernimmt den Abgleich.

Die Steuerungsebene wendet die Richtlinie an

Die Steuerungsebene liest die Aktionen der zugeordneten Richtlinien. Die obige Richtlinie weist die Steuerungsebene an, die Ergebnisse auf die Kategorie „Früchte“ zu beschränken. Die Steuerungsebene erstellt die endgültige Elasticsearch-Abfrage für den Produktkatalog wie folgt:

Der Nutzer suchte nach „Orangen“. Der Produktkatalog erhält eine Anfrage nach „Orangen“, die auf die Kategorie „Früchte“ beschränkt ist. Aufgrund dieser Einschränkung sind Orangensaft, Orangenmarmelade und Orangenlimonade ausgeschlossen.

Warum „Orangenmarmelade“ nicht unter die Richtlinie „Orangen“ fällt

Angenommen, ein anderer Nutzer sucht nach „Orangenmarmelade“. Die Steuerungsebene umschließt die Zeichenfolge und perkoliert: "START orange marmalade END". Das Muster der „Orangen“-Richtlinie ist match_phrase: "START oranges END". Die Richtlinie für Orangen passt nicht. Daher wird sie nicht angewendet und die Ergebnisse sind nicht auf die Kategorie „Früchte“ beschränkt.

Das ist der Zweck der Grenzmarkierungen START und END. Ohne sie könnte eine Richtlinie, die auf das Wort „Orangen“ abzielt, versehentlich bei einer Anfrage wie „Orangenmarmelade“ auslösen. Indem wir die Suchzeichenfolge des Nutzers mit START und END umschließen und diese Markierungen in das Muster der Richtlinie aufnehmen, stellen wir sicher, dass die Richtlinie nur dann ausgelöst wird, wenn die vollständige Suchzeichenfolge „Orangen“ lautet und keine weiteren Wörter enthält. Dies entspricht sowohl den Wünschen der Käufer als auch den Absichten des Händlers.

Eine zweite Richtlinie: „Olivenöl“ in einem Wortstammfeld

Nicht jede Richtlinie benötigt eine exakte Zeichenfolgenübereinstimmung. Die „Olivenöl“-Richtlinie findet Übereinstimmungen in einem Wortstammfeld, daher greift sie unabhängig von geringfügigen Wortformvariationen:

Das Muster dieser Richtlinie entspricht query.stemmed statt query. Wenn die Suchzeichenfolge des Nutzers eintrifft, wird sie sowohl in einem query -Feld (der exakte Text) als auch in einem query.stemmed -Feld gespeichert (analysiert mit einem Wortstamm-Analysator, der Wörter auf ihren Stamm reduziert, sodass „Oliven“ und „Olive“ beide auf denselben Stamm reduziert werden, ebenso wie „Öle“ und „Öl“). Das Muster der Richtlinie wird mit der Wortstammversion der Zeichenfolge überprüft und die Richtlinie damit unabhängig von geringfügigen Wortformvariationen ausgelöst.

Die START - und END -Grenzmarkierungen funktionieren auch im Wortstammfeld und stellen sicher, dass diese Richtlinie nur ausgelöst wird, wenn „Olivenöl“ die gesamte Suchzeichenfolge ist und nicht, wenn sie als Teil von etwas Längerem auftritt.

Der übrige Beitrag behandelt die Implementierungsdetails, die dies produktionsbereit machen: das Index-Mapping, das beide Abgleichmodi unterstützt, die Steuerung der Phrasenentfernung und Verfolgung bereits verarbeiteter Phrasen durch Hervorhebungen und die Kombination mehrerer widersprüchlicher Richtlinien zu einem einzigen Ausführungsplan.

Das Richtlinien-Index-Mapping

Der Richtlinienindex benötigt ein Perkolator-Feld zur Speicherung von Abfragemustern und ein Textfeld, das die Struktur der eingehenden Suchzeichenfolge widerspiegelt, mit der der Perkolator abgleicht. Das untenstehende Mapping ist aus Gründen der Übersichtlichkeit vereinfacht. Ein Produktions-Deployment ist komplexer und verwendet benutzerdefinierte Analysetools zur Handhabung von Grenzmarkierungen, den Abgleich von Variablenmustern (z. B. zur Erkennung, dass „unter 4 $“ einen Währungswert enthält) und andere Arten von Analysen.

Der Index wird policies genannt, weil jedes Dokument eine vollständige verwaltete Richtlinie darstellt, wie sie in Teil 2 definiert ist. Dazu gehören Übereinstimmungskriterien, Aktion, Priorität und Metadaten. Die Felder rule_type und rule_args enthalten die Aktionskomponente der Richtlinie, die die Anweisungen enthält, die die Steuerungsebene verwendet, um die Abfrage für die Ausführung im Produktkatalog zu erstellen.

Das query -Feld ist die Zeichenfolge, gegen die der Perkolator abgeglichen wird. Es gibt zwei Varianten: eine exakte Version und eine Wortstammversion. Wenn die Suchzeichenfolge des Nutzers eintrifft, wird sie in dieses Feld im temporären Speicherindex eingefügt. Richtlinien, die mit query übereinstimmen, sehen die exakte Zeichenfolge; Richtlinien, die mit query.stemmed übereinstimmen, sehen die Wortstammversion.

Perkolieren mit Hervorhebungen, Filtern und Sortierungen

Die oben genannten, einfachen Beispiele zeigten minimale Perkolationsanfragen. In der Praxis fügt die Steuerungsebene Hervorhebungen hinzu, filtert deaktivierte Richtlinien und sortiert nach Priorität:

Die Konfiguration mit Hervorhebung verwendet "query" als Feldschlüssel mit "query.stemmed" in matched_fields. Dies weist den einheitlichen Highlighter von Elasticsearch an, Hervorhebungen für das übergeordnete Feld query wiederzugeben, aber auch Übereinstimmungen aus dem Unterfeld query.stemmed zu berücksichtigen, wenn er bestimmt, welche Token hervorgehoben werden sollen. Auf diese Weise kann eine Richtlinie, die auf das Wortstammfeld zutrifft, trotzdem noch genaue Hervorhebungen im Originaltext erzeugen, die die Steuerungsebene für die Entfernung von Phrasen und die Nachverfolgung bereits verarbeiteter Phrasen benötigt.

Der enabled: true -Filter stellt sicher, dass deaktivierte Richtlinien übersprungen werden. sort bei der Priorität stellt sicher, dass Richtlinien mit höherer Priorität zuerst beachtet werden, sodass die Steuerungsebene sie in der richtigen Reihenfolge für kaskadierende Transformationen verarbeiten kann. Das Feld highlight ist die wichtigste Ergänzung; es sagt uns genau, welche Wörter in der Suchzeichenfolge des Benutzers die einzelnen Treffer ausgelöst haben.

Die Antwort auf eine Suchanfrage nach „Olivenöl“ könnte wie folgt aussehen:

Warum Hervorhebungen wichtig sind

Beachten Sie die Hervorhebung in der Antwort: "<em>START olive oil END</em>". Elasticsearch teilt uns genau mit, welche Wörter in der Suchzeichenfolge des Nutzers zu einer Übereinstimmung mit der Richtlinie geführt haben. Das ist nicht nur Kosmetik. Die Metadaten zur Hervorhebung steuern zwei entscheidende nachgelagerte Verhaltensweisen:

Phrasenentfernung. Einige Richtlinien müssen den übereinstimmenden Text aus der Suchzeichenfolge entfernen, bevor die Produktkatalogabfrage erstellt wird. Eine Richtlinie, die beispielsweise auf das Wort „billig“ abzielt, entfernt dieses Wort und wandelt es stattdessen in einen Preisfilter um. Die Hervorhebung gibt genau an, welcher Teil der Suchzeichenfolge mit der Richtlinie übereinstimmt, so dass das System weiß, was zu entfernen ist.

Verfolgung bereits verarbeiteter Phrasen. Wie in Teil 3 beschrieben, kann eine Richtlinie mit höherer Priorität Wörter entfernen, die auch von einer Richtlinie mit niedrigerer Priorität als übereinstimmend erkannt wurden, wenn mehrere Richtlinien mit derselben Suchzeichenfolge übereinstimmen. Durch den Vergleich der Hervorhebungen jeder Richtlinie mit der aktuellen (sich entwickelnden) Suchzeichenfolge kann das System erkennen, dass eine Phrase bereits verwendet wurde, und die Richtlinie mit der niedrigeren Priorität überspringen. Dies verhindert Doppelverarbeitung und gewährleistet deterministisches Verhalten.

Sie können mehr darüber erfahren, wie das Hervorheben funktioniert, in diesem Artikel.

Von der Perkolation zum Ausführungsplan

Der Perkolator gibt eine Reihe passender Richtlinien zurück. Aber wie schon in Teil 3 beschrieben: Die Suche ist nur die halbe Miete. Die andere Hälfte besteht darin, diese Übereinstimmungen zu einem kohärenten Ausführungsplan zusammenzusetzen. Und so sieht das für eine konkrete Abfrage aus.

Beispiel: „Billige Schokolade“ während einer Weihnachtskampagne

Angenommen, das System hat zwei aktive Richtlinien: die Richtlinie „Billige Schokolade“ (Priorität 210) und die Richtlinie „Weihnachtsschokolade“ (Priorität 300), die beide in Teil 3 ausführlich beschrieben wurden.

Schritt 1: Perkolieren. Der Nutzer sucht nach „billiger Schokolade“. Die Steuerungsebene umschließt die Suchzeichenfolge "START cheap chocolate END" und sendet sie an den Perkolator. Zwei Richtlinien stimmen überein: Das Muster der Richtlinie „Billige Schokolade“ entspricht der Phrase „billige Schokolade“; und das Muster der Richtlinie „Weihnachtsschokolade“ entspricht über das Wortstammfeld der Phrase „Schokolade“.

Schritt 2: Nach Priorität sortieren. Der Perkolator gibt beide Richtlinien wieder, sortiert nach Priorität in absteigender Reihenfolge. Zuerst wird die Richtlinie „Weihnachtsschokolade“ (300) bearbeitet, danach die Richtlinie „Billige Schokolade“ (210).

Schritt 3: Anwenden der kaskadierenden Transformation. Dies ist das Modell initial state → [Policy A] → state' → [Policy B] → state'' → execution plan aus Teil 3.

Die Richtlinie „Weihnachtsschokolade“ (Priorität 300) gilt zuerst:

• Fügt einen strengen Kategorienfilter hinzu: „Weihnachtsspeisen und -getränke“, „Weihnachtssüßigkeiten“.
• Fügt einen Preisfilter hinzu: weniger als 7 $.
• Fügt der Kategorie einen Soft-Boost hinzu: „Adventskalender“ (3x).

Die Richtlinie „Billige Schokolade“ (Priorität 210) gilt als Nächstes für den geänderten Zustand:

• Versuche, einen strengen Kategoriefilter hinzuzufügen: „Schokolade“, „Milchschokolade“; aber die Weihnachtsrichtlinie hat dieses Feld bereits mit on_conflict: override festgelegt, daher werden die „Billige Schokolade“-Kategorien verworfen.
• Versuche, einen Preisfilter hinzuzufügen: 2 $, die Weihnachtsrichtlinie legt on_conflict: restrict für den Preis fest, und 2 $ ist restriktiver als 7 $, daher gewinnt 2 $.
• Entfernt das Wort „billig“ aus der Suchzeichenfolge.

Schritt 4: Erstellen der Elasticsearch-Abfrage. Die Steuerungsebene fügt den Ausführungsplan zu einer einzigen Elasticsearch-Abfrage des Produktkatalogs zusammen:

Der ursprüngliche Suchbegriff lautete „billige Schokolade“. Die Abfrage, die den Produktkatalog erreicht, ist ein kontrollierter, zielorientierter Abrufplan: Das Wort „billig“ wurde verarbeitet und in eine Preisbeschränkung umgewandelt, die Ergebnisse sind auf saisonale weihnachtliche Kategorien beschränkt, Adventskalender-Produkte werden im Rang heraufgesetzt und die Preisobergrenze spiegelt den restriktiveren Wert der Richtlinie mit niedrigerer Priorität wider. Jede Transformation ist deterministisch, nachverfolgbar und erklärbar.

Einen kurzen Überblick darüber, wie diese Multiplikatoren mit dem Basis-BM25-Score interagieren, finden Sie ab Minute 8:45 im zugehörigen PRISM-Video wo wir kurz die multiplikativen Boosts erläutern.

Warum das skaliert

Der Perkolator ist in diesem Anwendungsfall effizient, weil er asymmetrisch ist: Ein Unternehmens-E-Commerce-System kann Millionen von Produkten enthalten, aber nur Hunderte oder Tausende an Steuerungsrichtlinien. Der Perkolator vergleicht eine eingehende Suchzeichenfolge mit diesen gespeicherten Richtlinienmustern und durchsucht nicht den gesamten Produktkatalog. Die Kosten verhalten sich proportional zur Anzahl der Richtlinien, und Elasticsearch wendet interne Optimierungen an (Indexieren von Begriffen aus gespeicherten Abfragemustern, Kurzschluss von Boolescher Logik), um eine schnelle Übereinstimmung zu gewährleisten.

Das Hinzufügen einer neuen Richtlinie bedeutet lediglich das Indexieren eines neuen Dokuments. Das Deaktivieren eines Feldes ist eine Feldaktualisierung. Keine Codeänderungen, keine Deployments, keine Neustarts.

Von der Suche zur gesteuerten Abfrage

Der Perkolator liefert das schnelle Rückwärtsabgleich-Primitiv, das die Architektur der Steuerungsebene aus Teil 3 im großen Maßstab in die Praxis umsetzt. Richtlinien sind Daten, die gespeichert und indexiert und dann effizient mit eingehenden Suchzeichenfolgen abgeglichen werden. Die Steuerungsebene fügt übereinstimmende Richtlinien durch die in Teil 3 beschriebene kaskadierende Transformation und Konfliktlösung pro Feld zu einem geregelten Ausführungsplan zusammen. Und die Abruf-Engine führt den festgelegten Ausführungsplan für den Produktkatalog aus.

Das Ergebnis ist ein System, bei dem ein Händler eine neue Richtlinie erstellen kann, ohne den Anwendungscode anzurühren, sie anhand repräsentativer Abfragen testen, in die Produktion übernehmen und sofort ihre Wirkung sehen kann. Der Perkolator beschleunigt die Richtliniensuche, die Steuerungsebene sorgt für eine deterministische Richtlinienkomposition, und der geregelte Workflow gewährleistet die Sicherheit des gesamten Prozesses.

Wie geht es weiter in dieser Serie?

Der nächste Beitrag in dieser Serie erweitert die kontrollierte Steuerungsebene um ein neues Gebiet. Er führt eine mehrstufige Sucharchitektur ein, die erklärt, wie man strenge, lockere und semantische Abrufe orchestrieren kann, während stabile Paginierung und Facetten erhalten bleiben.

Setzen Sie die reglementierte E-Commerce-Suche in die Praxis um

Die in diesem Beitrag beschriebene, auf dem Perkolator basierende Steuerungsebene – von Index-Mappings und Grenzmarkierungen bis hin zur durch Hervorhebungen gesteuerten Phrasenverfolgung und kaskadierender Richtlinienkomposition – wurde von Elastic Services Engineering als Teil unserer wiederholbaren E-Commerce-Suchbeschleuniger entwickelt. Jedes hier gezeigte Abfragebeispiel und jede Richtlinienstruktur stammt aus einem funktionierenden System, das gegen Unternehmensproduktkataloge validiert ist.

Wenn Sie eine kontrollierte, richtlinienbasierte Steuerungsebene auf Elasticsearch implementieren möchten, kommen Sie mit Elastic Services vielleicht schneller zum Ziel. Wenden Sie sich an Elastic Professional Services.

Nehmen Sie an der Diskussion teil

Haben Sie Fragen zur Suchsteuerung, zu Abrufstrategien oder zur Sucharchitektur im E-Commerce? Nehmen Sie an der Diskussion der Elastic-Community teil.