Wie wir Elasticsearch simdvec entwickelten

Jede Vektorsuchanfrage in Elasticsearch, sei es ein Hierarchical Navigable Small World (HNSW) Traversal, ein Inverted File (IVF) Scan oder ein Reranking-Pass, reduziert sich auf dasselbe Problem: die Berechnung der Distanzen zwischen Vektoren, und zwar millionenfach pro Anfrage. Elasticsearch unterstützt eine breite Palette von Datentypen und Quantisierungsstrategien, von float32 über int8, bfloat16, binär und Better Binary Quantization (BBQ). Jede Option bringt unterschiedliche Kompromisse zwischen Speicher, Durchsatz und Abruf mit sich. Hinter all dem steht eine einzige Engine: simdvec.

Wir haben simdvec so entwickelt, dass jede Entfernungsberechnung so schnell erfolgt, wie es die Hardware erlaubt. In diesem Beitrag geht es darum, warum wir sie entwickelt haben, was in ihr steckt und wo sie die größte Wirkung erzielt.

Gebaut wie ein Rennwagen

Als Formel-1-Enthusiasten, mit einer Person, die bereits mit dem Formel-1-Team von Ferrari gearbeitet hat, sehen wir eine klare Parallele. Ein Formel-1-Wagen wird mit einem einzigen Ziel entwickelt: die beste Rundenzeit zu erzielen. Motorleistung, Aerodynamik und Fahrwerkskonstruktion spielen nur insofern eine Rolle, als dass sie zu diesem Ergebnis beitragen. Das Gleiche gilt für eine Vektordatenbank, in der Indexierungsdurchsatz, Abfragelatenz und Rückruf den Erfolg definieren.

Das Endergebnis ist zwar wichtig, aber um ein Höchstmaß an Leistung zu erreichen, muss jede Komponente ihr Bestes geben. Es reicht nicht, wenn sie einfach nur gut sind, sie müssen die Besten in ihrer Kategorie sein. Simdvec wurde mit dieser Denkweise entwickelt und konzentriert sich auf einen entscheidenden Teil des Systems: die Engine. Sie ist eine zweckgebundene, Single Instruction Multiple Data (SIMD) optimierte Kernel-Bibliothek, die von Hand optimierte, native C++ Distanzfunktionen bereitstellt, die von Java über die Panama Foreign Function Interface (FFI) aufgerufen werden. Sie unterstützt Bulk-Scoring, Prefetching von Cache-Linien sowie alle in Elasticsearch verwendeten Vektortypen und Layouts.

Das ist der Motor hinter jeder Abfrage.

Warum wir unser eigenes System entwickelt haben

Wir haben 2023 mit der Panama Vector API in Apache Lucene begonnen. Für float32-Punktprodukte war das zunächst ideal, doch die Anforderungen von Elasticsearch überstiegen schnell die Möglichkeiten des Systems. Elasticsearch unterstützt eine breite Palette quantisierter Vektortypen: int8, int4, bfloat16, Single-Bit und asymmetrisches BBQ. Jedes System verfügt über unterschiedliche SIMD-Strategien, Packungs- und Akkumulatoranforderungen. Über die Typabdeckung hinaus verlangen die Scoring-Pfade von Elasticsearch mehr als einen Durchsatz für einzelne Paare: HNSW muss mehrere Graphnachbarn in einem Durchgang bewerten, IVF benötigt eine Massenbewertung von Tausenden von Kandidaten mit Vorabruf und die auf Festplatten basierte Bewertung muss direkt auf dem mmap-Speicher arbeiten, ohne zu kopieren. Kein Angebot auf dem Markt deckte das gesamte Spektrum ab.

Also haben wir simdvec entwickelt: Von Hand optimierte, native C++-Kernel, die über FFI aus Java aufgerufen werden, mit Bulk-Scoring, Prefetching und Unterstützung für jeden von Elasticsearch verwendeten Vektortyp. Als Inhaber der Bibliothek kontrollieren wir den gesamten Stack. Wenn wir einen neuen Quantisierungstyp wie BBQ hinzufügen, wird ein optimierter SIMD-Kernel im gesamten System integriert. Wir warten nicht auf die Unterstützung durch eine Upstream-Bibliothek und gehen absolut keine Kompromisse bei der Leistung ein. Jede Vektorabfrage in Elasticsearch, ob HNSW, IVF, Reranking oder Hybrid, läuft auf dieser Engine, die auf den von uns tatsächlich verwendeten Operationen und Typen aufbaut.

Simdvec verfügt über separate native Bibliotheken für x86 und ARM, wobei jeweils mehrere ISA-Ebenen (Instruction Set Architecture) beim Starten ausgewählt werden. Der Call-Overhead von Java über FFI ist mit einstelligen Nanosekunden sehr gering.

Die Landschaft

Wir sind nicht die Einzigen, die SIMD-optimierte Vektordistanz-Kernel erstellen. Das Ökosystem ist vielfältig und wir wollten verstehen, wie simdvec funktioniert. Nicht um Projekte zu bewerten, sondern um Kontext zu liefern und zu erklären, wo die Elasticsearch-Engine angesiedelt ist. Wir haben drei Projekte als Referenzpunkte ausgewählt, die jeweils einen anderen Ansatz repräsentieren:

• jvector: Eine Java-Bibliothek für Approximate Nearest Neighbor (ANN), die die Panama Vector API für vektorisierte Entfernungsberechnungen verwendet, mit optionaler nativer C-Beschleunigung auf x86.

• FAISS: Ein weit verbreitetes Open-Source-Framework zur Vektorsuche mit von Hand optimierten AVX2/AVX-512-Kernel.

• NumKong (ehemals SimSIMD): Eine umfassende Suite von über 2.000 von Hand optimierten SIMD-Kernel über Distanzfunktionen, Matrixoperationen und georäumliche Berechnungen.

Jedes Projekt verfolgt einen anderen Zweck und geht unterschiedliche Kompromisse ein. Wir fügen daraus Referenznummern hinzu, um Kontext für die Leistung von simdvec bei den spezifischen Abläufen zu erhalten, die Elasticsearch benötigt.

Wie wir messen

Die simdvec- und jvector-Benchmarks wurden in Java mit JMH, dem Standard JVM-Microbenchmark-Harness, geschrieben, einschließlich FFI-Overhead. Für die NumKong-Benchmarks und die FAISS-Benchmarks haben wir mit Google Benchmark, dem Standard-C++-Mikrobenchmark-Framework, kleine C/C++-Harnesses geschrieben. Beide Frameworks melden Nanosekunden pro Operation mit Aufwärmung und Iterationskalibrierung. Wir haben anhand von Hardware-Leistungszählern überprüft, dass alle Bibliotheken auf beiden Plattformen SIMD verwenden. Der gesamte Benchmark-Code ist in den verlinkten GitHub-Repositories (und im Fall von simdvec im Elasticsearch-Repository) öffentlich verfügbar.

Software: JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (neueste Version).

Ein Vektor nach dem anderen

Die grundlegendste Funktion der Vektorsuche ist die Berechnung des Abstands zwischen zwei Vektoren. Jede HNSW-Nachbarbewertung, jede IVF-Kandidatenbewertung und jeder Reranking-Vergleich dreht sich um diese interne Schleife.

Wir haben den Durchsatz einzelner Datenpaare in 1024 Dimensionen auf beiden Plattformen gemessen, beginnend mit float32, dem Basistyp, bei dem das Ökosystem am wettbewerbsfähigsten ist. Wir vergleichen simdvec mit FAISS und jvector, wobei wir NumKong ausgeschlossen haben, da es float64-Akkumulatoren für float32 verwendet, was es je nach Plattform 3,2- bis 5,3-mal langsamer macht und numerische Präzision über Durchsatz gestellt wird. Um den Vergleich nicht zu verfälschen, testen wir NumKong stattdessen auf int8, wo es die gleiche Akkumulatorstrategie wie simdvec verwendet.

Auf x86 ist FAISS AVX-512 der schnellste Einzelpaar-Kernel mit 23 ns. Simdvec AVX-512 folgt mit 28 ns, eine Lücke, die den Overhead des FFI-Aufrufs widerspiegelt. Beide verwenden 512-Bit-FMA mit Multi-Akkumulator-Unrolling. Auf der AVX2-Ebene liegen die beiden sehr viel näher beieinander, nämlich 36 ns bzw. 39 ns, die beide durch die 256-Bit-Register- und Speicherladebreiten eingeschränkt sind. jvector landet bei 44 ns mit der Java Panama Vector API. Panama generiert guten SIMD-Code, aber von Hand optimierte C++-Intrinsics sind hier im Vorteil

Auf ARM liegt simdvec mit 70 ns deutlich vor jvector mit 110 ns und FAISS mit 156 ns. Simdvec verfügt über von Hand optimierte NEON-Kernel für aarch64. Jvector hat keinen nativen ARM-Code und basiert auf Panama. FAISS verlässt sich auf die automatische Vektorisierung des Compilers und nicht auf explizite NEON-Intrinsics, was den größeren Abstand erklärt. Dies spiegelt einen praktischen Vorteil des Besitzes der Kernel-Bibliothek wider: Als Elasticsearch zu Graviton erweitert wurde, fügten wir eigens entwickelte NEON-Kernel hinzu. Weder jvector noch FAISS haben nativem ARM-Code den gleichen Stellenwert eingeräumt.

Elasticsearch bewertet aber nicht nur float32. Int8-Quantisierung reduziert den Speicher um das Vierfache, bfloat16 um das Doppelte und BBQ um das 32-Fache. Jeder Typ benötigt seine eigene SIMD-Strategie und simdvec bietet von Hand optimierte, native Kernel für alle diese Typen.

Von den Bibliotheken, die wir verglichen haben, hat nur NumKong vergleichbare Kernel für int8. Wir haben das int8-Skalarprodukt, die quadrierte euklidische Distanz und den Kosinus bei 1024 Dimensionen gemessen.

Int8 Einzelpaar-Wertung (1024 Dimensionen, ns/vec op – je niedriger, desto besser)

Auf beiden Architekturen ist NumKong bei kleinen bis mittleren Dimensionen gleich schnell oder sogar schneller, wobei der Unterschied hauptsächlich auf den geringeren Call-Overhead zurückzuführen ist (direkter C-Call vs. Java FFI). Bei größeren Dimensionen holt simdvec auf, wobei die effizientere Kernel-Implementierung (die Cascade Unrolling verwendet) die Aufrufkosten amortisiert: Mit zunehmender Dimension schließt sich diese Lücke und kehrt sich schließlich um. Die Übergangsdimensionen liegen je nach Funktion und Architektur zwischen 768 und 1536.

Trotz des etwas höheren Aufwands von Java FFI befindet sich simdvec mit hochoptimierten C/C++-Bibliotheken auf Augenhöhe. Sie ist nicht nur die einzige Bibliothek mit optimierten Kernel für float32 und int8, sondern führt auch beim ARM und liegt auf x86 (für float32) nur leicht hinter FAISS zurück und auf beiden Architekturen sehr nahe an NumKong (für int8). Für bfloat16, int4, binär und BBQ gibt es zwar Alternativen, aber simdvec zeichnet sich durch von Hand optimierte SIMD aus, die auf das Datenlayout jedes Typs zugeschnitten ist.

Eine Produktionssuchmaschine bewertet jedoch nicht einen Vektor nach dem anderen, sondern Tausende pro Abfrage. Die nächste Frage ist, was in diesem Maßstab passiert.

Tausende auf einmal

Die Leistung eines einzelnen Paares stellt nur einen Teil des Gesamtbildes dar. In der Praxis ist entscheidend, wie sich Systeme unter Last verhalten. Eine einzelne HNSW-Abfrage kann Hunderte von Nachbarn im Graphen bewerten. Ein IVF-Scan kann Tausende von Einträgen in Posting-Listen bewerten. Ein Reranking-Durchlauf kann Zehntausende von Kandidaten bewerten. Der Durchsatz pro Paar ist wichtig, aber noch wichtiger ist, wie schnell Sie viele Vektoren bewerten können und wie gut die Leistung nachlässt, wenn das Working Set nicht mehr in die CPU-Caches passt.

Simdvec bietet Bulk-Scoring für jeden Datentyp. Dabei handelt es sich nicht nur um Schleifen über Single-Pair-Kerne, sondern auch um innere Schleifen mit mehreren Akkumulatoren, die den Abfragevektor einmal pro Dimensionsschritt laden und ihn auf mehrere Dokumentvektoren verteilen, mit explizitem Cache-Line-Prefetching für den nächsten Batch. Weder jvector noch FAISS bieten ein Äquivalent (zum jetzigen Zeitpunkt). Jvector hat keine Bulk-API, sodass der Aufrufer ein Paar nach dem anderen in einer Schleife bewertet. FAISS stellt fvec_inner_products_ny zur Verfügung, das zum Zeitpunkt der Erstellung dieses Artikels als Schleife über die Single-Pair-Distanzfunktion ohne Amortisierung der Abfrage oder Vorabruf implementiert ist.

Float32. Um die Wirkung auf Kernel-Ebene zu messen, bewerteten wir eine einzelne Abfrage gegen zunehmende Zahlen von 1024-Dimension-float32-Dokumentvektoren mit Random-Access-Mustern, die HNSW-ähnliche verstreute Graph-Nachbarschaftsabfragen simulieren. Die drei Datensatzgrößen von 32, 625 und 32.500 Vektoren werden so gewählt, dass der Arbeitssatz den L1-, L2- und L3-Cache übersteigt.

Wenn die Daten in den Cache passen, ist simdvec auf beiden Plattformen am schnellsten, aber die Margen sind moderat, da die Kernel-Arithmetik dominiert. Die tatsächliche Trennung zeigt sich, wenn der Arbeitssatz über L3 hinauswächst. Auf x86 erzielt simdvec 95 ns pro Vektor, während FAISS 165 ns und jvector 412 ns benötigt. Auf ARM ist das Muster dasselbe: simdvec bleibt bei 162 ns, während FAISS auf 347 ns und jvector auf 476 ns ansteigt. Das Prefetching und die Abfrage-Amortisierung in simdvec verbergen die Speicherlatenz auf eine Weise, die eine einfache Schleife über Einzelpaar-Kernel nicht erreichen kann, und der Vorteil erweitert sich genau dort, wo reale Suchworkloads tief im Hauptspeicher arbeiten.

