Judge-LLM-Validierungsstudie · April 2026
Wir haben ein zweites LLM in unsere Pipeline für medizinische Notizen eingefügt, dessen einzige Aufgabe es ist, die Ausgabe des ersten Modells gegen das Originaltranskript zu prüfen und Fehler zu korrigieren. Vier Varianten dieser „Judge"-Architektur wurden gegen die Single-LLM-Baseline getestet.
Warum überhaupt ein Judge-LLM?
Die Single-LLM-Generierung medizinischer Notizen hat ein strukturelles Problem: Das Modell kann seine eigenen Fehler nicht zuverlässig erkennen.
Wenn GPT-4.1 eine „Uveitis anterior" halluziniert, weil die Patientin unspezifische Augensymptome erwähnt, weiß das Modell nicht, dass es halluziniert hat. Wenn es selbstbewusst „keine täglichen Bewegungsschmerzen der Finger" schreibt, weil die Patientin gesagt hat „nicht mehr so, dass ich jeden Tag" (was seltener heißt, nicht gar nicht), hat das Modell dies als beste Interpretation festgelegt und überdenkt es nicht.
Ein zweites Modell — das dasselbe Transkript ohne Bindung an den Text des ersten Modells liest — erkennt diese Fehler weit eher. Es ist das klassische Vier-Augen-Prinzip aus der klinischen Praxis selbst.
Die Frage ist nicht, ob ein Judge hilft. Sondern: Wie formuliert man den Prompt, ohne die Sache schlimmer zu machen?
Methodik
Studienaufbau
- 3 Baseline-Notizen, generiert von GPT-4.1 (Nixis vorheriges Produktionsmodell), aus drei realen Konsultationen: eine moderate (Duloxetin-Tapering), eine komplexe (Leflunomid-Schub mit dokumentierter Therapieablehnung), eine einfache (Handgelenksbeschwerden / Osteopenie).
- Diese Notizen wurden manuell bewertet anhand derselben 10-Kriterien-Rubrik aus unserer Modellauswahl-Studie als Baseline.
- Anschließend wurde jede Notiz an das Judge-LLM mit definiertem Prompt gesendet; die korrigierte Notiz wurde neu bewertet.
- Generierung und Korrektur liefen über Azure OpenAI / Azure AI Foundry. Als Judge-Modelle haben wir Claude Sonnet 4.5 und GPT-4.1 getestet.
Bewertungskriterien
| Dimension | Gewichtung |
|---|---|
| Faktische Vollständigkeit | 20 % |
| Halluzinations-Kontrolle | 15 % |
| Genauigkeit Therapie-Status | 15 % |
| Template-Anweisungs-Konformität | 15 % |
| Präzision medizinischer Terminologie | 10 % |
| Sprachstil & Register | 10 % |
| Abschnitts-Zuordnung | 5 % |
| Drei unterstützende Kriterien (kombiniert) | 10 % |
Jedes Kriterium wird pro Notiz mit 1–10 bewertet, gewichtet zu einem Gesamt-Score (0–10). Schwellen: PASS ≥ 8,5 · NEEDS_REVIEW ≥ 6,0 · FAIL < 6,0.
Getestete Architekturen
1. Single LLM (Produktions-Baseline vor dieser Studie)
Transkript → Generator (GPT-4.1) → Finale Notiz
Ein LLM-Aufruf. Kein zweites Augenpaar. Halluzinationen sind nicht erkennbar.
2. Two-LLM mit schwachem Judge-Prompt
Transkript → Generator → Notiz → Judge ("auf Fehler prüfen") → Korrigierte Notiz
Das Judge erhält eine generische Anweisung: „Prüfe die Notiz gegen das Transkript auf halluzinierte Fakten, weggelassene Fakten, falsche Medikamente und ungenaue Diagnosen. Wenn du Fehler findest, gib eine korrigierte Version aus." Kein Template, kein Terminologie-Wörterbuch, keine spezifischen Bewertungskriterien.
3. Two-LLM mit starkem Judge-Prompt (Produktionskandidat)
Transkript → Generator → Notiz → Judge (5-Schritt-Rubrik) → Korrigierte Notiz
Das Judge erhält:
- Ein 5-Schritt-Qualitätsframework: Halluzinations-Check → Vollständigkeits-Check → Abschnitts-Zuordnung → Template-Konformität → Terminologie-Check
- Die vollständigen Template-Anweisungen (damit es weiß, wie richtig aussieht)
- Das Terminologie-Wörterbuch (damit es die korrekte Form jedes Medikaments kennt)
- Explizite „nicht ändern"-Regeln — Therapiestatus, Dosierungen,
Abschnittszuordnungen, JSON-Struktur, ursprüngliche
[unklar]-Markierungen - Eine „Minimum-Changes"-Regel, damit es nicht aus stilistischer Vorliebe umschreibt
4. Three-LLM Extractor → Structurer → Judge
Transkript → Extractor (SOAP) → Structurer (Template) → Judge → Finale Notiz
Theoretisch ein Separation-of-Concerns-Ansatz: ein Modell extrahiert nur Fakten in eine generische SOAP-Notiz, das nächste formatiert in das Template, das letzte prüft.
Ergebnisse
Qualitäts-Scores nach Architektur
- Two-LLM, starker Judge (Claude Sonnet 4.5)Produktionskandidat · ~22 s end-to-end8.95
- Two-LLM, starker Judge (GPT-4.1)~14 s end-to-end8.40
- Two-LLM, schwacher Judge-Prompt~13 s end-to-end7.95
- Three-LLM (Extractor → Structurer → Judge)~32 s end-to-end7.90
- Single LLM (GPT-4.1 Baseline)~10,8 s end-to-end7.80
Brand-Gradient-Balken: höher ist besser. Der starke Judge mit Claude Sonnet 4.5 ist unsere Produktionsempfehlung für den optionalen Deep-Review-Modus.
- Single LLM · Halluzinations-Kontrolle6.0
- Two-LLM, starker Judge · Halluzinations-Kontrolle9.0
- Single LLM · Abschnitts-Zuordnung7.0
- Two-LLM, starker Judge · Abschnitts-Zuordnung9.0
Der starke Judge schließt fast vollständig die Lücke zu einem fehlerfreien Score auf den beiden für die klinische Notiz wichtigsten Kriterien.
- Single LLM (GPT-4.1)10.8 s
- Two-LLM, schwacher Judge13.0 s
- Two-LLM, starker Judge (GPT-4.1)14.0 s
- Two-LLM, starker Judge (Claude Sonnet 4.5)22.0 s
- Three-LLM (Extractor → Structurer → Judge)32.0 s
Flache Ink-Balken: weniger ist besser. Der Judge fügt 6–12 s end-to-end hinzu. Three-LLM-Pipelines verdreifachen die Latenz ohne Qualitätsgewinn.
Was der starke Judge tatsächlich korrigiert hat
Echte Beispiele aus dem Test-Korpus, in denen der Judge die Notiz verändert hat:
Wo der schwache Judge versagte
Zwei Fehlermuster traten beim schwachen Judge auf, die die starke Variante korrigiert:
-
Selbstbewusstes Umschreiben verstümmelter STT. Der schwache Judge sah „2 Wochen im Krankenschwester" (eine verstümmelte Phrase) und schrieb sie selbstbewusst um zu „Zwei Wochen Arbeitsunfähigkeit" — ein neuer Fakt (Krankschreibung) wurde eingeführt, der nie etabliert wurde. Der starke Judge hat eine explizite Regel: Wenn STT unklar ist, mit
[unklar]markieren, nicht raten. -
Hochstufung von Unsicherheit zu Gewissheit. Der schwache Judge nahm das „kann gut sein" der Ärztin und schrieb es um zu „Es besteht der Verdacht auf" (formaler klinischer Verdacht). Der starke Judge hat eine explizite Regel: Den Unsicherheitsgrad der Ärztin bewahren.
Es sind dieselben Fehlermuster, die der Generator hat. Ohne explizite Beschränkungen verfällt ein LLM-Judge in dasselbe generative Verhalten — alles klinischer und sicherer klingen zu lassen, als es tatsächlich ist.
Warum Three-LLM schlechter abschnitt als Two-LLM
Die Extractor → Structurer → Judge-Architektur scheiterte aus einem strukturellen Grund: Der Structurer sieht das Originaltranskript nie.
In unserem komplexen Leflunomid-Testfall las der Extractor den STT-verstümmelten Medikamentennamen „Level mit" und produzierte eine SOAP-Notiz, die „Methotrexat" erwähnte — ein völlig anderes Medikament (die Patientin nahm Leflunomid). Der Structurer schrieb die Notiz dann pflichtbewusst mit „Methotrexat", weil das die SOAP-Notiz so vorgab. Der Judge versuchte, gegen das Transkript zu prüfen, aber die gesamte Notiz war bereits um das falsche Medikament aufgebaut.
Das Two-LLM-Design vermeidet das, weil sowohl Generator als auch Judge das Originaltranskript sehen. Beide Modelle haben eine Chance, den STT-Fehler zu erkennen. Bei drei LLMs sehen nur das erste und letzte die Quelle, und ein Fehler in der Mitte propagiert.
Eine verallgemeinerbare Lehre: Mehr LLMs helfen nur dann, wenn jedes davon Zugriff auf die Wahrheitsquelle behält.
Was in einem starken Judge-Prompt funktioniert
Nach mehreren Iterationen sind wir bei diesen Design-Regeln gelandet. Jede ist das Ergebnis eines spezifisch beobachteten Fehlers:
Fünf-Schritt-Rubrik in fester Reihenfolge
- Halluzinations-Check — jeder Fakt muss auf das Transkript zurückführbar sein (mit explizitem Vorbehalt: STT-Korrektur ist keine Halluzination)
- Vollständigkeits-Check — jeder Fakt aus dem Transkript muss in der Notiz erscheinen
- Abschnitts-Zuordnung — Fakten im richtigen Template-Abschnitt gemäß dem Anweisungstext des Abschnitts
- Template-Konformität — Formatierung, Fließtext vs. Bullets, „Beginne mit:" korrekt umgesetzt
- Terminologie-Check — exakte Schreibweisen und Großschreibung aus dem Wörterbuch
Explizite „nicht ändern"-Regeln
Ohne diese überarbeitet der Judge zu viel:
- Bereits korrekte Sätze nicht umformulieren
- Therapiestatus, Dosierungen, Abschnittszuordnungen nicht ändern
[unklar]-Markierungen aus dem Original nicht auflösen — die Unsicherheit des Generators bewahren- Minimum-Changes: jede Änderung muss durch einen der fünf Schritte begründet sein
Explizite STT-Handhabungs-Regel
Wenn etwas im Transkript verstümmelt oder unklar ist, mit
[unklar]markieren. Nicht selbstbewusst umschreiben. Nur umschreiben, wenn die beabsichtigte Bedeutung mit > 80 % Sicherheit erkennbar ist.
Explizite Gewissheits-Bewahrungs-Regel
Wenn die Ärztin Unsicherheit ausdrückte („vielleicht", „kann sein"), muss die Notiz diesen Unsicherheitsgrad bewahren. Nicht zu „Verdacht auf" (formaler klinischer Verdacht) hochstufen.
Kosten- & Latenz-Überlegungen
Der Judge verdoppelt effektiv die Kosten pro Notiz und fügt 6–12 Sekunden End-to-End-Latenz hinzu. Für eine Praxis in Nixi-Größe (~50 Notizen / Arzt / Tag):
| Modus | Pro Notiz · Pro Tag · Pro Monat |
|---|---|
| Single LLM | $0,05, ~15 s · $2,50, 12 min · ~$50 |
| Two-LLM mit Judge | $0,10, ~25 s · $5,00, 21 min · ~$100 |
Ein Judge erhöht die Kosten um etwa $50 pro Arzt pro Monat. Die erwartete Reduktion der Nachbearbeitungszeit (1–2 Minuten Einsparung pro Notiz dank genauerer Erstfassung) zahlt das mehr als zurück.
Aber wir brauchen das nicht immer — für routinemäßige einfache Notizen ist die Single-LLM-Baseline bereits gut genug. Der Judge verdient seinen Platz in komplexen Konsultationen, in denen Halluzinationen und übergangene Negationen am schädlichsten sind.
Limitationen
- 3 Baseline-Fälle — repräsentativ über Komplexitätsbänder, aber statistisch nicht groß. Wir erweitern den Validierungsdatensatz auf 12 Fälle in 4 Fachgebieten, bevor weitere Scores publiziert werden.
- Tests komplett auf Deutsch in der Rheumatologie. Der Einsatz im englischsprachigen Raum erfordert eine Re-Validierung.
- Wir haben Claude Sonnet 4.5 und GPT-4.1 als Judge getestet. Neuere Modelle (GPT-5.x-Familie) schließen die Lücke wahrscheinlich weiter, wurden aber in unserer Companion-Modellauswahl-Studie zur Notiz-Generierung getestet, nicht als Judge.
- Die „Minimum-Changes"-Anweisung reduziert, eliminiert aber nicht die Über-Korrektur. ~3 % der Judge-Edits in unserer Stichprobe veränderten etwas, das bereits korrekt war.
Fazit
Das Hinzufügen eines korrekt formulierten Judge-LLMs zur medizinischen Notizgenerierung ist die größte einzelne Qualitätsverbesserung, die wir gemessen haben — größer als jede Änderung am Generator-Prompt oder am Basismodell.
Aber das Prompt-Design ist genauso wichtig wie die Architektur. Ein Judge mit einem generischen „Fehler finden"-Prompt bewirkt nahezu nichts. Ein Judge mit explizitem Schritt-für-Schritt- Rubrik, expliziten Beschränkungen, was nicht zu ändern ist, und expliziten STT- und Gewissheits-Regeln fügt etwa 1,0 Punkt Qualität auf einer 10-Punkte-Skala hinzu und halbiert die Halluzinationsrate.
Für Health-Tech-Teams, die klinische Dokumentation entwickeln: Das zweite LLM ist die Kosten wert, aber nur, wenn der Judge-Prompt mit derselben Sorgfalt behandelt wird wie der Generator-Prompt. Generische „prüfe dies nochmal"-Anweisungen funktionieren nicht. Spezifische, beschränkungsreiche, im Transkript verankerte Anweisungen schon.