Für neue Nutzer ist dies der schnellste Weg, eine hochwertige Vektorsuche in Betrieb zu nehmen. Wenn Sie Elasticsearch bereits nutzen, bietet das neue Angebot eine Vektorsuche auf der Plattform, auf der Ihre Daten bereits gespeichert sind – ganz ohne die Einführung eines neuen Systems. Die Elasticsearch-Vektordatenbank unterstützt verschiedene Szenarien – vom Grounding eines großen Sprachmodells (LLM) über die Bereitstellung von Abruf- und Speicherfunktionen für KI-Agenten bis hin zur Bereitstellung von Hunderten Milliarden Vektoren. Starten Sie ein neues Projekt und legen Sie in wenigen Minuten los.

Eine Engine für alle Vektor-Anwendungsfälle

Die Elasticsearch-Vektordatenbank wurde für alle entwickelt, die Anwendungen mit Vektoren erstellen:

• RAG: Rufen Sie mit dem Abruf dichter und dünnbesetzter Vektoren den passenden Kontext für Ihr LLM ab oder entscheiden Sie sich für die Hybridsuche, die sowohl den Vektor- als auch den lexikalischen Abruf kombiniert. Die Qualität Ihrer Generierung verbessert sich mit der Qualität Ihres Abrufs.

• KI-Agenten: Geben Sie Agenten schnellen, gefilterten Zugriff auf Dokumente und Konversationsgedächtnis – mit den niedrigen Latenzen, die mehrstufige Agentenschleifen erfordern.

• Semantische Suche: Gleichen Sie nach Bedeutung statt nach Schlagwörtern ab – mit einem einzigen Feldtyp und ganz ohne Pipeline-Code.

• Empfehlungen und Ähnlichkeit: Finden Sie die nächsten Nachbarn über Produkte, Bilder oder beliebige andere Inhalte hinweg – und das in großem Maßstab.

Alles, was Ihre Vektor-Workloads benötigen – standardmäßig optimiert

Eine vektorbasierte Anwendung zu erstellen bedeutet, mehrere separate Komponenten miteinander zu verbinden: Einbettungsmodelle einzurichten und zu hosten, Ihre Dokumente damit zu indexieren, die Vektoren effizient zu speichern, das Einbettungsmodell auf jede Abfrage anzuwenden, mit dem Vektorspeicher abzugleichen und schließlich die Dokumente hinter den Treffern abzurufen. Die Elasticsearch-Vektordatenbank übernimmt all das für Sie – ohne zusätzliche Konfiguration oder Einrichtung.

Vektorindexierung mit vectordb_document-Indexmodus

Der vectordb_document-Indexmodus, eine neue Indexkonfiguration, die speziell für vektororientierte Workloads entwickelt wurde, ist standardmäßig aktiviert, sodass Sie die Einstellungen erhalten, die Experten wählen würden. Folgendes wird dadurch aktiviert:

• Standardmäßig bfloat16: Vektoren werden mit der halben Größe von float32 bei vernachlässigbaren Auswirkungen auf den Recall gespeichert, wodurch sich Ihr Festplattenbedarf um etwa die Hälfte reduziert, noch bevor Quantisierung überhaupt ins Spiel kommt.

• Quellvektoren sind ausgeschlossen: In Elasticsearch befinden sich Ihre Einbettungen bereits in den Indexstrukturen, die für die Suche verwendet werden; eine zweite Rohkopie in _source würde lediglich den Speicher aufblähen und das Abrufen von Ergebnissen verlangsamen. Wir schließen das Duplikat aus, damit Antworten schneller zurückgegeben werden und Sie weniger speichern müssen.

• Die richtigen Dateien werden vorab in den Cache geladen: Die Datenstrukturen, auf die Vektorabfragen zuerst zugreifen, werden vorab in den Arbeitsspeicher geladen, sodass Ihre erste (und auch noch Ihre tausendste) Abfrage blitzschnell ist.

• Parallele Zusammenführung: Durch die Zusammenführung werden Segmente zu besser organisierten Vektorstrukturen konsolidiert, was sowohl den Recall als auch die Latenz verbessert, und durch die Multithread-Ausführung dieser Zusammenführungen erreichen Sie Ihr Ziel schneller.

Vektorspeicherung, Komprimierung und Auto-Tuning

• Ihre Vektoren werden automatisch komprimiert. Better Binary Quantization (BBQ) reduziert den Vektorspeicherbedarf um das bis zu 32-Fache bei Beibehaltung der Trefferquote, und DiskBBQ verringert den Speicherbedarf für Workloads in großem Maßstab noch weiter. 

• Entscheiden Sie sich für die automatische Kalibrierung, die die Quantisierung jedes Segments auf Ihre Daten abstimmt und bei jeder Zusammenführung neu abstimmt, wenn sich die Daten verändern. Bei Tests mit 18 Datensätzen verbesserten sich die Abfragen pro Sekunde (QPS) durchschnittlich um 16,7 %, wobei sich der Recall bei den meisten von ihnen erhöhte.

Einbettungen mit vollständig verwalteter GPU-Inferenz

• Generieren Sie Einbettungen mit nativen Embedding- und Reranking-Modellen von Jina AI oder binden Sie Drittanbieter-Modelle ein – alles auf verwalteten GPUs über den Elastic Inference Service (EIS) und ganz ohne eigene Modellserver. Oder hosten Sie selbst, wenn Sie eine eigene Lösung bevorzugen.

• Der Feldtyp semantic_text verarbeitet Chunking und Einbettung sowie Abfragen automatisch – der einfachste Weg zur semantischen Suche auf dem Markt. 

Hybridsuche und gefilterte Vektorsuche

• Die Hybridsuche ist integriert und kombiniert Volltext- und Vektor-Retrieval in einer einzigen Abfrage. Kombinieren Sie die Ergebnisse mit Reciprocal Rank Fusion (RRF) oder einem beliebigen anderen Mischmechanismus nach Ihren Wünschen. Die Vektorsuche ist meist der Teil der Hybridsuche, der sich am schwersten optimal konfigurieren lässt. Mit der Elasticsearch-Vektordatenbank haben Sie alles im Griff und Ihr gesamter Hybrid-Stack wird besser. 

• Mit der gefilterten Vektorsuche wenden Sie Metadatenfilter als Teil des Vektorabrufs selbst an und nicht erst im Nachhinein, was den Recall beeinträchtigt.

Enterprise von Anfang an

Sie erhalten außerdem rollenbasierte Zugriffssteuerung (RBAC), Audit Logging und die Compliance-Zertifizierungen, die reinen Vektordatenbanken in der Regel fehlen.

Erschwinglich in großem Maßstab und vorhersehbar

Die Elasticsearch-Vektordatenbank ist so konzipiert, dass sie auch bei wachsendem Bedarf erschwinglich bleibt: Durch BBQ- und DiskBBQ-Komprimierung, die das Speicherwachstum linear und den Arbeitsspeicherbedarf gering hält, führt die Skalierung auf Hunderte von Milliarden Vektoren nicht zu explodierenden Kosten. Und was Sie tatsächlich bezahlen, basiert auf Zahlen, die Sie bereits kennen: der Zahl der von Ihnen gespeicherten Daten, der Zahl der indexierten Daten und der von Ihnen benötigten Suchkapazität. Schätzen Sie Ihre Dokumentenzahl und die Vektordimensionen sowie Ihre Abfragelast ab, und Sie können bereits vor der Erstellung des Projekts ermitteln, was Sie zahlen werden. Außerdem können Sie Ihre Rechnung am Monatsende Zeile für Zeile nachvollziehen. Es gibt keine undurchsichtigen Recheneinheiten und keine überraschenden Gebühren für Hintergrundoperationen.

Erste Schritte mit der Elasticsearch-Vektordatenbank

Ein Serverless-Vektordatenbank-Projekt erstellen

Erstellen Sie ein neues serverloses Vektordatenbank-Projekt in Elastic Cloud. Leiten Sie Ihre Daten an den Endpoint weiter, und schon können Sie mit dem Indexieren beginnen.

Einen Index mit semantic_text erstellen

Der Vektorindex-Modus übernimmt die Vektorkonfiguration. Die Verwendung von semantic_text bedeutet, dass die Einrichtung von Einbettungen und Chunking sowie die Indexeinrichtung bei verwalteter GPU-Inferenz für Sie verwaltet werden, ohne dass Sie eine Einbettungs-Pipeline erstellen müssen.

Dokumente ingestieren

Indexieren Sie Text, und die Einbettungen werden für Sie generiert.

Eine semantische Suchabfrage ausführen

Fragen Sie dasselbe semantische Feld ab, das Sie gerade erstellt haben:

Und Sie erhalten Ergebnisse zurück:

Die semantische Suche ist erst der Anfang. Führen Sie rein textbasierte Abfragen aus oder kombinieren Sie beides zu hybriden Abfragen. Sie können für die volle Kontrolle sogar Ihre eigenen Vektorabfragen erstellen. Folgen Sie dem Schnellstart für die semantische Suche in der Dokumentation zur vollständigen Anleitung.

Was kommt als Nächstes für die Vektorsuche in Elasticsearch?

Wir arbeiten bereits an den nächsten Verbesserungen:

• Bessere Multi-Mandanten-Verwaltung: Wenn Ihre Daten pro Mandant getrennt bleiben müssen, bieten wir Ihnen eine Möglichkeit, dies schneller und mit weniger Code umzusetzen.

• Automatische Indexoptimierung: Vom „brandneuen Index“ bis zu „vollständig optimiert“, mit möglichst wenig Feinabstimmung.

• Kontinuierliche Infrastrukturverbesserungen: Eine laufende Optimierung der Einstellungen und Infrastruktur der Vektordatenbank, damit Sie stets den besten Durchsatz und die schnellsten Reaktionen erhalten.

Testen Sie die Elasticsearch-Vektordatenbank auf Elastic Cloud Serverless

Gelangen Sie in wenigen Minuten von einem leeren Projekt zu einer hybriden, gefilterten Vektorabfrage – mit produktionsreifen Standardeinstellungen, die das Tuning für Sie übernehmen. Erstellen Sie schnelle, skalierbare KI-Apps, keine Infrastruktur.

Starten Sie auf Elastic Cloud Serverless oder tauchen Sie ein in die vollständige Dokumentation und die API-Referenz.

Was ist ein Abruf?

Der Abruf misst auf einer Skala von 0 bis 1, wie viele der Dokumente, die Ihre Nutzer tatsächlich haben möchten, irgendwo in Ihren Suchergebnissen erscheinen. Wenn eine Abfrage drei Produkte anzeigen sollte und Ihre Suche nur zwei davon in den Top 10 zurückgibt, gilt recall@10 = 0.67 für diese Abfrage. Es ist eine mengenbasierte Metrik: Die Position der relevanten Dokumente innerhalb dieser k Ergebnisse spielt keine Rolle. Ein relevantes Dokument auf Position 10 zählt genauso wie eines auf Position 1. Ein hoher Abruf-Wert bedeutet, dass Sie keine relevanten Ergebnisse verlieren.

Das Diagramm zeigt zwei Mengen: alle relevanten Dokumente (links) und die Top 10, die BM25 tatsächlich abgerufen hat (rechts). Nur die Schnittmenge zählt für den Rückruf: prod_1 und prod_2 wurden gefunden, während prod_3, prod_4 und prod_6 vollständig übersehen wurden. Ergebnis: Recall@10 = 2/5 = 0.40.

Voraussetzungen

Lassen Sie uns zur Sache kommen, um besser zu verstehen, wie das Abrufverfahren funktioniert. Diese Demonstration verwendet Python. Sie können es im begleitenden Notebook verfolgen (notebook.ipynb), wo jeder Codeblock eine ausführbereite Zelle darstellt.

Der bereitgestellte Code verwendet Folgendes:

• Elasticsearch 9.3+

• Python 3.10+

• Eine .env-Datei mit Ihren Elasticsearch-Zugangsdaten

Der Datensatz

Wir verwenden einen Produktkatalog mit 1.000 Produkten, der Kategorien wie Schuhe, Elektronik, Werkzeuge und mehr umfasst.

Jedes Dokument hat vier Felder:

Feld

Typ

`Titel`

Text

`Beschreibung`

Text

`Marke`

Keyword

`Kategorie`

Keyword

Der Datensatz wird aus dataset.csv geladen.

Die Stärken und Grenzen der lexikalischen Suche

BM25 ist der Standard-Ranking-Algorithmus in Elasticsearch und den meisten Suchmaschinen. Er bewertet Dokumente danach, wie oft Ihre Abfragebegriffe darin erscheinen, angepasst an die Dokumentlänge und die Häufigkeit dieser Begriffe im gesamten Index. Sie erhalten zusätzlich Analyzer: Kleinschreibungsnormalisierung, Stemming und Stoppwort-Entfernung. Eine Suchanfrage nach „Laufschuhen“ liefert Treffer für „Laufschuhe“ und wahrscheinlich auch für „Laufen“.

Dies funktioniert gut für eine große Gruppe von Abfragen:

• „Laufschuhe“ findet sofort Produkte, die genau diesen Begriff im Titel enthalten.

• „Bluetooth-Lautsprecher“ taucht bei tragbaren Audioprodukten auf, weil die Token wortwörtlich erscheinen.

Die Ergebnisse sind deterministisch und erklärbar: Ein Dokument rangiert hoch, weil die Abfragebegriffe darin erscheinen. Die Relevanzprüfung ist unkompliziert.

Wo es fehlschlägt

Nun probieren wir diese Abfragen mit demselben Katalog aus:

• „Hautpflege-Routine“: Das Wort „Routine“ kommt in keinem Produkttitel vor. BM25 kann teilweise mit „Hautpflege“ abgestimmt werden, aber Gesichtsseren, Körperöle und Feuchtigkeitscremes werden mit Begriffen wie „Vitamin C“, „Retinol“ oder „Strahlkraft“ beschrieben, von denen sich keine mit der Abfrage überschneidet. Produkte, die eine vollständige Hautpflegeroutine darstellen, sind über den Index verstreut, ohne ein gemeinsames verankerndes Token.

• „Reisezubehör für Haustiere“: Dies ist eine Anwendungsfall-Gruppierung, keine Produktkategorie. Eine Hundetragetasche, ein Autositz für Haustiere und eine Transportbox sind alle relevant, aber in ihren Beschreibungen geht es eher um Tragbarkeit, Sicherheit und Komfort als um „Reisezubehör“. BM25 stimmt weitgehend mit „Haustier“ überein, hat aber kein Signal, um reisespezifische Produkte vom Rest des Haustierkatalogs zu unterscheiden.

Das ist ein Abrufproblem. Die relevanten Dokumente finden sich in Ihrem Index. BM25 kann sie einfach nicht finden, weil die Wörter des Nutzers und die Wörter des Dokuments nicht genau genug übereinstimmen.

Das Hinzufügen von Synonymen hilft bei bekannten Fällen. Man kann aber nicht alle Möglichkeiten aufzählen, wie ein Nutzer seine Absicht ausdrücken könnte. An dieser Stelle kommen Vektoren ins Spiel.

Warum Sie die Abruf-Rate messen sollten

Bevor Sie ein Problem beheben, müssen Sie es quantifizieren.

Recall@k misst, wie viele der Dokumente, die Ihre Nutzer tatsächlich suchen, tatsächlich in Ihren Suchergebnissen erscheinen. Formell:

Precision@k misst die besten k-Ergebnisse und wie viele tatsächlich relevant sind:

Hohe Präzision bedeutet, dass die Ergebnisse gut sind. Im E-Commerce ist es oft schlimmer, ein relevantes Produkt zu übersehen (niedrige Abruf-Werte), als ein nicht ganz perfektes Ergebnis anzuzeigen (geringere Präzision), denn ein verstecktes Produkt ist ein verlorener Verkauf.

Mit der rank_eval-API von Elasticsearch können Sie beides systematisch messen. Sie stellen eine Liste von Abfragen mit jeweils einer Reihe von bewerteten Dokumenten zur Verfügung, und Elasticsearch berechnet für Sie die Metriken für alle Abfragen.

Die Bewertung einrichten

Die rank_eval API benötigt einen Bewertungsdatensatz: ein Mapping von Abfragen zu den Dokumenten, die jeweils relevant sind, zusammen mit einer Relevanznote (0 = nicht relevant, 1 = relevant, 2 = sehr relevant).

Im Notebook ist dies die Bewertungsliste:

Die Mischung ist beabsichtigt: q1 ist eine Abfrage, die BM25 gut verarbeiten kann (exakte Tokens in Produkttiteln), während q2, q3 und q4 absichtsbasierte Abfragen sind, bei denen die Absicht des Nutzers als Konzept und nicht als spezifische Produktschlüsselwörter ausgedrückt wird.

Messung des BM25-Baseline-Abrufs

Richten Sie zuerst den Elasticsearch-Client ein und indexieren Sie die Rohtextdaten:

Erstellen Sie nun die rank_eval-Abfrage für BM25. Jede Abfrage in der Liste kombiniert eine Abfrage mit ihren Bewertungen:

Ergebnis:

0.43 Das bedeutet, dass BM25 bei allen vier Abfragen nur 43 % der Dokumente findet, die es finden sollte. Das Defizit konzentriert sich auf die absichtsbasierten Suchanfragen: Bei der Suche nach „Hautpflegeroutine“ werden Gesichtsseren und Körperöle nicht erfasst, da „Routine“ nie in den Produkttiteln vorkommt, und bei der Suche nach „Reisezubehör für Haustiere“ werden themenfremde Haustierprodukte gefunden, während Transportboxen und -käfige, die eher im Hinblick auf Tragbarkeit und Sicherheit als auf „Reisezubehör“ beschrieben werden, nicht erfasst werden.

Dies ist unsere Referenzgrundlage. Jetzt haben wir eine Zahl, die es zu übertreffen gilt.

Vektorsuche mit Jina-Embeddings hinzufügen

Vector search Dokumente und Abfragen werden als hochdimensionale Vektoren kodiert, eine Art von Vektor, der aus Hunderten oder Tausenden numerischer Werte besteht, wobei jeder Wert ein spezifisches Feature der dargestellten Daten kodiert. Dokumente mit ähnlicher Bedeutung befinden sich im Vektorraum nahe beieinander, selbst wenn sie keine gemeinsamen Wörter enthalten. „Fitnessgeräte“ und „Hantelset“ werden sich in unmittelbarer Nähe befinden, da die Konzepte miteinander verwandt sind. Ich habe Elasticsearch als meine Vektordatenbank gewählt, da es die hybride Suche unterstützt und mir sowohl semantisches Verständnis als auch präzise Stichwortsuche direkt bietet.

EIS bietet eine fertige Unterstützung für das Einbetten von Modellen über seine Inferenz-API.

Schritt 1: Verwendung von Jina-Embeddings v5 als Inferenz-Endpoint

Wenn Ihr Cluster GPU-Ressourcen hat (verfügbar in Elastic Cloud und Elasticsearch 9.3+), werden die Einbettungen auf GPU generiert, was deutlich schneller ist als die CPU-Inferenz und den Leistungskompromiss beseitigt, der Vektoren historisch im großen Maßstab teuer gemacht hat.

Warum genau Jina-Einbettungen? jina-embeddings-v5-text ist ein mehrsprachiges Modell (über 119 Sprachen) mit einem Kontextfenster von 32.000 Token und Unterstützung für aufgabenspezifische Low-Rank Adaptation (LoRA) Adapter. Es eignet sich hervorragend für kurze Produktbeschreibungen. Erfahren Sie mehr über das jina-embeddings-v5-text-Modell hier.

Schritt 2: Erstellen Sie den Index mit einem semantischen Feld

Der semantic_text-Feldtyp ist hier der Schlüssel. Es handelt sich um eine Abstraktion auf höherer Ebene über dense_vector: Sie verweisen auf einen Inferenz-Endpoint, und Elasticsearch kümmert sich automatisch um die Generierung von Einbettungen.

Die copy_to-Eigenschaft auf title und description bedeutet, dass Inhalte aus beiden Feldern in semantic_field zur Einbettung fließen, sodass ein einzelner Vektor die vollständige Produktdarstellung erfasst.

Schritt 3: Produkte indexieren

Zur Indexzeit ruft Elasticsearch für jedes Dokument den Inferenz-Endpoint auf und speichert die resultierende Einbettung in semantic_field. Kein zusätzlicher Code für Sie erforderlich.

Hybridsuche: Kombination von BM25 und Vektoren mit RRF

Das Hinzufügen von Vektoren verbessert den Abruf, aber die Verwendung von Vektoren allein birgt das Risiko, dass die Präzision bei exakten Übereinstimmungen auf der Strecke bleibt. „Laufschuhe“ sollten immer noch wortwörtliche Übereinstimmungen an erster Stelle einordnen. Die Hybridsuche behält die lexikalische Komponente bei, um diese Präzision zu erhalten.

Hybride Suche mit Reciprocal Rank Fusion (RRF) kombiniert das Beste von beidem:

• BM25 verarbeitet exakte und nahezu exakte Abfragen mit hoher Präzision.

• Die semantische Suche bewältigt absichtsbasierte und mehrsprachige Abfragen mit hoher Trefferquote.

• RRF kombiniert die beiden Ranglisten zu einer einzigen Rangliste.

Die RRF-Formel weist jedem Dokument eine Bewertung basierend auf seinem Rang in jeder Ergebnisliste zu:

Ein Dokument, das in beiden Listen einen hohen Rang einnimmt, erhält eine höhere kombinierte Punktzahl. rank_constant steuert, wie viel Gewicht Dokumente mit niedrigerem Rang erhalten.

Ergebnis:

Hybrid verbessert sich erheblich gegenüber BM25 (0.43) und erhält die Präzision für exakte Treffer bei Abfragen wie „Laufschuhe“ bei.

Ergebnisse: Vorher und Nachher

Hier der vollständige Vergleich aller drei Ansätze:

Ergebnis:

Methode

Recall@10

BM25 (Lexikalisch)

0,43

Hybrid (BM25 + Vektoren)

0,75

Aufschlüsselung nach Abfragen:

Fazit

Im Laufe dieses Beitrags haben wir erfahren, dass die lexikalische BM25-Suche zuverlässig ist, wenn Nutzer exakte Suchanfragen eingeben, aber an Treffsicherheit verliert, wenn sie nach Suchintention statt nach Schlüsselwörtern suchen. Mit rank_evalhaben wir eine reproduzierbare Basislinie festgelegt, um diese Lücke mit reellen Zahlen zu messen. Von dort aus haben wir ein semantic_text Feld hinzugefügt, das von Jina-Einbettungen unterstützt wird, und die Bewertung erneut durchgeführt. Das Ergebnis: Die Hybridsuche verbesserte die Trefferquote von 0.43 auf 0.75, während die Genauigkeit bei exakten Suchabfragen erhalten blieb. Die tatsächliche Verbesserung hängt jedoch von der Zusammensetzung Ihrer Suchabfragen ab.

Das Muster lässt sich über dieses Beispiel hinaus skalieren: Sammeln Sie Relevanzurteile aus den tatsächlichen Abfragen Ihrer Nutzer, führen Sie rank_eval als Baseline aus, fügen Sie semantic_text hinzu und messen Sie erneut. Sie wissen genau, was sich verbessert hat und um wie viel.

Wie geht es weiter?

• Tauchen Sie tiefer in Abruf und Vektorsuche ein: Recall and Vector Search Quantization von Jeff Vestal

• Fügen Sie ein Reranking hinzu, um die besten Ergebnisse noch präziser zu ermitteln

• Erkunden Sie die Elasticsearch-Dokumentation zur Hybridsuche

• Erfahren Sie mehr über rank_eval API

Wie wir im vorherigen Beitrag gesehen haben, ist die Konstanz, die durch Funktionsaufrufe ermöglicht wird, nicht nur eine praktische Optimierung, sondern essenziell. Nachdem wir strukturelle Fehler aus dem Evaluationskreislauf entfernt hatten, verbesserten sich die Ergebnisse in Standardszenarien (wie denen im Tier-4-Datensatz) dramatisch.

Doch eine offensichtliche Frage bleibt noch zu beantworten:

Funktioniert dieser Ansatz noch, wenn es kompliziert wird?

Die Entitätsauflösung in der realen Welt schlägt selten in einfachen Fällen fehl. Sie scheitert, wenn Namen Sprach-, Kultur-, Schrift-, Zeit- und Unternehmensgrenzen überschreiten. Sie scheitert, wenn auf Menschen mit Titeln anstelle von Namen Bezug genommen wird, wenn Unternehmen Namen ändern, wenn Transliterationen nicht konstant sind und wenn Kontext (nicht die Schreibweise) das Einzige ist, was eine Erwähnung mit einer realen Entität verbindet.

Für den letzten Beitrag dieser Serie haben wir das System einer sogenannten ultimativen Herausforderung unterzogen.

Was macht dies zur ultimativen Herausforderung?

In früheren Auswertungen haben wir das System mit zunehmend komplexeren Datensätzen getestet. Als wir die im vorherigen Beitrag besprochene Stufe 4 erreichten, hatten wir es bereits mit einer Mischung aus Spitznamen, Titeln, mehrsprachigen Namen und semantischen Bezügen zu tun. Diese Tests zeigten, dass die Architektur selbst solide war, aber dass Zuverlässigkeitsprobleme, insbesondere fehlerhaftes JSON, den Rückruf unterdrückten.

Mit dem implementierten Funktionsaufruf hatten wir endlich eine stabile Grundlage. So konnten wir eine interessantere Frage stellen:

Kann eine einheitliche Pipeline viele verschiedene Arten von Entitätsauflösungsproblemen gleichzeitig bewältigen?

Der ultimative herausfordernde Datensatz wurde darauf ausgelegt, genau diese Dimension zu erreichen.

Anstatt sich auf eine einzelne Schwierigkeit (wie Spitznamen oder Transliteration) zu konzentrieren, kombiniert dieser Datensatz mehr als 50 verschiedene Herausforderungstypen, darunter:

• Kulturelle Namenskonventionen.

• Titelbasierte Referenzen.

• Geschäftliche Beziehungen und historische Namensänderungen.

• Mehrsprachige und skriptübergreifende Erwähnungen.

• Zusammengesetzte Herausforderungen, die mehrere der oben genannten Punkte kombinieren.

Entscheidend ist, dass es hier nicht um die Optimierung für einen einzigen, eng begrenzten Anwendungsfall geht. Es geht darum zu testen, ob das Entwurfsmuster Bestand hat, wenn sich die Regeln von Entität zu Entität ändern.

Der Datensatz auf einen Blick

Der ultimativ herausfordernde Datensatz besteht aus:

• 50 Entitäten, darunter Personen, Unternehmen und Institutionen.

• ~60 Artikel, mit unterschiedlicher Struktur und sprachlicher Komplexität.

• 51 verschiedene Herausforderungskategorien, grob unterteilt in:

  • Kulturelle Namenskonventionen.

  • Titel und beruflichem Kontext.

  • Geschäfts- und Unternehmensbeziehungen.

  • Mehrsprachigkeit und Transliterationsherausforderungen.

  • Kombinierten und Grenzfall-Szenarien.

Zu Beginn der Serie haben wir gesehen, dass die Verwendung von generativer KI (GenKI) zur Erstellung von Datensätzen ein zweischneidiges Schwert sein kann. Ohne sie wäre es äußerst schwierig, ausreichend große und vielfältige Testdaten zusammenzustellen. Aber wenn das Modell nicht kontrolliert wird, neigt es dazu, die Dinge zu einfach zu machen.

Bei einer frühen Generationsüberprüfung stellten wir beispielsweise fest, dass das Modell Formulierungen wie „der russische Präsident“ als expliziten Aliasnamen für Wladimir Putin enthielt. Das mag heute vernünftig erscheinen, aber es widerspricht dem Zweck der Prüfung der Kontextauflösung. Was passiert, wenn der Artikel Russland in den 1990er Jahren behandelt? Das System sollte die richtige Entität aus dem Kontext ableiten und sich nicht auf einen fest codierten Alias verlassen.

Aus diesem Grund wurde dieser Datensatz bewusst so konzipiert, dass Abkürzungen nicht funktionieren. Pseudonyme werden nicht explizit aufgeführt, wenn das System die Bedeutung erschließen soll. Beschreibende Phrasen sind nicht vorab mit Entitäten verknüpft. Korrekte Treffer hängen oft vom Kontext auf Artikelebene ab, nicht nur vom lokalen Text.

Wichtiger Hinweis: Obwohl wir die Fähigkeiten des Systems in verschiedenen Szenarien demonstrieren, ist dies dennoch ein Bildungsprototyp. Produktionssysteme, die die Überwachung von sanktionierten Entitäten in der realen Welt handhaben, würden zusätzliche Validierung, Compliance-Prüfungen, Audit-Trails und eine spezialisierte Handhabung für sensible Anwendungsfälle erfordern.

Warum diese Szenarien schwierig sind

Im ersten Beitrag dieser Reihe haben wir ein einfaches, aber mehrdeutiges Beispiel vorgestellt: „Das neue Swift-Update ist da!“ Die Herausforderung besteht darin, dass „Swift“ je nach Kontext auf mehrere reale Entitäten aufgelöst werden kann. Dieses Beispiel verdeutlicht eine grundlegendere Wahrheit: Natürliche Sprache ist von Natur aus mehrdeutig.

Die Entitätsauflösung ist daher nicht nur ein Problem des Zeichenfolgenabgleichs. Menschen verlassen sich routinemäßig auf gemeinsames Wissen, kulturelle Normen und situativen Kontext, um Referenzen zu lösen, und oft merken wir gar nicht, dass wir das tun.

Betrachten wir ein paar gängige Fälle:

• Ein Titel wie „der Präsident“ ist ohne geopolitischen und zeitlichen Kontext bedeutungslos.

• Ein Firmenname kann sich je nach Zeitpunkt der Artikelveröffentlichung auf ein Mutterunternehmen, eine Tochtergesellschaft oder eine ehemalige Marke beziehen.

• Der Name einer Person kann in verschiedenen Reihenfolgen, Schriften oder Transliterationen erscheinen, abhängig von Sprache und Kultur.

• Die gleiche Phrase kann in verschiedenen Kontexten legitimerweise auf unterschiedliche Entitäten verweisen, und das System muss in der Lage sein, Matches genauso zuversichtlich abzulehnen, wie sie zu akzeptieren.

Es gibt kein einzelnes Regelwerk, das all dies sauber abdeckt. Deshalb trennt dieser Prototyp die verschiedenen Bereiche so konsequent:

• Elasticsearch schränkt den Kandidatenraum effizient und transparent ein.

• Das LLM wird nur dort verwendet, wo ein Urteil erforderlich ist, und ist gezwungen, sich selbst zu erklären.

• Abruf und Schlussfolgerung bleiben getrennte Schritte.

Diese Trennung wird umso wichtiger, je größer die Vielfalt der Herausforderungen ist.

So geht das System mit Vielfalt ohne Spezialfälle um

Eines der interessantesten Ergebnisse dieser Bewertung ist, was sich nicht geändert hat:

• Wir haben keine spezielle Logik für japanische Namen hinzugefügt.

• Wir haben keine benutzerdefinierten Regeln für arabische Patronyme hinzugefügt.

• Wir haben keine fest codierten Mappings für historische Firmennamen hinzugefügt.

Stattdessen basierte das System auf denselben Kernzutaten, die früher in der Serie eingeführt wurden:

• Mit Kontext angereicherte Entitäten, die für semantische Suchen indexiert sind.

• Hybrider Abruf (exakt, per Alias und semantisch) in Elasticsearch.

• Eine kleine, gut definierte Gruppe von Kandidatenmatches.

• LLM-Bewertung eingeschränkt durch Funktionsaufruf und Minimalschemata.

Das deutet darauf hin, dass die Flexibilität des Systems von Repräsentation und Architektur herrührt, nicht von einer ständig wachsenden Sammlung von Regeln.

Wenn das System erfolgreich ist, liegt das daran, dass die richtigen Kandidaten ermittelt werden und das LLM ausreichend Kontext hat, um zu erklären, warum eine Referenz einer bestimmten Entität zugeordnet wird oder nicht.

Ergebnisse: Wie hat es abgeschnitten?

Im ultimativ herausfordernden Datensatz erzielte das System folgende Gesamtergebnisse:

• Präzision: ~91 %

• Rückruf: ~86 %

• F1-Score: ~89 %

• LLM-Annahmequote: ~72 %

Leistung nach Herausforderungstyp

Die Aufschlüsselung der Ergebnisse nach Herausforderungstyp zeigt Stärken und Schwächen:

Die stärkste Leistung (100 % F1-Score) wurde in folgenden Bereichen beobachtet:

• Schriftübergreifender Abgleich (kyrillische, koreanische, chinesische Unternehmen).

• Hebräische Szenarien (Patronyme, Berufstitel, religiöse Titel, Transliteration).

• Unternehmenshierarchien (Luft- und Raumfahrt, diversifizierte Fertigungsunternehmen, Konzerne mit mehreren Geschäftsbereichen).

• Berufsbezeichnungen (akademisch, militärisch, politisch, religiös).

• Kombinierte japanische Szenarien mit mehreren Schriftsystemen.

Starke Leistung (80–99 % F1-Score) umfassten:

• Internationale politische Persönlichkeiten (98 %).

• Historische Namensänderungen (90 %).

• Komplexe Unternehmenshierarchien (89 %).

• Japanische Firmennamen (93 %).

• Cross-Script-Transliteration (86 %).

• Arabische Patronyme (86 %).

Problematischere Bereiche waren:

• Erweiterte Transliteration (Chinesisch, Koreanisch): 0 % F1.

• Bestimmte japanische Szenarien (Höflichkeitsformen, Namensreihenfolge, Variationen des Schriftsystems): ~67 % F1.

• Einige arabische Szenarien (Unternehmensnamen, institutionelle Referenzen): ~40 % F1.

Wichtig ist hier, warum das System in diesen Fällen Schwierigkeiten hatte. Die Fehler waren nicht auf das Scheitern des Gesamtansatzes zurückzuführen, sondern auf Einschränkungen in bestimmten Komponenten, insbesondere dem dichten Vektormodell, das für die semantische Suche in bestimmten mehrsprachigen Szenarien verwendet wird.

Da Abruf und Beurteilung klar getrennt sind, erfordert die Leistungssteigerung keine Neuprogrammierung des Systems. Der Austausch eines leistungsfähigeren mehrsprachigen Einbettungsmodells, die Anreicherung des Entitätskontextes oder die Verfeinerung der Suchstrategien würde die Ergebnisse in diesen Kategorien verbessern, ohne die Kernarchitektur zu verändern.

Aus architektonischer Sicht ist das der eigentliche Erfolgsmaßstab.

Was uns das über das Design verrät

Beim Rückblick auf die Serie lassen sich einige Muster erkennen:

• Vorbereitung ist wichtiger als kluges Matching. Die Anreicherung von Entitäten mit Kontextinformationen im Vorfeld reduziert spätere Mehrdeutigkeiten erheblich.

• LLMs sind als Bewertungs- und nicht als Abrufsysteme am wertvollsten. Sie um eine Erklärung zu bitten, warum eine Übereinstimmung sinnvoll ist, ist weitaus wirkungsvoller als sie um eine Suche zu bitten.

• Zuverlässigkeit ermöglicht Genauigkeit. Der Funktionsaufruf hat nicht nur JSON bereinigt, sondern auch den Abruf von Informationen freigegeben, die bereits in der Abrufphase latent waren.

• Verallgemeinerung schlägt Spezialisierung. Eine kleine Anzahl gut gewählter Abstraktionen bewältigte Dutzende von Aufgabentypen ohne benutzerdefinierte Logik.

Aus diesem Grund ist der Prototyp bewusst Elasticsearch-nativ und konservativ in der Verwendung von LLMs. Das Ziel besteht nicht darin, das Suchen zu ersetzen. Es geht darum, das Suchen in Situationen erklärbar zu machen, in denen die Bedeutung wichtig ist.

Fazit

Die ultimative Herausforderung bestand nicht darin, perfekte Metriken zu verfolgen; es ging darum, eine grundlegendere Frage zu beantworten:

Kann eine transparente, suchbasierte, LLM-gestützte Architektur mit der Mehrdeutigkeit realer Entitäten umgehen, ohne in Regeln oder Blackboxes zu zerfallen?

Für diesen Bildungsprototyp lautet die Antwort ja, mit klaren Vorbehalten in Bezug auf Produktionshärtung, Compliance, Überwachung und Datenqualität. Wenn Sie Systeme erstellen, die begründen müssen, warum ein Entitätsabgleich vorgenommen wurde, ist dieses Muster eine ernsthafte Überlegung wert. Ich hoffe, diese Serie hat gezeigt, dass die Entitätsauflösung kein Mysterium sein muss. Mit der richtigen Aufteilung der Anliegen wird sie zu etwas, worüber man nachdenken, was man messen und verbessern kann.

Diese Arbeit deutet auch auf ein breiteres architektonisches Muster hin. Daraus entsteht eine leichte, aber wichtige Weiterentwicklung der klassischen Retrieval-Augmented-Generation (RAG). Anstatt die Abfrage direkt in die Generierung einfließen zu lassen, führen wir einen expliziten Bewertungsschritt ein. Das LLM wird zunächst zur Beurteilung und Plausibilitätsprüfung der abgerufenen Kandidaten verwendet, und nur die als geeignet befundenen Ergebnisse dürfen die Generierung erweitern. Sie können sich das als Generation-Augmented Retrieval-Augmented Generation with Evaluation oder GARAGE vorstellen, denn wer weiß nicht ein gutes Akronym zu schätzen?

Welche anderen Anwendungsfälle könnten von diesem Muster profitieren? Systeme, die Vertrauen, Transparenz und nachvollziehbare Argumentation erfordern, sind natürliche Kandidaten. Die künftige Arbeit in diesem Bereich sollte sich als ebenso überzeugend erweisen wie die Ergebnisse, die wir hier gesehen haben, und ich bin gespannt, wie sich die Gemeinschaft weiter entwickelt.

Nächste Schritte: Versuchen Sie es selbst

Möchten Sie die ultimative Herausforderung in Aktion sehen? Schauen Sie sich das Ultimate Challenge-Notebook für eine vollständige Anleitung mit realen Implementierungen, detaillierten Erklärungen und praktischen Beispielen an.

Die vollständige Pipeline zur Entitätsauflösung demonstriert die Kernkonzepte und die Architektur, die für den produktiven Einsatz erforderlich sind. Sie können es als Grundlage nutzen, um Systeme zu entwickeln, die Nachrichtenartikel überwachen, Erwähnungen von Entitäten verfolgen und Fragen beantworten, welche Entitäten in welchen Artikeln erscheinen – und das alles, während Transparenz und Erklärbarkeit erhalten bleiben.

1. Das neue Swift-Update ist da! Entwickler sind gespannt darauf, die neuen Features auszuprobieren.

2. Das neue Swift-Update ist da! Das neue Album erscheint nächsten Monat.

Mit diesem zusätzlichen Kontext sollten wir den Namen „Swift“ der richtigen Entität zuordnen können.

Im vorherigen Beitrag haben wir unsere Watchlist eingerichtet und die Entitäten mit zusätzlichem Kontext angereichert. Anhand unserer obigen Beispiele müssen wir mindestens die folgenden beiden Elemente in der Liste haben: Taylor Swift und Swift Programming Language. Wir haben auch besprochen, wie wir Entitätserwähnungen aus Text extrahieren. Beide Beispiele würden „Swift“ extrahieren. Mit diesen Zutaten, der angereicherten Watchlist und den extrahierten Entitäten, sind wir endlich bereit, den Star der Show vorzustellen: den Entitätsabgleich.

Denken Sie daran: Dies ist ein pädagogischer Prototyp, der entwickelt wurde, um Konzepte zum Abgleich von Entitäten zu vermitteln. Produktionssysteme könnten verschiedene große Sprachmodelle (LLMs), benutzerdefinierte Abgleichsregeln, spezialisierte Bewertungspipelines oder Ensemble-Ansätze verwenden, die mehrere Abgleichsstrategien kombinieren.

Das Problem: Warum der Abgleich schwierig ist

Die menschliche Sprache ist eine bemerkenswerte Sache. Eine ihrer interessantesten Eigenschaften ist ihre unendliche Kreativität. Wir können eine unendliche Anzahl neuer Sätze erzeugen und verstehen. Ist es dann verwunderlich, dass exakte Übereinstimmungen bei der Entitätsauflösung selten sind? Autoren bemühen sich, kreativ zu sein, wenn sie können. Es wäre ziemlich mühsam, wenn wir immer die vollständigen Namen schreiben und lesen müssten, wenn eine Entität erwähnt wird. Exakte Übereinstimmungen sind zwar einfach, aber die Realität sieht so aus, dass wir einen ausgefeilteren Ansatz zur Entitätsauflösung benötigen: einen, der robust genug ist, um zumindest einen Teil der grenzenlosen Kreativität menschlicher Autoren zu bewältigen. Deshalb unterteilen wir das Problem in zwei Schritte: Mit Elasticsearch werden plausible Kandidaten skaliert abgerufen, und anschließend wird mit einem LLM beurteilt, ob sich diese Kandidaten tatsächlich auf dieselbe reale Entität beziehen.

Die Lösung: Dreistufiger Abgleich mit transparenter LLM-Bewertung

Wir befinden uns mitten in einem Paradigmenwechsel in der Art und Weise, wie wir Computer nutzen. Genauso wie der Aufstieg des Internets uns vom lokalen Computing zu einem global vernetzten Netzwerk geführt hat, verändert die generative KI grundlegend die Art und Weise, wie Inhalte, Code und Informationen erstellt werden. Tatsächlich wurde der pädagogische Prototyp, der diese Serie begleitet, fast ausschließlich „Vibe-codiert“ unter Verwendung eines LLMs mit sorgfältiger Eingabe durch den Autor. Das soll nicht heißen, dass LLMs die Produktivität der menschlichen Sprache erreicht haben oder erreichen werden, aber es bedeutet, dass wir jetzt eine leistungsstarke Ressource haben, die uns bei der Entitätsauflösung unterstützt.

Ein häufiges Muster, das wir mit GenAI verwenden, ist Retrieval-Augmented Generation (RAG). Hier bedeutet Abrufen das Abrufen von Entitätskandidaten (nicht das Generieren von Antworten), und das LLM wird ausschließlich für die Bewertung und Erklärung von Übereinstimmungen verwendet. Obwohl wir ein LLM um Unterstützung bei der End-to-End-Lösung von Entitäten bitten könnten, ist das sowohl zeitlich als auch finanziell kostspielig. RAG hilft LLMs bei ihrer Arbeit, indem es effizientere Wege nutzt, um dem LLM Kontext bereitzustellen, und ermöglicht es dem LLM so, effizient bei der Entitätsauflösung zu helfen.

