LLM Evaluation: Halluzination und Task-Erfolg 2026

Constantin, Consultant für GenAI bei Pexon Consulting | 10 Min. Lesezeit | 16.09.2026

TL;DR: llm evaluation halluzination

LLM Evaluation für Assistenten misst 2026 zwei Dinge: erfindet das Modell Fakten, und erledigt es die Aufgabe. Faithfulness allein reicht nicht. RAGAS bleibt Werkzeug. Die Scorekarte steuert den Rollout an der Control Plane. Methoden-Metriken bleiben auf RAG evaluieren und testen.

Das Problem: flüssig falsch schlägt stockend richtig

Das Modell klingt sicher und liegt falsch. Tarif, Vertrag, Störung. Genau das hören wir in Anfragen, die Evaluation und Betrieb in einem Atemzug nennen. RAGAS läuft im Notebook. Produktion hat kein Gate. Fachbereiche sehen eine glatte Antwort und glauben sie.

Halluzination ist nicht nur „falsche Zahl“. Halluzination ist eine Behauptung ohne Beleg in Quelle oder Tool-Ergebnis. Task-Erfolg ist nicht „Antwort generiert“. Task-Erfolg ist: Ticket geroutet, Störung gelöst, Formular korrekt, Freigabe eingeholt.

Wer nur Faithfulness misst, belohnt gute Zitate und verpasst den Job. Wer nur Task-Erfolg misst, belohnt Shortcuts und erfundete Felder. Beides zusammen ist der Assistenten-Job.

Diese Seite schreibt die Methoden-LP nicht um. Retrieval- und Generation-Metriken bleiben dort. Glossar und RAGAS-Blogs bleiben Lemma und Tool-TOFU. Hier geht es um die Scorekarte für den Assistenten.

Was ist Task-Erfolg – und warum reicht Faithfulness nicht?

Task-Erfolg ist eine binäre oder gestufte Aussage über den Auftrag, nicht über den Stil. Beispiele aus Telko und Fertigung ohne Kundennamen:

1. Tariffrage: korrekte Option genannt, keine erfundene Rabattzeile.
2. Störung: richtiges Routing an den Fachbereich, keine Schein-Lösung.
3. Wartungs-PDF: Schrittfolge aus dem Dokument, kein erfundenes Drehmoment.

Faithfulness fragt: hängt die Antwort am gelieferten Kontext. Das ist nötig. Es reicht nicht, wenn der Kontext die Aufgabe gar nicht trägt oder der Agent ein Tool braucht und keines aufruft.

Wir trennen deshalb drei Ebenen:

Ragas und ähnliche Suites decken die ersten zwei gut ab. Der Assistenten-Job braucht zusätzlich feste Cases mit erwartetem Ausgang. Sonst optimieren Sie Metriken, die der Fachbereich nie sieht.

Ein zweiter Fehler: Task-Erfolg nur als „Nutzer hat gedankt“ zu zählen. Dank ist Sentiment, nicht Auftrag. Besser ist ein beobachtbarer Ausgang im System: Status gesetzt, Mail raus, Feld geschrieben, Ticket geschlossen. Wenn der Assistent nur Text liefert, definieren Sie den Erfolg als korrekte Handlungsempfehlung mit Beleg, nicht als höflichen Absatz.

Wann gehört die Scorekarte ins Gateway, wann ins Notebook?

Notebook und CI sind der Ort für Regression: feste Gold-Fragen, Diff bei Prompt- oder Modellwechsel. Das Gateway und die Control Plane sind der Ort für Betriebssignale: Spend, Rate-Limits, Audit, wer darf welches Modell.

Bei Pexon ist die Control Plane LiteLLM, siehe LiteLLM-Hub. Evaluation ersetzt die Plane nicht. Die Plane liefert den Rahmen, in dem Sie ein Gate scharf schalten: bei Score unter Schwelle kein Rollout, bei PII-Treffer fail-closed, bei Budget-Stopp kein stiller Overflow.

Foundry-Evals und herstellereigene Evaluatoren sind Fläche oder Plattform-Feature. Sie ersetzen nicht Ihre fachlichen Cases. Azure AI Foundry bleibt Fläche der offenen Plattform, nicht zweite Marke: Foundry-Spoke.

Regel für den Alltag:

• Notebook: neue Metrik ausprobieren, Gold-Set pflegen.
• CI: jeder Prompt-Change muss die Suite halten.
• Produktion: Sampling, Alerts, wer stoppt den Rollout.

Betrieb 8×5 heißt: jemand sieht die Scorekarte in Servicezeit. 24/7 ist ein anderer Vertrag und steht hier nicht.

Was die Plane zusätzlich sichtbar macht: welcher Key welches Modell getroffen hat, welches Team das Budget gerissen hat, welcher Prompt-Change mit welchem Eval-Lauf korreliert. Ohne diese Kopplung bleibt Evaluation eine Insel. Mit der Kopplung wird Evaluation Teil des Betriebs, ohne den Support-Vertrag zu ersetzen.

Gold-Set  ->  CI-Gate  ->  Sampling in Prod  ->  Owner stoppt Rollout
                 |                |
   Ragas etc.   Plane/Audit    Task + Halluzination

Enablement gehört in denselben Monat wie Support: Key-User lesen die Scorekarte, nicht nur Engineers. Sonst landet die Schwelle in einem Repo, das niemand öffnet.

Halluzination messen, ohne Fake-Benchmarks

Öffentliche Leaderboards ersetzen keine Tarif- und Störungsfälle. Ein Prozentpunkt auf einem allgemeinen Bench sagt wenig über Ihren Tenant.

Praktischer Pfad ohne erfundene Zahlen:

