Aufbauend auf den Beispielen aus Teil 1 befasst sich dieser Blog damit, wie verschiedene Techniken und das leistungsstarke Toolkit zur Vektorsuche von Elasticsearch zur Bereitstellung später Interaktionsvektoren für umfassende Produktions-Workloads genutzt werden können.

Die vollständigen Code-Beispiele finden Sie auf GitHub.

Herausforderungen bei späten Interaktionsmodellen

ColPali erstellt über 1000 Vektoren pro Seite für die Dokumente in unserem Index.

Dies führt zu zwei Herausforderungen bei der Arbeit mit späten Interaktionsvektoren:

1. Speicherplatz: Das Speichern all dieser Vektoren auf Festplatten wird einen erheblichen Speicherplatzbedarf verursachen, was in großem Maßstab teuer wird.

2. Berechnung: Wenn wir unsere Dokumente mit dem maxSimDotProduct()-Vergleich bewerten, müssen wir alle diese Vektoren für jedes unserer Dokumente mit den N-Vektoren unserer Abfrage vergleichen.

Sehen wir uns einige Techniken zur Bewältigung dieser Probleme an.

Techniken zur Optimierung von späten Interaktionsmodellen

Bit-Vektoren

Um den Festplattenspeicher zu reduzieren, können wir die Bilder in Bitvektoren komprimieren. Wir können eine einfache Python-Funktion verwenden, um unsere Multivektoren in Bitvektoren umzuwandeln.

Das Kernkonzept der Funktion ist einfach: Werte über 0 werden zu 1 und Werte unter 0 werden zu 0. Daraus ergibt sich ein Array aus Nullen und Einsen, das wir dann in eine Hexadezimalzeichenfolge umwandeln, die unseren Bitvektor darstellt.

Für unser Index-Mapping setzen wir den Parameter element_type auf bit:

Nachdem wir alle unsere neuen Bitvektoren in unseren Index geschrieben haben, können wir unsere Bitvektoren mit folgendem Code bewerten:

Durch einen geringen Verlust an Genauigkeit können wir den Hamming-Abstand (maxSimInvHamming(...)) verwenden, wodurch Optimierungen wie Bitmasken oder SIMD genutzt werden können. Mehr über Bitvektoren und den Hamming-Abstand erfahren Sie in unserem Blog.

Alternativ können wir unseren Abfragevektor nicht in Bitvektoren umwandeln und mit dem vollwertigen späten Interaktionsvektor suchen:

Hierbei werden unsere Vektoren mithilfe einer asymmetrischen Ähnlichkeitsfunktion verglichen.

Betrachten wir den regulären Hamming-Abstand zwischen zwei Bitvektoren. Angenommen, wir haben einen Dokumentenvektor D:

Und ein Abfragevektor Q:

Eine einfache binäre Quantisierung transformiert Vektoren D in 10101101 und Q in 11111011. Um den Hamming-Abstand zu ermitteln, benötigen wir direkte Bit-Mathematik – die extrem schnell ist. In diesem Fall ist der Hamming-Abstand 01010110, was einer Bitanzahl von 4 entspricht. Das Scoring wird also zum Kehrwert dieses Hamming-Abstands. Denken Sie daran, dass ähnlichere Vektoren einen KLEINEREN Hamming-Abstand aufweisen, sodass durch die Umkehrung ähnlichere Vektoren eine höhere Bewertung erhalten können. Konkret wäre hier der Wert 1/4 = 0.25.

Beachten Sie jedoch, wie wir die Größenordnung jeder Dimension verlieren. Ein 1 ist ein 1. Für Q verschwindet also der Unterschied zwischen 0.01 und 0.79. Da wir lediglich gemäß >0 quantisieren, können wir einen kleinen Trick anwenden, bei dem der Q-Vektor nicht quantisiert wird. Dies ermöglicht zwar keine extrem schnellen Bitoperationen, hält aber die Speicherkosten niedrig, da D weiterhin quantisiert wird.

Das bedeutet, dass die in Q enthaltenen Informationen erhalten bleiben, wodurch die Qualität der Entfernungsschätzung verbessert und der Speicherbedarf gering gehalten wird.

Durch die Verwendung von Bitvektoren können wir bei der Abfragezeit deutlich an Festplattenspeicher und Rechenaufwand sparen. Aber wir können noch mehr tun.

Mittlere Vektoren

Um unsere Suche auf Hunderttausende von Dokumenten auszuweiten, reichen selbst die Leistungsvorteile, die Bitvektoren bieten, nicht aus. Für die Skalierung dieser Art von Workloads werden wir die HNSW-Indexstruktur von Elasticsearch für die Vektorsuche nutzen wollen.

