Kategorie: Tool-Tests

„A language model can perform well on a clean benchmark and still struggle with the cases that matter in production.“ Das Zitat beschreibt das Kernproblem der LLM-Evaluierung. Ein Benchmark ist eine kontrollierte Umgebung mit sauberen Daten und klaren Erwartungen. Die Produktion ist das nicht. Dort treffen unvollständige Kontexte, uneindeutige Eingaben und widersprüchliche Labels aufeinander. Wer LLM-Systeme ernsthaft einsetzen will, braucht eine Evaluierungsstrategie, die näher an der Realität liegt als ein kuratiertes Testset.

Der Erfahrungsbericht, der diesem Beitrag zugrunde liegt, beschreibt ein LLM-basiertes System, das False Positives beim GitHub Secret Scanning reduzieren soll. Secret Scanning erkennt Zugangsdaten wie Tokens und Schlüssel, die versehentlich in ein Repository gelangt sind. Ein Teil dieser Funde sieht zwar wie echte Zugangsdaten aus, ist aber harmlos. Entwickler verlieren dann Zeit mit der Prüfung solcher Alerts, obwohl keine Maßnahme nötig ist. Das Team stand vor einer typischen Produktionsfrage: Kann ein LLM die Spreu vom Weizen trennen, ohne relevante Alerts zu übersehen? Eine reine Benchmark-Aufgabe wäre gewesen, Strings korrekt zu klassifizieren. Die eigentliche Herausforderung war eine andere: die Fehlalarmrate senken, ohne die Sicherheit zu gefährden.

Am Anfang steht die Produktentscheidung, nicht das Modell

Für die Entwicklung dieses Systems war die Frage entscheidend: Kann die Lösung Fehlalarme reduzieren, ohne die Erkennungsrate realistischer Bedrohungen zu senken? Das klingt naheliegend, ist es aber nicht. Ohne eine klare Produktentscheidung verliert man sich in Prompt-Optimierung und Modellvergleichen, ohne zu wissen, was erreicht werden soll. Die Autoren raten, zuerst festzulegen, welche Fehler vermeidbar sein müssen und welche Kennzahlen die Entscheidung tragen.

Das Team entschied: Ein übersehener echter Credential ist schwerwiegender als ein zusätzlicher Fehlalarm. Precision und Recall wurden nicht gleich behandelt. Precision war das primäre Ziel, denn sie misst, wie viele der gemeldeten Alarme wirklich relevant sind. Recall diente als Sicherheitskriterium. Ein Experiment durfte nur weiterlaufen, wenn der Rückgang echter Erkennung innerhalb eines vorher festgelegten Rahmens blieb. Dazu kamen operative Rahmenbedingungen wie Latenz, Kosten, Zuverlässigkeit und die Kompatibilität mit der bestehenden Pipeline.

Ein Beispiel verdeutlicht das: Experiment A verbessert Precision stark, fällt aber unter den Recall-Schwellenwert. Experiment B bringt eine moderate Verbesserung, bleibt aber im erlaubten Bereich. Nur Experiment B ist aus Produktsicht ein Fortschritt. Diese Unterscheidung fehlt oft, wenn Teams nur einen Modellwechsel testen. Die Evaluierung von LLM-Systemen im Produktionsumfeld verlangt mehr als einen sauberen Testlauf. Sie verlangt eine klare Vorstellung davon, was das System verbessern soll.

Offline-Evaluation wie einen Integrationstest behandeln

Eine einmalige Evaluierung reicht nicht. Ändern sich Prompt, Modell, Eingabekonstruktion oder die Logik im Umfeld, verschiebt sich das Verhalten. Deshalb haben die Entwickler die Offline-Evaluation wie einen Integrationstest behandelt. Bei jeder relevanten Änderung lief sie erneut. Auch die Reproduzierbarkeit war wichtig. Zu jedem Lauf gehörten Prompt-Version, Modellversion, Datensatzversion und Systemkonfiguration. Nur so lässt sich beantworten, ob eine Änderung wirklich geholfen hat oder ob sich Fehler nur verschoben haben.

Ein Grundsatz war: eine große Variable pro Experiment. Eine Prompt-Änderung wurde getrennt von einem Modell-Upgrade getestet, bevor beide zusammenkamen. Wenn zwei Dinge gleichzeitig wechseln, weiß man am Ende nicht, was die Verbesserung oder Regression verursacht hat. Der Beitrag empfiehlt, Prompts wie Code zu behandeln – versioniert, dokumentiert und jederzeit zurückrollbar. Wer diese Disziplin nicht einhält, vergleicht Äpfel mit Birnen und schreibt einem Prompt eine Verbesserung zu, die eigentlich vom Modell stammt.

Modell-Upgrades sind ein eigenes Thema. Wenn ein System nicht gut funktioniert, neigen viele dazu, den Prompt mit immer mehr Anweisungen zu füllen. Manche Probleme verschwinden, andere entstehen neu. Ein stärkeres Modell arbeitet mit einem einfacheren Prompt oft besser als das alte Modell mit viel Feintuning. Ein simpler Prompt ist leichter zu verstehen, zu testen und zu warten. Aber auch der Wechsel des Modells muss durch die Offline-Evaluation, weil er Qualität, Latenz und Kosten verändern kann.

Die Offline-Evaluation so nah wie möglich an der Produktion halten

