Eine Demo beweist nichts: So testen Sie einen KI-Agenten, bevor Kunden ihn sehen

Von Julian Ott, Managing Partner Technology bei Alpinity AI · Aktualisiert am 2. September 2026

Kurz gesagt: Im Benchmark τ-bench löst gpt-4o 61,2 Prozent der Detailhandelsaufgaben beim ersten Versuch, aber unter 25 Prozent, wenn acht Versuche hintereinander gelingen müssen (Yao et al., Preprint 2024). Eine Demo prüft den ersten Versuch. Ihre Kunden erleben den achten. Abnahme heisst deshalb: dieselbe Aufgabe mehrfach, mit festen Prüfern und einer vorher gesetzten Schwelle.

Eine Demo zeigt einen einzigen Durchlauf, kein Verhalten

In einer Demo stellt jemand die Frage, die er vorher getestet hat. Der Agent antwortet gut, alle nicken, das Projekt gilt als abgenommen. Was Sie gesehen haben, ist ein einzelner Durchlauf.

Wie wenig das aussagt, zeigt τ-bench, ein Prüfstand des Anbieters Sierra für Agenten, die mit Werkzeugen arbeiten und dabei mit einem Nutzer sprechen (Yao et al., Preprint 2024). Ein Benchmark ist eine feste Sammlung von Aufgaben mit bekannter Lösung, an der sich verschiedene Systeme vergleichen lassen. In der Auswertung löst gpt-4o im Detailhandel 61,2 Prozent der Aufgaben, im Fluggesellschafts-Bereich 35,2 Prozent, im Mittel 48,2 Prozent. Claude-3-opus erreicht 44,2 und 34,7 Prozent.

Interessanter als diese Werte ist die Messgrösse, welche die Arbeit einführt: pass^k. Sie zählt nur jene Aufgaben, die in k unabhängigen Durchläufen jedes Mal gelingen. pass^1 misst Können. pass^k misst Verlässlichkeit. Im Detailhandel fällt gpt-4o von 61,2 Prozent bei einem Versuch auf unter 25 Prozent bei acht Versuchen. Anders gesagt: Von den Aufgaben, die er bei einem Versuch löst, übersteht deutlich weniger als die Hälfte acht Versuche. Für einen Kundendienst ist genau das die relevante Zahl, denn Ihre Kunden stellen dieselbe Frage nicht einmal, sondern hundertmal.

Sobald der Kunde selbst mithandeln muss, sinken die Werte deutlich

Die zweite Lücke zwischen Demo und Alltag ist der Kunde. In den meisten Tests antwortet ein simulierter Nutzer nur. In Wirklichkeit muss er handeln: das Gerät neu starten, ein Dokument suchen, eine Nummer vorlesen.

Genau dafür haben dieselben Autoren τ²-bench gebaut, ebenfalls bei Sierra und ebenfalls ein Preprint (Barres et al., Preprint 2025). Der Aufbau heisst Dual Control: Agent und Kunde bedienen beide dasselbe System, der Agent muss den Kunden also anleiten, statt nur für ihn zu arbeiten. Das Ergebnis ist deutlich. Das Modell gpt-4.1 erreicht pass^1 von 74 Prozent im Detailhandel und 56 Prozent bei der Fluggesellschaft, in der Telekom-Domäne mit geteilter Kontrolle nur noch 34 Prozent. Claude-3.7-sonnet kommt dort auf 49 Prozent, gpt-4.1-mini und o4-mini liegen um 50 Prozent.

Für Ihre Abnahme heisst das: Ein Testfall, in dem der simulierte Kunde brav antwortet, ist der einfache Fall. Der schwierige Fall ist der Kunde, der etwas falsch versteht, abbricht oder zurückfragt. Wenn diese Fälle in Ihrer Testsuite fehlen, testen Sie das freundlichste Viertel Ihrer Kundschaft.

