Dieser letzte Beitrag fragt: Was ändert sich, wenn die Eingabe stattdessen von einem KI-Agenten kommt?

Die Antwort ist, dass sich die Architektur nicht ändert, aber die Einsätze schon. Jede Eigenschaft der beherrschten Kontrollebene, die für von Menschen verfasste Abfragen von Bedeutung ist, ist umso wichtiger, wenn der vorgelagerte Entscheidungsträger ein großes Sprachmodell (LLM) ist. Determinismus, Überprüfbarkeit, Konfliktlösung und Zwangsdurchsetzung werden zu kritischen Leitplanken anstatt zu betrieblichen Annehmlichkeiten, da das System, das die Eingabe produziert, von Natur aus probabilistisch ist.

Das agentische Suchproblem

Der gängigste Ansatz für KI-gesteuerte Suche ist unkompliziert: Man gibt dem LLM das Datenbankschema, stellt Geschäftsregeln in der Eingabeaufforderung bereit und lässt den Agenten die Abfrage direkt generieren.

Für einen E-Commerce-Chatbot bedeutet dies, die Elasticsearch-Index-Mapping, Feldtypen, Kategorietaxonomien, Preislogik und Geschäftsbeschränkungen in das Kontextfenster des Agenten zu injizieren und dann das LLM zu bitten, natürliche Sprache in gültige Elasticsearch Query DSL zu übersetzen. Das LLM wird zum Abfrageautor.

Dieser Ansatz funktioniert in Demos. Es scheitert aus vier Gründen in der Produktion.

Kontextaufblähung

Ein Enterprise-E-Commerce-Index-Mapping ist kein triviales Dokument. Felddefinitionen, verschachtelte Objekte, Mehrfeldkonfigurationen und Analysatoreinstellungen können auf Tausende von Token ausgeführt werden, bevor Geschäftslogik hinzugefügt wird. Zusätzlich zum Mapping benötigt der Agent Kategorientaxonomien (die im Enterprise-E-Commerce Zehntausende von Werten enthalten können), Preisregeln, Markenhierarchien, Zulassungsbeschränkungen und Kampagnenlogik.

Das Ergebnis ist ein Kontextfenster, das von strukturellen Metadaten dominiert wird, anstatt von der eigentlichen Absicht des Nutzers. Dies erhöht die Latenzzeit, steigert die Token-Kosten und verschlechtert die Fähigkeit des LLM, Anweisungen zu befolgen, wenn der Kontext wächst. Dies ist ein gut dokumentiertes Phänomen, das manchmal als Kontextverfall bezeichnet wird: Je länger der Prompt wird, desto schwächer wird die Aufmerksamkeit des Modells für eine bestimmte Anweisung.

Probabilistische Halluzination

LLMs generieren Abfragen basierend auf Mustern in ihren Trainingsdaten und dem bereitgestellten Kontext. Wenn das Modell aufgefordert wird, Elasticsearch Query DSL zu generieren, kann es Feldnamen erzeugen, die nicht existieren, syntaktisch ungültige Abfrageklauseln erstellen, Filtertypen auf die falschen Feldtypen anwenden oder Abfragen erzeugen, die zwar syntaktisch gültig, aber semantisch falsch sind und Ergebnisse liefern, die nicht der Absicht des Nutzers entsprechen.

Der BIRD-Benchmark für Text-to-SQL von Google Cloud veranschaulicht die Grenzen dieses Ansatzes. Googles hochmodernes Single-Model-Ergebnis erreichte eine Genauigkeit zwischen 70 % und 80 %, was bedeutet, dass fast jede vierte generierte Abfrage falsch war. Dies gilt für SQL, das weitaus stärker standardisiert ist als die Elasticsearch Query DSL. Die Fehlerquote für LLM-generierte Elasticsearch-Abfragen in einer echten Produktionsumgebung mit komplexen Mappings und geschäftsspezifischer Semantik wäre wahrscheinlich höher.

Bei einem umsatzkritischen E-Commerce-System ist eine Fehlerrate von einem Viertel der Abfragen kein Optimierungsproblem, das iterativ gelöst werden kann. Es ist eine architektonische Einschränkung des Ansatzes.

Die Sicherheitslücke

Wenn das LLM Zugriff auf das Datenbankschema hat und als Abfrageautor fungiert, ist das System anfällig für indirekte Prompt-Injektion. Ein Nutzer, der mit einem E-Commerce-Chatbot interagiert, kann Eingaben erstellen, um den Agenten so zu manipulieren, dass er unbeabsichtigte Abfragen generiert.

Dies ist kein theoretisches Risiko. Prompt-Injektion ist eine der am aktivsten erforschten Angriffsflächen in eingesetzten LLM-Systemen. Das grundlegende Problem ist, dass es beim Erstellen der Abfrage durch den Agent keine strukturelle Grenze zwischen Nutzerintention und Abfrageausführung gibt. Das LLM interpretiert gleichzeitig die Nutzerabfrage und erstellt die Datenbankoperation. Jede Manipulation der ersten wirkt sich direkt auf die zweite aus.

Fehler beim Skalieren mit hoher Kardinalität

Bestimmte E-Commerce-Felder haben extreme Kardinalität. Ein Produktkatalog kann 17.000 Kategoriewerte, Tausende von Markennamen und Hunderte von Attributkombinationen enthalten. Standardmäßige agentische Workflows erfordern, diese Werte in den Kontext einzufügen, damit das LLM beim Erstellen einer Abfrage den richtigen auswählen kann.

Dies führt zu einem unmöglichen Kompromiss: Entweder werden alle möglichen Werte eingefügt (was enorm viel Kontext verbraucht und die Leistung mindert), es wird nur eine Teilmenge eingefügt (und man muss in Kauf nehmen, dass der Agent nicht auf Werte außerhalb dieser Teilmenge zugreifen kann), oder es wird auf eine unkontrollierte Suche zurückgegriffen. Dies knüpft direkt an das Kernproblem aus Teil 1 an: Wenn das LLM nach „Orangen“ sucht und Elasticsearch Orangenlimonade zurückgibt, verschlechtert sich das Chat-Erlebnis auf die gleiche Weise wie das Sucherlebnis. Das Fehlen von Governance bedeutet, dass das System die beabsichtigte Lösung des Käufers nicht durchsetzen kann.

Das dynamische Abrufen relevanter Werte auf der Grundlage der Abfrage ist eine bekannte Alternative, die jedoch einen zusätzlichen, nicht-deterministischen Schritt einführt, bei dem die Abfrage selbst relevante Werte verfehlen kann. Zusätzlich erhöht dies die Latenz und Komplexität jeder Abfrage.

Die architektonische Alternative: Entkopplung von Absicht und Ausführung

Die in den Teilen 1 bis 7 beschriebene gesteuerte Kontrollebene bietet einen grundlegend anderen Ansatz. Anstatt dass das LLM die endgültige Abfrage erstellt, wird die Rolle des LLM auf eine einzige, klar abgegrenzte Aufgabe reduziert: das Extrahieren einer Suchabsichts-Zeichenfolge aus der natürlichen Spracheingabe des Nutzers.

Der Nutzer sagt: „Ich suche günstige braune Schuhe.“ Die Aufgabe des Agenten besteht nicht darin, eine Elasticsearch-Abfrage zu generieren. Er soll die Suchabsicht (in diesem Fall etwa „billige braune Schuhe“) extrahieren und an die Steuerungsebene weiterleiten. Die Steuerebene tut dann das, was sie immer getan hat: Sie perkoliert die Absichtszeichenkette gegen gespeicherte Richtlinien, erstellt passende Richtlinien durch kaskadierende Transformationen, löst Konflikte deterministisch und erzeugt eine gesteuerte Elasticsearch-Abfrage.

Das LLM sieht das Index-Mapping nie. Es weiß nie etwas über Feldtypen, Kategorientaxonomien oder Preisschwellenwerte. Es konstruiert niemals eine Abfrageklausel. Es läuft auf der natürlichen Sprachseite einer architektonischen Grenze, die wir als Metadaten-Luftlücke bezeichnen, eine strikte Trennung zwischen der probabilistischen Komponente (dem LLM) und der strukturierten Datenschicht (Schema, Richtlinien und Abfragekonstruktion).

Was der Metadaten-Air-Gap bietet

• Schemablindheit. Das LLM hat keinen Zugriff auf das Datenbankschema und kann daher weder ungültige Abfragen generieren, Feldnamen erfinden noch so manipuliert werden, dass strukturelle Informationen offengelegt werden. Das Schema existiert nur auf der deterministischen Seite der Luftlücke.

• Minimaler Kontext. Anstatt Tausender Token von Mapping-Daten, Geschäftsregeln und Kategorie-Taxonomien enthält der Prompt des LLM nur eine Persona und Anweisungen zur Intent-Extraktion. Dadurch werden die Token-Kosten, die Latenzzeit und der Kontextwechsel drastisch reduziert.

• Deterministische Ausführung. Jede Abfrage, die Elasticsearch erreicht, wird von der Kontrollebene mit menschengeprüften Vorgabenvorlagen erstellt und nicht probabilistisch von einem LLM generiert. Syntaktische Gültigkeit ist garantiert. Die semantische Korrektheit wird durch dasselbe Vorgaben-Framework sichergestellt, das in den Teilen 1 bis 6 beschrieben wurde.

• Sicherheit durch Architektur. Prompt-Injektion wird strukturell unwirksam. Selbst wenn ein Nutzer den Agenten dazu manipuliert, eine ungewöhnliche Intent-Zeichenfolge zu erzeugen, wird diese Zeichenfolge gegen gespeicherte Richtlinien perkoliert. Wenn keine Vorgabe übereinstimmt, wird keine Abfrage generiert. Der Nutzer kann den Agenten nicht anweisen, eine Abfrage zu erstellen, da der Agent keine Abfragen erstellt. Die Steuerungsebene tut dies, und die Steuerungsebene ist deterministisch.

Wie die einzelnen Teile zusammenpassen

Die folgende exemplarische Vorgehensweise zeigt, wie die kontrollierte Steuerungsebene eine agentenvermittelte Abfrage handhabt.

Schritt 1: Der Nutzer spricht mit dem Agenten

Ein Kunde, der mit einem E-Commerce-Chatbot interagiert, sagt: „Ich suche günstige Schokolade, aber ohne Erdnüsse.“

Schritt 2: Der Agent extrahiert die Absicht

Die Rolle des LLM besteht in der Absichtsextraktion, nicht in der Abfragegenerierung. Auf Basis eines minimalen Prompts, der den Agenten anweist, die Produktabsicht zu ermitteln, erzeugt er eine Suchabfrage: „billige Schokolade ohne Erdnüsse“.

Dies ist eine einfache Klassifizierungsaufgabe. Das LLM braucht nicht das Index-Mapping, die Kategorie-Taxonomie oder die Preisregeln, um es auszuführen. Es muss die natürliche Sprache verstehen, und genau darin sind LLMs gut.

Schritt 3: Die Kontrollebene steuert die Abfrage

Die Absichtszeichenfolge „billige Schokolade ohne Erdnüsse“ wird an die Steuerungsebene weitergeleitet, die sie mit dem Vorgaben-Index perkolieren. Drei Vorgaben stimmen überein:

• Die Vorgabe „billig“ (extrahiert „billig“ und wendet einen Preisfilter basierend auf der Produktkategorie an).

• Die Vorgabe „Schokolade“ (beschränkt die Ergebnisse auf Schokoladenkategorien).

• Die Vorgabe „ohne“ (Negation; extrahiert das Ausschlussziel und wendet einen must_not-Filter an)

