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.

Der Inhalt dieses Blogbeitrags wurde mit den Elastic-Versionen 9.2.8 und 8.19.14 sowie den Filestream Integration Versionen 2.3.0 und 1.2.0 entwickelt und verifiziert.

Wichtiger Hinweis: Je nach Umgebung sind für einige Schritte spezielle Anpassungen erforderlich. Beachten Sie außerdem, dass dynamische Vorlagen ab Filestream Integration Version 2.3.3 aus der @package-Komponentenvorlage entfernt wurden.

Bevor Sie mit dem Reindexierungsprozess beginnen, ist es wichtig, die aktuelle Speicherzuweisung in Ihrer Umgebung zu berücksichtigen. Die unten beschriebenen Schritte beinhalten das Erstellen einer Kopie des bestehenden Backing-Index, der vorübergehend im hot Tier liegt.

Elasticsearch-Datenebenen

• Heiß: Die heiße Ebene ist der Einstiegspunkt von Elasticsearch für Zeitreihendaten, in der die aktuellsten und am häufigsten durchsuchten Daten gespeichert werden. Nodes der heißen Ebene erfordern schnelle Lese- und Schreibvorgänge, also mehr Ressourcen und schnelleren Speicher (SSDs). Diese Ebene ist obligatorisch und neue Datenstromindizes werden ihr automatisch zugeordnet.

• Warm: Zeitreihendaten können in die warme Ebene verschoben werden, sobald sie seltener abgefragt werden als die kürzlich indizierten Daten in der heißen Ebene. Die warme Ebene enthält in der Regel Daten der letzten Wochen. Aktualisierungen sind weiterhin erlaubt, aber wahrscheinlich selten. Die Nodes in der warmen Ebene müssen im Allgemeinen nicht so schnell sein wie die in der heißen Ebene. Für die Ausfallsicherheit sollten Indizes in der warmen Ebene so konfiguriert werden, dass sie eine oder mehrere Replikate verwenden.

• Kalt: Daten, die nur selten durchsucht werden, können von der warmen in die kalte Ebene verschoben werden. Die kalte Ebene ist zwar immer noch durchsuchbar, aber die geringeren Speicherkosten haben Vorrang vor der Suchgeschwindigkeit. Alternativ kann die kalte Ebene reguläre Indizes mit Replikaten anstelle von durchsuchbaren Snapshots speichern, wodurch für ältere Daten kostengünstigere Hardware verwendet werden kann, ohne dass der Festplattenspeicherbedarf im Vergleich zur warmen Ebene reduziert wird.

• Eingefroren: Daten, die nur selten oder gar nicht mehr abgefragt werden, werden für den Rest ihres Lebenszyklus von der Kategorie „Kalt“ in die Kategorie „Eingefroren“ verschoben. Diese Ebene nutzt ein Snapshot-Repository und teilweise eingebundene Indizes zum Speichern und Laden von Daten, wodurch der lokale Speicherplatz und die Kosten reduziert werden, während die Suche weiterhin möglich ist. Suchvorgänge auf der eingefrorenen Ebene sind im Allgemeinen langsamer als auf der kalten Ebene, da Elasticsearch möglicherweise eingefrorene Daten aus dem Snapshot-Repository abrufen muss. Wir empfehlen dedizierte Nodes für die eingefrorene Ebene.

Voraussetzungen: Ermitteln Sie, welche Felder Konflikte aufweisen

Um festzustellen, welche Felder Mapping-Konflikte aufweisen, navigieren Sie zu Stack Management –> Data Views –> Logs-* (die Verwendung der Data View Logs- ist die höchste Hierarchie der vorhandenen Daten mit dem Präfix Logs-.) Sollten Konflikte auftreten, wird dies in einem gelben Feld vermerkt. Sie können entweder auf Konflikte anzeigen klicken, oder unter dem Feld Feldtyp neben dem Suchfeld die Option Konflikt auswählen.

Wenn Sie auf die gelbe Schaltfläche Konflikt klicken, wird angezeigt, welche Indizes mit welchen Mapping-Typen verknüpft sind.

Diese Situation (in der das Feld sowohl als keyword als auch als long zugeordnet ist) tritt normalerweise auf, weil Daten ingestiert wurden, bevor ein spezifischer Mapping-Typ im Komponenten-Template für den relevanten Datenstrom definiert wurde. In solchen Fällen versucht Elasticsearch, das Mapping auf Basis seiner dynamischen Vorlagen festzulegen.

Um festzustellen, welches Mapping für das Feld geeignet ist und ob es sich um ein ECS-Feld handelt, ist eine Verifizierung mit ECS-Feldreferenz erforderlich. Wenn das betreffende Feld kein ECS-Feld ist, muss sein Wert überprüft werden, um das korrekte Mapping zu bestimmen.

Wenn ein Feld, wie log.offset in diesem Beispiel, im ECS nicht dokumentiert ist, bestehen die nächsten Schritte darin, den Feldwert zu untersuchen, den widersprüchlichen Mapping-Typ mit den meisten Backing-Indizes zu bestimmen und die Komponentenvorlagen der anderen Indizes zu prüfen.

In der Regel ist der Mapping-Typ mit der höchsten Anzahl an Indizes der richtige. Wir empfehlen Ihnen jedoch, den Wert des betreffenden Feldes zu überprüfen, um dies zu bestätigen. Um die Gültigkeit eines Mapping-Typs (zum Beispiel long) zu bestätigen, müssen Sie außerdem überprüfen, ob der Wert des Feldes für diesen Typ angemessen ist. Diese Verifizierung kann erfolgen, indem Sie Discover verwenden, um nach dem betreffenden Feld zu suchen. Die Überprüfung anderer Datenströme, die dasselbe Feld enthalten, kann ebenfalls zusätzliche Bestätigungen liefern.

Um die Werte für das Feld mit dem Mapping-Konflikt zu überprüfen, navigieren Sie zurück zu der bereits erwähnten gelben Schaltfläche Konflikt, klicken auf die Schaltfläche Konflikt, markieren einen der Backing-Indizes und fügen ihn in eine Discover-Sitzung ein. Die Anweisung Ihrer Kibana-Abfragesprache (KQL) sollte wie der folgende Screenshot aussehen, um den Feldbegrenzer _index: einzuschließen.

Bereiten Sie die neue benutzerdefinierte Komponentenvorlage für den Backing-Index vor

Um den Mapping-Konflikt im Datenstrom zu beheben, untersuchen Sie zuerst die relevante @package-Komponentenvorlage. Sie finden diese unter Stack Management -> Index Management -> Component Template. Suchen Sie nach dem Datenstrom und wählen Sie den entsprechenden @package Link aus. Diese Vorlage enthält grundlegend Mappings für die Felder, denn selbst wenn ein Mapping-Konflikt nicht häufig vorkommt, kann der passendere Typ leicht übersehen werden.

Überprüfen Sie die Vorlage, um sicherzustellen, dass sie die notwendige Feldverschachtelung und das Mapping für das betreffende Feld enthält. Wenn zum Beispiel die Vorlage log.offset fälschlicherweise als keyword angibt, ist dies die Ursache des Problems.

Wichtig: Da das Ändern von @package/Managed-Vorlagen nicht empfohlen wird, müssen Sie eine @custom-Komponentenvorlage verwenden oder erstellen, um den Mapping-Typ (zum Beispiel log.offset) für alle zukünftigen Daten zu korrigieren.

• Wir empfehlen nicht, die @package/Managed-Vorlagen zu ändern, da beim Aktualisieren der Integration auf eine neuere Version alle Änderungen, die Sie an der @package-Vorlage vornehmen, überschrieben werden. Deshalb empfehlen wir die Verwendung der @custom-Vorlagen.