1. 30 bis 50 Gold-Fragen aus echten Tickets, anonymisiert.
2. Erwartete Quelle oder Tool-Ausgabe je Frage.
3. Zwei Labels: Halluzination ja/nein, Task-Erfolg ja/teilweise/nein.
4. Doppelblind nur wenn Legal es verlangt, sonst klare Rubrik für Key-User.
5. Schwelle vor dem Rollout schriftlich: unter X Prozent Task-Erfolg kein Go-Live.

MLflow und ähnliche Tracker speichern Läufe. Ragas liefert Metriken. Beides ist Werkzeug. Der Owner der Schwelle sitzt bei Fachbereich plus AI Engineering, nicht allein beim Notebook-Autor.

Pydantic- und Tool-Calling-Halluzinationen sind ein Framework-Sonderfall. Der Blog dazu bleibt Tool-TOFU. Hier zählt der Job des Assistenten.

Was wir bewusst nicht tun: Prozentzahlen aus fremden Benches als Ihre Produktionsreife verkaufen. Was wir tun: Schwellen aus Ihren Cases ableiten und an die Plane hängen. Der Plattform-Check klärt, ob Sie überhaupt schon Cases haben oder zuerst eine Quelle und einen Prozess brauchen.

Drei Anti-Patterns, die wir stoppen:

1. Nur Demo-Prompts als Gold-Set. Die Fachwelt stellt andere Fragen.
2. Nur automatische LLM-as-Judge ohne Stichprobe durch Menschen. Judge-Drift ist real.
3. Nur Offline-Eval nach Go-Live. Dann ist der Schaden schon im Ticket.

Wer stoppt den Rollout?

Ohne Owner bleibt jede Scorekarte Dekoration. Legen Sie vor dem Go-Live fest:

1. Wer liest die wöchentliche Stichprobe?
2. Wer darf ein Modell oder einen Prompt zurücknehmen?
3. Welche Schwelle ist hart (Stopp) und welche weich (Ticket an Engineering)?
4. Wie hängt der Stopp an der Plane: Key sperren, Route ändern, UI-Hinweis?

IT und Fachbereich teilen sich den Stopp. AI Engineering baut die Suite. Betrieb hält 8×5 die Sichtbarkeit. Legal und Datenschutz lesen die Cases, wenn personenbezogene Daten in Gold-Fragen stecken. Maskierung vor dem Speichern ist Pflicht, nicht optional.

Wir haben gesehen, dass Teams ohne diesen Vertrag evaluiert haben und trotzdem live gegangen sind. Das Ergebnis war ein Assistent, dem niemand widerspricht, weil niemand zuständig ist. Die Scorekarte ohne Owner ist schlimmer als keine Scorekarte: Sie erzeugt falsche Sicherheit.

Orchestrierung, eine RAG-Quelle und die Scorekarte

Ohne klare Orchestrierung messen Sie Chaos. Library gegen Schicht ist die Schnittfrage vor dem Framework-Streit. Runtime kann LangGraph sein. Die Plane bleibt LiteLLM. Details im Blog Orchestrierung oder LangGraph, sobald er live ist. Bis dahin: KEEP LangGraph Agent Development für den Bau, offene KI-Plattform für die Marke.

Ohne klare Wissensquelle messen Sie Rauschen. Im Setup liegt zuerst eine RAG-Quelle. GraphRAG ist Escalation, kein Default. Die Entscheidung „wann RAG reicht“ gehört unter Setup und Wissen, nicht unter Evaluation als Produkt.

Die Scorekarte hängt an beiden: schlechte Chunks erzeugen Halluzinationen, die wie Modellfehler aussehen. Ein Graph ohne Gate erzeugt Task-Misserfolge, die wie Prompt-Pein aussehen.

Ein Setup mit einer RAG-Quelle, Plane und fail-closed Policy ist oft der schnellste Weg zu messbaren Cases. Mehr Graph, mehr Agenten, mehr Indizes ohne Owner macht Evaluation teurer und unschärfer. Qualität vor Tempo heißt hier: erst messen, dann eskalieren.

Häufig gestellte Fragen

Ersetzt dieser Text die Seite RAG evaluieren und testen?

Nein. Die Methoden-LP trägt Retrieval- und Generation-Metriken. Dieser Blog trägt Halluzination und Task-Erfolg für den Assistenten. Beide verlinken, keiner ersetzt den anderen.

Reicht Ragas für Produktion?

Ragas ist stark für RAG-Metriken. Produktion braucht zusätzlich Task-Cases, Owner und ein Gate am Rollout. Ohne das bleibt Evaluation Demo.

Gehört Evaluation in den Betriebsvertrag 8×5?

Die Scorekarte steuert Qualität. Der Betriebsvertrag steuert Patches, Limits und Enablement. Vermischen Sie die Jobs nicht. Qualitätstor zuerst, Support danach.

Was ist mit Foundry-Evals?

Nützlich als Fläche und Feature. Fachliche Gold-Fragen bleiben Ihr Eigentum. Foundry ersetzt weder LiteLLM noch Ihre Cases.

Wie viele Gold-Fragen sind genug zum Start?

Für den ersten Gate reichen oft 30 bis 50 klare Fälle aus einem Prozess. Mehr ist besser, sobald der erste Prozess stabil ist. Menge ohne Rubrik hilft nicht.

Nächster Schritt

Flüssig falsch ist teurer als stockend richtig. Bauen Sie die Scorekarte aus Halluzination und Task-Erfolg, bevor Sie den Assistenten freigeben. Methoden bleiben Nachbar. Die Plane trägt Audit und Spend. Der Check klärt Owner und Schwelle. Listenpreise und Fake-Benches gehören nicht in diesen Text.

Verwandte Themen