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!

Sie fragen sich vielleicht, warum Sie überhaupt mehrere Diagramme verwenden? Dies ist ein Nebeneffekt einer Architekturentscheidung in Lucene: unveränderliche Segmente. Wie bei den meisten architektonischen Entscheidungen gibt es Vor- und Nachteile. Beispielsweise haben wir vor Kurzem Serverless Elasticsearch allgemein zugänglich gemacht. In diesem Zusammenhang haben wir durch unveränderliche Segmente erhebliche Vorteile erzielt, darunter eine effiziente Indexreplikation und die Möglichkeit, die Index- und Abfrageberechnung zu entkoppeln und unabhängig voneinander automatisch zu skalieren. Bei der Vektorquantisierung bieten uns Segmentzusammenführungen die Möglichkeit, Parameter zu aktualisieren, um sie an die Dateneigenschaften anzupassen. In diesem Sinne sind wir der Meinung, dass die Möglichkeit, Datenmerkmale zu messen und Indexierungsentscheidungen zu überprüfen, noch weitere Vorteile mit sich bringt.

In diesem Beitrag besprechen wir die Arbeit, die wir geleistet haben, um den Aufwand für die Erstellung mehrerer HNSW-Diagramme deutlich zu reduzieren und insbesondere die Kosten für das Zusammenführen von Diagrammen zu senken.

Hintergrund

Um eine überschaubare Anzahl von Segmenten beizubehalten, prüft Lucene regelmäßig, ob Segmente zusammengeführt werden sollen. Dies läuft darauf hinaus, zu prüfen, ob die aktuelle Segmentanzahl eine Zielsegmentanzahl überschreitet, die durch die Basissegmentgröße und die Zusammenführungsrichtlinie bestimmt wird. Wenn die Anzahl überschritten wird, führt Lucene Segmentgruppen zusammen, während die Einschränkung verletzt wird. Dieser Vorgang wurde an anderer Stelle ausführlich beschrieben.

Lucene entscheidet sich für die Zusammenführung ähnlich großer Segmente, da dadurch ein logarithmisches Wachstum der Schreibverstärkung erreicht wird. Im Fall eines Vektorindex ist die Schreibverstärkung die Anzahl der Male, die ein Vektor in ein Diagramm eingefügt wird. Lucene versucht, Segmente in Gruppen von etwa 10 zusammenzuführen. Folglich werden Vektoren in einen Graphen eingefügt, der ungefähr beträgt.mal, wobei die Anzahl der Indexvektoren und die erwartete Anzahl der Basissegmentvektoren ist. Aufgrund des logarithmischen Wachstums liegt die Schreibverstärkung selbst bei großen Indizes im einstelligen Bereich. Die Gesamtzeit, die zum Zusammenführen von Graphen benötigt wird, ist jedoch linear proportional zur Schreibverstärkung.

Beim Zusammenführen von HNSW-Graphen nehmen wir bereits eine kleine Optimierung vor: Wir behalten den Graphen für das größte Segment bei und fügen Vektoren aus den anderen Segmenten darin ein. Dies ist der Grund für den oben genannten 9/10-Faktor. Im Folgenden zeigen wir, wie wir durch die Verwendung von Informationen aus allen Diagrammen, die wir zusammenführen, deutlich bessere Ergebnisse erzielen können.

HNSW-Graphzusammenführung

Bisher haben wir den größten Graphen beibehalten und Vektoren aus den anderen eingefügt, wobei wir die Graphen, die sie enthalten, ignoriert haben. Die zentrale Erkenntnis, die wir im Folgenden nutzen, ist, dass jeder HNSW-Graph, den wir verwerfen, wichtige Näheinformationen über die darin enthaltenen Vektoren enthält. Wir möchten diese Informationen nutzen, um das Einfügen zumindest einiger Vektoren zu beschleunigen.

Wir konzentrieren uns auf das Problem des Einfügens eines kleineren Graphen in einen größeren Graphen , da dies eine atomare Operation ist, die wir zum Erstellen beliebiger Zusammenführungsrichtlinien verwenden können.

Die Strategie besteht darin, eine Teilmenge von Eckpunkten von zu finden, die in den großen Graphen eingefügt werden soll. Wir verwenden dann die Konnektivität dieser Knoten im kleinen Graphen, um das Einfügen der verbleibenden Knoten zu beschleunigen. Im Folgenden verwenden wir und um die Nachbarn eines Knotens im kleinen bzw. großen Graphen zu bezeichnen. Schematisch ist der Ablauf wie folgt.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Wir berechnen die Menge mithilfe eines Verfahrens, das wir unten besprechen (Zeile 1). Dann fügen wir jeden Knoten in mithilfe des Standard-HNSW-Einfügeverfahrens in den großen Graphen ein (Zeile 2). Für jeden Knoten, den wir nicht eingefügt haben, finden wir seine Nachbarn, die wir eingefügt haben, und deren Nachbarn im großen Graphen (Zeilen 4 und 5). Wir verwenden ein mit diesem Set (Zeile 6) gesätes FAST-SEARCH-LAYER -Verfahren, um die Kandidaten für SELECT-NEIGHBORS-HEURISTIC aus dem HNSW- Papier (Zeile 7) zu finden. Tatsächlich ersetzen wir SEARCH-LAYER , um den Kandidatensatz in der Methode INSERT (Algorithmus 1 aus dem Dokument) zu finden, die ansonsten unverändert bleibt. Schließlich fügen wir den Scheitelpunkt hinzu, den wir gerade in eingefügt haben (Zeile 8).

Damit dies funktioniert, ist klar, dass jeder Scheitelpunkt in mindestens einen Nachbarn in haben muss. Tatsächlich verlangen wir, dass für jeden Scheitelpunkt in für ein gewisses , die maximale Schichtkonnektivität, gilt. Wir beobachten, dass in realen HNSW-Diagrammen eine ziemliche Streuung der Scheitelpunktgrade zu sehen ist. Die folgende Abbildung zeigt eine typische kumulative Dichtefunktion des Scheitelpunktgrads für die unterste Ebene eines Lucene HNSW-Diagramms.

Wir haben die Verwendung eines festen Werts für sowie die Möglichkeit untersucht, ihn zu einer Funktion des Scheitelpunktgrads zu machen. Diese zweite Wahl führt zu größeren Beschleunigungen bei minimalen Auswirkungen auf die Grafikqualität, daher habe ich mich für Folgendes entschieden

Beachten Sie, dass | per Definition gleich dem Grad des Scheitelpunkts im kleinen Graphen ist. Eine Untergrenze von zwei bedeutet, dass wir jeden Scheitelpunkt einfügen, dessen Grad kleiner als zwei ist.

Ein einfaches Zählargument legt nahe, dass wir bei sorgfältiger Wahl von nur etwa direkt in einfügen müssen. Konkret färben wir eine Kante des Graphen, wenn wir genau einen ihrer Endknoten in einfügen. Dann wissen wir, dass wir für jeden Knoten in mindestens Kanten einfärben müssen, um mindestens Nachbarn in Darüber hinaus erwarten wir, dass

Dabei ist der durchschnittliche Knotengrad im kleinen Graphen. Für jeden Knoten färben wir höchstens Kanten. Daher beträgt die Gesamtzahl der Kanten, die wir voraussichtlich einfärben werden, höchstens . Wir hoffen, dass wir durch sorgfältige Wahl von annähernd diese Anzahl von Kanten einfärben können. Um alle Eckpunkte abzudecken, muss folgende Bedingung erfüllen:

Dies impliziert, dass .

Vorausgesetzt, SEARCH-LAYER dominiert die Laufzeit, lässt dies darauf schließen, dass wir eine bis zu Beschleunigung der Zusammenführungszeit erreichen könnten. Angesichts des logarithmischen Wachstums der Schreibverstärkung bedeutet dies, dass wir selbst bei sehr großen Indizes die Erstellungszeit im Vergleich zum Erstellen eines Diagramms normalerweise nur verdoppeln würden.

Das Risiko bei dieser Strategie besteht darin, dass wir die Grafikqualität beeinträchtigen. Wir haben es zunächst mit einem No-Op FAST-SEARCH-LAYER versucht. Wir haben festgestellt, dass dies die Qualität des Diagramms in dem Maße verschlechtert, dass die Rückrufrate als Funktion der Latenz beeinträchtigt wird, insbesondere beim Zusammenführen auf ein einzelnes Segment. Anschließend haben wir mithilfe einer eingeschränkten Suche im Diagramm verschiedene Alternativen untersucht. Am Ende war die effektivste Wahl die einfachste. Verwenden Sie SEARCH-LAYER , aber mit einem niedrigen ef_construction. Mit dieser Parametrisierung konnten wir Grafiken von hervorragender Qualität erzielen und die Zusammenführungszeit dennoch durchschnittlich um etwas mehr als 30 % verkürzen.

Berechnung der Join-Menge

Die Suche nach einer guten Join-Menge kann als HNSW-Graphüberdeckungsproblem formuliert werden. Eine Greedy-Heuristik ist eine einfache und effektive Heuristik zur Annäherung an optimale Graphüberdeckungen. Bei unserem Ansatz werden die Knotenpunkte nacheinander in absteigender Reihenfolge der Verstärkung zu hinzugefügt. Der Gewinn ist wie folgt definiert:

Dabei bezeichnet die Anzahl der Nachbarn eines Vektors in und ist die Indikatorfunktion. Der Gewinn beinhaltet die Änderung der Anzahl der Scheitelpunkte, die wir zu hinzugefügt haben, also , da wir unserem Ziel durch das Hinzufügen eines weniger abgedeckten Scheitelpunkts näher kommen. Die Gewinnberechnung wird in der folgenden Abbildung für den zentralen orangefarbenen Scheitelpunkt veranschaulicht.

Wir behalten für jeden Knoten den folgenden Zustand bei:

1. Ob es abgestanden ist,

2. Sein Gewinn ,

3. Die Anzahl der benachbarten Eckpunkte in wird bezeichnet,

4. Eine Zufallszahl im Bereich [0,1], die zum Auflösen eines Gleichstands verwendet wird.

Der Pseudocode zum Berechnen des Join-Sets lautet wie folgt.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Wir initialisieren zunächst den Status in den Zeilen 1-5.

In jeder Iteration der Hauptschleife extrahieren wir zunächst den Scheitelpunkt mit der maximalen Verstärkung (Zeile 8) und lösen Gleichstände nach dem Zufallsprinzip auf. Bevor wir Änderungen vornehmen, müssen wir prüfen, ob die Verstärkung des Scheitelpunkts veraltet ist. Insbesondere beeinflussen wir jedes Mal, wenn wir einen Scheitelpunkt zu hinzufügen, den Gewinn anderer Scheitelpunkte:

1. Da alle seine Nachbarn einen zusätzlichen Nachbarn in haben, können sich ihre Gewinne ändern (Zeile 14).

2. Wenn einer seiner Nachbarn jetzt vollständig gedeckt ist, können sich die Gewinne aller seiner Nachbarn ändern (Zeilen 14-16).

Wir berechnen die Gewinne auf verzögerte Weise neu, d. h. wir berechnen den Gewinn eines Scheitelpunkts nur dann neu, wenn wir ihn in einfügen möchten (Zeilen 18–20). Da die Gewinne immer nur abnehmen, können wir nie einen Scheitelpunkt verpassen, den wir einfügen sollten.

Beachten Sie, dass wir lediglich den Gesamtgewinn der zu hinzugefügten Scheitelpunkte im Auge behalten müssen, um zu bestimmen, wann wir aussteigen müssen. Darüber hinaus wird, obwohl mindestens ein Scheitelpunkt einen von Null verschiedenen Gewinn aufweisen, sodass wir immer Fortschritte machen.

Ergebnisse

Wir haben Experimente mit vier Datensätzen durchgeführt, die zusammen unsere drei unterstützten Distanzmetriken (euklidisch, Kosinus und inneres Produkt) abdecken:

1. quora-E5-small: 522931 Dokumente, 384 Dimensionen und verwendet Kosinusähnlichkeit,

2. cohere-wikipedia-v2: 1 Million Dokumente, 768 Dimensionen und verwendet Kosinusähnlichkeit,

3. Kern: 1 Million Dokumente, 960 Dimensionen und verwendet euklidische Distanz und