Für den Abrufteil von RAG greifen wir erneut auf Elasticsearch zurück. Zunächst ermitteln wir potenzielle Übereinstimmungen mithilfe einer Kombination aus exaktem Abgleich, Abgleich mit Aliasen und hybrider Suche, die Stichwort- und semantische Suche kombiniert. Sobald wir diese potenziellen Übereinstimmungen gefunden haben, schicken wir sie an ein LLM zur Bewertung. Das LLM fungiert als der letzte Übereinstimmungsbewerter. Wir lassen das LLM außerdem seine Argumentation erläutern, was ein wichtiges Unterscheidungsmerkmal zu anderen Entitätsauflösungssystemen darstellt. Ohne diese Erklärungen ist die Entitätsauflösung eine Blackbox; mit ihnen können wir selbst sehen, warum eine Übereinstimmung Sinn ergibt.

Schlüsselkonzepte: Drei-Schritte-Abgleich, hybride Suche und transparente LLM-Bewertung

Was ist der Drei-Schritte-Abgleich? Zu Beginn dieses Projekts haben wir die Hypothese aufgestellt, dass die semantische Suche ein entscheidender Bestandteil des Systems sein wird, aber nicht jeder Abgleich erfordert eine so ausgefeilte Suche. Um effizient Übereinstimmungen zu finden, gehen wir das Problem progressiv an. Zuerst überprüfen wir exakte Übereinstimmungen mit der Stichwortsuche. Wenn wir eine solche Übereinstimmung finden, ist unsere Arbeit getan und wir können weitermachen. Wenn der exakte Abgleich fehlschlägt, wenden wir uns dem Aliasabgleich zu. Im Prototyp wird der Einfachheit halber auch der Aliasabgleich mit Stichwörtern durchgeführt. In der Produktion können Sie diesen Schritt durch Normalisierung, Transliterationsregeln, Fuzzy Matching oder kuratierte Aliastabellen erweitern. Wenn wir in den ersten beiden Schritten immer noch keinen potenziellen Treffer gefunden haben, dann ist es an der Zeit, die semantische Suche über die hybride Suche von Elasticsearch mit Reciprocal Rank Fusion (RRF) einzuführen.

Was ist die hybride Suche? In Elasticsearch können wir die semantische Suche nutzen, um bedeutungsvolle Übereinstimmungen zu finden, die Kontext berücksichtigen. Elasticsearch wird häufig für Vektorsuche und hybride Abfrageverfahren eingesetzt. Semantische Ähnlichkeit ist sehr aussagekräftig, aber sie ist kein Ersatz für strukturiertes Filtern (z. B. nach Zeitspannen, Orten oder Identifikatoren) und ist oft unnötig, wenn eine exakte Übereinstimmung verfügbar ist. Elasticsearch hat sich mit der lexikalischen Suche einen Namen gemacht, die sich hervorragend für Aufgaben eignet, bei denen die semantische Suche nicht ausreicht. Um beide Ansätze voll auszuschöpfen, verwenden wir die lexikalische Suche neben der semantischen Suche in einer einzigen hybriden Abfrage. Anschließend führen wir die Ergebnisse zusammen, um mithilfe von RRF die wahrscheinlichsten Übereinstimmungen zu finden. Im Prototyp werden die oberen zwei Ergebnisse zu potenziellen Übereinstimmungen, die zur LLM-Bewertung gesendet werden können.

Warum die LLM-Bewertung? LLM-Bewertungen und -Erklärungen ermöglichen es unserem System, Ambiguität und Kontext transparent zu behandeln. Dies ist entscheidend für Fälle wie „der Präsident“, die sich auf mehrere Entitäten beziehen können, abhängig vom Kontext, aber es ermöglicht auch, dass Dinge wie Spitznamen und kulturelle Variationen gut im System funktionieren. Und schließlich müssen wir bei geschäftskritischen Aufgaben, wie der Identifizierung von Personen aus Sanktionslisten, wissen, warum ein Treffer akzeptiert wurde, um dem System vertrauen zu können. Entscheidend ist, dass das LLM nicht den gesamten Korpus durchsucht; es bewertet nur die kleine Anzahl von Kandidaten, die von Elasticsearch zurückgegeben werden.

Reale Ergebnisse: Übereinstimmung mit der LLM-Argumentation

Eine große Herausforderung bei jeder Aufgabe der natürlichen Sprachverarbeitung ist die Erstellung eines Referenzdokuments, eines „Lösungsschlüssels“, der uns mitteilt, was die zu erwartenden Ergebnisse sind. Ohne diese Grundlage ist es nahezu unmöglich zu beurteilen, wie gut ein System eine Aufgabe erfüllt. Doch die Erstellung eines solchen Dokuments kann ein mühsamer Prozess sein. Für den Prototyp zur Entitätsauflösung haben wir uns erneut an generative KI gewandt, um Unterstützung bei der Einrichtung von Testdaten zu erhalten.

Zunächst definierten wir mehrere Herausforderungstypen, wie Spitznamen und Transliteration, und baten dann das LLM, eine gestufte Sammlung von Datensätzen zu erstellen, die für das System zunehmend größer und anspruchsvoller werden sollte. Die Erstellung der Datensätze war weniger einfach, als man es sich erhoffen könnte. Das LLM hatte eine starke Neigung zum „Betrügen“, indem es zu einfach wurde, die richtige Antwort zu erhalten. Eine der Herausforderungen konzentrierte sich zum Beispiel auf den semantischen Kontext. Zu dieser Art gehörte beispielsweise die Auflösung von „russischer Autor“ zu „Leo Tolstoi“. Das LLM hat fälschlicherweise „russischer Autor“ als Alias für „Leo Tolstoi“ verwendet, was die Notwendigkeit einer Hybridsuche zum Finden der Übereinstimmung negierte.

Nach mehreren Refaktorierungen, um Probleme wie dieses zu beheben, hatten wir fünf Datensatzstufen, mit denen wir arbeiten konnten. Die Stufen 1–4 waren zunehmend größer und boten mehr Herausforderungstypen. Stufe 5 war der Datensatz der „ultimativen Herausforderung“, der aus den kniffligsten Beispielen aller Herausforderungstypen bestand. Sämtliche Testdaten sind im umfassenden Auswertungsverzeichnis verfügbar.

Zur Evaluierung unseres auf Eingabeaufforderungen basierenden Ansatzes zur Entitätsauflösung konzentrierten wir uns auf den Stufe-4-Datensatz. Ein wichtiger Hinweis ist, dass die Bewertung als kontrolliertes Experiment durchgeführt wurde, so dass wir uns auf die Qualität der Entitätsübereinstimmung konzentrieren konnten. Die Daten der Watchlist wurden vorab mit Kontext angereichert, und Entitäten wurden im Voraus aus dem Artikel extrahiert. Dadurch wurde sichergestellt, dass sich die Bewertung auf den Abgleich und nicht auf die Genauigkeit der Extraktion konzentrierte. Dies isoliert die Qualität der Übereinstimmungen; die Gesamtleistung hängt zusätzlich von der Trefferquote bei der Extraktion und der Qualität der Anreicherung ab.

Evaluationsdatensatz

Der Evaluierungsdatensatz der Stufe 4 bietet einen umfassenden Test der Leistungsfähigkeit des Systems:[1]

• Watchlist-Entitäten: 66 Entitäten unterschiedlichster Art (Personen, Organisationen, Standorte).

• Testartikel: 69 Artikel über reale Szenarien zur Auflösung von Entitäten.

• Erwartete Übereinstimmungen: 206 erwartete Entitätsübereinstimmungen in allen Artikeln.

• Herausforderungstypen: 15 verschiedene Herausforderungstypen, die verschiedene Aspekte der Entitätsauflösung prüfen.

Die in den Datensätzen enthaltenen Herausforderungstypen sind:

• Spitznamen: „Bob Smith“ → „Robert Smith“ (sieben Artikel).

• Titel und Ehrenbezeichnungen: „Dr. Sarah Williams“ → „Sarah Williams“ (fünf Artikel).

• Semantischer Kontext: „Russischer Autor“ → „Leo Tolstoi“ (acht Artikel).

• Mehrsprachige Namen: Umgang mit Namen in verschiedenen Skripten (sechs Artikel).

• Geschäftseinheiten: Variationen von Firmennamen (sieben Artikel).

• Referenzen von Führungskräften: „Microsoft CEO“ → „Satya Nadella“ (fünf Artikel).

• Politische Führungspersönlichkeiten: Titelbasierte Referenzen (fünf Artikel).

• Initialen: „J. Smith“ → „John Smith“ (drei Artikel).

• Varianten der Namensreihenfolge: Verschiedene Konventionen für die Namensreihenfolge (drei Artikel).

• Abgekürzte Namen: Teilweise Namensübereinstimmungen (drei Artikel).

• Namensaufteilung: Namen, die über Text verteilt sind (drei Artikel).

• Fehlende Leerzeichen/Bindestriche: Formatierungsabweichungen (zwei Artikel).

• Transliteration: Skriptübergreifender Namensabgleich (zwei Artikel).

• Kombinierte Herausforderungen: Mehrere Herausforderungen in einem Artikel (sechs Artikel).

• Komplexe Geschäftsbeziehungen: Hierarchische Geschäftsbeziehungen (fünf Artikel).

Mal sehen, wie die auf Eingabeaufforderungen basierende Entitätsauflösung funktioniert hat.

Gesamtleistung

Die Ergebnisse zeigen, dass die LLM-gestützte Übereinstimmungsbewertung vielversprechend ist, aber sie offenbaren auch ein erhebliches Zuverlässigkeitsproblem. Da jedes Kandidatenpaar vom LLM bewertet werden muss, können Fehler im strukturierten Ausgang die Akzeptanz und das Erinnern unterdrücken, selbst wenn der Abruf gut funktioniert.

Metrik

Wert

Präzision

83,8 %

Abruf

62,6 %

F1-Score

71,7 %

Gesamtanzahl der Übereinstimmungen

344

LLM-Annahmequote

44,8 %

Fehlerquote

30,2 %

Das Problem mit der Fehlerrate

Zur Erinnerung: Der erste Schritt im Prototyp besteht darin, mithilfe von Elasticsearch potenzielle Übereinstimmungspaare zu erstellen. Jede dieser potenziellen Übereinstimmungen muss vom LLM bewertet werden. Um all diese Übereinstimmungen effizient zu verarbeiten, fassen wir die LLM-Aufrufe in Batches zusammen. Dies reduziert die API-Kosten und die Latenzzeit, aber es besteht auch ein erhöhtes Risiko, dass der Ausgang fehlerhaftes JSON enthält. Mit zunehmender Batchgröße wird das JSON länger und komplexer, wodurch die Wahrscheinlichkeit steigt, dass der LLM ungültiges JSON generiert. Hier liegt der Ursprung der Fehlerquote von 30 %. In der Bewertung haben wir eine Batch-Größe von fünf Übereinstimmungen pro Anfrage verwendet. Selbst bei dieser konservativen Batchgröße beobachten wir immer noch JSON-Parsing-Fehler, welche die Auswertungsergebnisse erheblich verfälschen.

Nächstes Ziel: Optimierung der LLM-Integration

Nachdem wir nun Entitäten mithilfe semantischer Suche und LLM-Bewertung abgeglichen haben, verfügen wir über eine vollständige Entitätsauflösungspipeline. Dieser Ansatz führt jedoch einen neuen Ausfallmodus ein, wenn die Einschätzung des Modells richtig ist, sein Ausgang jedoch nicht nutzbar ist. Wir können die LLM-Integration im Hinblick auf höhere Zuverlässigkeit und Kosteneffizienz optimieren. Im nächsten Beitrag werden wir untersuchen, wie Sie Funktionsaufrufe für einen strukturierten Ausgang verwenden können, der garantierte Struktur- und Typsicherheit bietet und gleichzeitig Fehler und Kosten reduziert.

Probieren Sie es selbst aus

Möchten Sie den Entitätsabgleich in Aktion sehen? Schauen Sie sich das Entitätsabgleich-Notizbuch für eine vollständige Anleitung mit realen Implementierungen, detaillierten Erklärungen und praktischen Beispielen an. Das Notizbuch zeigt Ihnen genau, wie Sie Entitäten mithilfe der dreistufigen Suche, der hybriden Suche mit RRF und der LLM-gestützten Bewertung mit Schlussfolgerungen abgleichen.

Denken Sie daran: Dies ist ein pädagogischer Prototyp, der entwickelt wurde, um die Konzepte zu vermitteln. Bei der Entwicklung von Produktionssystemen sollten zusätzliche Faktoren wie Modellauswahl, Kostenoptimierung, Latenzanforderungen, Qualitätsvalidierung, Fehlerbehandlung und Überwachung berücksichtigt werden, die in diesem lernorientierten Prototyp nicht behandelt werden.

Anmerkungen

1. Diese Datensätze sind synthetisch und für Bildungszwecke konzipiert; sie nähern sich realen Herausforderungen an, sind aber nicht repräsentativ für eine einzelne Produktionsdomäne.

In diesem Artikel erfahren Sie, wie Sie den Parameter „Mindestscore“ verwenden können, um die Genauigkeit Ihrer semantischen Suchergebnisse zu erhöhen. Wenn Sie die in diesem Blogbeitrag bereitgestellten Beispiele testen möchten, besuchen Sie das zugehörige Jupyter-Notizbuch.

Hintergrund: Präzision und Abruf

In der Suchrelevanz sind Präzision und Recall Schlüsselkonzepte. Lesern, die noch nicht mit diesen Themen vertraut sind, wird dringend empfohlen, sich darüber zu informieren. Nachfolgend eine Zusammenfassung.

• Genauigkeit: Der Anteil der zurückgegebenen Suchergebnisse, die für den Nutzer relevant sind.

• Recall: Der Anteil aller relevanten Dokumente im Korpus, die in den Suchergebnissen enthalten sind.

Oder, mit anderen Worten, Präzision gibt nur relevante Ergebnisse zurück; und Recall gibt alle relevanten Ergebnisse zurück. Wie Sie sich vorstellen können, handelt es sich dabei oft um konkurrierende Anforderungen. Die semantische Suche weist tendenziell eine sehr hohe Trefferquote auf, hat aber mitunter Schwierigkeiten mit der Präzision. Lesen Sie weiter, um zu erfahren, wie Sie diese Eigenschaft umgehen können.

Einführung des Mindestscore-Parameters

Der ‘min_score’-Parameter ermöglicht es uns, die Präzision zu verbessern, indem ein Mindestscore festgelegt wird, der das Ergebnisset durch Entfernen aller Treffer mit einem Score unter dem definierten Schwellenwert kürzt. Nachfolgend ein einfaches Beispiel:

Normalisierung des Scores

Die Festlegung eines Mindestscores ist schön und gut, aber nicht alle semantischen Modelle liefern einen Score, die sich für einen statischen Schwellenwert eignet. ELSER gibt beispielsweise einen unbegrenzten Score zurück. Einige Scores des dichten Modells sind eng gruppiert und nur im Zusammenhang mit der spezifischen Anfrage sinnvoll.

Für die meisten Fälle der semantischen Suche empfehlen wir, vor der Anwendung von „min_score“ einen Normalisierungsansatz zu verwenden. Durch die Normalisierung wird sichergestellt, dass der Dokumentenscore innerhalb eines definierten Intervalls liegt. Elasticsearch-Retriever bieten zwei solcher Normalisierer, ‘l2_norm’ und ‘minmax’. Am häufigsten wird die „minmax“-Methode verwendet, da sie leicht verständlich ist und in vielen Szenarien gut funktioniert. Wichtige Eigenschaften von ‘minmax’ umfassen:

• Die Dokumentenscores liegen im Bereich von 0 bis 1.

• Das Dokument mit der höchsten Punktzahl erhält immer den Score 1.

• Das Dokument mit der niedrigsten Punktzahl erhält immer den Score 0.

  • Dies kann die Eignung für die Stichwortsuche beeinträchtigen. Weitere Informationen finden Sie im Abschnitt „Hybride Suche“.

Im Folgenden ein Beispiel für eine normalisierte semantische Abfrage mit min_score. Die Größe des Ranking-Fensters wurde auf 500 erhöht, damit wir eine längere Liste von Suchergebnissen zurückgeben können, angefangen bei 100.

Die Größe wurde auf einen höheren Wert als in der Produktion üblich eingestellt. So können wir die Qualität der Suchergebnisse inspizieren und die Ergebnisse optimieren.

Hybridsuche mit dem linearen Retriever

Für die Hybridsuche ist der einfachste Ansatz, alle Scores zu normalisieren, Gewichte zuzuweisen und einen Mindestscore anzuwenden. Beachten Sie, dass Sie durch die Wahl von Gewichtungen mit einer Summe von 1 den Gesamtscore innerhalb eines Bereichs von 0 bis 1 halten. Dadurch lassen sich die Endergebnisse leicht nachvollziehen und die Melodie min_score stimmen. Nachfolgend ein Beispiel:

Hybridsuche mit RRF

Mit BM25 steuern wir die Präzision oft durch andere Mittel, wie die Verwendung des AND-Operators oder minimum_should_match. Darüber hinaus werden Abfragen, die aus einzelnen, präzisen und seltenen Begriffen bestehen, natürlicherweise zu Suchergebnissen mit wenigen Suchergebnissen führen, die oft alle hochrelevant sind. Dies kann zu Folgendem führen:

• Ergebnisse, die weiter hinten im Ergebnis stehen, erhalten im BM25-Retriever einen niedrigen normalisierten Score, selbst wenn der absolute BM25-Score nahe an den Treffern mit den höchsten Scores liegt.

• Wenn ein sehr niedriger BM25-Score zum semantischen Score hinzugefügt wird, kann die Summe als semantischer Score approximiert werden.

• Das Fehlen eines BM25-Score-Beitrags kann dazu führen, dass das Dokument von min_score threshold verworfen wird.

Als Lösung können wir stattdessen die reziproke Rangfusion (RRF) verwenden, um BM25- und semantische Ergebnisse zu kombinieren. RRF umgeht die Herausforderung, Scores verschiedener Suchalgorithmen zu vergleichen, indem es sich stattdessen auf die Position in jedem Ergebnis auf konzentriert. In diesem Szenario wird die min_score nur auf den semantischen Retriever angewendet.

Fazit

Mit min_score haben wir gezeigt, wie wir die Anzahl der Fehlalarme in unseren Ergebnissätzen reduzieren können, die durch den hohen Recall semantischer Suchalgorithmen verursacht werden. Um mehr über Retriever zu erfahren, siehe bitte diesen Blogbeitrag und die Elasticsearch-Dokumentation.

Benutzerdefinierte Konnektoren ermöglichen es Ihnen, Ihre vorhandenen ChatGPT-Konnektoren mit zusätzlichen Datenquellen wie Elasticsearch zu kombinieren, um umfassende Antworten zu erhalten.

In diesem Artikel werden wir einen MCP-Server erstellen, der ChatGPT mit einem Elasticsearch-Index verbindet, der Informationen zu internen GitHub Issues und Pull Requests enthält. So können Abfragen in natürlicher Sprache mit Ihren Elasticsearch-Daten beantwortet werden.

Wir werden den MCP-Server mithilfe von FastMCP auf Google Colab mit ngrok bereitstellen, um eine öffentliche URL zu erhalten, mit der ChatGPT eine Verbindung herstellen kann. Dadurch entfällt die Notwendigkeit einer komplexen Infrastruktureinrichtung.

Einen umfassenden Überblick über MCP und sein Ökosystem finden Sie unter „Der aktuelle Stand von MCP“.

Voraussetzungen

Vor Beginn benötigen Sie Folgendes:

• Elasticsearch-Cluster (8.X oder höher)

• Elasticsearch-API-Schlüssel mit Lesezugriff auf Ihren Index

• Google-Konto (für Google Colab)

• Ngrok-Konto (das kostenlose Abo genügt)

• ChatGPT-Konto mit Pro-, Enterprise-, Business- oder Edu-Plan

Die Anforderungen für ChatGPT MCP-Konnektoren verstehen

Für die ChatGPT MCP-Konnektoren müssen zwei Tools implementiert werden: search und fetch. Weitere Einzelheiten finden Sie in den OpenAI Dokumenten.

Suchtool

Gibt eine Liste relevanter Ergebnisse aus Ihrem Elasticsearch-Index auf der Grundlage einer Benutzerabfrage zurück.

Das erhält es:

• Eine einzelne Zeichenfolge mit der Anfrage des Benutzers in natürlicher Sprache.

• Beispiel: „Finde Probleme im Zusammenhang mit der Elasticsearch-Migration.“

Was es zurückgibt: 

• Ein Objekt mit einem result-Schlüssel, der ein Array von result-Objekten enthält. Jedes Ergebnis umfasst:

  • id - Eindeutige Dokumentkennung

  • title - Titel eines Issues oder Pull Requests (PR)

  • url - Link zum Issue/PR

In unserer Implementierung:

Abrufwerkzeug

Ruft den vollständigen Inhalt eines bestimmten Dokuments ab.

Das erhält es:

• Eine einzelne Zeichenfolge mit der Elasticsearch-Dokument-ID aus dem Suchergebnis

• Beispiel: „Nenne mir die Details zum PR-578.“

Was es zurückgibt:

• Ein vollständiges Dokumentobjekt mit:

  • id - Eindeutige Dokumentkennung

  • title - Titel eines Issues oder Pull Requests (PR)

  • text - Vollständige Beschreibung und Details des Problems/PR

  • url - Link zum Issue/PR

  • type - Dokumenttyp (Issue, Pull-Request)

  • status - Aktueller Status (offen, in Bearbeitung, abgeschlossen)

  • priority - Prioritätsstufe (niedrig, mittel, hoch, kritisch)

  • assignee - Person, der das Issue/der PR zugewiesen wurde

  • created_date - Erstellungsdatum

  • resolved_date - Wann das Issue gelöst wurde (falls zutreffend)

  • labels - Mit dem Dokument verbundene Tags

  • related_pr - Verwandte Pull-Request-ID

