KI-Agenten testen: ein Eval-Set, das seinen Aufwand wert ist
Die Frage, die startende Agenten von ewigen Piloten trennt, ist schlicht: Woher wissen Sie, ob die gestrige Änderung es besser gemacht hat? Ohne Antwort ist jede Prompt-Änderung ein Ratespiel, und jede Regression entdeckt eine Kundin.
Ein Eval-Set ist die Antwort, und es braucht keine Plattform. Fünfzig Fälle in einer Datei, ein Skript, das sie ausführt, und eine Bewertungsregel je Fall sagen mehr als jedes Leaderboard — weil es Ihre Fälle sind.
Wie ein Fall aussieht#
Ein Fall besteht aus Eingabe, Ausgangszustand der Welt und einer prüfbaren Erwartung. Die Erwartung ist fast nie eine exakte Zeichenkette — ein Agent kann in mehreren Formulierungen richtig liegen. Bewerten Sie stattdessen das Ergebnis: hat er das Rückerstattungswerkzeug mit Bestellung 4471 aufgerufen; enthält die Antwort das korrekte Lieferdatum; hat er richtigerweise abgelehnt und nachgefragt. Wo Prosaqualität zählt, ist ein modellbewertetes Kriterienraster in Ordnung, wenn es kurz bleibt und stichprobenartig von Hand geprüft wird.
Speichern Sie den nötigen Zustand — die Fixture — beim Fall. Ein Test, der nur dienstags wegen Livedaten besteht, ist kein Test.
Fünfzig Fälle und ihre Herkunft#
| Quelle | Etwa wie viele | Warum |
|---|---|---|
| Häufige echte Anfragen aus Logs | 20 | Schützt den Alltagspfad |
| Bekannte frühere Fehler | 10 | Verhindert wiederkehrende Regressionen |
| Mehrdeutige Eingaben | 8 | Sollte fragen statt raten |
| Fälle, die abzulehnen sind | 6 | Außerhalb des Auftrags, unbefugt, unsicher |
| Leere oder kaputte Werkzeugergebnisse | 6 | Der häufigste reale Vorfall |
Ergebnisse bewerten, nicht Wege#
Zwei Läufe, die auf verschiedenen Wegen zum selben richtigen Ergebnis kommen, sind beide korrekt; eine Suite, die auf einem Protokoll besteht, schlägt grundlos ständig fehl. Prüfen Sie, was sich geändert hat und was gesagt wurde: Werkzeugaufrufe mit Seiteneffekt, Kernfakten der Antwort, ob ein menschliches Tor angefordert wurde. Den vollen Trace speichern Sie zum Debuggen, aber prüfen ihn nicht — sonst sieht jede Verbesserung wie hundert Fehler aus.
Vier Zahlen über die Zeit#
- Erfolgsquote über das ganze Set und separat über die Ablehnungsfälle.
- Quote unbelegter Aussagen — Antworten mit Fakten, die nicht in den Belegen stehen.
- Median und 95. Perzentil von Kosten und Latenz pro Lauf.
- Interventionsquote: wie oft ein Mensch eingreifen musste und warum.
In der Pipeline und nach dem Start#
Lassen Sie das Set bei jeder Änderung an Prompts, Werkzeugen, Modellversion oder Retrieval laufen — nur diese vier ändern Verhalten, und alle vier ändern sich öfter als gedacht. Nach dem Start weiter aus echtem Traffic ziehen: täglich ein paar Läufe von Hand bewerten und Überraschendes ins Set aufnehmen. Ein Eval-Set, das nicht wächst, repräsentiert Ihre Nutzer meist schon nach einem Quartal nicht mehr.
Häufige Fragen
Wie viele Fälle zum Start?
Fünfzig fangen echte Regressionen ab und sind in wenigen Tagen geschrieben. Zwanzig reichen zum Anfangen. Wichtiger als die Zahl ist die Abdeckung der unangenehmen Kategorien: mehrdeutige Eingaben, Ablehnungsfälle und leere Werkzeugergebnisse.
Darf ein Modell bewerten?
Ja, mit Sorgfalt. Geben Sie explizite Kriterien statt der Frage, ob die Antwort gut sei, halten Sie das Raster kurz und prüfen Sie regelmäßig stichprobenartig. Bewertermodelle driften, und ein gedriftetes Modell winkt Regressionen durch.
Soll Evaluation Deployments blockieren?
Blockieren Sie beim sicherheitskritischen Teil — Ablehnungsfälle und alles Unumkehrbare. Für allgemeine Qualität verfolgen Sie den Trend und verlangen bei einem Abfall eine menschliche Entscheidung; kleine Bewegungen können Rauschen sein.
ki agenten evaluierenagenten testllm eval setllm regressionstestagenten qualitätsmetriken