4. cohere-wikipedia-v3: 1 Mio. Dokumente, 1024 Dimensionen und verwendet das maximale innere Produkt.

Für jeden Datensatz bewerten wir zwei Quantisierungsstufen:

1. int8 – verwendet eine 1-Byte-Ganzzahl pro Dimension und

2. BBQ – das ein einzelnes Bit pro Dimension verwendet.

Schließlich haben wir für jedes Experiment die Suchqualität bei zwei Abruftiefen bewertet und nach dem Erstellen des Index und anschließend nach der erzwungenen Zusammenführung zu einem einzelnen Segment untersucht.

Zusammenfassend lässt sich sagen, dass wir durchgängig erhebliche Beschleunigungen bei der Indizierung und Zusammenführung erzielen und dabei in allen Fällen die Grafikqualität und damit die Suchleistung beibehalten.

Experiment 1: int8-Quantisierung

Die durchschnittlichen Beschleunigungen von der Basislinie bis zum Kandidaten, die vorgeschlagenen Änderungen, sind:

Beschleunigung der Indexzeit: 1,28

Beschleunigung der Force Merge: 1,72

Dies entspricht folgender Laufzeitaufteilung

Der Vollständigkeit halber sind die genauen Zeiten

Index

Verschmelzen

Datensatz

Basislinie

Kandidat

Entwickeln

Kandidat

Quora-E5-klein

112,41 s

81,55 s

113,81 s

70,87 s

wiki-cohere-v2

158,1 s

122,95 s

425,20 s

239,28 s

Kern

141,82 s

119,26 s

536,07 s

279,05 s

wiki-cohere-v3

211,86 s

168,22 s

654,97 s

414,12 s

Unten zeigen wir die Diagramme „Rückruf vs. Latenz“, die den Kandidaten (gestrichelte Linien) mit der Basislinie bei zwei Abruftiefen vergleichen: Rückruf@10 und Rückruf@100 für Indizes mit mehreren Segmenten (das Endergebnis unserer Standard-Zusammenführungsstrategie nach der Indizierung aller Vektoren) und nach der erzwungenen Zusammenführung zu einem einzelnen Segment. Eine Kurve, die höher und weiter links liegt, ist besser, da sie eine höhere Rückrufrate bei geringerer Latenz bedeutet.

Wie Sie sehen, ist der Kandidat für mehrere Segmentindizes für den Cohere v3-Datensatz besser und für alle anderen Datensätze etwas schlechter, aber fast vergleichbar. Nach der Zusammenführung zu einem einzigen Segment sind die Erinnerungskurven in allen Fällen nahezu identisch.

Experiment 2: BBQ-Quantisierung

Die durchschnittlichen Beschleunigungen von der Basislinie zum Kandidaten sind:

Beschleunigung der Indexzeit: 1,33

Beschleunigung der Force Merge: 1,34

Dies entspricht folgender Laufzeitaufteilung

Der Vollständigkeit halber sind die genauen Zeiten

Index

Verschmelzen

Datensatz

Basislinie

Kandidat

Entwickeln

Kandidat

Quora-E5-klein

70,71 s

58,25 s

59,38 s

40,15 s

wiki-cohere-v2

203,08 s

142,27 s

107,27 s

85,68 s

Kern

110,35 s

105,52 s

323,66 s

202,2 s

wiki-cohere-v3

313,43 s

190,63 s

165,98 s

159,95 s

Bei Indizes mit mehreren Segmenten ist der Kandidat für fast alle Datensätze besser, mit Ausnahme von Cohere v2, wo die Basislinie etwas besser ist. Für die einzelnen Segmentindizes sind die Recall-Kurven in allen Fällen nahezu identisch.

Fazit

Der in diesem Blog besprochene Algorithmus wird im kommenden Lucene 10.2 und in der darauf basierenden Elasticsearch-Version verfügbar sein. Benutzer können in diesen neuen Versionen von der verbesserten Zusammenführungsleistung und der verkürzten Indexerstellungszeit profitieren. Diese Änderung ist Teil unserer kontinuierlichen Bemühungen, Lucene und Elasticsearch für die Vektor- und Hybridsuche schnell und effizient zu machen.

Das Debuggen von Parallelitätsfehlern ist kein Zuckerschlecken, aber wir werden uns damit befassen. Hier kommt Fray ins Spiel, ein deterministisches Framework für Parallelitätstests aus dem PASTA Lab der CMU, das unzuverlässige Fehler in zuverlässig reproduzierbare Fehler verwandelt. Dank Frays cleverem Shadow-Lock-Design und präziser Gewindesteuerung konnten wir einen kniffligen Fehler in Lucene aufspüren und ihn schließlich beheben. Dieser Beitrag untersucht, wie Open-Source-Helden und -Tools das Debuggen von Parallelverarbeitung weniger schmerzhaft machen – und die Softwarewelt um einiges besser.

Parallelitätsfehler: Der Fluch von Softwareentwicklern

Parallelitätsfehler sind das Schlimmste. Sie sind nicht nur schwer zu reparieren, sondern es ist schon die größte Herausforderung, sie zuverlässig zum Ausfall zu bringen. Nehmen wir diesen Testfehler, TestIDVersionPostingsFormat#testGlobalVersions, als Beispiel. Es erzeugt mehrere Threads zum Schreiben und Aktualisieren von Dokumenten und stellt damit Lucenes optimistisches Parallelitätsmodell in Frage. Dieser Test deckte eine Race Condition in der optimistischen Parallelitätskontrolle auf. Das heißt, eine Dokumentenoperation kann fälschlicherweise als die letzte in einer Abfolge von Operationen ausgegeben werden 😱. Das bedeutet, dass unter bestimmten Bedingungen eine Aktualisierungs- oder Löschoperation tatsächlich erfolgreich sein kann, obwohl sie aufgrund optimistischer Parallelitätsbeschränkungen eigentlich hätte fehlschlagen müssen.

Entschuldigung an alle, die Java-Stacktraces hassen. Hinweis: Löschen bedeutet nicht unbedingt „löschen“. Es kann auch auf eine Dokumentenaktualisierung hinweisen, da die Segmente von Lucene schreibgeschützt sind.

Apache Lucene verwaltet jeden Thread, der Dokumente schreibt, über die Klasse DocumentsWriter . Diese Klasse erstellt oder verwendet Threads zum Schreiben von Dokumenten wieder, wobei jede Schreibaktion ihre Informationen innerhalb der Klasse DocumentsWriterPerThread (DWPT) steuert. Darüber hinaus verfolgt der Autor, welche Dokumente in DocumentsWriterDeleteQueue (DWDQ) gelöscht werden. Diese Strukturen halten alle Dokumentänderungsaktionen im Speicher und werden periodisch geleert, wodurch Speicherressourcen freigegeben und Strukturen auf der Festplatte gespeichert werden.

Um blockierende Threads zu vermeiden und einen hohen Durchsatz in parallelen Systemen zu gewährleisten, versucht Apache Lucene, nur in sehr kritischen Abschnitten zu synchronisieren . Das kann in der Praxis zwar gut sein, aber wie bei jedem System mit parallelen Prozessen gibt es auch hier Tücken.

Eine falsche Hoffnung

Meine ersten Nachforschungen führten mich zu einigen kritischen Abschnitten, die nicht ordnungsgemäß synchronisiert waren. Alle Interaktionen eines gegebenen DocumentsWriterDeleteQueue werden durch das ihn umschließende DocumentsWriter gesteuert. Während also einzelne Methoden in DocumentsWriterDeleteQueue möglicherweise nicht angemessen synchronisiert sind, ist ihr Zugriff auf die Welt (oder sollte es sein) gewährleistet. (Wir wollen uns nicht näher damit befassen, wie dies die Eigentums- und Zugriffsrechte verkompliziert – es handelt sich um ein langjähriges Projekt, an dem viele Mitwirkende beteiligt sind.) Seid etwas nachsichtiger.)

Ich habe jedoch während eines Spülvorgangs eine Stelle gefunden, die nicht synchronisiert war.

Diese Aktionen werden nicht zu einer einzigen atomaren Operation synchronisiert. Das heißt, zwischen der Erstellung newQueue und dem Aufruf von getMaxSeqNo könnte anderer Code ausgeführt worden sein, der die Sequenznummer in der Klasse documentsWriter inkrementiert. Ich habe den Fehler gefunden!

Doch wie bei den meisten komplexen Fehlern war die Ursachenfindung nicht einfach. Da trat ein Held auf den Plan.

Ein Held im Kampf

Auftritt unseres Helden: Ao Li und seine Kollegen im PASTA-Labor. Ich lasse ihn erklären, wie sie mit Fray die Situation gerettet haben.

Fray ist ein deterministisches Framework für Parallelitätstests, das von Forschern des PASTA Lab an der Carnegie Mellon University entwickelt wurde. Die Motivation für die Entwicklung von Fray liegt in einer deutlich erkennbaren Kluft zwischen Wissenschaft und Industrie: Während deterministisches Concurrency-Testing in der akademischen Forschung seit über 20 Jahren intensiv untersucht wird, verlassen sich Praktiker weiterhin auf Stresstests – eine Methode, die allgemein als unzuverlässig und fehleranfällig gilt – um ihre Concurrency-Programme zu testen. Unser Hauptziel war daher die Entwicklung und Implementierung eines deterministischen Frameworks für Parallelitätstests, bei dem Allgemeingültigkeit und praktische Anwendbarkeit im Vordergrund standen.

Die Kernidee

Im Kern nutzt Fray ein einfaches, aber wirkungsvolles Prinzip: die sequentielle Ausführung. Das Nebenläufigkeitsmodell von Java bietet eine Schlüsseleigenschaft : Wenn ein Programm frei von Datenkonflikten ist, erscheinen alle Ausführungen sequenziell konsistent. Das bedeutet, dass das Verhalten des Programms als eine Folge von Programmanweisungen dargestellt werden kann.

Fray arbeitet, indem es das Zielprogramm sequenziell ausführt: Bei jedem Schritt werden alle Threads außer einem angehalten, wodurch Fray die Thread-Planung präzise steuern kann. Um Parallelität zu simulieren, werden die Threads zufällig ausgewählt, die Auswahl wird jedoch für die spätere deterministische Wiedergabe aufgezeichnet. Um die Ausführung zu optimieren, führt Fray Kontextwechsel nur dann durch, wenn ein Thread im Begriff ist, eine Synchronisierungsanweisung wie Sperren oder atomaren/flüchtigen Zugriff auszuführen. Eine schöne Eigenschaft der Data-Race-Freiheit ist, dass dieser begrenzte Kontextwechsel ausreicht, um alle beobachtbaren Verhaltensweisen aufgrund von Thread-Interleaving zu untersuchen (in unserem Paper findet sich eine Beweisskizze).

Die Herausforderung: die Thread-Planung steuern

Obwohl die Grundidee einfach erscheint, stellte die Implementierung von Fray erhebliche Herausforderungen dar. Um die Thread-Planung zu steuern, muss Fray die Ausführung jedes Anwendungsthreads verwalten. Auf den ersten Blick mag dies unkompliziert erscheinen – die grundlegenden Mechanismen zur Parallelverarbeitung werden einfach durch maßgeschneiderte Implementierungen ersetzt. Die Steuerung der Parallelverarbeitung in der JVM ist jedoch komplex und beinhaltet eine Mischung aus Bytecode-Anweisungen, High-Level-Bibliotheken und nativen Methoden.

Das entpuppte sich als Sackgasse:

• Beispielsweise muss zu jeder MONITORENTER -Anweisung eine entsprechende MONITOREXIT in derselben Methode gehören. Wenn Fray MONITORENTER durch einen Methodenaufruf an einen Stub/Mock ersetzt, muss es auch MONITOREXIT ersetzen.

• In Code, der object.wait/notify verwendet, muss, wenn MONITORENTER ersetzt wird, auch das entsprechende object.wait ersetzt werden. Diese Ersatzkette erstreckt sich bis object.notify und darüber hinaus.

• Die JVM ruft bestimmte Methoden im Zusammenhang mit Parallelität auf (z. B. object.notify , wenn ein Thread beendet wird) innerhalb des nativen Codes. Um diese Operationen zu ersetzen, müsste die JVM selbst modifiziert werden.