Hinweis: In diesem Beispiel wird eine flache Struktur verwendet, bei der sich alle Felder auf der Stammebene befinden. Die Anforderungen von OpenAI sind flexibel und unterstützen auch verschachtelte Metadatenobjekte.

Datensatz zu GitHub Issues und Pull Requests

Für dieses Tutorial verwenden wir einen internen GitHub Datensatz mit Issues und Pull Requests. Dies stellt ein Szenario dar, in dem Sie private, interne Daten über ChatGPT abfragen möchten.

Den Datensätze finden Sie hier. Wir werden außerdem den Index der Daten mit der Bulk-API aktualisieren.

Dieser Datensatz umfasst:

• Issues mit Beschreibungen, Status, Priorität und Zuweisungen

• Pull-Requests mit Codeänderungen, Bewertungen und Deployment-Informationen

• Beziehungen zwischen Issues und PRs (z. B. PR-578 behebt ISSUE-1889)

• Labels, Daten und andere Metadaten

Index-Mappings

Der Index verwendet die folgenden Mappings, um die hybride Suche mit ELSER zu unterstützen. Das text_semantic wird für die semantische Suche verwendet, während andere Felder die Schlüsselwortsuchen ermöglichen.

Den MCP-Server erstellen

Unser MCP-Server implementiert zwei Tools gemäß den OpenAI Spezifikationen und verwendet die hybride Suche, um den semantischen und den textbasierten Abgleich für bessere Ergebnisse zu kombinieren.

Suchtool

Nutzt hybride Suche mit RRF (Reciprocal Rank Fusion), die semantische Suche mit Textabgleich kombiniert:

Wichtige Punkte:

• Hybride Suche mit RRF: Kombiniert semantische Suche (ELSER) und Text-Suche (BM25) für bessere Ergebnisse.

• Multi-Match-Abfrage: Sucht über mehrere Felder hinweg mit Boosting (title^3, text^2, assignee^2). Das Caret-Symbol (^) multipliziert die Relevanzwerte und priorisiert dabei Treffer in Titeln gegenüber solchen im Inhalt.

• Fuzzy-Matching: fuzziness: AUTO behebt Tippfehler und Rechtschreibfehler, indem es ungefähre Übereinstimmungen erlaubt.

• RRF-Parameterabstimmung:

  • rank_window_size: 50 - Legt fest, wie viele Top-Ergebnisse von jedem Retriever (semantische und textbasierte) vor dem Zusammenführen berücksichtigt werden.

  • rank_constant: 60 - Dieser Wert bestimmt, wie viel Einfluss Dokumente in einzelnen Ergebnismengen auf das endgültige Ranking haben.

• Gibt nur die erforderlichen Felder zurück: id, title, url gemäß OpenAI-Spezifikation, und vermeidet das unnötige Freilegen zusätzlicher Felder.

Abrufwerkzeug

Ruft Dokumentdetails anhand der Dokumenten-ID ab, sofern vorhanden:

Wichtige Punkte:

• Suchen nach Dokumenten-ID-Feld: Verwendet eine Begriffsabfrage im benutzerdefinierten id-Feld.

• Vollständige Rückgabe des Dokuments: Mit vollständigem text-Feld mit allen Inhalten

• Flache Struktur: Alle Felder auf der Wurzelebene, entsprechend der Dokumentstruktur von Elasticsearch.

Bereitstellung auf Google Colab

Wir nutzen Google Colab, um unseren MCP-Server zu betreiben, und ngrok, um ihn öffentlich zugänglich zu machen, damit ChatGPT eine Verbindung herstellen kann.

Schritt 1: Öffnen Sie das Google Colab Notebook

Greifen Sie auf unser vorkonfiguriertes Notebook Elasticsearch MCP für ChatGPT zu.

Schritt 2: Konfigurieren Sie Ihre Anmeldeinformationen

Sie benötigen drei Informationen:

• Elasticsearch URL: Ihre Elasticsearch-Cluster-URL.

• Elasticsearch API-Schlüssel: API-Schlüssel mit Lesezugriff auf Ihren Index.

• Ngrok-Auth-Token: Kostenloses Token von ngrok. Wir nutzen ngrok, um die MCP-URL im Internet sichtbar zu machen, damit ChatGPT sich damit verbinden kann.

So erhalten Sie Ihr ngrok-Token

1. Registrieren Sie sich für ein kostenloses Konto bei ngrok

2. Gehe zu Ihrem Dashboard

3. Kopieren Sie Ihr Authentifizierungs-Token

Secrets zu Google Colab hinzufügen

Im Google Colab-Notizbuch:

1. Klicken Sie auf das Schlüsselsymbol in der linken Seitenleiste, um Secrets zu öffnen.

2. Fügen Sie diese drei Secrets hinzu:

3. Aktivieren Sie den Notebook-Zugriff für jedes Secret.

Schritt 3: Führen Sie das Notebook aus

1. Klicken Sie auf Runtime und dann auf alle ausführen, um alle Zellen auszuführen.

2. Warten Sie, bis der Server startet (etwa 30 Sekunden)

3. Suchen Sie nach der Ausgabe, die Ihre öffentliche ngrok-URL anzeigt.

4. Die Ausgabe sieht in etwa so aus:

Mit ChatGPT verbinden

Nun verbinden wir den MCP-Server mit Ihrem ChatGPT-Konto.

1. Öffnen Sie ChatGPT und gehen Sie zu Einstellungen.

2. Navigieren Sie zu Konnektoren. Wenn Sie ein Pro-Konto nutzen, müssen Sie den Entwicklermodus in den Konnektoren aktivieren.

Wenn Sie ChatGPT Enterprise oder Business verwenden, müssen Sie den Konnektor an Ihrem Workspace veröffentlichen.

3. Klicken Sie auf Erstellen.

Hinweis: In Business-, Enterprise- und Edu-Workspaces können nur Workspace-Inhaber, Administratoren sowie Benutzer, bei denen die entsprechende Einstellung aktiviert ist (für Enterprise/Edu), benutzerdefinierte Konnektoren hinzufügen. Benutzer mit der regulären Mitgliederrolle sind nicht berechtigt, selbst benutzerdefinierte Konnektoren hinzuzufügen.

Sobald ein Konnektor von einem Benutzer mit der Inhaber- oder Admin-Rolle hinzugefügt und aktiviert wurde, kann er von allen Mitgliedern des Workspaces verwendet werden.

4. Geben Sie die erforderlichen Informationen ein sowie Ihre ngrok-URL, die mit /sse/ endet. Beachten Sie den „/“ nach „sse“. Ohne diesen funktioniert es nicht:

• Name: Elasticsearch MCP

• Beschreibung: Benutzerdefiniertes MCP zum Suchen und Abrufen von internen GitHub-Informationen.

5. Klicken Sie auf Erstellen, um das benutzerdefinierte MCP zu speichern.

Die Verbindung ist sofort hergestellt, wenn Ihr Server läuft. Keine zusätzliche Authentifizierung ist erforderlich, da der Elasticsearch-API-Schlüssel auf Ihrem Server konfiguriert ist.

Teste den MCP-Server

Bevor Sie Fragen stellen, müssen Sie auswählen, welchen Konnektor ChatGPT verwenden soll.

Aufforderung 1: Nach Problemen suchen

Anfrage: „Finde Probleme im Zusammenhang mit der Elasticsearch-Migration“ und bestätigen Sie die Aktionen des aufgerufenen Tools.

ChatGPT wird das Tool search mit Ihrer Abfrage aufrufen. Sie können sehen, dass es nach verfügbaren Tools sucht, sich darauf vorbereitet, das Elasticsearch-Tool aufzurufen. Vor jeglichen Aktionen gegenüber dem Tool wird die Bestätigung des Benutzers eingeholt.

Anfrage zum Aufruf des Tools:

Reaktion des Tools:

ChatGPT verarbeitet die Ergebnisse und präsentiert sie in einem natürlichen, gesprächsorientierten Format.

Hinter den Kulissen

Prompt: „Finde Probleme im Zusammenhang mit der Elasticsearch-Migration.“

1. ChatGPT-Anrufe search(“Elasticsearch migration”)

2. Elasticsearch führt eine hybride Suche durch.

• Die semantische Suche versteht Konzepte wie „Upgrade“ und „Versionskompatibilität“.

• Die Textsuche findet exakte Treffer für „Elasticsearch“ und „Migration“.

• RRF kombiniert und bewertet Ergebnisse beider Ansätze

3. Sie gibt die 10 am besten mit id, title, übereinstimmenden Ergebnisse zurück url

4. ChatGPT identifiziert „ISSUE-1712: Migration von Elasticsearch 7.x auf 8.x“ als relevantestes Ergebnis.

Prompt 2: Nenne mir die vollständigen Details

Anfrage: „Nenne mir die Details zu ISSUE-1889“

ChatGPT erkennt, dass Sie detaillierte Informationen zu einem bestimmten Problem wünschen, ruft das Tool fetch auf holt beim Benutzer die Bestätigung ein, bevor Maßnahmen gegen das Tool ergriffen werden.

Anfrage zum Aufruf des Tools:

Reaktion des Tools:

ChatGPT fasst die Informationen zusammen und präsentiert sie übersichtlich.

Hinter den Kulissen

Prompt: „Nenne mir die Details von ISSUE-1889“

1. ChatGPT-Anrufe fetch(“ISSUE-1889”)

2. Elasticsearch ruft das vollständige Dokument ab

3. Gibt ein vollständiges Dokument mit allen Feldern auf der Stammebene zurück

4. ChatGPT synthetisiert die Informationen und antwortet mit korrekten Zitaten.

Fazit

In diesem Artikel haben wir einen maßgeschneiderten MCP-Server erstellt, der ChatGPT mit Elasticsearch über spezielle Such- und Abruf--MCP-Tools verbindet und so natürliche Sprachanfragen zu privaten Daten ermöglicht.

Dieses MCP-Muster funktioniert für jeden Elasticsearch-Index, jede Dokumentation, jedes Produkt, jedes Log oder andere Daten, die Sie über natürliche Sprache abfragen möchten.

Das Problem der Punktespanne

Um die Ausgangslage zu verdeutlichen, betrachten wir zunächst einen der Hauptgründe, warum die hybride Suche schwierig sein kann: die variierenden Bewertungsbereiche. Unser alter Bekannter BM25 liefert unbegrenzte Ergebnisse. Mit anderen Worten: BM25 kann Werte generieren, die von nahe 0 bis (theoretisch) unendlich reichen. Im Gegensatz dazu liefern Abfragen gegen dense_vector -Felder Ergebnisse im Bereich zwischen 0 und 1. Erschwerend kommt hinzu, dass semantic_text den Feldtyp verschleiert, der zur Indizierung von Einbettungen verwendet wird. Daher ist es ohne detaillierte Kenntnisse über die Konfiguration Ihres Index und Inferenzendpunkts schwierig abzuschätzen, in welchem Bereich die Ergebnisse Ihrer Abfrage liegen werden. Dies stellt ein Problem dar, wenn versucht wird, lexikalische und semantische Suchergebnisse zu verschachteln, da die lexikalischen Ergebnisse Vorrang vor den semantischen haben können, selbst wenn die semantischen Ergebnisse relevanter sind. Die allgemein anerkannte Lösung für dieses Problem besteht darin, die Werte vor der Verschachtelung der Ergebnisse zu normalisieren. Elasticsearch bietet hierfür zwei Tools an: den linearen und den RRF- Retriever.

Der RRF- Retriever wendet den RRF-Algorithmus an, wobei der Dokumentenrang als Relevanzmaß verwendet und der Score verworfen wird. Da die Punktzahl nicht berücksichtigt wird, stellen Abweichungen im Punktzahlbereich kein Problem dar.

Der lineare Retriever verwendet eine lineare Kombination, um die endgültige Punktzahl eines Dokuments zu bestimmen. Dabei wird für jede einzelne Abfrage die Punktzahl der Komponenten des Dokuments ermittelt, normalisiert und anschließend summiert, um die Gesamtpunktzahl zu erhalten. Mathematisch lässt sich die Operation wie folgt ausdrücken:

Dabei ist N die Normalisierungsfunktion und SX die Punktzahl für die Anfrage X. Die Normalisierungsfunktion ist hierbei von zentraler Bedeutung, da sie die Punktzahl jeder Abfrage so transformiert, dass sie denselben Wertebereich verwendet. Hier erfahren Sie mehr über den linearen Retriever.

Aufgeschlüsselt

Mit diesen Tools können Benutzer eine effektive Hybridsuche implementieren, dies erfordert jedoch gewisse Kenntnisse über ihren Index. Betrachten wir ein Beispiel mit dem linearen Retriever, bei dem wir einen Index mit zwei Feldern abfragen:

1. semantic_text_field ist ein semantic_text -Feld, das E5, ein Text-Embedding-Modell, verwendet.

2. text_field ist ein Standard- text -Feld

1. Wir verwenden eine match -Abfrage für unser semantic_text -Feld, dessen Unterstützung wir in Elasticsearch 8.18/9.0 hinzugefügt haben.

Bei der Erstellung der Abfrage müssen wir berücksichtigen, dass semantic_text_field ein Text-Embedding-Modell verwendet, sodass alle Abfragen darauf eine Punktzahl zwischen 0 und 1 generieren. Wir müssen außerdem wissen, dass text_field ein Standardfeld text ist und dass Abfragen darauf eine unbegrenzte Punktzahl erzeugen. Um ein Ergebnis-Set mit der richtigen Relevanz zu erstellen, müssen wir einen Retriever verwenden, der die Abfrage-Scores normalisiert, bevor er sie kombiniert. In diesem Beispiel verwenden wir den linearen Retriever mit minmax -Normalisierung, der den Score jeder Abfrage auf einen Wert zwischen 0 und 1 normalisiert.

Die Abfragekonstruktion in diesem Beispiel ist recht einfach, da nur zwei Felder beteiligt sind. Allerdings kann es sehr schnell kompliziert werden, wenn weitere Felder unterschiedlicher Art hinzugefügt werden. Dies zeigt, dass das Schreiben einer effektiven hybriden Suchanfrage oft ein tieferes Verständnis des abgefragten Index erfordert, damit die Punktzahlen der einzelnen Suchanfragen vor der Kombination richtig normalisiert werden. Dies stellt ein Hindernis für die breitere Akzeptanz der hybriden Suche dar.

Abfragegruppierung

Erweitern wir das Beispiel: Was wäre, wenn wir ein text -Feld und zwei semantic_text -Felder abfragen wollten? Wir könnten eine Abfrage wie diese erstellen:

Das klingt auf den ersten Blick gut, aber es gibt ein potenzielles Problem. Die Treffer im Feld semantic_text machen nun ⅔ der Gesamtpunktzahl aus:

Das ist wahrscheinlich nicht das, was Sie wollen, denn dadurch entsteht ein unausgewogenes Ergebnis. Die Auswirkungen sind in einem Beispiel wie diesem mit nur 3 Feldern möglicherweise nicht so deutlich erkennbar, aber es wird problematisch, wenn mehr Felder abgefragt werden. Beispielsweise enthalten die meisten Indizes weitaus mehr lexikalische als semantische Felder (d. h. dense_vector, sparse_vector, oder semantic_text). Was wäre, wenn wir einen Index mit 9 lexikalischen Feldern und 1 semantischen Feld nach dem oben genannten Muster abfragen würden? Die lexikalischen Übereinstimmungen würden 90 % der Punktzahl ausmachen und somit die Effektivität der semantischen Suche beeinträchtigen.

Eine gängige Methode, um diesem Problem zu begegnen, besteht darin, Anfragen in lexikalische und semantische Kategorien zu gruppieren und beide gleich zu gewichten. Dadurch wird verhindert, dass eine der beiden Kategorien die Gesamtpunktzahl dominiert.

Lasst uns das in die Praxis umsetzen. Wie sähe dieser Ansatz mit gruppierten Abfragen in diesem Beispiel bei Verwendung des linearen Retrievers aus?

Wow, das wird aber ausführlich! Möglicherweise mussten Sie sogar mehrmals auf- und abscrollen, um die gesamte Abfrage zu prüfen! Hier verwenden wir zwei Normalisierungsebenen, um die Abfragegruppen zu erstellen. Mathematisch lässt sich dies wie folgt ausdrücken:

Diese zweite Normalisierungsebene stellt sicher, dass die Anfragen an die Felder semantic_text und text gleich gewichtet werden. Beachten Sie, dass wir in diesem Beispiel die Normalisierung zweiter Ebene für text_field weglassen, da es nur ein lexikalisches Feld gibt, wodurch Sie sich noch mehr Ausführlichkeit ersparen.

Diese Abfragestruktur ist schon jetzt unhandlich, und wir fragen nur drei Felder ab. Je mehr Felder man abfragt, desto unübersichtlicher wird es, selbst für erfahrene Suchmaschinenexperten.

Das Abfrageformat mit mehreren Feldern

Um das Ganze zu vereinfachen, haben wir das Multi-Field-Abfrageformat für die linearen und RRF-Retriever in Elasticsearch 8.19, 9.1 und Serverless hinzugefügt. Sie können die gleiche Abfrage wie oben nun mit folgendem Befehl durchführen:

Dadurch verkürzt sich die Abfrage von 55 Zeilen auf nur noch 9! Elasticsearch verwendet automatisch die Indexzuordnungen für:

• Ermitteln Sie den Typ jedes abgefragten Feldes.

• Ordnen Sie jedes Feld einer lexikalischen oder semantischen Kategorie zu.

• Jede Kategorie sollte im Endergebnis gleich gewichtet werden.

Dies ermöglicht es jedem, eine effektive hybride Suchanfrage auszuführen, ohne Details über den Index oder die verwendeten Inferenzendpunkte kennen zu müssen.

Bei Verwendung von RRF kann das normalizer weggelassen werden, da der Rang als Indikator für die Relevanz dient:

Steigerung pro Spielfeld

Bei Verwendung des linearen Retrievers können Sie eine Gewichtung pro Feld anwenden, um die Wichtigkeit von Übereinstimmungen in bestimmten Feldern anzupassen. Nehmen wir beispielsweise an, Sie fragen vier Felder ab: zwei semantic_text -Felder und zwei text -Felder:

Standardmäßig wird jedes Feld innerhalb seiner Gruppe (lexikalisch oder semantisch) gleich gewichtet. Die Punkteverteilung sieht wie folgt aus:

Mit anderen Worten: Jedes Feld macht 25 % der Gesamtpunktzahl aus.

Mit der Syntax field^boost können wir jedem Feld einen feldbezogenen Boost hinzufügen. Wenden wir einen Boost von 2 auf semantic_text_field_1 und text_field_1 an:

Die Aufschlüsselung der Punkte sieht nun wie folgt aus:

Jede Abfragegruppe ist weiterhin gleich gewichtet, aber die Feldgewichtung innerhalb der Gruppen hat sich geändert:

• semantic_text_field_1 entspricht 66 % der Punktzahl der semantischen Abfragegruppe und 33 % der Gesamtpunktzahl.

• text_field_1 macht 66 % der Punktzahl der lexikalischen Abfragegruppe und 33 % der Gesamtpunktzahl aus.

ℹ️ Beachten Sie, dass sich die Gesamtpunktzahl nicht ändert, wenn ein Bonus pro Feld angewendet wird. Dies ist ein beabsichtigter Nebeneffekt der Score-Normalisierung, der sicherstellt, dass lexikalische und semantische Anfrage-Scores direkt miteinander vergleichbar bleiben.

ℹ️ Die feldbezogene Gewichtung kann auch mit dem RRF-Retriever in Elasticsearch 9.2+ verwendet werden.

Wildcard-Auflösung

Sie können das Platzhalterzeichen * im Parameter fields verwenden, um mehrere Felder abzugleichen. Um das obige Beispiel fortzuführen: Diese Abfrage ist funktional äquivalent zur expliziten Abfrage von semantic_text_field_1, semantic_text_field_2, und text_field_1 :

Interessanterweise passt das Muster *_field_1 sowohl zu text_field_1 als auch semantic_text_field_1. Dies wird automatisch gehandhabt; die Abfrage wird so ausgeführt, als ob jedes der Felder explizit abgefragt würde. Es ist auch in Ordnung, dass semantic_text_field_1 beiden Mustern entspricht; alle Feldnamenübereinstimmungen werden vor der Abfrageausführung dedupliziert.

Sie können das Wildcard-Zeichen auf verschiedene Arten verwenden:

• Präfixübereinstimmung (z. B. *_text_field)

• Inline-Matching (z. B. semantic_*_field)

• Suffix-Matching (z. B. semantic_text_field_*)

Sie können auch mehrere Platzhalter verwenden, um eine Kombination der oben genannten anzuwenden, z. B. *_text_field_*.

Standardabfragefelder

Das Abfrageformat mit mehreren Feldern ermöglicht es Ihnen auch, einen Index abzufragen, über den Sie nichts wissen. Wenn Sie den Parameter fields weglassen, werden alle Felder abgefragt, die durch die Indexeinstellung index.query.default_field angegeben sind:

Standardmäßig ist index.query.default_field auf * gesetzt. Dieser Platzhalter wird auf jeden Feldtyp im Index aufgelöst, der Termabfragen unterstützt, was auf die meisten zutrifft. Die Ausnahmen sind:

• dense_vector Felder

• rank_vector Felder

• Geometrische Felder: geo_point, shape

Diese Funktionalität ist besonders nützlich, wenn Sie eine hybride Suchanfrage auf einem von einem Drittanbieter bereitgestellten Index durchführen möchten. Das Abfrageformat mit mehreren Feldern ermöglicht es Ihnen, auf einfache Weise eine passende Abfrage auszuführen. Lassen Sie einfach den Parameter fields weg, und alle relevanten Felder werden abgefragt.

