Unser Ziel war es, zu einem automatisierten, adaptiven Ansatz überzugehen, der sowohl Log-Parsing (Feldextraktion) als auch Log-Partitionierung (Quellenidentifikation) bewältigen kann. Wir vermuteten, dass Large Language Models (LLMs) mit ihrem inhärenten Verständnis von Codesyntax und semantischen Mustern diese Aufgaben mit minimalem menschlichem Eingreifen automatisieren könnten.

Wir freuen uns, Ihnen mitteilen zu können, dass dieses Feature bereits in Streams verfügbar ist!

Beschreibung des Datensatzes

Wir haben für PoC-Zwecke eine Loghub-Sammlungvon Logs gewählt. Für unsere Untersuchung wählten wir repräsentative Stichproben aus den folgenden Schlüsselbereichen aus:

• Verteilte Systeme: Wir verwendeten die HDFS- (Hadoop Distributed File System) und Spark-Datensätze. Diese enthalten eine Mischung aus Info-, Fehlerbehebungs- und Fehlermeldungen, die für Big Data-Plattformen typisch sind.

• Server- und Webanwendungen: Logs von Apache-Webservern und OpenSSH boten eine wertvolle Quelle für Zugriffs-, Fehler- und sicherheitsrelevante Ereignisse. Diese sind entscheidend für die Überwachung des Webverkehrs und die Erkennung potenzieller Bedrohungen.

• Betriebssysteme: Wir haben Protokolle von Linux und Windows aufgenommen. Diese Datensätze repräsentieren die üblichen, semistrukturierten Ereignisse auf Systemebene, denen Betriebsteams täglich begegnen.

• Mobile Systeme: Um sicherzustellen, dass unser Modell auch Logs aus mobilen Umgebungen verarbeiten kann, haben wir den Android-Datensatz mit einbezogen. Diese Logs sind oft ausführlich und erfassen eine Vielzahl von Aktivitäten auf Anwendungs- und Systemebene auf Mobilgeräten.

• Supercomputer: Um die Leistung in Hochleistungs-Computing-Umgebungen (HPC) zu testen, haben wir den BGL-Datensatz (Blue Gene/L) integriert, der hochstrukturierte Logs mit spezifischer Domänenterminologie enthält.

Ein entscheidender Vorteil der Loghub-Sammlung ist, dass die Logs größtenteils unsaniert und unbeschriftet sind, was eine geräuschvolle Live-Produktionsumgebung mit Microservice-Architektur widerspiegelt.

Log-Beispiele:

Zusätzlich haben wir einen Kubernetes-Cluster mit einer typischen Webanwendung und Datenbank erstellt, die zusätzliche Logs in der gängigsten Domäne sammelt.

Beispiel für gängige Logfelder: Zeitstempel, Log-Ebene (INFO, WARN, FEHLER), Quelle, Nachricht.

Few-Shot-Log-Parsing mit einem LLM

Unsere erste Reihe von Experimenten konzentrierte sich auf eine grundlegende Frage: Kann ein LLM zuverlässig Schlüsselfelder identifizieren und konsistente Parsing-Regeln erzeugen, um sie zu extrahieren?

Wir haben ein Modell gebeten, rohe Log-Stichproben zu analysieren und Log-Parsing-Regeln im regulären Ausdruck (Regex) und im Grok-Format zu generieren. Unsere Ergebnisse zeigten, dass dieser Ansatz großes Potenzial hat, aber auch erhebliche Herausforderungen bei der Implementierung.

Hohe Zuverlässigkeit und Kontextbewusstsein

Die ersten Ergebnisse waren vielversprechend. Das LLM zeigte eine starke Fähigkeit, Parsing-Regeln zu generieren, die mit hoher Wahrscheinlichkeit zu den bereitgestellten Beispielen passten. Neben der einfachen Mustererkennung zeigte das Modell die Fähigkeit zum Log-Verständnis – es konnte die Log-Quelle (z. B. Gesundheits-Tracking-App, Nginx-Web-App, Mongo-Datenbank) korrekt identifizieren und benennen.

Das „Goldlöckchen“-Dilemma der Eingabestichproben

Unsere Experimente zeigten schnell einen erheblichen Mangel an Robustheit aufgrund der extremen Empfindlichkeit gegenüber der Eingabestichprobe. Die Leistung des Modells schwankt stark in Abhängigkeit von den spezifischen Log-Beispielen, die im Prompt enthalten sind. Wir haben ein Log-Ähnlichkeitsproblem beobachtet, bei dem die Log-Stichprobe gerade ausreichend unterschiedliche Logs enthalten muss:

• Zu homogen (Overfitting): Wenn die Eingabe-Logs zu ähnlich sind, neigt das LLM dazu, zu überspezifizieren. Es behandelt variable Daten – wie spezifische Java-Klassennamen in einem Stack-Trace – als statische Teile der Vorlage. Das Ergebnis sind spröde Regeln, die nur einen winzigen Teil der Logs abdecken und unbrauchbare Felder extrahieren.

• Zu heterogen (Verwirrung): Umgekehrt, wenn die Stichprobe erhebliche Formatierungsunterschiede enthält – oder schlimmer noch, „Müll-Logs“ wie Fortschrittsbalken, Speichertabellen oder ASCII-Art – kämpft das Modell damit, einen gemeinsamen Nenner zu finden. Oftmals greift man dabei auf die Generierung komplexer, fehlerhafter regulärer Ausdrücke zurück oder verallgemeinert die gesamte Zeile vorschnell zu einem einzigen Nachrichten-Feld.

Die Einschränkung des Kontextfensters

Wir sind außerdem auf einen Engpass im Kontextfenster gestoßen. Wenn die Eingabe-Logs lang, heterogen oder reich an extrahierbaren Feldern waren, verschlechterte sich oft die Ausgabe des Modells und wurde „unübersichtlich“ oder zu lang, um in das Ausgabekontextfenster zu passen. Natürlich hilft Chunking in diesem Fall. Durch das Aufteilen von Protokollen mithilfe zeichenbasierter und entitätsbasierter Trennzeichen könnten wir dem Modell helfen, sich auf das Extrahieren der Hauptfelder zu konzentrieren, ohne von Rauschen überwältigt zu werden.

Die Konsistenz- und Standardisierungslücke

Selbst wenn das Modell erfolgreich Regeln generierte, stellten wir leichte Inkonsistenzen fest:

• Namensvariationen für Dienste: Das Modell schlägt unterschiedliche Namen für dieselbe Entität vor (z. B. wird die Quelle in verschiedenen Ausführungen als „Spark“, „Apache Spark“ und „Spark log Analytics“ bezeichnet).

• Variationen bei der Feldbenennung: Es fehlte an Standardisierung bei den Feldnamen (z. B. id vs. service.id vs. device.id). Wir haben Namen mithilfe einer standardisierten Elastic-Feldbenennung normalisiert.

• Auflösungsvarianz: Die Auflösung der Feldextraktion variierte je nachdem, wie ähnlich die Eingabe-Logs einander waren.

Log-Format-Fingerprint

Um die Herausforderung der Log-Ähnlichkeit anzugehen, führen wir eine leistungsstarke Heuristik ein: Log-Format-Fingerprint (LFF).

Anstatt rohe, verrauschte Logs direkt in ein LLM einzuspeisen, wenden wir zunächst eine deterministische Transformation an, um die zugrundeliegende Struktur jeder Nachricht zu enthüllen. Dieser Vorverarbeitungsschritt abstrahiert variable Daten und generiert einen vereinfachten „Fingerabdruck“, der es uns ermöglicht, verwandte Logs zu gruppieren.

Die Mapping-Logik ist einfach, um Geschwindigkeit und Konsistenz zu gewährleisten:

1. Ziffernabstraktion: Jede Ziffernfolge (0–9) wird durch eine einzelne „0“ ersetzt.

2. Textabstraktion: Jede Folge von alphabetischen Zeichen mit Leerzeichen wird durch ein einzelnes „a“ ersetzt.

3. Normalisierung von Leerzeichen: Alle Sequenzen von Leerzeichen (Leerzeichen, Tabulatoren, Zeilenumbrüche) werden zu einem einzigen Leerzeichen zusammengefasst.

4. Symbolerhaltung: Zeichensetzung und Sonderzeichen (z. B. :, [, ], /) werden beibehalten, da sie oft die stärksten Indikatoren für die Log-Struktur sind.