Int8. Das gleiche Muster gilt für quantisierte Datentypen. Wir haben die Bulk-Bewertung von int8-Punktprodukten in 1024 Dimensionen mit Datensatzgrößen gemessen, die so gewählt wurden, dass sie die gleichen L1-, L2- und L3-Cache-Grenzen überschritten, und die Bulk-Bewertung von simdvec mit der Single-Pair-Bewertung von NumKong in einer Schleife verglichen.

Auf x86 ist simdvec zwischen 1,2-mal und 1,9-mal schneller, was auf die Kombination aus explizitem Prefetching und Batch-Verarbeitung zurückzuführen ist. Auf ARM ist simdvec bei allen Datensätzen erneut im Vorteil (1,7- bis 1,9-mal schneller). Der Vorteil liegt in der Batch-Verarbeitung von vier Vektoren auf einmal, die über ein verschachteltes Zugriffsmuster Parallelisierung auf Speicherebene bietet. In beiden Fällen ist das auffälligste Ergebnis, was bei der größten Datensatzgröße passiert, wo es am wichtigsten ist.

Die Ergebnisse für quadrierten Abstand und Kosinus zeigen ein ähnliches Muster, mit Beschleunigungen von 1,4x bis 1,8x für ARM und von 1,3x bis 3,0x für x86 (mehr dazu hier).

Wo Speicher eine Rolle spielt

Vektorindizes in der Produktion passen normalerweise nicht in den CPU-Cache. Ein 10M-Vektor-Int8-Index bei 1024 Dimensionen entspricht 10 GB. Die Bewertung von Kandidaten bedeutet das Streamen von Daten aus dem DRAM, und genau hier macht die Architektur für die Massenbewertung den Unterschied.

Wir verwendeten Hardware-Leistungszähler, um zu messen, was während der Massenbewertung innerhalb der CPU passiert, und stellten fest, dass das Verbergen der Speicherlatenz zwei grundlegend verschiedene Strategien erfordert: eine pro Architektur.

Auf x86 eliminiert explizites Prefetching Cache-Fehler. Der Bulk-Kernel verarbeitet Vektoren sequenziell – einen nach dem anderen vollständig berechnet – während er gleichzeitig Prefetch-Anweisungen für den nächsten Batch ausgibt. Künftige Daten werden in den L1-Cache geladen, bevor die CPU sie benötigt.

Auf ARM funktionierte derselbe sequentielle Ansatz nicht so gut, selbst mit Prefetching. Stattdessen verschachtelt der Bulk-Kernel Ladungen von vier Vektoren an jeder Schrittposition, wodurch die Out-of-Order-Engine vier unabhängige Speicherstreams erhält. Die CPU holt Daten nicht schneller, sondern wartet vielmehr weniger, weil sie während der Bearbeitung von Speicheranfragen immer etwas anderes zu berechnen hat. Eine detaillierte Analyse finden Sie in diesem GitHub-Issue.

Die Zahlen erzählen zwei unterschiedliche Geschichten:

1. Auf x86 verwandelt Prefetching 139K Cache-Fehler in 19K und die Anweisungen pro Zyklus (IPC) werden mehr als verdoppelt. Der Massenvorteil wächst mit der Größe der Datensätze, von 1,2-mal in L2 bis 2,8-mal jenseits von L3, weil das Prefetching zunehmend teurere DRAM-Roundtrips verbirgt.

2. Bei ARM ändern sich Cache-Fehler kaum. Was sich ändert, ist die Auslastung: Backend-Verzögerungen sinken um 40 %, da das verschachtelte Zugriffsmuster die Pipeline füttert. Dieser Vorteil bleibt konstant bei 1,8-mal, unabhängig von der Größe der Datensätze, da die Parallelität auf Speicherebene gilt, unabhängig davon, ob Daten aus dem Cache oder dem DRAM stammen.

Zwei Architekturen, zwei Strategien, ein Ergebnis: Im Produktionsmaßstab beschäftigt simdvec die CPU-Pipeline durchgehend, selbst wenn die Vektoren über den Hauptspeicher verteilt sind.

Was das für Elasticsearch-Nutzer bedeutet

Diese Fähigkeiten auf Kernel-Ebene verstärken sich gegenseitig. Eine einzelne Vektorsuchabfrage kann Millionen von Distanzoperationen berechnen: HNSW-Graph-Durchläufe, Kandidatenbewertung, Neusortierung. Bei Tausenden gleichzeitiger Abfragen lassen sich Nanosekunden pro Operation direkt in Abfragelatenz und Cluster-Durchsatz umrechnen. Egal ob Sie float32, int8, bfloat16 oder BBQ verwenden, egal ob sich Ihr Index im Arbeitsspeicher oder auf der Festplatte befindet, simdvec ist die zugrunde liegende Engine, wobei jede dieser Operationen über dieselbe Engine läuft, die bis auf die letzte Nanosekunde genau abgestimmt ist.

Die wichtigste Erkenntnis ist, dass die Leistung der Vektorsuche im Produktionsmaßstab nicht primär durch den reinen SIMD-Durchsatz bestimmt wird. Entscheidend ist, wie effizient das System die Speicherlatenz verbirgt und gleichzeitig die Rechenleistung über Millionen kleiner Operationen hinweg aufrechterhält.

Die simdvec-Kernel werden mit fast jeder Elasticsearch-Version verbessert. Wenn neue Quantisierungstypen und Hardwareplattformen entstehen, erhalten sie von Anfang an optimierte Kernel. Und die bestehenden Typen werden immer schneller, während wir die bereits ausgelieferten Implementierungen optimieren.

Genau aus diesem Grund haben wir schreibgeschützte Dashboards entwickelt. Das ist die Kontrolle, die Sie sich gewünscht haben. Geben Sie Dashboards vertrauensvoll weiter, ohne befürchten zu müssen, dass die nächste Person mit Bearbeitungsrechten sie verändert oder zerstört.

Hinweis: Schreibgeschützte Berechtigungen sind in Elastic Cloud Serverless und ab Version 9.3 für Elastic Cloud Hosted und Elastic Self-Managed verfügbar.

Wenn die Option „Jeder kann bearbeiten“ Probleme bereitet

In Kibana hat das Teilen in der Regel Berechtigungen auf Space-Ebene bedeutet. Wenn jemand Dashboards in einem Bereich erstellen kann, kann er auch die Dashboards anderer Personen bearbeiten oder löschen. Das ist großartig für die Zusammenarbeit – bis es das nicht mehr ist. Eine einzige versehentliche Änderung kann zu Fehlentscheidungen, Vertrauensverlust und viel Aufräumarbeit führen.

Wir haben die Workarounds gehört: „Wir haben ‚read-only‘ in den Dashboard-Namen gesetzt und hoffen, dass die Leute es bemerken.“ Oder: „Wir markieren sie und drücken die Daumen.“ Hoffnung ist kein Genehmigungsmodell. Sie brauchten eine echte Möglichkeit, ein Dashboard zu sperren, ohne alle aus dem Bereich auszusperren.

Was tatsächlich schiefgeht

Deb und Kevin haben beide Bearbeitungszugriff auf das Log-Monitoring-Dashboard im Operationsbereich. Kevin nimmt einige Änderungen an den Charts vor. Als Deb zurückkommt, stimmen die Zahlen nicht mit den von ihr präsentierten überein. Sie muss herausfinden, was sich geändert hat (oft aus dem Gedächtnis), es beheben und sich fragen, wie viele Berichte mit falschen Daten verschickt wurden.

Schreibgeschützte Dashboards: Verantwortung und Kontrolle, die sinnvoll sind

Schreibgeschützte Dashboards lösen dieses Problem, indem sie Ihnen die Kontrolle darüber geben, ob andere Nutzer das Dashboard bearbeiten können. Wenn Sie ein Dashboard teilen, wählen Sie: Bearbeiten (Standard, wie heute) oder Ansehen. Im Ansichtsmodus können nur Sie (und die Kibana-Administratoren) es ändern oder löschen. Alle anderen können es öffnen, verwenden und darauf vertrauen, aber sie können es nicht verändern.

Was Sie erhalten

• Dashboard-Integrität: Im Ansichtsmodus können andere Nutzer mit Bearbeitungszugriff das Dashboard nicht ändern oder löschen. Wenn sie es versuchen, wird ihnen mitgeteilt, dass es gesperrt ist. Ihre Diagramme und Logik bleiben so, wie Sie sie verlassen haben.

• Sie behalten die Kontrolle: Sie sind der Besitzer. Sie können jederzeit bearbeiten, verfeinern und aktualisieren. Das Teilen als Nur-Ansicht sperrt Sie nicht aus; es fixiert die Version, die alle anderen sehen.

• Flexibler Lebenszyklus: Sie können ein Dashboard jederzeit wieder auf „bearbeitbar“ umschalten. Und Kibana-Administratoren können weiterhin alle Dashboards verwalten (zum Beispiel, wenn der Eigentümer ausscheidet). Keine Sackgassen.

Sie können finalisierte, missionskritische Dashboards weitreichend teilen und sicher sein, dass sie konsistent bleiben. Dies ist in allen Elastic-Stufen und -Angeboten verfügbar, einschließlich Serverless.

Wer kann was tun?

Schnelle Referenz nach Rolle:

• Dashboard-Besitzer: Sie haben es erstellt; Sie haben vollen Bearbeitungszugriff.

• Kibana-Administrator: Kann alle Dashboards verwalten.

• Nutzer mit Bearbeitungsrechten: Kann eigene Dashboards erstellen und bearbeiten; kann schreibgeschützte Dashboards weder bearbeiten noch löschen.

• Nutzer mit Ansichtsrechten: Kann nur Dashboards anzeigen (und auflisten).

Aktion

Dashboard-Inhaber

Kibana-Administrator

Nutzer mit Bearbeitungsrechten

Nutzer mit Space-Ansicht

Dashboards auflisten und anzeigen

✔

✔

✔

✔

Neue Dashboards erstellen

✔

✔

✔

✘

Bearbeitbare Dashboards ändern/löschen

✔

✔

✔

✘

Dashboards mit Lesezugriff ändern/löschen

✔

✔

✘

✘

So aktivieren Sie den Schreibschutz

Sie können den schreibgeschützten Modus beim Speichern eines neuen Dashboards oder später über das Freigabemenü festlegen.

Beim Speichern eines neuen Dashboards

• Erstellen Sie Ihr Dashboard, und klicken Sie auf Speichern.

• Suchen Sie im Modal „Als neues Dashboard speichern“ nach Berechtigungen.

• Ändern Sie diese von Kann bearbeiten in Kann ansehen.

• Klicken Sie auf Speichern. Das war's. Für alle anderen ist es schreibgeschützt.

Für ein Dashboard, das Sie bereits besitzen

• Dashboard öffnen.

• Öffnen Sie das Menü Dashboard teilen.

• Im Freigabemodal suchen Sie Berechtigungen und wechseln Sie zu Kann anzeigen. Die Änderung tritt sofort in Kraft; andere Nutzer im selben Bereich können sie nicht mehr bearbeiten oder löschen.

• Sie können mit der Maus über die Aktion Teilen fahren, um zu sehen, welche Art von Berechtigungen ein bestimmtes Dashboard hat.

Sehen, welche Dashboards gesperrt sind

In der Hauptliste der Dashboards haben Dashboards, die Sie nicht bearbeiten oder löschen können, ein deaktiviertes Auswahlkästchen. Dadurch lässt sich leicht erkennen, welche Inhalte nur zur Ansicht freigegeben sind.

Im Dashboard werden Sie außerdem feststellen, dass die Aktion „Bearbeiten“ deaktiviert ist und ein Tooltip erscheint, der erklärt, dass das Dashboard als schreibgeschützt eingestellt wurde.

Ausprobieren

Schreibgeschützte Dashboards sind jetzt verfügbar. Erstellen Sie ein Dashboard, setzen Sie es auf Ansehen und teilen Sie es. Ihr Team erhält eine einzige verlässliche Informationsquelle, und Sie erhalten Sicherheit. Kein „Bitte nicht bearbeiten“ mehr im Titel.

Wir würden gerne hören, wie Sie schreibgeschützte Dashboards verwenden. Teilen Sie Ihr Feedback in unserem Community-Forum mit.

In HNSW erfolgt die Suche durch das iterative Erweitern von Kandidatenknoten im Graphen, wobei eine begrenzte Menge der bisher entdeckten nächsten Nachbarn gepflegt wird. Jede Erweiterung hat Kosten zur Folge (Vektorabläufe, zufällige Suchaktionen zur Festplatte und mehr), wobei der marginale Vorteil dieser Kosten tendenziell abnimmt, je weiter die Suche voranschreitet.

Eine Möglichkeit, die Durchquerung von HNSW-Graphen zu optimieren, besteht darin, die Suche zu beenden, wenn die marginale Wahrscheinlichkeit, neue echte Nachbarn zu finden, nicht steigt. Aus diesem Grund haben wir in Elasticsearch 9.2 einen neuen Mechanismus zur vorzeitigen Beendigung eingeführt. Das stoppt den Suchvorgang, wenn der Besuch von Graphknoten nicht genug neue nächste Nachbarn für eine feste Anzahl hintereinander liefert.

In diesem Artikel erfahren Sie, wie wir den erwähnten Mechanismus zur vorzeitigen Beendigung in HNSW verbessert haben, damit er sich für verschiedene Datensätze und Datenverteilungen besser eignet.

Vorzeitige Beendigung in HNSW

In HNSW erfolgt die Suche durch das iterative Erweitern von Kandidatenknoten im Proximity-Graphen, wobei eine begrenzte Menge der bisher entdeckten nächsten Nachbarn gepflegt wird, bis entweder der gesamte Graph besucht wurde oder ein frühes Abbruchkriterium erfüllt ist.

Die vorzeitige Beendigung ist daher nicht unbedingt immer eine Optimierung, sondern Teil des Suchalgorithmus selbst. Der Moment, in dem wir beschließen aufzuhören, bestimmt das Gleichgewicht zwischen Effizienz und Abruf. In Elasticsearch gibt es bereits eine Reihe von Möglichkeiten, um Abfragen auf HNSW vorzeitig zu beenden:

• Eine festgelegte maximale Anzahl von Knoten wird besucht.

• Ein festgelegtes Zeitlimit ist erreicht.

Diese Regeln sind zwar einfach und vorhersehbar, verhalten sich aber weitgehend unabhängig von dem, was die Suche tatsächlich bewirkt. Außerdem werden sie hauptsächlich verwendet, um sicherzustellen, dass die Abfrage für den Endnutzer in angemessener Zeit abgeschlossen wird.

In einem früheren Blogbeitrag haben wir das Konzept der Redundanz im HNSW vorgestellt. Kurz gesagt, redundante Berechnungen treten auf, wenn HNSW weiterhin neue Kandidatenknoten auswertet, ohne dabei weitere nächste Nachbarn zu finden.

Geduld: Fortschritt statt Anstrengung messen

Der Begriff der Geduld stellt die frühe Beendigung auf Fortschritt statt Anstrengung um.

Anstatt zu fragen:

„Wie viele Schritte haben wir unternommen?“

Die neue Frage lautet:

„Wie viel Rechenleistung sind wir bereit zu verschwenden, bis wir die Hoffnung verlieren?“

Während der HNSW-Suche führt eine frühe Exploration in der Regel zu Spitzenverbesserungen der Gruppe der Top-k-Kandidaten. Während der ersten Schritte der HNSW-Graph-Exploration wird die Menge der Nachbarn kontinuierlich aktualisiert, da der Algorithmus immer nähere Nachbarn zum Abfragevektor entdeckt. Mit der Zeit werden diese Verbesserungen immer seltener, da die Suche konvergiert. Die auf Geduld basierende Beendigung überwacht dieses Muster und beendet die Suche, sobald die Verbesserungen für längere Zeit weniger werden.

In der Praxis berechnen wir beim Besuchen des HNSW-Graphen auch das Sättigungsverhältnis der Warteschlange, während wir Kandidatenknoten durchgehen. So wird der Prozentsatz der nächstgelegenen Nachbarn gemessen, die beim Besuch des letzten Graphknoten unverändert blieben (oder der Kehrwert der Anzahl der während der letzten Iteration eingeführten neuen Nachbarn). Wenn ein solches Verhältnis für zu viele aufeinanderfolgende Iterationen zu groß wird, hören wir auf, den Graphen zu besuchen.

Konzeptionell betrachtet Geduld die HNSW-Suche als einen Prozess mit abnehmendem Ertrag. Wenn sich die Erträge einpendeln, bringt die weitere Exploration des Graphen wenig Nutzen.

Dieses Framing ist wirkungsvoll, weil es die Beendigung direkt an beobachtbare Ergebnisse bindet, anstatt an willkürlich festgelegte Grenzwerte.

Der Vorteil dieser intelligenten Technik zur vorzeitigen Beendigung liegt darin, dass HNSW-Graph-Explorationen tendenziell eine geringere Anzahl von Graphknoten besuchen und dabei eine nahezu perfekte relative Abrufquote beibehalten.

Um dies zu visualisieren, können wir die Abrufquote pro besuchtem Knoten aufzeichnen, die wir mit der geduldsbasierten frühzeitigen Beendigung (gekennzeichnet als et=static) im Vergleich zum standardmäßigen HNSW-Verhalten (gekennzeichnet als et=no) bei einigen Datensätzen, FinancialQA und Quora, und Modellen, JinaV3 und E5-small, erhalten haben.

Statische Schwellenwerte und HNSW-Dynamik

In der Praxis wird dies in Elasticsearch mithilfe statischer Schwellenwerte umgesetzt. Ein Schwellenwert bezieht sich auf den Sättigungsschwellenwert, also das Sättigungsverhältnis, das wir für suboptimal halten. Der andere Schwellenwert bezieht sich auf die Anzahl aufeinanderfolgender Graphknoten, die wir zum Besuch zulassen, während wir dennoch eine suboptimale Warteschlangenauslastung erreichen, also der Geduldsschwellenwert.

Als wir diese Strategie zur vorzeitigen Beendigung in Elasticsearch 9.2 einführten, entschieden wir uns für konservative Standardeinstellungen, um den Abruf so weit wie möglich zu erhalten und gleichzeitig die Latenz und den Speicherverbrauch zu verbessern. Aus diesem Grund legten wir den Sättigungsschwellenwert auf 100 % und den Geduldsschwellenwert auf einen (begrenzten) Wert von 30 % des num_candidates in der KNN-Abfrage fest.

In vielen Szenarien erwiesen sich diese Einstellungen als gut geeignet, es kann aber sein, dass zwei Anfragen, die die gleiche Anzahl von Nachbarn anfordern, ein völlig unterschiedliches Konvergenzverhalten aufweisen. Einige Abfragen stoßen auf dichte lokale Nachbarschaften und sind schnell gesättigt, andere müssen lange, spärliche Pfade durchqueren, bevor sie wettbewerbsfähige Kandidaten finden. Letztgenanntes erwies sich als besonders schwierig effektiv zu handhaben.

Dabei fiel uns folgendes auf:

• Übermäßige Exploration bei einfachen Abfragen.

• Vorzeitige Beendigung bei schwierigen Abfragen.

Daher kamen wir zu dem Schluss, dass feste Schwellenwerte globale Annahmen über die Konvergenz kodieren, während wir HNSW besser an unterschiedliche Dynamiken anpassen könnten.

Die vorzeitige Beendigung von HNSW adaptiv gestalten

Ein adaptiver Ansatz zur vorzeitigen Beendigung geht dieses Problem aus einem anderen Blickwinkel an. Anstatt vordefinierte Stoppschwellenwerte durchzusetzen, leitet der Algorithmus aus den Suchdynamiken selbst ab, wann gestoppt werden soll.

Anstatt also das Verhältnis der Warteschlangensättigung zwischen zwei aufeinanderfolgenden Kandidaten zu vergleichen, beschlossen wir, sowohl eine direkt ausgeglichene (wie viele neue Nachbarn für eine Abfrage q beim letzten Besuch i eingeführt wurden) sowie den fortlaufenden Mittelwert und die Standardabweichung dieser Entdeckungsrate während des Graphbesuchs (unter Verwendung von Welfords Algorithmus) einzuführen. Diese Statistiken zur Entdeckungsrate werden pro Abfrage berechnet, sodass diese Informationen genutzt werden können, um für jede Abfrage unterschiedliche Geduldsgrade festzulegen.

Die zuvor statischen Schwellenwerte werden an die Statistik der Entdeckungsrate angepasst: Die Sättigungsschwelle wird zum gleitenden Mittelwert und mit der Standardabweichung addiert, während wir die Geduld anpassen und umgekehrt mit der Standardabweichung skalieren.

Die Regeln für die vorzeitige Beendigung bleiben gleich: Die Sättigung tritt ein, wenn die sofortige Entdeckungsrate niedriger ist als der adaptive Sättigungsgrenzwert. Der Graph-Besuch stoppt, wenn die Sättigung für eine Anzahl aufeinanderfolgender Kandidatenbesuche anhält, die größer ist als die adaptive Geduld.

So erhalten wir ein Verhalten, das nicht vom num_candidates-Parameter in der KNN-Abfrage abhängt (der immer als Standard gesetzt oder belassen werden kann, unabhängig von der vorzeitigen Beendigung) und sich dynamisch besser an jede Abfrage und Vektorverteilung anpasst.

Die Abrufquote pro besuchtem Knoten auf FinancialQA und Quora mit der adaptiven Strategie (gekennzeichnet als et=adaptive) ist höher als bei der statischen Strategie (et=static) und dem Standardverhalten von HNSW (et=no).

Die adaptive vorzeitige Beendigung ist in Elasticsearch 9.3 standardmäßig für HNSW-dichte Vektorfelder aktiviert (und kann schließlich über die gleiche Index-Level-Einstellung deaktiviert werden).

Bei der Optimierung von Elasticsearch für Workloads mit hoher Parallelität besteht der Standardansatz darin, den Arbeitsspeicher zu maximieren, um den Arbeitsdatensatz im Speicher zu halten und so eine geringe Suchlatenz zu erreichen. Daher wird best_compression selten für Such-Workloads berücksichtigt, da es in erster Linie als Speichereinsparungsmaßnahme für Elastic Observability und Elastic Security betrachtet wird, in denen Speichereffizienz Vorrang hat.

In diesem Blog zeigen wir, dass, wenn die Datensatzgröße den OS-Seitencache deutlich übersteigt, best_compression die Suchleistung und Ressourceneffizienz verbessert, indem der I/O-Engpass reduziert wird.

Das Setup

Unser Anwendungsfall ist eine Suchanwendung mit hoher Parallelität, die auf Elastic Cloud CPU-optimierten Instanzen ausgeführt wird.

• Datenvolumen: ~500 Millionen Dokumente

• Infrastruktur: 6 Elastic Cloud (Elasticsearch Service)-Instanzen (jede Instanz: 1,76 TB Speicher | 60 GB RAM | 31,9 vCPUs)

• Verhältnis von Arbeitsspeicher zu Speicher: Ungefähr 5 % des gesamten Datensatzes passen in den Arbeitsspeicher

Die Symptome: hohe Latenz

Wir haben beobachtet, dass sich die Suchlatenz deutlich verschlechterte, wenn die Anzahl der aktuellen Anfragen um 19:00 Uhr stark anstieg. Wie in Abbildung 1 und Abbildung 2 zu sehen ist, erreichte der Datenverkehr einen Spitzenwert von 400 Anfragen pro Minute und Elasticsearch-Instanz, während die durchschnittliche Abfragezeit auf über 60 ms sank.

Die CPU-Auslastung blieb nach der anfänglichen Verarbeitung der Verbindungen relativ niedrig, was darauf hindeutet, dass die Rechenleistung nicht der Engpass war.

Es zeigte sich eine starke Korrelation zwischen dem Abfragevolumen und den Seitenfehlern. Mit zunehmenden Anfragen beobachteten wir einen proportionalen Anstieg der Seitenfehler, mit einem Höchststand von etwa 400.000 pro Minute. Dies deutete darauf hin, dass der aktive Datensatz nicht in den Seitencache passte.

Gleichzeitig schien die Heap-Nutzung der JVM normal und unauffällig zu sein. Dies schloss Probleme mit der Garbage Collection aus und bestätigte, dass der Engpass I/O war.

Die Diagnose: I/O gebunden

Das System war I/O-gebunden. Elasticsearch nutzt den OS-Seitencache, um Indexdaten aus dem Speicher bereitzustellen. Wenn der Index zu groß für den Cache ist, lösen Abfragen kostspielige Festplatten-Lesevorgänge aus. Während die typische Lösung darin besteht, horizontal zu skalieren (Nodes/RAM hinzufügen), wollten wir zunächst alle Möglichkeiten zur Effizienzsteigerung unserer bestehenden Ressourcen ausschöpfen.

Die Lösung

Standardmäßig verwendet Elasticsearch LZ4-Kompression für seine Indexsegmente und findet so ein Gleichgewicht zwischen Geschwindigkeit und Größe. Wir stellten die Hypothese auf, dass ein Wechsel zu best_compression (das zstd verwendet) die Größe der Indizes verringern würde. Durch den geringeren Speicherbedarf kann ein größerer Prozentsatz des Index im Seitencache gespeichert werden, wodurch ein vernachlässigbarer Anstieg der CPU-Auslastung (für die Dekomprimierung) gegen eine Reduzierung der Festplatten-I/O eingetauscht wird.

Um best_compressionzu aktivieren, haben wir die Daten mit der Indexeinstellung index.codec: best_compressionneu indexiert. Alternativ könnte dasselbe Ergebnis erreicht werden, indem der Index geschlossen, der Indexcodec auf best_compressionzurückgesetzt und dann eine Segmentzusammenführung durchgeführt wird.

Die Ergebnisse

Die Ergebnisse bestätigten unsere Hypothese: Die verbesserte Speichereffizienz führte direkt zu einer erheblichen Steigerung der Suchleistung, ohne dass die CPU-Auslastung anstieg.

Durch die Anwendung von best_compression wurde die Indexgröße um etwa 25 % reduziert. Obwohl die Reduzierung geringer ausfiel als bei sich wiederholenden Log-Daten, erhöhte diese 25%ige Reduzierung effektiv unsere Seitencache-Kapazität um denselben Faktor.

Beim nächsten Auslastungstest (ab 17:00 Uhr) war der Traffic sogar noch höher und erreichte seinen Höhepunkt bei 500 Anfragen pro Minute pro Elasticsearch-Node.

Trotz der höheren Last war die CPU-Auslastung geringer als in der vorherigen Ausführung. Die erhöhte Nutzung im früheren Test war wahrscheinlich auf den Overhead durch übermäßige Seitenfehlerbehandlung und Festplatten-I/O-Verwaltung zurückzuführen.

Entscheidend ist, dass die Seitenfehler deutlich zurückgingen. Selbst bei höherem Durchsatz lagen die Fehler bei etwa <200.000 pro Minute, verglichen mit >300.000 im Basistest.

Obwohl die Seitenfehlerergebnisse immer noch nicht optimal waren, wurde die Abfragedienstzeit um etwa 50 % reduziert und lag selbst bei höherer Last unter 30 ms.

Fazit: best_compression zum Suchen

Für Such-Anwendungsfälle, in denen das Datenvolumen den verfügbaren physischen Speicher übersteigt, ist best_compression ein kraftvoller Hebel zur Leistungsoptimierung.

Die herkömmliche Lösung für Cache-Fehler besteht darin, den Arbeitsspeicher (RAM) zu skalieren. Allerdings haben wir durch die Reduzierung der Indexgröße das gleiche Ziel erreicht: Maximierung der Dokumentanzahl im Seiten-Cache. Unser nächster Schritt ist es, die Indexsortierung zu untersuchen, um den Speicher weiter zu optimieren und noch mehr Leistung aus unseren bestehenden Ressourcen herauszuholen.

Bei der Behebung dieses einen Problems werden jedoch versehentlich andere Abfragen beeinträchtigt, da nicht alle Fälle manuell getestet werden konnten. Aber wie können Sie oder Ihr QA-Team testen, ob eine Änderung in einer Abfrage Auswirkungen auf andere Abfragen hat? Noch wichtiger: Wie können Sie sicher sein, dass Ihre Änderungen eine Abfrage tatsächlich verbessert haben?