Derselbe Prompt liefert nicht zuverlässig dasselbe Ergebnis

Viele Abnahmen scheitern an einer stillen Annahme: Wenn der Test heute grün ist, ist er morgen wieder grün. Das stimmt nicht. Eine Untersuchung mit fünf Sprachmodellen, acht Aufgaben und je zehn Durchläufen fand Genauigkeitsunterschiede von bis zu 15 Prozentpunkten zwischen natürlich auftretenden Durchläufen, zwischen bestem und schlechtestem Fall bis zu 70 Prozentpunkten. Kein Modell lieferte über alle Aufgaben hinweg wiederholbare Genauigkeit, geschweige denn identische Ausgabetexte (Atil et al., Preprint 2025).

Die naheliegende Gegenmassnahme greift nur teilweise. Eine begutachtete Studie an 829 Programmieraufgaben hält fest, dass Temperatur 0, also die Einstellung für möglichst wenig Zufall bei der Wortwahl, keine Determiniertheit garantiert, sie aber gegenüber der Standardeinstellung verringert. Je nach Datensatz lieferten 75,76 Prozent, 51,00 Prozent und 47,56 Prozent der Aufgaben über mehrere Anfragen hinweg kein einziges identisches Testergebnis (Ouyang et al., TOSEM 2025).

Der Grund liegt nicht im Modell, sondern in der Maschine darunter. Gleitkommaaddition ist nicht assoziativ, das Ergebnis hängt also von der Reihenfolge der Summanden ab, und diese Reihenfolge ändert sich, wenn Ihre Anfrage mit anderen Anfragen zusammen verarbeitet wird (Thinking Machines, 10. September 2025). Praktische Folge: Ein einzelner grüner Testlauf ist kein Nachweis, sondern eine Stichprobe der Grösse eins.

Eine Testsuite braucht drei Arten von Prüfern

Wer testet, braucht jemanden, der entscheidet, ob eine Antwort richtig war. Dafür gibt es drei Möglichkeiten, und die Reihenfolge, in der man sie einsetzt, ist keine Geschmacksfrage. Anthropic empfiehlt in seiner Anleitung zu Agenten-Evaluationen ausdrücklich, deterministische Prüfer zu wählen, wo es geht, und Sprachmodelle als Prüfer nur, wo es nötig ist oder zusätzliche Flexibilität bringt (Anthropic Engineering, abgerufen am 2. September 2026). Google beschreibt für seinen Bewertungsdienst denselben Aufbau mit sogenannten rubric-based metrics, also festen Bewertungsrastern, die ein Sprachmodell anwendet (Google Cloud, Dokumentation, abgerufen am 2. September 2026).

Der Grund für diese Reihenfolge ist nüchtern: Eine feste Regel kostet nichts, liefert morgen dasselbe Urteil und ist für jeden im Projekt nachvollziehbar. Jede Prüfart darüber bringt eigene Fehler mit und muss selbst überwacht werden.

Ein Sprachmodell als Prüfer hat berechenbare Verzerrungen

Die Zahl, die den Einsatz von Sprachmodellen als Prüfer überhaupt rechtfertigt, stammt aus einer begutachteten Arbeit: Starke Modelle wie GPT-4 erreichen über 80 Prozent Übereinstimmung mit menschlichen Präferenzen, also dasselbe Niveau, das Menschen untereinander erreichen (Zheng et al., NeurIPS 2023). Veröffentlicht wurden dazu 3’000 Expertenstimmen und 30’000 Gespräche mit menschlichen Präferenzurteilen.

Dieselbe Arbeit benennt drei systematische Fehler solcher Prüfer. Die Positionsverzerrung bevorzugt die Antwort, die zuerst steht. Die Längenverzerrung bevorzugt die längere Antwort. Die Selbstbevorzugung lässt ein Modell die eigenen Ausgaben besser bewerten. Eine Übersichtsarbeit zum Feld ordnet diese Befunde ein und sammelt Gegenmassnahmen (Gu et al., Preprint 2024).