• Wenn ein Datenstrom Mapping-Konflikte aufweist, müssen Sie alle fehlenden Feld-Nestings (ECS und Nicht-ECS) oder Mappings zur @custom Komponentenvorlage des Datenstroms hinzufügen. Erstellen Sie diese Vorlage, falls sie noch nicht existiert, und stellen Sie sicher, dass Sie den korrekten Mapping-Typ für das Feld angeben.

• Wenn mehrere Konflikte in Ihrer Datenquelle vorliegen, wenden Sie alle erforderlichen fehlenden Mappings für den Datenstrom gleichzeitig an, damit die Neuindizierung einmal statt mehrmals durchgeführt wird. Einträge für die korrekte Datentypisierung in der @custom-Komponentenvorlage stellen sicher, dass jede zukünftige Daten-Ingestion der gleichen Mapping-Richtlinie folgt.

Um die @custom-Komponentenvorlage zu erstellen (oder zu überprüfen, ob sie verwendet und ausgefüllt ist), navigieren Sie zu Index Templates, geben den Namen des betreffenden Datenstroms ein und klicken auf die entsprechende @custom-Vorlage, die vom Datenstrom verwendet wird. Falls die Vorlage noch nicht erstellt wurde, erscheint ein gelbes Feld, über das Sie die Vorlage mithilfe der Benutzeroberfläche erstellen können.

Der untenstehende Screenshot zeigt die nächste Seite, sobald die Create Component Vorlage ausgewählt ist. Lassen Sie die Standardwerte auf der ersten Seite unverändert und klicken Sie auf Mappings oder Weiter, bis Sie die Mappings-Seite erreichen.

Um das Mapping für ein neu eingehendes Feld explizit festzulegen oder ein Feld zu aktualisieren, bei dem ein Mapping-Konflikt besteht, wenn der Datenstrom aufgrund einer in der Indexlebenszyklusrichtlinie festgelegten Konfiguration überschrieben wird, ist ein Eintrag für das Feld erforderlich, in dem der Konflikt besteht.

Im Folgenden wird das Mapping für das Feld log.offset in der Komponentenvorlage @custom für den Filestream-Datenstrom festgelegt. Wiederholen Sie die Schritte, um gegebenenfalls benutzerdefinierte Felder hinzuzufügen oder notwendige Felder aus dem @package mit den entsprechenden Mappings für diesen Datensatz zu aktualisieren. In diesem Beispiel ist bei der Einstellung des Offsets auf Long der Feldtyp Numeric und der numerische Typ Long. Klicken Sie auf Feld hinzufügen und dann außerhalb des Bereichs, um fortzufahren.

Sobald alle benötigten Felder hinzugefügt wurden, gehen Sie sie zum Überprüfen durch und wählen Sie Komponenten-Vorlage erstellen, wenn Sie bereit sind. Alle neuen Daten, die ab diesem Schritt importiert werden, haben log.offset auf long gesetzt.

Erstellung der neuen Backing-Index-Struktur

Der neue Backing-Index muss die vorhandenen Mappings aus der Komponentenvorlage des Datenstroms sowie der ECS- ecs@mappings-Komponentenvorlage enthalten. Die ecs@mappings-Komponentenvorlage wird nach der Komponente des Datenstroms als Auffangbecken für zusätzliche Mappings angewendet, die möglicherweise in den vorherigen Komponentenvorlagen nicht erfasst wurden.

Navigieren Sie zum Browser-Tab für die @package Mappings des Datenstreams. (Gehen Sie zu Stack Management -> Index Management -> Component Template -> logs-filestream.generic@package -> Verwalten -> Bearbeiten.) Dort klicken Sie dann auf den Abschnitt Überprüfen , dann auf Anfrage und schließlich auf die Schaltfläche Kopieren rechts. Der JSON-Inhalt der kopierten Komponentenvorlage stellt sicher, dass die verbleibenden Feld-Mappings und Einstellungen erhalten bleiben, während wir das log.offset Feld-Mapping aktualisieren. Das JSON bildet die Basisstruktur für den neu indizierten Basisindex.

Wichtig: Wenn das JSON der Vorlage nicht kopiert wurde und die Arbeit mit der Neuindizierung fortgesetzt wurde, würde der log.offset-Konflikt gelöst werden, es würden jedoch neue Konflikte mit der Integration entstehen, da die Integrität der aktuellen Mappings nicht aufrechterhalten wurde, was doppelte Arbeit zur Lösung des ursprünglichen Problems nach sich zieht.

Öffnen Sie einen zweiten Tab im Browser, wechseln Sie zu Dev Tools und fügen Sie den kopierten Inhalt ein. Nun muss das Eingefügte entfernt werden:

Änderungen an der Anfrage

1. Indexname: Ersetzen Sie _component_template/logs-filestream.generic@package durch den Namen des Backing-Indexes, den Sie neu indizieren möchten, und fügen Sie -1 am Ende an. Verwenden Sie zum Beispiel PUT <backing index to reindex>-1.

• Das angehängte -1 steht für eine Neuindizierung und steht nicht in Konflikt mit den Standard-ILM-Rollover-Einstellungen, die auf dem Erstellungsdatum des Index basieren.