Die Steuerungsebene wendet diese Vorgaben durch dieselbe kaskadierende Transformation an, die in Teil 3 und Teil 4 beschrieben ist: Prioritätsreihenfolge, Konfliktlösung pro Feld, Verfolgung verbrauchter Phrasen. Wenn auch eine „Weihnachtskampagne“-Vorgabe aktiv ist, setzt sie sich mit den Produktvorgaben genau so zusammen, wie in Teil 3 beschrieben. Die Beteiligung des Agenten ändert das Governance-Modell überhaupt nicht.

Schritt 4: Die gesteuerte Abfrage wird ausgeführt

Die Steuerungsebene erzeugt eine vollständig gesteuerte Elasticsearch-Abfrage: eine Suche nach „Schokolade“, beschränkt auf die entsprechenden Kategorien, mit einer Preisobergrenze, die sich aus der Vorgabe „billig“ ergibt, einem Ausschlussfilter für erdnusshaltige Produkte und der Anwendung etwaiger aktiver Kampagnen-Boosts. Wenn die Vorgabe „Schokolade“ auch wirtschaftliche Optimierungsgewichte (Teil 7) einschließt, werden diese ebenfalls angewendet. Der Margenaufschlag ist auf 3,0x gesetzt, da „Schokolade“ eine Browsing-Abfrage ist, bei der der Einzelhändler von der Förderung von Produkten mit höherer Marge profitiert. Wenn der Käufer eine Kaufhistorie (Teil 6) hat, werden Personalisierungssignale darüber geschichtet. Diese Abfrage ist syntaktisch gültig durch Konstruktion und semantisch korrekt durch Vorgabendesign.

Schritt 5: Rückgabe der Ergebnisse durch den Agenten

Die Produktergebnisse werden an den Agenten zurückgegeben, der sie dem Nutzer im Dialog präsentiert. Die Rolle des Agenten auf dem Rückgabepfad ist die Präsentation: Formatierung der Ergebnisse, Beantwortung von Folgefragen, Bereitstellung von Produktdetails. Der Abruf selbst war geregelt, deterministisch und erklärbar.

Wozu der Agent gut ist (und wozu nicht)

Diese Architektur nutzt die Stärken des LLM und schützt das System vor seinen Schwächen.

LLMs sind hervorragend darin, die Absicht der natürlichen Sprache zu verstehen. „Ich suche nach billiger Schokolade, nichts mit Erdnüssen“ ist eine Aufgabe des natürlichen Sprachverständnisses, bei der die Absicht analysiert, Produktreferenzen identifiziert und Negation erkannt wird. LLMs handhaben dies zuverlässig, da es sich um ein Klassifizierungsproblem handelt, nicht um ein Generierungsproblem. Die Ausgabe ist eine kurze Absichtszeichenfolge, keine komplexe strukturierte Abfrage.

LLMs haben Schwierigkeiten, unter komplexen Rahmenbedingungen präzise strukturierten Ausgang zu erzielen. Die Erstellung gültiger Elasticsearch-Abfrage-DSL erfordert exakte Feldnamen, korrekte Klauselverschachtelung, geeignete Filtertypen für jedes Feld und eine konsistente Anwendung von Geschäftsregeln über Tausende von Randfällen. Dies sind genau die Eigenschaften, die ein deterministisches System trivialerweise erzwingt und die ein probabilistisches System unzuverlässig erzwingt.

Die gesteuerte Steuerungsebene platziert jede Komponente an ihrem Platz: das LLM auf der Seite der natürlichen Sprache, die deterministische Vorgaben-Engine auf der Seite der Abfragekonstruktion, und eine architektonische Grenze zwischen ihnen.

Die Governance begrenzt den Explosionsradius.

Dies ist derselbe Einblick aus Teil 3, erweitert auf den agentischen Kontext. In Teil 3 haben wir festgestellt, dass Governance die semantische Suche sicherer macht, indem sie die Kandidatenmenge vor Beginn der Suche eingrenzt. Eine semantische Suche über 500 Produkte in einer regulierten Kategorie ist eine ganz andere Sache als eine semantische Suche über 500.000 SKUs.

Das gleiche Prinzip gilt für agentenvermittelte Abfragen. Ohne entsprechende Steuerung könnte ein Agent, der „billige Schokolade“ falsch interpretiert, eine Abfrage generieren, die den gesamten Katalog ohne Preisbeschränkung, ohne Kategoriefilter und ohne Ausschlüsse durchsucht. Selbst wenn der Agent eine unvollständige Absichtszeichenfolge abgibt, schränkt die Kontrollebene die Abfrage auf die Richtlinien ein, die übereinstimmen. Im schlimmsten Fall werden weniger Richtlinien ausgelöst, nicht dass eine unbegrenzte Abfrage den Produktkatalog trifft.

Governance engt den Explosionsradius von probabilistischen Fehlern ein. Dies gilt unabhängig davon, ob es sich bei der probabilistischen Komponente um ein semantisches Retrieval-Modell oder einen LLM-Agenten handelt.

LLM-vorgeschlagene Richtlinien: Erweiterung der Abdeckung

In Teil 2 wurde die Idee eingeführt, dass ein LLM neue Richtlinien vorschlagen kann, die in dieselbe Author → Test → Promote-Pipeline aufgenommen werden wie von Menschen verfasste. Im Agentenkontext wird das zu einer starken Feedback-Schleife.

Ein LLM kann Abfrageprotokolle analysieren, Muster identifizieren, bei denen die Kontrollebene keine Matching-Vorgabe hat (Abfragen, die nicht zur unveränderten Abruf gelangen), und neue Vorgaben vorschlagen, um diese Lücken zu schließen. Ein Merchandiser prüft jeden Vorschlag, testet ihn und fördert ihn, wenn er das erwartete Verhalten hervorruft. Das Governance-Modell stellt sicher, dass keine von LLM vorgeschlagene Vorgabe ohne menschliche Validierung in die Produktion gelangt.

Im Laufe der Zeit entsteht dadurch ein positiver Kreislauf: Die Vorgabenabdeckung der Steuerungsebene erweitert sich, der Anteil der Abfragen, die eine unveränderte Abrufung erfordern, schrumpft, und das System wird zunehmend geregelt, wobei jede Vorgabe überprüfbar, versioniert und individuell umkehrbar ist.

Das breitere Muster: Deterministische Leitplanken für probabilistische Systeme

Die in dieser Serie beschriebene Architektur, eine deterministische Kontrollebene, die zwischen einer probabilistischen Eingangsquelle und einem Datenabrufsystem angesiedelt ist, ist nicht spezifisch für die E-Commerce-Suche. Das gleiche Muster gilt überall dort, wo ein KI-Agent mit strukturierten Daten interagieren muss.

Ein Agent, der eine SQL-Datenbank abfragt, steht vor denselben Herausforderungen: Kontextaufblähung durch Schema-Injektion, halluzinierte Spaltennamen, Risiken der Prompt-Injektion und Auswahl von Werten mit hoher Kardinalität. Ein Agent, der mit einem Ticketsystem wie Jira, einem Customer-Relationship-Management-System (CRM) wie Salesforce oder einem Code-Repository wie GitHub interagiert, steht vor ähnlichen Problemen. In jedem Fall ist die Kernarchitekturfrage dieselbe: Sollte das LLM die Abfrage erstellen, oder sollte das LLM die Absicht extrahieren und an eine deterministische Schicht weitergeben, die die Abfrage erstellt?

Die geregelte Kontrollebene bietet eine wiederholbare Antwort auf diese Frage. Richtlinien sind Daten. Die Extraktion von Absichten ist die Aufgabe des LLM. Die Abfragekonstruktion ist die Aufgabe der Steuerungsebene. Die Metadaten-Luftlücke hält sie getrennt. Und das Governance-Framework (Priorisierungsreihenfolge, Konfliktlösung, kaskadierende Transformationen, Überprüfbarkeit) stellt sicher, dass die deterministische Schicht bei wachsender Anzahl von Richtlinien operationell handhabbar bleibt.

Fazit

Die in dieser Reihe beschriebenen E-Commerce-Suchsteuerungsmuster (Richtlinien als Daten, Autor → Test → Workflow-Förderung, kaskadierende Transformationen, Konfliktlösung pro Feld, Percolator-basiertes Reverse Matching und mehrstufiges Fallback) wurden für eine Welt entwickelt, in der ein Händler Richtlinien erstellt und ein Käufer Abfragen eingibt. Aber die Architektur kann viel mehr ermöglichen als ihr ursprünglicher Anwendungsfall.

Wenn die Eingabequelle ein KI-Agent anstelle eines menschlichen Käufers ist, wird die gesteuerte Kontrollebene zur kritischen Sicherheitsschicht zwischen einem probabilistischen System und einem Produktionsdatenspeicher. Es bietet die deterministischen Garantien (syntaktische Gültigkeit, semantische Korrektheit, Überprüfbarkeit und Sicherheit), die Unternehmenssysteme benötigen und die LLMs allein nicht bieten können.

Die deterministische Steuerungsebene ersetzt den KI-Agenten nicht. Dadurch kann der KI-Agent sicher eingesetzt werden.

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

Die in dieser Serie beschriebene Architektur der Steuerebene, vom Paradigma der Vorgaben als Daten über die perkolatorbasierte Suche bis hin zu Personalisierung, wirtschaftlicher Optimierung und dem agentenbasierten Luftraum, wurde von Elastic Services Engineering entwickelt und gebaut. Jedes in dieser Serie beschriebene Muster stammt aus einem funktionierenden System, das anhand von Produktkatalogen auf Unternehmensebene erstellt und validiert wurde.

Wenn Ihr Team KI-gestützte Sucherlebnisse entwickelt und deterministische Leitplanken für agentenvermittelte Abfragen benötigt, oder wenn Sie eine kontrollierte, vom Unternehmen editierbare Sucharchitektur auf Elasticsearch implementieren möchten, können die Elastic Professional Services Ihre Implementierung beschleunigen. 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.

Dieser Beitrag stellt zwei Personalisierungsmechanismen vor, die die gesteuerte Steuerungsebene erweitern, ohne deren Architektur zu verändern. Beide Mechanismen wirken multiplikativ mit der Governance-Ebene aus den Teilen 1 bis 5 zusammen: Richtlinien werden weiterhin angewendet, Einschränkungen werden weiterhin durchgesetzt, Konflikte werden weiterhin gelöst und Personalisierungssignale werden in dieselbe gesteuerte Abfrage integriert, wodurch sichergestellt wird, dass die von Elasticsearch zurückgegebenen Ergebnisse bereits personalisiert sind.

Der erste Mechanismus fördert Produkte, die der einzelne Käufer zuvor gekauft hat. Der zweite Mechanismus aktiviert kohortenspezifische Richtlinien, die auf dem Profil des Käufers basieren. Gemeinsam zeigen sie, dass Personalisierung kein separates System ist, das an die Suche angehängt oder als Nachbearbeitung der Suchergebnisse angewendet wird; sie ist vielmehr eine natürliche Erweiterung der richtlinienbasierten Steuerungsebene.

Einen detaillierten Einblick in die mathematischen Grundlagen der in diesem Beitrag verwendeten Personalisierungstechniken finden Sie unter Personalisierung der Suche in Elasticsearch ohne ML-Nachbearbeitung sowie unter Kohortenorientiertes Ranking in Elasticsearch.

Um in einer Live-Demonstration zu sehen, wie sich der Kaufverlauf nutzen lässt, um die Suchergebnisse für wiederkehrende Kunden zu verbessern, sehen Sie sich das Video an: Nachvollziehbare Personalisierung: Verbesserung der Suche anhand des Kaufverlaufs.