Daraus folgen vier Handgriffe, die wenig kosten: Reihenfolge der verglichenen Antworten in der Hälfte der Durchläufe tauschen, Antwortlänge begrenzen oder in der Bewertung ausklammern, als Prüfer ein anderes Modell einsetzen als das geprüfte, und eine feste Stichprobe von Hand gegenprüfen. Ohne diesen letzten Schritt wissen Sie nicht, ob Ihr Prüfer noch misst oder nur noch nickt.

Für Wissens-Chatbots sind drei Prüfgrössen etabliert

Beantwortet Ihr Agent Fragen aus eigenen Dokumenten, spricht man von RAG, also von einer Antwort, die auf zuvor abgerufenen Textstellen beruht. Dafür hat sich ein begutachtetes Verfahren mit drei Messgrössen durchgesetzt (Es et al., EACL 2024).

Faithfulness prüft, ob die Antwort im abgerufenen Kontext gedeckt ist, ob das Modell also nichts hinzuerfindet. Answer Relevance prüft, ob die Antwort tatsächlich die gestellte Frage trifft und nicht eine benachbarte. Context Relevance prüft, ob der abgerufene Kontext auf das Nötige beschränkt ist und möglichst wenig Irrelevantes enthält. Die drei Grössen trennen sauber, was sonst als ein einziges Gefühl von schlechter Antwort zusammenfällt: falscher Inhalt, falsches Thema, falsche Quelle.

Die Autoren haben ihre Bewertungen gegen Menschen geprüft. Bei Faithfulness und Context Relevance waren sich zwei Annotatoren in rund 95 Prozent der Fälle einig, bei Answer Relevance in rund 90 Prozent. Für die Abnahme heisst das: Diese drei Zahlen sind belastbar genug, um sie in einen Vertrag zu schreiben, wenn Sie den Datensatz und das Prüfmodell mit angeben.

Sieben Schritte führen von echten Fehlern zur Abnahme

1. Aufgaben aus echten Fehlern bilden. Nicht ausdenken, sondern sammeln: Mailpostfach, Chatverlauf, Telefonnotizen. 20 bis 50 einfache Aufgaben aus echten Fehlern sind laut Anthropic ein guter Anfang, und die Arbeit wird schwieriger, je länger man wartet (Anthropic Engineering, abgerufen am 2. September 2026).

2. Das Ergebnis bewerten, nicht den Weg. Prüfen Sie, was der Agent geliefert hat, nicht welche Werkzeuge er in welcher Reihenfolge aufgerufen hat. Feste Wegvorgaben machen Tests spröde: Anthropic berichtet von einem Modell, das eine τ²-bench-Aufgabe über eine Lücke in der Richtlinie löste und formal durchfiel, obwohl die Lösung für den Nutzer besser war.

3. pass^k messen, nicht pass^1. Jede Aufgabe mehrfach laufen lassen und nur zählen, was jedes Mal gelingt. Acht Durchläufe sind ein brauchbarer Ausgangswert, weil τ-bench dieselbe Grösse verwendet.

4. Kundenbeteiligung simulieren. Bauen Sie Fälle, in denen der simulierte Kunde etwas falsch versteht, abbricht, zurückfragt oder eine Angabe verweigert. Das ist der Bereich, in dem die Werte im Dual-Control-Test von 74 auf 34 Prozent fielen.

5. Regressionslauf vor jedem Modellwechsel. Neues Modell, neuer Systemprompt, neue Wissensbasis: Erst läuft die vollständige Suite gegen die zuletzt freigegebene Version, dann wird umgestellt.

6. Die Prüfer prüfen. Wenn ein Sprachmodell bewertet, ziehen Sie eine Stichprobe und lassen einen Menschen dieselben Fälle beurteilen. Weicht die Übereinstimmung deutlich von den über 80 Prozent aus der Literatur ab, ist Ihr Prüfraster das Problem, nicht der Agent.