In Richtung einer systematischen Bewertung

Hier kommen Bewertungslisten ins Spiel. Anstatt bei jeder Änderung auf manuelle und subjektive Tests angewiesen zu sein, können Sie einen festen Satz von Abfragen festlegen, die für Ihren Anwendungsfall relevant sind, zusammen mit den entsprechenden Ergebnissen.

Dieser Satz wird zu Ihrer Referenzgrundlage. Bei jeder Änderung, die Sie vornehmen, nutzen Sie diese, um zu bewerten, ob sich Ihre Suche tatsächlich verbessert hat oder nicht.

Der Wert dieses Ansatzes liegt in Folgendem:

• Beseitigt Unsicherheit: Sie müssen sich nicht mehr fragen, ob Ihre Änderungen andere Anfragen beeinflussen; die Daten werden es Ihnen mitteilen.

• Stoppt das manuelle Testen: Sobald die Bewertungssätze aufgezeichnet sind, erfolgt der Test automatisch.

• Unterstützt Veränderungen: Sie können klare Metriken zeigen, die die Vorteile einer Veränderung untermauern.

So beginnen Sie mit dem Erstellen Ihrer Bewertungsliste

Eine der einfachsten Möglichkeiten ist die Auswahl einer repräsentativen Abfrage und die manuelle Auswahl der relevanten Dokumente. Zur Erstellung dieser Liste haben Sie zwei Möglichkeiten:

• Binäre Bewertungen: Jedes Dokument, das mit einer Suchanfrage verknüpft ist, erhält ein einfaches Tag: relevant (in der Regel mit einer Punktzahl von „1“) und nicht relevant („0“).

• Abgestufte Bewertungen: Hier erhält jedes Dokument eine Punktzahl mit unterschiedlichen Stufen. Beispiel: Festlegung einer Skala von 0 bis 4, ähnlich einer Likert-Skala, wobei 0 = „überhaupt nicht relevant” und 4 = „vollkommen relevant” bedeutet, mit Varianten wie „relevant”, „eher relevant” usw.

Binäre Urteile funktionieren gut, wenn die Suchintention klare Grenzen hat: Sollte dieses Dokument in den Ergebnissen enthalten sein oder nicht?

Abgestufte Bewertungen sind vor allem bei Grauzonen sinnvoll: Einige Ergebnisse sind besser als andere, sodass Sie „sehr gute“, „gute“ und „nutzlose“ Ergebnisse erhalten und Metriken verwenden können, die die Reihenfolge der Ergebnisse und das Feedback der Benutzer bewerten. Allerdings haben abgestufte Skalen auch Nachteile: Verschiedene Prüfer können die Bewertungsstufen unterschiedlich anwenden, was die Ergebnisse weniger konsistent macht. Und da bei abgestuften Metriken höhere Werte stärker gewichtet werden, kann selbst eine kleine Änderung (z. B. eine Bewertung von 3 statt 4) zu einer viel größeren Verschiebung der Metrik führen, als vom Prüfer beabsichtigt. Diese zusätzliche Subjektivität macht abgestufte Bewertungen im Laufe der Zeit unübersichtlicher und schwieriger zu verwalten.

Muss ich die Dokumente selbst klassifizieren?

Nicht unbedingt, da es verschiedene Möglichkeiten gibt, Ihre Bewertungsliste zu erstellen, jede mit ihren eigenen Vor- und Nachteilen:

• Explizite Bewertungen: Hier gehen SMEs jede Anfrage/jedes Dokument durch und entscheiden manuell, ob (oder inwieweit) sie relevant ist. Obwohl dies Qualität und Kontrolle bietet, ist die Skalierbarkeit geringer.

• Implizite Bewertungen: Mit dieser Methode leiten Sie die relevanten Dokumente auf der Grundlage des tatsächlichen Nutzerverhaltens wie Klicks, Abwanderungsraten und Käufe ab. Mit diesem Ansatz können Sie Daten automatisch erfassen, allerdings könnten die Ergebnisse verzerrt sein. Zum Beispiel klicken Nutzer häufiger auf Top-Ergebnisse, auch wenn sie nicht relevant sind.

• KI-generierte Bewertungen: Diese letzte Option verwendet Modelle (wie LLMs), um Anfragen und Dokumente automatisch zu bewerten, oft als LLM-Jurys bezeichnet. Sie lässt sich schnell und einfach skalieren, doch die Qualität der Daten hängt von der Qualität des verwendeten Modells und davon ab, wie gut die LLM-Trainingsdaten mit Ihren Geschäftsinteressen übereinstimmen. Wie bei menschlichen Bewertungen können auch LLM-Jurys ihre eigenen Vorurteile oder Inkonsistenzen einbringen. Daher ist es wichtig, ihre Ergebnisse anhand einer kleineren Gruppe vertrauenswürdiger Bewertungen zu validieren. LLM-Modelle sind von Natur aus probabilistisch, daher ist es nicht ungewöhnlich, dass ein LLM-Modell dem gleichen Ergebnis unterschiedliche Bewertungen zuweist, unabhängig davon, ob der Temperaturparameter auf 0 gesetzt wird.

Unten finden Sie einige Empfehlungen zur Auswahl der besten Methode für die Erstellung Ihres Bewertungssatzes:

• Entscheiden Sie, wie kritisch einige Features für Sie sind, die nur Nutzer richtig bewerten können (wie Preis, Marke, Sprache, Stil und Produktdetails). Wenn diese kritisch sind, benötigen Sie explizite Bewertungen für mindestens einen Teil Ihrer Bewertungsliste.

• Verwenden Sie implizite Bewertungen, wenn Ihre Suchmaschine bereits genügend Traffic hat, sodass Sie Metriken zu Klicks, Conversions und Verweildauer nutzen können, um Nutzungstrends zu erkennen. Sie sollten diese dennoch sorgfältig interpretieren und sie mit Ihren expliziten Bewertungssätzen vergleichen, um Verzerrungen zu vermeiden (z. B.: Nutzer neigen dazu, häufiger auf die Ergebnisse mit den höchsten Platzierungen zu klicken, auch wenn Ergebnisse mit niedrigeren Platzierungen relevanter sind)

Um dieses Problem zu beheben, werden mithilfe von Techniken zur Positionsentzerrung Klickdaten angepasst oder neu gewichtet, um das tatsächliche Interesse der Nutzer besser widerzuspiegeln. Mögliche Ansätze hierfür sind:

• Ergebnisse neu mischen: Ändern Sie die Reihenfolge der Suchergebnisse für eine Untergruppe von Nutzern, um zu schätzen, wie sich die Position auf die Klicks auswirkt.

• Zu den Click-Modellen gehörenDynamic Bayesian Network DBN, Nutzer Browsing Model UBM. Diese statistischen Modelle schätzen die Wahrscheinlichkeit, dass ein Klick echtes Interesse widerspiegelt und nicht nur die Position, indem sie Muster wie Scrollverhalten, Verweildauer, Klicksequenz und Rückkehr zur Ergebnisseite verwenden.

Beispiel: App zur Filmbewertung

Voraussetzungen

Um dieses Beispiel auszuführen, benötigen Sie einen laufenden Elasticsearch 8.x-Cluster, lokal oder Elastic Cloud Hosted (gehostet oder serverlos), sowie Zugriff auf die REST API oder Kibana.

Stellen Sie sich eine App vor, in der Nutzer ihre Meinungen zu Filmen hochladen und auch nach Filmen suchen können, die sie sich ansehen möchten. Da die Texte von den Nutzern selbst geschrieben werden, können sie Tippfehler und viele Ausdrucksvariationen aufweisen. Daher ist es unerlässlich, dass die Suchmaschine diese Vielfalt interpretieren und den Nutzern hilfreiche Ergebnisse liefern kann.

Um Abfragen wiederholen zu können, ohne das gesamte Suchverhalten zu beeinträchtigen, hat das Business-Team in Ihrem Unternehmen anhand der häufigsten Suchanfragen die folgenden binären Bewertungssätze erstellt:

Abfrage

DocID

Text

Leistung von DiCaprio

doc1

Die Leistung von DiCaprio in The Revenant war atemberaubend.

Leistung von DiCaprio

doc2

Inception zeigt Leonardo DiCaprio in einer seiner ikonischsten Rollen.

Leistung von DiCaprio

doc3

Brad Pitt liefert in diesem Krimi-Thriller eine solide Leistung ab.

Leistung von DiCaprio

doc4

Ein actiongeladenes Abenteuer mit atemberaubenden visuellen Effekten.

Traurige Filme, die einen zum Weinen bringen

doc5

Eine herzzerreißende Geschichte über Liebe und Verlust, bei der ich stundenlang geweint habe.

Traurige Filme, die einen zum Weinen bringen

doc6

Einer der traurigsten Filme, die je gedreht wurden – Taschentücher bereithalten!

Traurige Filme, die einen zum Weinen bringen

doc7

Eine unbeschwerte Komödie, die Sie zum Lachen bringen wird

Traurige Filme, die einen zum Weinen bringen

doc8

Ein Science-Fiction-Epos voller Action und Spannung.

Erstellung des Indexes:

BULK-Anfrage:

Nachfolgend finden Sie die Elasticsearch-Abfrage, die die App verwendet:

Von der Bewertung zu den Metriken

Für sich genommen liefern Bewertungslisten nicht viele Informationen; sie stellen lediglich eine Erwartung der Ergebnisse unserer Abfragen dar. Ihre wahre Stärke zeigen sie, wenn wir sie zur Berechnung objektiver Metriken zur Messung unserer Suchleistung verwenden.

Heutzutage umfassen die meisten gängigen Metriken Folgendes:

• Genauigkeit: Misst den Anteil der Ergebnisse, die innerhalb aller Suchergebnisse tatsächlich relevant sind.

• Recall: Misst den Anteil relevanter Ergebnisse, die die Suchmaschine unter den x Ergebnissen gefunden hat.

• Discounted Cumulative Gain (DCG):Misst die Qualität der Rangfolge der Ergebnisse, wobei die relevantesten Ergebnisse ganz oben stehen sollten.

• Mean Reziprocal Rank (MRR): Misst die Position des ersten relevanten Ergebnisses. Je höher es in der Liste steht, desto höher ist der Score.

Anhand derselben App zur Bewertung von Filmen berechnen wir die Recall-Metrik, um festzustellen, ob Informationen in unseren Abfragen ausgelassen werden.

In Elasticsearch können wir die Bewertungslisten nutzen, um Metriken über die Ranking Evaluation API zu berechnen. Diese API erhält als Eingabe die Bewertungsliste, die Abfrage und die zu bewertende Metrik und gibt einen Wert zurück, der einen Vergleich des Abfrageergebnisses mit der Bewertungsliste darstellt.

Lassen Sie uns die Ergebnisliste für die beiden vorliegenden Anfragen ausführen:

Wir verwenden zwei Anfragen an _rank_eval: eine für die DiCaprio-Abfrage und eine für traurige Filme. Jede Anfrage enthält eine Fragestellung und die dazugehörige Bewertungsliste (Bewertungen). Wir müssen nicht alle Dokumente bewerten, da diejenigen, die nicht in die Bewertung einbezogen werden, als unbewertet gelten. Für die Berechnungen berücksichtigt Recall nur den „relevanten Satz“, also die Dokumente, die für die Bewertung als relevant gelten.

In diesem Fall hat die DiCaprio-Abfrage einen Recall von 1, während die traurigen Filme einen Recall von 0 haben. Das bedeutet, dass wir bei der ersten Abfrage alle relevanten Ergebnisse erhalten haben, während wir bei der zweiten Abfrage keine Ergebnisse erhalten haben. Der durchschnittliche Recall beträgt daher 0,5.

Vielleicht sind wir mit dem Parameter minimum_should_match zu streng, da wir durch die Forderung, dass 100 % der Wörter in der Suchanfrage in den Dokumenten vorkommen müssen, wahrscheinlich relevante Ergebnisse auslassen. Entfernen wir den Parameter minimum_should_match, damit ein Dokument als relevant angesehen wird, wenn nur ein Wort aus der Suchanfrage darin vorkommt.

Wie Sie sehen können, erhalten wir durch Entfernen des Parameters minimum_should_match in einer der beiden Abfragen nun in beiden Fällen einen durchschnittlichen Recall von 1.

Zusammenfassend lässt sich sagen, dass durch das Entfernen der Klausel „minimum_should_match: 100%“ eine perfekte Trefferquote für beide Abfragen erzielt werden kann.

Wir haben es geschafft! Richtig?

Nicht so schnell!

Durch die Verbesserung des Recalls öffnen wir die Tür zu einer größeren Bandbreite an Ergebnissen. Jede Anpassung impliziert jedoch einen Kompromiss. Deshalb ist es wichtig, vollständige Testfälle festzulegen und verschiedene Metriken zur Bewertung von Änderungen zu verwenden.

Die Verwendung von Bewertungslisten und Metriken verhindert, dass Sie Änderungen blind vornehmen, da Sie nun über Daten verfügen, die diese stützen. Die Validierung erfolgt nicht mehr manuell und wiederholt, und Sie können Ihre Änderungen in mehr als nur einem Anwendungsfall testen. Darüber hinaus können Sie mit A/B-Tests live testen, welche Konfiguration für Ihre Nutzer und Ihren Anwendungsfall am besten geeignet ist, wodurch sich der Kreis von technischen Metriken und realen Metriken schließt.

Abschließende Empfehlungen zur Verwendung von Bewertungslisten

Bei der Arbeit mit Bewertungslisten geht es nicht nur um das Messen, sondern auch darum, einen Rahmen zu schaffen, der es Ihnen ermöglicht, mit Zuversicht zu iterieren. Zu diesem Zweck beachten Sie folgende Empfehlungen:

1. Fangen Sie klein an, aber fangen Sie an. Sie benötigen keine 10.000 Anfragen mit jeweils 50 Bewertungslisten. Sie müssen lediglich die 5 bis 10 wichtigsten Suchanfragen für Ihren Anwendungsfall identifizieren und festlegen, welche Dokumente Ihrer Meinung nach ganz oben in den Ergebnissen erscheinen sollten. Damit haben Sie bereits eine Grundlage. Sie möchten in der Regel mit den Top-Suchanfragen sowie den Suchanfragen ohne Ergebnisse beginnen. Sie können auch mit einer einfach zu konfigurierenden Metrik wie Genauigkeit beginnen und sich dann in der Komplexität steigern.

