Bewertung von Agenten mit einem Reisebot: Ergebnis gegen Verlauf, Schwellenwerte und Pass^k.

Agenten rufen nicht einfach nur APIs auf. Sie denken logisch, wählen im Eiltempo Werkzeuge aus, erstellen mehrstufige Pläne und bewältigen Aufgaben mit offenen Enden, die früher stundenlange menschliche Arbeit erforderten. Sobald jedoch etwas in die Produktion geht, taucht eine unangenehme Frage auf: Wie weiß man, dass es funktioniert?

Nicht mit dem bevorzugten Demo-Auftrag heute, sondern nächste Woche – nachdem jemand die Systemanweisungen geändert, ein Werkzeug hinzugefügt, das zugrunde liegende Modell ausgetauscht oder den Prompt angepasst hat. Hat diese Änderung etwas verbessert und dabei heimlich drei andere Dinge beschädigt?

Normale Software verfügt über deterministische Einheitstests wie assert add(2, 2) == 4. Agenten hingegen sind probabilistisch und können unterschiedliche Wege zum selben Ziel einschlagen, weshalb ein einfacher String-Vergleich des Endtextes unzureichend ist. Agent-Evals schließen diese Lücke.

Die Analogie zum Mathematiktest

Stellen Sie sich einen Lehrer vor, der einen Test bewertet, indem er nur auf die Endzahl schaut. Zwei Dinge laufen dann falsch:

1. Der glückliche Zufall. Die Herangehensweise ist unsinnig, zwei Rechenfehler heben sich gegenseitig auf, und die Antwort entsteht rein zufällig.
2. Der Fehler am Ende. Die Methode ist fehlerfrei und das Theorem verstanden, doch ein Tippfehler am Ende führt dazu, dass anstelle von 42 die Zahl 41 steht.

Ein guter Lehrer bewertet sowohl die Methode als auch die Antwort. Agenten verdienen dieselbe Beurteilung, denn ein Agent führt eine Abfolge von Schritten aus: Toolaufrufe, Suchvorgänge, formatierte Objekte sowie Entscheidungen bezüglich des Zustands. Eine faire Beurteilung bedeutet, zwei Aspekte zu messen:

• Ergebnis: das von ihm erzielte Geschäftsergebnis.
• Verlauf: der Weg, den er dazu eingeschlagen hat.

Einfach ausgedrückt besteht die Bewertung eines Agenten aus der Bewertung des Ergebnisses plus der Bewertung des Verlaufs, wobei beide Aspekte im selben Test mithilfe einer Kombination aus festgelegten Prüfungen und flexiblen Beurteilungskriterien gemessen werden.

Zwei Achsen zur Bewertung

Jeder Agent kann anhand von zwei unabhängigen Dimensionen überprüft werden.

Was wird untersucht?

• Ausgangsprüfungen prüfen, ob das richtige Endresultat vorliegt – beispielsweise der korrekte Flug, der richtige Hotelpreis oder die richtige Buchungsdatenbank.
• Trägheitsprüfungen prüfen, ob der Agent zuverlässig dorthin gelangt ist: Werkzeuge wurden in logischer Reihenfolge aufgerufen, gültige Parameter übergeben und es kam zu keinem endlosen Schleifenverhalten.

Wie wird bewertet?

• Deterministische Prüfungen beziehen sich auf Fakten mit objektiver Antwort. Ein Preis ist entweder 150 Dollar oder nicht, und ein Werkzeug wurde entweder aufgerufen oder nicht. Einfache Codeassertionen kümmern sich darum.

Prüfungen auf der Grundlage von Urteilen umfassen alles, was Kontext, Absicht oder Nuancen erfordert. Wurde „Budget“ fälschlicherweise als „Wirtschaft“ interpretiert? Passt das ausgewählte Hotel zu dem, was der Nutzer tatsächlich meinte? Ein LLM, das als neutrale Bewertungsinstanz fungiert, bewertet diese Aspekte.

Ein konkretes Beispiel: ein Reisebuchungsagent

Nehmen wir einen Agenten, der Reiserouten verarbeitet. Die Anfrage lautet: ein günstiger Flug, drei Übernachtungen in New York sowie eine Fahrt vom Flughafen. Dafür kann er Tools wie search_flights, search_hotels, book_flight, book_hotel und book_airport_transfer verwenden.

Bahnmetriken analysieren das Ausführungslog, die Aufrufreihenfolge, die Tool-Argumente sowie die Schlussfolgerungsspuren. Typische Fragen: Hat das System vor dem Handeln einen Plan erstellt? Wurden die Suchvorgänge vor den Buchungen durchgeführt? Stimmen die Hoteldaten mit den Flugdaten überein? Wurden überflüssige Aufrufe vermieden?

