Teams, die KI-Agenten entwickeln, benötigen mehr als eine Prüfung der endgültigen Antwort, um festzustellen, ob das System wie vorgesehen funktioniert. In Anwendungen, die Retrieval, Generierung und Tool-Aufrufe kombinieren, kann ein falsches Ergebnis durch die Auswahl einer ungeeigneten Datenbank oder den Abruf unpassender Dokumente verursacht werden, selbst wenn das Problem scheinbar nur im endgültigen Text liegt. Während einer Präsentation über InfoQ erläuterte Susan Chang, leitende Datenwissenschaftlerin bei Elastic, wie das Unternehmen ein gemeinsames Framework zur Bewertung seiner Agenten für Cybersicherheit und Unternehmens-Chatbots entwickelte.
Von isolierten Bewertungen zu gemeinsamen Werkzeugen
Die Teams von Elastic begannen damit, für jeden Agenten separate Datensätze, Evaluatoren und Tracing-Prozesse zu erstellen. Beim Agenten zur Angriffserkennung umfassten die Tests Angriffs- und unkritische Szenarien, die von Analysten und Sicherheitsforschern formuliert wurden, mit Metriken wie Genauigkeit und Recall, Faktenrichtigkeit, Ähnlichkeit sowie der Klassifizierung von MITRE-Taktiken. Unternehmensdatenbasierte Chatbots testeten dagegen Fragen und den Abruf aus Dokumenten, wobei der Fokus auf der Relevanz und Vollständigkeit der Antwort, der Richtigkeit von Produkt-IDs und der Formulierung von ES|QL-Abfragen lag.
Die Unterschiede zwischen diesen Anwendungsfällen führten zu einer erheblichen Wiederholung der Arbeit. Daher entwickelte Elastic ein gemeinsames Framework, das verschiedene Datensatztypen in ein einheitliches Schema importieren, auf Ausführungstraces basierende Bewertungen durchführen und gemeinsame Evaluatoren für RAG-Anwendungen neben produktspezifischen Komponenten ausführen kann. Der Prozess kann lokal ausgeführt werden: Daten werden geladen, der Agent wird ausgeführt, Ergebnisse werden gesammelt und die Bewertungen anschließend den Entwicklern angezeigt.
Tracing ist eine Voraussetzung, um Fehlerursachen zu verstehen
Die Erfahrung zeigt, dass sich das Tracing eines Agenten nicht auf seine endgültige Ausgabe beschränken sollte. Aufgezeichnet werden sollten die aufgerufenen Tools, Vektor- und Stichwortsuchen, abgerufene Daten, Tokenverbrauch, Antwortzeit und die Abfolge der Entscheidungen. Dieser Detailgrad ermöglicht die Bewertung eines bestimmten Tool-Aufrufs oder die Feststellung, dass der Agent eine falsche Quelle verwendet hat, bevor das Problem in der endgültigen Antwort sichtbar wird.
Fehlgeschlagene Fälle, die von Nutzern gemeldet werden, etwa eine negative Bewertung, können ebenfalls in neue Beispiele für den Testdatensatz umgewandelt werden. Dadurch werden Produktionsrückmeldungen zu Regressionstests in späteren Versionen, anstatt als manuelle Notizen getrennt vom Entwicklungszyklus bestehen zu bleiben.
Warum LLM-as-a-judge nicht ausreicht
Elastic setzte Sprachmodelle ein, um Ausgaben anderer Modelle bei offenen oder unklaren Aufgaben zu bewerten, etwa hinsichtlich Stil, Konsistenz und Kontextangemessenheit der Antwort. Dieser Ansatz ermöglicht eine Ausweitung der Bewertung, wenn es schwierig ist, eine präzise Regel zur Beurteilung eines langen Textes zu formulieren. Allerdings kann er von einem Durchlauf zum nächsten unterschiedliche Ergebnisse liefern und bestimmte Fehler möglicherweise nicht erkennen, etwa eine nicht vorhandene Produkt-ID oder eine ungültig formulierte Abfrage.
Daher kombinierte Elastic LLM-as-a-judge mit deterministischen, regel- und programmierbasierten Bewertungen. Diese Prüfungen untersuchen die Struktur von JSON oder YAML, die Gültigkeit der Syntax, das Vorhandensein der erforderlichen Entitäten sowie die Ausführbarkeit des Codes oder der Abfrage, zusätzlich zu Metriken wie Genauigkeit, Recall und Faktenrichtigkeit. Diese Kombination senkt die Kosten und beschleunigt die Bewertung in Fällen mit einer eindeutigen Antwort und überlässt die semantische Beurteilung Aufgaben, die sich nur schwer auf Regeln reduzieren lassen.
Was lässt sich nicht verallgemeinern?
Elastic betrachtete die Erstellung spezialisierter Testdaten nicht als vollständig automatisierbaren Bestandteil. In der Cybersicherheit benötigt das Team Analysten und Forscher, die bestimmen, was einen echten Angriff ausmacht und welches Verhalten für den Endnutzer akzeptabel ist. Auch die Definition einer Regression unterscheidet sich zwischen den Agenten; ein Sicherheitsagent kann beispielsweise nach einem bestimmten Update eher dazu neigen, Angriffe zu melden, selbst wenn unkritische Daten eingegeben werden.
Die Kalibrierung der Evaluatoren bleibt in der Verantwortung jedes Teams. Wenn der Sprachevaluator denselben Fall unterschiedlich bewertet oder nicht mit dem angestrebten menschlichen Urteil übereinstimmt, wird das gemeinsame Framework unabhängig von der Qualität der Softwarearchitektur irreführende Zahlen liefern. Chang wies außerdem auf das Risiko einer Verzerrung des Evaluators hin, wenn zur Generierung und Bewertung Modelle derselben Modellfamilie eingesetzt werden, da diese die Leistung dieser Modelle möglicherweise überschätzen.
Was ändert sich für die Teams in der Praxis?
Die Erfahrung von Elastic empfiehlt, mit einer kleinen Gruppe von Testbeispielen zu beginnen, möglicherweise zwischen 20 und 50 Fällen, statt auf einen perfekten Datensatz zu warten. In den frühen Phasen kann eine verstreute Vorgehensweise akzeptabel sein, um das Lernen zu beschleunigen, insbesondere wenn Anwendungsfälle und Metriken noch ermittelt werden. Sobald jedoch mehrere Agenten in Produktion gehen, werden grundlegendes Tracing und grundlegende Bewertungen erforderlich, um Fragen zur Leistung zu beantworten und Nutzerprobleme zu diagnostizieren.
Elastic übertrug außerdem einige Bewertungswerkzeuge von Python nach TypeScript, um sie an den in TypeScript geschriebenen Produktionscode sowie an Playwright und ein speziell entwickeltes internes Tool namens Scout anzupassen. Dieser Schritt bedeutet nicht, dass alle Bewertungen aus der Datenwissenschaft übertragen werden müssen, sondern spiegelt einen konkreten Bedarf wider, die Lücke zwischen dem, was das Team testet, und dem, was das System tatsächlich ausführt, zu verringern. Die praktische Schlussfolgerung lautet, dass ein gemeinsames Framework Schema, Ausführung und allgemeine Metriken vereinheitlichen kann, aber weder die Fachkompetenz noch das Urteil darüber ersetzen kann, was als Erfolg und Misserfolg gelten sollte.