2. Validieren Sie mit Nutzern. Ergänzen Sie die Zahlen durch A/B-Tests in der Produktion. Auf diese Weise können Sie feststellen, ob Änderungen, die in den Metriken gut aussehen, auch tatsächlich Auswirkungen haben.

3. Führen Sie die Liste weiter. Ihr Anwendungsfall wird sich weiterentwickeln. Und damit auch Ihre kritischen Fragen. Aktualisieren Sie Ihre Bewertung regelmäßig, um neue Anforderungen zu berücksichtigen.

4. Integrieren Sie sie in Ihren Workflow. Integrieren Sie Bewertungslisten in Ihre Entwicklungs-Pipelines. Stellen Sie sicher, dass jede Konfigurationsänderung, jedes Synonym und jede Textanalyse automatisch mit Ihrer Basisliste abgeglichen wird.

5. Verbinden Sie technisches Wissen mit Strategie. Beschränken Sie sich nicht auf die Messung technischer Metriken wie Genauigkeit oder Recall. Nutzen Sie Ihre Bewertungsergebnisse, um die Geschäftsergebnisse zu verbessern.

Was ist rekursives Chunking?

Bei der rekursiven Segmentierung wird eine Liste von vorgegebenen Abschnittstrennungsmustern durchlaufen, um ein Dokument schrittweise in kleinere Segmente zu unterteilen, bis eine gewünschte maximale Segmentgröße erreicht ist.

Wie konfiguriere ich rekursives Chunking?

Folgende Werte können vom Benutzer für die rekursive Segmentierung konfiguriert werden:

• (erforderlich) max_chunk_size: Die maximale Anzahl von Wörtern in einem Chunk.

• Entweder eines von beiden:

  • separatorsEine Liste von regulären Ausdrücken, die verwendet werden, um das Dokument in Abschnitte zu unterteilen.

  • separator_groupEine Zeichenkette, die einer von Elastic definierten Standardliste von Trennzeichen zugeordnet wird, die für bestimmte Dokumenttypen verwendet werden. Aktuell sind markdown und plaintext verfügbar.

Wie funktioniert rekursives Chunking?

Der Prozess des rekursiven Chunkings bei gegebenem Eingabedokument, einem max_chunk_size (gemessen in Wörtern) und einer Liste von Trennzeichenketten verläuft wie folgt:

1. Wenn das Eingabedokument bereits innerhalb der maximalen Chunk-Größe liegt, wird ein einzelner Chunk zurückgegeben, der die gesamte Eingabe umfasst.

2. Teile den Text anhand des Vorkommens des Trennzeichens in mögliche Abschnitte auf. Für jeden potenziellen Teil:

   1. Wenn der potenzielle Datenblock innerhalb der maximalen Datenblockgröße liegt, fügen Sie ihn der Liste der an den Benutzer zurückzugebenden Datenblöcke hinzu.

   2. Andernfalls wiederholen Sie ab Schritt 2, wobei Sie nur den Text aus dem potenziellen Chunk verwenden und diesen anhand des nächsten Trennzeichens in der Liste aufteilen. Wenn keine weiteren Trennzeichen mehr übrig sind, sollte man auf satzbasierte Segmentierung zurückgreifen.

Beispiele für die Konfiguration von rekursivem Chunking

Abgesehen von der Chunk-Größe besteht die wichtigste Konfiguration für rekursives Chunking in der Auswahl der Trennzeichen, die zum Aufteilen der Dokumente verwendet werden sollen. Wenn Sie nicht sicher sind, wo Sie anfangen sollen, bietet Elasticsearch einige Standardtrennzeichengruppen an, die für gängige Anwendungsfälle verwendet werden können.

Verwendung von Trenngruppen

Um eine Trenngruppe zu verwenden, geben Sie einfach den Namen der Gruppe an, die Sie bei der Konfiguration der Chunking-Einstellungen verwenden möchten. Zum Beispiel:

Dies führt zu einer rekursiven Chunking-Strategie, die die Trennzeichenliste ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")] verwendet. Dies funktioniert gut für allgemeine Klartextanwendungen, wobei der Text an zwei Zeilenumbruchzeichen, gefolgt von einem weiteren Zeilenumbruchzeichen, geteilt wird.

Wir bieten außerdem eine Trennzeichengruppe markdown an, die die Trennzeichenliste verwendet:

Diese Trennzeichenliste eignet sich gut für allgemeine Markdown-Anwendungsfälle, da sie an jeder der 6 Überschriftenebenen und den Abschnittsumbruchzeichen aufteilt.

Beim Erstellen einer Ressource (Inferenzendpunkt/semantisches Textfeld) wird die Liste der Trennzeichen, die der Trennzeichengruppe zu diesem Zeitpunkt entsprechen, in Ihren Konfigurationen gespeichert. Wenn die Trenngruppe zu einem späteren Zeitpunkt aktualisiert wird, ändert sich dadurch das Verhalten Ihrer bereits erstellten Ressourcen nicht.

Verwendung einer benutzerdefinierten Trennliste

Falls eine der vordefinierten Trennzeichengruppen für Ihren Anwendungsfall nicht geeignet ist, können Sie eine benutzerdefinierte Liste von Trennzeichen definieren, die Ihren Anforderungen entspricht. Beachten Sie, dass reguläre Ausdrücke innerhalb der Trennzeichenliste angegeben werden können. Nachfolgend ein Beispiel für Chunking-Einstellungen mit benutzerdefinierten Trennzeichen:

Die oben beschriebene Chunking-Strategie teilt an zwei Zeilenumbruchzeichen, gefolgt von einem Zeilenumbruchzeichen und schließlich an der Zeichenkette “<my-custom-separator>” auf.

Ein Beispiel für rekursives Chunking in der Praxis

Schauen wir uns ein Beispiel für rekursives Chunking in der Praxis an. In diesem Beispiel verwenden wir die folgenden Chunking-Einstellungen mit einer benutzerdefinierten Liste von Trennzeichen, die ein Markdown-Dokument anhand der beiden obersten Header-Ebenen aufteilen:

Werfen wir einen Blick auf ein einfaches, unstrukturiertes Markdown-Dokument:

Nun verwenden wir die oben definierten Chunking-Einstellungen, um das Dokument in Chunking-Elemente zu unterteilen:

Hinweis: Der Zeilenumbruch am Ende jedes Abschnitts (außer Abschnitt 3) ist nicht hervorgehoben, befindet sich aber innerhalb der eigentlichen Abschnittsgrenzen.

Legen Sie noch heute mit rekursivem Chunking los!

Weitere Informationen zur Nutzung dieser Funktion finden Sie in der Dokumentation zur Konfiguration der Chunking-Einstellungen.

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!

Stellen Sie sich einen Finanzmanager vor, der sich vor einem Kundengespräch schnell einarbeiten muss. Statt manuell Newsfeeds zu durchforsten und Portfolio-Dashboards abzugleichen, können sie ihrem individuell entwickelten Agenten jetzt einfach eine direkte Frage stellen. Das ist der Vorteil eines „Chat-First“-Ansatzes. Der Manager hat einen direkten, dialogorientierten Draht zu seinen Daten und fragt beispielsweise: „Was gibt es Neues zu ACME Corp und wie wirkt sich das auf die Anlagen meines Kunden aus?“ und innerhalb von Sekunden eine zusammengefasste Expertenantwort zu erhalten.

Während wir heute einen Finanzexperten aufbauen, sind die Anwendungsbereiche so vielfältig wie Ihre Daten. Mit der gleichen Macht kann ein Cybersicherheitsanalyst zur Suche nach Bedrohungen, ein Site Reliability Engineer zur Diagnose eines Ausfalls oder ein Marketingmanager zur Optimierung einer Kampagne geschaffen werden. Unabhängig vom Fachgebiet bleibt die Kernmission dieselbe: Ihre Daten in einen Spezialisten zu verwandeln, mit dem Sie sich unterhalten können.

Schritt 0: Unser Datensatz

Unser heutiger Datensatz ist ein synthetischer, auf Finanzdaten basierender Datensatz, der aus Finanzkonten, Vermögenspositionen, Nachrichten und Finanzberichten besteht. Er ist zwar synthetisch, repliziert aber eine vereinfachte Version eines realen Finanzdatensatzes.

financial_accountsKundenportfolios mit Risikoprofilen

financial_holdings: Aktien-/ETF-/Anleihenpositionen mit Kaufhistorie

financial_asset_detailsDetails zur Aktie/zum ETF/zur Anleihe

financial_news: KI-generierte Marktartikel mit Stimmungsanalyse

financial_reportsUnternehmensgewinne und Analystennotizen

Sie können diesen Datensatz selbst laden, indem Sie der beigefügten Anleitung in diesem Notebook folgen.

Schritt 1: Die Grundlage – Ihre Geschäftslogik als ES|QL

Jede KI-Fähigkeit beginnt mit einer soliden Logik. Unserem Financial Manager-Agenten müssen wir beibringen, wie er eine häufig gestellte Frage beantworten kann: „Ich bin besorgt über die Marktstimmung.“ Können Sie mir zeigen, welche unserer Kunden am stärksten von schlechten Nachrichten bedroht sind? Diese Frage geht über eine einfache Suche hinaus. Dies erfordert von uns, die Marktstimmung mit den Kundenportfolios in Zusammenhang zu bringen.

Wir müssen die in den negativen Artikeln erwähnten Vermögenswerte finden, jeden Kunden identifizieren, der diese Vermögenswerte hält, den aktuellen Marktwert seines Engagements berechnen und dann die Ergebnisse nach dem höchsten Risiko ordnen. Diese komplexe Analyse mit mehreren Verknüpfungen ist die perfekte Aufgabe für unser hochentwickeltes ES|QL-Tool.

Hier ist die vollständige Abfrage, die wir verwenden werden. Es sieht beeindruckend aus, aber die Konzepte sind einfach.

Aufschlüsselung: Verbindungen und Leitplanken

Bei dieser Abfrage spielen zwei wichtige Konzepte eine Rolle, die den Agent Builder ausmachen.

1. Die LOOKUP JOIN-Funktion

Seit Jahren gehört die Möglichkeit, Daten aus verschiedenen Indizes anhand eines gemeinsamen Schlüssels zu verknüpfen, zu den am häufigsten nachgefragten Funktionen von Elasticsearch. Mit ES|QL ist das jetzt mit LOOKUP JOIN möglich.

In unserer neuen Abfrage führen wir eine Kette von drei LOOKUP JOIN durch: Zuerst verbinden wir negative Nachrichten mit Vermögensdetails, dann verknüpfen wir diese Vermögenswerte mit den Kundenbeständen und schließlich fügen wir sie zu den Kontoinformationen des Kunden hinzu. Dadurch wird mit einer einzigen, effizienten Abfrage ein unglaublich reichhaltiges Ergebnis aus vier verschiedenen Indizes erzeugt. Das bedeutet, dass wir unterschiedliche Datensätze kombinieren können, um eine einzige, aussagekräftige Antwort zu erhalten, ohne vorher alle unsere Daten in einen einzigen riesigen Index denormalisieren zu müssen.

2. Parameter als LLM-Leitplanken

Sie werden feststellen, dass die Abfrage ?time_duration verwendet. Das ist nicht nur eine Variable; es ist eine Leitplanke für die KI. Während große Sprachmodelle (LLMs) hervorragend darin sind, Abfragen zu generieren, kann es zu ineffizienten oder sogar falschen Abfragen führen, wenn man ihnen freie Hand bei der Daten lässt.

Durch die Erstellung einer parametrisierten Abfrage zwingen wir das LLM dazu, innerhalb der getesteten, effizienten und korrekten Geschäftslogik zu arbeiten, die ein menschlicher Experte bereits definiert hat. Das ist vergleichbar damit, wie Entwickler seit Jahren Suchvorlagen verwenden, um Abfragefunktionen sicher für Anwendungen bereitzustellen. Der Agent kann eine Benutzeranfrage wie "diese Woche" interpretieren, um den Parameter time_duration zu füllen, muss aber unsere Abfragestruktur verwenden, um die Antwort zu erhalten. Dadurch erhalten wir die perfekte Balance zwischen Flexibilität und Kontrolle.

Letztendlich ermöglicht diese Abfrage einem Experten, der die Daten versteht, sein Wissen in einem Werkzeug zu kapseln. Andere Personen – und KI-Agenten – können dieses Werkzeug dann nutzen, um korrelierte Ergebnisse zu erhalten, indem sie einfach einen einzigen Parameter angeben, ohne etwas über die zugrunde liegende Komplexität wissen zu müssen.

Schritt 2: Die Fertigkeit – Eine Abfrage in ein wiederverwendbares Werkzeug umwandeln

Eine ES|QL-Abfrage ist nur Text, bis wir sie als Werkzeug registrieren. Im Agent Builder ist ein Tool mehr als nur eine gespeicherte Abfrage; es ist eine „Fähigkeit“, die ein KI-Agent verstehen und einsetzen kann. Der Zauber liegt in der von uns bereitgestellten Beschreibung in natürlicher Sprache . Diese Beschreibung bildet die Brücke zwischen der Frage eines Benutzers und der zugrunde liegenden Abfragelogik. Registrieren wir nun die soeben erstellte Abfrage.

Der UI-Pfad

Das Erstellen eines Tools in Kibana ist ein unkomplizierter Prozess.

1. Navigieren Sie zu Agenten

• Klicken Sie auf „Tools“oder „Tools verwalten“ und klicken Sie dann auf die Schaltfläche „Neues Tool“ .

2. Füllen Sie das Formular mit folgenden Angaben aus:

• Werkzeug-ID: find_client_exposure_to_negative_news

ich. Dies ist die eindeutige ID des Tools.

• Beschreibung: "Ermittelt das Risiko negativer Nachrichten im Kundenportfolio." Dieses Tool durchsucht aktuelle Nachrichten und Berichte nach negativen Stimmungen, identifiziert den zugehörigen Vermögenswert und findet alle Kunden, die diesen Vermögenswert halten. Es liefert eine nach dem aktuellen Marktwert der Position sortierte Liste zurück, um das höchste potenzielle Risiko hervorzuheben.“