Ein Offline-Test ist nur so gut wie seine Ähnlichkeit zum Produktionseinsatz. Das Modell bewertet selten einen einzelnen, sauber isolierten Wert. Es sieht einen Kandidaten, umgebenden Code und weitere Hinweise, die relevant, unvollständig oder irreführend sein können. Bereits kleine Unterschiede verzerren das Ergebnis. Ein bereinigtes Testset, das alle mehrdeutigen Fälle entfernt und immer vollständigen Kontext liefert, misst ein einfacheres Problem als das, was später in Produktion auftritt.

Der Beitrag nennt ein Beispiel: Eine Variable heißt candidate_value und soll bewertet werden. Daneben steht eine Variable example_token, deren Name nach einem Sicherheitswert klingt. Das Modell könnte sich auf example_token stürzen und eine plausible Erklärung für den falschen Wert liefern. In einem sauberen Evaluierungsdatensatz mit nur einem offensichtlichen Kandidaten fällt das nicht auf. In der realen Secret-Scanning-Umgebung passiert genau das. Wer ein LLM für solche Aufgaben baut, sollte die Offline-Pipeline der Produktionspipeline so ähnlich wie möglich gestalten. Sonst zeigt eine gute Offline-Bewertung nur, dass das System ein einfacheres Problem gut löst.

Produktionslabels sind Signale, keine absolute Wahrheit

Produktionsdaten sind wertvoll, aber ihre Labels entstehen oft aus Workflow-Abläufen. Ein als „dismissed“ markierter Secret-Scanning-Alert ist nicht automatisch ein False Positive. Die Entwickler nennen mehrere Gründe: Der Credential wurde rotiert, das Risiko wurde akzeptiert, der Alert musste für einen Workflow verschwinden, oder die Klassifikation war schlicht falsch. Diese Fälle können im selben Datenfeld landen, obwohl sie unterschiedliche Wahrheiten repräsentieren. Wer ein Korpus aus Produktionsdaten baut, sollte sich fragen: Wie wurde das Label erzeugt? Beantwortet es dieselbe Frage, die die Evaluierung stellen soll? Werden verschiedene Workflow-Ausgänge in einer Kategorie zusammengefasst?

Ein manueller Review ist für wichtige oder mehrdeutige Teilmengen notwendig. Ziel ist nicht, jedes unvollständige Label zu eliminieren, sondern die Datengrundlage präzise genug für die Entscheidung zu machen. Wer diese Genauigkeit ignoriert, evaluiert auf einer Statistik, die mit der echten Welt wenig zu tun hat. Bei LLM-Modellen vor dem Produktionseinsatz hängt viel davon ab, ob die Labels die tatsächliche Produktlogik abbilden oder nur eine Annäherung.

Synthetische Daten und offene Datensätze als Ergänzung nutzen

Gute produktionsnahe Daten sind nicht immer verfügbar. Am Anfang fehlen repräsentative Beispiele, oder die Daten sind sensibel. Dann helfen synthetische Daten, akademische Benchmarks und offene Datensätze. Sie füllen Lücken – etwa bei seltenen Eingabeformaten, fehlendem Kontext oder ungewöhnlichen Fehlermustern. Sie sollten die produktionsnahen Daten ergänzen, nicht ersetzen. Eine Liste von Credential-Strings zeigt, ob das Modell Formate erkennt. Sie zeigt nicht, wie es mit einem Kandidaten in echtem Code umgeht.

Die Entwickler haben externe Beispiele an ihre Aufgabe angepasst und geprüft, ob die Labels zur eigenen Produktdefinition passen. Aus real aufgetretenen Fehlermustern haben sie gezielt synthetische Fälle erzeugt. Das sagt mehr aus als ein generischer Corpus. Dass ein Modell Benchmarks kann, ist noch kein Produktionsargument. Erst wenn die Testfälle die typischen Fallstricke des eigenen Einsatzbereichs abdecken, wird daraus ein belastbares Ergebnis.

Was die LLM-Evaluierung vor dem Produktionseinsatz bedeutet

Der Erfahrungsbericht zeigt: Die Evaluierung von Large Language Models vor dem Produktionseinsatz ist kein einmaliger Check, sondern ein Prozess. Sie beginnt mit der Produktentscheidung, läuft durch eine reproduzierbare Offline-Phase und endet idealerweise in einem Online-Experiment. Im beschriebenen Fall diente die Offline-Evaluation als Filter. Erst wenn die Ergebnisse den Produktkriterien standhielten, kam es zu einem kontrollierten Test in der echten Umgebung. So verhindert man, dass ein Modell nur auf Papier gut aussieht und in Produktion unerwartet versagt.

Für dein eigenes Projekt bedeutet das: Definiere zuerst das erwünschte Verhalten, nicht die Modellarchitektur. Entscheide, welche Fehler akzeptabel sind und welche nicht. Baue die Offline-Evaluation so auf, dass sie die Produktionsrealität abbildet – inklusive Unschärfen. Versioniere deine Prompts und Modelle, damit jede Verbesserung zugeordnet werden kann. Hinterfrage Labels, bevor du sie als Ground Truth akzeptierst. Und nutze synthetische Daten, um Lücken zu schließen, ohne dich von ihnen blenden zu lassen. Wer diese Punkte beachtet, hat eine belastbare Grundlage, um LLM-Modelle vor dem Produktionseinsatz zu bewerten – jenseits von Benchmark-Zahlen, mit Blick auf False Positives, Recall und Produktionsrealität.

Quelle: github.blog