Optimierung des individuellen Kaufverlaufs

Die einfachste Form der Personalisierung ist auch eine der effektivsten: Wenn ein Käufer ein Produkt bereits gekauft hat, sollte es hervorgehoben werden, wenn er nach etwas Ähnlichem sucht. Ein Kunde, der regelmäßig eine bestimmte Marke von Schokoladenkeksen kauft, sollte diese Kekse bei der Suche nach „Keksen“ weiter oben in der Rangliste sehen, nicht, weil ein Modell eine Präferenz vorhergesagt hat, sondern weil es direkte Verhaltenshinweise dafür gibt.

So funktionierts

Wenn eine Suchanfrage eine Benutzerkennung enthält, wie es beispielsweise bei einem Nutzer mit einer offenen Sitzung der Fall wäre, führt die Steuerungsebene zwei Elasticsearch-Abfragen parallel mithilfe eines Thread-Pools aus:

1. Die Perkolator-Abfrage gegen den Richtlinienindex (die gleiche Governance-Abfrage, die in den Teilen 3 und 4 beschrieben wurde).

2. Eine Abfrage zum Kaufverlauf anhand eines user_purchases-Index, die nach term(user_id) auf den bestimmten Nutzer gefiltert wurde und dann die aktuelle Suchzeichenfolge mit den Produkttiteln dieses Nutzers abgleicht.

Diese Prozesse laufen parallel (keiner wartet auf den anderen), sodass die Personalisierungsabfrage keine nennenswerte Latenz in der Governance-Pipeline verursacht.

Die Kaufverlauf-Abfrage verwendet die Textanalyse von Elasticsearch (Stemming, Tokenisierung), um die aktuelle Suchzeichenfolge mit gespeicherten Produkttiteln abzugleichen. Das bedeutet, dass eine Suche nach „Cookies“ durch eine Standard-Textanalyse einen früheren Kauf von „Brownie-Cookies“ findet, ohne dass eine exakte Übereinstimmung der Zeichenketten erforderlich ist.

Berechnung von Boost-Gewichten

Nicht alle früheren Käufe verdienen die gleiche Aufwertung. Das Gewicht berücksichtigt zwei intuitive Faktoren: wie oft der Kunde das Produkt gekauft hat und wie aktuell es ist. Ein Produkt, das letzte Woche 15 Mal gekauft wurde, ist ein viel stärkeres Signal als ein Produkt, das vor sechs Monaten einmal gekauft wurde. Bei der Gewichtung wird die Häufigkeit logarithmisch skaliert (damit ein einzelner Artikel, der besonders häufig gekauft wurde, nicht alle anderen Artikel überlagert) und die Aktualität exponentiell abgewichtet (damit ältere Käufe mit der Zeit auf natürliche Weise an Bedeutung verlieren).

Die mathematischen Details zur Boost-Formel finden Sie unter Personalisierung der Suche in Elasticsearch ohne ML-Nachbearbeitung.

Wie es zu einer Abfrage wird

Die Kaufverlaufs-Boosts werden als oberste Bewertungsschicht in die Abfrage integriert und umfassen die Filter und Boosts der Governance-Richtlinien aus Teil 3 und 4 sowie alle Geschäftssignal-Boosts wie Marge und Beliebtheit (die wir in Teil 7 näher betrachten werden). Das bedeutet, dass ein Produkt, das aufgrund einer Governance-Richtlinie entfernt wurde, nicht aufgrund eines positiven Kaufverlaufs wieder angezeigt wird. Die Governance steuert den Ergebnissatz; die Personalisierung passt die Reihenfolge innerhalb dieses Satzes an. Produkte ohne Kaufverlauf werden nicht benachteiligt. Das durch die Governance festgelegte Ranking bleibt erhalten, allerdings werden Produkte mit relevantem Kaufverlauf – bei sonst gleichen Bedingungen – darüber platziert.

Warum Elasticsearch bei jeder Suche abfragen?

Der Kaufverlauf wird bei jeder Suche aus Elasticsearch abgefragt, anstatt in der Anwendungsebene zwischengespeichert zu werden. Dies ist eine bewusste Designentscheidung. Da die Abfrage die aktuelle Suchzeichenfolge mit den Produkttiteln mithilfe der Textanalyse-Pipeline von Elasticsearch abgleicht, profitiert das System von der gleichen Stemming-, Tokenisierungs- und Sprachverarbeitungsfunktion, die auch der Produktsuche selbst zugrunde liegt. Eine zwischengespeicherte In-Memory-Suche würde entweder eine erneute Implementierung dieser Analyse oder die Akzeptanz einer gröberen Übereinstimmung erfordern.

Um zu verstehen, warum diese Reihenfolge wichtig ist, betrachten wir einen Kunden, der zuvor Orangensaft gekauft hat und nun nach „Orangen“ sucht. Die Kaufverlauf-Abfrage gleicht „Orangensaft“ mit dem Suchbegriff „Orangen“ durch Textanalyse ab und berechnet einen Boost für dieses Produkt. Die Governance-Ebene hat jedoch bereits „Orangen“ auf die Kategorie „Obst und Gemüse“ beschränkt und Orangensaft vollständig herausgefiltert. Der Kaufverlauf-Boost für Orangensaft ist zwar in der Abfrage vorhanden, hat aber keine Auswirkung, da es im gesteuerten Ergebnissatz kein passendes Dokument gibt, auf das er angewendet werden könnte. Dem Kunden werden frische Orangen angezeigt, sortiert nach Relevanz und Personalisierung. Die Governance-Orientierungshilfen greifen.

Die Leistungskosten sind minimal: Der Kaufverlaufsindex ist klein (der Kaufverlauf eines Nutzers umfasst typischerweise Dutzende bis Hunderte von Dokumenten, nicht Millionen), und die Abfrage wird parallel zur Perkolator-Suche ausgeführt, sodass sie den kritischen Pfad nicht verlängert.

Beispielanfrage für „Quellwasser“ ohne Nutzerverlauf

Wenn ein nicht angemeldeter Nutzer oder ein Nutzer, der noch nie „Quellwasser“ gekauft hat, eine Suche durchführt, werden ihm möglicherweise Ergebnisse angezeigt, die in etwa wie folgt aussehen:

Beispielhafte Kaufhistorie eines Nutzers

Eine Nutzerin namens Carol hingegen hat einen Einkaufsverlauf, die folgende Produkte enthält:

Beispielsuche nach „Quellwasser“ mit dem obigen Kaufverlauf

Wenn Carol nach „Quellwasser“ sucht, werden ihr personalisierte Ergebnisse angezeigt, die ihre bisherigen Käufe widerspiegeln. Ein Blick auf den Kaufverlauf oben zeigt, dass sie das „kohlensäurehaltige Quellwasser“ (die grüne Flasche) etwa 40 Mal gekauft hat, zuletzt vor zwei Tagen. Wenn sie nach „Quellwasser“ sucht, wird dieses Produkt hervorgehoben, da wir wissen, dass sie es mag. Beachten Sie, dass in den nicht personalisierten Ergebnissen stattdessen das Rubicon-Quellwasser an erster Stelle stand.

Kohortenorientierte Richtlinienaktivierung

Der individuelle Kaufverlauf eignet sich gut für wiederkehrende Kunden mit etabliertem Verhalten. Viele Käufer sind jedoch Neukunden, anonym oder verhalten sich anders als sonst. Für diese Kunden bietet die Zugehörigkeit zu einer Kohorte eine andere Art der Personalisierung, die darauf basiert, wer der Kunde ist, und nicht darauf, wie er sich verhalten hat.

Ein veganer Kunde, der nach „Schokolade“ sucht, sollte vegane Schokolade weiter oben in den Suchergebnissen sehen. Ein Halal-bewusster Kunde, der nach „Snacks“ sucht, sollte Halal-zertifizierte Produkte gut sichtbar angezeigt bekommen. Ein gesundheitsbewusster Käufer, der nach „Joghurt“ sucht, sollte probiotische Optionen bevorzugt angezeigt bekommen.

Kohorten als Richtlinien, nicht als Produkt-Tags

Produkte verfügen bereits über ihre normalen Attribute, einschließlich Felder wie dietary_restrictions: ["vegan"] oder dietary_restrictions: ["halal"]. Die Frage ist, wo die Logik liegt, die die Kohorte eines Kunden mit diesen Produktattributen verbindet.

Der naive Ansatz wäre, diese Zuordnung in der Anwendungsebene oder in der Suchvorlage fest zu programmieren: Wenn der Nutzer Veganer ist, wird ein Boost für dietary_restrictions: "vegan" hinzugefügt. Aber es handelt sich hier um dasselbe „Spaghetti-Code“-Chaos auf Anwendungsebene, das in Teil 1 beschrieben wurde, und es verursacht dieselben operativen Reibungsverluste: Das Hinzufügen einer neuen Kohorte oder die Änderung der Definition einer Kohorte erfordert eine Codeänderung.

Die gesteuerte Steuerungsebene behält die Kohortenlogik stattdessen in der Richtlinien-Engine bei. Eine Kohortenrichtlinie verbindet zwei Aspekte miteinander: die Zugehörigkeit eines Kunden zu einer Kohorte (zum Beispiel „vegan“) und ein Produktmerkmal (zum Beispiel dietary_restrictions: “vegan”). Die Richtlinie legt Folgendes fest: Wenn ein Käufer aus der veganen Zielgruppe eine Suche durchführt, sollen Produkte bevorzugt angezeigt werden, bei denen dietary_restrictions den Begriff „vegan“ enthält.

Da die Kohortenlogik in der Richtlinien-Engine und nicht im Anwendungscode enthalten ist, bedeutet das Folgendes:

• Eine neue Kohorte kann durch die Erstellung einer neuen Richtlinie hinzugefügt werden; eine Produkt-Neuindizierung ist nicht erforderlich.

• Kohorten-Richtlinien verwenden die vollständige Regel-Engine: Sie können Filter hinzufügen, Soft-Boosts anwenden, Synonyme erweitern, Abrufstrategien ändern oder jede andere Aktion einer Richtlinie vornehmen.

• Das Kohortenverhalten wird über dieselbe Admin-Benutzeroberfläche verwaltet wie alle anderen Richtlinien: Ein Händler kann Kohortenrichtlinien über den unter Teil 2 beschriebenen Workflow „Erstellen → Testen → Veröffentlichen“ erstellen, testen und veröffentlichen.

Beispiel einer veganen Kohortenrichtlinie

Ein Händler erstellt eine Kohortenrichtlinie mit folgenden Merkmalen:

• Kohorten: ["vegan"].

• Matchkriterien: Entspricht jeder Abfrage (oder einer bestimmten Produktkategorie).

Aktion: Soft-Boost auf dietary_restrictions: "vegan" mit einem Boost-Gewicht von 2.

So funktioniert die Kohortenaktivierung

Jedes Richtliniendokument hat ein cohorts-Feld. Bei allgemeinen Richtlinien, die für alle Käufer unabhängig von der Kohorte gelten, kann dieses Feld leer gelassen werden; diesen wird intern von der Steuerungsebene der Wert "_all" zugewiesen. Kohortenspezifische Richtlinien speichern die Namen ihrer Zielkohorte, wie zum Beispiel ["vegan", "kosher", “sweet_tooth”].

Wenn eine Suchanfrage ein Nutzerprofil enthält, erstellt die Steuerungsebene einen einfachen terms-Filter für die Perkolator-Abfrage:

Dieser einzelne Filter umfasst alle allgemeinen Richtlinien sowie die kohortenspezifischen Richtlinien des Nutzers. Der _all-Sentinel ermöglicht einen übersichtlichen Einbeziehungsfilter: Es sind keine must_not- oder exists-Abfragen erforderlich, um den Fall zu behandeln, in dem eine Richtlinie keine Kohortenbeschränkung enthält.

Der Perkolator wertet dann wie gewohnt die Richtlinienübereinstimmungen aus. Der einzige Unterschied besteht darin, dass die Auswahl an Richtlinien auf diejenigen beschränkt wurde, die für die Zielgruppe dieses Käufers relevant sind. Alle nachfolgenden Schritte (kaskadierende Transformationen, Konfliktlösung auf Feldebene, Nachverfolgung verwendeter Phrasen) funktionieren genauso wie der in den Teilen 3 und 4 beschriebene nicht personalisierte Ablauf.

Ergebnisse für nicht-vegane (standardmäßige) Nutzer bei der Suche nach „Schokolade“

Wenn ein nicht-veganer Nutzer nach Schokolade sucht, wird kein veganer Kohorten-Boost auf seine Ergebnisse angewendet. Oft tauchten in den Top-Treffern nicht-vegane Schokoladen wie folgt auf:

Ergebnisse der veganen Kohortenrichtlinie bei der Suche nach „Schokolade“

Wenn ein Käufer aus der veganen Kohorte nach „Schokolade“ sucht, wird diese Richtlinie in die Liste der in Frage kommenden Ergebnisse aufgenommen. Die Übereinstimmung ist gegeben, und die Steuerungsebene gewährt vegan-zertifizierten Schokoladenprodukten einen Soft-Boost. Der Boost wirkt sich multiplikativ aus: Vegane Schokoladen erhalten eine höhere Bewertung, doch nicht-vegane Schokoladen werden nicht vollständig ausgeschlossen, da der oben genannte Filter als Soft-Boost festgelegt ist, den wir in Teil 3 dieser Serie ausführlich beschrieben haben.

Wenn der Käufer jedoch ausdrücklich nach „Hershey-Milchschokolade“ sucht, greift der Vegan-Boost zwar weiterhin, wird jedoch möglicherweise durch die stärkere Textrelevanz der Hershey-Milchschokoladenprodukte überlagert.

Ein Käufer außerhalb der veganen Zielgruppe, der nach der gleichen Abfrage sucht, sieht die Richtlinie für die „vegane Zielgruppe“ nie; sie ist nicht in seiner Auswahl enthalten. Die Governance-Ebene ist identisch, nur der aktive Richtliniensatz unterscheidet sich.

Kohorten mit Kaufhistorie

Ein veganer Kunde mit umfangreichem Kaufverlauf erhält sowohl eine speziell auf seine Kohorte zugeschnittene Richtlinienaktivierung als auch Kaufverlauf-Boosts. Bei neuen oder anonymen Kunden ermöglicht bereits die implizite Zugehörigkeit zu einer Kohorte eine aussagekräftige Personalisierung, ohne dass Verhaltensdaten erforderlich sind (wenn ein anonymer Nutzer beispielsweise ausschließlich nach veganen Produkten gesucht hat, stufen wir ihn als Mitglied der veganen Kohorte ein). Ein Kunde, der sich bei der Kontoeröffnung als Halal-bewusst identifiziert, erhält bei seiner ersten Suche sofort auf Halal zugeschnittene Ergebnisse.

Wie sich Personalisierungsebenen zusammensetzen

Die Verschachtelungsreihenfolge der function_score-Ebenen ist entscheidend. Vom Innersten zum Äußersten:

1. Basisabfrage: Das Schlüsselwort oder die semantische Übereinstimmung mit benannten Abfragen (fulltext_match, title_phrase_match).

2. Ebene der Governance-Richtlinie: Feste Filter als bool.filter-Klauseln, Soft-Boosts als function_score-Funktionen (Teile 3 und 4).

3. Business-Signal-Steigerungen: Margen- und Popularitätssteigerung (die wir in Teil 7 erkunden werden).

4. Kaufverlauf-Boosts: Die äußerste function_score-Ebene.

Diese Reihenfolge stellt sicher, dass die Governance die Ergebnisliste (was angezeigt wird) steuert, geschäftliche Signale das Ranking innerhalb dieser Liste anpassen (was aus Sicht des Händlers zuerst angezeigt wird) und den Kaufverlauf das Ranking auf der Grundlage des individuellen Verhaltens weiter anpasst (was aus Sicht des Käufers zuerst angezeigt wird). Jede Ebene überlagert die vorherige auf multiplikative Weise, sodass sich die Effekte verstärken, anstatt sich zu widersprechen.

Was das operativ bedeutet

Durch die Personalisierung über die geregelte Steuerungsebene bleiben alle in Teil 1 und 2 beschriebenen betrieblichen Eigenschaften erhalten:

• Änderungen ohne Bereitstellung. Kohorten-Richtlinien werden über die Admin-Benutzeroberfläche erstellt, getestet und aktiviert. Das Hinzufügen einer neuen Ernährungkohorte oder das Anpassen einer Gewichtung erfordert weder Codeänderungen noch die Beteiligung der Entwicklungsabteilung.

• Prüfbarkeit. Jede Kohortenrichtlinie ist ein eigenständiges, versioniertes Dokument. Wenn ein Händler fragt: „Warum ist das Ranking für vegane Produkte für diesen Nutzer höher?“, ist die Antwort eine spezifische Richtlinie mit einer spezifischen Priorität, die im Fehlerbehebungs-Panel zusammen mit allen anderen Richtlinien angezeigt wird, die für diese Abfrage ausgelöst wurden.

• Konfliktlösung. Die Richtlinien für Kohorten unterliegen der gleichen Konfliktlösung pro Feld, die in Teil 3 beschrieben wurde. Wenn die Kategorie-Boost-Funktion einer Kohortenrichtlinie mit der Kategorie-Überschreibung einer Kampagnenrichtlinie in Konflikt gerät, wird der Konflikt deterministisch durch denselben Prioritäts- und Strategie-Framework gelöst; eine Sonderbehandlung ist nicht erforderlich.

• Messbarkeit. Da Kohorten-Richtlinien eigenständig und einzeln aktivierbar sind, lassen sich ihre Auswirkungen auf die Konversions-, Klick- und Warenkorb-Raten ebenso wie bei jeder anderen Richtlinie im System unabhängig voneinander messen.

Wie geht es weiter in dieser Serie?

Im nächsten Beitrag wird eine weitere Dimension der gesteuerten Kontrollebene untersucht: wie Margen und Popularitätssteigerungen pro Anfrage durch Richtlinien angepasst werden können, wodurch die ökonomische Optimierung zu einer Governance-Entscheidung und nicht zu einer statischen Konfiguration wird.

Siehe Teil 7: Abfragegesteuerte wirtschaftliche Optimierung: Margen- und Popularitätssteigerung pro Abfrage

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

Die in diesem Beitrag beschriebenen Personalisierungsmuster (Boosting des individuellen Kaufverlaufs und kohortenbasierte Richtlinienaktivierung) wurden von Elastic Services Engineering als Teil unseres wiederholbaren E-Commerce-Suchbeschleunigers konzipiert und entwickelt. Beide Mechanismen sind in die in der gesamten Reihe beschriebene verwaltete Steuerungsebenen-Architektur integriert. 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.

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.

Warum die Interpretation von Abfragen oft zur Herausforderung wird

Die Speicherung von Richtlinien als Code (if/else-Blöcke in der Anwendungsschicht) erzeugt zehntausende Zeilen fehleranfälliger Logik, die kein Indexieren für einen effizienten Richtlinienabruf zur Abfragezeit bietet. Die Iteration ist langsam (eine einzelne Änderung des Verhaltens von Abfragen kann einen sechswöchigen Deployment-Zyklus erfordern), die Verantwortlichkeit ist unklar (warum haben sich die Ergebnisse geändert?), und Geschäftsnutzer können das Suchverhalten ohne technische Einbindung nicht ändern. Dies wird auf der linken Seite des folgenden Bildes gezeigt::

Das Speichern von Richtlinien als Daten in einem Elasticsearch-Index ist auf der rechten Seite des obigen Bildes dargestellt. Dieser Ansatz löst alle Probleme, die mit der fest codierten Abfrage-Auflösungslogik verbunden sind. Allerdings benötigen Sie dafür eine Möglichkeit, schnell zu ermitteln, welche Richtlinien mit der Nutzerabfrage übereinstimmen und wie Konflikte gelöst werden sollten. Hier kommt die kontrollierte Steuerungsebene ins Spiel.

Muster der Steuerungsebene

Eine kontrollierte Steuerungsebene befindet sich zwischen der rohen Nutzerabfrage und dem Elasticsearch-Abruf. Sie empfängt den Nutzertext als Eingabe und gibt einen Ausführungsplan aus, der Filter, Boosts und Entscheidungen zur Weiterleitung der Suchergebnisse enthält.

Eine Pipeline für die Steuerungsebene besteht aus:

1. Nutzerabfrage: Ein Nutzer gibt eine Zeichenfolge ein, wonach er sucht, zum Beispiel „Orangen“ oder „Geschenk für Opa“.

2. Richtliniensuche: Ordnen Sie die Nutzerabfrage dem Richtlinienindex zu.

3. Übereinstimmende Richtlinien zurückgeben: Richtlinien, die der Nutzerabfrage entsprechen, werden aus dem Richtlinienindex zurückgegeben.

4. Richtlinienanwendung: Die Steuerungsebene analysiert diese zurückgegebenen Richtlinien und fügt übereinstimmende Richtlinien zu einem einzigen kohärenten Ausführungsplan zusammen, der Filter, Boosts, Überschreibungen und Leitplanken umfasst und die geeignete Abrufmethode anwendet (z. B. lexikalisches Abrufen, semantisches Abrufen oder einen hybriden Ansatz).

5. Ausführung: Die modifizierte intent-bewusste Elasticsearch-Abfrage wird an die Anwendung weitergegeben, um sie gegen einen Produktkatalogindex auszuführen.

6. Erklärung (optional): Zusätzlich zur Erstellung einer Abfrage, die geschäfts- und absichtsorientierte Ergebnisse liefert, bietet die Steuerungsebene eine optionale Nutzlast zur Erklärbarkeit, um zu zeigen, welche Richtlinien ausgelöst und wie sie kombiniert wurden.

Um herauszufinden, welche Richtlinien für die Suchzeichenkette eines Nutzers angewendet werden sollten, ist ein schnelles, rückwärts abgestimmtes Primitiv erforderlich, das wir mit der Perkolator-Abfrage lösen. Nach dem Abrufen relevanter Richtlinien erfordert die Kombination mehrerer übereinstimmender Richtlinien zu einem einheitlichen Ausführungsplan ein Framework zur Beurteilung: Prioritäten, Konfliktstrategien, die Verfolgung verbrauchter Phrasen und kaskadierende Transformationen, die Richtlinien in einer Sequenz anstatt unabhängig voneinander anwenden. Darüber hinaus muss die am besten geeignete Abruftechnologie ausgewählt werden (zum Beispiel BM25 für „Orangen“ versus semantische Suche für „Geschenk für Opa“).

Richtliniensuche: Überprüfung der Abfrage vor der Produktsuche

Wenn ein Kunde eine Abfrage eingibt, sendet ein Suchsystem mit einer kontrollierten Steuerungsebene diese Abfrage nicht direkt, um sie gegen den Produktkatalog auszuführen. Zunächst wird die Abfrage gegen eine Reihe gespeicherter Richtlinien geprüft und modifiziert, um die Absicht der Abfrage und die Geschäftsprioritäten widerzuspiegeln.

