Wie Sie QA-Fehler bei Custom-LLMs in 7 Schritten diagnostizieren

Notizen aus dem Release-Zyklus — Teil VI

Eine Scored-QA-Suite begann, das Medizin-Q&A-Modell eines Kunden zu markieren. Die Headline-Zahl — aggregierte Qualität über alle Slices hinweg — fiel über Nacht um 6 Punkte. Das Team verbrachte zwei Tage damit, das Modell zu debuggen. Sie führten Fine-Tunes erneut durch. Sie rollten zurück auf das vorherige Release. Die Zahlen bewegten sich nicht.

Am Morgen des dritten Tages bemerkte jemand, dass die Eval-Suite in derselben Nacht aktualisiert worden war, in der die Regression begann. Drei neue Prompts zur pädiatrischen Dosierung waren dem Test-Set hinzugefügt worden, und das Modell hatte pädiatrische Dosierung im Training nie gesehen. Der „QA-Fehler“ war keine Modellregression. Es war ein Slice-Abdeckungs-Ereignis: Die Eval begann, nach etwas zu fragen, das das Modell nie wissen sollte.

Bei unseren Kunden-Rollouts ist dies das dominante Muster. Ein „QA-Fehler“-Alarm ist das Symptom. Die Ursache ist das Modell etwa in einem von sieben Fällen. In den anderen sechs Fällen steckt der Fehler irgendwo stromaufwärts: im Eval-Design, in der Judge-Kalibrierung, im Prompt-SHA, in der Preprocessing-Pipeline, in der Datensatzversion oder im Retrieval-Index. Jede dieser Fehlerklassen sieht aus Sicht des Alarms identisch aus — eine Zahl ist gesunken — hat aber einen vollständig anderen Fix.

Dieser Beitrag ist der Diagnose-Baum, den wir der Reihe nach durchgehen, wenn ein Alarm ausgelöst wird. Sechs Schritte, die nicht modellbezogene Ursachen ausschließen, bevor der siebte Schritt das Modell selbst in Betracht zieht. Jeder Schritt hat einen konkreten API-Aufruf oder eine Abfrage, die ihn beantwortet. Wenn Sie die sechs abgearbeitet haben, wissen Sie entweder genau, was zu reparieren ist, oder Sie haben sich das Recht erarbeitet, das Modell anzusehen.

Der Entscheidungsbaum

Der Baum ist sequenziell, weil die Schritte von günstig zu teuer geordnet sind. Schritt 1 ist ein git diff der Eval-Suite; Schritt 7 ist ein Fine-Tune-Zyklus. Sie wollen zehn Minuten für jede der sechs günstigen Prüfungen aufwenden, bevor Sie eine Woche für die teure aufwenden.

Schritt 1 — Hat die Eval diesen Slice abgedeckt?

Das Symptom. Die aggregierte Qualität sinkt, aber die Slice-Aufschlüsselung zeigt, dass ein Slice einbricht, während die anderen flach bleiben. Oder — noch verwirrender — jeder Slice sinkt leicht, alle um ähnliche Beträge.

Die Diagnose. Diffen Sie den SHA des Eval-Suite-Manifests gegen das des vorherigen Releases. Wenn sich die Eval-Suite geändert hat und Sie das Modell nicht geändert haben, liegt die Regression in der Eval, nicht im Modell.

# Eval-Suite-Manifest-SHA zwischen Releases vergleichen
curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.eval_suite_sha256'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.eval_suite_sha256'
# Unterschiedlich? Ihre Eval hat sich geändert. Auditieren Sie, was hinzugefügt wurde.

Der Fix. Entweder die Änderung der Eval-Suite zurücknehmen (falls sie unbeabsichtigt war) oder die Trainingsabdeckung erweitern, um der neuen Eval zu entsprechen (falls der neue Slice ein echtes Produktionsanliegen ist). Liefern Sie keinen Modellregressions-Fix für ein Eval-Abdeckungsproblem aus — Sie werden das Modell bei dem schlechter machen, was es eigentlich gut konnte.