„Ein einziger KI-Output ist ein Beispiel, keine Bewertung.“ Dieser Satz klingt banal, wird in der Praxis aber oft ignoriert. Wer mit KI-Systemen arbeitet, kennt das: ein Testinput, ein plausibles Ergebnis, und schon wirkt das System zuverlässig. Doch ein einzelner Durchlauf sagt nichts darüber, ob das System auch bei anderen Eingaben und Wiederholungen diese Leistung bringt. Der Artikel argumentiert dagegen: Teams sollen nicht länger von einem einzelnen Output auf die Qualität eines KI-Systems schließen.

Stattdessen schlägt der Beitrag vor, KI-Systeme wie in einer quantitativen UX-Studie zu evaluieren: viele repräsentative Testeingaben, mehrere Wiederholungen pro Eingabe, dazu eine statistische Zusammenfassung mit Mittelwerten und Konfidenzintervallen. Das kennt man aus der Marktforschung. Genau darum geht es: keine neue Wissenschaft der KI-Messung, sondern bewährte experimentelle Prinzipien anwenden.

Wieso ein einzelner Testlauf unzuverlässig ist

Warum ein einzelner Output nicht reicht: KI-Sprachmodelle arbeiten nichtdeterministisch. Gleiche Eingabe, unterschiedliche Ausgaben. Für jedes nächste Token berechnen sie eine Wahrscheinlichkeitsverteilung und wählen daraus, oft per Zufallsstichprobe. Dieselbe Frage kann also zweimal gestellt ganz unterschiedliche Antworten liefern – im Wortlaut und in der Qualität.

Das ist kein Randphänomen. Wiederholte Generationen desselben Modells zeigen messbare Leistungsunterschiede, und Evaluationsergebnisse hängen von der Art der Ausgabeerzeugung ab. Wer klassische Software gewohnt ist, kennt das nicht: Ein deterministisches Programm, das einmal korrekt läuft, läuft unter denselben Bedingungen immer korrekt. Diese Erwartung überträgt man unbewusst auf KI-Systeme – zu Unrecht. Ein einzelner guter Output beweist nur, dass das System die Aufgabe prinzipiell kann. Nicht, wie oft es das unter realen Bedingungen tut.

KI-Evaluation wie eine UX-Studie

Ein Vergleich macht das deutlich: Wer die Usability eines Checkout-Prozesses misst, lässt nicht eine Person eine Aufgabe erledigen und schließt daraus, der Prozess sei perfekt. Man definiert repräsentative Aufgaben, die verschiedene Produkttypen und Käufersituationen abdecken, beobachtet viele Teilnehmer und berechnet für Metriken wie Aufgabenerfolg oder Bearbeitungszeit einen Durchschnittswert. Dazu kommt ein Konfidenzintervall, also der Bereich, in dem der wahre Wert der Grundgesamtheit mit hoher Wahrscheinlichkeit liegt. Dieses Vorgehen lässt sich auf KI-Evaluationen übertragen.

Die Analogie ist nicht perfekt. Ein KI-Lauf ist kein menschlicher Teilnehmer, eine Testeingabe keine Aufgabe mit allen situativen Feinheiten. Aber die Grundlogik ist dieselbe: Man sammelt mehrere Beobachtungen, um die Leistung des Systems zu schätzen. Die UX-Forschung fasst Ergebnisse über Aufgaben und Teilnehmer hinweg zusammen. KI-Evaluationen sollten das auch tun – mit repräsentativen Eingaben, genügend Wiederholungen und einer Auswertung, die Mittelwert, Streuung und Unsicherheit ausweist.

Ein Beispiel: Kundenservice-Fragen fünfmal stellen

Ein Beispiel zeigt, wie das aussehen kann. Ein KI-gestützter Kundenservice beantwortet Fragen zu Unternehmensrichtlinien. Man wählt zehn repräsentative Fragen aus, die unterschiedliche Themen, Komplexitätsgrade und Kundensituationen abdecken: Rückgaben, Stornierungen, Schäden, Abonnements, Garantien. Jede Frage wird fünfmal eingereicht, insgesamt also 50 Antworten. Die Zahlen sind nur illustrativ. Je nach Variabilität des Systems und Tragweite der Entscheidungen braucht es in der Praxis mehr Fragen oder mehr Wiederholungen.

Vor der Datenerhebung muss klar sein, was eine akzeptable Antwort ist. Der Artikel nennt vier Kriterien: Sie muss die Frage korrekt beantworten, alle wichtigen Bedingungen und Ausnahmen enthalten, mit den Unternehmensrichtlinien übereinstimmen und dem Kunden bei Bedarf einen nächsten Schritt nennen. Fehlt ein Kriterium, gilt sie als nicht akzeptabel. Aus den 50 Antworten lässt sich der Anteil akzeptabler Antworten berechnen, dazu ein Konfidenzintervall. Ebenso wichtig: Wie stark schwankt die Qualität zwischen den zehn Fragen? Wie konsistent antwortet das System auf dieselbe Frage?

Eine Evaluation ist immer nur eine Momentaufnahme. Modellversion, Prompt, Einstellungen, Tools und Kontext gehören sorgfältig dokumentiert. Ändert sich eine dieser Komponenten, muss die Evaluation unter Umständen wiederholt werden. Nur so sind Ergebnisse nachvollziehbar und vergleichbar.

Zwei Formen von Variabilität: Testeingaben und Wiederholungen