• JVM-Funktionen wie Klassenlader und Garbage-Collection-Threads (GC-Threads) nutzen ebenfalls Parallelitätsprimitive. Durch die Modifizierung dieser Grundfunktionen können Inkompatibilitäten mit den entsprechenden JVM-Funktionen entstehen.

• Das Ersetzen von Parallelitätsprimitiven im JDK führt oft zu JVM-Abstürzen während der Initialisierungsphase.

Diese Herausforderungen machten deutlich, dass ein umfassender Ersatz der Parallelverarbeitungsprimitive nicht realisierbar war.

Unsere Lösung: Schattenverriegelungsdesign

Um diese Herausforderungen zu bewältigen, verwendet Fray einen neuartigen Schattensperrmechanismus, um die Thread-Ausführung zu orchestrieren, ohne die Parallelitätsprimitive zu ersetzen. Schattensperren fungieren als Vermittler, die die Thread-Ausführung steuern. Bevor ein Anwendungsthread beispielsweise eine Sperre erwerben kann, muss er mit der entsprechenden Schatten-Sperre interagieren. Die Schattensperre bestimmt, ob der Thread die Sperre erwerben kann. Kann der Thread nicht fortfahren, blockiert die Schattensperre ihn und ermöglicht anderen Threads die Ausführung, wodurch Deadlocks vermieden und eine kontrollierte Parallelität ermöglicht wird. Dieses Design ermöglicht es Fray, die Thread-Verschachtelung transparent zu steuern und gleichzeitig die Korrektheit der Parallelitätssemantik zu erhalten. Jedes Parallelitätsprimitiv wird innerhalb des Shadow-Lock-Frameworks sorgfältig modelliert, um Korrektheit und Vollständigkeit zu gewährleisten. Weitere technische Details finden Sie in unserem Artikel.

Darüber hinaus ist dieses Design zukunftssicher ausgelegt. Da lediglich die Instrumentierung von Schattensperren um Parallelitätsprimitive herum erforderlich ist, wird die Kompatibilität mit neueren JVM-Versionen sichergestellt. Dies ist möglich, da die Schnittstellen der Parallelverarbeitungsprimitive in der JVM relativ stabil sind und seit Jahren unverändert geblieben sind.

Testkampf

Nach der Entwicklung von Fray folgte der nächste Schritt: die Evaluierung. Zum Glück beinhalten viele Anwendungen, wie beispielsweise Apache Lucene, bereits Tests zur Parallelverarbeitung. Bei solchen Parallelitätstests handelt es sich um reguläre JUnit-Tests, die mehrere Threads erzeugen, eine bestimmte Arbeit verrichten, dann (in der Regel) warten, bis diese Threads fertig sind, und dann eine bestimmte Eigenschaft überprüfen. In den meisten Fällen bestehen diese Tests, weil sie nur eine einzige Verschachtelung durchführen. Noch schlimmer ist, dass einige Tests in der CI/CD-Umgebung nur gelegentlich fehlschlagen, wie bereits erwähnt, was die Fehlersuche extrem erschwert. Als wir die gleichen Tests mit Fray durchführten, entdeckten wir zahlreiche Fehler. Besonders bemerkenswert ist, dass Fray zuvor gemeldete Fehler wiederentdeckte, die aufgrund des Fehlens einer zuverlässigen Reproduktion ungelöst geblieben waren, einschließlich des Themas dieses Blogs: TestIDVersionPostingsFormat.testGlobalVersions. Zum Glück können wir mit Fray diese deterministisch wiedergeben und den Entwicklern detaillierte Informationen liefern, sodass sie das Problem zuverlässig reproduzieren und beheben können.

Nächste Schritte für Fray

Wir freuen uns sehr über die Rückmeldung der Entwickler von Elastic, dass Fray bei der Fehlersuche in Parallelverarbeitungsproblemen hilfreich war. Wir werden weiterhin an Fray arbeiten, um es mehr Entwicklern zugänglich zu machen.

Zu unseren kurzfristigen Zielen gehört es, die Fähigkeit von Fray zu verbessern, den Zeitplan deterministisch wiederzugeben, selbst bei Vorhandensein anderer nicht-deterministischer Operationen wie einem Zufallswertgenerator oder der Verwendung von object.hashcode. Wir streben außerdem eine höhere Benutzerfreundlichkeit von Fray an, um Entwicklern die Analyse und das Debuggen bestehender Parallelitätstests ohne manuelle Eingriffe zu ermöglichen. Am wichtigsten ist jedoch, dass wir uns freuen, von Ihnen zu hören, wenn Sie Schwierigkeiten beim Debuggen oder Testen von Parallelitätsproblemen in Ihrem Programm haben. Bitte zögern Sie nicht, ein Problem im Fray GitHub-Repository zu melden.

Es ist an der Zeit, den Parallelitätsfehler zu beheben.

Dank Ao Li und dem PASTA-Labor haben wir nun eine zuverlässig fehlschlagende Instanz dieses Tests! Wir können das Problem endlich lösen. Die Kernfrage bestand darin, wie DocumentsWriterPerThreadPool die Wiederverwendung von Threads und Ressourcen ermöglichte.

Hier können wir sehen, wie jeder Thread erstellt wird, wobei auf die anfängliche Löschwarteschlange in Generation 0 verwiesen wird.

Beim Leeren der Warteschlange erfolgt dann ein Fortschrittsschritt, wobei die vorherigen 7 Aktionen in der Warteschlange korrekt angezeigt werden.

Bevor jedoch alle Threads vollständig verarbeitet werden können, werden zwei für ein zusätzliches Dokument wiederverwendet:

Dadurch wird der Wert seqNo über den angenommenen Maximalwert, der während des Spülvorgangs mit 7 berechnet wurde, erhöht. Beachten Sie die zusätzlichen numDocsInRAM für die Segmente _3 und _0

Dadurch wird die Reihenfolge der Dokumentaktionen während eines Flush-Vorgangs von Lucene falsch berücksichtigt, was zu diesem Testfehler führt.

Wie bei allen guten Bugfixes besteht die eigentliche Korrektur aus etwa 10 Codezeilen. Doch zwei Ingenieure brauchten mehrere Tage, um das herauszufinden:

Nicht alle Helden tragen Umhänge.

Ja, es ist ein Klischee – aber es stimmt.

Das Debuggen von parallelen Programmen ist unglaublich wichtig. Diese kniffligen Parallelitätsfehler erfordern einen unverhältnismäßig hohen Zeitaufwand für die Fehlersuche und -behebung. Während neue Sprachen wie Rust eingebaute Mechanismen zur Vermeidung solcher Race Conditions bieten, ist der Großteil der Software weltweit bereits geschrieben – und zwar in einer anderen Sprache als Rust. Auch nach all den Jahren ist Java immer noch eine der meistgenutzten Programmiersprachen. Eine verbesserte Fehlersuche in JVM-basierten Sprachen macht die Welt der Softwareentwicklung besser. Und angesichts der Tatsache, dass manche Leute glauben, Code werde von großen Sprachmodellen geschrieben, werden unsere Aufgaben als Ingenieure vielleicht irgendwann nur noch darin bestehen, schlechten LLM-Code zu debuggen, anstatt nur unseren eigenen schlechten Code. Doch unabhängig von der Zukunft der Softwareentwicklung wird das Debuggen paralleler Programme für die Wartung und Entwicklung von Software weiterhin von entscheidender Bedeutung sein.

Vielen Dank an Ao Li und seine Kollegen vom PASTA Lab, die das Ganze noch viel besser gemacht haben.

Lucene und die Gemeinschaft

Ein Projekt ist nur so stark wie die Gemeinschaft, die es unterstützt. Trotz seiner mehr als 20-jährigen Entwicklungsgeschichte ist das Lucene-Projekt nach wie vor lebendig und floriert dank seiner leidenschaftlichen und aktiven Mitwirkenden.

Im Jahr 2024 verzeichnete das Lucene-Projekt mehr als 2.000 Commits von 98 verschiedenen Mitwirkenden und fast 800 Pull Requests. Die Zahl der Mitwirkenden wächst stetig, neue Committer und PMC-Mitglieder schließen sich dem Projekt an und tragen zu seinem Erfolg bei.

Lucene 10

Im Jahr 2024 erschien die erste größere Version seit fast 3 Jahren – Lucene 10 – mit mehr als 2.000 Commits von 185 verschiedenen Mitwirkenden. Während das Entwicklungsmodell von Lucene es ermöglicht, viele Verbesserungen und Funktionen in kleineren Releases bereitzustellen, bietet ein Major-Release die Möglichkeit, größere Funktionen und Modernisierungen einzuführen. Beispielsweise benötigt Lucene 10 mindestens Java 21. Durch die Erhöhung der minimalen Java-Version wird sichergestellt, dass Lucene weiterhin von den Verbesserungen moderner Java-Versionen profitieren kann.

Der Hauptfokus von Lucene 10 liegt auf der besseren Ausnutzung der Hardware, auf der es läuft. Werfen wir einen kurzen Blick auf einige der wichtigsten Punkte:

• Mehr Suchparallelität – während die Suchausführung bereits segmentübergreifend parallelisiert ist, gehen wir jetzt noch einen Schritt weiter und parallelisieren innerhalb der Segmente. Dadurch wird die Darstellung auf der Festplatte von der Ausführungsleistung entkoppelt, sodass selbst einzelne Segmente von der Anzahl der Kerne auf modernen Systemen profitieren können.

• Verbesserte I/O-Parallelität – das einfache synchrone I/O-Modell, das Lucene verwendet, wurde um eine Vorabrufphase erweitert. Dadurch wird dem Betriebssystem mitgeteilt, dass ein Bereich einer Indexdatei in naher Zukunft benötigt wird, ohne den aufrufenden Thread zu blockieren.

• Bessere CPU- und Speichereffizienz durch Sparse-Indexierung – Lucene 10 führt die Unterstützung für Sparse-Indexierung ein, die in anderen Datenspeichern auch als Primärschlüssel-Indexierung oder Zonenindexierung bezeichnet wird.

Weitere Informationen zu Lucene 10 finden Sie im entsprechenden Artikel zu Lucene 10.

Lucene Forschung und Innovation

Im Jahr 2024 erlebte Lucene einen Aufschwung in Forschung und Innovation, insbesondere in den Bereichen maschinelles Lernen Integration, Vektorsuche und Optimierung für große Datensätze, mit Referenzen aus 10 separaten Forschungsarbeiten und Veröffentlichungen. Zu den wichtigsten Forschungsbereichen und Entwicklungen gehören:

• Vektorsuche und Einbettungsunterstützung – Lucene bietet eine leistungsstarke und skalierbare Lösung für die vektorbasierte Suche und ermöglicht so die semantische Suche in großem Umfang. Durch die Nutzung der robusten Indexierungs- und Suchinfrastruktur von Lucene können Anwender die Vorteile der traditionellen Textsuche mit den fortschrittlichen Möglichkeiten der modernen Vektorsuche kombinieren. Dadurch wird Lucene zu einer umfassenden Lösung für eine breite Palette von Such- und Informationsabrufaufgaben.

• Hybride Suchmodelle – Die Forschung hat sich auch mit hybriden Suchtechniken befasst, bei denen Lucene die traditionelle schlüsselwortbasierte Suche mit der modernen vektorbasierten Suche kombiniert. Durch die Verknüpfung von termbasierten Indizes mit dichten Vektordarstellungen kann Lucene genauere und kontextbezogenere Suchergebnisse liefern und so die Lücke zwischen der Präzision traditioneller Suchmaschinen und der Flexibilität der semantischen Suche schließen.

Die laufenden Forschungsarbeiten im Jahr 2024 demonstrieren die Anpassungsfähigkeit von Lucene an die sich wandelnden Bedürfnisse moderner Suchtechnologien, insbesondere im Kontext von KI, semantischer Suche und Big-Data-Anwendungen. Das Projekt entwickelt sich stetig weiter und ist zu einer leistungsstarken, flexiblen und effizienten Plattform für sowohl traditionelle als auch innovative Suchanwendungen geworden.

Lucene-Veröffentlichungen 2024