Fazit

Das Problem der Bewertungsbereiche kann die Implementierung einer effektiven hybriden Suche zu einer echten Herausforderung machen, insbesondere wenn nur begrenzter Einblick in den abgefragten Index oder die verwendeten Inferenzendpunkte besteht. Das Mehrfeld-Abfrageformat für die linearen und RRF-Retriever mindert dieses Problem, indem es einen automatisierten, auf Abfragegruppierung basierenden hybriden Suchansatz in einer einfachen und zugänglichen API bündelt. Zusätzliche Funktionen wie die Gewichtung einzelner Felder, die Auflösung von Platzhaltern und die Verwendung von Standardabfragefeldern erweitern den Funktionsumfang und decken viele Anwendungsfälle ab.

Probieren Sie heute noch das Abfrageformat mit mehreren Feldern aus.

Sie können die linearen und RRF-Retriever mit dem Multi-Field-Query-Format in vollständig verwalteten Elasticsearch Serverless- Projekten mit einer kostenlosen Testversion ausprobieren. Es ist auch in Stack-Versionen ab 8.19 und 9.1 verfügbar.

Legen Sie in wenigen Minuten in Ihrer lokalen Umgebung mit einem einzigen Befehl los:

Die Suche ist nicht tot, sie hat sich nur verlagert.

Wir haben also einen Wandel erlebt: von der primären Suche nach Kontext über ein Textfeld und der Verwendung der zurückgegebenen Informationen (des Kontexts), um die Antworten selbst zu konstruieren, hin zur Verwendung natürlicher Sprache, um einem Agenten mitzuteilen, was wir wollen, und lassen ihn die Antwort automatisch für uns recherchieren und zusammenstellen. Viele in der Tech-Welt verweisen auf diesen Wandel und verkünden, dass „Suche tot ist“ (nun ja, die SEO- und AdWords-Welt verändert sich definitiv: GEO, irgendjemand?), aber die Suche ist für operative Abläufe immer noch absolut entscheidend – sie wird nur heute größtenteils im Verborgenen mithilfe von Tools durchgeführt.

Bisher waren Menschen die Hauptverantwortlichen für die Beurteilung der subjektiven Relevanz: Jeder Nutzer hatte seine eigenen Gründe für die Durchführung der Suche, und seine persönlichen Erfahrungen prägten die relative Genauigkeit der Ergebnisse. Wenn wir darauf vertrauen sollen, dass Agenten zu demselben (oder einem besseren) Schluss kommen können, zu dem wir gekommen wären, müssen wir sicherstellen, dass die Kontextinformationen, auf die sie Zugriff haben, so nah wie möglich an unserer subjektiven Absicht liegen. Wir müssen den Kontext, den wir LLMs bieten, auf dieses Ziel ausrichten!

Kontextgenerierung mit hybrider Suchabfrage

Zur Erinnerung an Teil I: Die Hybridsuche von Elastic kombiniert die Stärken der traditionellen schlüsselwortbasierten Suche (Syntaxflexibilität, Schlüsselwortgenauigkeit und Relevanzbewertung) mit dem semantischen Verständnis der Vektorähnlichkeitssuche und bietet mehrere Reranking-Techniken. Diese Synergie (eine treffendere Verwendung dieses Wortes wurde noch nie gefunden!) ermöglicht hochrelevante Ergebnisse mit Suchanfragen, die wesentlich differenzierter auf die Inhalte abzielen. Es geht nicht nur darum, dass man die subjektive Relevanz als eine der Abrufphasen anwenden kann; es geht vielmehr darum, dass der Abruf in der ersten Phase die Relevanzbewertung zusammen mit all diesen anderen Modi gleichzeitig beinhalten kann.

Überragende Genauigkeit und Effizienz

Die Verwendung einer Datenplattform, die verteilte Suche, Abfrage und Neubewertung als primäre Kontextabfrage-Engine ermöglicht, ist sehr sinnvoll. Sie können eine erweiterte Abfragesyntax verwenden, um die fehlende Komponente der subjektiven Absicht hinzuzufügen und Inhalte herauszufiltern, die vom Wert der zurückgegebenen Kontextinformationen ablenken oder diesen verfälschen könnten. Sie können aus den verfügbaren Syntaxoptionen auswählen oder Modalitäten zu einer einzigen Suche kombinieren, die auf jeden Datentyp auf die für ihn beste Weise abzielt, und diese dann mit Reranking kombinieren/neu anordnen. Sie können die Antwort so filtern, dass sie nur die gewünschten Felder/Werte enthält und überflüssige Daten fernhält. Im Dienste der Agenten ermöglicht diese Targeting-Flexibilität die Entwicklung von Tools, die äußerst präzise beim Abrufen von Kontextinformationen sind.

Kontextverfeinerung (Aggregationen und nicht-inhaltliche Signale)

Aggregationen können besonders nützlich sein, um den Inhalt zu gestalten, den ein Tool im Kontextfenster anzeigt. Aggregationen liefern naturgemäß numerisch basierte Fakten über die Struktur der zurückgegebenen Kontextdaten, was es LLMs erleichtert und genauer macht, darüber zu argumentieren. Da Aggregationen hierarchisch verschachtelt werden können, ist dies eine einfache Möglichkeit, dem LLM mehrstufige Details hinzuzufügen, um ein differenzierteres Verständnis zu erzeugen. Aggregationen können auch bei der Verwaltung der Kontextfenstergröße helfen – Sie können ein Abfrageergebnis von 100.000 Dokumenten leicht auf einige hundert Tokens aggregierter Erkenntnisse reduzieren.

Nicht-inhaltliche Signale sind die in Ihren Daten enthaltenen Indikatoren, die Ihnen ein umfassenderes Bild dessen vermitteln, was Sie betrachten; es handelt sich um zusätzliche Merkmale der Ergebnisse, wie beispielsweise Popularität, Aktualität, geografische Lage, Kategorien, Vielfalt der Anbieter oder Preisklassen. Diese Informationsschnipsel können für den Agenten hilfreich sein, um die Bedeutung des empfangenen Kontextes einzuschätzen. Einige einfache Beispiele veranschaulichen dies am besten:

• Hervorhebung kürzlich veröffentlichter und beliebter Inhalte – Stellen Sie sich vor, Sie verfügen über eine Wissensdatenbank mit Artikeln. Sie möchten Artikel finden, die für die Suchanfrage eines Nutzers relevant sind, aber Sie möchten auch Artikel hervorheben, die sowohl aktuell sind als auch von anderen Nutzern als hilfreich empfunden wurden (z. B. eine hohe Anzahl von „Gefällt mir“-Angaben haben). In diesem Szenario können wir eine Hybridsuche verwenden, um relevante Artikel zu finden und sie dann anhand einer Kombination aus Veröffentlichungsdatum und Popularität neu zu ordnen.

• E-Commerce-Suche mit Umsatz- und Lagerbestandsanpassung – Im E-Commerce-Umfeld möchten Sie Ihren Kunden Produkte anzeigen, die zu ihrem Suchbegriff passen, aber Sie möchten auch Produkte bewerben, die sich gut verkaufen und auf Lager sind. Um Frustration bei den Kunden zu vermeiden, sollten Sie Produkte mit geringem Lagerbestand möglicherweise in der Rangfolge herabstufen.

• Priorisierung von schwerwiegenden Problemen in einem Bugtracker - Für ein Softwareentwicklungsteam ist es bei der Suche nach Problemen entscheidend, dass schwerwiegende, prioritäre und kürzlich aktualisierte Probleme zuerst angezeigt werden. Sie können nicht-signalgebende Kriterien wie „Kritikalität“ und „meistdiskutiert“ verwenden, um verschiedene Faktoren unabhängig voneinander zu gewichten und so sicherzustellen, dass die wichtigsten und am aktivsten diskutierten Themen ganz oben stehen.

Diese und weitere Beispielabfragen finden Sie auf der zugehörigen Inhaltsseite von Elasticsearch Labs.

Sicherheitsdurchsetzung

Ein entscheidender Vorteil der Nutzung einer suchbasierten Geschwindigkeitsschicht wie Elastic für Context Engineering ist ihr integriertes Sicherheitsframework. Die Plattform von Elastic stellt sicher, dass der Kontext, der an agentenbasierte und generative KI-Operationen geliefert wird, sensible, privat gehaltene Informationen durch granulare rollenbasierte Zugriffskontrolle (RBAC) und attributbasierte Zugriffskontrolle (ABAC) respektiert und schützt. Dies bedeutet, dass Anfragen nicht nur effizient bearbeitet werden, sondern dass die Ergebnisse auch nach den spezifischen Berechtigungen des Agenten oder des Benutzers, der die Anfrage initiiert, gefiltert werden.

Die Agenten werden als authentifizierter Benutzer ausgeführt, sodass die Sicherheit implizit durch die in die Plattform integrierten Sicherheitsfunktionen gewährleistet ist:

• Feingranulare Berechtigungen: Definieren Sie den Zugriff auf Dokument-, Feld- oder sogar Begriffsebene und stellen Sie so sicher, dass KI-Agenten nur Daten erhalten, zu deren Einsicht sie berechtigt sind.

• Rollenbasierte Zugriffskontrolle (RBAC): Agenten oder Benutzern werden Rollen zugewiesen, wodurch ihnen basierend auf ihren definierten Verantwortlichkeiten Zugriff auf bestimmte Datensätze oder Funktionalitäten gewährt wird.

• Attributbasierte Zugriffskontrolle (ABAC): Implementieren Sie dynamische Zugriffsrichtlinien basierend auf Attributen der Daten, des Benutzers oder der Umgebung, wodurch eine hochgradig anpassungsfähige und kontextsensitive Sicherheit ermöglicht wird.

• Dokumentenebene-Sicherheit (DLS) und Feldebene-Sicherheit (FLS): Diese Funktionen gewährleisten, dass auch innerhalb eines abgerufenen Dokuments nur autorisierte Abschnitte sichtbar sind, wodurch die Offenlegung sensibler Informationen verhindert wird.

• Integration mit der Unternehmenssicherheit: Nahtlose Integration mit bestehenden Identitätsmanagementsystemen (wie LDAP, SAML, OIDC), um einheitliche Sicherheitsrichtlinien im gesamten Unternehmen durchzusetzen.

Durch die direkte Integration dieser Sicherheitsmaßnahmen in den Kontextabrufmechanismus fungiert Elastic als sicherer Wächter, der sicherstellt, dass KI-Agenten innerhalb definierter Datengrenzen arbeiten, eine unbefugte Datenoffenlegung verhindert und die Einhaltung der Datenschutzbestimmungen gewährleistet. Dies ist von entscheidender Bedeutung für den Aufbau von Vertrauen in agentenbasierte KI-Systeme, die vertrauliche oder geschützte Informationen verarbeiten.

Als zusätzlichen Vorteil verringern Sie durch die Verwendung einer einheitlichen Datengeschwindigkeitsschicht über Ihren Unternehmensdatenquellen die unerwarteten Ad-hoc-Abfragelasten auf diese Repositories, die agentenbasierte Tools erzeugen würden. Sie erhalten einen zentralen Ort, um alles nahezu in Echtzeit zu durchsuchen, und einen Ort, um Sicherheits- und Governance-Kontrollen anzuwenden.

Hybride suchbasierte Tools

Es gibt einige Kernfunktionen (und ständig kommen neue hinzu) der Elastic-Plattform, die das Streben nach Kontextentwicklung enorm beschleunigen. Das Wichtigste hierbei ist, dass die Plattform eine Vielzahl von Möglichkeiten bietet, um Ziele zu erreichen, und die Flexibilität besitzt, Methoden anzupassen, zu verändern und zu erweitern, wenn sich das KI-Ökosystem weiterentwickelt.

Wir stellen Ihnen Agent Builder vor

Elastic Agent Builder ist unser erster Ausflug in die Welt der agentenbasierten KI-Tools, die entwickelt wurden, um mit den Daten zu kommunizieren, die Sie bereits in Elastic speichern. Agent Builder bietet eine Chat-Oberfläche, mit der Benutzer ihre eigenen Agenten und Tools innerhalb von Kibana erstellen und verwalten können. Es verfügt über integrierte MCP- und A2A-Server, programmatische APIs und eine Reihe vorkonfigurierter Systemtools zum Abfragen und Erkunden von Elasticsearch-Indizes sowie zum Generieren von ES|QL-Abfragen aus natürlicher Sprache. Mit Agent Builder können Sie benutzerdefinierte Tools erstellen, die die an den Agenten zurückgegebenen Kontextdaten mithilfe einer ausdrucksstarken ES|QL- Abfragesyntax gezielt ansprechen und formen.

Wie funktioniert die hybride Suche in ES|QL, fragen Sie? Die Kernfunktionalität wird durch die Kombination des Feldtyps semantic_text und der Befehle FORK/FUSE erreicht (FUSE verwendet standardmäßig RRF , um die Ergebnisse der einzelnen Forks zusammenzuführen). Hier ein einfaches Beispiel für eine fiktive Produktsuche:

Die EVAL- Klausel, die in jedem der FORK-Zweige im obigen Beispiel enthalten ist, ist nicht unbedingt notwendig; sie dient lediglich dazu, zu veranschaulichen, wie Sie nachverfolgen können, aus welcher Suchmodalität ein bestimmtes Ergebnis zurückgegeben wurde.

Suchvorlagen

Angenommen, Sie möchten Ihre eigenen externen Agenten-Tools auf Ihre Elastic-Bereitstellung verweisen. Anstelle von ES|QL möchten Sie mehrstufige Retriever verwenden oder eine bereits entwickelte DSL-Syntax wiederverwenden und außerdem die Eingaben, die die Abfrage akzeptiert, die Syntax, die zur Ausführung der Suche verwendet wird, und die in der Ausgabe zurückgegebenen Felder steuern können. Suchvorlagen ermöglichen es Benutzern, vordefinierte Strukturen für häufige Suchmuster festzulegen, wodurch die Effizienz und Konsistenz beim Abrufen von Daten verbessert wird. Dies ist besonders vorteilhaft für agentenbasierte Tools, die mit Such-APIs interagieren, da sie dazu beitragen, Boilerplate-Code zu standardisieren und eine schnellere Iteration der Suchlogik zu ermöglichen. Und falls Sie jemals einen dieser Faktoren anpassen müssen, aktualisieren Sie einfach die Suchvorlage und voilà, die Änderungen werden übernommen. Wenn Sie ein Beispiel für die Verwendung von Suchvorlagen mit agentenbasierten Tools suchen, schauen Sie sich den Blog von Elasticsearch Labs an: „MCP für intelligente Suche “. Dort wird eine Suchvorlage hinter einem Tool-Aufruf von einem externen MCP-Server verwendet.

Integrierte Arbeitsabläufe (FTW!)

Eine der größten Herausforderungen in unserer neuen Welt der agentenbasierten KI ist die nicht-deterministische Natur von semi-autonomen, selbstgesteuerten „denkenden“ Agenten. Kontextgestaltung ist eine entscheidende Disziplin für agentenbasierte KI: Es handelt sich um Techniken, die dazu beitragen, die möglichen Schlussfolgerungen, die unser Agent generieren kann, auf das einzugrenzen, was wir als Wahrheit kennen. Selbst bei einem hochpräzisen und relevanten Kontextfenster (wenn wir den Bereich numerischer Fakten verlassen) fehlt uns immer noch die Gewissheit, dass die Reaktion des Agenten vollständig wiederholbar und verlässlich ist.

Wenn Sie dieselbe Anfrage mehrmals an einen Agenten senden, können die Antworten im Wesentlichen gleich sein, wobei sich lediglich die Antwort geringfügig unterscheidet. Das ist in der Regel für einfache Abfragen ausreichend, vielleicht kaum wahrnehmbar, und wir können versuchen, die Ausgabe mithilfe von Kontextmanipulationstechniken zu gestalten. Doch je komplexer die Aufgaben werden, die wir unseren Agenten stellen, desto größer ist die Wahrscheinlichkeit, dass eine oder mehrere Teilaufgaben eine Abweichung hervorrufen, die das Endergebnis geringfügig verändert. Es wird wahrscheinlich noch schlimmer werden, wenn wir uns stärker auf die Kommunikation zwischen den Agenten verlassen, und diese Abweichungen werden sich summieren. Dies unterstreicht erneut die Notwendigkeit, dass die Werkzeuge, mit denen unsere Agenten interagieren, sehr flexibel und genau auf die jeweiligen Kontextdaten abstimmbar sein müssen und dass sie in einem erwarteten Ausgabeformat reagieren sollten. Dies deutet auch darauf hin, dass wir für viele Anwendungsfälle die Interaktion zwischen Agenten und Werkzeugen steuern müssen – hier kommen Workflows ins Spiel!

Elastic wird schon bald vollständig anpassbare Workflows in den Kern der Plattform integrieren. Diese Workflows werden in der Lage sein, bidirektional mit Agenten und Tools zu interagieren, sodass Workflows Agenten und Tools aufrufen können und Agenten und Tools Workflows aufrufen können. Die vollständige Integration dieser Funktionen in dieselbe Such-KI-Plattform, auf der sich all Ihre Daten befinden, wird einen grundlegenden Wandel bewirken; das Potenzial der Arbeitsabläufe ist äußerst spannend! Bald, schon sehr bald!

Elastisch wie die einheitliche Speicherbank

Da Elastic eine verteilte Datenplattform ist, die für die Suche in nahezu Echtzeit konzipiert wurde, übernimmt sie auf natürliche Weise die Langzeitgedächtnisfunktionen für agentenbasierte KI-Systeme. Mit der integrierten Chat-Funktion des Agent Builders bieten wir auch die Möglichkeit, das Kurzzeitgedächtnis und den Chatverlauf zu verfolgen und zu verwalten. Und weil die gesamte Plattform API-first ist, ist es extrem einfach, Elastic als Plattform zu nutzen, um die Kontextausgabe eines Tools zu speichern (und später darauf zurückgreifen zu können), die das Kontextfenster des Agenten überfordern könnte; diese Technik wird in Kontext-Engineering-Kreisen manchmal als „ Notizen-Making“ bezeichnet.

Die Kombination von Kurzzeit- und Langzeitgedächtnis auf derselben Suchplattform bietet viele Vorteile: Stellen Sie sich vor, Sie könnten Chatverläufe und gespeicherte Kontextantworten als semantische Einflussfaktoren für zukünftige Chatinteraktionen nutzen, Bedrohungsanalysen durchführen oder persistente Datenprodukte erstellen, die automatisch aus häufig wiederholten Toolaufrufen generiert werden… Die Möglichkeiten sind endlos!

Fazit

Das Aufkommen großer Sprachmodelle hat die Art und Weise verändert, wie wir Inhalte abgleichen und wie wir unsere Daten analysieren. Wir bewegen uns rasant weg von unserer gegenwärtigen Welt, in der Menschen Recherche, Kontextbetrachtung und logisches Denken betreiben, um ihre eigenen Fragen zu beantworten, hin zu einer Welt, in der diese Schritte weitgehend durch agentenbasierte KI automatisiert werden. Damit wir den generierten Antworten vertrauen können, benötigen wir die Gewissheit, dass der Agent bei der Generierung seiner Antwort alle relevanten Informationen (einschließlich des Faktors der subjektiven Relevanz) berücksichtigt hat. Unsere primäre Methode, um agentenbasierte KI vertrauenswürdig zu machen, besteht darin, die Werkzeuge, die zusätzlichen Kontext abrufen, durch RAG- und Kontext-Engineering-Techniken zu verankern. Die Art und Weise, wie diese Werkzeuge den anfänglichen Abruf durchführen, kann jedoch entscheidend für die Genauigkeit der Antwort sein.

Die Elastic Search AI-Plattform bietet die Flexibilität und Vorteile der hybriden Suche sowie zahlreiche integrierte Funktionen, die agentenbasierte KI in Bezug auf Genauigkeit, Leistung und Skalierbarkeit unterstützen; mit anderen Worten: Elastic ist eine fantastische Plattform für verschiedene Aspekte des Kontext-Engineerings! Durch die Standardisierung des Kontextabrufs über eine Suchplattform vereinfachen wir die Funktionsweise von agentenbasierten Werkzeugen in vielerlei Hinsicht – und ähnlich dem Widerspruch „langsamer werden, um schneller zu werden“ bedeutet Einfachheit auf der Ebene der Kontextgenerierung eine schnellere und vertrauenswürdigere agentenbasierte KI.

Wie viele von uns bin auch ich gleichermaßen begeistert und erstaunt über das Tempo, mit dem sich die Fähigkeiten der KI weiterentwickeln. Wir erlebten zum ersten Mal, wie große Sprachmodelle (LLMs) und die Vektorsuche uns in die semantische Revolution katapultierten, bei der wir nicht mehr mühsam mit Schlüsselwörtern herumsuchen mussten, um Dinge zu finden. Dann zeigten uns die LLMs neue Wege der Interaktion mit unseren Daten auf, indem sie Chat-Schnittstellen nutzten, um Anfragen in natürlicher Sprache in Antworten umzuwandeln, die riesige Wissensdatenbanken in leicht verständliche Zusammenfassungen destillierten. Wir jetzt (schon!) haben die Anfänge einer automatisierten LLM-gesteuerten Logik in Form von „agentischen KI“-Workflows, die eine eingehende Anfrage semantisch verstehen, über die zu unternehmenden Schritte nachdenken und dann aus den verfügbaren Werkzeugen auswählen können, um iterativ Aktionen auszuführen, um diese Ziele zu erreichen.