Wo sich das in unserer Pipeline versteckt. Stage 1 — Register bindet den SHA der Eval-Suite in das Release-Manifest. Die obige Diagnose ist einfach das Diffen zweier Manifeste. Der Grund, warum der Fehler das Medizin-Q&A-Team zwei Tage gekostet hat, ist, dass sie keinen Manifest-Level-Diff hatten — sie verglichen Modell-Checkpoints, keine Release-Manifeste.

Schritt 2 — Ist die Judge-Instanz auf diesem Slice an Menschen kalibriert?

Das Symptom. Ein Slice, der für die Eval-Suite neu ist, erzielt schlechte Werte, aber die menschliche Begutachtung der Modellausgaben auf diesem Slice bewertet sie als in Ordnung. Die Judge-Instanz hält das Modell für fehlerhaft; Menschen nicht.

Die Diagnose. Berechnen Sie Spearmans ρ zwischen den Bewertungen der LLM-Judge-Instanz und einer kleinen menschlich bewerteten Stichprobe (50 Elemente) auf dem fehlerhaften Slice. Wenn ρ < 0,4 ist, misst die Judge-Instanz nicht das, was Menschen auf diesem Slice messen.

curl -X POST https://api.divinci.ai/v1/judges/<judge_id>/calibrate \
  -d '{ "slice": "pediatric-oncology-dosing", "human_ratings_csv": "..." }'
# → { "spearman_rho": 0.31, "interpretation": "judge_uncalibrated_for_slice" }

Der Fix. Entweder wählen Sie ein anderes Judge-Modell für diesen Slice oder verwenden Sie eine Kette von Judges mit einem Schiedsrichter. MT-Bench^[1] zeigt, dass GPT-4-als-Judge im Durchschnitt zu >80% mit Menschen übereinstimmt, aber mit kategoriespezifischer Varianz von 86% (Coding) bis 36–44% (Schreiben/Geisteswissenschaften). Die Varianz ist die entscheidende Zahl; „im Durchschnitt gut“ verbirgt Slices, in denen die Judge-Instanz falsch liegt.

Wo sich das in unserer Pipeline versteckt. Stage 2 — Gate verlangt eine kalibrierte Judge-Instanz pro Slice. Der Beitrag Calibrating the AI Judge dokumentiert das Verfahren. Wenn der Slice ohne Kalibrierungsschritt zur Eval hinzugefügt wurde, haben Sie ein strukturell unzuverlässiges Gate.

Schritt 3 — Stimmt der Prompt-Template-SHA mit der Produktion überein?

Das Symptom. Die Qualität sinkt, aber model_ref und dataset_ref sind unverändert. Nichts am Training hat sich geändert. Das Modell ist dasselbe Modell. Und doch.

Die Diagnose. Vergleichen Sie den SHA von prompt_template_ref im fehlerhaften Release-Manifest mit dem des vorherigen Releases. Eine 38-Zeichen-Änderung an einem System-Prompt, die die „Kürze verbessert“, kann das nachgelagerte Verhalten stärker verändern als ein vollständiges Neutraining.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.prompt_template_ref'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.prompt_template_ref'
# Unterschiedlich? Ziehen Sie den Diff. Schauen Sie ihn sich sorgfältig an.

Der Fix. Behandeln Sie Prompts wie Code. Der Beitrag zu 10 Release-Fehlern behandelt den Fehlermodus der Dashboard-Bearbeitung — Tianpans Semver Lie-Postmortem^[2] benennt dies als das dominante Fehlermuster von 2026. Wenn Sie nachweisen können, dass sich der Prompt geändert hat, haben Sie Ihren Fehler gefunden.

Schritt 4 — Stimmt die Preprocessing-Pipeline mit der Produktion überein?

Das Symptom. Das Modell besteht die Eval lokal. Dasselbe Modell besteht dieselbe Eval in der Produktion nicht. Gleiche model_ref, gleicher Prompt, gleicher Datensatz.