ich. Dies ist das, was der LLM liest, um zu entscheiden, ob dieses Werkzeug das richtige für die Aufgabe ist.

• Labels: retrieval and risk-analysis

Etiketten dienen dazu, mehrere Werkzeuge zu gruppieren.

• Konfiguration: Fügen Sie die vollständige ES|QL-Abfrage aus Schritt 1 ein.

ich. Dies ist die Suche, die der Agent verwenden wird.

3. Klicken Sie auf „Parameter aus Abfrage ableiten“. Die Benutzeroberfläche wird ?time_duration automatisch finden und unten auflisten. Fügen Sie für jedes Element eine kurze Beschreibung hinzu, damit der Agent (und andere Benutzer) dessen Zweck verstehen können.

• time_durationDer Zeitraum, in dem nach negativen Nachrichten gesucht wird. Format ist "X Stunden", Standardwert: 8760 Stunden

4. Probier es aus!

• Klicken Sie auf Speichern & Testen.

• Es wird ein neues Flyout angezeigt, in dem Sie die Abfrage testen können, um sicherzustellen, dass sie wie erwartet funktioniert.

ich. Geben Sie in time_duration den gewünschten Bereich ein, hier verwenden wir „8760 Stunden“.

• Klicken Sie auf „Absenden“, und wenn alles gut geht, erhalten Sie eine JSON-Antwort. Um sicherzustellen, dass es wie erwartet funktioniert, scrollen Sie nach unten und sehen Sie sich das Objekt values an. Dort werden die eigentlichen übereinstimmenden Dokumente zurückgegeben.

5. Klicken Sie auf das „X“ oben rechts, um das Testfenster zu schließen. Ihr neues Tool wird nun in der Liste angezeigt und kann einem Agenten zugewiesen werden.

Der API-Pfad

Für Entwickler, die Automatisierung bevorzugen oder Tools programmatisch verwalten müssen, lässt sich dasselbe Ergebnis mit einem einzigen API-Aufruf erzielen. Senden Sie einfach eine POST -Anfrage an den /api/agent_builder/tools -Endpunkt mit der Definition des Tools.

Schritt 3: Das Gehirn – Ihren individuellen Agenten erstellen

Wir haben eine wiederverwendbare Fähigkeit entwickelt (das Tool). Nun müssen wir den Agenten erstellen, die Persona, die es tatsächlich benutzen wird. Ein Agent ist die Kombination aus einem LLM, einem bestimmten Satz von Werkzeugen, zu denen Sie ihm Zugriff gewähren, und vor allem einer Reihe von benutzerdefinierten Anweisungen , die als seine Verfassung fungieren und seine Persönlichkeit, Regeln und seinen Zweck definieren.

Die Kunst des Prompts

Der wichtigste Aspekt bei der Schaffung eines zuverlässigen, spezialisierten Agenten ist die Pünktlichkeit. Eine gut ausgearbeitete Anleitung macht den Unterschied zwischen einem generischen Chatbot und einem zielgerichteten, professionellen Assistenten aus. Hier legen Sie die Leitplanken fest, definieren die Ausgabe und geben dem Agenten seine Mission.

Für unseren Financial Manager -Agenten verwenden wir die folgende Eingabeaufforderung.

Lassen Sie uns genauer betrachten, warum diese Aufforderung so effektiv ist:

• Es definiert eine anspruchsvolle Persönlichkeit: Schon die erste Zeile stellt den Agenten als „spezialisierten Data Intelligence Assistant“ dar und vermittelt so einen professionellen und kompetenten Eindruck.

• Es bietet einen Denkrahmen: Indem wir dem Agenten sagen, er solle "Verstehen, Planen, Ausführen und Synthetisieren", geben wir ihm eine Standardarbeitsanweisung. Dadurch wird seine Fähigkeit verbessert, komplexe, mehrstufige Fragen zu beantworten.

• Es fördert den interaktiven Dialog: Die Anweisung, „klärende Fragen zu stellen“, macht den Agenten widerstandsfähiger. Dadurch werden Fehlinterpretationen bei mehrdeutigen Anfragen minimiert, was zu genaueren Antworten führt.

Der UI-Pfad

1. Navigieren Sie zu Agenten.

• Klicken Sie auf „Tools“oder „Tools verwalten“ und klicken Sie dann auf die Schaltfläche „Neues Tool“ .

2. Füllen Sie die grundlegenden Angaben aus:

• Agenten-ID: financial_assistant.

• Anleitung: Kopieren Sie die obige Eingabeaufforderung.

• Labels: Finance.

• Anzeigename: Financial Assistant.

• Anzeigebeschreibung: An assistant for analyzing and understanding your financial data.

3. Klicken Sie oben auf „Tools“.

• Setzen Sie ein Häkchen neben unserem find_client_exposure_to_negative_news -Tool.

4. Klicken Sie auf Speichern.

Der API-Pfad

Sie können denselben Agenten mit einer POST -Anfrage an den /api/agent_builder/agents -Endpunkt erstellen. Der Anfragetext enthält dieselben Informationen: die ID, den Namen, die Beschreibung, die vollständigen Anweisungen und eine Liste der Tools, die der Agent verwenden darf.

Schritt 4: Der Lohn – Ein Gespräch führen

Unsere Geschäftslogik ist in einem Tool gekapselt und ein "Gehirn" ist bereit, es in unserem Agenten zu verwenden. Jetzt wird es Zeit, dass alles zusammenkommt. Wir können nun mithilfe eines spezialisierten Agenten mit unseren Daten kommunizieren.

Der UI-Pfad

1. Navigieren Sie in Kibana zu „Agenten“ .

2. Wechseln Sie mithilfe des Dropdown-Menüs unten rechts im Chatfenster vom standardmäßigen Elastic AI Agent zu unserem neu erstellten Financial Assistant Agent.

3. Stellen Sie eine Frage, die es dem Agenten ermöglicht, unser Spezialtool zu nutzen:

   1. Ich bin besorgt über die Marktstimmung. Können Sie mir zeigen, welche unserer Kunden am stärksten von schlechten Nachrichten betroffen sein könnten?

Nach kurzer Zeit liefert der Agent eine perfekt formatierte, vollständige Antwort. Aufgrund der Beschaffenheit von LLMs kann Ihre Antwort etwas anders formatiert sein, aber für diesen Durchlauf hat der Agent Folgendes zurückgegeben:

Was ist gerade passiert? Die Argumentation des Agenten

Der Agent kannte die Antwort nicht einfach nur. Es wurde ein mehrstufiger Plan umgesetzt, dessen Mittelpunkt die Auswahl des besten Werkzeugs für die jeweilige Aufgabe bildete. Hier ein Einblick in den Denkprozess:

• Identifizierte Absicht: Es wurden Schlüsselwörter aus Ihrer Frage, wie „Risiko“ und „negative Nachrichten“, mit der Beschreibung des find_client_exposure_to_negative_news -Tools abgeglichen.

• Plan ausgeführt: Es hat den Zeitrahmen aus Ihrer Anfrage extrahiert und einen einzigen Aufruf an dieses spezialisierte Tool durchgeführt.

• Die Arbeit wurde delegiert: Das Tool übernahm dann die gesamte schwere Arbeit: die verketteten Joins, die Wertberechnungen und die Sortierung.

• Ergebnis zusammengefasst: Abschließend formatierte der Agent die Rohdaten des Tools gemäß den Vorgaben in eine klare, für Menschen lesbare Zusammenfassung.

Und wir müssen nicht nur raten, wenn wir unser Denken erweitern und mehr Details betrachten.

Der API-Pfad

Sie können diese Konversation auch programmatisch starten. Senden Sie einfach die Eingabefrage an den converse API-Endpunkt und achten Sie darauf, die agent_id unseres financial_manager anzugeben.

Für Entwickler: Integration mit der API

Während die Kibana-Benutzeroberfläche ein fantastisches und intuitives Erlebnis beim Erstellen und Verwalten Ihrer Agenten bietet, kann alles, was Sie heute gesehen haben, auch programmatisch erreicht werden. Der Agent Builder basiert auf einer Reihe von APIs, die es Ihnen ermöglichen, diese Funktionalität direkt in Ihre eigenen Anwendungen, CI/CD-Pipelines oder Automatisierungsskripte zu integrieren.

Die drei wichtigsten Endpunkte, mit denen Sie arbeiten werden, sind:

• /api/agent_builder/tools: Der Endpunkt zum Erstellen, Auflisten und Verwalten der wiederverwendbaren Fähigkeiten, die Ihre Agenten nutzen können.

• /api/agent_builder/agentsDer Endpunkt zur Definition Ihrer Agenten-Personas, einschließlich ihrer wichtigen Anweisungen und Tool-Zuweisungen.

• /api/agent_builder/converse: Der Endpunkt für die Interaktion mit Ihren Agenten, den Start von Gesprächen und das Erhalten von Antworten.

Eine vollständige, praktische Anleitung zur Verwendung dieser APIs für jeden Schritt dieses Tutorials finden Sie im zugehörigen Jupyter Notebook , das hier in unserem GitHub-Repository verfügbar ist.

Fazit: Jetzt sind Sie am Bauen

Wir begannen damit, eine ES|QL-Abfrage zu nehmen und sie in eine wiederverwendbare Fähigkeit umzuwandeln. Anschließend entwickelten wir einen spezialisierten KI-Agenten, gaben ihm eine klare Mission und klare Regeln und statteten ihn mit diesen Fähigkeiten aus. Das Ergebnis ist ein hochentwickelter Assistent, der eine komplexe Frage verstehen und eine mehrstufige Analyse durchführen kann, um eine präzise, datengestützte Antwort zu liefern.

Dieser Workflow ist das Herzstück des neuen Agent Builders in Elastic. Es ist so konzipiert, dass es einfach genug ist, damit auch technisch nicht versierte Benutzer Agenten über die Benutzeroberfläche erstellen können, gleichzeitig aber differenziert genug, damit Entwickler auf Basis unserer APIs maßgeschneiderte KI-gestützte Anwendungen entwickeln können. Am wichtigsten ist jedoch, dass Sie LLMs sicher und geschützt mit Ihren eigenen Daten verbinden können, die von der von Ihnen definierten Expertenlogik gesteuert werden, und mit Ihren Daten kommunizieren können.

Sind Sie bereit, Agenten für die Kommunikation mit Ihren Daten einzusetzen?

Am besten festigt man das Gelernte, indem man selbst Hand anlegt. Probieren Sie alles, was wir heute besprochen haben, in unserem kostenlosen, interaktiven Praxisworkshop aus. Sie werden diesen gesamten Ablauf und mehr in einer speziellen Sandbox-Umgebung durchlaufen.

In einem zukünftigen Blogbeitrag zeigen wir Ihnen, wie Sie eine eigenständige Anwendung verwenden, die mit unserem Financial Assistant -Agenten interagiert, und gehen näher auf das Model Context Protocol (MCP) ein, das dies alles ermöglicht. In einem separaten Blogbeitrag werden wir die Unterstützung des Agent Builders für das sich entwickelnde Agent2Agent- oder A2A-Protokoll besprechen.

Bleibt dran und viel Spaß beim Bauen!

Agent Builder: Eine Grundlage für die Entwicklung datengesteuerter KI-Agenten

Das Versprechen eines KI-Agenten ist einfach: Man gibt ihm ein Ziel, und er erledigt die Aufgabe. Für Entwickler sieht die Realität jedoch anders aus: Sie steht vor einer Reihe komplexer Herausforderungen. Erstens ist ein Agent nur so gut wie seine Wahrnehmung seiner Umgebung und der ihm zur Verfügung stehenden Werkzeuge, um die Ziele des Benutzers zu erreichen. Dann stellt es eine enorme Herausforderung dar, aus einer Flut von unterschiedlichen Unternehmensdaten den richtigen Kontext herauszufiltern. Schließlich muss all dies von einer zuverlässigen Denkschleife orchestriert werden, die planen, ausführen und lernen kann.

Um dieses Problem zu lösen, müssen die Entwickler einen komplexen und fehleranfälligen Stack von Grund auf neu aufbauen. Die heutige Agentenarchitektur erfordert das Zusammenfügen mehrerer, voneinander unabhängiger Komponenten: ein LLM, eine Vektordatenbank, ein Metadatenspeicher, separate Systeme für Protokollierung und Tracing sowie eine Möglichkeit zur Überprüfung, ob das Ganze überhaupt funktioniert. Das ist nicht nur komplex, sondern auch kostspielig, fehleranfällig und erschwert den Aufbau der hochwertigen, vertrauenswürdigen KI-Systeme, die Ihre Nutzer fordern.

Wir wollen es also vereinfachen. Unser Ansatz hierfür besteht darin, die wesentlichen Bestandteile eines effektiven kontextgesteuerten Agenten zu nehmen und sie mit einer neuen Reihe von Funktionen namens Elastic AI Agent Builder direkt in den Kern von Elasticsearch zu integrieren. Diese neue Schicht bietet ein Framework mit allen wesentlichen Bausteinen für die Erstellung von KI-Agenten auf Basis von Elasticsearch: ein offenes Set an Primitiven, standardbasierte Protokolle und sicherer Datenzugriff – damit Sie agentenbasierte Systeme entwickeln können, die auf reale Daten und Anforderungen zugeschnitten sind:

KI-Erlebnisse bereitstellen: Das ist das ultimative Ziel. Mit unserer Search AI Platform und Ihren Daten als Grundlage können Sie jede Art von generativer KI-Anwendung erstellen: von benutzerdefinierten Chat-Oberflächen bis hin zu Integrationen mit agentenbasierten Frameworks wie LangChain oder Geschäftsanwendungen wie Salesforce.

Unterstützt von Agenten und Tools: Auf der Plattform selbst stellen wir eine saubere, einfache Abstraktionsschicht bereit. Sie interagieren direkt mit Agenten und Tools, die Sie an Ihre spezifischen Bedürfnisse anpassen können. Sie können die Funktionen der Plattform auch über robuste APIs und offene Standards wie MCP und A2A nutzen.

Ermöglicht durch die Search AI Platform: Dies ist die Kern-Engine, in die wir die Komponenten integriert haben. Die hochentwickelte Vektordatenbank, die Agentenlogik, die Abfragekonstruktion, Sicherheitsfunktionen, das Tracing zur Auswertung – all das befindet sich hier und wird von Elastic verwaltet und optimiert.