Ergebnismetriken prüfen die tatsächlich von dem Agenten erstellten Buchungsobjekte: den Tarif, die Tagesrate, den Transfer, die Währung sowie die Datumsangaben.

Prüfpunkte vor Durchschnitten

Eine Lektion, die meist schmerzhaft gelernt wird: Nicht jede Metrik gehört in einen einzigen Durchschnittswert. Stellen Sie sich einen Agenten vor, der aufgrund eleganter Schlussfolgerungen und einer perfekten Tool-Reihenfolge insgesamt 95 Prozent erreicht, aber den Flug für 1.500 Dollar statt für 150 Dollar bucht. In der Praxis handelt es sich dabei nicht um eine A-Klasse-Leistung – es ist ein Buchungsdesaster.

Damit starke Ergebnisse bei der Argumentation nicht kritische Fehler im Geschäftsablauf verdecken, kann die Bewertung in zwei Phasen durchgeführt werden.

Phase 1: Die Kontrollstufe. Zunächst werden deterministische Überprüfungen an kritischen Feldern durchgeführt: Preise, Daten, Währung, Abrechnungsidentifikatoren sowie Auslöser für Gebühren. Fällt eine dieser Kontrollen durch, scheitert das gesamte Testverfahren sofort. Keine noch so gute Argumentation kann das ändern.

Phase 2: Die gewichtete Bewertungskriterienliste. Nur Testverfahren, die alle Kontrollstufen bestehen, erhalten eine Qualitätsbewertung, die anhand weiterer Kriterien wie Effizienz der Tools, Qualität der Argumentation, Einhaltung des Plans und semantischer Übereinstimmung ermittelt wird. Die Regel ist einfach: Wenn die Kontrollstufe bestanden wurde und die gewichtete Bewertung den Schwellenwert erreicht oder überschreitet – sagen wir 0,85 – gilt das Testverfahren als bestanden.

Fehlerdiagnose mit einer 2x2-Matrix

Ein einziger „82%ige Bestehensrate“ sagt Ihnen nichts Nützliches für das Debuggen. Sie müssen wissen, warum die Ausführungen fehlgeschlagen sind, damit Sie entscheiden können, ob Sie den Prompt, die Tools oder das Datenset korrigieren sollen. Zeichnen Sie das Ergebnis in Abhängigkeit von der Vorgehensweise auf – es erscheinen vier Quadranten:

• Gute Vorgehensweise, gutes Ergebnis: das Ziel erreicht.
• Schlechte Vorgehensweise, gutes Ergebnis: ein glücklicher Zufall sowie ein drohendes Risiko.
• Gute Vorgehensweise, schlechtes Ergebnis: ein Fehler in der Endphase, meist ein Problem mit den Tools oder den Daten.
• Schlechte Vorgehensweise, schlechtes Ergebnis: ein grundlegender Fehler, der eine Neuarbeit erfordert.

Eine End-zu-End-Aufzeichnung

So würde der Pipeline einen Versuch des Buchungsagenten verarbeiten. Er beginnt mit der Anfrage des Benutzers sowie der Aufzeichnung des Agenten, die mit einem Plan startet (Flüge suchen, Hotels suchen, beides buchen, Transfer hinzufügen) und anschließend jede Überlegung sowie jeden Tool-Aufruf in der richtigen Reihenfolge protokolliert.

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

Danach prüft die Prüfstelle die für die Mission entscheidenden Felder: Flugpreis, Hotelkosten pro Nacht und Transferkosten. Angenommen, alle drei Werte entsprechen den erwarteten Werten von 150 Dollar, 120 Dollar pro Nacht und 35 Dollar. Die Prüfstelle gibt grünes Licht, und der Test geht in die Stufe 2 über.

In Stufe 2 erhält jede verbleibende Metrik eine Bewertung zwischen 0 und 1, die mit ihrem Gewicht multipliziert wird; die Gewichte summieren sich auf 1. Zur Veranschaulichung: Angenommen, fünf Metriken haben die Gewichte 0,20, 0,20, 0,15, 0,15 und 0,30 sowie die Bewertungen 1,0, 1,0, 0,8, 1,0 und 0,95. Die gewichtete Gesamtbewertung beträgt 0,20 + 0,20 + 0,12 + 0,15 + 0,285, was 0,955 entspricht. Im Vergleich zum vor dem Test festgelegten Schwellenwert von 0,85 gilt dies als Bestehen.