Wir stellen den Log-Mapping-Ansatz vor. Die grundlegenden Mapping-Muster umfassen Folgendes:

• Ziffern 0–9 von beliebiger Länge -> auf „0“.

• Text (alphabetische Zeichen mit Leerzeichen) von beliebiger Länge -> auf „a“.

• Leerzeichen, Tabulatoren und neue Zeilen -> auf ein einzelnes Leerzeichen.

Schauen wir uns ein Beispiel an, wie uns dieses Mapping die Transformation der Logs ermöglicht.

Dadurch erhalten wir folgende Log-Masken:

Beachten Sie die Fingerabdrücke der ersten beiden Logs. Trotz unterschiedlicher Zeitstempel, Quellklassen und Nachrichteninhalte sind ihre Präfixe (0/0/0 0:0:0 a a.a:) identisch. Durch diese strukturelle Ausrichtung können wir diese Logs automatisch in denselben Cluster einordnen.

Das dritte Log erzeugt jedoch einen völlig abweichenden Fingerabdruck (0-0-0...). Dies ermöglicht es uns, es algorithmisch von der ersten Gruppe zu trennen, bevor wir überhaupt ein LLM aufrufen.

Bonus: Sofortige Implementierung mit ES|QL

Es ist so einfach wie das Übergeben dieser Abfrage in Discover.

Abfrage-Aufschlüsselung:

FROM LogHub: Zielt auf unseren Index mit den Rohprotokolldaten ab.

EVAL Muster = …: Die Kern-Mapping-Logik. Wir verketten REPLACE-Funktionen, um die Abstraktion durchzuführen (z. B. Ziffern zu '0', Text zu 'a' usw.) und speichern das Ergebnis in einem „Muster“-Feld.

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15):

Dies ist ein Clustering-Schritt. Wir gruppieren Protokolle, die die ersten 15 Zeichen ihres Musters gemeinsam haben, und erstellen aggregierte Felder wie die Gesamtzahl der Protokolle pro Gruppe, eine Liste der Protokoll-Datenquellen, das Musterpräfix und 3 Protokollbeispiele.

SORT total_count DESC | LIMIT 100 : Zeigt die 100 häufigsten Log-Muster an

Die Abfrageergebnisse auf LogHub werden unten angezeigt:

Wie in der Visualisierung gezeigt, partitioniert dieser „LLM-freie“ Ansatz Protokolle mit hoher Genauigkeit. Es gelang ihm, 10 von 16 Datenquellen (basierend auf LogHub-Labels) vollständig zu clustern (>90 %), und er erreichte ein Mehrheits-Clustering in 13 von 16 Quellen (>60 %) – alles ohne zusätzliche Reinigung, Vorverarbeitung oder Feinabstimmung.

Log-Format-Fingerprinting bietet eine pragmatische, wirkungsvolle Alternative und Ergänzung zu ausgefeilten ML-Lösungen wie der Log-Pattern-Analyse. Es bietet sofortige Einblicke in die Zusammenhänge der Logs und verwaltet große Log-Cluster effektiv.

• Vielseitigkeit als Grundform

Dank ES|QL-Implementierung dient LFF sowohl als eigenständiges Werkzeug für schnelle Datendiagnostik/-visualisierungen als auch als Baustein in Loganalyse-Pipelines für Anwendungsfälle mit hohem Volumen.

• Flexibilität

LFF lässt sich leicht anpassen und erweitern, um spezifische Muster zu erfassen, z. B. hexadezimale Zahlen und IP-Adressen.

• Deterministische Stabilität

Im Gegensatz zu ML-basierten Clustering-Algorithmen ist die LFF-Logik geradlinig und deterministisch. Neue eingehende Logs wirken sich nicht rückwirkend auf bestehende Log-Cluster aus.

• Leistung und mMemory

Es benötigt nur minimalen Speicher, kein Training und keine GPU und ist daher ideal für Echtzeit-Umgebungen mit hohem Durchsatz geeignet.

Kombination des Log-Format-Fingerprints mit einem LLM

Zur Validierung der vorgeschlagenen hybriden Architektur enthielt jedes Experiment eine zufällige 20%ige Teilmenge der Logs aus jeder Datenquelle. Diese Einschränkung simuliert eine reale Produktionsumgebung, in der Logs in Batches und nicht als monolithischer historischer Dump verarbeitet werden.

Das Ziel war zu demonstrieren, dass LFF als effektive Kompressionsschicht fungiert. Wir wollten beweisen, dass Parsing-Regeln mit hoher Abdeckung aus kleinen, kuratierten Stichproben generiert und erfolgreich auf den gesamten Datensatz verallgemeinert werden können.

Ausführungspipeline

Wir haben eine mehrstufige Pipeline implementiert, die die Daten filtert, gruppiert und stratifizierte Stichproben auf sie anwendet, bevor sie das LLM erreichen.

1. Zweistufiges hierarchisches Clustering

• Unterklassen (exakte Übereinstimmung): Logs werden anhand identischer Fingerabdrücke aggregiert. Alle Logs einer Unterklasse haben exakt die gleiche Formatstruktur.

• Ausreißerbereinigung. Wir verwerfen alle Unterklassen, die weniger als 5 % des gesamten Logvolumens ausmachen. Dadurch wird sichergestellt, dass sich das LLM auf das dominante Signal konzentriert und nicht durch Rauschen oder fehlerhafte Logs abgelenkt wird.

• Metaklassen (Präfixübereinstimmung): Verbleibende Unterklassen werden in Metaklassen nach den ersten N Zeichen der Format-Fingerabdruckübereinstimmung gruppiert. Wir haben N=5 für das Log-Parsing und N=15 für die Log-Partitionierung gewählt, wenn die Datenquellen unbekannt sind.

2. Stratifiziertes Sampling. Sobald der hierarchische Baum erstellt ist, erstellen wir die Log-Stichprobe für das LLM. Das strategische Ziel ist es, die Varianzabdeckung zu maximieren und gleichzeitig die Verwendung von Token zu minimieren.

• Wir wählen repräsentative Logs aus jeder gültigen Unterklasse innerhalb der breiteren Metaklasse aus.

• Um einen Randfall mit zu vielen Unterklassen zu managen, wenden wir zufälliges Downsampling an, um die Zielfenstergröße anzupassen.

3. Regelgenerierung. Abschließend fordern wir das LLM auf, eine Regex-Parsing-Regel zu generieren, die auf alle Logs in der bereitgestellten Stichprobe für jede Metaklasse zutrifft. Für unseren PoC haben wir das Modell GPT-4o Mini verwendet.

Experimentelle Ergebnisse und Beobachtungen

Wir haben auf dem Loghub-Datensätze eine Parsing-Genauigkeit von 94 % und eine Partitionierungs-Genauigkeit von 91 % erreicht.

Die obige Konfusionsmatrix veranschaulicht die Ergebnisse der Log-Partitionierung. Die vertikale Achse stellt die tatsächlichen Datenquellen dar, die horizontale Achse die vorhergesagten Datenquellen. Die Intensität der Heatmap entspricht dem Log-Volumen, wobei leichtere Kacheln auf eine höhere Anzahl hinweisen. Die diagonale Ausrichtung zeigt die hohe Genauigkeit des Modells bei der Quellenzuweisung mit minimaler Streuung.

Einblicke aus unseren Leistungsvergleichsanalysen:

• Optimale Ausgangsbasis: Ein Kontextfenster von 30 bis 40 Log-Stichproben pro Kategorie erwies sich als der „Sweet Spot“, der sowohl mit Regex- als auch mit Grok-Mustern durchweg ein robustes Parsing ermöglichte.

• Eingabeminimierung: Wir haben die Eingabegröße für Regex-Muster auf 10 Logs pro Kategorie erhöht und nur einen 2%igen Rückgang der Parsing-Leistung festgestellt, was bestätigt, dass diversitätsbasierte Stichproben kritischer sind als das rohe Volumen.

Filter und Facetten im Vergleich