7. Die Freigabe-Schwelle vor dem Lauf festlegen. Welcher pass^k-Wert genügt, welche Fälle müssen zu 100 Prozent stimmen, wer entscheidet bei Grenzfällen.

Auch der Benchmark selbst kann falsch messen

Bevor Sie sich an fremden Bestenlisten orientieren, lohnt ein Blick darauf, wie sauber die dort gestellten Aufgaben sind. OpenAI liess 93 erfahrene Python-Entwicklerinnen und -Entwickler 1’699 zufällig gezogene Aufgaben des Benchmarks SWE-bench von Hand sichten. Übrig blieben 500 Aufgaben, die als unproblematisch bestätigt wurden. Auf dieser bereinigten Menge erreicht gpt-4o 33,2 Prozent statt 16 Prozent auf dem ursprünglichen Satz (OpenAI, abgerufen am 2. September 2026). Ein grosser Teil des Unterschieds lag also an den Aufgaben, nicht am Modell.

Zwei weitere Arbeiten sind für die Erwartungshaltung nützlich. AgentBench prüft Sprachmodelle als Agenten in acht verschiedenen Umgebungen und nennt als Hauptursachen des Scheiterns langfristiges Schlussfolgern, Entscheiden und Anweisungstreue, nicht fehlendes Wissen (Liu et al., ICLR 2024). Und WebArena, eine realistische Weboberfläche aus vier Bereichen, misst für den besten GPT-4-Agenten eine Erfolgsquote von 14,41 Prozent gegenüber 78,24 Prozent beim Menschen (Zhou et al., ICLR 2024).

Diese Zahlen sind kein Grund, auf Agenten zu verzichten. Sie sind ein Grund, den Einsatzbereich eng zu schneiden und ihn mit eigenen Aufgaben zu prüfen statt mit fremden.

Werkzeuge verschwinden, das Verfahren bleibt

Wer seine Testfälle in der Konsole eines Anbieters ablegt, macht sich von dessen Produktplanung abhängig. Ein aktuelles Beispiel: Die Evals-Funktion von OpenAI wird laut Plattformdokumentation für bestehende Nutzer am 31. Oktober 2026 auf Lesezugriff umgestellt, die Abschaltung ist für den 30. November 2026 vorgesehen (OpenAI, Plattformdokumentation, abgerufen am 2. September 2026).

Die Konsequenz ist einfach: Aufgaben, erwartete Ergebnisse, Prüfregeln und Schwellen gehören in Ihr eigenes Repository, in einem Format, das Sie lesen können. Der Anbieter, der die Läufe ausführt, ist austauschbar. Ihre Testfälle sind es nicht, denn sie sind die einzige Stelle im Projekt, an der das Wissen über echte Kundenfehler schriftlich festgehalten ist.

Gegen das Werkzeug selbst spricht nichts. Eine Oberfläche, die Läufe startet, Ergebnisse speichert und Auswertungen zeigt, spart in den ersten Wochen viel Zeit. Sie darf nur nicht der einzige Ort sein, an dem Ihre Aufgaben liegen. Exportieren Sie die Suite regelmässig und prüfen Sie einmal im Jahr, ob ein vollständiger Lauf auch ohne dieses Werkzeug startet.

So machen wir das bei Alpinity AI

Wir bauen die Testsuite aus echten Anfragen des Kunden, bevor der Agent geschrieben wird. Dafür sichten wir Mailpostfach, Chatverlauf und Telefonnotizen und formen daraus 20 bis 50 Aufgaben mit erwartetem Ergebnis. Die Sammlung gehört dem Kunden.