Das Beispiel zeigt: Eine KI-Evaluation muss zwei getrennte Fragen beantworten. Erstens: Wie gut funktioniert das System über die Bandbreite an Eingaben, die Nutzer real stellen? Das ist die Testeingaben-Variabilität. Ein Kundenservice-System kann bei kurzen, klaren Fragen wie „Wo ist meine Bestellung?“ hervorragend arbeiten, aber bei komplexen Ausnahmefällen versagen. Enthält die Evaluation überwiegend einfache Fragen, überschätzt sie die reale Leistung. Die Testeingaben müssen also repräsentativ für die tatsächliche Nutzung sein. Quantität allein genügt nicht – viele einfache Fragen liefern ein präzises Ergebnis für die falsche Frage.

Die zweite Frage betrifft die Wiederholungs-Variabilität: Wie konsistent antwortet das System auf dieselbe Eingabe? Da es nichtdeterministisch ist, kann die Qualität variieren. Ohne wiederholte Läufe bleibt unklar, ob eine Aufgabe zuverlässig gemeistert wird oder nur gelegentlich gelingt. Mehr Testeingaben verbessern die Schätzung der Leistung über den Eingabenraum, mehr Wiederholungen die Schätzung der Konsistenz für eine bestimmte Eingabe. Beide Maßnahmen betreffen unterschiedliche Risiken. Das eine ersetzt das andere nicht.

Derselbe Score kann auf unterschiedliche Schwächen hinweisen

Dazu ein Beispiel: Zwei Kundenservice-Systeme werden mit zehn Fragen und fünf Wiederholungen getestet. Beide erreichen 80 Prozent akzeptabler Antworten – auf den ersten Blick gleich gut. Doch die Fehler verteilen sich völlig unterschiedlich. Das erste System antwortet auf acht Fragen in jedem Lauf korrekt und scheitert bei zwei Fragen konsequent. Das zweite System antwortet auf jede Frage in vier von fünf Läufen korrekt und versagt unregelmäßig über alle Fragen. Die identische Quote verdeckt zwei sehr verschiedene Probleme.

Dieser Unterschied ist in der Praxis entscheidend. Ein System, das immer an denselben Stellen scheitert, lässt sich gezielt verbessern – mit besseren Trainingsdaten oder angepassten Prompts für diese Frageklassen. Ein System, das unregelmäßig mal gut, mal schlecht antwortet, hat ein grundsätzlicheres Zuverlässigkeitsproblem. Wer nur den Gesamtscore betrachtet, sieht das nicht. Erst die Auswertung auf Ebene einzelner Fragen und Läufe zeigt, wo man ansetzen muss.

Konfidenzintervalle und Variabilität auszuwerten ist aufwendiger als ein einzelner Testlauf. Dafür bekommt man eine realistischere Einschätzung der Zuverlässigkeit von KI-Systemen. Wenn KI zunehmend Entscheidungen unterstützt oder übernimmt, ist das kein Luxus, sondern notwendig. Ein einzelnes gutes Beispiel ist schön. Es sagt nur nichts darüber, was im nächsten Moment passiert, wenn der Kunde dieselbe Frage stellt.

Quelle: nngroup.com

Ein 10-Millionen-Dokument-Korpus, der als Float32-Vektoren 31 Gigabyte Arbeitsspeicher belegt, passt mit turbovec in 4 Gigabyte. Die Suche in diesem komprimierten Index dauert weniger lang als mit FAISS, dem etablierten Standardwerkzeug für Vektorsuche. Möglich macht das eine Kombination aus einem neuen Quantisierungsverfahren und handoptimierten SIMD-Kernels.

Speicherfresser Vektorsuche: Das Problem

Vektorsuche steckt in vielen modernen Anwendungen, von Empfehlungssystemen bis zu Retrieval-Augmented Generation. Die zugrunde liegenden Einbettungen haben ihren Preis: Ein Vektor mit 1536 Dimensionen belegt als Float32 knapp 6 Kilobyte. Bei Millionen von Dokumenten summiert sich das auf mehrere hundert Gigabyte RAM. Zu teuer und oft unpraktikabel.

Dazu kommt die Geschwindigkeit. Eine lineare Suche über alle Vektoren ist bei dieser Größenordnung zu langsam. Klassische Indizes wie FAISS oder HNSW benötigen oft eine Trainingsphase, bevor sie Daten aufnehmen können. FAISS muss erst mit einer Stichprobe trainieren, um Codebücher zu lernen. Bei sich ständig ändernden Daten wird das zum Problem.

turbovec umgeht das: weniger Speicher durch Quantisierung, schnellere Suche durch SIMD-Optimierung und ein Online-Ingest ohne Trainingsschritt. Der Index eignet sich für Szenarien mit kontinuierlich neuen Daten, etwa bei RAG-Systemen für Dokumentenanalyse.

TurboQuant: Quantisierung ohne Trainingsphase

Um Vektoren kompakt abzulegen, nutzt turbovec die Produktquantisierung. Dabei wird ein Vektor in mehrere Untervektoren zerlegt, die jeweils durch einen Index aus einem Codebuch repräsentiert werden. Üblicherweise muss dieses Codebuch mit einem Trainingslauf auf den eigenen Daten erstellt werden. Genau das macht TurboQuant überflüssig.

Der Algorithmus von Google Research ist ein daten-agnostischer Quantisierer. Er erzeugt ein Codebuch, das für beliebige Datenverteilungen nahezu optimale Verzerrung bietet. Statt vollständiger Vektoren werden nur Codebuch-Indizes gespeichert. Das spart Platz, kostet aber etwas Genauigkeit.