Bevor wir beginnen, definieren wir zunächst, was Filter und Facetten sind. Filter sind vordefinierte Attribute, die verwendet werden, um eine Reihe von Ergebnissen einzuschränken. Auf einem Marktplatz stehen beispielsweise Filter schon vor der eigentlichen Suche zur Verfügung. Der Benutzer kann vor der Suche nach „PS5“ eine Kategorie auswählen, zum Beispiel „Videospiele“, und so die Suche auf eine spezifischere Teilmenge anstatt der gesamten Datenbank eingrenzen. Dadurch erhöhen sich die Chancen auf relevantere Ergebnisse erheblich.

Facetten funktionieren ähnlich wie Filter, sind aber erst nach der Durchführung der Suche verfügbar. Mit anderen Worten: Die Suche liefert Ergebnisse, und auf deren Grundlage wird eine neue Liste von Verfeinerungsoptionen generiert. Bei der Suche nach einer PS5-Konsole werden beispielsweise Aspekte wie Speicherkapazität, Versandkosten und Farbe angezeigt, um den Nutzern bei der Auswahl des idealen Produkts zu helfen.

Nachdem wir nun Filter und Facetten definiert haben, wollen wir die Auswirkungen der klassischen und der auf maschinellem Lernen (ML) basierenden Ansätze auf ihre Implementierung und Verwendung erörtern. Jede Methode hat Vor- und Nachteile, die die Effizienz der Suche beeinflussen.

Klassischer Ansatz für Filter und Facetten

Bei diesem Ansatz werden Filter und Facetten manuell anhand vordefinierter Regeln definiert. Dies bedeutet, dass die zur Verfeinerung der Suche verfügbaren Attribute festgelegt und im Voraus geplant sind, wobei die Katalogstruktur und die Bedürfnisse der Nutzer berücksichtigt werden.

Auf einem Marktplatz können beispielsweise Kategorien wie „Elektronik“ oder „Mode“ über spezifische Filter wie Marke, Format und Preisspanne verfügen. Diese Regeln werden statisch erstellt, um eine einheitliche Sucherfahrung zu gewährleisten, erfordern jedoch manuelle Anpassungen, sobald neue Produkte oder Kategorien auftauchen.

Obwohl dieser Ansatz Vorhersagbarkeit und Kontrolle über die angezeigten Filter und Facetten bietet, kann er an seine Grenzen stoßen, wenn neue Trends entstehen, die eine dynamische Anpassung erfordern.

Vorteile:

• Vorhersagbarkeit und Kontrolle: Da Filter und Facetten manuell definiert werden, wird die Verwaltung einfacher.

• Geringe Komplexität: Es müssen keine Modelle trainiert werden.

• Wartungsfreundlichkeit: Da die Regeln vordefiniert sind, können Anpassungen und Korrekturen schnell vorgenommen werden.

Nachteile:

• Neuindizierung für neue Filter erforderlich: Wenn ein neues Attribut als Filter verwendet werden soll, muss der gesamte Datensatz neu indiziert werden, um sicherzustellen, dass die Dokumente diese Information enthalten.

• Fehlende dynamische Anpassung: Filter sind statisch und passen sich nicht automatisch an Änderungen im Nutzerverhalten an.

Implementierung von Filtern/Facetten – Klassischer Ansatz

In Dev Tools, Kibana, werden wir eine Demonstration von Filtern/Facetten mit dem klassischen Ansatz erstellen.

Zuerst definieren wir die Zuordnung zur Strukturierung des Index:

Die Felder „Marke“ und „Speicherort “ sind als Schlüsselwort festgelegt, sodass sie direkt in Aggregationen (Facetten) verwendet werden können. Das Preisfeld ist vom Typ Float, wodurch die Erstellung von Preisspannen ermöglicht wird.

Im nächsten Schritt werden die Produktdaten indexiert:

Nun wollen wir klassische Aspekte herausfiltern, indem wir die Ergebnisse nach Marke, Speicherort und Preisspanne gruppieren. In der Abfrage wurde Größe:0 definiert. In diesem Szenario besteht das Ziel darin, nur die Aggregationsergebnisse abzurufen, ohne die Dokumente einzubeziehen, die der Abfrage entsprechen.

Die Antwort wird Zählungen für Marke, Lager und Preis enthalten und so zur Erstellung von Filtern und Facetten beitragen.

Ansatz, der auf Machine Learning/KI basiert, für Filter und Facetten

Bei diesem Ansatz analysieren Modelle des maschinellen Lernens (ML), einschließlich Techniken der künstlichen Intelligenz (KI), Datenattribute, um relevante Filter und Facetten zu generieren. Anstatt sich auf vordefinierte Regeln zu stützen, nutzt ML/KI die Merkmale indexierter Daten. Dies ermöglicht die dynamische Entdeckung neuer Facetten und Filter.

Vorteile:

• Automatische Aktualisierungen: Neue Filter und Facetten werden automatisch generiert, ohne dass manuelle Anpassungen erforderlich sind.

• Entdeckung neuer Attribute: Es kann bisher unberücksichtigte Datenmerkmale als Filter identifizieren und so das Sucherlebnis bereichern.

• Reduzierter manueller Aufwand: Das Team muss keine Filterregeln mehr ständig definieren und aktualisieren, da die KI aus den verfügbaren Daten lernt.

Nachteile:

• Wartungsaufwand: Die Verwendung von Modellen kann eine Vorvalidierung erfordern, um die Konsistenz der generierten Filter sicherzustellen.

• Erfordert Expertise in den Bereichen Maschinelles Lernen und Künstliche Intelligenz: Die Lösung erfordert qualifizierte Fachkräfte, die die Modellleistung feinabstimmen und überwachen.

• Risiko irrelevanter Filter: Wenn das Modell nicht gut kalibriert ist, kann es Facetten generieren, die für die Benutzer nicht nützlich sind.

• Kosten: Der Einsatz von ML und KI kann die Inanspruchnahme von Dienstleistungen Dritter erfordern, was die Betriebskosten erhöht.

Es ist wichtig zu beachten, dass selbst bei einem gut kalibrierten Modell und einer gut formulierten Eingabeaufforderung die generierten Facetten noch einen Überprüfungsschritt durchlaufen sollten. Diese Validierung kann manuell oder auf der Grundlage von Moderationsregeln erfolgen, um sicherzustellen, dass die Inhalte angemessen und sicher sind. Dies ist zwar nicht unbedingt ein Nachteil, aber dennoch ein wichtiger Aspekt, um die Qualität und Eignung der Facetten sicherzustellen, bevor sie den Nutzern zur Verfügung gestellt werden.

Implementierung von Filtern/Facetten – KI-Ansatz

In dieser Demonstration verwenden wir ein KI-Modell, um Produkteigenschaften automatisch zu analysieren und relevante Attribute vorzuschlagen. Mithilfe einer gut strukturierten Eingabeaufforderung extrahieren wir Informationen aus dem Katalog und wandeln diese in Filter und Facetten um. Im Folgenden stellen wir jeden einzelnen Schritt des Prozesses vor.

Zunächst werden wir die Inference API verwenden, um einen Endpunkt für die Integration mit einem ML-Dienst zu registrieren. Nachfolgend ein Beispiel für die Integration mit dem Dienst von OpenAI.

Nun definieren wir die Pipeline, um die Eingabeaufforderung auszuführen und die vom Modell generierten neuen Filter zu erhalten.

Eine Simulation dieser Pipeline für das Produkt „PlayStation 5“ wird mit folgender Beschreibung durchgeführt:

Atemberaubendes Spielerlebnis: Bestaunen Sie die beeindruckende Grafik und erleben Sie die Funktionen der neuen PS5.

Atemberaubendes Eintauchen: Entdecken Sie ein intensiveres Spielerlebnis mit Unterstützung für haptisches Feedback, adaptive Trigger und 3D-Audiotechnologie.

Schlankes Design: Mit der PS5 Digital Edition erhalten Gamer leistungsstarke Gaming-Technologie in einem schlanken, kompakten Design.

1 TB Speicherplatz: Dank 1 TB integriertem SSD-Speicher sind Ihre Lieblingsspiele immer griffbereit und warten nur darauf, von Ihnen gespielt zu werden.

Abwärtskompatibilität und Game Boost: Die PS5-Konsole kann über 4.000 PS4-Spiele abspielen. Mit Game Boost können Sie sogar in einigen der besten PS4-Konsolenspiele schnellere und flüssigere Bildwiederholraten genießen.

Betrachten wir nun die von dieser Simulation generierte Prompt-Ausgabe.