Die Diagnose. Ziehen Sie den preprocessing_ref-SHA aus dem Produktions-Manifest und verifizieren Sie, dass die Eval mit demselben gelaufen ist. Der klassische Fall: Training normalisiert Leerzeichen und konvertiert in Kleinbuchstaben; Produktion nicht. Die Eval lief durch das Produktions-Preprocessing; alles wurde geprüft. Bis jemand das Preprocessing nur auf einer Seite aktualisierte.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.preprocessing_ref'
# Mit dem Preprocessing vergleichen, das Ihr Trainings-/Eval-Harness tatsächlich verwendet hat.

Der Fix. Containerisieren Sie das Preprocessing als versioniertes Artefakt. Referenzieren Sie es aus dem Manifest. Verweigern Sie das Deployment, wenn der Preprocessing-SHA des Gates vom Produktions-SHA abweicht.

Schritt 5 — Stimmt der Datensatz-SHA mit der Produktion überein?

Das Symptom. Gate-Eval-Ergebnisse aus dem fehlerhaften Release unterscheiden sich von den Gate-Eval-Ergebnissen desselben Modells vom Vortag.

Die Diagnose. Diffen Sie das Feld dataset_version zwischen den beiden Releases. Die Eval-Suite behielt denselben Namen, aber der Datensatzinhalt wurde aktualisiert und neu getaggt. Gleicher Name, anderer SHA, andere Ergebnisse.

diff <(curl .../rel_a01c66 | jq '.dataset_version') \
     <(curl .../rel_8f72b1 | jq '.dataset_version')

Der Fix. Content-hashen Sie Ihre Datensätze. Der Datensatzname ist keine Version; der SHA ist es.

Schritt 6 — Stimmt der Retrieval-Index-SHA mit der Produktion überein?

Das Symptom. Nur für RAG-Workloads. Die Qualität sinkt bei Fragen, die von abgerufenem Kontext abhängen. Direkte-Antwort-Fragen sind unverändert.

Die Diagnose. Ziehen Sie den retrieval_index_ref-SHA aus dem Manifest. Vergleichen Sie ihn mit dem Retrieval-Index der Gate-Evaluierung. Der RAG-Index wurde über Nacht aktualisiert (ein frischer Ingestion-Lauf); die Gate-Evaluierung hat ein älteres Retrieval gecached; der Produktions-Canary verwendete das neue.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.retrieval_index_ref'

Der Fix. Binden Sie den Retrieval-Index-SHA in das Manifest, genau wie wir Preprocessing binden. Die automatisierte Index-Rotationskadenz von AutoRAG macht diese Prüfung besonders lohnenswert — der Index wird sich aktualisieren, ob Sie es autorisiert haben oder nicht, wenn Sie ihn nicht pinnen.

Schritt 7 — Endlich das Modell selbst

Sechs Schritte sind absolviert. Die Eval deckt den Slice ab. Die Judge-Instanz ist kalibriert. Der Prompt-SHA stimmt überein. Das Preprocessing stimmt überein. Der Datensatz stimmt überein. Der Retrieval-Index stimmt überein.

Jetzt — und erst jetzt — haben Sie sich das Recht erarbeitet, das Modell anzusehen.

Die Diagnose für diesen Schritt ist ein Slice-spezifischer Spearman-Vergleich gegen das vorherige Release, wobei beide Releases gegen denselben manifestgebundenen Datensatz, dasselbe Preprocessing und dasselbe Retrieval evaluiert werden. Die Zahl, die Sie produzieren, ist ein sauberes Signal: eine echte Slice-spezifische Regression, ohne stromaufwärtige Störfaktoren.

curl -X POST https://api.divinci.ai/v1/releases/<failing_id>/diff-eval \
  -d '{ "baseline_release_id": "<prior_id>", "slices": ["legal-IP-licensing"] }'
# → { "spearman_rho_failing": 0.41, "spearman_rho_baseline": 0.68, "delta": -0.27 }