Auch wenn es kein exaktes Abbild darstellt, unterstreicht die schiere Anzahl der Veröffentlichungen doch das anhaltende Engagement und die Energie der Community. Diese Aktualisierungen beinhalten wesentliche Verbesserungen der Vektorsuchleistung und -effizienz, Unterstützung für madvise, Optimierungen für die Dekodierung von Postinglisten, weitere Geschwindigkeitsverbesserungen durch SIMD und vieles mehr.

Hier ist die vollständige Liste der Veröffentlichungen:

• 10.1.0 (2024-12-20)

• 9.12.1 (13.12.2024)

• 10.0.0 (14.10.2024)

• 9.12.0 (2024-09-28)

• 8.11.4 (2024-09-24)

• 9.11.1 (2024-06-27)

• 9.11.0 (2024-06-06)

• 9.10.0 (2024-02-20)

• 8.11.3 (2024-02-08)

• 9.9.2 (2024-01-29)

Weitere Informationen und Versionshinweise finden Sie auf der Lucene Core- Seite. Zusätzlich gibt es entsprechende PyLucene- Versionen.

Zusammenfassung

Mit zunehmender Reife floriert Lucene dank seiner engagierten und dynamischen Community weiterhin. Wie wir gesehen haben, war 2024 ein unglaublich produktives Jahr, und wir freuen uns nun auf die spannenden Entwicklungen, die 2025 bringen wird.

Dieser Blog ist anders als üblich. Es handelt sich weder um die Erklärung einer neuen Funktion noch um ein Tutorial. Es geht hier um eine einzige Codezeile, deren Schreiben drei Tage gedauert hat. Wir werden eine mögliche Beschädigung des Apache Lucene-Index beheben. Einige Erkenntnisse, die Sie hoffentlich mitnehmen können:

• Alle unzuverlässigen Tests sind bei ausreichend Zeit und den richtigen Werkzeugen wiederholbar.

• Für robuste Systeme sind viele Testebenen unerlässlich. Höhere Testebenen werden jedoch zunehmend schwieriger zu debuggen und zu reproduzieren.

• Sleep ist ein ausgezeichneter Debugger.

Wie Elasticsearch testet

Bei Elastic verfügen wir über eine Vielzahl von Tests, die gegen die Elasticsearch-Codebasis ausgeführt werden. Manche sind einfache und fokussierte Funktionstests, andere sind Integrationstests für einen einzelnen Knoten im „Happy Path“-Modus, und wieder andere versuchen, den Cluster zum Absturz zu bringen, um sicherzustellen, dass sich in einem Fehlerszenario alles korrekt verhält. Wenn ein Test wiederholt fehlschlägt, erstellt ein Ingenieur oder die Tool-Automatisierung ein GitHub-Issue und kennzeichnet es zur Untersuchung durch ein bestimmtes Team. Dieser spezielle Fehler wurde bei einem Test der letztgenannten Art entdeckt. Diese Tests sind knifflig und manchmal erst nach vielen Durchläufen wiederholbar.

Was genau wird mit diesem Test geprüft?

Dieser Test ist besonders interessant. Es wird eine bestimmte Zuordnung erstellen und diese auf einen primären Shard anwenden. Dann beim Versuch, eine Replik zu erstellen. Der entscheidende Unterschied besteht darin, dass beim Versuch der Replik, das Dokument zu parsen, der Test eine Ausnahme auslöst, was dazu führt, dass die Wiederherstellung auf eine überraschende (aber erwartete) Weise fehlschlägt.

Alles funktionierte wie erwartet, allerdings mit einem entscheidenden Haken. Bei der Bereinigung der Testergebnisse haben wir die Konsistenz überprüft, und dabei ist dieser Test auf ein Problem gestoßen.

Dieser Test schlug erwartungsgemäß fehl. Im Rahmen der Konsistenzprüfung würden wir überprüfen, ob alle replizierten und primären Lucene-Segmentdateien konsistent sind. Das heißt, unverfälscht und vollständig repliziert. Teilweise oder beschädigte Daten sind viel schlimmer als ein vollständiger Ausfall. Hier ist der beängstigende und abgekürzte Stacktrace des Fehlers.

Irgendwie wurde der replizierte Shard während des erzwungenen Replikationsfehlers beschädigt! Ich möchte Ihnen den Kern des Fehlers in einfachen Worten erklären.

Lucene ist eine segmentbasierte Architektur, das heißt, jedes Segment kennt und verwaltet seine eigenen schreibgeschützten Dateien. Dieses spezielle Segment wurde über seine SegmentCoreReaders validiert, um sicherzustellen, dass alles in Ordnung war. Jeder Core-Reader speichert Metadaten, die angeben, welche Feldtypen und Dateien für ein bestimmtes Segment vorhanden sind. Bei der Validierung des Lucene90PointsFormat fehlten jedoch bestimmte erwartete Dateien. Mit der Segmentdatei _0.cfs erwarteten wir eine Punktformatdatei namens kdi. cfs steht für "zusammengesetztes Dateisystem", in dem Lucene manchmal alle Feldtypen und alle kleinen Dateien zu einer einzigen größeren Datei kombiniert, um eine effizientere Replikation und Ressourcennutzung zu ermöglichen. Tatsächlich fehlten alle drei Punktdateierweiterungen: kdd, kdi, und kdm . Wie konnten wir an eine Stelle gelangen, an der ein Lucene-Segment eine Punktdatei erwartet, diese aber fehlt?! Das sieht nach einem schwerwiegenden Datenkorruptionsfehler aus!

Der erste Schritt bei jeder Fehlerbehebung: den Fehler reproduzieren.

Es war äußerst mühsam, den Fehler bei diesem speziellen Bug zu reproduzieren. Obwohl wir in Elasticsearch die Möglichkeit des randomisierten Wertetests nutzen, stellen wir sicher, dass jeder Fehler mit einem (hoffentlich) reproduzierbaren Zufallswert versehen wird, um zu gewährleisten, dass alle Fehler untersucht werden können. Das funktioniert hervorragend für alle Fehler, außer für solche, die durch eine Race Condition verursacht werden.

Egal wie oft ich es versucht habe, der Fehler konnte mit diesem speziellen Seed lokal nie reproduziert werden. Es gibt jedoch Möglichkeiten, die Tests durchzuführen und ein reproduzierbareres Scheitern zu erzielen.

Unsere spezielle Testsuite ermöglicht es, einen bestimmten Test über den Parameter -Dtests.iters im selben Befehl mehr als einmal auszuführen. Das reichte mir aber nicht, ich musste sicherstellen, dass die Ausführungsthreads wechselten und dadurch die Wahrscheinlichkeit des Auftretens dieser Race Condition erhöht wurde. Ein weiteres Problem im System war, dass der Test am Ende so lange dauerte, dass der Test-Runner eine Zeitüberschreitung meldete. Am Ende verwendete ich den folgenden albtraumhaften Bash-Code, um den Test reproduzierbar auszuführen:

Und da kommt Stress ins Spiel. Dies ermöglicht es Ihnen, schnell einen Prozess zu starten, der die CPU-Kerne im Handumdrehen belegt. Durch wiederholtes, wahlloses Ausführen von stress-ng während zahlreicher Iterationen des fehlgeschlagenen Tests konnte ich den Fehler schließlich reproduzieren. Ein Schritt näher. Um das System zu belasten, öffnen Sie einfach ein weiteres Terminalfenster und führen Sie folgenden Befehl aus:

Aufdeckung des Fehlers

Da der Testfehler, der den Bug aufdeckt, nun größtenteils reproduzierbar ist, ist es an der Zeit, die Ursache zu finden. Das Merkwürdige an diesem speziellen Test ist, dass Lucene eine Ausnahme auslöst, weil es Punktwerte erwartet, aber vom Test direkt keine hinzugefügt werden. Nur Textwerte. Dies veranlasste mich, die jüngsten Änderungen an unseren optimistischen Parallelitätskontrollfeldern _seq_no und _primary_term genauer zu betrachten. Beide werden als Punkte indexiert und sind in jedem Elasticsearch-Dokument vorhanden.

Tatsächlich hat ein Commit unseren _seq_no Mapper verändert! JA! Das muss die Ursache sein! Doch meine Begeisterung war nur von kurzer Dauer. Dies änderte lediglich die Reihenfolge, in der Felder zum Dokument hinzugefügt wurden. Vor dieser Änderung wurden _seq_no Felder zuletzt zum Dokument hinzugefügt. Anschließend wurden sie zuerst hinzugefügt. Die Reihenfolge beim Hinzufügen von Feldern zu einem Lucene-Dokument kann unmöglich diesen Fehler verursachen...

Ja, die Änderung der Reihenfolge beim Hinzufügen der Felder hat den Fehler verursacht. Das war überraschend und entpuppte sich als Fehler in Lucene selbst! Die Änderung der Reihenfolge, in der die Felder analysiert werden, sollte das Verhalten beim Parsen eines Dokuments nicht verändern.

Der Fehler in Lucene

Der Fehler in Lucene bezog sich tatsächlich auf folgende Bedingungen:

• Indizieren eines Punktewertfeldes (z. B. _seq_no)

• Beim Versuch, ein Textfeld zu indizieren, trat während der Analyse ein Fehler auf.

• In diesem ungewöhnlichen Zustand öffnen wir einen Near Real Time Reader des Autors, der die Textindexanalyse-Ausnahme erlebt.

Aber egal, wie viele Wege ich auch versucht habe, ich konnte es nicht vollständig nachbilden. Ich habe direkt Haltepunkte zum Debuggen im gesamten Lucene-Quellcode eingefügt. Ich habe versucht, während des Ausnahmepfads zufällig Reader zu öffnen. Ich habe sogar Megabytes über Megabytes an Protokolldateien ausgedruckt, um den genauen Pfad zu finden, an dem dieser Fehler aufgetreten ist. Ich konnte es einfach nicht. Ich habe einen ganzen Tag lang gekämpft und verloren.

Dann habe ich geschlafen.

Am nächsten Tag las ich den ursprünglichen Stacktrace erneut und entdeckte die folgende Zeile:

Bei all meinen Nachbildungsversuchen habe ich die Aufbewahrungs- und Zusammenführungsrichtlinie nie explizit festgelegt. Die SoftDeletesRetentionMergePolicy wird von Elasticsearch verwendet, um Löschungen in Replikaten genau zu replizieren und sicherzustellen, dass alle unsere Parallelitätskontrollen dafür zuständig sind, wann Dokumente tatsächlich entfernt werden. Andernfalls hat Lucene die volle Kontrolle und entfernt sie bei jedem Merge.

Nachdem ich diese Richtlinie hinzugefügt und die oben genannten grundlegendsten Schritte wiederholt hatte, trat der Fehler sofort wieder auf.

Ich habe mich noch nie so sehr gefreut, einen Fehler in Lucene zu melden.

Während sich dies in Elasticsearch als Race Condition darstellte, war es einfach, in Lucene einen wiederholt fehlschlagenden Test zu schreiben, sobald alle Bedingungen erfüllt waren.

Am Ende wurde es, wie alle guten Bugs, mit nur einer einzigen Codezeile behoben. Mehrere Tage Arbeit für nur eine einzige Codezeile.

Aber es hat sich gelohnt.

Nicht das Ende

Ich hoffe, ihr hattet Spaß an dieser turbulenten Reise mit mir! Software zu entwickeln, insbesondere so weit verbreitete und komplexe Software wie Elasticsearch und Apache Lucene, ist sehr lohnend. Manchmal ist es jedoch außerordentlich frustrierend. Ich liebe und hasse Software gleichermaßen. Die Fehlerbehebung hört nie auf!

Die Vektorsuche revolutioniert die Art und Weise, wie wir Ähnlichkeitssuchen durchführen, insbesondere in Bereichen wie KI und Machine Learning. Mit der zunehmenden Verbreitung von Vektoreinbettungsmodellen wird die Fähigkeit, Millionen von hochdimensionalen Vektoren effizient zu durchsuchen, immer wichtiger.