turbovec unterstützt zwei Bit-Breiten: 2-Bit und 4-Bit pro Komponente. Je niedriger die Bit-Breite, desto stärker die Kompression, aber desto größer der potenzielle Qualitätsverlust. In den Benchmarks zeigt sich, dass die 4-Bit-Variante kaum an Recall einbüßt, während sie den Speicherbedarf drastisch senkt. Die 2-Bit-Variante ist für extrem speicherhungrige Systeme gedacht.

Rust, SIMD und Python: Die technische Basis

Rust als Implementierungssprache hat Vorteile. Sie garantiert Speichersicherheit ohne Garbage Collector und erlaubt feingranulare Optimierungen. Entwickler Ryan Codrai hat die Such-Kernels von turbovec von Hand geschrieben und nutzt SIMD-Instruktionen. SIMD steht für Single Instruction Multiple Data – eine CPU verarbeitet damit mehrere Vektoren parallel. Das beschleunigt die Suche erheblich.

Konkret kommen auf ARM-Prozessoren NEON SDOT/SMMLA zum Einsatz, auf x86 AVX-512 VNNI und vpermb. Ältere CPUs nutzen AVX2 oder skalare Fallbacks. In den Messungen des Autors übertrifft turbovec damit FAISS IndexPQFastScan in fast jeder Konfiguration. Bei 4-Bit-Quantisierung liegt der Vorsprung durchschnittlich beim Faktor 3,4, bei 2-Bit bei 20 bis 30 Prozent.

Die Python-Bindings machen die Bibliothek direkt nutzbar. Du installierst turbovec per Pip und kannst sofort einen Index anlegen, Vektoren hinzufügen und durchsuchen. Die API ist bewusst schlank: TurboQuantIndex für den einfachen Fall, IdMapIndex für stabile IDs. Wer in Python arbeitet, profitiert damit von der Leistung einer nativen Rust-Bibliothek.

Quelle: github.com

Drei SKILL.md-Dateien, ein gemeinsamer REST-Client: Das ist die Essenz des Projekts spark-observability-skills von EmbrasureAI. Das Open-Source-Projekt hilft, typische Probleme in Apache-Spark-Workloads schneller zu finden – von abgestürzten Executoren bis hin zu teuren SQL-Plänen. Wer schon einmal stundenlang Logs durchforstet hat, nachdem ein Spark-Job unerwartet fehlschlug, weiß, wie wertvoll ein strukturierter Ansatz sein kann.

Jeder Skill ist eine einzelne Datei mit einer priorisierten Checkliste. Ein kleines Python-Skript sammelt die nötigen Laufzeitdaten direkt vom History Server. Das Ganze ist read-only, begrenzt die Antwortgrößen und redigiert sensible Eigenschaften. Du bekommst ein Werkzeug, das dir den Weg durch den Spark-Dschungel weist, ohne tief in die Cluster-Interna eintauchen zu müssen.

Was genau sind Agent Skills?

Bevor wir uns die drei Skills im Detail ansehen, lohnt ein kurzer Blick auf das Konzept dahinter. Agent Skills sind kleine, klar definierte Anweisungen für KI-gestützte Programmierassistenten wie Codex oder Claude Code. Stell dir vor, du hast einen erfahrenen Kollegen, der bei einem Problem nicht nur Tipps gibt, sondern systematisch eine Diagnose durchführt – Schritt für Schritt, mit einer klaren Reihenfolge von Ursachen, die er zuerst prüft. Genau das macht ein Skill: Er gibt dem Agenten eine strukturierte Vorgehensweise vor.

Im Fall von spark-observability-skills ist jeder Skill eine Datei namens SKILL.md. Sie enthält eine geordnete Liste der häufigsten und wirkungsvollsten Ursachen für ein bestimmtes Problem – zum Beispiel für einen fehlgeschlagenen Job. Dazu kommt ein Skript, das die Beweise aus dem Spark History Server holt. Der Agent kann so nicht nur raten, sondern konkrete Daten auswerten und dir erklären, was schiefläuft.

Die drei Skills decken die klassischen Problemfelder ab: Fehlerdiagnose, Performance-Analyse und SQL-Optimierung. Diese Trennung ist sinnvoll. Ein abgestürzter Job hat andere Ursachen als ein langsamer, und eine teure Query verlangt wiederum nach anderen Hebeln.

Skill 1: Fehler im Spark-Job aufspüren

Der erste Skill heißt „Debug Spark failures“ und zielt auf den Albtraum jedes Dateningenieurs: Ein Job läuft nicht durch, aber der letzte Fehler im Log sagt nichts Nützliches. Oft sieht man nur die oberflächliche Meldung wie „Task failed“ oder „Executor lost“, während die eigentliche Ursache viel weiter zurückliegt – ein abgestürzter Treiber, ein Out-of-Memory-Kill, ein Fetch-Fehler oder eine Exception in einem Task.

Der Skill leitet dazu an, diese Symptome zu hinterfragen und zur frühesten unterstützenden Ursache zurückzugehen. Statt den letzten Retry-Error zu betrachten, schaut man sich die Kette der Ereignisse an. Dafür nutzt der Agent den History-Server-REST-Client, um die relevanten Teile des Event Logs zu ziehen – und nur die. Die Liste der Prioritäten hilft, die wahrscheinlichsten Verdächtigen zuerst zu überprüfen, statt alles gleichzeitig zu untersuchen.

Das klingt simpel. In der Praxis spart es Zeit und Frustration. Viele Spark-Nutzer verlieren Stunden damit, den falschen Fehler zu jagen. Dieser Skill kanalisiert die Diagnose in eine klare Bahn.

Skill 2: Langsame Jobs beschleunigen