Wenn das Delta eine echte Regression bestätigt: Auto-Rollback wird ausgelöst (falls Sie es nicht schon manuell aufgerufen haben), und das fehlerhafte Modell wird gegen einen erweiterten Slice-Abdeckungs-Korpus neu trainiert. Wenn das Gate, das dieses Release befördert hat, den Slice von vornherein verpasst hat, ist das Gate ebenfalls der Fehler — Fähigkeit 4 fehlt in Ihrer Release-Pipeline.

Wie die Verteilung tatsächlich aussieht

Das „1 von 7“-Framing von weiter oben war kein rhetorisches Mittel. Es ist ungefähr die Verteilung, die wir bei Kunden-Rollouts sehen. Von jeweils sieben QA-Alarmen:

Die zwei größten Slices sind Eval-Abdeckungslücke und Judge-Fehlkalibrierung. Zusammen machen sie die Hälfte der QA-Alarme aus. Keines davon ist ein Modellproblem. Beide sind Probleme damit, wie Sie das Modell messen.

Was dies nicht löst

Drei ehrliche Einschränkungen:

Die Verteilung ist unsere, nicht Ihre. Die obigen Prozentsätze stammen aus unserer Kunden-Kohorte und dem Tooling unserer Pipeline. Wenn Sie eine andere Art von Workload betreiben — stark multimodal, stark Agent-orchestriert, stark Single-Shot-generativ — wird Ihre Verteilung anders aussehen. Die Diagnose-Reihenfolge sollte trotzdem gelten; die Zahlen hinter jedem Schritt werden es nicht.

Die „Eval-Abdeckungslücke“ aus Schritt 1 ist am schwersten zu beheben. Den fehlenden Slice zu Ihrem Trainingskorpus hinzuzufügen, eine kalibrierte Judge-Instanz dafür zu bauen und den Canary erneut laufen zu lassen, ist selbst ein mehrwöchiges Projekt. Die Diagnose ist schnell; die Behebung nicht.

Eine echte Regression kann auf einem nicht modellbezogenen Fehler reiten. Die Fälle, in denen Sie sowohl einen Prompt-Drift ALS AUCH eine echte Modellregression haben, sind die schlimmsten, weil Schritt 3 den Prompt-Drift findet, Sie ihn beheben und der Alarm erneut feuert. Die Diagnose-Reihenfolge in diesem Beitrag bewältigt sie, fügt aber verstrichene Zeit hinzu. Es gibt keine Abkürzung für „der Fehler war an zwei Stellen gleichzeitig“.

FAQ

Warum produziert mein LLM unterschiedliche Ausgaben für ähnliche Prompts?

Prompt-Sensitivität ist real, aber sie ist nicht immer die Ursache eines QA-Alarms — manchmal ist sie ein Symptom eines stromaufwärtigen Fehlers. Gehen Sie die Diagnose durch. Wenn der Prompt-Template-SHA übereinstimmt, das Preprocessing übereinstimmt und der Datensatz übereinstimmt, dann ja — das Modell hat eine große Varianz auf diesem Slice, und Sie brauchen einen deterministischeren Decoding-Pfad oder eine andere Judge-Instanz. Wenn sich irgendetwas Stromaufwärtiges geändert hat, beheben Sie das zuerst.

Wie oft sollten Sie Ihre LLM-Benchmarks neu auswerten?

Werten Sie den Inhalt des Benchmarks jedes Mal neu aus, wenn sich die Traffic-Form eines Produktions-Slices signifikant ändert. Werten Sie die Judge-Kalibrierung des Benchmarks mindestens vierteljährlich neu aus — Judge-Modelle driften schneller, als Sie denken würden. Die größte Quelle für falsche QA-Alarme ist ein Benchmark, der vor 18 Monaten zuletzt validiert wurde und jetzt eine Sache misst, die Ihre Produktion nicht mehr macht.

Was verursacht Halluzinationen in Custom-Language-Modellen?