Das Versprechen agentenbasierter KI zwingt uns, uns von der primären Verwendung von „Prompt Engineering“ zur Gestaltung unserer generativen KI-Interaktionen hin zu einem Fokus darauf zu entwickeln, wie wir agentenbasierte Werkzeuge dabei unterstützen können, die relevantesten und effizientesten Zusatzinformationen zu erhalten, die das LLM bei der Generierung seiner Antworten berücksichtigen muss – „Context Engineering“ ist die nächste Herausforderung. Die hybride Suche ist mit Abstand das leistungsstärkste und flexibelste Mittel, um relevante Kontextinformationen zu finden, und die Search AI-Plattform von Elastic eröffnet völlig neue Möglichkeiten, Daten im Dienste des Context Engineering zu nutzen. In diesem Artikel werden wir aus zwei Blickwinkeln erörtern, wie LLMs die Welt der Informationswiedergewinnung verändert haben, und anschließend darauf eingehen, wie sie für bessere Ergebnisse zusammenarbeiten können. Es gibt noch viel zu besprechen…

Teil I: Wie LLMs die Suche verändert haben

Beginnen wir mit der Frage, wie LLMs die Art und Weise verändert haben, wie wir auf Informationen zugreifen und sie abrufen.

Unser lexikalisches Erbe

Wir alle leben schon seit langer Zeit in der etwas eingeschränkten Welt der lexikalischen Suche (ziemlich gut, so gut es eben geht). Die Suche ist das erste Werkzeug, zu dem wir greifen, wenn wir recherchieren oder ein neues Projekt beginnen, und bis vor kurzem lag es an uns, unsere Suchanfragen so zu formulieren, dass eine lexikalische Suchmaschine sie versteht. Die lexikalische Suche basiert auf dem Abgleich von Suchbegriffen mit Schlüsselwörtern in einem Dokumentenkorpus – unabhängig davon, ob der Inhalt unstrukturiert oder strukturiert ist. Damit eine lexikalische Suche ein Dokument als Treffer zurückgibt, muss dieses mit dem entsprechenden Schlüsselwort übereinstimmen (oder über ein kontrolliertes Vokabular wie eine Synonymliste oder ein Wörterbuch verfügen, um die konzeptionelle Verbindung für uns herzustellen).

Beispiel einer lexikalischen Mehrfachabfrage

Suchmaschinen haben zumindest die Möglichkeit, Treffer mit einer Relevanzbewertung zurückzugeben. Suchmaschinen bieten eine Fülle von Abfragesyntaxoptionen, um indizierte Daten effektiv anzusprechen, sowie integrierte Relevanzalgorithmen, die die Ergebnisse im Verhältnis zur Absicht der Abfragesyntax des Benutzers bewerten. Suchmaschinen profitieren von jahrzehntelangen Fortschritten bei Relevanz-Ranking-Algorithmen und sind dadurch eine effiziente Datenabrufplattform, die Ergebnisse liefern kann, die nach ihrer Relevanz für die Suchanfrage bewertet und sortiert sind. Datenbanken und andere Systeme, die SQL als ihre Hauptmethode zum Abrufen von Daten verwenden, sind hier im Nachteil: Es gibt kein Relevanzkonzept in einer Datenbankabfrage; sie können bestenfalls Ergebnisse alphabetisch oder numerisch sortieren. Die gute Nachricht ist, dass Sie mit diesen Schlüsselwörtern alle Treffer (Recall) erhalten, diese aber nicht unbedingt in einer hilfreichen Reihenfolge im Hinblick darauf, warum Sie danach gesucht haben (Präzision). Das ist ein wichtiger Punkt, wie wir gleich sehen werden…

Betreten Sie den (semantischen) Drachen

Das Potenzial von Vektordarstellungen von Informationen als Alternative zur Stichwortsuche wird schon seit geraumer Zeit erforscht. Vektoren bergen großes Potenzial, da sie uns aus dem rein schlüsselwortbasierten Modus des Inhaltsabgleichs herausführen – da Vektoren numerische Darstellungen von Begriffen und Gewichtungen sind, ermöglichen sie es, Konzepte mathematisch nahe beieinander zu bringen, basierend auf dem Verständnis eines Sprachmodells darüber, wie Begriffe im Trainingsbereich miteinander in Beziehung stehen. Die lange Verzögerung bei der allgemeinen Vektorsuche war darauf zurückzuführen, dass die Modelle größtenteils auf spezifische Domänen beschränkt waren; sie waren einfach nicht groß genug, um die vielen verschiedenen Konzepte, die ein Begriff in unterschiedlichen Kontexten repräsentieren könnte, ausreichend zu verstehen.

Erst mit dem Aufkommen der Large Language Models (LLMs) vor einigen Jahren, die in der Lage sind, mit viel größeren Datenmengen zu trainieren (unter Verwendung von Transformatoren und Aufmerksamkeit), wurde die Vektorsuche praktikabel – die Größe und Tiefe der LLMs ermöglichten es Vektoren schließlich, genügend Nuancen zu speichern, um tatsächlich semantische Bedeutung zu erfassen. Dieser plötzliche Anstieg des Verständnisses ermöglichte es LLMs, nun eine große Anzahl von Funktionen der natürlichen Sprachverarbeitung (NLP) zu erfüllen, die zuvor gesperrt waren. Die vielleicht wirkungsvollste Funktion ist die Fähigkeit, aus dem Kontext dessen, was sich bisher in der Sequenz befindet, auf das wahrscheinlichste nächste Glied in einer Sequenz zu schließen. Inferenz ist der Prozess, der generativer KI ihre nahezu menschenähnliche Fähigkeit verleiht, Texte zu erzeugen. Der KI-generierte Text basiert auf dem Verständnis des LLM darüber, wie Begriffe in seinen Trainingsdaten miteinander in Beziehung stehen, und verwendet außerdem die Formulierung der Anfrage, um zwischen verschiedenen Kontexten, in denen die Begriffe vorkommen könnten, zu unterscheiden.

So magisch generative KI auch sein mag, es gibt Einschränkungen bei LLMs, die zu Fehlern in Qualität und Genauigkeit führen, die gemeinhin als Halluzinationen bezeichnet werden. Halluzinationen treten auf, wenn das LLM keinen Zugang zu den Informationen hat (oder nicht in den richtigen Kontext geführt wird), um seine Antwort auf die Wahrheit zu gründen. Stattdessen generiert es, um hilfreich zu sein, eine selbstsicher und plausibel klingende, aber erfundene Antwort. Ein Teil der Ursache liegt darin, dass LLMs zwar den Sprachgebrauch in großen Bereichen mit vielfältigen Informationen erlernen, das Training aber irgendwann beendet werden muss. Daher gibt es einen Zeitfaktor für ihr Verständnis – das heißt, das Modell kann nur das wissen, was bis zum Zeitpunkt des Trainingsstopps korrekt war. Ein weiterer Faktor für Halluzinationen ist, dass das Modell normalerweise keine Kenntnis von privat gespeicherten Daten hat (Daten, die nicht im öffentlichen Internet verfügbar sind), und das ist besonders bedeutsam, wenn diese Daten spezifische Begriffe und Nomenklatur enthalten.

Vektordatenbanken

LLMs vektorisieren Inhalte in ihren Modellraum mithilfe einer Technik namens Text Embedding. Dabei wird die semantische Bedeutung des Inhalts auf der Grundlage des erhaltenen Trainings in die Weltanschauung des Modells eingebettet oder abgebildet. Zur Vorbereitung und Verarbeitung von Inhalten für die Einbettung sind einige Schritte erforderlich, darunter Chunking und Tokenisierung (sowie Subwort-Tokenisierung). Das Ergebnis ist typischerweise eine Menge dichter Vektoren, die das Verständnis des Modells für die Bedeutung dieses Inhaltsabschnitts innerhalb seines Vektorraums darstellen. Chunking ist ein ungenaues Verfahren, das darauf abzielt, Inhalte an die Verarbeitungsbeschränkungen eines Modells zur Generierung von Einbettungen anzupassen und gleichzeitig verwandten Text mithilfe semantischer Konstrukte wie Satz- und Absatzindikatoren zu einem Chunk zusammenzufassen.

Die Notwendigkeit der Segmentierung kann zu einem gewissen semantischen Verlust in einem eingebetteten Dokument führen, da einzelne Segmente nicht vollständig mit anderen Segmenten aus demselben Dokument verknüpft sind. Die inhärente Undurchsichtigkeit neuronaler Netze kann diesen Verlust noch verschlimmern – ein LLM ist in Wahrheit eine „Black Box“, bei der die während des Trainings hergestellten Verbindungen zwischen Begriffen und Konzepten nicht deterministisch und für Menschen nicht interpretierbar sind. Dies führt zu Problemen mit der Erklärbarkeit, der Wiederholbarkeit, unbewussten Voreingenommenheit und möglicherweise zu einem Verlust an Vertrauen und Genauigkeit. Dennoch ist die Möglichkeit, Ideen semantisch zu verknüpfen und bei Suchanfragen nicht an bestimmte Schlüsselwörter gebunden zu sein, extrem wirkungsvoll:

Ein Beispiel für eine semantische Anfrage

Bei Vektordatenbanken gibt es noch einen weiteren Punkt zu beachten: Sie sind keine Suchmaschinen, sondern Datenbanken! Bei einer Vektorähnlichkeitssuche werden die Suchbegriffe kodiert, um einen Satz von (Einbettungs-)Koordinaten innerhalb des Vektorraums des Modells zu finden. Diese Koordinaten dienen dann als Zielscheibe, um die Dokumente zu finden, die die „nächsten Nachbarn“ der Zielscheibe sind – das heißt, der Rang eines Dokuments (oder seine Platzierung in den Ergebnissen) wird durch die berechnete Ähnlichkeitsdistanz der Koordinaten dieses Dokuments zu den Koordinaten der Anfrage bestimmt. In welche Richtung sollte die Rangfolge Vorrang haben, welcher der möglichen Kontexte entspricht am ehesten der Absicht des Nutzers? Das Bild, mit dem ich es vergleiche, ist eine Szene aus dem Film Stargate, in der wir die sechs Koordinatenpunkte haben, die sich schneiden, um uns das Ziel (die Zielscheibe) zu nennen, aber wir können es nicht erreichen, ohne das „7. Symbol“ zu kennen – die Koordinaten des Startpunkts, die die subjektive Absicht des Benutzers repräsentieren. Anstatt also die relative Rangfolge der Vektoren auf einer sich ständig erweiternden und undifferenzierten Sphäre der Ähnlichkeit zu basieren, können wir durch die Berücksichtigung der subjektiven Absicht der Anfrage mittels ausdrucksstarker Syntax und Relevanzbewertung so etwas wie einen Zylinder abgestufter subjektiver Relevanz erhalten.

Die Inferenzfähigkeiten eines LLM können zwar helfen, den wahrscheinlichsten Kontext für die Anfrage zu identifizieren, das Problem besteht jedoch darin, dass ohne diese Unterstützung die Koordinaten der eingehenden Anfrage nur anhand der Art und Weise bestimmt werden können, wie das Modell ursprünglich trainiert wurde.

In gewisser Hinsicht könnte man sagen, dass Vektorähnlichkeit das entgegengesetzte Extrem darstellt als eine strikte Stichwortübereinstimmung – ihre Stärke liegt in ihrer Fähigkeit, die Probleme der Begriffsabweichung zu überwinden, aber fast bis zum Exzess: LLMs neigen dazu, verwandte Konzepte zu vereinheitlichen, anstatt zwischen ihnen zu unterscheiden. Die Vektorähnlichkeit verbessert unsere Fähigkeit, Inhalte semantisch abzugleichen, garantiert aber keine Präzision, da sie exakte Schlüsselwörter und spezifische Details übersehen kann, die vom Modell nicht ausreichend unterschieden werden. Die Vektorähnlichkeitssuche ist an sich schon leistungsstark, aber wir brauchen Möglichkeiten, die Ergebnisse, die wir aus einer Vektordatenbank abrufen, mit Ergebnissen anderer Abrufmethoden zu korrelieren.

Neubewertungstechniken

An dieser Stelle sei eine allgemeine Technik namens Reranking erwähnt, bei der die Ergebnismengen neu bewertet oder normalisiert werden, um eine einheitliche Rangfolge zu erhalten. Die Notwendigkeit einer Neubewertung könnte darauf zurückzuführen sein, dass Ergebnisse aus mehreren Quellen oder Abrufmethoden unterschiedliche Bewertungsmechanismen (oder gar keine, SQL!) haben, oder die Neubewertung könnte dazu dienen, die Ergebnisse aus nicht-semantischen Quellen semantisch an die Anfrage des Benutzers anzupassen. Das Reranking ist ein zweiter Schritt, bei dem es sich um eine Reihe von Ergebnissen handelt, die durch eine erste Abrufmethode (z. B. Anschließend werden SQL-, lexikalische und Vektorsuchen mit einer anderen Bewertungsmethode neu geordnet.

Es stehen verschiedene Ansätze zur Verfügung, darunter Learning-To-Rank (LTR) und Reciprocal Rank Fusion (RRF) – LTR eignet sich, um Suchergebnisse zu erfassen (Likes, Bewertungen, Klicks usw.) und diese zu nutzen, um Ergebnisse zu bewerten und zu verstärken oder zu verzerren. RRF eignet sich perfekt zum Zusammenführen von Ergebnissen, die von verschiedenen Abfragemodalitäten zurückgegeben werden (z. B. lexikalische und Vektordatenbankrecherchen) werden zu einer einzigen Ergebnisliste zusammengeführt. Elastic bietet außerdem die Flexibilität, die Ergebnisse mithilfe linearer Neubewertungsmethoden anzupassen.

Eine der effektivsten Reranking-Techniken ist jedoch das semantische Reranking, bei dem das semantische Verständnis eines LLM genutzt wird, um die Vektoreinbettungen sowohl der Anfrage als auch der Ergebnisse gemeinsam zu analysieren und anschließend eine Relevanzbewertung/Rescoring anzuwenden, um die endgültige Reihenfolge zu bestimmen. Für das semantische Reranking ist natürlich eine Verbindung zu einem Reranking-Modell erforderlich. Elasticsearch bietet eine Inference API , mit der Sie Rerank- Endpunkte erstellen können, die integrierte Modelle (Elastic Rerank), importierte Modelle von Drittanbietern oder extern gehostete Dienste wie Cohere oder Google Vertex AI nutzen. Anschließend können Sie mithilfe der Abstraktionssyntax der Retriever -Abfrage ein Reranking durchführen:

Ein Beispiel für eine mehrstufige Retriever-Neubewertungsoperation

Klingt super, oder? Wir können eine Neubewertung der Ergebnisse aus unterschiedlichen Quellen durchführen und so ein nahezu vollständiges semantisches Verständnis aller Inhaltsarten erreichen… Die semantische Neubewertung kann sowohl rechenintensiv als auch zeitaufwendig sein, weshalb sie nur bei einer begrenzten Anzahl von Ergebnissen praktikabel ist. Daher ist es wichtig, wie die ursprünglichen Ergebnisse abgerufen werden.

Die Methode zur Kontextabfrage ist wichtig.

Die subjektive Intention ist ein wichtiger Faktor bei der Bestimmung der Genauigkeit eines Ergebnisses und bei der Bewertung seiner Relevanz. Ohne die Möglichkeit, die Absicht des Benutzers bei der Durchführung der Abfrage zu berücksichtigen (ausgedrückt durch eine flexible Syntax oder durch eine Neubewertung in einer zweiten Stufe), können wir nur aus den bereits im Modellraum kodierten Kontexten auswählen. Um diesem Mangel an Kontext zu begegnen, setzen wir üblicherweise Techniken wie Retrieval Augment Generation (RAG) ein. Die Funktionsweise von RAG besteht darin, dass die Koordinaten der Abfrage effektiv verschoben werden, indem zusätzliche verwandte Begriffe aus einer Vorabfrage für kontextrelevante Daten einbezogen werden. Dadurch wird die Art und Weise, wie die Engine diesen zusätzlichen Kontext bereitstellt, und ihre anfängliche Methode zur Datenabfrage umso wichtiger für die Genauigkeit des Kontextes!

Lassen Sie uns die verschiedenen Methoden zur Kontextabfrage und deren Einfluss auf eine RAG-Operation betrachten:

• Hybride Suchabrufe ohne Suchmaschine weisen immer noch einen Mangel an subjektiver Relevanz auf. Wenn die Plattform, die RAG bereitstellt, im Wesentlichen auf SQL basiert (was auf die meisten „Data Lake“-Plattformen zutrifft), fehlt ihr die Relevanzbewertung in der ersten Abrufphase. Viele Data-Lake-Plattformen bieten ihre eigene Version des hybriden Retrieval (nicht der Suche) an, wobei in der Regel Reranking-Techniken wie semantisches Reranking und RRF auf ihren SQL-basierten Retrieval- und Vektordatenbankergebnissen kombiniert werden. Eine einfache Sortierung reicht offensichtlich nicht für eine subjektive Rangfolge aus, aber selbst wenn sie als Grundlage für eine semantische Neubewertung in einem zweiten Schritt verwendet wird, wird SQL als erste Stufe der Abfrage problematisch, wenn die semantische Neubewertung nur auf den „Top k“ Treffern durchgeführt wird – ohne eine Möglichkeit, die Ergebnisse bei der Abfrage zu bewerten, welche Garantie haben wir, dass die besten Ergebnisse tatsächlich unter den Top-Ergebnissen enthalten sind?

• Vektorähnlichkeit allein reicht für RAG nicht aus. Das liegt eigentlich an einer Reihe von sich gegenseitig verstärkenden Problemen – es ist der Verlust beim Einbetten, zusammen mit naiven Chunking-Methoden, der Art und Weise, wie Ähnlichkeit berechnet wird, und der entscheidenden fehlenden Komponente der subjektiven Absicht. Eines der Hauptziele von RAG ist es, generative KI-Interaktionen auf objektiver Wahrheit zu gründen, um sowohl Halluzinationen zu verhindern als auch das LLM über private Informationen zu informieren, von denen es während des Trainings keine Kenntnis hatte. Wir können den durch RAG bereitgestellten zusätzlichen Kontext nutzen, um LLMs einzuschränken und anzuleiten, die Verbindungen und Details zu berücksichtigen, von denen wir wissen, dass sie für die Beantwortung der jeweiligen Frage am wichtigsten sind. Dazu müssen wir sowohl semantische als auch lexikalische Ansätze verwenden.

• Dateibasierte grep/regex RAG. Einige Kreise im Universum der agentenbasierten KI plädieren für die Verwendung stark vergrößerter Kontextfenster, die über grep und reguläre Ausdrücke für RAG auf lokale Dateien zugreifen, anstatt externe Abrufplattformen zu nutzen. Die Idee dahinter ist, dass LLMs mit einem wesentlich größeren Kontextfenster in der Lage sein werden, konzeptionelle Verbindungen innerhalb ihres eigenen Denkraums herzustellen, anstatt sich auf fragmentierte Informationen und verschiedene Abrufmethoden/Plattformen zu verlassen, um relevante Informationen zu sammeln. Theoretisch ist es zwar richtig, dass ein ganzes Dokument ein umfassenderes Bild liefert als Dokumentsegmente, dies funktioniert jedoch nur in kleinen Datenbereichen (oder beispielsweise bei der Bereitstellung von Dateien für Vibecoding), und selbst dann besteht die erste Abrufmethode in einem Scan aller Dokumente mit einer reinen Stichwortübereinstimmung.

Suche ist mehr als nur Abruf.

Suchmaschinen sind speziell dafür entwickelt, Suchanfragen so schnell und flexibel wie möglich zu gestalten. Intern nutzen sie spezialisierte Datenstrukturen zum Speichern und Abrufen verschiedener Datentypen, die auf diese Datentypen zugeschnitten sind. Elasticsearch bietet optimiertes Speichern und Abfragen für praktisch alle Datentypen, einschließlich unstrukturierter/Volltext-Lexikalsuche (Match, Phrase, Proximity, Multi-Match), schneller Keyword-Suche (exakte Übereinstimmung) und Filterung, numerischer Bereiche, Datumsangaben, IP-Adressen und ist sehr flexibel in der Speicherung von Dokumentstrukturen (z. B. …). verschachtelte oder flache Dokumente). Elasticsearch ist außerdem eine native Vektordatenbank, die sowohl dünnbesetzte als auch dichte Vektortypen speichern und abfragen kann, und wir erforschen weiterhin innovative Wege (zum Beispiel Better Binary Quantization (BBQ) & DiskBBQ), um die Suchgenauigkeit zu erhalten und gleichzeitig die Geschwindigkeit, Skalierbarkeit und Kosten im Zusammenhang mit vektorisierten Inhalten zu verbessern. Die Elasticsearch-Plattform bietet zudem integrierte Datenstabilität und Hochverfügbarkeit und beinhaltet Funktionen für das Datenlebenszyklusmanagement wie Searchable Snapshots , mit denen Sie selten genutzte oder langfristig aufzubewahrende Daten auf kostengünstigem Objektspeicher speichern können – und diese dennoch vollständig durchsuchbar sind.

Die Hybridsuche vereint das Beste aus allen Welten.

Hybride Suche (nicht nur hybride Abfrage!) kombiniert die Stärken der traditionellen lexikalischen Suche mit dem semantischen Verständnis von LLMs und der Vektorähnlichkeitssuche. Diese Synergie ermöglicht es, bereits in der Abrufphase hochrelevante Ergebnisse durch die flexiblen Abfragesyntaxoptionen einer Suchmaschine zu erzielen: absichtsgesteuerte Syntaxoptionen und Relevanzbewertung, multimodaler Datenabruf, Filterung, Aggregation und Biasing. Mit Suchsyntax wie ES|QL und mehrstufigen Abrufern können wir die traditionelle Suche flexibel mit semantischer Suche, Filtern und mehreren Reranking-Techniken in einer einzigen Anfrage kombinieren.