Der zweite Skill „Debug slow Spark jobs“ richtet sich an das alltägliche Problem, dass ein Job zwar läuft, aber deutlich länger oder teurer ist als erhofft. Hier empfiehlt der Skill einen Vergleich mit einem gesunden Lauf: Du brauchst eine Referenz, um die erste Abweichung zu lokalisieren. Liegt es an Skew – also ungleicher Datenverteilung –, an exzessivem Shuffle, an Spill auf die Festplatte, an GC-Pausen, an schlechter Parallelität oder doch an der Infrastruktur?

Der Agent nutzt wieder den REST-Client, schaut sich aber diesmal Metriken wie Aufgabenzeiten, Shuffle-Volumen und Speichernutzung an. Die Skill-Datei listet die wahrscheinlichsten Ursachen in sinnvoller Reihenfolge. So folgst du einer deduktiven Spur, statt ratlos durch die Benutzeroberfläche zu gehen.

Der Hinweis, dass ein gesunder Lauf als Basis dient, ist nützlich. Wenn du eine frühere erfolgreiche Ausführung hast, kann der Agent die Unterschiede punktgenau herausarbeiten. Das ist präziser, als pauschal nach „Performance-Problemen“ zu suchen.

Skill 3: SQL-Pläne kosteneffizient machen

Der dritte Skill widmet sich einer typischen Spark-Herausforderung: Eine Query liefert die richtigen Ergebnisse, aber sie kostet zu viel – zu viele Scans, zu teure Joins, unnötige Shuffles. Hier geht es um „Optimize Spark SQL plans“. Der Skill liest den finalen adaptiven Plan und die Laufzeitmetriken, um Schwachstellen zu identifizieren, ohne das Ergebnis zu verändern.

Dabei hilft der History-Server-REST-Client, detaillierte Informationen über die ausgeführten Operationen zu sammeln. So kann der Agent sehen, wo Daten gescannt werden, welche Joins besonders teuer sind und ob es unnötige Arbeit gibt. Anschließend schlägt er konkrete Optimierungen vor – etwa das Umformulieren der Query, das Hinzufügen von Partitionen oder das Anpassen von Join-Hinweisen.

Wichtig ist: Der Skill verändert nichts an der Logik. Er ist auf Konservierung der Semantik ausgelegt. Du kannst die Vorschläge übernehmen, ohne befürchten zu müssen, dass sich die Ergebnisse ändern.

Der gemeinsame REST-Client: Beweise sammeln, ohne etwas zu verändern

Alle drei Skills basieren auf demselben Skript: `scripts/spark_history_api.py`. Es agiert als read-only REST-Client gegenüber dem Spark History Server oder der Live-UI einer laufenden Anwendung (Port 4040). Der Client begrenzt standardmäßig große Antworten, redigiert sensible Spark-Eigenschaften und lässt TLS-Verifikation aktiviert. Das ist eine durchdachte Sicherheitsvorkehrung – du willst nicht, dass ein KI-Agent versehentlich Daten verändert oder Zugangsdaten preisgibt.

Das Skript sammelt die relevanten Beweise in einem „bounded snapshot“ – also einem zeitlich und größenmäßig begrenzten Ausschnitt. Das ist wichtig, denn ein Spark History Server kann riesige Datenmengen enthalten. Durch die Begrenzung bleibt die Analyse effizient und der Agent wird nicht mit überflüssigen Informationen überflutet.

Die Einrichtung ist unkompliziert: Du setzt die Umgebungsvariable `SPARK_HISTORY_URL`, optional mit Authorization-Token oder Cookie für SSO-Proxys. Wenn der Server im Cluster läuft, reicht ein Port-Forward, etwa `kubectl port-forward`. Die Skills erwarten, dass die History-Daten vorhanden sind – also dass `spark.eventLog.enabled=true` gesetzt war, als die Jobs liefen. Das solltest du im Hinterkopf behalten.

Der Einrichtungsprozess und nötige Voraussetzungen

Die Installation ist simpel: Du klonst das Repository und erstellst einen Symlink auf dein Skills-Verzeichnis – sei es bei Codex, Claude oder einem anderen Agenten. Genau genommen musst du nur den Ordner `skills/` mit deinem vorhandenen Skills-Pfad verknüpfen. Sobald du den Agenten neu lädst, stehen dir die drei Skills zur Verfügung.

Wichtig ist die Umgebungsvariable `SPARK_HISTORY_URL`. Ohne sie kann der Client nicht arbeiten. Du hast die Wahl zwischen einem öffentlich erreichbaren History Server oder einem getunnelten Port. Für private Zertifikate gibt es die Option `–ca-file`, und für SSO-Proxys kannst du entweder ein Cookie oder zusätzliche HTTP-Header übergeben. Das deckt die meisten Realweltszenarien ab.

Die Autoren betonen, dass der Client vollständig read-only arbeitet. Trotzdem empfehlen sie, jeden Befehl vor der Ausführung gegen die eigenen Sicherheitsrichtlinien zu prüfen. Das ist verantwortungsvoll, gerade wenn du den Agenten in einer Produktionsumgebung einsetzt.

Was das für deine Spark-Praxis bedeutet

Betrachtet man das Projekt als Ganzes, zeigt sich ein klarer Trend: KI-Assistenten werden von reinen Code-Generatoren zu diagnostischen Werkzeugen. Die Skills von Embrasure sind ein Beispiel dafür, wie man implizites Wissen über Spark – das oft in den Köpfen erfahrener Ingenieure steckt – explizit und für Agenten zugänglich macht. Die geordneten Checklisten ersetzen keine tiefe Systemkenntnis, aber sie helfen dir, schneller an die richtige Stelle zu schauen.