Richtlinienstruktur

Jede Richtlinie ist ein einfaches Dokument, das zwei Dinge definiert:

• Übereinstimmungskriterien: Welcher Abfragetext dazu führen sollte, dass diese Richtlinie ausgelöst wird. Dies kann eine exakte Phrase, ein einzelnes Wort, ein Muster oder eine Kombination sein.

• Aktion: Was tun, wenn die Richtlinie ausgelöst wird. Dies könnte das Anwenden eines Kategorienfilters, das Ausschließen von Produkten, das Extrahieren einer Preisbeschränkung oder die Änderung der Abrufstrategie sein.

Das System findet alle passenden Richtlinien, setzt sie zu einem Ausführungsplan zusammen und führt erst dann die Produktsuche durch. Zusammengenommen wirken die Richtlinien wie ein sachkundiger Verkäufer, der versteht, was Sie suchen, und Sie zum richtigen Regal führt.

Das Richtlinienmuster

In den ersten Artikeln dieser Reihe wurden Beispiele für Richtlinien in Aktion vorgestellt: „Orangen" werden auf die Kategorie Obst und Gemüse beschränkt, „ohne Erdnüsse" als Ausschluss behandelt und „Geschenk für Opa" an die semantische Suche weitergeleitet. Der architektonische Kernpunkt ist, dass in jedem Fall die Abfrage anhand gespeicherter Richtlinien überprüft wird, bevor die Produktsuche beginnt. Die Richtlinien bestimmen, welche Einschränkungen angewendet werden, welcher Text geändert und welche Abrufstrategie verwendet werden soll. Die Abfrage gegen den Produktkatalog erfolgt, nachdem die Richtlinien angewendet wurden und eine neu geschriebene Abfrage erstellt wurde.

Warum dies schnell ist

Ein E-Commerce-System für Unternehmen kann Millionen von Produkten enthalten, aber nur Hunderte oder Tausende von Richtlinien. Der Suchschritt nach Richtlinien durchsucht einen kleinen kuratierten Index, nicht den vollständigen Produktkatalog, und erfolgt daher schnell. Da Richtlinien als Daten in einem eigenen Index gespeichert werden, müssen Händler, die eine neue Richtlinie hinzufügen, gar nicht erst den Anwendungscode berühren, und Techniker, die für die Optimierung der Produktsuche zuständig sind, kommen nicht mit dem Richtlinienindex in Berührung. Beide Probleme entwickeln sich unabhängig voneinander.

Die obigen Beispiele beschreiben, was konzeptionell geschieht. Unter der Haube wird die Richtliniensuche mit dem Elasticsearch-Perkolator-Abfragetyp implementiert, der speziell für dieses Muster entwickelt wurde: das Abgleichen eingehender Texte mit einer Reihe gespeicherter Abfragen. Teil 4 dieser Reihe bietet einen praktischen eingehenden Einblick in die Perkolator-Implementierung, einschließlich Index-Mappings, Grenzmarkern und von Highlights gesteuerter Phrasenverfolgung. Nachdem wir uns in Teil 4 eingehend mit dem Lookup-Mechanismus befasst haben, wollen wir uns nun der Frage zuwenden, was ein Richtliniendokument eigentlich enthält und wie die Steuerungsebene mehrere Richtlinien zu einem einzigen Ausführungsplan zusammensetzt.

Beispielrichtlinien

Nachdem wir nun erfahren haben, was Richtlinien konzeptionell bewirken, schauen wir uns an, was sie tatsächlich enthalten. Die beiden nachfolgenden Richtlinien wurden so gestaltet, dass sie absichtlich in Konflikt zueinander stehen. Dies soll das in den darauffolgenden Abschnitten beschriebene Konfliktlösungssystem veranschaulichen.

Günstige Schokolade

Die unten dargestellte Richtlinie erkennt, ob ein Nutzer eine Suchabfrage mit dem Begriff „günstige Schokolade“ gestellt hat. In diesem Fall beschränken sich die Ergebnisse auf die Kategorien „Schokolade“ und „Vollmilchschokolade“. Diese Richtlinie wendet auch einen Preisfilter von 2 $ an. Beachten Sie außerdem, dass diese Richtlinie eine Priorität von 210 hat. Darauf werden wir zurückkommen, wenn wir die Konfliktlösung genauer besprechen.

Die hier gezeigten Einstellungen für den Filtermodus und die Konfliktstrategie (hard_filter, soft_boost, restrict, override) werden im Abschnitt zur Konfliktlösung weiter unten ausführlich erläutert.

Wenn die obige Richtlinie aktiviert ist, berücksichtigt eine Suche nach „günstige Schokolade“ den Preisfilter von 2 $ und beschränkt die Ergebnisse auf die Kategorien „Schokolade“ und „Milchschokolade“. Ein Beispiel für die Ergebnisse finden Sie weiter unten:

Weihnachtsschokolade

Die unten gezeigte Richtlinie ist ein Beispiel für eine Richtlinie, die zur Weihnachtszeit angewendet werden könnte. Dieses Beispiel beschränkt die Ergebnisse auf „Weihnachtslebensmittel und -getränke“ und „Weihnachtssüßigkeiten“, hebt Produkte hervor, die auch in der Kategorie „Adventskalender“ enthalten sind, und wendet einen Preisfilter von weniger als 7 $ an, um sich auf erschwingliche saisonale Artikel zu konzentrieren. Beachten Sie außerdem, dass diese Richtlinie eine Priorität von 300 hat. Wir werden darauf zurückkommen, wenn wir die Konfliktlösung detaillierter besprechen.

Wenn die oben genannte Richtlinie ohne widersprüchliche Richtlinien aktiviert ist, berücksichtigt eine Suche nach „Schokolade“ den Preisfilter von 7 $, beschränkt die Ergebnisse auf die Kategorien „Weihnachtslebensmittel und -getränke“ und „Weihnachtssüßigkeiten“ und hebt alle Produkte hervor, die mit „Adventskalender“ gekennzeichnet sind. Ein Beispiel für die Ergebnisse finden Sie weiter unten:

Kombination übereinstimmender Richtlinien

Die oben beschriebene Richtliniensuche ist nur die halbe Wahrheit. Die andere Hälfte ist das, was passiert, wenn mehrere Richtlinien derselben Abfrage entsprechen.

In jeder nichttrivialen Deployment wird eine einzelne Abfrage routinemäßig mehrere Richtlinien gleichzeitig auslösen. „Günstige Schokolade“ passt zu beiden oben dargestellten Richtlinien. Jede Richtlinie ist für sich genommen richtig. Die Herausforderung besteht darin, sie zu einem einzigen, kohärenten Ausführungsplan zusammenzustellen, ohne Widersprüche, ohne Doppelzählungen und ohne dass eine Richtlinie die Arbeit einer anderen stillschweigend rückgängig macht.

Dies ist kein Nachschlageproblem; es ist ein Beurteilungsproblem. Das System muss entscheiden:

• Reihenfolge der Anwendung: Wenn eine Negationsrichtlinie „ohne Erdnüsse“ aus der Abfrage entfernt, sieht die Preisrichtlinie dann noch den Originaltext oder den geänderten Text?

• Filterkonflikte: Wenn zwei Richtlinien unterschiedliche Preisobergrenzen festlegen, welche zählt dann? Wird der Verlierer stillschweigend fallen gelassen oder degradiert er sich sanft zu einem soft Boost?

• Phrasenbesitz: Wenn zwei Richtlinien auf dasselbe Wort zutreffen und die erste es bereits belegt hat, sollte die zweite dann trotzdem greifen?

Eine naive Implementierung (Anwendung aller übereinstimmenden Richtlinien unabhängig voneinander und Zusammenführung von Ergebnissen) führt zu Fehlern, sobald Richtlinien interagieren. Die Architektur benötigt ein explizites Modell dafür, wie sich Richtlinien zusammensetzen. In den nächsten beiden Abschnitten wird dieses Modell beschrieben: ein Framework zur Prioritätensetzung und Konfliktlösung sowie ein kaskadierendes Transformationsmodell, das die Interaktion zwischen Richtlinien deterministisch gestaltet.

Die zentrale Erkenntnis ist, dass die Anwendung von Richtlinien keine Reihe unabhängiger Abläufe darstellt, sondern eine kaskadierende Transformation. Jede Richtlinie erhält den von allen Richtlinien mit höherer Priorität erzeugten Rewrite-Zustand und transformiert ihn weiter:

Anfangszustand → [Richtlinie A] → Zustand' → [Richtlinie B] → Zustand'' → ... → Ausführungsplan

Der Zustand enthält den umgeschriebenen Abfragetext, akkumulierte Filter, die aktuelle Absicht und alle Synonym-Erweiterungen. Eine hochprioritäre Richtlinie kann Text aus der Abfrage entfernen, und jede nachfolgende Richtlinie sieht die geänderte Abfrage, nicht die ursprüngliche. Kontext wird akkumuliert. Die Reihenfolge ist wichtig.

Priorität und Konfliktlösung: Der Determinismus zählt

Die konkreten Konfliktstrategien sind eine bewusste Gestaltungsentscheidung. Einzelne Unternehmen können Konflikte unterschiedlich lösen, abhängig von ihren geschäftlichen Anforderungen. Der folgende Ansatz veranschaulicht die Art des Beurteilungs-Frameworks, die eine Steuerungsebene benötigt. Wichtig sind nicht diese spezifischen Strategien, sondern dass das System explizite, deterministische Strategien enthält, anstatt Konflikte durch unvorhersehbare Interaktionen lösen zu lassen.

Prioritätsreihenfolge

Die Richtlinien sind nach Priorität sortiert (höchste zuerst). Wenn mehrere Richtlinien mit derselben Abfrage übereinstimmen, werden sie in Prioritätsreihenfolge angewendet. Wenn zwei Richtlinien versuchen, dasselbe Filterfeld festzulegen, hat die deklarierte Strategie der Richtlinie mit höherer Priorität für dieses Feld Vorrang. Wenn mehrere Richtlinien ausgelöst werden, die dieselbe Priorität haben, erhält die Richtlinie mit der höchsten ID Vorrang (als ob ihr eine höhere Priorität zugewiesen wäre); diese Wahl sorgt für deterministisches Verhalten, wenn Konflikte auftreten.

Auflösung pro Feld, nicht pro Richtlinie

Ein kritisches Designprinzip: Die Konfliktlösung erfolgt pro Feld (zum Beispiel Marke, Kategorie oder Beschreibung), nicht pro Richtlinie. Wenn zwei Richtlinien Filter erzeugen, die sich bei bestimmten Feldern überschneiden, sind nur diese spezifischen Felder von der Konfliktlösungsstrategie betroffen, und die Auflösungsstrategie wird durch die übereinstimmende Richtlinie mit der höchsten Priorität bestimmt. Nicht kollidierende Felder aus beiden Richtlinien bleiben erhalten.

Dies ist wichtig, weil die Alternative eines richtlinienbasierten Ansatzes das System dazu zwingen würde, eine gesamte Richtlinie entweder zu akzeptieren oder abzulehnen, wenn nur ein Konflikt zwischen den Feldern besteht.

Bei der Auflösung pro Feld bleibt die maximale Menge an nützlichen Einschränkungsinformationen erhalten.

Drei Einstellungen pro Filterfeld

Jedes Filterfeld in einer Richtlinie hat drei unabhängige Einstellungen:

Filtermodus: Wie der Filter angewendet wird, wenn es keinen Konflikt gibt.