Geprüft wird in der Reihenfolge aus der Tabelle oben. Termine, Preise, Öffnungszeiten und Adressen prüfen wir deterministisch, also mit festen Regeln gegen die Quelldaten, weil dort keine Auslegung erlaubt ist. Tonalität, Vollständigkeit und Rückfragen bewertet ein Sprachmodell als Prüfer, bei uns Claude Sonnet 5 von Anthropic. Eine wöchentliche Stichprobe prüft ein Mensch gegen. Vor dem Go-live läuft jede Aufgabe mehrfach, wir berichten pass^k statt eines Einzeldurchlaufs, die Freigabe-Schwelle steht vorher fest.

Die Schwellen in dieser Beispielkonfiguration legen wir in jedem Projekt gemeinsam mit dem Kunden fest.

suite: kundenagent_abnahme
quelle_der_aufgaben: echte_kundenanfragen
aufgaben: 32
wiederholungen_k: 8
freigabe_schwelle:
  pass_1: 0.90
  pass_8: 0.75
  kritische_faelle: 1.00
pruefer:
  - typ: deterministisch
    prueft: [termin, preis, oeffnungszeit, adresse]
  - typ: sprachmodell
    modell: claude-sonnet-5
    prueft: [tonalitaet, vollstaendigkeit]
    gegenprobe_mensch: 10
  - typ: mensch
    stichprobe: 10
kundenbeteiligung:
  simulierter_kunde: true
  szenarien: [unklare_frage, abbruch, nachfrage]
regressionslauf:
  ausloeser: [modellwechsel, promptaenderung]
  vergleich_gegen

suite: kundenagent_abnahme
quelle_der_aufgaben: echte_kundenanfragen
aufgaben: 32
wiederholungen_k: 8
freigabe_schwelle:
  pass_1: 0.90
  pass_8: 0.75
  kritische_faelle: 1.00
pruefer:
  - typ: deterministisch
    prueft: [termin, preis, oeffnungszeit, adresse]
  - typ: sprachmodell
    modell: claude-sonnet-5
    prueft: [tonalitaet, vollstaendigkeit]
    gegenprobe_mensch: 10
  - typ: mensch
    stichprobe: 10
kundenbeteiligung:
  simulierter_kunde: true
  szenarien: [unklare_frage, abbruch, nachfrage]
regressionslauf:
  ausloeser: [modellwechsel, promptaenderung]
  vergleich_gegen

suite: kundenagent_abnahme
quelle_der_aufgaben: echte_kundenanfragen
aufgaben: 32
wiederholungen_k: 8
freigabe_schwelle:
  pass_1: 0.90
  pass_8: 0.75
  kritische_faelle: 1.00
pruefer:
  - typ: deterministisch
    prueft: [termin, preis, oeffnungszeit, adresse]
  - typ: sprachmodell
    modell: claude-sonnet-5
    prueft: [tonalitaet, vollstaendigkeit]
    gegenprobe_mensch: 10
  - typ: mensch
    stichprobe: 10
kundenbeteiligung:
  simulierter_kunde: true
  szenarien: [unklare_frage, abbruch, nachfrage]
regressionslauf:
  ausloeser: [modellwechsel, promptaenderung]
  vergleich_gegen

Bei jedem Modellwechsel und jeder Prompt-Änderung läuft die vollständige Suite erneut gegen die zuletzt freigegebene Version. Betrieb und Protokolle liegen auf der Alpinity Agentenplattform, die Gesprächsverläufe sehen Sie im Alpinity Agentenportal über den Kunden-Login. Das Hosting erfolgt in der Schweiz oder EU, auf Wunsch ausschliesslich in der Schweiz. Ein Chatbot startet bei CHF 990 Setup plus CHF 99 pro Monat, den Festpreis nennen wir nach dem Scoping. Die Testsuite ist Teil des Projekts.

Was gilt weiter, wenn die Modelle besser werden

Die absoluten Zahlen in diesem Text werden altern, und zwar schnell. Aufgaben, an denen heutige Modelle scheitern, lösen die nächsten womöglich zuverlässig. Vier Dinge bleiben trotzdem.