Halluzinationen haben mehrere stromaufwärtige Ursachen — Retrieval-Fehler (Schritt 6 im obigen Baum), Trainingsabdeckungslücken (Schritt 1, indirekt) und Decoding-Pfad-Probleme (ein echtes Modellanliegen in Schritt 7). AutoRAG adressiert die retrieval-seitigen Ursachen, indem es den Retrieval-Index in das Release-Manifest bindet und ihn bei jedem Release neu pinnt. Die anderen beiden erfordern Pipeline-seitige Fixes stromaufwärts des Modells.

Woher wissen Sie, ob Ihre Trainingsdaten das Problem sind?

Wenn der Datensatz-SHA im fehlerhaften Release mit dem Datensatz-SHA im vorherigen guten Release übereinstimmt (Schritt 5 des Baums), sind die Daten nicht die unmittelbare Ursache. Wenn sie sich unterscheiden, haben Sie sie gefunden. Die schwierigere Frage — „ist der Datensatz vollständig für unsere Produktions-Slice-Abdeckung?“ — ist das, was Schritt 1 testet. Ein Datensatz, der für die Eval vollständig, aber für den Produktions-Traffic unvollständig ist, ist ein Slice-Abdeckungsproblem.

Können Sie QA-Fehler beheben, ohne das gesamte Modell neu zu trainieren?

Ja — in sechs von sieben Fällen ist der Fix kein Neutraining. Die Schritte 1–6 im Baum haben Fixes, die das Modell nicht anfassen: Eval aktualisieren, Judge-Instanz neu kalibrieren, Prompt-SHA neu registrieren, Preprocessing reparieren, Datensatz neu pinnen oder Retrieval-Index neu pinnen. Neutraining ist Schritt 7, der teuerste Fix, vorbehalten für tatsächliche Modellregressionen. Die Audit-Spur der Release-Pipeline ermöglicht es Ihnen, diese stromaufwärtigen Fixes mit derselben Provenienz-Disziplin durchzuführen, die Sie für eine Modelländerung verwenden würden.

References

1. LLM-as-judge per-category variance. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement with per-category variance from coding (86%) down to writing (36–44%). Anchor for step 2 — why judge calibration has to be measured per slice rather than assumed from a published headline number.
2. The Semver Lie. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). The dominant 2026 failure-mode writeup. Names dashboard-edit prompt drift as the most-cited cause of production LLM incidents. Anchor for step 3.
3. NIST AI RMF — Measure function. NIST AI Risk Management Framework. The "Measure" function explicitly covers benchmark-validity and evaluation-coverage as part of governance, not as a separate engineering concern. Cited as the institutional anchor for treating eval design as the first diagnostic step.
4. RAGAS — retrieval-augmented generation evaluation. Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation (arXiv:2309.15217). The reference framework for RAG-side evaluation. Anchor for step 6 — separating retrieval failures from generation failures requires a RAG-aware eval discipline.
5. Internal — root-cause distribution across customer rollouts. The percentages in the pie chart are our internal observation across Divinci customer rollouts, not from a controlled benchmark. Your distribution will vary by workload type, fine-tune cadence, and team discipline. The relative ordering (steps 1–2 dominating) is stable across the cohort we've measured; the exact percentages are not portable to your environment without your own data.
6. The four-stage release pipeline. How to Build an LLM CI/CD Pipeline With Divinci AI. Each diagnostic step in this post corresponds to a manifest field bound at Stage 1 — Register. Without the manifest discipline upstream, the diagnostic loses its grip; you can't diff what you didn't bind.

Nächster Beitrag in dieser Reihe: Automated Regression Testing for Custom LLMs in 2026. Dieser Beitrag handelt von der Diagnose, nachdem ein QA-Alarm ausgelöst wurde. Der nächste handelt von der Regressionstest-Disziplin, die den Alarm überhaupt erst ausgelöst hat — was in die Eval gehört, wie man sie ehrlich hält und was zu tun ist, wenn der Regressionstest beginnt, Ihrer Judge-Instanz zu widersprechen.