ColPali generiert etwa tausend Vektoren pro Dokument. Das sind zu viele, um sie zu unserem HNSW-Graph hinzuzufügen. Daher müssen wir die Anzahl der Vektoren reduzieren. Dazu können wir eine einzige Repräsentation der Bedeutung des Dokuments erstellen, indem wir den Durchschnitt aller Dokumentvektoren bilden, die von ColPali beim Einbetten unseres Bildes erzeugt werden.

Aktuell ist das innerhalb von Elastic selbst nicht möglich, daher müssen wir die Vektoren vorverarbeiten, bevor wir sie in Elasticsearch ingestieren können.

Das ist mit Logstash- oder Ingest-Pipelines möglich, jedoch verwenden wir hier eine einfache Python-Funktion:

Außerdem normalisieren wir den Vektor, damit wir die Ähnlichkeit des Skalarprodukts verwenden können.

Nachdem wir alle unsere ColPali-Vektoren in mittlere Vektoren umgewandelt haben, können wir sie in unser dense_vector-Feld indexieren:

Wir müssen berücksichtigen, dass dadurch die gesamte Festplattennutzung erhöht wird, da wir neben unseren späten Interaktionsvektoren mehr Informationen speichern. Zusätzlich werden wir zusätzlichen RAM für den HNSW-Graphen verwenden, wodurch wir die Suche auf Milliarden von Vektoren skalieren können. Um den RAM-Verbrauch zu reduzieren, können wir unser beliebtes BBQ-Feature nutzen. Dadurch erhalten wir schnelle Suchergebnisse über enorme Datensätze, die sonst nicht möglich wären.

Jetzt suchen wir einfach mit der kNN-Abfrage, um unsere relevantesten Dokumente zu finden.

Das bisher beste Ergebnis ist leider auf Platz 3 abgerutscht.

Um dieses Problem zu beheben, können wir ein mehrstufiges Abrufen durchführen. Im ersten Schritt verwenden wir die kNN-Abfrage, um unter Millionen von Dokumenten die besten Kandidaten für unsere Abfrage zu suchen. Im zweiten Schritt ordnen wir nur die besten k (hier: 10) mit der höheren Genauigkeit der späten ColPali-Interaktionsmodelle neu. 

Hier verwenden wir den in 8.18 vorgestellten Rescore-Retriever zum Reranking unserer Ergebnisse. Nach dem Rescoring sehen wir, dass unser bester Treffer wieder an erster Stelle steht.

Hinweis: In einer Produktionsanwendung können wir einen viel höheren Wert für k als 10 verwenden, da die Max-Sim-Funktion immer noch vergleichsweise leistungsfähig ist.

Token-Pooling

Token-Pooling reduziert die Sequenzlänge von Multi-Vektor-Einbettungen, indem redundante Informationen wie weiße Hintergrund-Patches gepoolt werden. Diese Technik verringert die Anzahl der Einbettungen, während der Großteil des Seitensignals erhalten bleibt.

Token-Pooling funktioniert, indem ähnliche Token-Einbettungen innerhalb eines Dokuments mithilfe eines Clustering-Algorithmus in Cluster gruppiert werden. Anschließend wird der Mittelwert der Vektoren in jedem Cluster berechnet, um eine einzige, aggregierte Darstellung zu erzeugen. Dieser aggregierte Vektor ersetzt die ursprünglichen Token in der Gruppe und reduziert die Gesamtzahl der Vektoren ohne nennenswerten Verlust des Dokumentsignals.

Im ColPali-Paper wird für die meisten Datensätze ein anfänglicher Pooling-Faktor von 3 vorgeschlagen, der 97,8 % der ursprünglichen Leistung beibehält und gleichzeitig die Gesamtzahl der Vektoren um 66,7 % reduziert. 

Aber Vorsicht ist geboten: Der Datensatz „Shift“, der sehr dichte, textlastige Dokumente mit wenig Leerzeichen enthält, zeigt eine rapide Leistungsverschlechterung bei steigenden Poolfaktoren.

Um die gepoolten Vektoren zu erstellen, können wir die Bibliothek colpali_engine verwenden:

Wir haben nun einen Vektor, der in seinen Dimensionen um etwa 66,7 % reduziert wurde. Wir indexieren ihn wie üblich und können mit unserer maxSimDotProduct()-Funktion danach suchen.

Wir erzielen gute Suchergebnisse, auch wenn die Genauigkeit der Ergebnisse dadurch etwas beeinträchtigt wird.

Tipp: Mit einem höheren pool_factor (100–200) kann man auch einen Mittelweg zwischen der mittleren Vektorlösung und der hier besprochenen Lösung finden. Bei etwa 5–10 Vektoren pro Dokument ist es sinnvoll, diese in einem verschachtelten Feld zu indizieren, um den HNSW-Index optimal zu nutzen.