• hard_filter (Standard): Wird als Elasticsearch bool.filter Klausel angewendet. Dies ist nützlich, um nicht verwandte Produkte vollständig auszuschließen. Wenn man beispielsweise die Suche nach „Orangen“ auf die Kategorie Obst und Gemüse beschränkt, werden Treffer wie Orangensaft und Orangenmarmelade ausgeschlossen. Nicht übereinstimmende Dokumente werden vollständig aus den Ergebnissen ausgeschlossen.

• soft_boost: Wird als Elasticsearch function_score-Gewichtung mit einer konfigurierbaren boost_weight angewendet. Übereinstimmende Dokumente erhalten einen Ranking-Boost, aber nicht übereinstimmende Dokumente werden nicht ausgeschlossen. Das ist nützlich, um zum Beispiel eine Marke zu stärken, ohne andere Marken auszuschließen.

Konfliktstrategie

Was passiert, wenn eine Richtlinie mit niedrigerer Priorität dasselbe Feld festlegt:

• override: Der Wert dieser Richtlinie mit hoher Priorität gewinnt; der Wert mit niedrigerer Priorität wird vollständig ignoriert. Gültig für alle Feldtypen.

• restrict: Nehmen Sie den restriktiveren numerischen Wert (zum Beispiel die niedrigere Obergrenze für Preis__max, the higher floor for price__min). Gilt nur für numerische Bereichsfelder.

• merge: Kombinieren Sie beide Werte in eine Vereinigung. Gültig nur für nicht-numerische Felder.

• soft_boost: Konvertieren Sie den konfliktierenden Filter in ein function_score-Gewicht mit einer konfigurierbaren boost_weight anstelle eines festen Filters. Weitere Details zum Function_score-Boosting finden Sie unter „Beeinflussung des BM25-Rankings mit multiplikativem Boosting in Elasticsearch“. Dies gilt nur für Nicht-Negationsfelder.

Wert: Der tatsächliche Filterwert (z. B. eine Kategorienliste, ein Preisschwellenwert).

Strategien nach Feldtyp: Nicht alle Strategien sind für alle Feldtypen sinnvoll. Zum Beispiel ist eine Ausschlussregel von Natur aus binär, daher kann sie keinen soft Boost erhalten. Die folgende Tabelle zeigt, welche Strategien für einzelne Feldtypen verfügbar sind:

Feldtyp

Verfügbare Strategien

Standard

Negationsfelder (__not, __match__not)

überschreiben, zusammenführen

Überschreiben

Numerische Bereichsfelder (__max, __min., __gt, __lt.)

einschränken, überschreiben, Soft-Boost

einschränken

Alle anderen Felder (Schlüsselwort, Text)

soft_boost, override, merge

soft_boost

Negationsfelder können nicht soft-geboostet werden, da die Ausschlüsse binär sind. Die Umwandlung von „zeige niemals Konserven“ in „ziehe Nicht-Konserven vor“ ändert die Semantik grundlegend. Ein Produkt aus „Konserven“ würde immer noch erscheinen, nur etwas niedriger eingestuft, was den Zweck des Ausschlusses unterläuft.

Ein konkretes Beispiel: Die Suche nach „günstiger Schokolade“ während einer Weihnachtskampagne

Angenommen, ein Händler hat die beiden zuvor demonstrierten Richtlinien für Schokolade erstellt, eine mit niedrigerer Priorität für günstige Schokolade und eine andere, höher priorisierte schokoladenbezogene Richtlinie, die während der Weihnachtszeit aktiviert wird. Wenn beide dieser Richtlinien aktiviert sind, hängt ihre Kombination vom Filtermodus und der Konfliktstrategie der Richtlinie mit höherer Priorität ab. Wenn beide zuvor besprochenen Richtlinien aktiviert sind, werden sie wie folgt kombiniert:

Dies zeigt zwei Konflikte, eine bei den Kategorien und eine beim Preis. Es sollte erwähnt werden, dass die Abfrage, die nach dieser Transformation ausgeführt wird, folgende Eigenschaften aufweist:

• Es werden nur Produkte aus den Kategorien „Weihnachtslebensmittel und -getränke“ und „Weihnachtssüßigkeiten“ angezeigt.

• Innerhalb dieser Kategorien werden Produkte, die auch mit der Kategorie „Adventskalender“ gekennzeichnet sind, um das Dreifache aufgewertet.

• Ein Preisfilter für 2 $ wird angewendet. Er stammt aus der Richtlinie mit niedrigerer Priorität (weil die Richtlinie mit höherer Priorität bei Konflikten „Restrict“ festlegt).

• Das Wort „günstig“ wird entfernt und es werden nur Produkte zurückgegeben, die „Schokolade“ entsprechen.

Wenn diese beiden Richtlinien aktiviert sind, gibt „billige Schokolade“ Ergebnisse zurück, die der Abbildung unten ähneln:

Einschränkungen lockern

Vielleicht möchte der Einzelhändler keine Produkte in den Kategorien „Schokolade“ und „Milchschokolade“ während der Weihnachtszeit ausschließen. Die Einstellungen der Weihnachtsrichtlinie könnten zu weit gefasst sein und versehentlich Kategorien entfernt haben, die von der Richtlinie für „günstige Schokolade“ abgedeckt werden. Dies ist ein Beispiel, das zeigt, warum es unter Umständen wünschenswerter sein kann, Richtlinien mit niedrigerer Priorität mit sich widersprechenden Richtlinien mit höherer Priorität zu kombinieren. Wir könnten beispielsweise die Weihnachtsschokoladen-Aktion so modifizieren, dass wir bei Konflikten nicht „Überschreiben“, sondern einen soft Boost durchführen. Die Änderung dieser Richtlinie würde wie folgt aussehen:

Nach dieser Modifikation sieht die Ausführung der Transformationspipeline zur Abfrageumschreibung für „günstige Schokolade“ wie folgt aus:

Mit dem soft Boost bei Konflikten werden die miteinander in Konflikt stehenden Filter in softe Boosts umgewandelt, anstatt weggelassen zu werden. Die Abfrage, die nach dieser Umwandlung im Produktkatalog ausgeführt wird, hat die folgenden Eigenschaften:

• Weil „Bei Konflikt“ als „soft Boost“ in der höher priorisierten Richtlinie angegeben ist, werden die Konflikte wie folgt in Boosts umgewandelt:

  • Produkte aus den Kategorien „Weihnachtslebensmittel und -getränke“ und „Weihnachtssüßigkeiten“ erhalten einen einfachen Boost.

  • Produkte aus den Kategorien „Schokolade“ und „Milchschokolade“ erhalten einen dreifachen Boost.

• Wie im vorherigen Beispiel, bei dem die Produkte auch als zur Kategorie „Adventskalender“ gehörig markiert sind, erhalten sie einen dreifachen Boost.

• Wie im vorherigen Beispiel wird ein Preisfilter für 2 $ angewendet.

• Das Wort „günstig“ wird entfernt und es werden nur Produkte zurückgegeben, die „Schokolade“ entsprechen.

Bei weniger strenger Filterung sehen die Ergebnisse wie folgt aus:

Preisüberschreibung einer Richtlinie mit hoher Priorität

Vielleicht möchte der Händler zu Weihnachten auch etwas teurere Schokoladenprodukte anzeigen, indem der Preis auf 7 $ erhöht wird. Um sicherzustellen, dass der Maximalpreis aus der Weihnachtsschokoladen-Richtlinie nicht überschrieben wird, wenn jemand nach „günstiger Schokolade“ sucht, können wir den Konfliktmodus des Preises folgendermaßen auf „überschreiben“ statt auf „einschränken“ setzen:

Mit dieser Überschreibung ignoriert die Abfrage für „billige Schokolade“ den in der „billigen Schokoladenrichtlinie“ definierten Höchstpreis und wendet nur den in der „Weihnachtsschokoladenrichtlinie“ festgelegten Preis an, wie folgt:

Dies ähnelt dem vorherigen Beispiel, mit dem Unterschied, dass der Höchstpreis auf den Wert von 7 $ aus der Richtlinie mit höherer Priorität festgelegt ist, weil in dieser Richtlinie „Überschreiben“ bei Konflikt angegeben wurde. Wenn der Weihnachtspreisfilter Vorrang hat, sehen die Ergebnisse wie folgt aus:

Diese drei Varianten (override, soft_boost und override on price) zeigen eine zentrale Eigenschaft des Systems: Ein Merchandiser kann die Interaktion zweier Richtlinien ändern, indem er eine Einstellung in einem einzelnen Feld innerhalb einer einzelnen Richtlinie ändert, ohne Code bereitzustellen. Die Konfliktstrategie ist der Hebel, der das Geschäftsverhalten steuert.

Verfolgung verwendeter Phrasen

Es gibt eine subtilere Form des Konflikts: zwei Richtlinien, die auf dieselbe Phrase zutreffen. Wenn eine Richtlinie mit höherer Priorität „ohne Erdnüsse“ aus der Abfrage entfernt, hat eine Richtlinie mit niedrigerer Priorität, die ebenfalls auf „ohne“ zutrifft, nichts mehr, worauf sie wirken kann. Das System erkennt, ob die übereinstimmende Phrase nicht mehr in der umgeschriebenen Abfrage vorhanden ist, und überspringt die Richtlinie mit niedrigerer Priorität.

Intent-Richtlinien sind von der Verfolgung verbrauchter Phrasen ausgenommen: Sie legen die Abrufstrategie basierend auf der ursprünglichen Abfrageübereinstimmung fest, unabhängig davon, welcher Text durch Richtlinien mit höherer Priorität entfernt wurde.

Gemeinsam verleihen Prioritätsordnung, feldbasierte Konfliktlösung und die Verfolgung verbrauchter Phrasen der Steuerungsebene ein deterministisches Kompositionsmodell. Auf dieser Grundlage kann das System eine Routing-Entscheidung treffen, die ohne sie riskant wäre.

Governance macht die Abrufstrategie sicher

Eine wichtige Erkenntnis bezüglich des Routings zur richtigen Abrufmethode (textuell, semantisch oder hybrid) ist, dass sie nach der Governance ausführen wird. Wenn Ihre Richtlinien bereits die „Produktkategorie“ durchgesetzt haben, ist der semantische Abruf wesentlich weniger riskant, da die Kandidatenmenge eingeschränkt ist. Eine semantische Suche mit über 500 Produktartikeln ist eine ganz andere Sache als eine semantische Suche über 500.000 SKUs. Die Governance schränkt den Explosionsradius ein, bevor der Abruf beginnt.

Ohne entsprechende Steuerung könnte beispielsweise eine semantische Abfrage nach „Obst mit hohem Vitamin-C-Gehalt unter 4 $“ neben Obst auch Vitaminpräparate, Karotten und grüne Paprika zurückgeben. Die Steuerungsebene stellt sicher, dass diese unerwünschten Ergebnisse nicht einmal als Teil der semantischen Erweiterung in Betracht gezogen werden.

Mit dieser Einschränkung wendet die Steuerungsebene pragmatische Routing-Logik an:

• Lexikalisch für Navigations- und Hauptabfragen, bei denen deterministische Präzision zählt.

• Semantisch für beschreibende Discovery-Abfragen, bei denen ein Konzeptabgleich hilft.

• Selektiv hybrid, wenn Beschränkungen bereits durchgesetzt wurden und das Unternehmen einen umfassenderen Abruf akzeptiert.

Von der Architektur bis zur Implementierung