Bei der Energieversorgung von Vektordatenbanken haben Elastic und OpenSearch bemerkenswert unterschiedliche Ansätze gewählt. Elastic investierte stark in die Optimierung von Apache Lucene mit Elasticsearch, um sie zur erstklassigen Wahl für Vektorsuchanwendungen zu machen. Im Gegensatz dazu erweiterte OpenSearch seinen Fokus, indem es andere Implementierungen der Vektorsuche integriert und über den Rahmen von Lucene hinausgeht. Unser Fokus auf Lucene ist strategisch und ermöglicht es uns, in unserer Version von Elasticsearch hochintegrierten Support bereitzustellen, was zu einem erweiterten Funktionsumfang führt, bei dem jede Komponente die Fähigkeiten der anderen ergänzt und erweitert.

Dieser Blog bietet einen detaillierten Vergleich zwischen Elasticsearch 8.14 und OpenSearch 2.14, wobei verschiedene Konfigurationen und Vektor-Engines berücksichtigt werden. In dieser Leistungsanalyse hat sich Elasticsearch als die überlegene Plattform für Vektorsuchen erwiesen, und kommende Features werden die Unterschiede noch deutlicher machen. Als es gegen OpenSearch antrat, schnitt es in jedem Benchmark-Track hervorragend ab und bot im Durchschnitt eine 2 bis 12 Mal schnellere Leistung. Dies geschah in Szenarien mit unterschiedlichen Vektormengen und Dimensionen, einschließlich so_vector (2 Mio. Vektoren, 768D), openai_vector (2,5 Mio. Vektoren, 1536D) und dense_vector (10 Mio. Vektoren, 96D), die alle in diesem Repository neben den Terraform-Skripten zum Bereitstellen der gesamten erforderlichen Infrastruktur in Google Cloud und Kubernetes-Manifesten für die Ausführung der Tests verfügbar sind.

Die in diesem Blog beschriebenen Ergebnisse ergänzen die Ergebnisse einer zuvor veröffentlichten und von Dritten validierten Studie, die zeigt, dass Elasticsearch bei den gängigsten Suchanalyseoperationen um 40%–140% schneller ist als OpenSearch: bei Textabfrage, Sortierung, Bereich, Datumshistogramm und Begriffsfilterung. Jetzt können wir ein weiteres Unterscheidungsmerkmal hinzufügen: die Vektorsuche.

Bis zu 12 Mal schneller einsatzbereit

Unsere gezielten Benchmarks über die vier Vektordatensätze hinweg umfassten sowohl approximative kNN- als auch exakte kNN-Suchen, wobei unterschiedliche Größen, Dimensionen und Konfigurationen berücksichtigt wurden, was insgesamt 40.189.820 nicht zwischengespeicherte Suchanfragen ergab. Das Ergebnis: Elasticsearch ist bei der Vektorsuche bis zu 12 Mal schneller als OpenSearch und benötigt daher weniger Rechenressourcen.

Abbildung 1: Gruppierte Aufgaben für ANN und exaktes kNN in verschiedenen Kombinationen in Elasticsearch und OpenSearch.

Die Gruppen wie knn-10-100 bezeichnen eine kNN-Suche mit und . Bei der HNSW-Vektorsuche bestimmt die Anzahl der nächsten Nachbarn, die für einen Abfragevektor abgerufen werden sollen. Es wird angegeben, wie viele ähnliche Vektoren als Ergebnis gefunden werden sollen. legt die Anzahl der Kandidatenvektoren fest, die in jedem Segment abgerufen werden sollen. Mehr Kandidaten können die Genauigkeit erhöhen, erfordern jedoch mehr Rechenressourcen.

Wir haben auch mit verschiedenen Quantisierungstechniken getestet und Engine-spezifische Optimierungen genutzt. Die detaillierten Ergebnisse für jeden Track und jede Aufgabe und Vektor-Engine sind unten verfügbar.

Exaktes kNN und approximatives kNN

Beim Umgang mit unterschiedlichen Daten und Anwendungsfällen variiert der richtige Ansatz für die Vektorsuche. In diesem Blog verwenden alle als knn-* angegebenen Aufgaben wie knn-10-100 approximatives kNN und script-score-* beziehen sich auf exaktes kNN, aber was ist der Unterschied zwischen ihnen und warum ist das wichtig?

Im Wesentlichen ist bei der Verarbeitung umfangreicherer Datensätze die Methode des Approximativen K-Nearest-Neighbor (ANN) aufgrund ihrer überlegenen Skalierbarkeit die bevorzugte Methode. Für bescheidenere Datensätze, die möglicherweise einen Filterprozess erfordern, ist die exakte kNN-Methode ideal.

Exaktes kNN verwendet eine Brute-Force-Methode, die den Abstand zwischen einem Vektor und jedem anderen Vektor im Datensatz berechnet. Anschließend werden diese Abstände in eine Rangfolge gebracht, um die nächsten Nachbarn zu finden. Diese Methode gewährleistet zwar eine exakte Übereinstimmung, leidet aber bei großen, hochdimensionalen Datensätzen unter Problemen der Skalierbarkeit. Es gibt jedoch viele Fälle, in denen exaktes kNN benötigt wird:

• Neubewertung: In Szenarien mit lexikalischen oder semantischen Suchen, gefolgt von einer vektorbasierten Neubewertung, ist exaktes kNN unerlässlich. In einer Produktsuchmaschine können erste Suchergebnisse auf der Grundlage von Textabfragen (z. B. Schlüsselwörtern, Kategorien) gefiltert werden. Anschließend werden Vektoren, die mit den gefilterten Elementen verknüpft sind, für eine genauere Ähnlichkeitsbewertung verwendet.

• Personalisierung: Bei einer großen Anzahl von Nutzern, die jeweils durch eine relativ kleine Anzahl (z. B. 1 Million) unterschiedlicher Vektoren repräsentiert werden, wird die Sortierung des Indexes nach nutzerspezifischen Metadaten (z. B. user_id) und die Brute-Force-Bewertung mit Vektoren effizient. Dieser Ansatz ermöglicht personalisierte Empfehlungen oder die Bereitstellung von Inhalten basierend auf präzisen Vektorvergleichen, die auf die individuellen Nutzerpräferenzen zugeschnitten sind.

Exaktes kNN stellt sicher, dass das endgültige Ranking und die Empfehlungen basierend auf der Vektorähnlichkeit präzise und auf die Nutzerpräferenzen zugeschnitten sind.

Approximatives kNN (oder ANN) verwendet hingegen Methoden, um die Datensuche schneller und effizienter als exaktes kNN zu gestalten, insbesondere in großen, hochdimensionalen Datensätzen. Anstelle eines Brute-Force-Ansatzes, der den genauen kürzesten Abstand zwischen einer Abfrage und allen Punkten misst, was zu Berechnungs- und Skalierungsproblemen führt, verwendet ANN bestimmte Techniken, um die Indizes und Dimensionen durchsuchbarer Vektoren im Datensatz effizient neu zu strukturieren. Dies kann zwar zu einer leichten Ungenauigkeit führen, erhöht jedoch die Geschwindigkeit des Suchvorgangs erheblich und macht ihn zu einer effektiven Alternative für den Umgang mit großen Datensätzen.

In diesem Blog verwenden alle als knn-* bezeichneten Aufgaben wie knn-10-100 approximatives kNN und script-score-* beziehen sich auf exaktes kNN.

Testmethodik

Während Elasticsearch und OpenSearch hinsichtlich der API für BM25-Suchvorgänge ähnlich sind, da letzteres ein Fork von ersterem ist, trifft dies auf die Vektorsuche, die nach dem Fork eingeführt wurde, nicht zu. OpenSearch verfolgte einen anderen Ansatz als Elasticsearch in Bezug auf Algorithmen, indem es neben lucene zwei weitere Engines – nmslib und faiss – einführte, die jeweils über spezifische Konfigurationen und Einschränkungen verfügen (z. B. erlaubt nmslib in OpenSearch keine Filter, ein wesentliches Feature für viele Anwendungsfälle).

Alle drei Engines verwenden den Hierarchical Navigable Small World (HNSW)-Algorithmus, der effizient für die approximative Suche nach dem nächsten Nachbarn und besonders leistungsfähig beim Umgang mit hochdimensionalen Daten ist. Es ist wichtig zu beachten, dass faiss auch einen zweiten Algorithmus, ivf, unterstützt, aber da dafür ein Vortraining am Datensatz erforderlich ist, werden wir uns ausschließlich auf HNSW konzentrieren. Die Kernidee von HNSW besteht darin, die Daten in mehreren Schichten verbundener Graphen zu organisieren, wobei jede Schicht eine andere Granularität des Datensatzes darstellt. Das Suchen beginnt auf der obersten Ebene mit der gröbsten Ansicht und schreitet zu immer feineren Schichten fort, bis es die unterste Ebene erreicht.

Beide Suchmaschinen wurden unter identischen Bedingungen in einer kontrollierten Umgebung getestet, um faire Testbedingungen zu gewährleisten. Die angewandte Methode ähnelt diesem zuvor veröffentlichten Leistungsvergleich, mit dedizierten Node-Pools für Elasticsearch, OpenSearch und Rally. Das Terraform-Skript ist (neben allen Quellen) verfügbar, um einen Kubernetes-Cluster mit Folgendem bereitzustellen:

• 1 Node-Pool für Elasticsearch mit 3 e2-standard-32-Maschinen (128 GB RAM und 32 CPUs)

• 1 Node-Pool für OpenSearch mit 3 e2-standard-32-Maschinen (128 GB RAM und 32 CPUs)

• 1 Node-Pool für Rally mit 2 t2a-standard-16 Maschinen (64 GB RAM und 16 CPUs)

Jeder „Track“ (oder Test) wurde 10 Mal für jede Konfiguration ausgeführt, die unterschiedliche Engines, Konfigurationen und Vektortypen umfasste. Die Tracks haben Aufgaben, die sich je nach Track zwischen 1.000 und 10.000 Mal wiederholen. Wenn eine der Aufgaben in einem Track z. B. aufgrund einer Netzwerk-Zeitüberschreitung fehlschlug, wurden alle Aufgaben verworfen, sodass alle Ergebnisse Tracks darstellen, die ohne Probleme gestartet und beendet wurden. Alle Testergebnisse sind statistisch validiert, um sicherzustellen, dass Verbesserungen nicht zufällig sind.

Detaillierte Ergebnisse

Warum das 99. Perzentil und nicht die durchschnittliche Latenz vergleichen? Betrachten Sie ein hypothetisches Beispiel für die durchschnittlichen Hauspreise in einem bestimmten Viertel. Der Durchschnittspreis mag auf eine teure Gegend hindeuten, aber bei näherer Betrachtung stellt sich womöglich heraus, dass die meisten Häuser viel niedriger bewertet sind und nur einige wenige Luxusimmobilien den Durchschnittswert in die Höhe treiben. Dies verdeutlicht, dass der Durchschnittspreis das gesamte Spektrum der Hauswerte in der Gegend nicht unbedingt genau wiedergibt. Man kann das mit der Untersuchung von Reaktionszeiten vergleichen, bei denen der Durchschnittswert möglicherweise kritische Probleme verbirgt.

Aufgaben

• Approximatives kNN mit k:10, n:50

• Approximatives kNN mit k:10, n:100

• Approximatives kNN mit k:100, n:1000

• Approximatives kNN mit k:10, n:50 und Keyword-Filtern

• Approximatives kNN mit k:10, n:100 und Keyword-Filtern

• Approximatives kNN mit k:100, n:1000 und Keyword-Filtern

• Approximatives kNN mit k:10, n:100 in Verbindung mit Indizierung

• Exaktes kNN (Skriptergebnis)

Vektor-Engines

• lucene in Elasticsearch und OpenSearch, beide in Version 9.10

• faiss in OpenSearch

• nmslib in OpenSearch

Vektortypen

• hnsw in Elasticsearch und OpenSearch

• int8_hnsw in Elasticsearch (HNSW mit automatischer 8-Bit-Quantisierung: Link)

• sq_fp16 hnsw in OpenSearch (HNSW mit automatischer 16-Bit-Quantisierung: Link)

Vorkonfigurierte und gleichzeitige Segmentsuche

Wie Sie wahrscheinlich wissen, ist Lucene eine hochleistungsfähige Text-Suchmaschinen-Bibliothek, die in Java geschrieben wurde und als Rückgrat für viele Suchplattformen wie Elasticsearch, OpenSearch und Solr dient. Im Kern organisiert Lucene Daten in Segmente, die im Wesentlichen in sich geschlossene Indizes sind, mit denen Lucene Suchvorgänge effizienter ausführen kann. Wenn Sie also eine auf Lucene basierende Suchmaschine mit einer Suche beauftragen, wird Ihre Suche in diesen Segmenten entweder sequentiell oder parallel ausgeführt.