Ein Detail: Die Skripte sind in allen drei Skill-Ordnern identisch. Das ist eine bewusste Designentscheidung, damit jeder Skill eigenständig funktioniert – du kannst also auch nur einen Skill auswählen, ohne die anderen zu installieren. Diese Modularität ist angenehm, auch wenn sie Wartungsaufwand bedeutet: Änderst du etwas am Skript, musst du alle drei Kopien synchronisieren.

Das Projekt ist eine solide Brücke zwischen der komplexen Welt von Apache Spark und dem Wunsch nach schneller Fehlerbehebung. Es ersetzt kein professionelles Monitoring, aber es gibt dir und deinem Agenten eine gemeinsame Sprache und einen strukturierten Blick ins Innere deiner Workloads. Wenn du mit Spark arbeitest und eine neutralere, datenbasierte Diagnose willst, ist dieses Open-Source-Tool einen Blick wert.

Quelle: github.com

Ein Datenanalyst sitzt vor einem Dashboard und hat soeben eine Anfrage an einen KI-Agenten geschickt. Die Frage: Hat die Marketingkampagne „Midwest acquisition v2″ den Einsatz gelohnt? Der Agent rechnet, summiert und liefert nach wenigen Sekunden eine klare Antwort: Nein, die Kampagne war das Geld nicht wert. Der Analyst nickt zufrieden, bis er bemerkt, dass die zugrunde liegenden Daten gar nicht existieren. Es gibt schlicht keinen Tracking-Code für die Kampagne. Der Agent hat sich die Zahlen aus dem Zusammenhang heraus erfunden – mit einer Selbstsicherheit, die menschliche Analysten verblüfft.

Genau dieses Szenario beschreibt das Team von Hex, einer Plattform für kollaborative Datenanalyse, in ihrem neuen Benchmark. Sie nennen ihn DataBench. Die Lektion daraus ist unbequem: Die größte Stärke großer Sprachmodelle – ihre Fähigkeit, aus Kontext Wahrscheinlichkeiten zu berechnen – wird in der Datenanalyse zur tödlichen Schwäche, weil sie keine intrinsische Skepsis kennen. Die Ergebnisse betreffen jeden, der mit Daten arbeitet.

Warum herkömmliche Benchmarks ein falsches Bild zeichnen

Die führenden KI-Modelle glänzen auf etablierten Benchmarks wie Spider 2.0 oder DABstep mit Erfolgsraten von über 85 Prozent. Sonnet 4.5 von Anthropic erreicht 90 Prozent, Claude Haiku 4.5 liegt bei 89 Prozent. Auf dem Papier wirkt die Datenanalyse damit nahezu gelöst. Doch das Team von Hex argumentiert, dass diese Benchmarks eine Realität abbilden, die mit der Arbeit echter Datenanalysten wenig zu tun hat.

Die Aufgaben dort sind präzise formuliert, die Datenbanken sauber aufgeräumt, die Ziele glasklar. Es gibt genau eine richtige Antwort, oft sogar einen vorgegebenen SQL-Code als Vergleich. „Das ist wie Krafttraining im Fitnessstudio“, schreibt der Autor des Beitrags, „beeindruckend, aber nicht der Alltag.“ Echte Anfragen in Unternehmen sind vage, mehrdeutig und mit impliziten Annahmen durchsetzt. Ein Analyst fragt nicht: „Berechne die Summe aller Umsätze für Produktkategorie X im Zeitraum Y.“ Er fragt: „Sollten wir unsere Preisstrategie in Europa überdenken?“ – und erwartet eine Empfehlung, keine Zahl.

Die Diskrepanz zwischen Benchmarktests und realen Anforderungen ist das Kernproblem, das DataBench adressiert. Die Entwickler haben 100 realistische Aufgaben aus der Nutzung ihrer eigenen Plattform gesammelt, anonymisiert und in eine synthetische Geschäftswelt namens Shorelane Commerce eingebettet. Die Aufgaben reichen von einfachen Datenabfragen bis zu komplexen Entscheidungsszenarien mit Fallstricken, die bewusst an die Grenzen der Modelle führen.

Die unbequeme Wahrheit über Datenqualität und geteilte Verantwortung

Die Ergebnisse von DataBench zeigen ein ernüchterndes Bild: Selbst die besten Modelle scheitern an Aufgaben, die für Menschen trivial erscheinen. Die Hälfte der Testfälle beinhaltet chaotische Daten – widersprüchliche Metrikdefinitionen, fragmentierte Datensätze, veraltete Einträge. Hier zeigen die Modelle überraschende Stärke, solange die Absicht klar ist. Ein Beispiel: Die Aufgabe verlangt die aktuelle USD-Pipeline für einen historischen Bericht mit Stichtag 15. Januar – eine scheinbar simple Abfrage, die aber erfordert, dass der Agent den Datenbestand auf den damaligen Zustand zurückspult. 29 von 32 Modellkonfigurationen meistern das.

Doch sobald die Anweisung vage wird oder der Kontext Interpretationsspielraum lässt, kippt die Bilanz. Bei offenen, delegierten Entscheidungen sinkt die Erfolgsquote auf 66 Prozent, bei speziell konstruierten „Fallen“ – Aufgaben mit einer plausiblen, aber falschen Antwort – sogar auf 54 Prozent. Das Team spricht von einem „verfluchten Bereich“: In der Datenanalyse sehen einfache Fragen schwer aus, schwere Fragen leicht, und viele Fragen sind schlicht unmöglich zu beantworten, weil die Datenlage es nicht hergibt.