Die kontrollierte Steuerungsebene übersetzt die Geschäftsabsicht in deterministische, zusammensetzbare Ausführungspläne, ohne diese Logik in den Anwendungscode einzubetten. Richtlinien sind Daten: Sie werden zur Abfragezeit abgeglichen, durch explizite Konfliktstrategien pro Feld aufgelöst und als kaskadierende Transformationen angewendet, die erklärbare Ergebnisse liefern. Elastic Services Engineering hat diese Architektur für E-Commerce-Teams in Unternehmen entwickelt und implementiert, wobei wiederholbare Muster und Beschleuniger verwendet wurden, die den Weg vom Konzept zur Produktion komprimieren. Eine Demo unserer Implementierung einer Steuerungsebene können Sie auf YouTube unter folgendem Link ansehen: Fixing Search Relevance in Seconds: Introducing PRISM.

Wie geht es weiter in dieser Serie?

Der nächste Beitrag geht praktisch auf die Implementierung ein: wie der Elasticsearch-Perkolator die Richtliniensuche beschleunigt, einschließlich Index-Mappings, Grenzmarkern, von Highlights gesteuerter Phrasenverfolgung und konkreter Abfragebeispiele.

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

Die in diesem Beitrag beschriebene Architektur der Steuerungsebene (Konfliktlösung pro Feld, kaskadierende Richtlinien-Transformationen und durch Governance beschränktes Retrieval-Routing) wurde von Elastic Services Engineering entworfen und entwickelt. Jedes Muster, jeder Screenshot und jede Transformationspipeline, die in dieser Serie gezeigt wird, stammt aus einem funktionierenden System, das von Elastic Services Engineering entwickelt und anhand von Produktkatalogen im Unternehmensmaßstab validiert wurde.

Wenn Sie eine kontrollierte, richtliniengesteuerte Steuerungsebene in Elasticsearch implementieren möchten, kann Elastic Services Sie schneller dorthin bringen.

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.

Die lexikalische Suche (Textabgleich), die semantische Suche (Abgleich von Konzepten) und die hybride Suche (Kombination lexikalischer und semantischer Signale) lösen diese Probleme für sich genommen nicht. Bei der lexikalischen Suche werden möglicherweise alle Ergebnisse angezeigt, die das Wort „Orangen“ enthalten, während sich die rein semantische Suche bei einer Suchanfrage mit hoher Intentionsstärke wie „Orangen“ auf verwandte Begriffe wie Zitronen oder Grapefruits ausweiten kann. Die hybride Abfrage kombiniert diese lexikalischen und semantischen Signale, kann jedoch nach wie vor nicht entscheiden, ob diese Abfrage als navigatorisch zu behandeln ist, welche Einschränkungen durchgesetzt werden sollten oder welche geschäftlichen Richtlinien gelten sollten. Das Problem liegt nicht in der Abruftechnologie selbst, sondern im Fehlen einer Steuerungsebene, die erkennt, um welche Art von Abfrage es sich handelt und welche Einschränkungen vor Beginn des Abrufs durchgesetzt werden müssen.

In diesem Blogbeitrag befassen wir uns mit der Steuerung der E-Commerce-Suche, ihrer Bedeutung und der Frage, wie eine Kontrollschicht für vorhersehbare und präzise Suchergebnisse sorgt.

Was Governance in der E-Commerce-Suche bedeutet

Governance bedeutet in diesem Zusammenhang, eine Entscheidungsebene zwischen der Abfrage des Nutzers und der Abruf-Engine einzuführen. Diese Ebene erfüllt die folgenden Funktionen:

• Klassifiziert die Suchabsicht: Handelt es sich um eine Navigation („Orangen“) oder um eine Suche („Geschenk für Opa“)?

• Wendet geschäftliche Vorgaben an: Welche Kategoriegrenzen, Zulassungsregeln, Verfügbarkeitsbeschränkungen oder Merchandising-Richtlinien gelten?

• Wege zur geeigneten Strategie: Sollte hierbei lexikalisches Abrufen, semantisches Abrufen oder ein hybrider Ansatz zum Einsatz kommen?

Eine Governance-Ebene legt fest, welcher Abrufansatz für jede Abfrage verwendet werden soll, welche Einschränkungen durchgesetzt werden müssen und welche Geschäftsrichtlinien vor Beginn des Abrufs gelten sollen. Es ist wichtig, Governance nicht mit dem hybriden Abruf zu verwechseln: Der hybride Abruf ist eine Abrufstrategie, die lexikalische und semantische Signale kombiniert, während Governance die vorgelagerte Entscheidungsebene ist, die bestimmt, ob lexikalische, semantische oder hybride Signale verwendet werden sollen.

Der Status quo: Die „Spaghetti“-Implementierung auf Anwendungsebene

Derzeit versuchen viele Händler, dieses Problem zu lösen, indem sie die Logik direkt in die Anwendungsschicht integrieren. Dies führt oft zu Spaghetti-Code, also zu Tausenden von Zeilen fest codierter if-then-Anweisungen, Regex und komplexen Suchvorlagen.

Dieser Ansatz kann die oben gezeigten gewünschten Suchergebnisse liefern; jedoch verursacht er erhebliche betriebliche Reibungsverluste:

• Abhängigkeit von der Entwicklungsabteilung: Geschäfts-Nutzer und Merchandiser können das Suchverhalten nicht ohne Entwicklungs-Tickets und lange Deployment-Zyklen ändern, die oft mehrere Wochen dauern.

• Fragmentierung: Die Suchlogik verteilt sich auf den Anwendungscode und die Suchvorlagen, ist schwer zu erklären oder zu überprüfen und birgt daher Risiken bei der Weiterentwicklung.

Selbst wenn Teams die Notwendigkeit des Routings erkennen, konzentriert sich die Debatte oft auf die falsche Frage: welche Abrufmethode gewählt werden soll.

Die falsche Wahl: Lexikalisch vs. semantisch vs. hybrid

Suchteams betrachten diese Herausforderung häufig als eine Frage der Wahl der Abrufstrategie: lexikalisch/BM25 versus semantisch/Vektoren versus hybrid. Diese Sichtweise ist zwar nachvollziehbar (die Abrufmethoden spielen eine Rolle), lässt jedoch die häufigste Fehlerquelle in realen Implementierungen außer Acht: Die Verwendung eines einzigen Abrufansatzes für alle Abfragen führt zu suboptimalen Ergebnissen.

Commerce Search ist eine Mischung aus grundlegend verschiedenen Absichten:

• Deterministische Navigation mit hoher Absicht („Orangen“, „Milch“, „Schokolade ohne Erdnüsse“, „billiges Olivenöl“).

• Explorative Suche („Jacke zum Wandern in den Bergen“, „Geschenk für ein 12‑jähriges Kind, das Robotik mag“).

• Betriebliche Einschränkungen (Verfügbarkeit, Größe, Preis, Farbe).

• Merchandising und Kampagnen (Boost, Begraben, saisonale Kampagnen).

Wenn das System all diese Vorgänge über dieselbe Abrufstrategie abwickelt, sind die Ergebnisse oft auf vorhersehbare Weise systematisch fehlerhaft, da es dem Betriebsmodell an Governance mangelt. Wenn Teams dies nicht als Lücke in der Unternehmensführung erkennen, reagieren sie mit dem einzigen Mittel, das ihnen zur Verfügung steht: noch mehr Feinabstimmung.

Warum „Relevanzoptimierung“ zyklisch werden kann.

Ohne eine Routing-Schicht verwandelt sich „Relevanz“ oft in einen nie endenden Rückstand:

• Warum zeigt diese Abfrage Zubehör über dem Kernprodukt an?

• Warum hat diese Kopfabfrage plötzlich verwandte Ergebnisse angezeigt?

• Warum änderten sich die Ergebnisse, nachdem wir Synonyme hinzugefügt, Analysatoren angepasst oder Hybrid aktiviert hatten?

• Warum benötigt das Business-Team ein Engineering-Release, um eine einzelne Abfrage zu beheben?

Die Teams reagieren mit weiteren Optimierungen: mehr Synonyme, mehr Boosts, mehr Experimente zur Neugewichtung, mehr Ausnahmen im Anwendungscode. Dies kann eine Zeit lang funktionieren, führt jedoch häufig zu instabilem Verhalten, da dem System nach wie vor eine explizite Entscheidungsebene fehlt, um den Abfragetyp zu bestimmen und die richtigen Einschränkungen vor dem Abruf durchzusetzen.

Die Anatomie der E-Commerce-Absicht: „Head“ und „Tail“

In diesem Abschnitt verwenden wir „Head“ und „Tail“ als praktische Kurzform für gängige Navigations- und Suchmuster im E-Commerce. In der realen Welt enthalten viele Anfragen Aspekte von beidem:

„Head“-Abfragen (deterministische Absicht)

Dies sind direkte, navigationsbezogene Abfragen, bei denen der Nutzer genau weiß, was er möchte:

• Absicht in Bezug auf einen einzelnen Artikel ("Orangen", "Milch", "Brot").

• Genaue Marken oder Produktfamilien („iPhone 15 Pro“, „Diet Coke“).

• Artikelnummern, Modellnummern, Größen ("ABC123", "air max 270").

Für diese Abfragen kann die lexikalische Suche die Token-Korrespondenz (Wortübereinstimmung) abdecken, aber das Unternehmen erwartet außerdem, dass Constraints eingehalten werden, vorhersehbare Rankings zurückgegeben werden und die Ergebnisse steuerbar sind. Ein Merchandiser muss sicherstellen, dass eine Abfrage innerhalb der richtigen Kategoriegrenzen aufgelöst wird, die Eligibility-Kriterien einhält und bestimmte geschäftliche Prioritäten sichtbar macht.

Governance ist erforderlich, um die beabsichtigte Lösung durchzusetzen. Zum Beispiel sollten „Orangen“ der Kategorie Frischwaren zugeordnet werden, nicht Orangensaft, Orangenmarmelade oder Orangenlimonade.

„Tail“-Abfragen (explorative Datensuche)

Dies sind beschreibende, absichtsvolle Suchanfragen, mit denen Käufer recherchieren:

• „Geschenk für Opa mit einer Vorliebe für Süßes“

• „Jacke zum Wandern in den Bergen“

• „Schuhe, um den ganzen Tag zu stehen“

Der lexikalische Abruf hat hier oft Schwierigkeiten. Der semantische Abruf ist überlegen, weil er das Abfragekonzept mit dem Produkt verknüpfen kann, selbst wenn die Formulierungen nicht übereinstimmen. Aber auch der semantische Abruf allein reicht selten aus. Abfragen aus der Praxis erfordern oft, dass Constraints durchgesetzt werden – unabhängig davon, welche Abrufmethode verwendet wird.

Die Einschränkungen sind orthogonal zur Abrufmethode.

Das Anwenden von Einschränkungen auf semantische Abrufe bedeutet nicht hybride Suche. Dies sind orthogonale Konzepte. Einschränkungen wie Filter und Boosts in Elasticsearch können auf jede lexikalische, semantische oder hybride Suche angewendet werden. Die Herausforderung besteht darin, zu entscheiden, wie die Abfrage interpretiert werden soll, welche Einschränkungen durchgesetzt werden müssen und welche Abfragemethode verwendet werden soll.

Im Folgenden finden Sie einige Beispiele für Abfragen, die die Datensuche mit festen Einschränkungen kombinieren:

• Orangen: Lexikalische Suche nach „Orangen“ unter Hinzunahme einer Kategoriebeschränkung, wie beispielsweise „Obst“ oder „Frischwaren“, wodurch Orangenmarmelade, Orangensaft und Orangenlimonade ausgeschlossen werden.