Einer der größten Vorteile der hybriden Suche ist, dass Ihre Abfragen eine spezialisierte Syntax für mehrere verschiedene Datentypen gleichzeitig verwenden können. Diese unterschiedlichen Abfragesyntaxen können nicht nur zum Auffinden von Ergebnissen verwendet werden, sondern auch als Filter oder Aggregationen der Ergebnisse. Ein Beispiel hierfür ist die Geodatenanalyse, eine der häufigsten Abfragearten, die oft mit anderen Syntaxelementen kombiniert wird. Sie können beispielsweise Abfragen durchführen, um Ergebnisse zu erhalten, deren Geokoordinaten sich innerhalb einer bestimmten Entfernung von einem Punkt befinden, oder um Aggregationen Ihrer Ergebnisse nach Region anzufordern, oder um Aggregationen anzufordern, um Bewegungen in/aus einer Zone zu verfolgen und Warnungen auszugeben. Mit der Hybridsuche haben Sie die Flexibilität, Syntaxen zu kombinieren, um Ergebnisse so präzise wie möglich zu liefern und die Inhalte abzurufen, die Ihrem Kontext am nächsten kommen.

Pause

Dieser erste Teil erzählt die Geschichte, wie die Vektorsuche die Art und Weise verändert hat, wie wir Daten abrufen können, und bereitet den Boden für die Veränderungen, die LLMs an den Abfragemechanismen mit sich gebracht haben, mit denen wir mit Daten interagieren. Wir werden so tun, als hätten wir das in mehrere Teile aufteilen müssen, damit LLMs es verstehen können, ohne den Kontext zu verlieren… ;-) Erfahren wir mehr darüber, warum das wichtig ist, in Teil II: Agentische KI und die Notwendigkeit des Kontext-Engineerings, und in Teil III kehren wir zu unserer Diskussion über die hybride Suche zurück.

Um dies zu erreichen, verwenden wir Googles SigLIP-2, um Vektoreinbettungen sowohl für Bilder als auch für Texte zu generieren und diese in der Elasticsearch-Vektordatenbank zu speichern. Zum Zeitpunkt der Abfrage wandeln wir die Sucheingabe, Text oder Bild, in Einbettungen um und führen schnelle kNN-Vektorsuchen durch, um Ergebnisse abzurufen. Diese Konfiguration ermöglicht eine effiziente Text-zu-Bild- und Bild-zu-Bild-Suche. Eine Streamlit-Benutzeroberfläche erweckt dieses Projekt zum Leben, indem sie uns ein Frontend zur Verfügung stellt, mit dem wir nicht nur textbasiert nach passenden Fotos aus dem Album suchen und diese anzeigen können, sondern auch den Berggipfel auf dem hochgeladenen Bild identifizieren und weitere Fotos dieses Berges im Fotoalbum anzeigen können. Wir beschreiben außerdem die Schritte, die wir zur Verbesserung der Suchgenauigkeit unternommen haben, und geben praktische Tipps und Tricks. Zur weiteren Erkundung stellen wir ein GitHub-Repository und ein Colab-Notebook zur Verfügung.

Wie alles begann

Dieser Blogbeitrag entstand auf Anregung eines 10-Jährigen, der mich bat, ihm alle Bilder des Mount Ama Dablam von meiner Everest-Basislager-Trekkingtour zu zeigen. Während wir das Fotoalbum durchsahen, wurde ich auch gebeten, mehrere andere Berggipfel zu identifizieren, von denen ich einige nicht benennen konnte.

Das brachte mich auf die Idee, dass dies ein unterhaltsames Computer-Vision-Projekt werden könnte. Was wir erreichen wollten:

• Finde Bilder eines Berggipfels anhand seines Namens

• Errate den Namen des Berggipfels anhand eines Bildes und finde ähnliche Gipfel im Fotoalbum.

• Konzeptabfragen zum Laufen bringen (Person, Fluss, Gebetsfahnen usw.)

Zusammenstellung des Dreamteams: SigLIP-2, Elasticsearch & Streamlit

Es wurde schnell klar, dass wir, um dies zu ermöglichen, sowohl den Text („Ama Dablam“) als auch die Bilder (Fotos aus meinem Album) in Vektoren umwandeln müssten, die sinnvoll verglichen werden können, d. h. im selben Vektorraum. Sobald wir das getan haben, besteht die Suche nur noch darin, „die nächstgelegenen Nachbarn zu finden“.

Um Bildeinbettungen zu generieren, verwenden wir einen mehrsprachigen Bild-Sprach-Encoder, sodass ein Foto eines Berges und ein Ausdruck wie „Ama Dablam“ im selben Vektorraum landen.

SigLIP-2, das kürzlich von Google veröffentlicht wurde, passt hier gut hinein. Es kann Einbettungen ohne aufgabenspezifisches Training generieren (eine Zero-Shot -Einstellung) und eignet sich hervorragend für unseren Anwendungsfall: unbeschriftete Fotos und Gipfel mit unterschiedlichen Namen und Sprachen. Da es für die Zuordnung von Text zu Bild trainiert wurde, werden ein Bergbild von der Wanderung und eine kurze Texteingabeaufforderung als Einbettungen sehr ähnlich dargestellt, selbst wenn die Abfragesprache oder die Rechtschreibung variiert.

SigLIP-2 bietet ein gutes Verhältnis von Qualität zu Geschwindigkeit, unterstützt mehrere Eingangsauflösungen und läuft sowohl auf der CPU als auch auf der GPU. Der SigLIP-2 ist im Vergleich zu Vorgängermodellen wie dem ursprünglichen CLIP robuster für Außenaufnahmen. Während unserer Tests lieferte SigLIP-2 durchweg zuverlässige Ergebnisse. Es wird zudem sehr gut unterstützt, was es zur naheliegenden Wahl für dieses Projekt macht.

Als nächstes benötigen wir eine Vektordatenbank zum Speichern der Einbettungen und zur Durchführung der Power-Suche. Es sollte nicht nur die Cosinus-kNN-Suche über Bildeinbettungen unterstützen, sondern auch Geofencing und Textfilter in einer einzigen Abfrage anwenden. Elasticsearch passt hier gut: Es verarbeitet Vektoren (HNSW kNN auf dense_vector-Feldern) sehr gut, unterstützt die hybride Suche, die Text-, Vektor- und Geo-Abfragen kombiniert, und bietet standardmäßig Filter- und Sortierfunktionen. Es ist außerdem horizontal skalierbar, sodass man problemlos von einer Handvoll Fotos auf Tausende wachsen kann. Der offizielle Elasticsearch Python-Client hält die Infrastruktur einfach und lässt sich nahtlos in das Projekt integrieren. Schließlich benötigen wir noch ein schlankes Frontend, in dem wir Suchanfragen eingeben und Ergebnisse anzeigen können. Für eine schnelle, Python-basierte Demo ist Streamlit hervorragend geeignet. Es bietet die grundlegenden Funktionen, die wir benötigen – Datei-Upload, ein responsives Bildraster und Dropdown-Menüs zum Sortieren und Geofencing. Es lässt sich leicht klonen und lokal ausführen und funktioniert auch in einem Colab-Notebook.

Implementierung

Elasticsearch-Indexierungsdesign und Indexierungsstrategie

Für dieses Projekt verwenden wir zwei Indizes: peaks_catalog und photos.

Peaks_Katalogindex

Dieser Index dient als kompakter Katalog markanter Berggipfel, die während der Everest-Basislager-Trekkingtour sichtbar sind. Jedes Dokument in diesem Index entspricht einem einzelnen Berggipfel, wie zum Beispiel dem Mount Everest. Für jedes Berggipfeldokument speichern wir Namen/Aliasse, optionale Breiten- und Längengradkoordinaten sowie einen einzelnen Prototypvektor, der durch die Kombination von SigLIP-2-Texteingabeaufforderungen (+ optionalen Referenzbildern) erstellt wird.

Indexzuordnung:

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Ausweis

Stichwort

ama-dablam

Stabiler Slug/ID

—

Namen

Text + Stichwort-Unterfeld

["Ama Dablam","Amadablam"]

Aliase / mehrsprachige Namen; names.raw für genaue Filter

—

Breitengrad

Geopunkt

{"lat":27.8617,"lon":86.8614}

GPS-Koordinaten des Gipfels als Kombination aus Breitengrad und Längengrad (optional)

—

elev_m

ganze Zahl

6812

Höhenangabe (optional)

—

text_embed

dense_vector

768

Kombinierter Prototyp (Aufforderungen und optional 1–3 Referenzbilder) für diesen Peak

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

Dieser Index wird vor allem für Bild-zu-Bild-Suchen verwendet, beispielsweise zur Identifizierung von Berggipfeln anhand von Bildern. Wir verwenden diesen Index auch, um die Ergebnisse der Text-zu-Bild-Suche zu verbessern.

Zusammenfassend lässt sich sagen, dass die peaks_catalog die Frage „Welcher Berg ist das?“ in ein fokussiertes Nächste-Nachbar-Problem umwandelt und so das konzeptionelle Verständnis effektiv von der Komplexität der Bilddaten trennt.

Indexierungsstrategie für den peaks_catalog-Index: Wir beginnen mit der Erstellung einer Liste der markantesten Gipfel, die während der EBC-Trekkingtour sichtbar sind. Für jeden Gipfel speichern wir seine geografische Position, seinen Namen, Synonyme und seine Höhe in einer YAML-Datei. Im nächsten Schritt wird für jeden Peak die Einbettung generiert und im Feld text_embed gespeichert. Um robuste Einbettungen zu erzeugen, verwenden wir die folgende Technik:

• Erstellen Sie einen Textprototyp mit folgendem Werkzeug:

  • Namen der Gipfel

  • Prompt-Ensemble (Verwendung mehrerer unterschiedlicher Prompts, um dieselbe Frage zu beantworten), zum Beispiel:

    • „Ein Naturfoto des Berggipfels {name} im Himalaya, Nepal“

    • „ {name} markanter Gipfel in der Khumbu-Region, alpine Landschaft“

    • „ {name} Berggipfel, Schnee, felsiger Grat“

  • optionales Anti-Konzept (sagt SigLIP-2, wonach nicht gematcht werden soll): einen kleinen Vektor für „Gemälde, Illustration, Poster, Karte, Logo“ abziehen, um eine Bevorzugung von echten Fotos zu erreichen.

• Optional kann ein Bildprototyp erstellt werden, falls Referenzbilder des Gipfels vorhanden sind.

Anschließend verschmelzen wir den Text- und Bildprototyp , um die endgültige Einbettung zu erzeugen. Abschließend wird das Dokument mit allen erforderlichen Feldern indexiert :

Beispieldokument aus dem Index peaks_catalog :

Fotoindex

Dieser Hauptindex speichert detaillierte Informationen über alle Fotos im Album. Jedes Dokument stellt ein einzelnes Foto dar und enthält folgende Informationen:

• Relativer Pfad zum Foto im Fotoalbum. Dies kann verwendet werden, um das passende Bild anzuzeigen oder das Bild in die Suchoberfläche zu laden.

• GPS- und Zeitinformationen des Bildes.

• Dichter Vektor für die Bildkodierung, generiert durch SigLIP-2.

• predicted_peaks Das ermöglicht es uns, nach Gipfelnamen zu filtern. Indexzuordnung

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Weg

Stichwort

data/images/IMG_1234.HEIC

Wie die Benutzeroberfläche das Miniaturbild/Vollbild öffnet

—

Bildausschnitt

dense_vector

768

SigLIP-2 Bildeinbettung

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

vorhergesagte_Spitzen

Stichwort

["ama-dablam","pumori"]

Top-K-Vorhersagen zur Indexierungszeit (kostengünstiger UX-Filter / Facette)

—

GPS

Geopunkt

{"lat":27.96,"lon":86.83}

Aktiviert Geofilter

—

Schusszeit

date

2023-10-18T09:41:00Z

Aufnahmezeit: Sortieren/Filtern

—

Indexierungsstrategie für den Fotoindex: Für jedes Foto im Album gehen wir wie folgt vor: Extrahieren Sie die Bildinformationen shot_time und gps aus den Bildmetadaten.

• SigLIP-2 Bildeinbettung: Das Bild wird durch das Modell geleitet und der Vektor anschließend L2-normalisiert. Speichere die Einbettung im Feld clip_image .

• Die Peaks werden vorhergesagt und im Feld predicted_peaks gespeichert. Dazu nehmen wir zunächst den im vorherigen Schritt erzeugten Bildvektor des Fotos und führen dann eine schnelle kNN-Suche im Feld text_embed im Index peaks_catalog durch. Wir behalten die obersten 3-4 Spitzen bei und ignorieren den Rest.

• Wir berechnen das Feld _id , indem wir einen Hashwert aus Bildname und Pfad erstellen. Dadurch wird sichergestellt, dass nach mehreren Durchläufen keine Duplikate entstehen.

Sobald alle Felder für das Foto ermittelt wurden, werden die Fotodokumente mithilfe der Massenindizierung stapelweise indexiert:

Beispieldokument aus dem Fotoindex:

Zusammenfassend lässt sich sagen, dass der Fotoindex ein schneller, filterbarer und kNN-fähiger Speicher aller Fotos im Album ist. Die Kartierung ist bewusst minimalistisch gehalten – gerade so strukturiert, dass die Ergebnisse schnell abgerufen, übersichtlich dargestellt und nach Raum und Zeit unterteilt werden können. Dieser Index dient beiden Suchanwendungsfällen. Das Python-Skript zur Erstellung beider Indizes finden Sie hier.

Die untenstehende Visualisierung der Kibana-Karten zeigt Dokumente aus dem Fotoalbum als grüne Punkte und Berggipfel ab dem Index peaks_catalog als rote Dreiecke an, wobei die grünen Punkte gut mit dem Wanderweg zum Everest-Basislager übereinstimmen.

Suchanwendungsfälle

Namenssuche (Text-zu-Bild): Mit dieser Funktion können Benutzer mithilfe von Textanfragen Fotos von Berggipfeln (und sogar abstrakten Konzepten wie „Gebetsfahnen“) finden. Um dies zu erreichen, wird die Texteingabe mithilfe von SigLIP-2 in einen Textvektor umgewandelt . Für eine robuste Textvektorgenerierung verwenden wir die gleiche Strategie wie für die Erstellung von Text-Embeddings im peaks_catalog -Index: Kombination der Texteingabe mit einem kleinen Prompt-Ensemble, Subtraktion eines minor Anti-Concept-Vektors und Anwendung der L2-Normalisierung zur Erzeugung des endgültigen Abfragevektors. Anschließend wird eine kNN- Abfrage auf dem Feld photos.clip_image ausgeführt, um die am besten übereinstimmenden Peaks auf Basis der Kosinusähnlichkeit zu ermitteln und so die ähnlichsten Bilder zu finden. Optional können die Suchergebnisse relevanter gestaltet werden, indem Geo- und Datumsfilter und/oder ein photos.predicted_peaks -Termfilter als Teil der Abfrage angewendet werden (siehe Abfragebeispiele unten). Dadurch werden ähnlich aussehende Gipfel ausgeschlossen, die auf der Wanderung gar nicht sichtbar sind.

Elasticsearch-Abfrage mit Geofilter:

Bildsuche (Bild-zu-Bild): Mit dieser Funktion können wir einen Berg auf einem Bild identifizieren und weitere Bilder desselben Berges innerhalb des Fotoalbums finden. Beim Hochladen eines Bildes wird dieses vom SigLIP-2-Bildcodierer verarbeitet, um einen Bildvektor zu erzeugen. Anschließend wird eine kNN-Suche im Feld peaks_catalog.text_embed durchgeführt, um die am besten passenden Peaknamen zu identifizieren. Anschließend wird aus diesen übereinstimmenden Peaknamen ein Textvektor generiert und eine weitere kNN-Suche im Fotoindex durchgeführt, um entsprechende Bilder zu finden.

Elasticsearch-Abfrage:

Schritt 1: Finde die passenden Peaknamen

Schritt 2: Führen Sie eine Suche im Index photos durch, um die passenden Bilder zu finden (dieselbe Abfrage wie im Anwendungsfall der Text-zu-Bild-Suche):

Streamlit-Benutzeroberfläche

Um alles zusammenzuführen, haben wir eine einfache Streamlit-Benutzeroberfläche entwickelt, die es uns ermöglicht, beide Suchanwendungsfälle durchzuführen. In der linken Spalte wird eine scrollbare Liste von Gipfeln (aggregiert aus photos.predicted_peaks) mit Kontrollkästchen und einem Mini-Karten-/Geofilter angezeigt. Ganz oben befinden sich ein Suchfeld für den Namen und eine Schaltfläche zum Hochladen eines Fotos zur Identifizierung . Im mittleren Bereich befindet sich ein responsives Miniaturraster mit kNN-Werten, vorhergesagten Spitzenwerten und Erfassungszeiten. Jedes Bild enthält eine Schaltfläche „Bild anzeigen“ für Vorschauen in voller Auflösung.

Suche durch Hochladen eines Bildes: Wir prognostizieren den Peak und finden übereinstimmende Peaks aus dem Fotoalbum.

Suche nach Text: Finde die passenden Höhepunkte im Album anhand des Textes

Fazit

Was mit der Frage begann: Können wir bitte die Bildervon Ama Dablamsehen? entwickelte sich zu einem kleinen, funktionierenden multimodalen Suchsystem . Wir haben Rohdaten von Trekkingfotos aufgenommen, diese in SigLIP-2-Einbettungen umgewandelt und Elasticsearch verwendet, um ein schnelles kNN über Vektoren durchzuführen, sowie einfache Geo-/Zeitfilter, um die richtigen Bilder anhand ihrer Bedeutung anzuzeigen. Dabei haben wir die Belange mithilfe zweier Indizes getrennt: einem winzigen peaks_catalog Index von kombinierten Prototypen (zur Identifizierung) und einem skalierbaren photos Index von Bildvektoren und EXIF-Daten (zum Abruf). Es ist praktisch, reproduzierbar und leicht erweiterbar.

Falls Sie es feinabstimmen möchten, gibt es einige Einstellungen, mit denen Sie experimentieren können:

• Einstellungen für die Abfragezeit: k (wie viele Nachbarn Sie zurückbekommen möchten) und num_candidates (wie breit die Suche vor der endgültigen Bewertung sein soll). Diese Einstellungen werden hier im Blog besprochen.

• Indexzeiteinstellungen: m (Graphkonnektivität) und ef_construction (Genauigkeit der Build-Zeit vs. Speicher). Experimentieren Sie bei Abfragen auch mit ef_search – ein höherer Wert bedeutet in der Regel eine bessere Trefferquote, allerdings mit einem gewissen Nachteil bei der Latenz. Weitere Einzelheiten zu diesen Einstellungen finden Sie in diesem Blog .

Zukünftig werden native Modelle/Reranker für multimodale und mehrsprachige Suche in Kürze im Elastic-Ökosystem verfügbar sein. Dies dürfte die Bild-/Textsuche und das hybride Ranking von Haus aus noch weiter verbessern. ir.elastic.co+1

Wenn Sie das selbst ausprobieren möchten:

• GitHub-Repository: https://github.com/navneet83/multimodal-mountain-peak-search

• Colab-Schnellstartanleitung: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Damit ist unsere Reise zu Ende, und es ist Zeit, zurückzufliegen. Ich hoffe, das war hilfreich, und falls etwas kaputtgeht (oder verbessert wird), würde ich gerne erfahren, was Sie geändert haben.

Lesen Sie den Blogbeitrag „Building AI Agentic Workflows with Elasticsearch“, um mehr über das Gesamtbild dieser Bemühungen zu erfahren, oder „Your First Elastic Agent: From a Single Query to an AI-Powered Chat“ für eine praxisorientiertere Einführung.

In diesem Blogbeitrag wollen wir uns jedoch etwas genauer mit einem der ersten Dinge befassen, die beim Starten eines Chats passieren, und Ihnen einige der kürzlich vorgenommenen Verbesserungen vorstellen.

Was geschieht hier?

Wenn Sie mit Ihren Elasticsearch-Daten interagieren, durchläuft unser standardmäßiger KI-Agent diesen Standardablauf:

1. Überprüfen Sie die Eingabeaufforderung.

2. Ermitteln Sie, welcher Index wahrscheinlich die Antworten auf diese Frage enthält.

3. Erstelle eine Abfrage für diesen Index basierend auf der Eingabeaufforderung.

4. Durchsuchen Sie diesen Index mit dieser Suchanfrage.

5. Die Ergebnisse zusammenfassen.

6. Können die Ergebnisse die Fragestellung beantworten? Falls ja, antworten Sie bitte. Wenn nicht, wiederholen Sie den Vorgang, aber versuchen Sie etwas anderes.

Das sollte nicht allzu neuartig aussehen – es ist einfach nur Retrieval Augmented Generation (RAG). Wie zu erwarten, hängt die Qualität Ihrer Antworten stark von der Relevanz Ihrer ersten Suchergebnisse ab. Während wir an der Verbesserung unserer Antwortqualität gearbeitet haben, haben wir den Abfragen, die wir in Schritt 3 generiert und in Schritt 4 ausgeführt haben, sehr große Aufmerksamkeit geschenkt. Und wir haben ein interessantes Muster festgestellt.

Oftmals lag es bei unseren ersten, „schlechten“ Antworten nicht daran, dass wir eine fehlerhafte Abfrage ausgeführt hatten. Das lag daran, dass wir den falschen Index für die Abfrage ausgewählt hatten . Die Schritte 3 und 4 waren normalerweise nicht unser Problem – es war Schritt 2.