2. Einstellungen: Entfernen Sie die Zeile "template" (Zeile 3) sowie die allerletzte schließende Klammer für die gesamte JSON-Nutzlast. Zeile 3 sollte mit "settings": { beginnen.

• Ersetzen Sie den Inhalt des Abschnitts „Einstellungen“ durch "index.codec": "best_compression". Diese Aktion wendet die beste Kompression von Elastic auf den Index bei der Erstellung an.

• Fügen Sie "index.lifecycle.name": "logs" sowie eine Zeile für "index.lifecycle.rollover_alias": "" hinzu.

  1. Der Eintrag "index.lifecycle.name": "logs" wendet die ILM-Richtlinie für Logs auf den neuen zugrunde liegenden Index an. Ändern Sie den Namen der ILM-Richtlinie, wenn Sie keine Logs verwenden.

  2. Der "index.lifecycle.rollover_alias": "" ist leer, da dieser Backing-Index nicht übertragen wird, aber die Einstellung ist erforderlich, um ILM-Rollover-Fehler in die nächste ILM-Phase nach der heißen Ebene zu vermeiden.

3. Struktur: Die Anfrage sollte nun sowohl einen Settings-Abschnitt als auch einen Mappings-Abschnitt enthalten. Innerhalb von "mappings": { sollten Sie "dynamic_templates" und einen "properties" Abschnitt finden, der fest codierte Felder und deren Mappings enthält.

4. Änderung dynamischer Vorlagen: Der aktuelle Abschnitt für dynamische Vorlagen enthält Einträge für Felder, die überschrieben werden können, wenn die nächsten ecs@mappings dynamischen Vorlagen hinzugefügt werden, was Redundanz und zusätzliche Zeilen verursacht, die nicht benötigt werden.

• Entfernen Sie alle Abschnitte in "dynamic_templates" außer dem zweiten Abschnitt mit dem Titel "_embedded_ecs-data_stream_to_constant": {.

• Wiederholen Sie den gleichen Vorgang wie oben beschrieben, indem Sie die dynamischen Mappings für die @package-Komponentenvorlage sammeln, aber diesmal die dynamischen Mappings für die ecs@mappings-Komponentenvorlage.

  • Es kann einfacher sein, den gesamten Inhalt der Mappings aus der Benutzeroberfläche für die ecs@mappings-Komponentenvorlage zu kopieren, in den Arbeitsbereich des Dev-Tools- dynamic_templates-Abschnitts einzufügen und doppelte und unnötige Zeilen entsprechend zu entfernen. Fügen Sie diese dynamischen Template-Einstellungsinhalte nach dem"_embedded_ecs-data_stream_to_constant": {-Eintrag ein. Der Abschnitt dynamic_templates sollte den untenstehenden Beispielinhalten in den Dev-Tools sehr entsprechen.

• Wenn dynamic_templates nicht einbezogen oder vollständig entfernt werden, haben andere Felder (siehe untenstehenden Screenshot) doppelte Mappings: text und keyword im Vergleich zu den entsprechenden Mappings, falls der Abschnitt dynamic_templates enthalten geblieben wäre. Was übrig bleibt, sollte der Abschnitt "properties" unter "mappings" sein. Dies wird auch Probleme in der Datenquelle verursachen, da die Felder doppelt zugeordnet werden (falls sie nicht bereits auf diese Weise zugeordnet sind) und zusätzliche Mapping-Konflikte verursachen.

5. Metadaten-Entfernung: Löschen Sie den letzten Abschnitt mit der Bezeichnung "_meta", sowie den Abschnitt mit der Bezeichnung "version", falls vorhanden.

6. Formatierung: Die verbleibenden Abschnitte automatisch einrücken und unnötige geschweifte Klammern anpassen oder entfernen, die eine erfolgreiche Ausführung verhindern würden.

7. Mapping-Änderung: Navigieren Sie zum Abschnitt "properties", suchen Sie "log" und dann "offset", das darunter verschachtelt ist. Ändern Sie den Typ von keyword zu long und entfernen Sie den Zeileneintrag (inklusive Komma) mit der Bezeichnung "ignore_above": 1024,. Wenn mehr als ein Eintrag zur zuvor erstellten @custom Komponentenvorlage hinzugefügt wurde, fügen Sie diesen hier hinzu.

Ihre Dev Tools-Konsolenansicht sollte jetzt dem unten angegebenen Beispiel entsprechen.

Wenn Ihre Konsole dem Beispiel entspricht (mit allen zusätzlichen benutzerdefinierten Feldern und benutzerspezifischen Werten für Ihre Umgebung), führen Sie den Befehl aus, um das Gerüst des neuen Backing-Index zu erstellen. Pausieren Sie, wenn auftretende Fehler behoben werden müssen.

Neuindizierung beginnen

Wenn das Gerüst des neuen Backing-Index erfolgreich erstellt wurde, besteht der nächste Schritt darin, neu zu indizieren und die Mapping-Konflikte zu lösen.

Wichtig: Wenn der Backing-Index, der den Mapping-Konflikt aufweist, der aktuellste Index ist und der aktuelle Schreibindex (zum Beispiel ist die Endzahl des Backing-Index -000001), muss der Datenstrom übertragen werden. Das Übertragen des Datenstroms ist erforderlich, da der aktuelle Schreibindex, in den Dokumente eingespeist werden, ein Live-Backing-Index ist und nicht modifiziert werden kann.

Mit dem korrekten Feld-Mapping, das nun über die zuvor erstellte @custom Komponentenvorlage auf den neueren Schreibindex angewendet wird, spiegeln alle neuen Dokumente diese Änderung wider.

Dies wird durch Ausführen des Folgenden erreicht:

Zum Beispiel:

Die Neuindizierung beinhaltet das Kopieren der Daten aus einem bestehenden Backing-Index in einen neuen innerhalb derselben Namenskonvention, normalerweise um notwendige Änderungen vorzunehmen. Diese Änderungen könnten Aktualisierungen einer Komponentenvorlage oder das Hinzufügen einer neuen Ingest-Pipeline für die zu verarbeitenden Daten beinhalten.

Als Nächstes werden die Daten aus dem Backing-Index mit den falschen Mappings in einen neuen Backing-Index kopiert. Der ursprüngliche Backing-Index wird überschrieben, sodass keine neuen Dokumente mehr hinzugefügt werden können. Der neue Backing-Index folgt derselben Namenskonvention, die die Datentransparenz und -integrität bei Anwendung der korrekten ILM-Richtlinie bewahrt, aber ein -1-Suffix enthält, das anzeigt, dass er neu indexiert wurde.

Passen Sie die Indexnamen nach Bedarf an und fügen Sie den folgenden Code in die Konsole ein. Indem Sie wait_for_completion=false einbeziehen, können Sie den Fortschritt des Dokumentenkopierens verfolgen, was hilft, die verbleibende Reindexierungszeit abzuschätzen. Ohne diese Einstellung können Sie den Status nicht mit dem untenstehenden Befehl GET _tasks verfolgen und nur die Dokumentenanzahl im neueren Backing-Index mit GET <backing index name>-1/_count überprüfen.

Wichtig: Wenn während der Neuindizierung Probleme auftreten, führen Sie den Befehl Neuindizierung nicht erneut aus. Dadurch wird der Prozess neu gestartet und doppelte Einträge im Index mit -1 erstellt. Wenn ein Neustart notwendig ist, löschen Sie zunächst den Index mit dem nachlaufenden -1 und führen Sie dann den vorherigen PUT-Befehl aus, um das neue Backing-Index-Gerüst zu erstellen.

Nach der Ausführung enthält die Reaktion eine Aufgaben-ID. Sie können den Fortschritt der Neuindizierung mit dieser ID mit dem Befehl GET _tasks/<task ID> überwachen.

Die Dauer der Neuindizierung hängt vom Datenvolumen im ursprünglichen Index ab. Die Verarbeitung verfolgen Sie, indem Sie bei der Ausführung des Befehls GET nach "completed": true suchen, was zu einer ähnlichen Ausgabe führen sollte.

GET _tasks/<task ID>

Die Neuindizierung für die Dokumentenzählung ist nun abgeschlossen. Der nächste Schritt besteht darin, zu überprüfen, ob die Mappings für den neuen Backing-Index und das betreffende Feld korrekt sind.

Zum Beispiel:

Sie können überprüfen, ob das Mapping für log.offset wie unten dargestellt aussieht. Um zu bestätigen, dass andere Felder nur einen einzigen Mapping-Eintrag haben (nicht sowohl text als auch keyword), vergleichen Sie sie mit einem Feld, das nicht Teil des dynamischen Template-Abschnitts im vorherigen PUT-Befehl war.

Wenn der neu indizierte Backing-Index eine große Anzahl von Dokumenten enthält, ist es hilfreich, den Status der Dokumente zu überprüfen, die in den neuen Backing-Index kopiert werden. Dies kann mit den folgenden beiden Dev Tools-Befehlen zum Vergleich der Zählungen erfolgen.

GET .ds-logs-filestream.generic-default-2026.04.14-000001/_count

GET .ds-logs-filestream.generic-default-2026.04.14-000001-1/_count

Sobald die Zählungen als übereinstimmend verifiziert wurden und die korrekten Mappings vorhanden sind, aktualisieren Sie den Datenstrom, um den neuen zugrunde liegenden Index zu integrieren. Dadurch wird verhindert, dass ein verwaister zugrunde liegender Index in der Indexverwaltung entsteht, bei dem die ILM-Richtlinie niemals auf den zugrunde liegenden Index angewendet wird.

• Die Rückgabe sollte im Erfolgsfall eine Bestätigung von true sein.

Überprüfen Sie mit folgendem Befehl, ob der neue Backing-Index hinzugefügt wurde und ob die ilm_policy korrekt ist:

Überprüfen Sie als Nächstes den ILM-Status des Backing-Index mit folgendem Befehl:

• Es ist normal, dass der Index als heiß angezeigt wird, da er gerade erst erstellt wurde (überprüfen Sie Zeile 8 oder 10).

Führen Sie Folgendes aus, um den Backing-Index von der heißen Ebene auf die nächste geeignete Ebene zu übertragen, die nach der heißen Ebene für die ILM-Richtlinie für diesen Datenstrom liegt. Die spezifischen Werte für phase, action und name in den folgenden current_step können in den Zeilen 11, 13 und 15 im obigen Screenshot nachgeschlagen werden.

Der next_step-Wert gibt die anschließende ILM-Phase oder Datenebene an, zu der der Index übergeht.

Zum Beispiel:

• Es ist nicht zwingend notwendig, aber als Sicherheitsmaßnahme können Sie den Befehl _ilm/explain erneut ausführen, um sicherzustellen, dass sich der Backing-Index in die nächste Phase verschoben hat und sich nicht mehr in der heißen Phase befindet.

Sobald die folgenden Bedingungen erfüllt sind, können Sie den ursprünglichen Backing-Index, der Mapping-Konflikte aufwies, sicher löschen:

1. Ein neuer Backing-Index wurde erfolgreich erstellt.

2. Dokumente wurden in den neuen Index verschoben, und die Dokumentanzahlen stimmen überein.

3. Die Mappings wurden korrigiert (sowohl datenstromspezifisch als auch ECS-spezifisch).

4. Der Datenstrom beinhaltet den neuen Backing-Index.

5. Die ILM-Richtlinie wurde angewendet und der Index hat die heiße Phase überwunden.

Wichtig: Alternativ können Sie vor dem Löschen des ursprünglichen Index die Seite Data Views überprüfen. Wählen Sie logs-* aus und überprüfen Sie, dass der neuindizierte Backing-Index (der auf -1endet) nun im Abschnitt long erscheint. Der ursprüngliche Backing-Index sollte unter keywordnoch vorhanden sein. Wenn der neuindizierte Backing-Index nicht im long-Abschnitt enthalten ist, gehen Sie zurück, überprüfen die vorherigen Schritte und nehmen gegebenenfalls Korrekturen vor.

Zum Beispiel:

Nachdem Sie die Konflikte gelöst haben, kehren Sie zur Seite Data Views zurück und wählen Sie logs-* aus. Wenn der Konflikt ausschließlich mit log.offset zusammenhängt, sollten keine Konflikte mehr aufgeführt sein. Wenn es weitere Konflikte gab, sollte der ursprüngliche Backing-Index nicht mehr in der Konfliktliste erscheinen. Stattdessen sollte der neue Backing-Index nun im Abschnitt long aufgeführt werden.

Sie können auch in Discover überprüfen, ob das log.offset-Feld jetzt die entsprechenden Symbole anzeigt.

Führen Sie diesen Prozess fort, indem Sie die obigen Schritte für jeden Backing-Index wiederholen, der einen Mapping-Konflikt aufweist, bis alle erfolgreich gelöst sind.

Referenzen:

• Referenz zu den ECS-Feldern

• Dokumente neu indexieren

Fazit

Indem Sie die Schritte in diesem Blog befolgen, lösen Sie Mapping-Konflikte und stellen sicher, dass alle neuen Daten korrekt zugeordnet sind. Dafür verknüpfen Sie die erforderlichen Komponentenvorlagen mit Ihrer Datenquelle. Dieser Workflow behebt nicht nur die unmittelbaren Probleme, sondern etabliert auch einen sicheren und wiederholbaren Prozess zur Verwaltung von Schemaänderungen, während sich Ihre Daten und Anforderungen weiterentwickeln.

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.

Wir haben ein umfassendes Infrastruktur-Upgrade für alle Elastic Cloud Serverless-Projekte abgeschlossen, die auf AWS laufen und auf neuere, schnellere Hardware migriert wurden. Diese Änderung wurde automatisch auf alle Serverless-Projekte ausgerollt. Es bietet einen höheren Durchsatz und geringere Latenz für Serverless-Projekte mit Elasticsearch, Elastic Observability und Elastic Security auf AWS.

Wichtigste Leistungsvorteile für Entwickler:innen

Die neue AWS-Hardwareinfrastruktur bildet die Grundlage für alles, was Sie mit Elastic Cloud Serverless tun, und führt zu spürbaren Vorteilen hinsichtlich der Geschwindigkeit und Reaktionsfähigkeit Ihrer Anwendungen.

Reduzierte Abfragelatenz … erhöhter Durchsatz

Die verbesserte Hardware steigert die Geschwindigkeit der Rechenressourcen erheblich, sodass Ihre Suchanfragen schneller als je zuvor verarbeitet werden.

• Suchen und Vektorsuche: Egal, ob Sie traditionelle Volltextabfragen durchführen oder modernste Vektorsuche für Ihre generative KI- und Retrieval-Augmented-Generation (RAG)-Anwendungen verwenden – Sie werden eine deutliche Verringerung der Latenzzeit feststellen. Interne Benchmarkings zeigten einen durchschnittlichen Rückgang der Suchlatenz um 35 %.

• Schnellere Indexierung: Die Ingestion-Raten sind optimiert, sodass Sie riesige Datenmengen und komplexe Dokumente mit erhöhtem Durchsatz indexieren können. Das ist besonders wichtig für Anwendungen, die Daten nahezu in Echtzeit anzeigen müssen. Interne Benchmarkings zeigten einen durchschnittlichen Anstieg des Indexierungsdurchsatzes um 26 %.

Konstante Leistung unter Last

Elastic Cloud Serverless ist so konzipiert, dass es sich dynamisch in Echtzeit an die Nachfrage anpasst und die Latenz minimiert, unabhängig von Ihrer Arbeitslast. Mit diesem Hardware-Upgrade ist das Skalieren nun leistungsfähiger und reaktionsschneller.

• Problemloser Umgang mit Spitzen: Egal, ob Sie mit einem plötzlichen Anstieg des Nutzerverkehrs oder einem massiven Batch-Ingest konfrontiert sind – die neue Infrastruktur stellt sicher, dass Ihre Such- und Indexierungsressourcen effizienter skaliert werden, um eine gleichbleibend niedrige Latenz zu gewährleisten.

• Optimierte Entkopplung von Rechenleistung und Speicher: Die Serverless-Architektur trennt Rechenleistung und Speicher, wodurch Workloads unabhängig voneinander skaliert werden können, um optimale Leistung und Kosteneffizienz zu gewährleisten. Die schnellere Hardware verbessert die Computerschicht und maximiert die Effizienz dieses entkoppelten Designs.

Hinter den Kulissen: Ergebnisse interner Benchmarks

Um die Auswirkungen unseres AWS-Infrastruktur-Upgrades zu quantifizieren, führte das Elastic-Engineering-Team ein umfassendes internes Benchmarking mit einer Reihe von Serverless-Workloads durch. Diese Workloads lieferten empirische Beweise für Leistungsverbesserungen, die Sie in Ihren Anwendungen erwarten können, unabhängig von Ihrem Anwendungsfall.

Der Benchmarking-Ansatz

Wir konzentrierten unsere Tests auf die wichtigsten Kennzahlen, die das Entwicklererlebnis und die Anwendungsreaktionsfähigkeit direkt beeinflussen: Reaktionszeit (also Latenz) und Durchsatz bei Such- und Indexierungsoperationen.

• Getestete Arbeitslasten: Die Tests umfassten Suchvorgänge mit hoher Parallelität, wie sie typisch für benutzerorientierte Anwendungen sind, komplexe Vektorsuchanfragen sowie die Erfassung/Indexierung großer Datenmengen für Anwendungsfälle im Bereich Beobachtbarkeit und Sicherheit. Insbesondere nutzte unsere Testmethodik öffentlich verfügbare Datensätze für Rally, das Benchmarking-Tool von Elastic.

  • wikipediaEin Datensatz, der aus einem Snapshot des Wikipedia-Textinhalts abgeleitet wurde, um die allgemeine Textsuchleistung zu messen.

  • MSMARCO-Passage-RankingEin Datensatz, abgeleitet von Microsofts Machine Reading Comprehension (MS MARCO), um die Suchleistung auf spärlichen Vektorfeldern zu messen.

  • OpenAI_Vector: Ein Datensatz, der aus BEIRs NQ abgeleitet und mit Einbettungen angereichert wurde, die vom text-embedding-ada-002-Modell von OpenAI generiert wurden, um die Suchleistung auf dichten Vektorfeldern zu messen.

• Messung: Wir verglichen die Leistung der alten und neuen Infrastruktur und maßen die Latenz im 99. Perzentil (P99), um den Worst-Case, die Tail-Latenz-Performance und die Operationen pro Sekunde zu erfassen. Jeder Track wurde für jedes Hardware-Profil fünfmal ausgeführt, um die Konsistenz der Ergebnisse zu gewährleisten.

• Das Ziel: Unser Ziel war es, die Fähigkeit der Infrastruktur zu validieren, um eine konstant schnellere und vorhersehbarere Leistung zu liefern, selbst in Phasen schneller automatischer Skalierung.

Zusammenfassung der Leistungsdaten

Die Ergebnisse bestätigen deutliche Verbesserungen in Effizienz und Geschwindigkeit. Diese Vorteile schlagen sich direkt in kürzeren Reaktionszeiten für Ihre Benutzer:innen und niedrigeren Betriebskosten nieder, da Sie die gleiche Menge an Arbeit mit weniger Rechenressourcen erledigen können.

Die folgenden Tabellen zeigen die quantitativen Verbesserungen. Höhere Werte sind besser für den Durchsatz; niedrigere Werte sind besser für die Latenz.

Suche nach Benchmark-Ergebnissen:

Benchmark

Vergleich

Alte Infrastruktur

Neue Infrastruktur

Differential

„Wikipedia“ (Klartext)

Durchsatz der Suchvorgänge (Operationen/s)

729

1.107

+52 %

„Wikipedia“ (Klartext)

Latenz der Suchoperation (p99, ms)

56

35

-37 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

22

31

+40 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Latenz der Suchoperation (p99, ms)

108

67

-38 %

`OpenAI_Vector` (dichte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

475

624

+31 %

`OpenAI_Vector` (dichte Vektoren)

Latenz der Suchoperation (p99, ms)

35

22

-37 %

Indexieren der Benchmark-Ergebnisse:

Benchmark

Vergleich

Alte Infrastruktur

Neue Infrastruktur

Differential

„Wikipedia“ (Klartext)

Durchsatz der Suchvorgänge (Operationen/s)

2.845

3220

+13 %

„Wikipedia“ (Klartext)

Latenz der Suchoperation (p99, ms)

1769

1120

-37 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

7.087

8900

+26 %

„MSMARCO-Passage-Ranking“ (dünnbesetzte Vektoren)

Latenz der Suchoperation (p99, ms)

824

677

-18 %

`OpenAI_Vector` (dichte Vektoren)

Durchsatz der Suchvorgänge (Operationen/s)

2.972

3187

+7 %

`OpenAI_Vector` (dichte Vektoren)

Latenz der Suchoperation (p99, ms)

2946

2944

0 %

Der zusätzliche Bonus: Kostenreduzierung

Unser Fokus liegt zwar auf der Bereitstellung einer Performance mit geringer Latenz, aber die Effizienz der neuen Hardware hat auch einen direkten, positiven Einfluss auf die Kosten von Elasticsearch-Projekten.

Die Preisgestaltung von Elasticsearch Serverless basiert auf der Nutzung, das heißt, Sie zahlen nur für die Ingest- und Suchressourcen, die Sie verbrauchen. Da die neuere, schnellere Hardware effizienter ist, werden Ihre Arbeitslasten oft mit weniger Ressourcen erledigt, was bei den meisten Projekten zu einer erheblichen Kostenreduzierung führt. Sie erhalten eine Premium-Leistungssteigerung ohne den Premium-Preis – die Definition von optimierter Effizienz.

Was bedeutet das für Sie als Entwickler:in?

Dieses Infrastruktur-Upgrade wird vollständig von Elastic verwaltet, sodass Sie keinen Finger rühren müssen – keine Migrationen und keine Konfigurationsänderungen. Die Verbesserung erfolgt sofort und automatisch bei all Ihren AWS-basierten Serverless-Projekten.

Dieses Upgrade ermöglicht Ihnen Folgendes:

• Erstellen Sie schnellere Anwendungen: Konzentrieren Sie sich auf die Geschwindigkeit der Features, da Sie wissen, dass Ihre zugrundeliegende Such-Platform die Geschwindigkeit bietet, die Ihre Benutzer:innen erwarten.

• Innovation mit Zuversicht: Stellen Sie neue Such-, Beobachtbarkeits- und Sicherheitsfeatures – einschließlich komplexer KI-Features wie Vektorsuche und Relevanzranking – mit der Gewissheit bereit, dass die Platform die Last mit maximaler Leistung bewältigen kann.

• Vereinfachen Sie Ihren Stack: Nutzen Sie einen vollständig verwalteten Service, der Infrastrukturmanagement, Kapazitätsplanung und Skalierung übernimmt, damit Sie sich auf Ihren Code und Ihre Daten konzentrieren können.

Im letzten Teil dieser Serie haben wir die Bereitstellung des vortrainierten E5-Modells von Elastic (sowie anderer mehrsprachiger Text-Embedding-Modelle von Hugging Face) erläutert und uns mit der Generierung dichter Vektor-Embeddings aus Ihren Textdaten mithilfe von Elasticsearch und Kibana befasst. In diesem Blogbeitrag werden wir die Ergebnisse dieser Einbettungen untersuchen und die wesentlichen Vorteile der Verwendung eines mehrsprachigen Modells hervorheben.

Nachdem wir nun unseren Index coco_multilingual haben, liefert die Suche Dokumente in mehreren Sprachen, wobei das Feld „en“ als Referenz dient:

Eine Suche auf Englisch durchführen

Versuchen wir, die Suche auf Englisch durchzuführen und sehen wir, wie gut sie funktioniert:

Auch wenn die Anfrage täuschend einfach aussieht, suchen wir hier im Hintergrund nach den numerischen Einbettungen des Wortes „Kitty“ in allen Dokumenten und Sprachen. Und weil wir eine Vektorsuche durchführen, können wir semantisch nach allen Wörtern suchen, die mit „Kitty“ verwandt sein könnten: „Katze“, „Kätzchen“, „Katze“, „Gatto“ (Italienisch), „Mèo“ (Vietnamesisch), 고양이 (Koreanisch), 猫 (Chinesisch) usw. Das bedeutet, dass wir, selbst wenn meine Suchanfrage auf Englisch ist, auch Inhalte in allen anderen Sprachen suchen können. Wenn man beispielsweise nach „kitty lying on something sucht, erhält man auch Dokumente in Italienisch, Niederländisch oder Vietnamesisch. Das nenne ich Effizienz!

Suche nach Inhalten in anderen Sprachen

Eine Suche nach dem koreanischen Stichwort „Katze“ („고양이“) liefert ebenfalls aussagekräftige Ergebnisse. Das Spektakuläre daran ist, dass wir in diesem Index nicht einmal Dokumente in koreanischer Sprache haben!

Dies funktioniert, weil das Einbettungsmodell die Bedeutung in einem gemeinsamen semantischen Raum repräsentiert und somit das Auffinden relevanter Bilder auch bei einer Anfrage in einer anderen Sprache als den indizierten Bildunterschriften ermöglicht.

Erhöhung der Relevanz der Suchergebnisse durch hybride Suche und Reranking

Wir freuen uns, dass die entsprechenden Ergebnisse wie erwartet eingetreten sind. In der realen Welt, beispielsweise im E-Commerce oder bei RAG-Anwendungen, bei denen die Ergebnisse auf die 5 bis 10 relevantesten Ergebnisse eingegrenzt werden müssen, können wir ein Rerank-Modell verwenden, um die relevantesten Ergebnisse zu priorisieren.

Eine Suchanfrage wie „Welche Farbe hat die Katze?“ auf Vietnamesisch liefert hier zwar viele Ergebnisse, aber die ersten ein oder zwei Ergebnisse sind möglicherweise nicht die relevantesten.

In allen Ergebnissen wird die Katze oder irgendeine Farbe erwähnt:

Lasst uns das verbessern! Lasst uns das mehrsprachige Rerank-Modell von Cohereintegrieren, um die Argumentation in Bezug auf unsere Frage zu verbessern.

Mit den besten Ergebnissen kann unsere Anwendung nun mit Sicherheit sagen, ob das Kätzchen schwarz oder braun mit Streifen ist. Was hierbei noch interessanter ist: Unsere Vektorsuche hat tatsächlich eine Auslassung in der englischen Bildunterschrift des ursprünglichen Datensatzes aufgedeckt. Es ist in der Lage, die braun gestreifte Katze zu finden, obwohl die englische Referenzübersetzung dieses Detail ausgelassen hat. Das ist die Stärke der Vektorsuche.

Fazit

In diesem Blog haben wir den Nutzen eines mehrsprachigen Einbettungsmodells erläutert und gezeigt, wie man Elasticsearch nutzen kann, um die Modelle zu integrieren, Einbettungen zu generieren und Relevanz und Genauigkeit mit einer hybriden Suche und einem Reranker effektiv zu verbessern. Sie können einen eigenen Cloud-Cluster erstellen , um die mehrsprachige semantische Suche mit unserem sofort einsatzbereiten E5-Modell auf der Sprache und dem Datensatz Ihrer Wahl auszuprobieren.

In einer Welt globaler Nutzer ist die sprachübergreifende Informationswiedergewinnung (CLIR) von entscheidender Bedeutung. Anstatt die Suche auf eine einzige Sprache zu beschränken, ermöglicht CLIR das Auffinden von Informationen in jeder beliebigen Sprache, verbessert so die Benutzerfreundlichkeit und optimiert die Abläufe. Stellen Sie sich einen globalen Markt vor, auf dem E-Commerce-Kunden in ihrer Sprache nach Artikeln suchen können und die passenden Ergebnisse angezeigt werden, ohne dass die Daten vorher lokalisiert werden müssen. Oder, um akademischen Forschern die Möglichkeit zu geben, in ihrer Muttersprache nach wissenschaftlichen Artikeln zu suchen, inklusive aller Nuancen und Komplexitäten, selbst wenn die Quelle in einer anderen Sprache verfasst ist.

Mehrsprachige Text-Embedding-Modelle ermöglichen uns genau das. Einbettungen sind eine Möglichkeit, die Bedeutung von Text als numerische Vektoren darzustellen. Diese Vektoren sind so konzipiert, dass Texte mit ähnlicher Bedeutung in einem hochdimensionalen Raum nahe beieinander liegen. Multilinguale Text-Embedding-Modelle sind speziell dafür entwickelt worden, Wörter und Phrasen mit der gleichen Bedeutung in verschiedenen Sprachen in einen ähnlichen Vektorraum abzubilden.

Modelle wie das Open-Source-Multilingual E5 werden mit riesigen Mengen an Textdaten trainiert, oft unter Verwendung von Techniken wie dem kontrastiven Lernen. Bei diesem Ansatz lernt das Modell, zwischen Textpaaren mit ähnlicher Bedeutung (positive Paare) und solchen mit unähnlicher Bedeutung (negative Paare) zu unterscheiden. Das Modell wird so trainiert, dass die von ihm erzeugten Vektoren so angepasst werden, dass die Ähnlichkeit zwischen positiven Paaren maximiert und die Ähnlichkeit zwischen negativen Paaren minimiert wird. Bei mehrsprachigen Modellen umfassen diese Trainingsdaten Textpaare in verschiedenen Sprachen, die Übersetzungen voneinander sind, wodurch das Modell einen gemeinsamen Repräsentationsraum für mehrere Sprachen erlernen kann. Die resultierenden Einbettungen können dann für verschiedene NLP-Aufgaben verwendet werden, darunter die sprachübergreifende Suche, bei der die Ähnlichkeit zwischen Texteinbettungen genutzt wird, um relevante Dokumente unabhängig von der Sprache der Anfrage zu finden.

Vorteile der mehrsprachigen Vektorsuche

• Nuance: Die Vektorsuche zeichnet sich durch ihre Fähigkeit aus, semantische Bedeutungen zu erfassen und geht über die reine Stichwortsuche hinaus. Dies ist von entscheidender Bedeutung für Aufgaben, die das Verständnis von Kontext und sprachlichen Feinheiten erfordern.

• Sprachübergreifendes Verständnis: Ermöglicht einen effektiven Informationsabruf über verschiedene Sprachen hinweg, selbst wenn die Suchanfrage und die Dokumente unterschiedliches Vokabular verwenden.

• Relevanz: Liefert relevantere Ergebnisse durch Fokussierung auf die konzeptionelle Ähnlichkeit zwischen Suchanfragen und Dokumenten.

Nehmen wir beispielsweise einen akademischen Forscher, der den „Einfluss sozialer Medien auf den politischen Diskurs“ in verschiedenen Ländern untersucht. Mit der Vektorsuche können sie Suchanfragen wie „l'impatto dei social media sul discorso politico“ (Italienisch) oder „ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị“ (Vietnamesisch) eingeben und relevante Artikel auf Englisch, Spanisch oder einer anderen Sprache finden indizierte Sprache. Dies liegt daran, dass die Vektorsuche Artikel identifiziert, die das Konzept des Einflusses sozialer Medien auf die Politik diskutieren, und nicht nur solche, die die exakten Schlüsselwörter enthalten. Dies erweitert und vertieft die Bandbreite ihrer Forschung erheblich.

Erste Schritte

Hier erfahren Sie, wie Sie CLIR mit Elasticsearch einrichten – mit dem E5-Modell, das standardmäßig mitgeliefert wird. Wir verwenden den Open-Source-Datensatz COCO, der Bildunterschriften in mehreren Sprachen enthält, um zwei Arten von Suchanfragen zu visualisieren:

1. Suchanfragen und Suchbegriffe in anderen Sprachen für einen englischen Datensatz, und

2. Abfragen in mehreren Sprachen auf einem Datensatz, der Dokumente in mehreren Sprachen enthält.

Anschließend werden wir die Leistungsfähigkeit der hybriden Suche und des Rerankings nutzen, um die Suchergebnisse noch weiter zu verbessern.

Voraussetzungen

• Python 3.6+

• Elasticsearch 8+

• Elasticsearch Python-Client: pip install elasticsearch

Datensatz

Der COCO-Datensatz ist ein umfangreicher Datensatz zur Untertitelung. Jedes Bild im Datensatz ist in mehreren verschiedenen Sprachen beschriftet, wobei für jede Sprache mehrere Übersetzungen verfügbar sind. Zur Veranschaulichung werden wir jede Übersetzung als einzelnes Dokument indexieren, zusammen mit der ersten verfügbaren englischen Übersetzung als Referenz.

Schritt 1: Laden Sie den mehrsprachigen COCO-Datensatz herunter

Um den Blog zu vereinfachen und das Nachvollziehen zu erleichtern, laden wir hier die ersten 100 Zeilen der Restval-Tabelle mit einem einfachen API-Aufruf in eine lokale JSON-Datei. Alternativ können Sie die Datensätze der HuggingFace-Bibliothek verwenden, um den vollständigen Datensatz oder Teilmengen des Datensatzes zu laden.

Wenn die Daten erfolgreich in eine JSON-Datei geladen wurden, sollte die Ausgabe in etwa so aussehen:

Data successfully downloaded and saved to multilingual_coco_sample.json

Schritt 2: (Elasticsearch starten) und die Daten in Elasticsearch indizieren

a) Starten Sie Ihren lokalen Elasticsearch-Server.

b) Starten Sie den Elasticsearch-Client.

c) Indexdaten

Sobald die Daten indexiert sind, sollte etwa Folgendes angezeigt werden:

Successfully bulk indexed 4840 documents

Indexing complete!

Schritt 3: Das mit E5 trainierte Modell bereitstellen

Navigieren Sie in Kibana zur Seite „Stack-Verwaltung > Trainierte Modelle“ und klicken Sie für das Modell „.multilingual-e5-small_linux-x86_64“ auf „Bereitstellen“ . Option. Dieses E5-Modell ist ein kleines, mehrsprachiges Gerät, das für linux-x86_64 optimiert ist und sofort einsatzbereit ist. Durch Klicken auf „Bereitstellen“ wird ein Bildschirm angezeigt, auf dem Sie die Bereitstellungseinstellungen oder vCPU-Konfigurationen anpassen können. Der Einfachheit halber verwenden wir die Standardoptionen mit der Auswahl adaptiver Ressourcen, wodurch unsere Bereitstellung je nach Nutzung automatisch skaliert wird.

Optional können Sie auch andere Text-Embedding-Modelle verwenden. Um beispielsweise BGE-M3 zu verwenden, können Sie den Eland Python-Client von Elastic verwenden, um das Modell von HuggingFace zu importieren.

Navigieren Sie anschließend zur Seite „Trainierte Modelle“, um das importierte Modell mit den gewünschten Konfigurationen bereitzustellen.

Schritt 4: Vektorisieren oder Einbettungen für die Originaldaten mit dem bereitgestellten Modell erstellen

Um die Einbettungen zu erstellen, müssen wir zunächst eine Ingest-Pipeline erstellen, die es uns ermöglicht, den Text zu nehmen und ihn durch das Inferenz-Texteinbettungsmodell laufen zu lassen. Dies ist über die Benutzeroberfläche von Kibana oder über die API von Elasticsearch möglich.

Um dies über die Kibana-Oberfläche zu tun, klicken Sie nach dem Bereitstellen des trainierten Modells auf die Schaltfläche „Testen “. Dies ermöglicht es Ihnen, die generierten Einbettungen zu testen und eine Vorschau anzuzeigen. Erstellen Sie eine neue Datenansicht für cocoIndex, Datenansicht auf die neu erstellte Coco-Datenansicht setzen und Feld auf description setzen, da dies das Feld ist, für das wir Einbettungen generieren möchten.

Das funktioniert hervorragend! Nun können wir mit der Erstellung der Ingest-Pipeline fortfahren und unsere Originaldokumente neu indizieren, sie durch die Pipeline leiten und einen neuen Index mit den Einbettungen erstellen. Dies erreichen Sie durch Klicken auf „Pipeline erstellen“. Sie werden dann durch den Erstellungsprozess der Pipeline geführt, wobei automatisch die benötigten Prozessoren zur Erstellung der Einbettungen bereitgestellt werden.

Der Assistent kann außerdem automatisch die Prozessoren eintragen, die zur Fehlerbehebung während der Datenerfassung und -verarbeitung benötigt werden.

Erstellen wir nun die Ingest-Pipeline. Ich nenne die Pipeline coco_e5. Sobald die Pipeline erfolgreich erstellt wurde, können Sie sie sofort verwenden, um die Einbettungen zu generieren, indem Sie die ursprünglich indizierten Daten im Assistenten in einen neuen Index umindizieren. Klicken Sie auf „Neu indizieren“ , um den Vorgang zu starten.

Für komplexere Konfigurationen können wir die Elasticsearch-API verwenden.

Bei einigen Modellen kann es aufgrund der Art und Weise, wie die Modelle trainiert wurden, erforderlich sein, bestimmte Texte vor oder nach dem eigentlichen Input einzufügen, bevor die Einbettungen generiert werden; andernfalls kommt es zu einer Leistungsverschlechterung.

Beim Modell e5 erwartet man beispielsweise, dass der Eingabetext dem Format „passage: {content of passage}“ folgt. Um das zu erreichen, nutzen wir die Ingest-Pipelines: Wir erstellen eine neue Ingest-Pipeline vectorize_descriptions. In dieser Pipeline erstellen wir ein neues temporäres Feld temp_desc , fügen dem Text description „passage: “ voran, führen temp_desc das Modell aus, um Text-Embeddings zu generieren, und löschen dann temp_desc.

Darüber hinaus möchten wir möglicherweise festlegen, welche Art der Quantisierung wir für den generierten Vektor verwenden möchten. Standardmäßig verwendet Elasticsearch int8_hnsw, aber hier möchte ich Better Binary Quantization (oder bqq_hnsw), wodurch jede Dimension auf eine Einzelbitgenauigkeit reduziert wird. Dadurch wird der Speicherbedarf um 96 % (oder um das 32-Fache) reduziert, allerdings auf Kosten der Genauigkeit. Ich entscheide mich für diese Quantisierungsart, weil ich weiß, dass ich später einen Reranker verwenden werde, um den Genauigkeitsverlust zu verbessern.

Dazu erstellen wir einen neuen Index mit dem Namen coco_multi und legen die Zuordnungen fest. Die Magie liegt hier im Feld vector_description, wo wir den Typ von index_optionsauf bbq_hnsw festlegen.

Nun können wir die Originaldokumente in einem neuen Index neu indizieren, wobei unsere Ingest-Pipeline das Beschreibungsfeld „vektorisiert“ oder Einbettungen erstellt.

Und das war's! Wir haben erfolgreich ein mehrsprachiges Modell mit Elasticsearch und Kibana implementiert und Schritt für Schritt gelernt, wie man mit Elastic Vektoreinbettungen für seine Daten erstellt, entweder über die Kibana-Benutzeroberfläche oder mit der Elasticsearch-API. Im zweiten Teil dieser Reihe werden wir die Ergebnisse und die Feinheiten der Verwendung eines mehrsprachigen Modells untersuchen. In der Zwischenzeit können Sie einen eigenen Cloud-Cluster erstellen , um die mehrsprachige semantische Suche mit unserem sofort einsatzbereiten E5-Modell auf der Sprache und dem Datensatz Ihrer Wahl auszuprobieren.

Traditionell war die Verwaltung von Webcrawlern ein manueller, fehleranfälliger Prozess. Dabei ging es um das direkte Bearbeiten von Konfigurationen in der Benutzeroberfläche sowie um das Klonen von Crawl-Konfigurationen, das Zurücksetzen von Einstellungen, die Versionsverwaltung und vieles mehr. Die Behandlung von Crawler-Konfigurationen als Code löst dieses Problem, indem sie die gleichen Vorteile bietet, die wir von der Softwareentwicklung erwarten: Wiederholbarkeit, Nachvollziehbarkeit und Automatisierung.

Dieser Workflow erleichtert es, den Open Web Crawler in Ihre CI/CD-Pipeline für Rollbacks, Backups und Migrationen einzubinden – Aufgaben, die mit früheren Elastic Crawlern wie dem Elastic Web Crawler oder dem App Search Crawler wesentlich schwieriger waren.

In diesem Artikel erfahren Sie, wie Sie:

• Verwalten Sie unsere Crawl-Konfigurationen mit GitHub.

• Eine lokale Testumgebung für Pipelines vor der Bereitstellung einrichten

• Wir erstellen eine Produktionsumgebung, um den Webcrawler jedes Mal mit neuen Einstellungen auszuführen, wenn wir Änderungen an unseren Hauptzweig übertragen.

Das Projekt-Repository finden Sie hier. Zum Zeitpunkt der Erstellung dieses Dokuments verwende ich Elasticsearch 9.1.3 und Open Web Crawler 0.4.2.

Voraussetzungen

• Docker Desktop

• Elasticsearch-Instanz

• Virtuelle Maschine mit SSH-Zugriff (z. B. AWS EC2) und installiertem Docker

Schritte

1. Ordnerstruktur

2. Raupenkonfiguration

3. Docker-Compose-Datei (lokale Umgebung)

4. GitHub Actions

5. Lokale Tests

6. Bereitstellung in der Produktionsumgebung

7. Änderungen vornehmen und erneut bereitstellen

Ordnerstruktur

Für dieses Projekt werden wir folgende Dateistruktur verwenden:

Raupenkonfiguration

Unter crawler-config.yml, wird Folgendes eingetragen:

Dies führt einen Crawl von https://web-scraping.dev/products durch, einer simulierten Website für Produkte. Wir werden nur die ersten drei Produktseiten durchsuchen. Die Einstellung max_crawl_depth verhindert, dass der Crawler mehr Seiten als die als seed_urls definierten Seiten entdeckt, indem er die darin enthaltenen Links nicht öffnet.

Elasticsearch host und api_key werden dynamisch befüllt, abhängig von der Umgebung, in der das Skript ausgeführt wird.

Docker-Compose-Datei (lokale Umgebung)

Für die lokale Umgebung docker-compose.yml, werden wir den Crawler und einen einzelnen Elasticsearch-Cluster + Kibana bereitstellen, damit wir unsere Crawling-Ergebnisse vor der Bereitstellung in der Produktionsumgebung einfach visualisieren können.

Beachten Sie, wie der Crawler wartet, bis Elasticsearch bereit ist, ausgeführt zu werden.

GitHub Actions

Nun müssen wir eine GitHub-Aktion erstellen, die die neuen Einstellungen kopiert und den Crawler bei jedem Push auf den Hauptzweig in unserer virtuellen Maschine ausführt. Dadurch wird sichergestellt, dass wir immer die aktuellste Konfiguration im Einsatz haben, ohne manuell in die virtuelle Maschine eingreifen zu müssen, um Dateien zu aktualisieren und den Crawler auszuführen. Wir werden AWS EC2 als Anbieter virtueller Maschinen verwenden.

Der erste Schritt besteht darin, den Host (VM_HOST), den Maschinenbenutzer (VM_USER), den SSH-RSA-Schlüssel (VM_KEY), den Elasticsearch-Host (ES_HOST) und den Elasticsearch-API-Schlüssel (ES_API_KEY) zu den GitHub Action Secrets hinzuzufügen:

Auf diese Weise kann die Aktion auf unseren Server zugreifen, um die neuen Dateien zu kopieren und den Crawl auszuführen.

Nun erstellen wir unsere .github/workflows/deploy.yml -Datei:

Diese Aktion führt jedes Mal die folgenden Schritte aus, wenn wir Änderungen an der Crawler-Konfigurationsdatei vornehmen:

1. Tragen Sie den Elasticsearch-Host und den API-Schlüssel in die YAML-Konfiguration ein.

2. Kopieren Sie den Konfigurationsordner auf unsere VM

3. Stellen Sie über SSH eine Verbindung zu unserer VM her.

4. Führen Sie den Crawl mit der Konfiguration aus, die wir gerade aus dem Repository kopiert haben.

Lokale Tests

Um unseren Crawler lokal zu testen, haben wir ein Bash-Skript erstellt, das den Elasticsearch-Host mit dem lokalen Docker-Repository befüllt und einen Crawl startet. Sie können ./local.sh eingeben, um es auszuführen.

Schauen wir uns die Kibana DevTools an, um zu bestätigen, dass web-crawler-index korrekt befüllt wurde:

Bereitstellung in der Produktionsumgebung

Jetzt sind wir bereit, die Änderungen auf den Hauptzweig zu übertragen. Dadurch wird der Crawler in Ihrer virtuellen Maschine bereitgestellt und beginnt, Protokolle an Ihre Serverless Elasticsearch-Instanz zu senden.

Dadurch wird die GitHub-Aktion ausgelöst, die das Bereitstellungsskript innerhalb der virtuellen Maschine ausführt und mit dem Crawling beginnt.

Sie können die Ausführung der Aktion überprüfen, indem Sie zum GitHub-Repository gehen und den Tab „Aktionen“ aufrufen:

Änderungen vornehmen und erneut bereitstellen

Vielleicht ist Ihnen aufgefallen, dass die price jedes Produkts Teil des Body-Felds des Dokuments ist. Ideal wäre es, den Preis in einem separaten Feld zu speichern, damit wir Filter darauf anwenden können.

Fügen wir diese Änderung zur Datei crawler.yml hinzu, um Extraktionsregeln zu verwenden, mit denen der Preis aus der CSS-Klasse product-price extrahiert werden kann:

Wir sehen auch, dass der Preis ein Dollarzeichen ($) enthält, das wir entfernen müssen, wenn wir Bereichsabfragen ausführen wollen. Dafür können wir eine Ingest-Pipeline verwenden. Beachten Sie, dass wir in unserer neuen Crawler-Konfigurationsdatei oben darauf verweisen:

Wir können diesen Befehl in unserem Elasticsearch-Produktionscluster ausführen. Da die Entwicklungsversion ephemer ist, können wir die Pipeline-Erstellung in die docker-compose.yml -Datei integrieren, indem wir den folgenden Dienst hinzufügen. Beachten Sie, dass wir dem Crawler-Dienst auch eine depends_on hinzugefügt haben, damit er erst startet, nachdem die Pipeline erfolgreich erstellt wurde.

Führen wir nun `./local.sh` aus, um die Änderung lokal zu sehen:

Großartig! Jetzt lasst uns die Veränderung vorantreiben:

Um sicherzustellen, dass alles funktioniert, können Sie Ihre Produktions-Kibana-Datei überprüfen. Dort sollten die Änderungen sichtbar sein und der Preis als neues Feld ohne Dollarzeichen angezeigt werden.

Fazit

Mit dem Elastic Open Web Crawler können Sie Ihren Crawler als Code verwalten. Das bedeutet, dass Sie die gesamte Pipeline – von der Entwicklung bis zur Bereitstellung – automatisieren und beispielsweise ephemere lokale Umgebungen und Tests anhand der gecrawlten Daten programmatisch hinzufügen können.

Sie sind eingeladen, das offizielle Repository zu klonen und mit der Indizierung Ihrer eigenen Daten mithilfe dieses Workflows zu beginnen. In diesem Artikel erfahren Sie auch, wie Sie eine semantische Suche auf den vom Crawler erzeugten Indizes durchführen.