• Früchte mit hohem Vitamin-C-Gehalt unter 4 $: Semantische Suche nach dem Nährwert plus Einschränkungen, die die Ergebnisse auf die Kategorie Obst und Produkte unter 4 $ beschränken.

• Bequeme Schuhe für die Arbeit: Semantischer Informationsabruf für kontextuelle Absicht plus eine Kategoriebeschränkung, die die Ergebnisse auf Schuhe begrenzt.

Diese Abfragen können nicht mit einem einzigen Ansatz bearbeitet werden:

• Ein rein lexikalischer Abruf ist hier oft unzureichend, da Phrasen wie „reich an Vitamin C“ oder „komfortabel“ möglicherweise nicht als saubere, strukturierte Attribute existieren. Sie müssen möglicherweise aus Produktbeschreibungen, Bewertungen oder Spezifikationen abgeleitet werden.

• Auch eine rein semantische Suche reicht nicht immer aus, da eine Suchanfrage wie „vitamin-C-reiche Früchte“ ohne explizite Einschränkungen auf Vitaminpräparate, Getränke mit Fruchtgeschmack oder vitaminreiches Gemüse außerhalb der beabsichtigten Kategorie und Preisklasse ausgeweitet werden könnte.

Eine Steuerungsebene legt fest, ob eine Abfrage eine lexikalische Suche, ein semantisches Verständnis, die Durchsetzung von Einschränkungen oder eine Kombination dieser Elemente erfordert. Ohne diese Ebene könnten E-Commerce-Teams in folgende Situation geraten:

• Übermäßige Einschränkung: Verwendung lexikalischer Abfragen für semantische Anfragen (zum Beispiel „Geschenk für Opa“).

• Unterbeschränkung: Verwendung semantischer Abfragen für Head-Abfragen mit hoher Intention (z. B. „Orangen“).

Die Herausforderung im Bereich der Governance besteht darin, ein System zu entwickeln, das für jede Art von Anfrage die richtige Entscheidung treffen kann.

Was passiert ohne Governance?

Die häufigste Fehlerquelle ist ganz einfach: Teams nehmen die rohe Benutzeranfrage und leiten sie direkt an eine einzige Abrufstrategie weiter (lexikalisch, semantisch oder hybrid), ohne eine zwischengeschaltete Governance-Ebene.

Die lexikalische Suche verfehlt die beabsichtigte Auflösung.

Wenn ein Nutzer nach "Orangen" sucht, kann eine lexikalische Suchstrategie alles zurückgeben, was dieses Token enthält: Orangensaft, Orangenmarmelade oder Orangenlimonade. Das System hat den Begriff korrekt zugeordnet, aber ohne Governance kann es den beabsichtigten Einkaufskontext (die Frucht) nicht auflösen.

Der semantische Abruf weitet sich über die beabsichtigten Einschränkungen hinaus aus

Wenn ein Nutzer nach „Orangen“ sucht, kann ein semantisches System konzeptionell verwandte Elemente aus nahegelegenen Produktkonzepten abrufen. Das System versteht zwar den übergeordneten Bereich (Obst oder Gemüse), aber ohne explizite Steuerung kann es dennoch über die vom Nutzer beabsichtigte Beschränkung (speziell Orangen) hinausgehen.

Die Lücke ist Governance

Erforderlich ist eine vorgelagerte Entscheidungsebene, die die Abfrageabsicht bestimmt und die richtigen Einschränkungen durchsetzt, bevor der Abruf beginnt. Dadurch werden Probleme wie die folgenden behoben:

• Ähnliche oder verwandte Artikel, die neben dem angezeigt werden, was der Nutzer eigentlich gesucht hat.

• Verschwimmende Kategoriegrenzen („Getränke“ vs. „Frischwaren“).

• Unfähigkeit, saisonale Boosts oder Kampagnen umzusetzen.

• Unvorhersehbare und unerklärliche Ergebnisse.

Absichtserkennung und Weiterleitung: Die notwendige Steuerungsebene

Ein gesteuertes Suchsystem führt eine schlanke Steuerungsebene vor dem Abruf ein (vor der Ausführung einer Abfrage in Elasticsearch). Auf dieses Steuerelement wird in den Teilen 3 und 4 dieser Blogreihe ausführlich eingegangen. Vorerst beschränken wir uns darauf, zu erläutern, was es leisten kann, ohne jedoch auf seine Funktionsweise einzugehen:

Eine Steuerungsebene kann Absichten erkennen, Geschäftsrichtlinien anwenden und die entsprechende Abrufstrategie wie folgt sicherstellen:

1. Absichtssignale erkennen

• Ist diese Abfrage wahrscheinlich Navigation oder Entdeckung?

• Handelt es sich um eine bekannte Head-Abfrage (Milch, Brot, Bananen)?

• Gibt es eine bekannte Interpretation für ein Produkt, eine Marke oder eine Kategorie (beispielsweise sollte „Orangen“ zu „Frischwaren“ führen)?

• Ist die Abfrage ein SKU-ähnliches Muster?

• Fällt die Abfrage unter eine aktive Kampagne oder eine saisonale Richtlinie (beispielsweise während der Weihnachtszeit, um Suchergebnisse zum Thema Truthahn stärker hervorzuheben)?

• Impliziert die Abfrage Einschränkungen (Kategorie, Attribute, Ausschlüsse, Preis/Größe/Farbe)?

2. Setzen Sie Governance- und Geschäftsrichtlinien um.

• Wenden Sie zunächst deterministische Einschränkungen an (Kategorie/Attribut/Negation/Verfügbarkeit).

• Wenden Sie aktive Merchandising-Maßnahmen an (hervorheben/verbergen/fixieren/überschreiben).

• Lösen Sie Konflikte mithilfe von Prioritätsregeln (z. B. Kampagnen-Überschreibungen gegenüber globalen Richtlinien).

3. Weg zur geeigneten Abrufstrategie

• Lexikalisch (schnell, deterministisch) für navigationsorientierte Suchanfragen mit hoher Kaufabsicht.

• Semantische Suche für echte Entdeckungsanfragen.

• Ein hybrider Ansatz, bei dem kombinierte lexikalische und semantische Signale unter expliziten geschäftlichen Vorgaben einen Mehrwert schaffen.

In der Praxis ist der Ausgang der Steuerungsebene nicht einfach „Hybrid verwenden“ oder „Semantik verwenden“. Es handelt sich um einen geregelten Abrufplan: eine Interpretation der Absicht des Kunden, der geltenden Einschränkungen und Richtlinien sowie der auszuführenden Abrufstrategie. Ein paar einfache Beispiele verdeutlichen dies:

Kundenabfrage

Gesteuerte Interpretation

Beispiel-Abrufplan

„Schokolade ohne Erdnüsse“

Produktorientierte Abfrage mit einer strengen Ausschlussbedingung

Lexikalische Suche nach „Schokolade“ sowie ein Ausschlussfilter für Produkte, die Erdnüsse enthalten

„billiges Olivenöl“

Produkt-/Kategorie-Abfrage mit einer Preisbeschränkung

Lexikalischer Abruf für Olivenöl plus ein Preisfilter, der auf den Schwellenwert des Einzelhändlers für „günstig“ begrenzt ist

„Obst reich an Vitamin C unter 4 $“

Discovery-Abfrage, die semantisches Verständnis sowie strikte Einschränkungen erfordert

Semantische Suche nach Produkten für Ernährungszwecke, beschränkt auf die Kategorie „Obst“ und gefiltert nach Produkten mit einem Preis unter 4 $

Eine Steuerungsebene wählt für jede Abfrage konsistent, vorhersehbar und in großem Maßstab die richtige Richtlinie und Abrufstrategie aus. Dies macht fortgeschrittene Abrufmethoden in der Produktion vorhersehbarer, da absichtsbasierte Einschränkungen zuerst durchgesetzt werden und Routing-Entscheidungen explizit statt implizit getroffen werden.

Wie dies mit anderen Ansätzen zusammenhängt

Einige Teams nutzen verbesserte Einbettungsmodelle, um die Produktsemantik besser zu erfassen, was die Qualität der semantischen Suche erheblich verbessern kann. Andere nutzen Ansätze zur Neureihenfolge, wie beispielsweise Learning To Rank (LTR), um die Reihenfolge der Ergebnisse nach der Abfrage auf der Grundlage von Interaktions- oder geschäftsbezogenen Signalen zu optimieren. Beide sind wertvoll und ergänzen sich oft. Bessere Einbettungen verbessern den Ähnlichkeitsabgleich. Durch die Neubewertung wird die Reihenfolge der abgerufenen Kandidaten verbessert.

Governance befasst sich mit einer anderen Ebene des Problems: Sie ist dem Abrufprozess vorgelagert. Es entscheidet, welche Abrufstrategie verwendet wird (zum Beispiel lexikalisch, semantisch oder hybrid), welche deterministischen Einschränkungen erforderlich sind und welche Abfragen mehrere Geschäftsrichtlinien kombinieren sollten.

Was eine gesteuerte Steuerungsebene ermöglicht

Sobald eine Governance-Ebene eingerichtet ist, verändert sich das Betriebsmodell grundlegend. Umsatzrelevante Abfragen lassen sich vorhersagen. Geschäftsteams können das Suchverhalten anpassen, ohne auf die Release-Zyklen der Entwickler warten zu müssen. Und fortgeschrittene Abrufmethoden, wie semantische und hybride Verfahren, können schrittweise eingeführt werden – im Rahmen von Routing-Regeln und Sicherheitsvorkehrungen – anstatt als globaler Ein-/Aus-Schalter.

Der nächste Beitrag dieser Reihe befasst sich damit, wie dieses Betriebsmodell in der Praxis aussieht und warum es möglicherweise genauso wichtig ist wie die ihm zugrunde liegende Suchtechnologie.

Wenn ein Merchandiser ein Jira-Ticket erstellen und auf eine Bereitstellung warten muss, um eine umsatzkritische Abfrage zu beheben, liegt der Engpass nicht in der Engine, sondern im Betriebsmodell. Eine moderne E-Commerce-Suche muss in der Lage sein, geschäftliche Absichten schnell und sicher in kontrolliertes, überprüfbares Suchverhalten umzusetzen, dabei aber weiterhin auf erweiterte Suchfunktionen zurückzugreifen, wo diese einen messbaren Mehrwert bieten.

Wie geht es weiter in dieser Serie?

Die in dieser Reihe behandelten Muster greifen bereits vor der Abfrage an: Sie dienen dazu, geschäftliche Absichten in die richtige Abfragestrategie umzusetzen, noch bevor die Abfrage generiert wird. Im nächsten Beitrag wechseln wir vom technischen zum operativen Problem: Was passiert, wenn Geschäftsteams das Suchverhalten ohne ein technisches Deployment ändern können, und warum Governance das sicher macht?

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

Technische Engpässe, instabile Logik auf Anwendungsebene und unvorhersehbare Suchergebnisse sind Probleme, bei deren Lösung Ihnen Elastic Services im Rahmen von E-Commerce-Projekten für Unternehmen behilflich sein kann. Die in dieser Reihe beschriebene Architektur der verwalteten Steuerungsebene wurde von Elastic Services Engineering entwickelt.

Wenn Ihr Team Entwicklungsressourcen darauf verwendet, Merchandising-Anforderungen in Codeänderungen umzusetzen, oder wenn Ihr Rückstand bei der Suchrelevanz scheinbar nie abnimmt, können wir Ihnen dabei helfen, Ihre aktuelle Architektur zu bewerten und einen Weg zu einer kontrollierten, vom Geschäftsteam editierbaren Suche zu ebnen. Kontaktieren Sie Elastic 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.