Was haben wir gemacht?

Unsere erste Implementierung war einfach. Wir hatten ein Tool (namens index_explorer) entwickelt, das effektiv eine _cat/indices -Auflistung aller verfügbaren Indizes durchführt und anschließend den LLM auffordert, denjenigen dieser Indizes zu ermitteln, der am besten zur Nachricht/Frage/Aufforderung des Benutzers passt. Die ursprüngliche Implementierung können Sie hier einsehen.

Wie gut funktionierte das? Wir waren uns nicht sicher! Wir hatten klare Beispiele, wo es nicht gut funktionierte, aber unsere eigentliche erste Herausforderung bestand darin, unseren aktuellen Zustand zu quantifizieren.

Festlegung einer Ausgangsbasis

Es beginnt mit Daten

Was wir brauchten, war ein Referenzdatensatz, um die Effektivität eines Tools bei der Auswahl des richtigen Index anhand einer Benutzereingabe und einer bereits vorhandenen Menge von Indizes zu messen. Und wir hatten keinen solchen Datensatz zur Hand. Also haben wir einen generiert.

Hinweis: Wir wissen, dass dies nicht die „Best Practice“ ist. Manchmal ist es aber besser, vorwärts zu gehen, als auf der Stelle zu treten. Fortschritt, schlichte Perfektion.

Wir haben mithilfe dieser Eingabeaufforderung Startindizes für verschiedene Domänen generiert. Anschließend generierten wir für jede generierte Domäne mithilfe dieser Eingabeaufforderung einige weitere Indizes (Ziel war es, das LLM mit schwierigen Negativen und schwer zu klassifizierenden Beispielen zu verwirren). Anschließend haben wir jeden generierten Index und seine Beschreibungen manuell bearbeitet. Abschließend generierten wir mithilfe dieser Eingabeaufforderung Testabfragen. Dies ergab Beispieldaten wie:

und Testfälle wie:

Anfertigung eines Testgeschirrs

Der weitere Ablauf war von hier an sehr einfach. Entwerfen Sie ein Tool, das Folgendes kann:

1. Erstellen Sie eine saubere Ausgangsbasis mit einem Elasticsearch-Zielcluster.

2. Erstelle alle im Zieldatensatz definierten Indizes.

3. Führen Sie für jedes Testszenario das Tool index_explorer aus (praktischerweise verfügen wir über eine Execute Tool API).

4. Vergleiche den Ergebnisindex mit dem erwarteten Index und speichere das Ergebnis.

5. Nachdem alle Testszenarien abgeschlossen sind, werden die Ergebnisse tabellarisch erfasst.

Laut einer Umfrage…

Die ersten Ergebnisse waren wenig überraschend mittelmäßig.

Insgesamt lag die Trefferquote bei der Identifizierung des richtigen Index bei 77,14 %. Und das war ein „Best-Case“-Szenario, in dem alle Indizes gute, semantisch aussagekräftige Namen haben. Jeder, der schon einmal `PUT test2/_doc/foo {...}` ausgeführt hat, weiß, dass die Indizes nicht immer aussagekräftige Namen haben.

Wir haben also einen Ausgangspunkt, und dieser zeigt, dass es noch viel Raum für Verbesserungen gibt. Nun war es Zeit für etwas Wissenschaft! 🧪

Experimentieren

Hypothese 1: Kartierungen werden helfen

Das Ziel hierbei ist es, einen Index zu identifizieren, der Daten enthält, die für die ursprüngliche Fragestellung relevant sind. Und der Teil eines Index, der die darin enthaltenen Daten am besten beschreibt, sind die Indexzuordnungen. Selbst ohne Stichproben aus dem Indexinhalt zu entnehmen, lässt die Tatsache, dass der Index ein Preisfeld vom Typ double besitzt, darauf schließen, dass die Daten etwas darstellen, das verkauft werden soll. Ein Autorenfeld vom Typ Text impliziert unstrukturierte Sprachdaten. Die Kombination der beiden Begriffe könnte darauf hindeuten, dass es sich bei den Daten um Bücher/Geschichten/Gedichte handelt. Allein aus der Kenntnis der Eigenschaften eines Index lassen sich viele semantische Hinweise ableiten. In einem lokalen Branch habe ich also unsere `.index_explorer`-Methode angepasst. Tool zum Senden der vollständigen Zuordnungen eines Index (samt Namen) an das LLM zur Entscheidungsfindung.

Das Ergebnis (aus den Kibana-Protokollen):

Die ursprünglichen Entwickler des Tools hatten dies vorhergesehen. Während die Zuordnung eines Index eine wahre Fundgrube an Informationen darstellt, ist sie gleichzeitig ein ziemlich umfangreicher JSON-Block. Und in einem realistischen Szenario, in dem man zahlreiche Indizes vergleicht (unser Evaluierungsdatensatz definiert 20), summieren sich diese JSON-Blobs. Wir möchten dem LLM also mehr Kontext für seine Entscheidung geben als nur Indexnamen für alle Optionen, aber nicht so sehr die vollständigen Zuordnungen jeder einzelnen.

Hypothese 2: „Vereinfachte“ Zuordnungen (Feldlisten) als Kompromiss

Wir gingen von der Annahme aus, dass Indexersteller semantisch aussagekräftige Indexnamen verwenden würden. Was wäre, wenn wir diese Annahme auch auf Feldnamen ausdehnen würden? Unser vorheriges Experiment scheiterte, weil Mapping-JSON eine Menge überflüssiger Metadaten und Boilerplate-Code enthält.

Der obige Block beispielsweise umfasst 236 Zeichen und definiert lediglich ein einzelnes Feld in einem Elasticsearch-Mapping. Die Zeichenkette „description_text“ hingegen umfasst nur 16 Zeichen. Das entspricht einer fast 15-fachen Erhöhung der Zeichenanzahl, ohne dass sich die semantische Aussagekraft dieses Feldes hinsichtlich der verfügbaren Daten sinnvoll verbessert. Was wäre, wenn wir Zuordnungen für alle Indizes abrufen, diese aber vor dem Senden an das LLM zu einer Liste ihrer Feldnamen „vereinfachen“ würden?

Wir haben es versucht.

Das ist großartig! Durchweg Verbesserungen. Aber könnten wir es besser machen?

Hypothese 3: Beschreibungen in der Mapping-Datei _meta

Wenn schon Feldnamen ohne zusätzlichen Kontext einen so großen Sprung verursachen, wäre das Hinzufügen von substanziellem Kontext vermutlich noch besser! Es ist nicht unbedingt üblich, jedem Index eine Beschreibung beizufügen, aber es ist möglich, dem _meta-Objekt der Zuordnung Metadaten auf Indexebene jeglicher Art hinzuzufügen. Wir haben unsere generierten Indizes erneut aufgerufen und jedem Index in unserem Datensatz eine Beschreibung hinzugefügt. Solange die Beschreibungen nicht übermäßig lang sind, sollten sie weniger Tokens verwenden als die vollständige Zuordnung und einen deutlich besseren Einblick in die im Index enthaltenen Daten bieten. Unser Experiment bestätigte diese Hypothese.

Eine kleine Verbesserung, und wir liegen jetzt durchweg bei über 90 % Genauigkeit.

Hypothese 4: Das Ganze ist größer als seine Teile

Feldnamen haben unsere Ergebnisse verbessert. Die Beschreibungen verbesserten unsere Ergebnisse. Die Verwendung von Beschreibungen UND Feldnamen sollte also noch bessere Ergebnisse liefern, richtig?

Die Daten ergaben „nein“ (keine Veränderung gegenüber dem vorherigen Experiment). Die vorherrschende Theorie hierbei war, dass, da die Beschreibungen von vornherein aus den Indexfeldern/Zuordnungen generiert wurden, zwischen diesen beiden Kontextelementen nicht genügend unterschiedliche Informationen vorhanden sind, um bei ihrer Kombination etwas „Neues“ hinzuzufügen. Darüber hinaus wird die Nutzlast, die wir für unsere 20 Testindizes senden, ziemlich groß. Der Gedankengang, dem wir bisher gefolgt sind, ist nicht skalierbar. Tatsächlich gibt es guten Grund zu der Annahme, dass keines unserer bisherigen Experimente auf Elasticsearch-Clustern funktionieren würde, bei denen Hunderte oder Tausende von Indizes zur Auswahl stehen. Ein Ansatz, der die Größe der an den LLM gesendeten Nachricht linear mit der Gesamtzahl der Indizes erhöht, dürfte wahrscheinlich keine allgemein anwendbare Strategie darstellen.

Was wir wirklich brauchen, ist ein Ansatz, der uns hilft, eine große Anzahl von Kandidaten auf die relevantesten Optionen zu reduzieren…

Wir haben es hier mit einem Suchproblem zu tun.

Hypothese 5: Selektion durch semantische Suche

Wenn der Name eines Indexes eine semantische Bedeutung hat, dann kann er als Vektor gespeichert und semantisch durchsucht werden.

Wenn die Feldnamen eines Index eine semantische Bedeutung haben, dann können sie als Vektoren gespeichert und semantisch durchsucht werden.

Wenn ein Index eine Beschreibung mit semantischer Bedeutung besitzt, kann auch diese als Vektor gespeichert und semantisch durchsucht werden.

Aktuell sind diese Informationen mit Elasticsearch-Indizes nicht durchsuchbar (vielleicht sollten wir das ändern!), aber es war relativ einfach, etwas zusammenzubasteln , das diese Lücke umgehen konnte. Mithilfe des Connector-Frameworks von Elastic habe ich einen Connector erstellt, der für jeden Index in einem Cluster ein Dokument ausgibt. Die Ausgabedokumente würden etwa so aussehen:

Ich habe diese Dokumente in einen neuen Index verschoben, in dem ich die Zuordnung manuell wie folgt definiert habe:

Dadurch entsteht ein einzelnes semantisches Inhaltsfeld, in dem alle anderen Felder mit semantischer Bedeutung zusammengefasst und indiziert werden. Die Suche in diesem Index wird trivial, mit lediglich:

Das modifizierte index_explorer -Tool ist jetzt wesentlich schneller, da es keine Anfrage an ein LLM stellen muss, sondern stattdessen eine einzelne Einbettung für die gegebene Anfrage anfordern und eine effiziente Vektorsuche durchführen kann. Wenn wir den Spitzenreiter als unseren ausgewählten Index verwenden, erhalten wir folgende Ergebnisse:

Dieser Ansatz ist skalierbar. Diese Vorgehensweise ist effizient. Dieser Ansatz ist aber kaum besser als unser Ausgangszustand. Das ist allerdings nicht überraschend; der Suchansatz ist hier unglaublich naiv. Da gibt es keine Nuancen. Es wird nicht anerkannt, dass der Name und die Beschreibung eines Index mehr Gewicht haben sollten als ein beliebiger Feldname, der im Index enthalten ist. Es besteht keine Möglichkeit, exakte lexikalische Übereinstimmungen gegenüber synonymen Übereinstimmungen zu gewichten. Allerdings müsste man für die Erstellung einer hochdifferenzierten Abfrage eine Menge Annahmen über die vorliegenden Daten treffen. Bis jetzt haben wir bereits einige große Annahmen darüber getroffen, dass Index- und Feldnamen eine semantische Bedeutung haben, aber wir müssten noch einen Schritt weiter gehen und anfangen anzunehmen, wie viel Bedeutung sie haben und wie sie zueinander in Beziehung stehen. Ohne dies zu tun, können wir wahrscheinlich nicht zuverlässig die beste Übereinstimmung als unser Top-Ergebnis identifizieren, sondern können eher sagen, dass die beste Übereinstimmung irgendwo unter den Top N Ergebnissen liegt. Wir benötigen etwas, das semantische Informationen in dem Kontext, in dem sie existieren, verarbeiten, mit einer anderen Entität vergleichen kann, die sich möglicherweise auf eine semantisch unterschiedliche Weise darstellt, und zwischen ihnen urteilen kann. Wie ein LLM.

Hypothese 6: Reduktion der Kandidatenmenge

Es gab noch einige weitere Experimente, die ich hier nur kurz erwähnen werde, aber der entscheidende Durchbruch bestand darin, den Wunsch aufzugeben, die beste Übereinstimmung ausschließlich anhand einer semantischen Suche auszuwählen, und stattdessen die semantische Suche als Filter zu nutzen, um irrelevante Indizes aus der Betrachtung des LLM auszusortieren. Wir kombinierten Linear Retrievers, Hybrid Search mit RRF und semantic_text für unsere Suche und beschränkten die Ergebnisse auf die Top 5 übereinstimmenden Indizes.

Anschließend haben wir für jede Übereinstimmung den Namen des Index, die Beschreibung und die Feldnamen zu einer Nachricht für das LLM hinzugefügt. Die Ergebnisse waren fantastisch:

Die höchste Genauigkeit, die je in einem Experiment erzielt wurde! Und weil bei diesem Ansatz die Nachrichtengröße nicht proportional zur Gesamtzahl der Indizes ansteigt, ist dieser Ansatz weitaus besser skalierbar.

Ergebnisse

Das erste eindeutige Ergebnis war, dass unsere Ausgangslage verbessert werden kann . Dies erscheint im Nachhinein offensichtlich, aber bevor die Experimente begannen, gab es ernsthafte Diskussionen darüber, ob wir unser index_explorer -Tool ganz aufgeben und uns auf eine explizite Konfiguration durch den Benutzer verlassen sollten, um den Suchraum einzuschränken. Auch wenn dies nach wie vor eine praktikable und gültige Option darstellt, zeigt diese Studie, dass es vielversprechende Wege zur Automatisierung der Indexauswahl gibt, wenn solche Benutzereingaben nicht verfügbar sind.

Das nächste eindeutige Ergebnis war, dass das bloße Hinzufügen weiterer beschreibender Zeichen zur Lösung des Problems immer weniger Nutzen bringt. Vor dieser Studie hatten wir darüber diskutiert, ob wir in den Ausbau der Elasticsearch-Funktionalität zur Speicherung von Metadaten auf Feldebene investieren sollten. Heute sind diese meta -Werte auf 50 Zeichen begrenzt, und es gab die Annahme, dass wir diesen Wert erhöhen müssten, um ein semantisches Verständnis unserer Felder zu erlangen. Dies ist eindeutig nicht der Fall, und das LLM scheint mit reinen Feldnamen recht gut zurechtzukommen. Wir werden dies möglicherweise später noch genauer untersuchen, aber es erscheint uns momentan nicht dringlich.

Umgekehrt hat dies deutlich gezeigt, wie wichtig „durchsuchbare“ Indexmetadaten sind. Für diese Experimente haben wir einen Index von Indizes gehackt. Aber das ist etwas, was wir untersuchen könnten, indem wir es direkt in Elasticsearch integrieren, APIs zur Verwaltung erstellen oder zumindest eine Konvention dafür festlegen. Wir werden unsere Optionen abwägen und intern diskutieren, also bleiben Sie gespannt.

Letztendlich hat diese Anstrengung den Wert darin bestätigt, uns Zeit für Experimente zu nehmen und datengestützte Entscheidungen zu treffen. Tatsächlich hat es uns geholfen, erneut zu bestätigen, dass unser Agent Builder-Produkt robuste, im Produkt integrierte Evaluierungsfunktionen benötigt. Wenn wir ein komplettes Test-Framework nur für ein Tool entwickeln müssen, das Indizes auswählt, benötigen unsere Kunden unbedingt Möglichkeiten, ihre kundenspezifischen Tools qualitativ zu bewerten, während sie iterative Anpassungen vornehmen.

Ich bin gespannt, was wir bauen werden, und ich hoffe, Sie auch!

Lernen Sie den Linear Retriever kennen!

In diesem Beitrag stellen wir den linear Retriever vor, unsere neueste Ergänzung zur Unterstützung der Hybridsuche! Im Gegensatz zu rrf berechnet der linear -Retriever eine gewichtete Summe aller Abfragen, die mit einem Dokument übereinstimmen. Dieser Ansatz bewahrt die relative Bedeutung jedes Dokuments innerhalb eines Ergebnissatzes und ermöglicht gleichzeitig eine präzise Kontrolle über den Einfluss jeder Abfrage auf das Endergebnis. Dadurch bietet es eine intuitivere und flexiblere Möglichkeit zur Feinabstimmung der Hybridsuche.

Definieren eines linearen Retrievers, bei dem die endgültige Punktzahl wie folgt berechnet wird:

Es ist so einfach wie:

Merken Sie, wie einfach und intuitiv es ist? (und sehr ähnlich zu rrf!) Mit dieser Konfiguration können Sie genau steuern, wie viel jeder Abfragetyp zum endgültigen Ranking beiträgt, im Gegensatz zu rrf, das sich ausschließlich auf relative Ränge stützt.

Ein Vorbehalt bleibt bestehen: knn -Wertungen können je nach verwendeter Ähnlichkeitsmetrik streng begrenzt sein. Beispielsweise liegen die Werte bei der Kosinusähnlichkeit oder dem Skalarprodukt einheitsnormalisierter Vektoren immer im Bereich [0, 1] . Im Gegensatz dazu sind bm25 -Werte weniger vorhersehbar und haben keine klar definierten Grenzen.

Skalierung der Ergebnisse: kNN vs. BM25

Eine Herausforderung bei der Hybridsuche besteht darin, dass verschiedene Retriever Ergebnisse auf unterschiedlichen Skalen liefern. Stellen Sie sich beispielsweise das folgende Szenario vor:

Abfrage A-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

Abfrage B-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

0,63

0,01

0,3

0,4

Sie können die Ungleichheit oben sehen: kNN -Wertungen liegen zwischen 0 und 1, während bm25 -Wertungen stark variieren können. Dieser Unterschied macht es schwierig, statische optimale Gewichte für die Kombination der Ergebnisse festzulegen.

Normalisierung zur Rettung: der MinMax-Normalisierer

Um dieses Problem zu beheben, haben wir einen optionalen minmax -Normalisierer eingeführt, der die Punktzahlen unabhängig für jede Abfrage mithilfe der folgenden Formel auf den [0, 1] -Bereich skaliert:

Dadurch bleibt die relative Wichtigkeit jedes Dokuments innerhalb des Ergebnissatzes einer Abfrage erhalten, was die Kombination von Bewertungen verschiedener Abrufer erleichtert. Durch die Normalisierung ergeben sich folgende Werte:

Abfrage A-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,01

0,005

0,000

Abfrage B-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,000

0,465

0,645

Alle Punktzahlen liegen jetzt im Bereich [0, 1] und die Optimierung der gewichteten Summe ist viel einfacher, da wir jetzt die (im Verhältnis zur Abfrage) Wichtigkeit eines Ergebnisses anstelle seiner absoluten Punktzahl erfassen und die Konsistenz über alle Abfragen hinweg aufrechterhalten.

Beispiel für einen linearen Retriever

Sehen wir uns nun ein Beispiel an, um zu zeigen, wie das oben genannte aussieht und wie der linear -Retriever einige der Mängel von rrf behebt. RRF basiert ausschließlich auf relativen Rängen und berücksichtigt keine tatsächlichen Punkteunterschiede. Beispielsweise bei diesen Ergebnissen:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

RRF-Score

0,03226

0,03252

0,03200

0,03125

rrf würde die Dokumente wie folgt einstufen:

Allerdings weist doc1 einen deutlich höheren bm25 -Score als die anderen auf, den rrf nicht erfasst, da nur die relativen Ränge berücksichtigt werden. Der linear -Retriever berücksichtigt in Kombination mit der Normalisierung sowohl die Punktzahlen als auch ihre Unterschiede korrekt und erzeugt so eine aussagekräftigere Rangfolge:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1

0,01

0,005

0

Wie wir oben sehen können, wird das großartige Ranking von doc1 und score für bm25 richtig berücksichtigt und in den endgültigen Ergebnissen widergespiegelt. Darüber hinaus liegen jetzt alle Ergebnisse im Bereich [0, 1] , sodass wir sie viel intuitiver vergleichen und kombinieren können (und sogar Offline-Optimierungsprozesse erstellen können).

Alles zusammenfügen

Um den linear -Retriever mit Normalisierung optimal zu nutzen, würde die Suchanfrage folgendermaßen aussehen:

Dieser Ansatz kombiniert das Beste aus beiden Welten: Er behält die Flexibilität und intuitive Bewertung des linear -Retrievers bei und gewährleistet gleichzeitig eine konsistente Bewertungsskalierung mit MinMax-Normalisierung.

Wie alle unsere Retriever kann der linear -Retriever in jede Ebene eines hierarchischen Retrieverbaums integriert werden und bietet Unterstützung für Erklärbarkeit, Hervorhebung von Übereinstimmungen, Ausblenden von Feldern und mehr.

Wann Sie sich für den Linear Retriever entscheiden sollten und warum das einen Unterschied macht

Der linear -Retriever:

• Bewahrt die relative Bedeutung durch die Nutzung tatsächlicher Punktzahlen und nicht nur von Rängen.

• Ermöglicht eine Feinabstimmung mit gewichteten Beiträgen aus verschiedenen Abfragen.

• Verbessert die Konsistenz durch Normalisierung und macht die Hybridsuche robuster und vorhersehbarer.

Fazit

Der linear -Retriever ist bereits auf Elasticsearch Serverless und den Versionen 8.18 und 9.0 verfügbar! Weitere Beispiele und Konfigurationsparameter finden Sie auch in unserer Dokumentation. Probieren Sie es aus und sehen Sie, wie es Ihr Hybridsucherlebnis verbessern kann – wir freuen uns auf Ihr Feedback. Viel Spaß beim Suchen!