„In der Demo hat es funktioniert“ ist der teuerste Satz in KI-Projekten. Demos laufen mit zehn freundlichen Fragen. Der Produktivbetrieb bringt Tausende echte – mit Tippfehlern, in mehreren Sprachen, verärgert, manchmal feindselig –, dazu Modell-Updates, um die niemand gebeten hat, und eine Wissensbasis, die sich jede Woche ändert.
Deshalb ist Qualität und nicht der Preis die größte Hürde für KI-Agenten. In LangChains State of Agent Engineering 2026 nennen 32 % der Teams die Qualität als Haupthindernis auf dem Weg in den Produktivbetrieb, vor der Latenz mit rund 20 % (LangChain-Umfrage). Gartner erwartet, dass bis Ende 2027 mehr als 40 % der agentischen KI-Projekte eingestellt werden (Gartner). Die Teams, die durchkommen, verbindet eine Gewohnheit: Sie messen Qualität systematisch, vor und nach dem Launch. Diese Gewohnheit heißt Evals.
Dieser Leitfaden erklärt, was Evals sind, wie Sie einen ersten Testdatensatz in Tagen aufbauen, welche Bewertungsmethode wofür taugt und wie Sie weiter messen, sobald echte Kunden kommen.
Was Evals sind – und warum Unit-Tests nicht reichen
Ein Eval ist ein wiederholbarer Test des KI-Verhaltens: ein fester Satz von Eingaben, eine Beschreibung, wie ein gutes Ergebnis aussieht, eine Bewertungsmethode und ein Schwellenwert. Klassische Softwaretests prüfen, ob eine Funktion den erwarteten Wert liefert. KI-Systeme ticken anders:
- Ausgaben schwanken. Dieselbe Frage kann unterschiedliche, gleich richtige Formulierungen erzeugen – und gelegentlich eine falsche.
- Änderungen haben Nebenwirkungen. Eine Prompt-Anpassung, die Fragen zu Erstattungen repariert, kann Versandfragen kaputt machen. Ein Modell-Update des Anbieters kann Tonfall, Länge oder Tool-Nutzung über Nacht verändern.
- „Fast richtig“ ist der typische Fehler. In der Stack-Overflow-Umfrage 2025 nannten 66 % der Entwickler KI-Antworten, die „fast richtig, aber eben nicht ganz“ sind, als größtes Ärgernis; 46 % misstrauen der Genauigkeit von KI (Stack Overflow). Genau dieses „fast richtig“ zeigt keine Demo.
Ein ausgereiftes Setup hat drei Ebenen:
- Offline-Evals auf einem kuratierten „goldenen“ Datensatz während der Entwicklung.
- Release-Gates, die die Evals bei jeder Änderung an Prompts, Modellen, Tools oder Retrieval automatisch erneut ausführen und die Auslieferung bei Rückschritten stoppen.
- Online-Evals, die laufend eine Stichprobe echter Gespräche aus dem Betrieb bewerten.
Schritt 1: „Gut“ in Geschäftsbegriffen definieren
Evals beginnen beim Geschäftsergebnis, nicht bei Modellmetriken. Für einen KI-Agenten im Kundenservice ist das Ergebnis ein korrekt gelöstes Ticket. Für eine Dokumentenstrecke ist es die richtig verbuchte Rechnung, für eine telefonische KI-Rezeption ein Termin mit der richtigen Uhrzeit, dem richtigen Namen und der richtigen Leistung.
Das ist auch kaufmännisch relevant. Plattformen rechnen bereits pro Ergebnis ab: Intercom Fin mit 0,99 US-Dollar pro Lösung (Intercom), Zendesk mit 1,50–2,00 US-Dollar pro automatisierter Lösung (Macha), HubSpot seit April 2026 mit 0,50 US-Dollar pro gelöstem Gespräch (Resolve247). Die Analysten von HFS warnen, dass die Definition einer „gelösten“ Anfrage zum nächsten Streitpunkt in Service-Level-Vereinbarungen wird – sie gehört in den Vertrag und muss überprüfbar sein (HFS Research). Wer pro Ergebnis zahlt oder bezahlt wird, macht seine Eval-Definitionen zum Vertragsbestandteil.
Zerlegen Sie das Ergebnis in messbare Dimensionen:
- Korrektheit: Fakten, Zahlen, Preise und Richtlinien stimmen mit der verbindlichen Quelle überein.
- Quellentreue: Jede Aussage ist durch abgerufene Dokumente belegt; nichts ist erfunden.
- Handlungsgenauigkeit: Das richtige Tool wurde mit den richtigen Parametern aufgerufen – Bestellnummer, Betrag, Datum.
- Regelkonformität: keine unzulässigen Zusagen, der vorgeschriebene KI-Hinweis ist vorhanden, Eskalation erfolgt, wenn sie nötig ist.
- Ton und Sprache: Antworten in der Sprache des Kunden und in Ihrer Markenstimme – im deutschen Kundenservice inklusive der Frage „Sie“ oder „du“.
- Latenz und Kosten: innerhalb des Budgets für den jeweiligen Kanal.
Schritt 2: Einen goldenen Datensatz in Tagen statt Monaten aufbauen
Sie brauchen für den Start keine Tausende Beispiele. Einige Dutzend bis wenige Hundert sorgfältig gewählte Fälle fangen die meisten Rückschritte ab. Gute Quellen:
- Echte Historie. Frühere Tickets, E-Mails, Gesprächsprotokolle und Dokumente, anonymisiert. Darin stecken die Fragen, die Kunden tatsächlich stellen, in ihren eigenen Worten.
- Der lange Schwanz. Seltene, aber teure Fälle: Kündigungen, Beschwerden, Anwaltsdrohungen, Großkunden, gemischte Sprachen.
- Fälle für „muss ablehnen“ und „muss eskalieren“. Anfragen außerhalb des Auftrags, medizinische oder rechtliche Beratung, ein verärgerter Kunde, der einen Menschen verlangt. Ein Agent, der alles beantwortet, ist ein Haftungsrisiko.
- Angriffsfälle. Versuche, den Systemprompt auszulesen, Rabatte zu erschleichen oder Anweisungen über Dokumente einzuschleusen – mehr dazu im Leitfaden zur Abwehr von Prompt Injection.
- Unbequeme Formate. Eingescannte PDFs, Handyfotos von Rechnungen, Sprachaufnahmen mit Hintergrundlärm.
Halten Sie für jeden Fall das erwartete Ergebnis fest: Fakten, die vorkommen müssen, Aussagen, die nicht vorkommen dürfen, den erwarteten Tool-Aufruf mit Parametern oder die erwarteten extrahierten Felder. Versionieren Sie den Datensatz in Git wie Code und nehmen Sie jeden Fehler aus dem Betrieb auf. Der Datensatz wächst mit jedem Vorfall.
Schritt 3: Die passende Bewertungsmethode wählen
| Methode | Was sie prüft | Stärken | Grenzen |
|---|---|---|---|
| Exakter oder strukturierter Abgleich | Extrahierte Felder, JSON-Schema, Tool-Argumente, Klassifikationen | Günstig, schnell, eindeutig | Nur für strukturierte Ausgaben |
| Regelbasierte Prüfungen | Verbotene Formulierungen, Pflichthinweise, Preise gegen Katalog, Formate | Deterministisch und leicht erklärbar | Kann keine Bedeutung beurteilen |
| LLM als Richter mit Rubrik | Korrektheit, Quellentreue, Hilfsbereitschaft, Ton | Skaliert auf Freitext, günstig pro Fall | Muss gegen menschliche Urteile kalibriert werden; kann verzerrt sein |
| Menschliche Prüfung | Alles, auch Nuancen | Goldstandard | Langsam und teuer; für Kalibrierung und Stichproben |
| Aufgabenerfolg in einer Sandbox | Hat der Agent die Aufgabe wirklich erledigt – Erstattung angelegt, Termin gebucht? | Misst Ergebnisse statt Worte | Braucht eine Testumgebung mit realistischen Daten |
| Sprachspezifische Metriken | Erkennung von Namen, Zahlen und Daten; Unterbrechungen; Antwortlatenz | Erfasst, was Text-Evals übersehen | Erfordert Audio-Testsätze |
Zwei Tipps. Erstens: Setzen Sie deterministische Prüfungen ein, wo immer es geht, und heben Sie sich den LLM-Richter für das auf, was wirklich Urteilsvermögen braucht. Zweitens: Kalibrieren Sie den Richter. Lassen Sie Menschen 50–100 Fälle bewerten, vergleichen Sie deren Urteile mit den Bewertungen des Richters und schärfen Sie die Rubrik, bis beide übereinstimmen. Ein Modell sollte nie mit demselben Prompt seine eigenen Antworten benoten.
Telefon-Anwendungen verdienen besondere Sorgfalt. Laut AssemblyAI ist die Spracherkennung unter realen Bedingungen typischerweise zwei- bis dreimal schlechter als in Laborbenchmarks (AssemblyAI), und Telefonaudio verschlechtert sie weiter. Namen, Adressen, Telefonnummern und Daten sind die häufigsten Fehlerquellen von Voice-Agenten – gerade bei deutschen Straßennamen und Nachnamen. Testen Sie genau diese.
Schritt 4: Schwellenwerte und Release-Gates
Ein Eval ohne Schwellenwert ist ein Bericht, den niemand liest. Legen Sie pro Dimension fest, was akzeptabel ist, und trennen Sie Durchschnittswerte von kritischen Fehlern.
Hier ein Beispiel-Evalplan für einen Kundenservice-Agenten. Die Werte sind illustrativ; legen Sie Ihre eigenen nach Risiko fest.
| Dimension | Metrik | Methode | Beispiel-Schwellenwert |
|---|---|---|---|
| Lösung | Anteil der Fälle, die vollständig korrekt gelöst werden | Sandbox-Erfolg plus menschliche Stichprobe | Mindestens das heutige Niveau des Teams |
| Quellentreue | Anteil der Antworten, die vollständig durch Quellen belegt sind | Kalibrierter LLM-Richter | 95 % oder mehr |
| Kritische Fehler | Falscher Preis, falscher Erstattungsbetrag, Daten eines anderen Kunden | Regeln plus strukturierter Abgleich | Null Toleranz |
| Eskalation | Pflicht-Eskalationen an einen Menschen übergeben | Strukturierter Abgleich | 100 % |
| KI-Hinweis | Hinweis vorhanden, wo vorgeschrieben (EU AI Act, Art. 50) | Regelprüfung | 100 % |
| Latenz | p95-Antwortzeit | Logs | Kanalbudget, z. B. unter 3 Sekunden im Chat |
| Kosten | Kosten pro gelöstem Fall | Gateway-Logs | Im Rahmen des Business Case |
Lassen Sie die vollständige Suite bei jeder Änderung laufen: Prompt, Modell, Tool-Definition, Retrieval-Einstellung, Import in die Wissensbasis. Stoppen Sie die Auslieferung, wenn eine kritische Metrik sinkt. Beim Modellvergleich nutzen Sie denselben Datensatz und betrachten Qualität, Latenz und Kosten nebeneinander. Genau diese Belege braucht ein LLM-Gateway, um Verkehr sicher auf günstigere Modelle zu verlagern.
Schritt 5: Nach dem Launch weiter messen
Mit dem Launch beginnt der echte Datensatz zu entstehen. Online-Evals schließen den Kreis:
- Eine Stichprobe echter Gespräche bewerten – mit derselben Rubrik, bei neuen Systemen täglich, im stabilen Betrieb wöchentlich. Automatisierte Bewertung macht eine vollständige Abdeckung bezahlbar: Klassische Qualitätssicherung im Contact Center prüft typischerweise nur 1–2 % der Anrufe (AssemblyAI). Als Preisanker: Retell berechnet für automatisierte Qualitätsprüfung von Voice-Agenten 0,10 US-Dollar pro Minute (Retell).
- Verhaltenssignale verfolgen. Eskalationsquote, erneute Kontakte innerhalb von 48 Stunden, negative Bewertungen, abgebrochene Gespräche, manuelle Korrekturen in nachgelagerten Systemen.
- Auf Drift achten. Eine veraltete Wissensbasis ist die häufigste Ursache steigender Halluzinationen einige Monate nach dem Launch; Modell-Updates der Anbieter folgen auf Platz zwei. Nach jedem Update die Offline-Suite erneut ausführen.
- Konfidenzschwellen nutzen. Lassen Sie das System an einen Menschen übergeben, wenn es unsicher ist. Ein Anbieter von CRM-Agenten etwa eskaliert automatisch, sobald die Relevanz der abgerufenen Inhalte unter 0,40 fällt (NOVA). Der genaue Wert ist weniger wichtig, als überhaupt einen zu haben und ihn datenbasiert nachzujustieren.
- Fehler zurückspielen. Jeder ernsthafte Fehler im Betrieb wird zum neuen Testfall – so kann er nie unbemerkt zurückkehren.
Wie gute Ergebnisse aussehen
Evals verwandeln vage Versprechen in Zahlen. Einige veröffentlichte Beispiele – allesamt Herstellerangaben, also eher Richtung als Benchmark:
- Fractional AI berichtet von 80 % weniger Halluzinationen in einem für Zapier gebauten KI-System (Fractional AI).
- Vstorm nennt ein Projekt, in dem die Genauigkeit von 44 % auf 98 % stieg (Vstorm).
- Salesforce zufolge sehen 70 % der Serviceorganisationen mit KI-Agenten innerhalb der ersten 60 Tage einen messbaren Effekt (Salesforce).
Gemeinsam ist diesen Fällen kein besseres Modell, sondern ein gemessener Kreislauf: Ausgangswert, Änderung, erneute Messung.
Wer die Evals verantwortet
Evals scheitern häufiger an der Organisation als an der Technik. Drei Rollen machen sie wirksam:
- Ein fachlich Verantwortlicher – Leitung Kundenservice, Operations oder Vertrieb – definiert, was „gut“ heißt, gibt Schwellenwerte frei und trägt die Abwägung zwischen Automatisierungsgrad und Risiko.
- Fachexperten – erfahrene Servicekräfte, Buchhalterinnen, Disponenten – bewerten Fälle und prüfen Stichproben. Zwei Stunden pro Woche von der richtigen Person sind mehr wert als tausend synthetische Beispiele.
- Ein technisch Verantwortlicher pflegt Testumgebung, Release-Gates und Dashboards und sorgt dafür, dass jeder Vorfall zum Testfall wird.
Setzen Sie den monatlichen Eval-Bericht auf dieselbe Agenda wie die übrigen operativen Kennzahlen. Stehen Qualitätswerte neben Kosten und Volumen, werden Entscheidungen über Modelle, Prompts und Automatisierungsumfang faktenbasiert statt anekdotisch.
Werkzeuge: einfach anfangen
Für den Start genügen eine Tabelle mit Testfällen und ein Skript, das Ihr System aufruft und die Ergebnisse bewertet. Wächst das Volumen, kommen Tracing- und Evaluierungswerkzeuge hinzu. Langfuse oder Helicone für Traces und Scores, Sentry für Fehler und PostHog für Produktsignale sind eine verbreitete Kombination in produktiven KI-Paketen (HouseofMVPs).
Egal, womit Sie arbeiten: Datensätze, Rubriken und Ergebnisse gehören in Systeme, die Ihnen gehören – nicht nur in das Dashboard eines Anbieters. Nach Ihren Daten selbst sind sie das wertvollste Gut eines KI-Projekts: Mit ihnen können Sie Modell, Anbieter oder Agentur wechseln, ohne bei null anzufangen.
Typische Fehler
- Mit den Demo-Fragen testen. Ist der Datensatz leicht, ist der Score wertlos.
- Text bewerten, Handlungen nicht. Eine höfliche Antwort mit falschem Erstattungsbetrag ist ein Fehler.
- Kritische Fehler im Durchschnitt verstecken. 97 % im Mittel können ein Datenleck enthalten.
- Unkalibrierte LLM-Richter oder ein Modell, das sich selbst benotet.
- Keine Ablehnungs- oder Eskalationsfälle – dann wird der Agent dafür belohnt, alles zu beantworten.
- Evals einmal vor dem Launch, danach nie wieder. Modelle, Daten und Kunden ändern sich ständig.
- Unversionierte Prompts und Datensätze – dann lässt sich nicht klären, was einen Rückschritt verursacht hat.
Fazit
Evals sind die günstigste Versicherung im KI-Geschäft. Ein goldener Datensatz aus echten Fällen, eine Handvoll gut gewählter Metriken mit Schwellenwerten, automatische Release-Gates und laufende Bewertung des Live-Verkehrs machen aus einer beeindruckenden Demo ein System, dem Sie vertrauen – und das Sie kalkulieren – können. Den meisten festgefahrenen Pilotprojekten, die wir sehen, fehlt kein besseres Modell, sondern ein Beleg dafür, dass das vorhandene funktioniert. Wenn Ihnen das bekannt vorkommt, lesen Sie als Nächstes, wie KI-Piloten in den Produktivbetrieb kommen.
Unser Systems-Team baut Eval-Suiten, Release-Gates und Qualitäts-Dashboards für Service-, Voice- und Dokumenten-Agenten. Vereinbaren Sie ein kostenloses 15-Minuten-Audit – wir prüfen, wie Ihre KI-Qualität heute gemessen wird und wo die blinden Flecken liegen.