OpenSearch hat die gleichzeitige Segmentsuche als optionales Flag eingeführt und verwendet sie standardmäßig nicht. Sie müssen sie mit einer speziellen Indexeinstellung index.search.concurrent_segment_search.enabled, wie hier beschrieben, aktivieren und es gibt einige Einschränkungen.

Elasticsearch hingegen sucht standardmäßig gleichzeitig in Segmenten, daher berücksichtigen die Vergleiche, die wir in diesem Blog anstellen, neben den verschiedenen Vektor-Engines und Vektortypen auch die unterschiedlichen Konfigurationen:

• Elasticsearch ootb: Elasticsearch sofort einsatzbereit, mit gleichzeitiger Segmentsuche;

• OpenSearch ootb: ohne aktivierte gleichzeitige Segmentsuche;

• OpenSearch css: mit aktivierter gleichzeitiger Segmentsuche

Kommen wir nun zu einigen detaillierten Ergebnissen für jeden getesteten Vektordatensatz:

2,5 Millionen Vektoren, 1536 Dimensionen (openai_vector)

Beginnen wir mit dem einfachsten, aber hinsichtlich der Dimensionen auch größten Track, openai_vector – er verwendet den NQ-Datensatz, der mit Einbettungen angereichert ist, die mit dem Modell „text-embedding-ada-002“ von OpenAI generiert wurden. Dieser Track ist der einfachste, da er nur approximatives kNN testet und nur 5 Aufgaben hat. Er testet sowohl im Standalone-Modus (ohne Indizierung) als auch parallel zur Indizierung und verwendet sowohl einen einzelnen Client als auch 8 gleichzeitige Clients.

Aufgaben

• standalone-search-knn-10-100-multiple-clients: Suche in 2,5 Millionen Vektoren mit 8 Clients gleichzeitig, k:10 und n:100

• standalone-search-knn-100-1000-multiple-clients: Suche in 2,5 Millionen Vektoren mit 8 Clients gleichzeitig, k:100 und n:1000

• standalone-search-knn-10-100-single-client: Suche in 2,5 Millionen Vektoren mit einem einzigen Client, k:10 und n:100

• standalone-search-knn-100-1000-single-client: Suche in 2,5 Millionen Vektoren mit einem einzigen Client, k:100 und n:1000

• parallel-documents-indexing-search-knn-10-100: Suche in 2,5 Millionen Vektoren bei gleichzeitigem Indexieren von weiteren 100.000 Dokumenten, k:10 und n:100

Die durchschnittliche p99-Leistung ist unten aufgeführt:

Hier haben wir beobachtet, dass Elasticsearch zwischen 3 und 8 Mal schneller ist als OpenSearch, wenn es neben dem Indexieren auch eine Vektorsuche (d. h. Lesen und Schreiben) mit :10 und :100 durchführt, und ohne Indizierung für denselben k- und n-Wert 2 bis 3 Mal schneller ist. Bei :100 und :1000 (standalone-search-knn-100-1000-single-client und standalone-search-knn-100-1000-multiple-clients) ist Elasticsearch im Durchschnitt 2 bis 7 Mal schneller als OpenSearch.

Die detaillierten Ergebnisse zeigen die exakten Tickets und Vektor-Engines im Vergleich:

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969485

0,995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0,781445

0,784817

OpenSearch-2.14.0@lucene-hnsw

0,96519

0,995422

OpenSearch-2.14.0@faiss

0,984154

0,98049

OpenSearch-2.14.0@faiss-sq_fp16

0,980012

0,97721

OpenSearch-2.14.0@nmslib

0,982532

0,99832

10 Millionen Vektoren, 96 Dimensionen (dense_vector)

In dense_vector mit 10 Millionen Vektoren und 96 Dimensionen. Dies basiert auf dem Bilddatensatz DEEP1B von Yandex. Der Datensatz wird aus den ersten 10 Millionen Vektoren der „Beispieldaten“-Datei mit dem Namen learn.350M.fbin erstellt. Die Suchvorgänge verwenden Vektoren aus der Abfrage der Datei „Abfragedaten“public.10K.fbin.

Sowohl Elasticsearch als auch OpenSearch funktionieren bei diesen Daten sehr gut, insbesondere nach einer erzwungenen Zusammenführung, die normalerweise bei schreibgeschützten Indizes durchgeführt wird und der Defragmentierung des Index ähnelt, um eine einzige „Tabelle“ zu haben, in der gesucht werden kann.

Aufgaben

Jede Aufgabe wird mit 100 Anfragen aufgewärmt und dann werden 1000 Anfragen gemessen

• knn-search-10-100: Suche in 10 Millionen Vektoren, k:10 und n:100

• knn-search-100-1000: Suche in 10 Millionen Vektoren, k:100 und n:1000

• knn-search-10-100-force-merge: Suche in 10 Millionen Vektoren nach einer erzwungenen Zusammenführung, k:10 und n:100

• knn-search-100-1000-force-merge: Suche in 10 Millionen Vektoren nach einer erzwungenen Zusammenführung, k:100 und n:1000

• knn-search-100-1000-concurrent-with-indexing: Suche in 10 Millionen Vektoren bei gleichzeitiger Aktualisierung von 5 % des Datensatzes, k:100 und n:1000

• script-score-query: Exakte kNN-Suchen in 2000 spezifischen Vektoren.

Sowohl Elasticsearch als auch OpenSearch haben sich bei der ANN-Suche gut bewährt. Wenn der Index in knn-search-100-1000-force-merge und knn-search-10-100-force-merge zusammengeführt wird (d. h. nur ein Segment hat), schneidet OpenSearch bei der Verwendung von nmslib und faiss besser ab als die anderen, obwohl sie alle um die 15 ms und dicht beieinander liegen.

Wenn der Index in knn-search-10-100 und knn-search-100-1000 jedoch mehrere Segmente hat (eine typische Situation, in der ein Index Aktualisierungen seiner Dokumente erhält), hält Elasticsearch die Latenz bei etwa ~7 ms und ~16 ms, während alle anderen OpenSearch-Engines langsamer sind.

Auch wenn der Index gleichzeitig gesucht und beschrieben wird (knn-search-100-1000-concurrent-with-indexing), hält Elasticsearch die Latenz unter 15 ms (bei 13,8 ms) und ist damit fast 4 Mal schneller als OpenSearch im Standardmodus (49,3 ms) und auch dann noch schneller, wenn die gleichzeitige Segmentsuche aktiviert ist (17,9 ms). Dies ist aber zu nah, um von Bedeutung zu sein.