Nun wird dem neuen Index ein neues Feld, dynamic_facets, hinzugefügt, um die von der KI generierten Facetten zu speichern.

Mithilfe der Reindex API werden wir den Videospiele- Index auf videogames_1 neu indizieren und dabei die generate_filter_ai- Pipeline anwenden. Diese Pipeline generiert während der Indizierung automatisch dynamische Facetten.

Nun führen wir eine Suche durch und rufen die neuen Filter ab:

Ergebnisse:

Zur Veranschaulichung der Umsetzung der einzelnen Aspekte folgt unten ein einfaches Frontend:

Der hier dargestellte UI-Code befindet sich hier.

Fazit

Beide Ansätze zur Erstellung von Filtern und Facetten haben ihre Vor- und Nachteile. Der klassische Ansatz, der auf manuellen Regeln basiert, bietet Kontrolle und niedrigere Kosten, erfordert jedoch ständige Aktualisierungen und passt sich nicht dynamisch an neue Produkte oder Funktionen an.

Andererseits automatisiert der auf KI und maschinellem Lernen basierende Ansatz die Facettenextraktion, wodurch die Suche flexibler wird und die Entdeckung neuer Attribute ohne manuelles Eingreifen ermöglicht wird. Allerdings kann dieser Ansatz in der Umsetzung und Aufrechterhaltung komplexer sein und erfordert eine Kalibrierung, um konsistente Ergebnisse zu gewährleisten.

Die Wahl zwischen klassischen und KI-basierten Ansätzen hängt von den Bedürfnissen und der Komplexität des Unternehmens ab. Bei einfacheren Szenarien, in denen die Datenattribute stabil und vorhersehbar sind, kann der klassische Ansatz effizienter und einfacher zu warten sein, wodurch unnötige Kosten für Infrastruktur und KI-Modelle vermieden werden. Andererseits kann der Einsatz von ML/KI zur Extraktion von Facetten einen erheblichen Mehrwert bieten, das Sucherlebnis verbessern und die Filterung intelligenter gestalten.

Wichtig ist es zu beurteilen, ob die Automatisierung die Investition rechtfertigt oder ob eine traditionellere Lösung die Geschäftsanforderungen bereits effektiv erfüllt.

Den BEIR-Benchmark bei der Bewertung der Suchrelevanz verstehen

Für die Verbesserung eines Systems müssen Sie messen können, wie gut es funktioniert. Im Zusammenhang mit der Suche BEIR (oder gleichwertig der Abschnitt „Retrieval” der Bestenliste MTEB) gilt als der „heilige Gral” für die Informationsabruf-Community, was nicht weiter verwunderlich ist. Es handelt sich um einen sehr gut strukturierten Benchmark mit vielfältigen Datensätzen für unterschiedliche Aufgaben. Genauer gesagt werden folgende Bereiche abgedeckt:

• Abrufen von Argumenten (ArguAna, Touche2020)

• Open-Domain-QA (HotpotQA, Natural Questions, FiQA)

• Passagenabruf (MSMARCO)

• Abrufen doppelter Fragen (Quora, CQADupstack)

• Faktenprüfung (FEVER, Climate-FEVER, Scifact)

• Biomedizinische Informationsabfrage (TREC-COVID, NFCorpus, BioASQ)

• Abrufen von Entitäten (DBPedia)

• Zitationsvorhersage (SCIDOCS)

Es liefert eine einzige Statistik, nDCG@10, die angibt, wie gut ein System die relevantesten Dokumente für jedes Aufgabenbeispiel in den von ihm zurückgegebenen besten Ergebnissen abgleicht. Für ein Suchsystem, mit dem ein Mensch interagiert, ist die Relevanz der betsen Ergebnisse entscheidend. Allerdings gibt es bei der Bewertung von Suchvorgängen viele Nuancen, die durch eine einzelne zusammenfassende Statistik nicht erfasst werden.

Struktur eines BEIR-Datensatzes

Jeder Benchmark hat drei Artefakte:

• der Korpus oder die Dokumente, die abgerufen werden sollen

• Die Abfragen

• die Relevanzbewertungen für die Abfragen (auch bekannt als qrels).

Relevanzbewertungen werden als Wert zwischen null und größer angegeben. Werte ungleich Null zeigen an, dass das Dokument in gewisser Weise mit der Abfrage in Zusammenhang steht.

Datensatz

Korpusgröße

#Abfragen im Testset

#qrels positiv gekennzeichnet

#qrels gleich Null

#duplicates im Korpus

Arguana

8.674

1.406

1.406

0

96

Climate-FEVER

5.416.593

1.535

4.681

0

0

DBPedia

4.635.922

400

15.286

28.229

0

FEVER

5.416.568

6.666

7.937

0

0

FiQA-2018

57.638

648

1.706

0

0

HotpotQA

5.233.329

7.405

14.810

0

0

Natürliche Fragen

2.681.468

3.452

4.021

0

16.781

NFCorpus

3.633

323

12.334

0

80

Quora

522.931

10.000

15.675

0

1.092

SCIDOCS

25.657

1.000

4.928

25.000

2

Scifact

5.183

300

339

0

0

Touche2020

382.545

49

932

1.982

5.357

TREC-COVID

171.332

50

24.763

41.663

0

MSMARCO

8.841.823

6.980

7.437

0

324

CQADupstack (Summe)

457.199

13.145

23.703

0

0

Tabelle 1: Datensatzstatistiken. Die Zahlen wurden auf dem Testabschnitt der Datensätze berechnet (dev für MSMARCO).

Tabelle 1 enthält einige Statistiken zu den Datensätzen, aus denen der BEIR-Benchmark besteht, wie zum Beispiel die Anzahl der Dokumente im Korpus, die Anzahl der Abfragen im Testdatensatz und die Anzahl der positiven/negativen Paare (Abfrage, Dokument) in der qrels-Datei. Ein kurzer Blick auf die Daten lässt uns sofort Folgendes ableiten:

• Die meisten Datensätze enthalten keine negativen Beziehungen in der qrels-Datei, d. h. null Werte, was Dokumente ausdrücklich als irrelevant für die jeweilige Abfrage kennzeichnen würde.