Das Potenzial Ihrer Daten freisetzen: Die Grundlage jedes erfolgreichen Agenten sind hervorragende Daten. Unsere Plattform beginnt mit der Fähigkeit, den Zugriff auf alle Ihre Unternehmensdaten zu erfassen oder zu föderieren.

Agentenaufbau in der Plattform

Der in die Search AI Platform integrierte Agent Builder bietet ein komplettes Framework für die Agentenentwicklung. Es basiert auf fünf zentralen Säulen, von denen jede einen kritischen Aspekt beim Aufbau und Einsatz produktionsreifer KI-Systeme adressiert. Lassen Sie uns aufschlüsseln, wie Agenten das Ziel definieren, Tools die Fähigkeiten bereitstellen, offene Standards Interoperabilität gewährleisten, Evaluierung Transparenz schafft und Sicherheit das Vertrauen schafft.

Agenten

Agenten sind die obersten Bausteine dieser neuen Ebene von Elasticsearch. Ein Agent definiert das zu erreichende Ziel, die zur Ausführung verfügbaren Werkzeuge und die Datenquellen, mit denen er arbeiten kann. Agenten sind nicht auf dialogbasierte Interaktionen beschränkt; sie können komplette Arbeitsabläufe, Aufgabenautomatisierung oder benutzerorientierte Erlebnisse ermöglichen.

Wenn eine Anfrage an einen Agenten gerichtet wird, durchläuft sie einen strukturierten Zyklus:

1. Interpretieren Sie Ihre Eingabe und Ihr Ziel.

2. Wählen Sie das richtige Werkzeug und die richtigen Argumente für die Ausführung aus.

3. Begründen Sie die Antwort des Tools.

4. Entscheiden Sie, ob ein Ergebnis zurückgegeben oder mit weiteren Toolaufrufen fortgefahren werden soll.

Elastic übernimmt die Orchestrierung, den Kontext und die Ausführung dieses Zyklus. Die Entwickler konzentrieren sich darauf, festzulegen, was der Agent tun soll: Ziele, Werkzeuge und Daten, während das System die Durchführung der Schlussfolgerungen und Arbeitsabläufe steuert.

Der Standardagent

Unser erster Agent, der auf dieser Plattform basiert, ist ein nativer Dialogagent in Kibana, der Ihnen die Möglichkeit gibt, sofort mit Ihren Daten zu interagieren. Es bietet eine sofort einsatzbereite Benutzererfahrung und bleibt gleichzeitig vollständig erweiterbar, sodass Sie ohne zusätzliche Konfiguration sofort mit Ihren Daten interagieren können.

Sie können mit dieser Funktion direkt in Kibana über eine neue Chat-Benutzeroberfläche oder über eine API interagieren.

Die Abfrage des Standardagenten über die API erfordert nur einen einzigen Aufruf:

Da Konversationen zustandsbehaftet sind, können Sie die Interaktion mit einem Agenten mithilfe einer conversation_id fortsetzen oder den vollständigen Konversationsverlauf abrufen:

Zollagenten

Entwickler können über einfache APIs auch ihre eigenen benutzerdefinierten Agenten erstellen. Agenten kapseln Anweisungen, Werkzeuge und Datenzugriff und erstellen so maßgeschneiderte Schlussfolgerungsmaschinen.

Die Erstellung eines benutzerdefinierten Agenten ist so einfach wie ein einziger API-Aufruf. Das folgende Beispiel zeigt, dass das Feld „Konfiguration“ alle wichtigen Details enthält, wie z. B. Anweisungen oder verfügbare Tools:

Sobald der Agent erstellt ist, kann er direkt abgefragt werden:

Dieser Ansatz wandelt den Agenten von einem komplexen, von Grund auf neu zu entwickelnden System in eine einfache, deklarative Einheit der Geschäftslogik um, wodurch Sie intelligente Automatisierung schneller realisieren können.

Eine detaillierte Anleitung zum Erstellen eines spezialisierten Agenten von Grund auf finden Sie in unserem ausführlichen Schritt-für-Schritt-Leitfaden: Ihr erster elastischer Agent: Von einer einzelnen Abfrage zu einem KI-gestützten Chat.

Tools

Wenn Agenten definieren, was erreicht werden soll, definieren Werkzeuge, wie.

Die Tools stellen Agenten spezifische Elastic-Kernfunktionen zur Verfügung, um Informationen abzurufen und auszuführen oder Aktionen durchzuführen. Tools können Kernfunktionen wie das Abrufen von Indizes oder Zuordnungen umfassen, aber auch fortgeschrittenere Funktionen wie die Verarbeitung natürlicher Sprache zu ES|QL.

Elasticsearch wird mit einer Reihe von Standardwerkzeugen ausgeliefert, die für gängige Anwendungsfälle optimiert sind. Die wahre Flexibilität ergibt sich jedoch daraus, eigene Lösungen zu entwickeln. Durch die Definition von Tools legen Sie genau fest, welche Abfragen, Indizes und Felder einem Agenten mit ES|QL zugänglich gemacht werden, und erhalten so eine präzise Kontrolle über Geschwindigkeit, Genauigkeit und Sicherheit.

Die Registrierung eines neuen Tools ist ebenfalls so einfach wie ein einziger API-Aufruf. Sie könnten ein Tool erstellen, das unsere ES|QL (Elasticsearch Query Language) nutzt, um Neuigkeiten über ein bestimmtes Finanzinstrument zu finden:

Nach der Registrierung können Sie das neue Tool Ihren benutzerdefinierten Agenten zuweisen und ihnen so eine kuratierte Auswahl an Funktionen zur Verfügung stellen, die sie bei Bedarf nutzen können.

Wir bieten eine Plattform zur Erstellung von maßgeschneiderten Tools für Ihre spezifischen Bedürfnisse, z. B. mit ES|QL, die den Agenten von einem Allzweckagenten in einen domänenspezifischen Experten verwandelt, der auf Ihren einzigartigen Daten und Ihrer Geschäftsdomäne basiert.

Offene Standards und Interoperabilität

Elasticsearch Agents und Tools werden über offene Standard-APIs bereitgestellt, wodurch sie sich leicht als grundlegende Bausteine in das breitere Ökosystem agentenbasierter Frameworks integrieren lassen. Unser Ansatz ist einfach: keine Blackboxes. Wir möchten, dass Sie die Kernkompetenz von Elastic im Bereich der Suche nutzen und sie mit komplementären Fähigkeiten und anderen agentenbasierten Systemen kombinieren können.

Um dies zu ermöglichen, stellen wir unsere Fähigkeiten über APIs, neue Protokolle und offene Standards zur Verfügung.

Model Context Protocol (MCP)

Das Model Context Protocol (MCP) entwickelt sich schnell zum offenen Standard für die systemübergreifende Vernetzung von Tools. Durch die Unterstützung von MCP kann Elasticsearch dialogbasierte KI mit Ihren Datenbanken, Indizes und externen APIs verbinden. Da im Elastic Stack ein Remote-MCP-Server integriert ist, kann jeder MCP-kompatible Client auf die Tools von Elastic zugreifen und sie als Bausteine in seinen umfassenderen agentenbasierten Workflows verwenden.

Das ist keine Einbahnstraße. Sie können außerdem Tools von externen MCP-Servern importieren und diese in Elasticsearch verfügbar machen. Schon bald werden MCP-Server wahrscheinlich für nahezu alles verfügbar sein und weitaus umfassender sein als alles, was wir selbst entwickeln könnten. Elastic bietet Such- und Abruffunktionen in großem Umfang, und Sie können dies mit spezialisierten Funktionen anderer Plattformen kombinieren, um effektive Agenten zu erstellen.

Agent-to-Agent (A2A)

Wir arbeiten außerdem an der Unterstützung von Agent zu Agent (A2A). Bei MCP geht es um die Vernetzung von Tools, bei A2A hingegen um die Vernetzung von Agenten. Mit einem A2A-Server können die von Ihnen erstellten Elastic-Agenten direkt mit Agenten aus anderen Systemen kommunizieren: Kontext austauschen, Aufgaben delegieren und Arbeitsabläufe koordinieren.

Man kann es sich als Interoperabilität auf der Ebene der Argumentation vorstellen. Ihr Elastic-Agent könnte die Suche und den Abruf übernehmen, dann eine Aufgabe an einen spezialisierten Support- oder IT-Agenten weitergeben und das Ergebnis nahtlos zurückerhalten. Das Ergebnis ist ein Ökosystem kooperierender Akteure, von denen jeder das tut, was er am besten kann.

Die Einführung von MCP und A2A unterstreicht letztlich unser Bekenntnis zu Elasticsearch als vollwertigem Bestandteil und gewährleistet die offene Integration innerhalb des gesamten agentenbasierten Ökosystems.

Rückverfolgung und Bewertung

Mit der Integration von Suchfunktionen in Agenten wird die Herausforderung einer effektiven Evaluierung entscheidend. Um Agenten in realen Unternehmensumgebungen bedenkenlos einsetzen zu können, benötigen Sie die Gewissheit, dass sie nicht nur präzise, sondern auch effizient und zuverlässig sind. Wie misst man die Leistung, diagnostiziert eine schlechte Reaktion oder verbessert die Ausgangslage? Alles beginnt mit Transparenz.

Aus diesem Grund haben wir unsere Agenten-APIs von Grund auf auf Transparenz ausgelegt. Betrachten wir folgende einfache Agenteninteraktion:

Die Antwort enthält nicht nur das Endergebnis, sondern auch den vollständigen Ausführungsablauf, aus dem hervorgeht, welche Werkzeuge der Agent ausgewählt hat, welche Parameter er verwendet hat und welche Ergebnisse jeder Schritt erbracht hat.

Eine umfassende Ablaufverfolgung und Protokollierung sind für einen kontinuierlichen Verbesserungsprozess unerlässlich, und schon bald können Sie diese Agenten-Traces direkt in Elasticsearch speichern und anzeigen. Noch besser: Diese Traces basieren auf dem OpenTelemetry-Protokoll, wodurch sichergestellt wird, dass sie standardisiert und portabel sind und sich in die Observability-Plattform Ihrer Wahl integrieren lassen.

Dieser Detaillierungsgrad ist die Grundlage für einen echten kontinuierlichen Verbesserungsprozess. Es ermöglicht Ihnen, eine umfassende Suite von Tests zu erstellen, Fehler zu beheben, Fehlermodi zu identifizieren, um Regressionen zu verhindern, und erfolgreiche Muster zu erfassen, um die Leistung feinabzustimmen. Letztendlich ist dieser datengetriebene Ansatz der Schlüssel zur Umwandlung eines vielversprechenden Prototyps in ein produktionsreifes, vertrauenswürdiges KI-System.

Security

Da Agenten und Tools immer leistungsfähiger werden, ist Sicherheit nicht mehr optional – sie ist grundlegend. Die Bereitstellung von APIs, die Automatisierung von Aufgaben und Arbeitsabläufen erfordert, dass Unternehmenssysteme vertrauenswürdig sind. Gerade weil Agenten immer mehr Arbeitsabläufe automatisieren, ist die Fähigkeit, diese zu sichern und sicherzustellen, dass sie den Unternehmensanforderungen entsprechen, von entscheidender Bedeutung.

Die genannten Funktionen übernehmen alle die in Elastic bereits heute verfügbaren Steuerelemente, einschließlich rollenbasierter Zugriffskontrolle (RBAC) für API-Aufrufe und API-Schlüsselverwaltung. Wir dehnen die gleichen Kontrollen auch auf neue Protokolle wie MCP aus. Das bedeutet Unterstützung für Standards wie OAuth sowie die Möglichkeit, benutzerdefinierte Authentifizierungsmechanismen einzubinden.

Unser Ziel ist es, Ihnen die Flexibilität zu geben, mit Agenten und Tools zu experimentieren und gleichzeitig das von Ihrer Organisation geforderte Maß an Sicherheit, Compliance und Governance aufrechtzuerhalten.

Was kommt als Nächstes?

Wir fügen nicht nur Funktionen hinzu; wir erweitern Elasticsearch für agentenbasierte Kontextentwicklung. Wir planen, unsere zukünftige Entwicklung auf diesen Prinzipien aufzubauen:

1. Bekenntnis zu Open Source und Standards

Unser Bekenntnis zu Open Source und offenen Standards gewährleistet, dass diese Funktionen mit externen Agenten-Frameworks interoperabel bleiben. Sie können jederzeit Agenten in Ihrem gesamten Ökosystem verbinden, erweitern und zusammenstellen und behalten dabei die Kontrolle über Ihre Daten und Arbeitsabläufe.

2. Wert des Kontextes

Der Kontext ist das größte Kapital eines KI-Agenten. Die Verwaltung des Kontextes während der Suchvorgänge und Workflow-Operationen der Agenten kann eine anspruchsvolle Aufgabe sein. Wir nutzen die Kernkompetenzen von Elastic, um Kontext-Engineering zu realisieren und sicherzustellen, dass Ihrem Agenten stets die relevantesten Informationen zur Verfügung stehen.

3. Fokus auf agentenbasierte Datenströme

Zukünftig werden Agenten eine immer größere Datenquelle darstellen, einschließlich der Ergebnisse von Agenten (generierte Dokumente, Berichte, Visualisierungen) und der Ausführungsspur von Agenten (ihr Denken, Werkzeugaufrufe, Speicher/Kontext). Elastic eignet sich hervorragend für die Verarbeitung dieser Art von Daten, und wir arbeiten an Forschungsprojekten zur Durchführung von Analysen, Auswertungen und automatisierten Verbesserungen mithilfe dieser Daten.

4. Sicherheit durch Design

KI-Agenten bringen eine ganze Reihe neuer Sicherheitsherausforderungen mit sich. Elastic war schon immer ein Vorreiter für sichere Lösungen und wir bauen auch weiterhin auf Enterprise-Niveau Schutzmechanismen, Zugriffskontrollen und "Zero-Trust"-Prinzipien.

5. In die Plattform integriert