Erstens verschiebt ein besseres Modell nur den pass^1-Wert. Solange Ihre Kunden dieselbe Frage hundertmal stellen, bleibt die Verlässlichkeit über Wiederholungen der Massstab, nicht das beste Einzelergebnis. Zweitens bleibt der Nichtdeterminismus, weil er aus der Rechenarchitektur stammt und nicht aus der Modellqualität (Thinking Machines, 10. September 2025). Drittens bleiben die Verzerrungen von Prüfmodellen bestehen, solange Modelle Modelle bewerten, weshalb die menschliche Stichprobe nicht wegfällt. Und viertens bleibt die Erkenntnis aus der Sichtung von SWE-bench: Ein Teil jedes gemessenen Fortschritts steckt in der Qualität der Aufgaben, nicht im geprüften System.

Was Sie von einem Anbieter verlangen sollten, ist deshalb unabhängig von der Modellgeneration: die Liste der Testaufgaben, die Anzahl Durchläufe, die Prüfart je Aufgabe und die Schwelle, die vor dem Lauf festgelegt wurde. Wer das nicht liefern kann, hat eine Demo gezeigt.

Quellen

• Yao, S., Shinn, N., Razavi, P., Narasimhan, K.: «τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains». Preprint vom 17. Juni 2024, Arbeit des Anbieters Sierra. arxiv.org/abs/2406.12045

• Barres, V., Dong, H., Ray, S., Si, X., Narasimhan, K.: «τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment». Preprint vom 9. Juni 2025, Arbeit des Anbieters Sierra. arxiv.org/abs/2506.07982

• Zheng, L. et al.: «Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena». Begutachtet, NeurIPS 2023 Datasets and Benchmarks Track. arxiv.org/abs/2306.05685

• Gu, J. et al.: «A Survey on LLM-as-a-Judge». Preprint, erste Fassung 2024. arxiv.org/abs/2411.15594

• Es, S., James, J., Espinosa Anke, L., Schockaert, S.: «RAGAs: Automated Evaluation of Retrieval Augmented Generation». Begutachtet, EACL 2024, System Demonstrations. aclanthology.org/2024.eacl-demo.16

• Liu, X. et al.: «AgentBench: Evaluating LLMs as Agents». Begutachtet, ICLR 2024. arxiv.org/abs/2308.03688

• Zhou, S. et al.: «WebArena: A Realistic Web Environment for Building Autonomous Agents». Begutachtet, ICLR 2024. arxiv.org/abs/2307.13854

• OpenAI: «Introducing SWE-bench Verified». Industriebericht, ohne Datumsangabe, abgerufen am 2. September 2026. openai.com/index/introducing-swe-bench-verified

• Atil, B. et al.: «Non-Determinism of ‹Deterministic› LLM Settings». Preprint, Fassung vom 2. April 2025. arxiv.org/abs/2408.04667

• Ouyang, S., Zhang, J. M., Harman, M., Wang, M.: «An Empirical Study of the Non-determinism of ChatGPT in Code Generation». Begutachtet, ACM TOSEM 2025. arxiv.org/abs/2308.02828

• Anthropic Engineering: «Demystifying evals for AI agents». Industriebericht, ohne Datumsangabe, abgerufen am 2. September 2026. anthropic.com/engineering/demystifying-evals-for-ai-agents

• He, H. und Thinking Machines: «Defeating Nondeterminism in LLM Inference». Industriebericht vom 10. September 2025. thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference

• OpenAI: «Evals», Plattformdokumentation. Anbieterangabe, abgerufen am 2. September 2026. platform.openai.com/docs/guides/evals

• Google Cloud: «Gen AI evaluation service overview». Anbieterangabe, abgerufen am 2. September 2026. cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview

Passende Leistung von Alpinity AI: KI-Automatisierung