Cross-Encoder vs. späte Interaktion vs. Bi-Encoder

Auf Grundlage unserer bisherigen Erkenntnisse stellt sich die Frage: Wo ordnen sich späte Interaktionsmodelle wie ColPali oder ColBERT im Vergleich zu anderen KI-gestützten Retrieval-Techniken ein?

Obwohl die Max-Sim-Funktion im Vergleich zu Cross-Encodern günstiger ist, erfordert sie dennoch deutlich mehr Vergleiche und Berechnungen als die Vektorsuche mit Bi-Encodern, bei denen wir einfach zwei Vektoren für jedes Abfrage-Dokumentpaar vergleichen.

Aus diesem Grund empfehlen wir, späte Interaktionsmodelle generell nur für das Reranking der besten k-Suchergebnisse zu verwenden. Wir halten das auch im Namen des Feldtyps fest: rank_vectors.

Aber was ist mit dem Cross-Encoder? Sind späte Interaktionsmodelle besser, weil sie zum Zeitpunkt der Abfrage günstiger auszuführen sind? Wie so oft lautet die Antwort: Es kommt darauf an. Cross-Encoder liefern in der Regel qualitativ hochwertigere Ergebnisse, sind aber sehr rechenintensiv, da die abgefragten Dokumentenpaare das Transformatormodell vollständig durchlaufen müssen. Sie profitieren außerdem davon, dass sie keine Indizierung von Vektoren erfordern und zustandslos arbeiten können. Dies führt zu Folgendem:

• Weniger verwendeter Festplattenspeicher

• Ein einfacheres System

• Höhere Qualität der Suchergebnisse

• Höhere Latenz und daher keine Möglichkeit, ein umfassendes Reranking vorzunehmen

Andererseits können späte Interaktionsmodelle einen Teil dieser Berechnungen beim Indizieren auslagern, wodurch die Abfrage kostengünstiger wird. Der Preis, den wir dafür zahlen, ist, dass wir die Vektoren indizieren müssen, was unsere Indizierungspipelines komplexer macht und auch mehr Festplattenspeicher zum Speichern dieser Vektoren erfordert.

Insbesondere im Fall von ColPali ist die Analyse von Informationen aus Bildern sehr teuer, da sie viele Daten enthalten. In diesem Fall verschiebt sich der Kompromiss zugunsten eines späten Interaktionsmodells wie ColPali, da die Bewertung dieser Informationen zur Abfragezeit zu ressourcenintensiv bzw. zu langsam wäre.

Bei einem späten Interaktionsmodell wie ColBERT, das wie die meisten Cross-Encoder (z. B. elastic-rerank-v1) mit Textdaten arbeitet, könnte die Entscheidung eher zugunsten des Cross-Encoders ausfallen, um von den Festplattenspeicherersparnissen und der Einfachheit zu profitieren.

Wir empfehlen Ihnen, die Vor- und Nachteile für Ihren Anwendungsfall abzuwägen und mit den verschiedenen Tools von Elasticsearch zu experimentieren, um die besten Suchanwendungen zu entwickeln.

Fazit

In diesem Blog befassen wir uns mit verschiedenen Techniken zur Optimierung von späten Interaktionsmodellen wie ColPali für umfassende Vektorsuche in Elasticsearch. Während späte Interaktionsmodelle ein gutes Gleichgewicht zwischen Retrieval-Effizienz und Ranking-Qualität bieten, bringen sie auch Herausforderungen in Bezug auf Speicher und Berechnung mit sich.

Für die Bewältigung dieser Herausforderungen haben wir Folgendes untersucht:

• Bitvektoren zur deutlichen Reduzierung des Festplattenspeichers bei gleichzeitiger Nutzung effizienter Ähnlichkeitsberechnungen wie dem Hamming-Abstand oder der asymmetrischen maximalen Ähnlichkeit.

• Mittlere Vektoren zur Komprimierung mehrerer Einbettungen in eine einzige dichte Darstellung, wodurch ein effizientes Abrufen mit HNSW-Indizierung ermöglicht wird.

• Token-Pooling zur intelligenten Zusammenführung redundanter Einbettungen unter Beibehaltung der semantischen Integrität, wodurch der Rechenaufwand zum Zeitpunkt der Abfrage reduziert wird.

Elasticsearch bietet ein leistungsstarkes Toolkit zur Anpassung und Optimierung von Suchanwendungen gemäß Ihren Anforderungen. Unabhängig davon, ob Sie Retrieval-Geschwindigkeit, Ranking-Qualität oder Speichereffizienz priorisieren – mit diesen Tools und Techniken können Sie die Leistung und Qualität entsprechend den Anforderungen Ihrer Anwendungen in der Praxis aufeinander abstimmen.

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.

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!

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!