Die Funktionen zum Erstellen von KI-Agenten sind in die Elasticsearch-Plattform integriert. Dies bedeutet, dass Funktionen auf Plattformebene wie Tracing, Evaluation, Visualisierung und Analyse auch für Agenten anwendbar sind. Sie möchten Dashboards auf Basis von Agentenausführungen entwickeln? Das ist bereits integriert. Sie möchten die Leistung des KI-Agenten mithilfe von Stimmungsanalysen bewerten? Die Plattform ermöglicht das. Dies ermöglicht es, einen kompletten Lebenszyklus rund um Ihre KI-Erlebnisse aufzubauen.

Elastic hat sich zum Ziel gesetzt, Ihnen Schnittstellen zur Verfügung zu stellen, mit denen Sie dialogbasierte KI und automatisierte Arbeitsabläufe entwickeln können, die vollständig integriert, erweiterbar und auf Ihren Daten basieren. Weitere technische Details und Fortschritte werden in Kürze bekannt gegeben.

Agent Builder ist ab sofort als private Vorschau verfügbar. Nehmen Sie Kontakt mit uns auf , um Zugang anzufordern. Haben Sie Fragen oder Feedback? Tauschen Sie sich mit unserer Entwickler-Community in unserem Slack-Workspace oder in unserem Diskussionsforum aus.

Das Verständnis der Funktionsweise von Filtern bei der Vektorsuche hilft Ihnen, die Kompromisse zwischen Leistung und Trefferquote auszubalancieren und einige der Optimierungen zu entdecken, die verwendet werden, um die Vektorsuche bei Verwendung von Filtern leistungsfähig zu gestalten.

Warum filtern?

Die Vektorsuche hat die Art und Weise, wie wir relevante Informationen in großen Datensätzen finden, revolutioniert und ermöglicht es uns, Elemente zu entdecken, die einer Suchanfrage semantisch ähnlich sind.

Es genügt jedoch nicht, einfach nur ähnliche Artikel zu finden. Oftmals müssen wir die Suchergebnisse anhand spezifischer Kriterien oder Attribute eingrenzen.

Stellen Sie sich vor, Sie suchen in einem Online-Shop nach einem Produkt. Eine reine Vektorsuche zeigt Ihnen möglicherweise visuell ähnliche Artikel an, aber Sie möchten vielleicht auch nach Preisspanne, Marke, Verfügbarkeit oder Kundenbewertungen filtern. Ohne Filterfunktion würden Ihnen unzählige ähnliche Produkte präsentiert, was es schwierig macht, genau das zu finden, was Sie suchen.

Durch die Filterung wird eine präzise Kontrolle über die Suchergebnisse ermöglicht, sodass sichergestellt wird, dass die abgerufenen Elemente nicht nur semantisch übereinstimmen, sondern auch alle notwendigen Anforderungen erfüllen. Dies führt zu einem wesentlich genaueren, effizienteren und benutzerfreundlicheren Sucherlebnis.

Hier liegt die Stärke von Elasticsearch und Apache Lucene – die effektive Filterung über verschiedene Datentypen hinweg ist einer der Hauptunterschiede zu anderen Vektordatenbanken.

Filterung für exakte Vektorsuche

Es gibt zwei Hauptmethoden zur Durchführung exakter Vektorsuchen:

• Verwendung des Indextyps flat für Ihr dense_vector-Feld. Dies bewirkt, dass knn -Suchen eine exakte Suche anstelle einer approximativen Suche verwenden.

• Die Punktzahl wird mithilfe einer script_score-Abfrage berechnet, die Vektorfunktionen verwendet. Dies kann mit jedem Indextyp verwendet werden.

Bei der Ausführung einer exakten Vektorsuche werden alle Vektoren mit der Suchanfrage verglichen. In diesem Szenario verbessert das Filtern die Leistung, da nur die Vektoren verglichen werden müssen, die den Filter passieren.

Dies hat keinen Einfluss auf die Ergebnisqualität, da ohnehin alle Vektoren berücksichtigt werden. Wir filtern bereits im Voraus die Ergebnisse heraus, die nicht interessant sind, um die Anzahl der Operationen zu reduzieren.

Dies ist sehr wichtig, da eine exakte Suche gegenüber einer approximativen Suche performanter sein kann, wenn die angewendeten Filter zu einer geringen Anzahl von Dokumenten führen.

Als Faustregel gilt: Verwenden Sie die exakte Suche, wenn weniger als 10.000 Dokumente den Filter passieren. BBQ -Indizes sind für Vergleiche wesentlich schneller, daher ist es sinnvoll, bei weniger als 100.000 Einträgen für die Basisindizes die exakte Suche zu verwenden. Weitere Details finden Sie in diesem Blogbeitrag .

Falls Ihre Filter immer sehr restriktiv sind, könnten Sie erwägen, die Indizierung auf die exakte Suche anstatt auf die ungefähre Suche auszurichten, indem Sie einen flat -Indextyp anstelle eines HNSW-basierten Index verwenden. Weitere Details finden Sie in den Eigenschaften von index_options.

Filterung für die approximative Vektorsuche

Bei der Durchführung einer approximativen Vektorsuche tauschen wir Ergebnisgenauigkeit gegen Leistung ein. Vektorsuchdatenstrukturen wie HNSW suchen effizient nach ungefähren nächsten Nachbarn in Millionen von Vektoren. Sie konzentrieren sich darauf, die ähnlichsten Vektoren zu finden, indem sie die geringste Anzahl an Vektorvergleichen durchführen, deren Berechnung aufwändig ist.

Dies bedeutet, dass andere Filterattribute nicht Teil der Vektordaten sind. Verschiedene Datentypen verfügen über eigene Indexierungsstrukturen, die effizient zum Auffinden und Filtern dieser Daten sind, wie beispielsweise Termwörterbücher, Beitragslisten und Dokumentwerte.

Da diese Datenstrukturen vom Vektorsuchmechanismus getrennt sind, wie wenden wir Filter auf die Vektorsuche an? Es gibt zwei Möglichkeiten: Filter nach der Vektorsuche (Nachfilterung) oder vor der Vektorsuche (Vorfilterung) anwenden.

Jede dieser Optionen hat Vor- und Nachteile. Lasst uns tiefer in diese Materie eintauchen!

Nachfilterung

Die Nachfilterung wendet Filter an, nachdem die Vektorsuche durchgeführt wurde. Dies bedeutet, dass die Filter angewendet werden, nachdem die k ähnlichsten Vektorergebnisse gefunden wurden.

Offensichtlich können wir nach Anwendung der Filter auf die Ergebnisse unter Umständen weniger als k Ergebnisse erhalten. Wir könnten natürlich mehr Ergebnisse durch eine Vektorsuche erhalten (höherer k-Wert), aber wir können nicht sicher sein, dass wir nach Anwendung der Filter k oder mehr Ergebnisse erhalten.

Der Vorteil der Nachfilterung besteht darin, dass sie das Laufzeitverhalten der Vektorsuche nicht verändert – die Vektorsuche ist sich der Filterung nicht bewusst. Dies ändert jedoch die endgültige Anzahl der abgerufenen Ergebnisse.

Nachfolgend ein Beispiel für die Nachfilterung mithilfe der knn-Abfrage. Prüfen Sie, ob die Filterklausel von der knn-Abfrage getrennt ist:

Für die KNN-Suche ist auch eine Nachfilterung mit dem Postfilter möglich:

Beachten Sie, dass Sie bei der knn-Suche einen expliziten Post-Filter-Abschnitt verwenden müssen. Wenn Sie keinen Nachfilter verwenden, kombiniert die kNN-Suche die Ergebnisse der nächsten Nachbarn mit anderen Abfragen oder Filtern, anstatt einen Nachfilter anzuwenden.

Vorfilterung

Durch das Anwenden von Filtern vor der Vektorsuche werden zunächst die Dokumente abgerufen, die den Filtern entsprechen, und diese Informationen werden dann an die Vektorsuche weitergegeben.

Lucene verwendet BitSets , um die Dokumente, die die Filterbedingung erfüllen, effizient zu speichern. Anschließend durchläuft die Vektorsuche den HNSW-Graphen und berücksichtigt dabei die Dokumente, die die Bedingung erfüllen. Bevor ein Kandidat zu den Ergebnissen hinzugefügt wird, wird geprüft, ob er im BitSet gültiger Dokumente enthalten ist.

Allerdings muss der Kandidat untersucht und mit der Anfrage verglichen werden, selbst wenn es sich nicht um ein gültiges Dokument handelt. Die Effektivität von HNSW beruht auf der Verbindung zwischen den Vektoren im Graphen – wenn wir die Untersuchung eines Kandidaten abbrechen würden, hieße das, dass wir möglicherweise auch seine Nachbarn überspringen würden.

Stellen Sie es sich so vor, als würden Sie zu einer Tankstelle fahren. Wenn Sie alle Straßen ausschließen, auf denen sich keine Tankstelle befindet, ist es unwahrscheinlich, dass Sie Ihr Ziel erreichen. Andere Straßen sind vielleicht nicht das, was Sie brauchen, aber sie verbinden Sie mit Ihrem Ziel. Gleiches gilt für Vektoren in einem HNSW-Diagramm!

Daraus folgt, dass die Anwendung von Vorfiltern weniger effizient ist als der Verzicht auf Filter. Wir müssen die Arbeit an allen Vektoren durchführen, die wir bei unserer Suche besuchen, und diejenigen verwerfen, die nicht dem Filter entsprechen. Wir investieren mehr Arbeit und nehmen uns mehr Zeit, um unsere Top-K-Ergebnisse zu erzielen.

Nachfolgend ein Beispiel für Vorfilterung in der Elasticsearch Query DSL. Prüfen Sie, ob die Filterklausel nun Teil des knn-Abschnitts ist:

Eine Vorfilterung ist sowohl für die KNN-Suche als auch für die KNN-Abfrage verfügbar:

Vorfilteroptimierungen

Es gibt einige Optimierungen, die wir anwenden können, um eine effiziente Vorfilterung zu gewährleisten.

Wir können auf die exakte Suche umschalten, wenn der Filter sehr restriktiv ist. Wenn nur wenige Vektoren zu vergleichen sind, ist es schneller, eine exakte Suche in den wenigen Dokumenten durchzuführen, die dem Filter entsprechen.

Dies ist eine Optimierung, die in Lucene und Elasticsearch automatisch angewendet wird.

Eine weitere Optimierungsmethode besteht darin, die Vektoren zu ignorieren, die den Filter nicht erfüllen. Stattdessen prüft diese Methode die Nachbarn der gefilterten Vektoren, die den Filter passieren. Dieser Ansatz reduziert effektiv die Anzahl der Vergleiche, da die gefilterten Vektoren nicht berücksichtigt werden, und untersucht weiterhin Vektoren, die mit dem aktuellen Pfad verbunden sind.

Dieser Algorithmus heißt ACORN-1, und der Prozess wird in diesem Blogbeitrag ausführlich beschrieben.

Filtern mithilfe der Dokumentensicherheit

Document Level Security (DLS) ist eine Elasticsearch-Funktion, die festlegt, welche Dokumente Benutzerrollen abrufen können.

DLS wird mittels Abfragen durchgeführt. Einer Rolle kann eine Abfrage zugeordnet sein, die die Dokumente einschränkt, die ein Benutzer dieser Rolle aus den Indizes abrufen kann.

Die Rollenabfrage dient als Filter, um die Dokumente abzurufen, die ihr entsprechen, und wird als BitSet zwischengespeichert. Dieses BitSet wird dann verwendet, um den zugrunde liegenden Lucene-Reader zu umschließen, sodass nur die Dokumente, die von der Abfrage zurückgegeben wurden, als aktivgelten – das heißt, sie existieren im Index und wurden nicht gelöscht.

Da die Live-Dokumente vom Reader abgerufen werden, um die kNN-Abfrage durchzuführen, werden nur die dem Benutzer zur Verfügung stehenden Dokumente berücksichtigt. Falls ein Vorfilter vorhanden ist, werden die DLS-Dokumente diesem hinzugefügt.

Dies bedeutet, dass die DLS-Filterung als Vorfilter für die approximative Vektorsuche fungiert, mit denselben Auswirkungen auf die Leistung und den gleichen Optimierungen.

Die DLS-Suche mit exakter Suche bietet die gleichen Vorteile wie die Anwendung eines beliebigen Filters – je weniger Dokumente aus der DLS abgerufen werden, desto effizienter ist die exakte Suche. Berücksichtigen Sie auch die Anzahl der von DLS zurückgegebenen Dokumente – wenn die DLS-Rollen sehr restriktiv sind, sollten Sie die Verwendung einer exakten Suche anstelle einer ungefähren Suche in Betracht ziehen.

Benchmarking

Wir bei Elasticsearch möchten sicherstellen, dass die Vektorsuchfilterung effizient ist. Wir haben einen speziellen Benchmark für die Vektorfilterung , der approximative Vektorsuchen mit unterschiedlichen Filtern durchführt, um sicherzustellen, dass die Vektorsuche relevante Ergebnisse so schnell wie möglich liefert.

Prüfen Sie die Verbesserungen, die mit der Einführung von ACORN-1 einhergingen. Bei Tests, bei denen nur 2 % der Vektoren den Filter passieren, reduziert sich die Abfragelatenz auf 55 % der ursprünglichen Dauer:

Fazit

Filtern ist ein integraler Bestandteil der Suche. Die Gewährleistung einer leistungsfähigen Filterung bei der Vektorsuche sowie das Verständnis der damit verbundenen Kompromisse und Optimierungsmöglichkeiten entscheiden darüber, ob eine effiziente und genaue Suche gelingt oder scheitert.

Die Filterung beeinflusst die Leistung bei der Vektorsuche:

• Die exakte Suche ist schneller, wenn Filter verwendet werden. Sie sollten die Verwendung einer exakten Suche anstelle einer ungefähren Suche in Betracht ziehen, wenn Ihre Filterkriterien ausreichend restriktiv sind. Dies ist eine automatische Optimierung in Elasticsearch.

• Die ungefähre Suche ist langsamer, wenn Vorfilter verwendet werden. Durch die Vorfilterung erhalten wir die ersten k Ergebnisse, die dem Filter entsprechen, allerdings auf Kosten einer langsameren Suche.

• Die Nachfilterung liefert nicht unbedingt die obersten k Ergebnisse, da diese bereits beim Anwenden des Filters herausgefiltert worden sein können.

Viel Spaß beim Filtern!