• Die durchschnittliche Anzahl von Dokumentbeziehungen pro Abfrage (#qrels / #queries) variiert von 1,0 im Ticket von ArguAna bis 493,5 (TREC-COVID), jedoch mit einem Wert von <5 für die Mehrheit der Tickets.

• Bei einigen Datensätzen gibt es doppelte Dokumente im Korpus, was in einigen Fällen zu einer falschen Auswertung führen kann, z. B. wenn ein Dokument als relevant für eine Abfrage angesehen wird, sein Duplikat jedoch nicht. Zum Beispiel haben wir in ArguAna 96 Tickets von doppelten Dokumentpaaren identifiziert, wobei pro Paar nur ein Dokument als relevant für eine Abfrage markiert wurde. Durch die „Erweiterung“ der ursprünglichen Qrels-Liste um die Duplikate haben wir einen relativen Anstieg des nDCG@10-Wertes um durchschnittlich ~1 % festgestellt.

Beispiel für duplizierte Paare in ArguAna. In der qrels-Datei scheint nur der erste Eintrag (als Gegenargument) für die Abfrage („test-economy-epiasghbf-pro02a“) relevant zu sein.

Beim Vergleich von Modellen in der MTEB-Rangliste ist es naheliegend, sich auf die durchschnittliche Retrieval-Qualität zu konzentrieren. Dies ist ein guter Indikator für die Gesamtqualität des Modells, sagt jedoch nicht unbedingt etwas darüber aus, wie es für Sie funktionieren wird. Da die Ergebnisse pro Datensatz gemeldet werden, ist es sinnvoll zu verstehen, wie eng die verschiedenen Datensätze mit Ihrer Suchaufgabe zusammenhängen, und die Modelle nur anhand der relevantesten Datensätze neu zu bewerten. Wenn Sie noch tiefer eintauchen möchten, können Sie zusätzlich überprüfen, ob es Überschneidungen zwischen den Themen der verschiedenen Datensätze gibt. Die Stratifizierung von Qualitätsmaßen nach Themen ermöglicht eine viel differenziertere Bewertung ihrer spezifischen Stärken und Schwächen.

Wichtig ist hierbei, dass ein Dokument, das nicht in der qrels-Datei markiert ist, standardmäßig als für die Abfrage irrelevant angesehen wird. Wir befassen uns etwas eingehender mit diesem Bereich und sammeln einige Nachweise, um mehr Licht in die folgende Frage zu bringen: „Wie oft werden einem Evaluator Paare (Abfrage, Dokument) vorgelegt, für die es keine Ground-Truth-Informationen gibt?“. Der Grund dafür ist, dass bei nur verfügbaren oberflächlichen Markups (sodass nicht jedes relevante Dokument als solches gekennzeichnet ist) ein Informationsabrufsystem schlechter bewertet werden kann als ein anderes, nur weil es sich dafür „entscheidet“, andere relevante (aber nicht markierte) Dokumente anzuzeigen. Das ist ein häufiger Fehler bei der Erstellung qualitativ hochwertiger Evaluierungsdatensätze, insbesondere bei großen Datensätzen. Aus praktischen Gründen konzentriert sich die manuelle Kennzeichnung in der Regel auf die besten Ergebnisse, die vom aktuellen System zurückgegeben werden, sodass relevante Dokumente in den blinden Flecken möglicherweise übersehen werden. Daher ist es in der Regel vorzuziehen, mehr Ressourcen auf ein umfassenderes Markup weniger Abfragen als auf ein breites, oberflächliches Markup zu konzentrieren.

Nutzung des BEIR-Benchmarks zur Bewertung der Suchrelevanz

Um unsere Analyse zu beginnen, implementieren wir das folgende Szenario (siehe Notizbuch):

1. Zuerst laden wir den Korpus jedes Datensatzes in einen Elasticsearch-Index.

2. Für jede Abfrage im Testsatz rufen wir die 100 besten Dokumente mit BM25 ab.

3. Wir ordnen die abgerufenen Dokumente mithilfe verschiedener SOTA-Reranking-Modelle neu an.

4. Abschließend geben wir die „Bewertungsrate“ für die 10 besten Dokumente aus Schritt 2 (nach dem Abrufen) und Schritt 3 (nach dem Reranking) an. Mit anderen Worten: Wir berechnen den durchschnittlichen Prozentsatz der 10 besten Dokumente mit einer Bewertung in der qrels-Datei.

Die Liste der von uns verwendeten Reranking-Modelle lautet wie folgt:

• Coheres rerank-english-v2.0 und rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Abruf

Reranking

Datensatz

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15,1

14,02

14,42

Natürliche Fragen

5,94

8.84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

Scifact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (Durchschnitt)

5,47

6,32

6,87

5.89

6,22

6,16

Tabelle 2: Bewertungsrate pro Paare (Datensatz, Reranker), berechnet anhand der 10 am häufigsten abgerufenen/neu geordneten Dokumente

Aus Tabelle 2 sehen wir, mit Ausnahme von TREC-COVID (>90 % Abdeckung), DBPedia (~65 %), Touche2020 und nfcorpus (~35 %), dass die Mehrheit der Datensätze eine Labeling-Rate zwischen 5 % und etwas mehr als 10 % nach dem Abrufen oder Reranking aufweist. Das heißt nicht, dass alle diese unmarkierten Dokumente relevant sind, aber es könnte ein Teilbereich davon geben, insbesondere diejenigen, die an oberster Stelle stehen, die positiv sein könnten.

Mit dem Aufkommen von auf allgemeine Anweisungen abgestimmten Sprachmodellen haben wir ein neues leistungsfähiges Tool, das die Beurteilung der Relevanz potenziell automatisieren kann. Diese Methoden sind in der Regel viel zu rechenaufwändig, um online für die Suche verwendet zu werden, aber hier geht es uns um die Offline-Auswertung. Im Folgenden verwenden wir sie, um die Hinweise darauf zu untersuchen, dass einige der BEIR-Datensätze unter oberflächlichen Markups leiden.

Zur weiteren Untersuchung dieser Hypothese haben wir uns entschlossen, uns auf MSMARCO zu konzentrieren und einen Teilbereich von 100 Abfragen zusammen mit den fünf (mit Cohere v2) höchsten Reranking-Dokumenten auszuwählen, die derzeit nicht als relevant markiert sind. Wir haben zwei verschiedene Bewertungsansätze verfolgt: Zunächst haben wir einen sorgfältig abgestimmten Prompt (mehr dazu in einem späteren Beitrag) verwendet, um das kürzlich veröffentlichte Phi-3-mini-4k-Modell darauf vorzubereiten, die Relevanz (oder Nicht-Relevanz) eines Dokuments für die Abfrage vorherzusagen. Parallel dazu wurden diese Tickets auch manuell gekennzeichnet, um auch die Übereinstimmungsrate zwischen dem LLM-Ausgang und der menschlichen Bewertung zu ermitteln. Insgesamt können wir die folgenden beiden Schlüsse ziehen:

• Die Übereinstimmungsrate zwischen den LLM-Reaktionen und den menschlichen Beurteilungen lag bei knapp 80 %, was als Ausgangspunkt in diese Richtung durchaus gut erscheint.

• In 57,6 % der Fälle (nach menschlicher Beurteilung) erwiesen sich die zurückgegebenen Dokumente tatsächlich als relevant für die Abfrage. Anders ausgedrückt: Bei 100 Abfragen werden 107 Dokumente als relevant eingestuft, aber es gibt mindestens 0,576 x 5 x 100 = 288 zusätzliche Dokumente, die tatsächlich relevant sind!

Hier einige Beispiele aus dem Datensatz MSMARCO/dev, die die Abfrage, das annotierte positive Dokument (aus qrels) und ein falsch negatives Dokument aufgrund unvollständiger Auszeichnung enthalten:

Beispiel 1:

Beispiel 2:

Die manuelle Auswertung solcher spezifischer Abfragen ist eine allgemein nützliche Methode, um die Suchqualität zu verstehen und quantitative Messgrößen wie nDCG@10 zu ergänzen. Bei einem repräsentativen Abfrageset, das Sie immer ausführen, wenn Sie Änderungen an der Suche vornehmen, erhalten Sie wichtige qualitative Informationen darüber, wie sich die Leistung verändert, die in den Statistiken nicht sichtbar sind. Beispielsweise erhalten Sie viel mehr Einblick in die falschen Ergebnisse Ihrer Suche: Sie erkennen offensichtliche Fehler in den Suchergebnissen, Kategorien verwandter Fehler, wie z. B. die Fehlinterpretation fachspezifischer Terminologie und so weiter.

Unser Ergebnis stimmt mit einschlägigen Studien zur MSMARCO Bewertung der Suchrelevanz überein. Zum Beispiel folgen Arabzadeh et al. einem ähnlichen Verfahren, bei dem sie Crowdsourcing-Mitarbeiter für Präferenzurteile einsetzen: Sie zeigen unter anderem, dass in vielen Fällen die von den Reranking-Modulen zurückgegebenen Dokumente im Vergleich zu den Dokumenten in der MSMARCO- qrels-Datei bevorzugt werden. Ein weiterer Nachweis stammt von den Autoren des RocketQA-Rerankers, die berichten, dass mehr als 70 % der Reranking-Dokumente nach einer manuellen Überprüfung als relevant eingestuft wurden.

Aktualisierung – 9. September: Nach einer genauen Neubewertung des Datensatzes haben wir 15 weitere Fälle relevanter Dokumente identifiziert, wodurch sich die Gesamtzahl von 273 auf 288 erhöht hat

Wichtigste Erkenntnisse und nächste Schritte

• Das Streben nach besseren Referenzwerten ist ein nie endender Prozess, da diese für Benchmarking und Modellvergleiche von entscheidender Bedeutung sind. LLMs können in einigen Bewertungsbereichen helfen, wenn sie mit Vorsicht angewendet und mit den richtigen Anweisungen abgestimmt werden.

• Allgemeiner gesagt: Da Benchmarks niemals perfekt sein werden, könnte es vorteilhaft sein, von einem reinen Wertevergleich zu robusteren Methoden überzugehen, die statistisch signifikante Unterschiede erfassen. Die Arbeit von Arabzadeh et al. liefert hierfür ein gutes Beispiel, da auf Grundlage der Ergebnisse 95-prozentige Konfidenzintervalle erstellt wurden, die signifikante (oder nicht signifikante) Unterschiede zwischen den verschiedenen Durchläufen aufzeigen Im beigefügten Notizbuch stellen wir eine Implementierung von Konfidenzintervallen unter Verwendung von Bootstrapping zur Verfügung.

• Aus der Perspektive des Endnutzers ist es sinnvoll, bei der Betrachtung von Benchmark-Ergebnissen über die Aufgabenausrichtung nachzudenken. Für einen KI-Ingenieur, der beispielsweise eine RAG-Pipeline entwickelt und weiß, dass der typische Anwendungsfall das Zusammenführen mehrerer Informationen aus verschiedenen Quellen beinhaltet, wäre es sinnvoller, die Leistung seines Retrieval-Modells anhand von Multi-Hop-QA-Datensätzen wie HotpotQA zu bewerten, anstatt den globalen Durchschnitt des gesamten BEIR-Benchmarks zu verwenden.

Im nächsten Blogbeitrag werden wir uns eingehender mit der Verwendung von Phi-3 als LLM-as-a-Judge und der Optimierung zur Vorhersage der Relevanz befassen.

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!

Was macht sysgrok?

sysgrok kann beispielsweise Folgendes:

• Nehmen Sie die vom Profiler ermittelten, kostenintensivsten Funktionen und Prozesse, erläutern Sie deren jeweilige Funktionalität und schlagen Sie Optimierungen vor.

• Nimmt einen Host und eine Beschreibung des Problems, das auf diesem Host auftritt, und debuggt das Problem automatisch. Anschließend werden Lösungsansätze und weitere Maßnahmen vorgeschlagen.

• Nehmen Sie Quellcode, der von einem Profiler annotiert wurde, erläutern Sie die kritischen Pfade und schlagen Sie Möglichkeiten zur Verbesserung der Code-Performance vor.

Die Funktionalität von sysgrok zielt auf drei große Lösungskategorien ab:

1. Als Analysetool für Leistungs-, Zuverlässigkeits- und andere systembezogene Daten. In diesem Modus wird dem LLM die Ausgabe eines anderen vom Ingenieur verwendeten Tools zugeführt (z. B. eines Linux-Befehlszeilentools, eines Profilers oder einer Observability-Plattform). Ziel von sysgrok ist es, mithilfe eines LLM den Zustand des Systems zu interpretieren, zusammenzufassen und Hypothesen darüber aufzustellen. Anschließend können auch Optimierungen oder Abhilfemaßnahmen vorgeschlagen werden.

2. Als fokussierte, automatisierte Lösung für spezifische Aufgaben im Bereich Leistung und Zuverlässigkeit. Es gibt einige Aufgaben, die im Bereich Performance Engineering und SRE immer wieder anfallen. Hierfür können wir zielgerichtete, automatisierte Assistenten entwickeln, die entweder direkt vom Ingenieur oder von sysgrok selbst zur Lösung anderer Probleme eingesetzt werden können. Beispielsweise ist es im Bereich Performance Engineering üblich, die Frage zu beantworten: „Gibt es eine schnellere Version dieser Bibliothek mit gleichwertiger Funktionalität?“ sysgrok unterstützt dies direkt.

3. Als automatisiertes Werkzeug zur Ursachenanalyse von Leistungs- und Zuverlässigkeitsproblemen. Bei den ersten beiden Lösungskategorien handelt es sich um eine Mischung aus Datenanalyse, Interpretation, Suche und Zusammenfassung. Entscheidend ist, dass sie gezielt auf Daten angewendet werden, die der Ingenieur selbst erhoben hat. Im Projekt sysgrok untersuchen wir außerdem einen dritten Ansatz zur Problemlösung mit LLMs, bei dem das LLM mit anderen Werkzeugen kombiniert wird, um autonom eine Ursachenanalyse und Lösung eines gegebenen Problems durchzuführen. Bei diesem Ansatz erhält der LLM eine Problembeschreibung (z. B. „Der Webserver weist eine hohe Latenz auf“) und erfährt, welche Fähigkeiten ihm zur Verfügung stehen (z. B. „SSH-Verbindung zu einem Host herstellen“, „Beliebige Linux-Befehlszeilentools ausführen“). Anschließend wird das LLM gebeten, die ihm zur Verfügung stehenden Maßnahmen zur Priorisierung des Problems zu ergreifen. Diese Aktionen werden von sysgrok ausgeführt, und der LLM wird gebeten, die Ergebnisse zu analysieren, das Problem zu priorisieren, Abhilfemaßnahmen vorzuschlagen und die nächsten Schritte zu empfehlen.

sysgrok befindet sich noch in der Anfangsphase, aber wir veröffentlichen es, da es bereits für eine Vielzahl von Aufgaben nützlich ist – wir hoffen, dass es eine bequeme Basis für andere sein wird, um ähnliche Experimente durchzuführen. Schickt uns gerne Pull Requests oder öffnet Issues auf GitHub, wenn ihr Ideen habt!

Analyse von Leistungsproblemen mit LLMs

LLMs, wie beispielsweise die GPT-Modelle von OpenAI, haben in den letzten Monaten einen enormen Popularitätsschub erlebt und bieten eine natürliche Sprachschnittstelle sowie den Kern von allen möglichen Produkten, von Chatbots für den Kundenservice über Assistenten zur Datenmanipulation bis hin zu Programmierassistenten. Ein interessanter Aspekt dieses Trends ist, dass im Wesentlichen alle diese Anwendungen auf vorgefertigte, generische Modelle zurückgreifen, die nicht speziell für die jeweilige Aufgabe trainiert oder feinabgestimmt wurden. Stattdessen wurden sie mit großen Teilen des Internets als Ganzes trainiert und sind daher für eine breite Palette von Aufgaben anwendbar.

Können wir diese Modelle also zur Unterstützung von Leistungsanalyse, Fehlersuche und Optimierung nutzen? Es gibt eine Vielzahl von Methoden, um Leistungsprobleme zu untersuchen, die Ursachen zu ermitteln und Optimierungen zu entwickeln. Im Kern geht es bei jeder Leistungsanalyse jedoch darum, die Ausgabe verschiedener Tools zu betrachten, beispielsweise von Linux-Befehlszeilentools oder einer Observability-Plattform, und diese Ausgabe zu interpretieren, um eine Hypothese über den Zustand des Systems aufzustellen. Zu den Materialien, mit denen die GPT-Modelle trainiert wurden, gehören Quellen, die Softwareentwicklung, Debugging, Infrastrukturanalyse, Betriebssysteminterna, Kubernetes, Linux-Befehle und deren Verwendung sowie Methoden zur Leistungsanalyse abdecken. Die Modelle können daher genutzt werden, um die Daten und Probleme, mit denen Leistungsingenieure tagtäglich konfrontiert werden, zusammenzufassen, zu interpretieren und Hypothesen darüber aufzustellen. Dies kann das Tempo beschleunigen, mit dem ein Ingenieur seine Analyse durchführt.

Wir können aber noch einen Schritt weiter gehen und über die reine Nutzung des LLM für Datenanalyse und Fragebeantwortung im Kontext des eigenen Untersuchungsprozesses des Ingenieurs hinausgehen. Wie wir später in diesem Beitrag zeigen werden, kann das LLM in bestimmten Szenarien selbst den Prozess steuern, indem es entscheidet, welche Befehle ausgeführt werden sollen oder welche Datenquellen zur Fehlerbehebung herangezogen werden sollen.

Demos

Eine vollständige Übersicht über die von sysgrok unterstützten Funktionen finden Sie im GitHub- Repository. Im Großen und Ganzen unterstützt es drei Ansätze zur Problemlösung:

Ansatz 1: Als Analysetool für Leistungs-, Zuverlässigkeits- und andere systembezogene Daten

In diesem Modus wird dem LLM die Ausgabe eines anderen vom Ingenieur verwendeten Tools zugeführt, beispielsweise eines Linux-Befehlszeilentools, eines Profilers oder einer Observability-Plattform. Das Ziel von sysgrok ist es, Daten zu interpretieren, zusammenzufassen und Abhilfemaßnahmen vorzuschlagen.

Beispielsweise nimmt der Unterbefehl topn die vom Profiler gemeldeten, teuersten Funktionen, erläutert die Ausgabe und schlägt dann Möglichkeiten zur Optimierung des Systems vor.

Dieses Video zeigt auch die Chat-Funktionalität von sysgrok. Bei Angabe des Arguments „–chat“ startet sysgrok nach jeder Antwort des LLM eine Chat-Sitzung.

Diese Funktionalität lässt sich auch allgemein auf die Ausgabe von Linux-Befehlszeilentools anwenden. In dem Artikel „Linux Performance Analysis in 60 seconds“ beschreibt Brendan Gregg beispielsweise 10 Befehle, die ein SRE ausführen sollte, wenn er sich zum ersten Mal mit einem Host verbindet, bei dem ein Leistungs- oder Stabilitätsproblem auftritt. Der Unterbefehl analyzecmd nimmt als Eingabe einen Host, zu dem eine Verbindung hergestellt werden soll, und einen auszuführenden Befehl entgegen und analysiert und fasst dann die Ausgabe des Befehls für den Benutzer zusammen. Wir können dies nutzen, um den von Gregg beschriebenen Prozess zu automatisieren und dem Benutzer eine einzeilige Zusammenfassung aller von den 10 Befehlen generierten Daten zu geben, wodurch ihm die Mühe erspart wird, die Ausgabe jedes Befehls einzeln durchzugehen.

Ansatz 2: Als fokussierte, automatisierte Lösung für spezifische Aufgaben im Zusammenhang mit Leistung und Zuverlässigkeit

Es gibt einige Aufgaben, die im Bereich Performance Engineering und SRE immer wieder anfallen. Hierfür können wir zielgerichtete, automatisierte Assistenten entwickeln, die entweder direkt vom Ingenieur oder von sysgrok selbst zur Lösung anderer Probleme eingesetzt werden können.

Beispielsweise nimmt der Unterbefehl findfaster als Eingabe den Namen einer Bibliothek oder eines Programms und verwendet den LLM, um einen schnelleren, gleichwertigen Ersatz dafür zu finden. Dies ist eine sehr häufige Aufgabe im Bereich Performance Engineering.

Ein weiteres Beispiel für diesen Ansatz in sysgrok ist der Unterbefehl explainfunction . Dieser Unterbefehl benötigt den Namen einer Bibliothek und einer Funktion innerhalb dieser Bibliothek. Es erklärt, was die Bibliothek leistet und welche typischen Anwendungsfälle sie hat, und anschließend wird die Funktion erläutert. Schließlich werden mögliche Optimierungen vorgeschlagen, falls die Bibliothek und die Funktion einen erheblichen Teil der CPU-Ressourcen beanspruchen.

Ansatz 3: Als automatisiertes Werkzeug zur Ursachenanalyse von Leistungs- und Zuverlässigkeitsproblemen

Der Einsatz von LLMs beschränkt sich nicht nur auf die Beantwortung fokussierter Fragen, das Zusammenfassen von Texten und ähnliche Aufgaben. Es beschränkt sich auch nicht auf einmalige Anwendungen, bei denen ihnen eine einzige, isolierte Frage gestellt wird. Der Unterbefehl sysgrok debughost demonstriert, wie ein LLM als "Gehirn" in einem Agenten mit dem Ziel der automatisierten Problemlösung eingesetzt werden kann. In diesem Modus ist das LLM in einen Prozess eingebettet, der das LLM nutzt, um zu entscheiden, wie ein bestimmtes Problem zu debuggen ist, und ihm die Möglichkeit gibt, Verbindungen zu Hosts herzustellen, Befehle auszuführen und auf andere Datenquellen zuzugreifen.

Der Befehl debughost ist derzeit wahrscheinlich der experimentellste Teil von sysgrok. Es zeigt einen Schritt auf dem Weg zu automatisierten Agenten für die Leistungsanalyse, aber es ist noch ein erheblicher Forschungs- und Entwicklungsaufwand erforderlich, um dieses Ziel zu erreichen.

Fazit

In diesem Beitrag habe ich sysgrok vorgestellt, einen neuen Open-Source-KI-Assistenten zur Analyse, zum Verständnis und zur Optimierung von Systemen. Wir haben auch die drei Hauptkategorien von Ansätzen besprochen, die sysgrok implementiert:

1. Eine Analyse-Engine für Leistungs-, Zuverlässigkeits- und andere systembezogene Daten: Siehe die Unterbefehle topn, stacktrace, analyzecmd und code.

2. Gezielte, automatisierte Lösungen für spezifische Aufgaben im Zusammenhang mit Leistung und Zuverlässigkeit: Siehe die Unterbefehle explainprocess, explainfunction und findfaster.

3. Automatisierte Ursachenanalyse für Leistungs- und Zuverlässigkeitsprobleme: Siehe den Unterbefehl debughost.

Das sysgrok-Projekt finden Sie auf GitHub. Sie können gerne Pull Requests und Issues erstellen oder mich direkt unter sean.heelan@elastic.co kontaktieren, wenn Sie das Projekt oder die Anwendungsmöglichkeiten von LLMs im Allgemeinen besprechen möchten.

Wo wir angefangen haben

Die erste Version von Elasticsearch wurde 2010 als verteilte, skalierbare Suchmaschine veröffentlicht, die es Benutzern ermöglicht, schnell nach wichtigen Erkenntnissen zu suchen und diese anzuzeigen. Zwölf Jahre und über 65.000 Commits später bietet Elasticsearch seinen Nutzern weiterhin praxiserprobte Lösungen für eine Vielzahl von Suchproblemen. Dank des Engagements von über 1.500 Mitwirkenden, darunter Hunderte von festangestellten Elastic-Mitarbeitern, hat sich Elasticsearch ständig weiterentwickelt, um den neuen Herausforderungen im Bereich der Suche gerecht zu werden.

In der Frühphase von Elasticsearch, als Bedenken hinsichtlich Datenverlusten aufkamen, unternahm das Elastic-Team über mehrere Jahre hinweg Anstrengungen , das Cluster-Koordinationssystem neu zu schreiben, um zu gewährleisten, dass bestätigte Daten sicher gespeichert werden. Als deutlich wurde, dass die Verwaltung von Indizes in großen Clustern mühsam ist, arbeitete das Team an der Implementierung einer umfassenden ILM-Lösung , um diese Arbeit zu automatisieren, indem es den Benutzern ermöglicht, Indexmuster und Lebenszyklusaktionen vorzudefinieren. Da die Nutzer den Bedarf erkannten, große Mengen an Metrik- und Zeitreihendaten zu speichern, wurden verschiedene Funktionen wie eine bessere Komprimierung hinzugefügt, um die Datengröße zu reduzieren. Da die Speicherkosten für die Suche in großen Mengen kalter Daten stiegen, investierten wir in die Entwicklung von durchsuchbaren Snapshots , um Benutzerdaten direkt in kostengünstigen Objektspeichern durchsuchen zu können.

Diese Investitionen legen den Grundstein für die nächste Entwicklungsstufe von Elasticsearch. Angesichts des Wachstums cloudnativer Dienste und neuer Orchestrierungssysteme haben wir beschlossen, Elasticsearch weiterzuentwickeln, um die Benutzerfreundlichkeit bei der Arbeit mit cloudnativen Systemen zu verbessern. Wir sind überzeugt, dass diese Änderungen Möglichkeiten zur Verbesserung des Betriebsablaufs, der Leistung und der Kosten beim Betrieb von Elasticsearch auf Elastic Cloud bieten.

Wohin wir gehen – Die Einführung einer staatenlosen Architektur

Eine der größten Herausforderungen beim Betrieb oder der Orchestrierung von Elasticsearch besteht darin, dass es von zahlreichen persistenten Zuständen abhängt und daher ein zustandsbehaftetes System ist. Die drei Hauptbestandteile sind das Translog, der Indexspeicher und die Cluster-Metadaten. Dieser Zustand bedeutet, dass die Daten persistent sein müssen und bei einem Neustart oder Austausch eines Knotens nicht verloren gehen dürfen.

Die bestehende Elasticsearch-Architektur auf Elastic Cloud muss die Indizierung über mehrere Verfügbarkeitszonen hinweg duplizieren, um im Falle von Ausfällen Redundanz zu gewährleisten. Wir beabsichtigen, die Speicherung dieser Daten von lokalen Festplatten in einen Objektspeicher wie AWS S3 zu verlagern. Durch die Nutzung externer Dienste zur Speicherung dieser Daten entfällt die Notwendigkeit der Indexierungsreplikation, wodurch der mit der Datenerfassung verbundene Hardwareaufwand erheblich reduziert wird. Diese Architektur bietet zudem sehr hohe Garantien für die Datenbeständigkeit, da Cloud-Objektspeicher wie AWS S3, GCP Cloud Storage und Azure Blob Storage Daten über Verfügbarkeitszonen hinweg replizieren.

Durch die Auslagerung der Indexspeicherung in einen externen Dienst können wir Elasticsearch auch neu strukturieren, indem wir die Verantwortlichkeiten für Indizierung und Suche trennen. Anstatt primäre und Replikatinstanzen für beide Arbeitslasten zu verwenden, planen wir eine Indexierungsebene und eine Suchebene. Durch die Trennung dieser Arbeitslasten können diese unabhängig voneinander skaliert werden, und die Hardwareauswahl kann gezielter auf die jeweiligen Anwendungsfälle abgestimmt werden. Es hilft auch dabei, eine seit langem bestehende Herausforderung zu lösen, bei der sich die Such- und Indexierungslast gegenseitig beeinflussen kann.

Nach einer mehrmonatigen Machbarkeits- und Versuchsphase sind wir davon überzeugt, dass diese Objektspeicherdienste die Anforderungen erfüllen, die wir an die Speicherung von Indizes und Cluster-Metadaten stellen. Unsere Tests und Benchmarks zeigen, dass diese Speicherdienste die hohen Indexierungsanforderungen der größten Cluster, die wir in Elastic Cloud gesehen haben, erfüllen können. Darüber hinaus reduziert die Speicherung der Daten im Objektspeicher die Indizierungskosten und ermöglicht eine einfache Optimierung der Suchleistung. Zur Datensuche nutzt Elasticsearch das bewährte Searchable Snapshots-Modell, bei dem die Daten dauerhaft im Cloud-nativen Objektspeicher abgelegt werden und lokale Festplatten als Cache für häufig abgerufene Daten dienen.

Um die Unterschiede zu verdeutlichen, bezeichnen wir unser bestehendes Modell als „Knoten-zu-Knoten“-Replikation. In der Hot-Tier-Ebene dieses Modells übernehmen sowohl der primäre als auch der Replikat-Shard die gleiche rechenintensive Aufgabe bei der Verarbeitung und Beantwortung von Suchanfragen. Diese Knoten sind „zustandsbehaftet“, da sie sich auf ihre lokalen Festplatten verlassen, um die Daten für die von ihnen gehosteten Shards sicher zu speichern. Darüber hinaus kommunizieren primäre und Replikat-Shards ständig miteinander, um synchron zu bleiben. Dies geschieht, indem die auf dem primären Shard durchgeführten Operationen auf den Replikat-Shard repliziert werden, was bedeutet, dass die Kosten dieser Operationen (hauptsächlich CPU) für jedes angegebene Replikat anfallen. Die gleichen Shards und Nodes, die für die Datenaufnahme zuständig sind, bedienen auch Suchanfragen, daher müssen Bereitstellung und Skalierung beide Arbeitslasten berücksichtigen.

Neben der Suche und dem Datenimport übernehmen Shards im Node-to-Node-Replikationsmodell weitere rechenintensive Aufgaben, wie beispielsweise das Zusammenführen von Lucene-Segmenten. Dieses Design hat zwar seine Vorzüge, aber wir sahen viele Möglichkeiten, die sich aus unseren Erfahrungen mit Kunden im Laufe der Jahre und der Entwicklung des gesamten Cloud-Ökosystems ergaben.

Die neue Architektur ermöglicht zahlreiche sofortige und zukünftige Verbesserungen, darunter:

1. Sie können den Datendurchsatz auf derselben Hardware deutlich erhöhen, oder anders ausgedrückt, die Effizienz bei gleicher Datenerfassungslast deutlich verbessern. Diese Steigerung resultiert aus der Beseitigung der Duplizierung von Indexierungsvorgängen für jede Replik. Die rechenintensiven Indexierungsvorgänge müssen nur einmal auf der Indexierungsebene durchgeführt werden, die anschließend die resultierenden Segmente an einen Objektspeicher sendet. Von dort aus können die Daten direkt von der Suchschicht verwendet werden.

2. Sie können Rechenleistung und Speicher trennen, um Ihre Clustertopologie zu vereinfachen. Elasticsearch verfügt heute über mehrere Datenebenen (Content, Hot, Warm, Cold und Frozen), um Daten mit Hardwareprofilen abzugleichen. Die Hot-Tier-Kategorie dient der Suche in nahezu Echtzeit, die Frozen-Tier-Kategorie der Suche nach weniger häufig gesuchten Daten. Diese Ebenen bieten zwar einen Mehrwert, erhöhen aber auch die Komplexität. In der neuen Architektur werden Datenebenen nicht mehr benötigt, was die Konfiguration und den Betrieb von Elasticsearch vereinfacht. Wir trennen außerdem die Indizierung von der Suche, was die Komplexität weiter reduziert und es uns ermöglicht, beide Arbeitslasten unabhängig voneinander zu skalieren.

3. Sie können die Speicherkosten auf der Indexierungsebene senken, indem Sie die Menge der Daten reduzieren, die auf einer lokalen Festplatte gespeichert werden müssen. Aktuell muss Elasticsearch für Indexierungszwecke eine vollständige Shard-Kopie auf den Hot Nodes (sowohl primären als auch Replikaten) speichern. Bei dem zustandslosen Ansatz, direkt auf den Objektspeicher zuzugreifen, wird nur ein Teil dieser lokalen Daten benötigt. Bei reinen Anfüge-Anwendungsfällen müssen nur bestimmte Metadaten zur Indizierung gespeichert werden. Dadurch wird der für die Indizierung benötigte lokale Speicherplatz erheblich reduziert.

4. Sie können die mit Suchanfragen verbundenen Speicherkosten senken. Indem das Searchable Snapshots-Modell zum nativen Modus der Datensuche gemacht wird, werden die mit Suchanfragen verbundenen Speicherkosten deutlich reduziert. Je nach den Anforderungen der Benutzer an die Suchlatenz ermöglicht Elasticsearch Anpassungen, um das lokale Caching häufig angeforderter Daten zu erhöhen.

Benchmarking – 75 % Verbesserung des Indexierungsdurchsatzes

Um diesen Ansatz zu validieren, haben wir einen umfangreichen Machbarkeitsnachweis erbracht, bei dem die Daten nur auf einem einzigen Knoten indiziert und die Replikation über Cloud-Objektspeicher realisiert wurde. Wir stellten fest, dass wir eine Verbesserung des Indexierungsdurchsatzes um 75 % erreichen konnten, indem wir die Notwendigkeit beseitigten, Hardware für die Indexierungsreplikation zu dedizieren. Darüber hinaus waren die CPU-Kosten für das einfache Abrufen von Daten aus dem Objektspeicher wesentlich geringer als für das Indizieren der Daten und das lokale Schreiben, wie es heutzutage für die Hot-Tier-Ebene erforderlich ist. Dies bedeutet, dass die Suchknoten ihre gesamte CPU-Leistung der Suche widmen können.

Diese Leistungstests wurden auf einem Zwei-Knoten-Cluster gegen alle drei großen Public-Cloud-Anbieter (AWS, GCP und Azure) durchgeführt. Wir beabsichtigen, im Zuge unserer Bemühungen um eine zustandslose Produktionsimplementierung weiterhin größere Benchmarks zu entwickeln.

Indexierungsdurchsatz

CPU-Auslastung

Staatenlos für uns, Ersparnisse für Sie

Die zustandslose Architektur von Elastic Cloud ermöglicht es Ihnen, den Indexierungsaufwand zu reduzieren, die Datenerfassung und -suche unabhängig voneinander zu skalieren, die Verwaltung der Datenebenen zu vereinfachen und Vorgänge wie Skalierung oder Upgrade zu beschleunigen. Dies ist der erste Meilenstein hin zu einer umfassenden Modernisierung der Elastic Cloud-Plattform.

Werden Sie Teil unserer Vision für zustandsloses Elasticsearch.

Haben Sie Interesse, diese Lösung vor allen anderen auszuprobieren? Sie können uns über die Diskussionsseite oder unseren Community-Slack-Kanal erreichen. Wir würden uns über Ihr Feedback freuen, um die Ausrichtung unserer neuen Architektur mitzugestalten.

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.