Bei exaktem kNN ist der Unterschied viel größer: Elasticsearch ist 6 Mal schneller als OpenSearch (~260 ms gegenüber ~1600 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969843

0,996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0,775458

0,840254

OpenSearch-2.14.0@lucene-hnsw

0,971333

0,996747

OpenSearch-2.14.0@faiss

0,9704

0,914755

OpenSearch-2.14.0@faiss-sq_fp16

0,968025

0,913862

OpenSearch-2.14.0@nmslib

0,9674

0,910303

2 Millionen Vektoren, 768 Dimensionen (so_vector)

Dieser Track,so_vector, stammt aus einem Bündel von StackOverflow-Beiträgen, die am 21. April 2022 heruntergeladen wurden. Er enthält nur Fragedokumente – alle Dokumente mit Antworten wurden entfernt. Jeder Fragentitel wurde mithilfe des Satztransformatormodells multi-qa-mpnet-base-cos-v1 in einen Vektor kodiert. Dieser Datensatz enthält die ersten 2 Millionen Fragen.

Im Gegensatz zum vorherigen Track enthält jedes Dokument hier neben Vektoren auch andere Felder, um Test-Features wie approximativer kNN mit Filterung und Hybridsuche zu unterstützen. nmslib für OpenSearch fehlt in diesem Test auffallend, da es keine Filter unterstützt.

Aufgaben

Jede Aufgabe wird mit 100 Anfragen aufgewärmt und dann werden 100 Anfragen gemessen. Beachten Sie, dass die Aufgaben der Einfachheit halber gruppiert wurden, da der Test 16 Suchtypen mal 2 verschiedene k-Werte mal 3 verschiedene n-Werte enthält.

• kNN-10-50: Suche in 2 Millionen Vektoren ohne Filter, k:10 und n:50

• knn-10-50-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:10 und n:50

• knn-10-50-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:10 und n:50

• knn-10-100: Suche in 2 Millionen Vektoren ohne Filter, k:10 und n:100

• knn-10-100-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:10 und n:100

• knn-10-100-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:10 und n:100

• knn-100-1000: Suche in 2 Millionen Vektoren ohne Filter, k:100 und n:1000

• knn-100-1000-filtered: Suche in 2 Millionen Vektoren mit Filtern, k:100 und n:1000

• knn-100-1000-after-force-merge: Suche in 2 Millionen Vektoren mit Filtern und nach einer erzwungenen Zusammenführung, k:100 und n:1000

• exact-knn: Exakte KNN-Suche mit und ohne Filter.

Elasticsearch ist in diesem Test durchweg schneller als OpenSearch, nur in zwei Fällen ist OpenSearch schneller, jedoch nicht viel (knn-10-100 und knn-100-1000). Aufgaben mit knn-10-50, knn-10-100 und knn-100-1000 in Kombination mit Filtern zeigen einen Unterschied von bis zu dem Siebenfachen (112 ms vs. 803 ms).

Die Leistung beider Lösungen scheint sich nach einem „force-merge“ verständlicherweise anzugleichen, wie knn-10-50-after-force-merge, knn-10-100-after-force-merge und knn-100-1000-after-force-merge zeigen. Bei diesen Aufgaben ist faiss schneller.

Die Leistung beim exakten kNN ist erneut sehr unterschiedlich, wobei Elasticsearch diesmal 13 Mal schneller ist als OpenSearch (~385 ms vs. ~5262 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0,986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0,9674

0,910303

0,976394

Elasticsearch und Lucene als klare Sieger

Bei Elastic entwickeln wir Apache Lucene und Elasticsearch ständig weiter, um sicherzustellen, dass wir die führende Vektordatenbank für Such- und Abrufanwendungsfälle bereitstellen können, einschließlich RAG (Retrieval-Augmented Generation). Unsere jüngsten Fortschritte haben die Leistung drastisch gesteigert und, aufbauend auf den Vorteilen von Lucene 9.10, die Vektorsuche noch schneller und platzsparender gemacht. In diesem Blog wurde eine Studie vorgestellt, die zeigt, dass Elasticsearch beim Vergleich aktueller Versionen bis zu 12 Mal schneller ist als OpenSearch.

Es ist erwähnenswert, dass beide Produkte dieselbe Version von Lucene verwenden (Versionshinweise zu Elasticsearch 8.14 und zu OpenSearch 2.14).

Das Innovationstempo bei Elastic wird nicht nur für unsere On-Prem- und Elastic Cloud-Kunden, sondern auch für diejenigen, die unsere zustandslose Plattform nutzen, noch mehr bieten. Features wie die Unterstützung der skalaren Quantisierung auf int4 werden mit strengen Tests angeboten, um sicherzustellen, dass Kunden diese Techniken ohne signifikanten Rückgang der Abrufe nutzen können, ähnlich wie bei unseren Tests für int8.

Die Effizienz der Vektorsuche wird aufgrund der Verbreitung von KI- und Machine Learning-Anwendungen allmählich zu einem unverzichtbaren Feature in modernen Suchmaschinen. Für Unternehmen, die nach einer leistungsstarken Suchmaschine suchen, die in der Lage ist, mit den Anforderungen an großvolumige, hochkomplexe Vektordaten Schritt zu halten, ist Elasticsearch die definitive Antwort.

Egal, ob Sie eine etablierte Plattform erweitern oder neue Projekte initiieren – die Integration von Elasticsearch für Vektorsuchen ist ein strategischer Schritt, der greifbare, langfristige Vorteile bringen wird. Mit seinem nachgewiesenen Leistungsvorteil ist Elasticsearch bereit, die nächste Welle von Innovationen im Bereich des Suchens zu unterstützen.

HNSW ist zwar eine leistungsstarke und flexible Methode zum Speichern und Durchsuchen von Vektoren, benötigt aber eine beträchtliche Menge an Speicherplatz, um schnell ausgeführt werden zu können. Beispielsweise benötigt die Abfrage von 1 Million float32-Vektoren mit 768 Dimensionen ungefähr RAM. Sobald man eine beträchtliche Anzahl von Vektoren durchsucht, wird dies teuer. Eine Möglichkeit, den Speicherverbrauch um etwa zu reduzieren, besteht in der Byte-Quantisierung. Lucene und folglich auch Elasticsearch unterstützen die Indizierung -Vektoren schon seit einiger Zeit, die Erstellung dieser Vektoren lag jedoch bisher in der Verantwortung des Benutzers. Das wird sich bald ändern, da wir in Lucene die Skalarquantisierung eingeführt haben.

Skalarquantisierung 101

Alle Quantisierungstechniken werden als verlustbehaftete Transformationen der Rohdaten betrachtet. Das bedeutet, dass aus Platzgründen einige Informationen verloren gehen. Eine ausführliche Erklärung der Skalarquantisierung finden Sie unter: Skalarquantisierung 101. Im Prinzip ist die Skalarquantisierung eine verlustbehaftete Kompressionstechnik. Durch einfache Berechnungen lassen sich erhebliche Speicherplatzeinsparungen erzielen, ohne dass die Speicherkapazität nennenswert beeinträchtigt wird.

Die Architektur erkunden

Wer bereits Erfahrung mit Elasticsearch hat, kennt diese Konzepte möglicherweise schon, aber hier ist ein kurzer Überblick über die Verteilung der Dokumente für die Suche.

Jeder Elasticsearch-Index besteht aus mehreren Shards. Obwohl jeder Shard nur einem einzigen Knoten zugewiesen werden kann, ermöglicht die Verwendung mehrerer Shards pro Index eine parallele Berechnung über mehrere Knoten hinweg.

Jeder Shard besteht aus einem einzelnen Lucene-Index. Ein Lucene-Index besteht aus mehreren schreibgeschützten Segmenten. Während der Indizierung werden Dokumente zwischengespeichert und regelmäßig in ein schreibgeschütztes Segment geschrieben. Wenn bestimmte Bedingungen erfüllt sind, können diese Segmente im Hintergrund zu einem größeren Segment zusammengeführt werden. Das alles ist konfigurierbar und birgt seine eigenen Komplexitäten. Wenn wir aber von Segmenten und deren Zusammenführung sprechen, meinen wir schreibgeschützte Lucene-Segmente und die automatische, periodische Zusammenführung dieser Segmente. Hier folgt ein detaillierterer Einblick in die Segmentzusammenführung und die damit verbundenen Designentscheidungen.

Quantisierung pro Segment in Lucene

Jedes Segment in Lucene speichert Folgendes: die einzelnen Vektoren, die HNSW-Graphindizes, die quantisierten Vektoren und die berechneten Quantile. Aus Gründen der Kürze konzentrieren wir uns darauf, wie Lucene quantisierte und rohe Vektoren speichert. Für jedes Segment erfassen wir die Rohvektoren in der Datei, die quantisierten Vektoren und einen einzelnen Korrekturmultiplikator (Gleitkommazahl) in sowie die Metadaten rund um die Quantisierung in der Datei.

Abbildung 1: Vereinfachtes Layout der Rohvektorspeicherdatei. Benötigt Speicherplatz in da 4 Byte groß sind. Da wir quantisieren, werden diese Daten während der HNSW-Suche nicht geladen. Sie werden nur auf ausdrücklichen Wunsch verwendet (z. B. Brute-Force-Sekundärverfahren mittels Rescore), oder zur erneuten Quantisierung während der Segmentzusammenführung.

Abbildung 2: Vereinfachtes Layout der Datei. Benötigt Speicherplatz und wird während der Suche in den Speicher geladen. Die Bytes dienen der Berücksichtigung des Korrekturmultiplikators, der zur Anpassung der Bewertung für eine bessere Genauigkeit und Trefferquote verwendet wird.

Abbildung 3: Vereinfachter Aufbau der Metadatendatei. Hier erfassen wir die Quantisierung und Vektorkonfiguration sowie die berechneten Quantile für dieses Segment.

Für jedes Segment speichern wir also nicht nur die quantisierten Vektoren, sondern auch die Quantile, die zur Erstellung dieser quantisierten Vektoren verwendet wurden, sowie die ursprünglichen Rohvektoren. Aber warum bewahren wir die Rohvektoren überhaupt auf?

Quantisierung, die mit Ihnen wächst

Da Lucene periodisch in schreibgeschützte Segmente schreibt, hat jedes Segment nur einen Teil Ihrer Daten zur Verfügung. Das bedeutet, dass die berechneten Quantile nur für diese Stichprobe Ihrer gesamten Daten direkt gelten. Das ist kein großes Problem, wenn Ihre Stichprobe Ihr gesamtes Korpus angemessen repräsentiert. Lucene ermöglicht es Ihnen jedoch, Ihren Index auf verschiedene Arten zu sortieren. Es könnte also vorkommen, dass die Daten so indiziert werden, dass sie so sortiert sind, dass dies zu Verzerrungen bei der Berechnung der Quantile pro Segment führt. Außerdem können Sie die Daten jederzeit löschen! Ihr Stichprobensatz kann winzig sein, sogar nur ein einziger Vektor. Ein weiterer Haken ist, dass Sie die Kontrolle darüber haben, wann Zusammenführungen erfolgen. Elasticsearch verfügt zwar über voreingestellte Standardwerte und eine regelmäßige Zusammenführung, Sie können aber jederzeit über die _force_merge -API eine Zusammenführung anfordern. Wie können wir also all diese Flexibilität ermöglichen und gleichzeitig eine gute Quantisierung mit guter Recall-Qualität gewährleisten?

Die Vektorquantisierung von Lucene passt sich im Laufe der Zeit automatisch an. Da Lucene mit einer Architektur für schreibgeschützte Segmente konzipiert ist, haben wir die Garantie, dass sich die Daten in jedem Segment nicht verändert haben, und klare Abgrenzungen im Code, wann Aktualisierungen möglich sind. Das bedeutet, dass wir während der Segmentzusammenführung die Quantile nach Bedarf anpassen und gegebenenfalls Vektoren neu quantisieren können.

Abbildung 4: Drei Beispielsegmente mit unterschiedlichen Quantilen.

Aber ist eine erneute Quantifizierung nicht teuer? Es verursacht zwar einen gewissen Mehraufwand, aber Lucene geht intelligent mit Quantilen um und führt nur dann eine vollständige Neuquantisierung durch, wenn dies erforderlich ist. Nehmen wir die Segmente in Abbildung 4 als Beispiel. Wir geben den Segmenten und jeweils Dokumente und Segment nur Dokumente. Lucene berechnet einen gewichteten Durchschnitt der Quantile. Wenn das resultierende zusammengeführte Quantil nahe genug an den ursprünglichen Quantilen des Segments liegt, muss das Segment nicht erneut quantisiert werden, sondern es werden die neu zusammengeführten Quantile verwendet.

Abbildung 5: Beispiel für zusammengeführte Quantile, wobei die Segmente und Dokumente enthalten und nur enthält.

In der in Abbildung 5 dargestellten Situation ist zu erkennen, dass die resultierenden zusammengeführten Quantile den ursprünglichen Quantilen in und sehr ähnlich sind. Daher rechtfertigen sie keine Quantisierung der Vektoren. Segment weicht anscheinend zu stark ab. Folglich würden die Vektoren in mit den neu zusammengeführten Quantilwerten erneut quantisiert.

Es gibt tatsächlich extreme Fälle, in denen die zusammengeführten Quantile dramatisch von allen ursprünglichen Quantilen abweichen. In diesem Fall werden wir aus jedem Segment eine Stichprobe entnehmen und die Quantile vollständig neu berechnen.

Quantisierungsleistung und Zahlen

Ist es also schnell und bietet es trotzdem noch eine gute Speicherkapazität? Die folgenden Zahlen wurden bei der Durchführung des Experiments auf einer c3-standard-8 GCP-Instanz ermittelt. Um einen fairen Vergleich mit zu gewährleisten, verwendeten wir eine ausreichend große Instanz, um Rohvektoren im Speicher zu halten. Wir haben Cohere Wiki- Vektoren mithilfe des Maximum-Skalarprodukts indiziert.

Abbildung 6: Recall@10 für quantisierte Vektoren im Vergleich zu Rohvektoren. Die Suchleistung von quantisierten Vektoren ist deutlich schneller als die von Rohvektoren, und der Recall kann schnell wiederhergestellt werden, indem nur 5 weitere Vektoren gesammelt werden; sichtbar durch .

Abbildung 6 veranschaulicht die Geschichte. Es gibt zwar einen Unterschied in der Erinnerungsleistung, wie zu erwarten war, dieser ist jedoch nicht signifikant. Und der Unterschied in der Trefferquote verschwindet bereits durch das Sammeln von nur 5 weiteren Vektoren. All dies bei schnellen Segmentzusammenführungen und nur einem Viertel des Speicherbedarfs von Vektoren.

Fazit

Lucene bietet eine einzigartige Lösung für ein schwieriges Problem. Für die Quantisierung ist kein „Trainings“- oder „Optimierungs“-Schritt erforderlich. In Lucene funktioniert es einfach. Sie müssen sich keine Sorgen machen, Ihren Vektorindex „neu trainieren“ zu müssen, falls sich Ihre Daten ändern. Lucene erkennt signifikante Änderungen und kümmert sich während der gesamten Lebensdauer Ihrer Daten automatisch darum. Wir freuen uns darauf, wenn wir diese Funktion in Elasticsearch integrieren!

Hintergrund

Bei der Entwicklung von Elasticsearch stoßen wir gelegentlich auf wichtige Probleme, für die es keine einfache oder etablierte Lösungsmethode gibt. Es liegt nahe zu fragen: „Hmm, gibt es dazu eine wissenschaftliche Arbeit?“ Manchmal ist die akademische Arbeit auch eine Quelle der Inspiration. Wir stoßen auf eine wissenschaftliche Arbeit, in der ein neuer Algorithmus oder eine neue Datenstruktur vorgeschlagen wird, und denken: „Das wäre so nützlich!“ Hier sind nur einige Beispiele dafür, wie Elasticsearch und Apache Lucene akademische Arbeiten integrieren:

• HyperLogLog++ für Kardinalitätsaggregationen

• C3-Algorithmus zur adaptiven Replikaauswahl

• Hierarchische navigierbare Small-World-Graphen (HNSW) für die Suche nach dem nächsten Vektor in Lucene

• MIC-Statistik zur Verbesserung der Klassifizierung durch maschinelles Lernen

• Block-max WAND für schnelleres Abrufen von Top-Hits in Lucene

• ... und viele mehr

Wissenschaftliche Artikel sind eine unschätzbare Ressource für Ingenieure, die datenintensive Systeme entwickeln. Doch ihre Umsetzung kann einschüchternd und fehleranfällig sein – Algorithmenbeschreibungen sind oft komplex, und wichtige praktische Details werden ausgelassen. Und das Testen stellt eine echte Herausforderung dar: Wie können wir beispielsweise einen Algorithmus für maschinelles Lernen gründlich testen, dessen Ausgabe stark vom Datensatz abhängt?

Bewerten Sie das Dokument wie eine Softwareabhängigkeit.

Das Hinzufügen einer neuen Softwareabhängigkeit erfordert eine sorgfältige Prüfung: Wenn das andere Paket fehlerhaft, langsam oder unsicher ist, könnte unser Projekt es auch sein. Bevor Entwickler eine Abhängigkeit einbinden, stellen sie sicher, dass sie deren Qualität bewerten.

Das Gleiche gilt für wissenschaftliche Arbeiten, deren Umsetzung Sie erwägen. Man könnte meinen, dass ein Algorithmus, nur weil er in einer wissenschaftlichen Arbeit veröffentlicht wurde, korrekt sein und gut funktionieren muss. Doch selbst wenn eine wissenschaftliche Arbeit den Begutachtungsprozess durchlaufen hat, kann sie Mängel aufweisen. Vielleicht beruht der Korrektheitsbeweis auf Annahmen, die nicht realistisch sind. Oder vielleicht zeigt der Abschnitt „Experimente“ eine deutlich bessere Performance als die Basislinie, aber das gilt nur für einen bestimmten Datensatz. Auch wenn die Arbeit von hoher Qualität ist, passt ihr Ansatz möglicherweise nicht zu Ihrem Projekt.

Wenn man darüber nachdenkt, ob man eine Abhängigkeit von einer wissenschaftlichen Arbeit eingehen sollte, ist es hilfreich, dieselben Fragen zu stellen, die man auch bei einem Softwarepaket stellen würde:

• Ist die Bibliothek weit verbreitet und „praxiserprobt“? → Haben andere Softwarepakete diese Arbeit bereits umgesetzt und hat sie sich dabei bewährt?

• Sind Leistungsvergleichswerte verfügbar? Erscheinen diese Angaben zutreffend und fair? → Enthält die Arbeit realistische Experimente? Sind sie gut gestaltet?

• Ist die Leistungsverbesserung groß genug, um die Komplexität zu rechtfertigen? → Lässt sich die Arbeit mit einem soliden Basisansatz vergleichen? Um wie viel übertrifft es diesen Vergleichswert?

• Lässt sich dieser Ansatz gut in unser System integrieren? → Passen die Annahmen und Abwägungen des Algorithmus zu unserem Anwendungsfall?

Seltsamerweise schneidet die Software, die in einem Leistungsvergleich mit der Konkurrenz auftritt, immer am schnellsten ab! Wenn die Benchmarks von einem Dritten entworfen wurden, sind sie möglicherweise ausgewogener. Das gleiche Phänomen trifft auch auf wissenschaftliche Arbeiten zu. Wenn ein Algorithmus nicht nur in der Originalveröffentlichung gut abschneidet, sondern auch in anderen Veröffentlichungen als starke Basislinie auftaucht, dann ist er mit hoher Wahrscheinlichkeit solide.

Werden Sie kreativ beim Testen

Algorithmen aus wissenschaftlichen Artikeln weisen oft ein komplexeres Verhalten auf als die Algorithmen, denen wir im Alltag begegnen. Vielleicht handelt es sich um einen Näherungsalgorithmus, der Genauigkeit gegen höhere Geschwindigkeit eintauscht. Oder vielleicht handelt es sich um eine Methode des maschinellen Lernens, die einen großen Datensatz verarbeitet und (manchmal unerwartete) Ergebnisse liefert. Wie können wir Tests für diese Algorithmen schreiben, wenn wir ihr Verhalten nicht auf einfache Weise charakterisieren können?

Fokus auf Invarianten

Beim Entwerfen von Unit-Tests ist es üblich, in Beispielen zu denken: Wenn wir dem Algorithmus diese Beispieleingabe geben, sollte er diese Ausgabe haben. Leider deckt das Testen anhand von Beispielen das Verhalten der meisten mathematischen Algorithmen nicht ausreichend ab.

Betrachten wir den C3-Algorithmus, den Elasticsearch verwendet, um herauszufinden, welcher Knoten eine Suchanfrage bearbeiten soll. Es bewertet jeden Knoten anhand einer differenzierten Formel, die die bisherigen Service- und Antwortzeiten des Knotens sowie seine Warteschlangengröße berücksichtigt. Das Testen einiger Beispiele bestätigt nicht wirklich, dass wir die Formel richtig verstanden haben. Es hilft, einen Schritt zurückzutreten und über Testinvarianten nachzudenken: Verringert sich der Rang des Knotens, wenn sich die Bedienzeit erhöht? Wird der Rang, wie in der Studie behauptet, durch die Antwortzeit bestimmt, wenn die Warteschlangenlänge 0 beträgt?

Die Konzentration auf Invarianten kann in einer Reihe häufiger Fälle hilfreich sein:

• Soll die Methode unabhängig von der Reihenfolge sein? In diesem Fall sollte die Übergabe der Eingabedaten in einer anderen Reihenfolge zum gleichen Ergebnis führen.

• Erzeugt ein Schritt im Algorithmus Klassenwahrscheinlichkeiten? In diesem Fall müssten sich diese Wahrscheinlichkeiten zu 1 addieren.

• Ist die Funktion symmetrisch um den Ursprung? In diesem Fall sollte das Umkehren des Vorzeichens des Eingangssignals einfach das Vorzeichen des Ausgangssignals umkehren.

Bei der ersten Implementierung von C3 hatten wir einen Fehler in der Formel, bei dem wir versehentlich den Kehrwert der Antwortzeit anstelle der Antwortzeit verwendet haben. Das bedeutete, dass langsamere Knoten höher eingestuft werden konnten! Bei der Behebung des Problems haben wir darauf geachtet, Invariantenprüfungen einzubauen, um zukünftigen Fehlern vorzubeugen.

Vergleich mit einer Referenzimplementierung

Zusammen mit der Veröffentlichung des Artikels haben die Autoren hoffentlich auch eine Implementierung des Algorithmus veröffentlicht. (Dies ist besonders wahrscheinlich, wenn die Arbeit Experimente enthält, da viele Fachzeitschriften von den Autoren die Veröffentlichung des Codes zur Reproduktion der Ergebnisse verlangen.) Sie können Ihren Ansatz anhand dieser Referenzimplementierung testen, um sicherzustellen, dass Sie keine wichtigen Details des Algorithmus übersehen haben.

Während der Entwicklung der HNSW-Implementierung von Lucene für die Nächste-Nachbarn-Suche haben wir diese anhand einer Referenzbibliothek der Autoren des Artikels getestet . Wir haben sowohl Lucene als auch die Bibliothek mit demselben Datensatz ausgeführt und die Genauigkeit ihrer Ergebnisse sowie die Anzahl der durchgeführten Berechnungen verglichen. Wenn diese Zahlen annähernd übereinstimmen, wissen wir, dass Lucene den Algorithmus korrekt implementiert.

Bei der Integration eines Algorithmus in ein System müssen oft Modifikationen oder Erweiterungen vorgenommen werden, wie z. B. die Skalierung auf mehrere Kerne oder das Hinzufügen von Heuristiken zur Leistungsverbesserung. Am besten implementiert man zunächst eine „Standardversion“, testet sie anhand der Referenz und nimmt dann schrittweise Änderungen vor. So können Sie sicher sein, dass Sie alle wichtigen Aspekte erfasst haben, bevor Sie Anpassungen vornehmen.

Duell gegen einen bestehenden Algorithmus

Im letzten Abschnitt wird eine weitere Idee für eine Testinvariante vorgestellt: der Vergleich der Ausgabe des Algorithmus mit der Ausgabe eines einfacheren und besser verstandenen Algorithmus. Nehmen wir beispielsweise den Block-Max-WAND-Algorithmus in Lucene, der die Dokumentensuche beschleunigt, indem er Dokumente überspringt, die nicht in den Top-Ergebnissen erscheinen können. Es ist schwierig, genau zu beschreiben, wie sich block-max WAND in jedem Fall verhalten sollte, aber wir wissen, dass die Anwendung die Top-Ergebnisse nicht verändern sollte! Unsere Tests können also mehrere zufällige Suchanfragen generieren, diese dann sowohl mit als auch ohne WAND-Optimierung ausführen und überprüfen, ob ihre Ergebnisse immer übereinstimmen.

Ein wichtiger Aspekt dieser Tests ist, dass sie zufällige Eingaben generieren, mit denen der Vergleich durchgeführt wird. Dies kann dabei helfen, Fälle durchzuspielen, an die man sonst nicht gedacht hätte, und unerwartete Probleme aufzudecken. Beispielsweise hat der randomisierte Vergleichstest von Lucene für die BM25F-Bewertung dazu beigetragen , Fehler in subtilen Grenzfällen aufzudecken. Die Idee, einen Algorithmus mit zufälligen Eingaben zu füttern, ist eng mit dem Konzept des Fuzzing verwandt, einer gängigen Testmethode in der Computersicherheit.

Elasticsearch und Lucene verwenden diesen Testansatz häufig. Wenn Sie einen Test sehen, der ein "Duell" zwischen zwei Algorithmen erwähnt (TestDuelingAnalyzers, testDuelTermsQuery...), dann wissen Sie, dass diese Strategie zum Einsatz kommt.

Verwenden Sie die im Artikel verwendete Terminologie.

Wenn ein anderer Entwickler mit Ihrem Code arbeitet, muss er die Dokumentation konsultieren, um die Details zu verstehen. Der Kommentar zur HyperLogLog++-Implementierung von Elasticsearch bringt es gut auf den Punkt: „Der Versuch, die Funktionsweise dieser Klasse zu verstehen, ohne das zugehörige Paper gelesen zu haben, gilt als abenteuerlich.“ Dieser Methodenkommentar ist ebenfalls ein gutes Beispiel. Es enthält einen Link zur wissenschaftlichen Arbeit und hebt hervor, welche Änderungen am Algorithmus im Vergleich zur ursprünglichen Beschreibung vorgenommen wurden.

Da die Entwickler ihr Verständnis des Codes auf dem Papier aufbauen, ist es hilfreich, genau dieselbe Terminologie zu verwenden. Da die mathematische Notation kurz und bündig ist, kann dies zu Namen führen, die im Allgemeinen nicht als „guter Stil“ gelten würden, im Kontext der Arbeit aber sehr verständlich sind. Formeln aus wissenschaftlichen Arbeiten gehören zu den wenigen Fällen, in denen man in Elasticsearch auf kryptische Variablennamen wie rS und muBarSInverse stößt.

Die vom Autor empfohlene Art, einen wissenschaftlichen Artikel zu lesen: mit einer großen Tasse Kaffee.

Sie können dem Autor eine E-Mail schreiben.

Bei der Bearbeitung einer schwierigen Hausarbeit kann es vorkommen, dass man stundenlang über einer Formel grübelt und sich nicht sicher ist, ob man sie falsch verstanden hat oder ob es sich nur um einen Tippfehler handelt. Wenn es sich um ein Open-Source-Projekt handeln würde, könnten Sie eine Frage auf GitHub oder StackOverflow stellen. Aber wo kann man eine wissenschaftliche Arbeit finden? Die Autoren scheinen beschäftigt zu sein und könnten von Ihren E-Mails genervt sein.

Im Gegenteil, viele Akademiker freuen sich, wenn sie hören, dass ihre Ideen in die Praxis umgesetzt werden, und beantworten gerne Fragen per E-Mail. Wenn Sie an einem Produkt arbeiten, mit dem sie vertraut sind, listen sie die Anwendung möglicherweise sogar auf ihrer Website auf!

Es gibt auch einen wachsenden Trend unter Akademikern, wissenschaftliche Arbeiten öffentlich zu diskutieren und dabei viele der gleichen Werkzeuge wie in der Softwareentwicklung zu verwenden. Wenn zu einer Veröffentlichung ein Softwarepaket gehört, finden Sie möglicherweise Antworten auf häufig gestellte Fragen auf GitHub. In den Stack Exchange-Communities „Theoretical Computer Science“ und „Cross Validated“ finden sich auch detaillierte Diskussionen über populärwissenschaftliche Artikel. Einige Konferenzen haben damit begonnen, alle Paper-Reviews online zu veröffentlichen. Diese Rezensionen beinhalten einen Dialog mit den Autoren, der hilfreiche Einblicke in den Ansatz ermöglichen kann.

Fortgesetzt werden

Dieser Beitrag konzentriert sich auf die Grundlagen der Auswahl einer wissenschaftlichen Arbeit und

Die Implementierung erfolgt zwar korrekt, deckt aber nicht alle Aspekte der tatsächlichen Bereitstellung des Algorithmus ab. Wenn der Algorithmus beispielsweise nur eine Komponente in einem komplexen System ist, wie können wir sicherstellen, dass Änderungen an dieser Komponente zu Verbesserungen des gesamten Systems führen? Und was ist, wenn die Integration des Algorithmus wesentliche Änderungen oder Erweiterungen erfordert, die in der Originalveröffentlichung nicht behandelt werden? Dies sind wichtige Themen, über die wir in zukünftigen Beiträgen gerne mehr berichten werden.