Ein konkretes Beispiel ist die Aufgabe mit den zwei Abrechnungssystemen, die unterschiedliche Aussagen darüber treffen, welche Kunden säumig sind. Die naheliegende Lösung – alle Kunden anzurufen, über die sich die Systeme uneinig sind – wird durch Daten im System gestützt. Doch diese Daten sind veraltet: Die meisten fraglichen Konten haben längst bezahlt, nur die Sync-Prozesse haben das nicht erfasst. Nur Opus 5 von Anthropic erkennt die Falle. Alle anderen Modelle folgen dem naheliegenden Pfad – und scheitern.

Das Problem der erfundenen Sicherheit

Besonders beunruhigend ist ein Muster, das sich durch die Tests zieht: Modelle konstruieren Sicherheit, wo keine existiert. In einem Testfall geht es um die Frage, ob Bestellungen, die in mehreren Paketen geliefert werden, mehr Support-Tickets erzeugen. Opus 5 rechnet elf Minuten lang korrekt, um dann eine kausale Beziehung zu „verifizieren“, die schlicht nicht aus den Daten ableitbar ist. Die Analyse ignoriert den Kontext: Bestellungen werden nur dann geteilt, wenn das Lagerbestände verteilen muss – was typischerweise bei Engpässen passiert, die auch ohne die Pakettrennung zu Beschwerden führen.

Der Unterschied zwischen Korrelation und Kausalität ist für Modelle offenbar kaum überwindbar. Sie akzeptieren ihre eigenen Rechenergebnisse als Beweis für einen Mechanismus, den sie nur vermuten. Das Team von Hex nennt das „Herstellung von Gewissheit“ – ein Prozess, der die Modelle dazu bringt, ihre Ergebnisse zu überschätzen und menschliche Nutzer in die Irre zu führen.

Das ist kein Randphänomen. Die Entwickler berichten, dass sie bei fünf Aufgaben, die als „unlösbar“ konzipiert waren, die Bewertung ändern mussten, weil Fable 5 von Anthropic – eine der neuesten Modellgenerationen – elegantere Lösungen fand als die erwartete Antwort. Diese Mischung aus Brillanz und Arroganz macht die Arbeit mit KI-Agenten in der Datenanalyse zu einem ständigen Spagat zwischen Vertrauen und Kontrolle.

Die Kostenfrage: Wo günstige Modelle erstaunlich stark konkurrieren

DataBench zeigt auch, dass die Kosten-Nutzen-Rechnung vieler Unternehmen überdacht werden muss. Die „Pareto-Effizienzgrenze“ – ein Begriff für das beste Verhältnis von Kosten zu Genauigkeit – offenbart eine Überraschung: Das Modell GPT-5.6 Luna erreicht bei hohem Rechenaufwand fast die Leistung des deutlich teureren Sol – zu einem Bruchteil der Kosten. Das Team von Hex spricht von einem „absurden Preisleistungsverhältnis“. Während Fable 5 das einzige Modell ist, bei dem erhöhte Anstrengung keine negativen Effekte zeigt, verhält sich Opus 5 auf hohen Stufen erratisch.

Für Unternehmen bedeutet das: Das beste Modell ist nicht automatisch das wirtschaftlichste. Wer täglich hunderte Datenanalysen automatisiert ausführen lässt, kann mit einem günstigen Modell wie Luna erhebliche Kosten sparen – ohne signifikanten Qualitätsverlust bei Standardaufgaben. Bei kniffligen Fällen bleibt der Griff zu den großen Modellen unvermeidlich, aber die Schwelle, ab wann sich das lohnt, liegt deutlich höher als bisher angenommen.

Die Brücke zwischen Skepsis und Automatisierung

Die Autoren von DataBench lassen offen, ob sie eine Lösung für das Problem der mangelnden Modell-Skepsis haben. Ihr Rat ist bodenständig: Bleiben Sie neugierig, fragen Sie nach, testen Sie Ergebnisse, behalten Sie Ihr Urteilsvermögen. Sie versprechen, dass sie Bescheid geben, sobald man „das Gehirn ausschalten kann“ – ein Versprechen, das vermutlich noch lange uneingelöst bleibt.

Was DataBench konkret zeigt, ist, dass die Datenanalyse für KI-Agenten nicht nur eine technische, sondern eine kulturelle Herausforderung ist. Modelle müssen lernen, Unsicherheit zu kommunizieren statt Gewissheit zu erfinden. Sie müssen erkennen, wann eine Frage nicht beantwortet werden kann, und den Mut haben, das dem Nutzer mitzuteilen – auch auf die Gefahr hin, als weniger intelligent zu gelten. Denn in der Datenanalyse ist die Fähigkeit, die eigenen Grenzen zu kennen, wertvoller als jede errechnete Zahl.

Der Benchmark bleibt ein erster Versuch, wie die Entwickler selbst einräumen. Die 100 Aufgaben sind ein Ausschnitt, keine vollständige Landkarte des analytischen Denkens. Doch sie liefern ein wichtiges Signal für alle, die mit KI-Agenten arbeiten: Die Technologie ist mächtig, aber sie ist kein Ersatz für den gesunden Menschenverstand. Sie ist ein Werkzeug, das nachdenkliche Nutzer fordert – und belohnt.

Quelle: hex.tech