Anschließend wird das Ergebnis mit drei Fakten festgehalten: Die Prüfstelle gab grünes Licht, die gewichtete Bewertung übertraf den Schwellenwert und die Diagnosematrix ordnete den Test in die Kategorie „guter Weg, gutes Ergebnis“ ein.

Varianzmessung mit pass@k und pass^k

Ein einziger Versuch sagt nicht die ganze Wahrheit, da Agenten nicht-deterministisch sind. Führt man denselben Prompt mit denselben Werkzeugen zehn Minuten später aus, kann das Modell zuerst nach Hotels suchen, einen Argumentationsablauf anders gestalten oder auf einer anderen Logikkette argumentieren. Ein Test, der heute bestanden hat, kann bei identischen Eingaben morgen fehlschlagen.

In Anthropics technischem Dokument zur Bewertung von Agenten werden zwei Statistiken beschrieben, um diese Varianz in den Griff zu bekommen: pass@k und pass^k.

pass@k: Fähigkeit

Hier geht es darum, ob bei mindestens einem von k getrennten Versuchen Erfolg erzielt wird. Mit zunehmendem Wert von k steigt auch die Bewertung, da mehr Versuche eine Erfolgschance erhöhen. Diese Metrik wurde durch OpenAI’s HumanEval-Projekt zur Codegenerierung bekannt, bei dem ein System mehrere Programmvorschläge erstellt und überprüft, ob einer die Einheitstests besteht.

Es eignet sich für Konfigurationen mit menschlicher Überwachung sowie Systeme mit automatisierten Validatoren: drei Entwürfe für Reiseverantwortliche zur Auswahl oder fünf mögliche SQL-Abfragen, wobei ein Motor die erste gültige Abfrage ausführt.

pass^k: Konsistenz

Dies ist die Wahrscheinlichkeit, dass der Agent bei k Versuchen jedes Mal erfolgreich ist – also die pro Versuch liegende Rate p hoch zur Potenz k. Mit zunehmendem k sinkt die Wertigkeit schnell. Angenommen, der Agent schafft 75 % der einzelnen Versuche:

• ein Versuch: 75,0 %,
• drei aufeinanderfolgende Versuche: etwa 42,2 %,
• fünf aufeinanderfolgende Versuche: etwa 23,7 %,
• zehn aufeinanderfolgende Versuche: etwa 5,6 %.

Dies ist die Messgröße für den autonomen, missionkritischen Einsatz in der Produktion. Wenn der Buchungsagent mit Zahlungskarten und Anbieter-APIs verbunden ist, kümmert es die Nutzer nicht, wenn er nur einmal von fünf Versuchen erfolgreich ist – sie benötigen eine zuverlässige Funktionsweise bei jedem Versuch.

Warum die Wahl wichtig ist

Bei k gleich 1 sind die beiden Metriken identisch und entsprechen dem Basis-Erfolgsgrad. Bei k gleich 10 erzählen sie gegensätzliche Geschichten: pass@k nähert sich 100 % an, da ausreichend viele Versuche letztendlich zum Erfolg führen werden, während pass^k auf null zusteuert, da zehn fehlerfreie Abläufe ohne einzige Fehlleistung oder Tool-Fehler schwierig sind. Die Auswahl der Metrik, die den Versprechen Ihres Produkts entspricht, unterscheidet leere Benchmarks von echter Zuverlässigkeit.

Praktische Erkenntnisse

1. Testen Sie nicht nur die endgültige Antwort. Ein Agent, der durch fehlerhafte Logik zur richtigen Antwort gelangt, stellt ein Produktionsrisiko dar.
2. Mischen Sie Code und LLM-Bewerter. Verwenden Sie deterministischen Code für Preise, IDs und Präsenzprüfungen sowie LLM-Bewerter für die Qualität der Logik, die Einhaltung des Plans und die Abstimmung mit der Absicht.

Sicherstellen, dass nichts falsch gehen kann. Ein elegantes Berechnungsverfahren sollte nicht in der Lage sein, einen falschen Preis, eine schlechte Währung oder ein fehlerhaftes Datum im Durchschnitt zu verwässern.

Evaluierungen wie CI behandeln. Führen Sie den Testzyklus jedes Mal aus, wenn sich eine Anfrage oder ein Modell ändert, damit Regressionen bereits vor dem Erkennen durch die Nutzer aufgedeckt werden.

Toxische Agenten entstehen nicht daraus, dass man hofft, das Modell verhalte sich heute richtig. Sie entstehen durch ein System, das täglich überprüft, ob dies der Fall ist.