Who Drifted: the System or the Judge? Anytime-Valid Attribution in LLM Evaluation Pipelines

Technisches Resümee: Wer ist abgedriftet? Zeitunabhängig valide Attribuierung in LLM-Evaluations-Pipelines

1. Das Problem

Die kontinuierliche Evaluierung von Large Language Model (LLM)-Produkten stützt sich zunehmend auf „LLM-as-judge“-Pipelines, bei denen ein starkes Modell Interaktionen bewertet, um Alarme auszulösen, wenn die Performance sinkt. Die grundlegende Annahme dieser Systeme ist, dass der Judge als fixes Lineal fungiert; somit impliziert ein Rückgang der Scores eine Regression im Produkt. Der Judge selbst ist jedoch ein API-basierter Prozess, der stillen Versionssprüngen, Prompt-Updates oder Richtlinienänderungen unterliegt.

Wenn ein Monitoring-System einen Alarm auslöst, steht es vor einer Ambiguität: Hat sich die Produktqualität verschlechtert oder hat sich das Bewertungsverhalten des Judges geändert? Das Handeln auf Basis einer falschen Attribuierung ist kostspielig: Teams führen möglicherweise ein gesundes Produkt zurück oder veröffentlichen eine Regression, indem sie den Alarm als „Judge-Drift“ abtun. Klassische statistische Methoden, wie etwa rollierende Z-Tests, versagen in diesem Kontext der kontinuierlichen Überwachung, da ihnen die Zeitunabhängige Validität (anytime-validity) fehlt; das wiederholte Durchführen eines Tests mit festem $\alpha$ bei jedem Schritt bläht die Falschalarmrate auf und führt zu spürbaren Fehlalarmen selbst in driftfreien Datenströmen.

2. Methodik

Das Paper schlägt ein Framework vor, um System-Drift von Judge-Drift mittels zeitunabhängig validen e-Prozessen und einer menschen-basierten Attribuierungsregel zu entwirren.

A. Der budgetierte Hauptmonitor (System-Drift-Erkennung)
Das System nutzt einen stratifizierten, prädiktionsgestützten Monitor (folgend nach Csillag et al., 2025b; Angelopoulos et al., 2023), um Qualitätsregressionen zu erkennen:

• Architektur: Ein günstiger Judge ($\mu$) bewertet jedes Item, während ein teurer, starker Judge ($y$) eine Stichprobe unter einem festen Budget bewertet.
• Mechanismus: Für jede (Rubrik $\times$ Stratum)-Zelle akkumuliert ein prädiktionsgestützter e-Prozess „Reichtum“ (wealth), um die Nullhypothese zu testen, dass der Mittelwert nicht unter eine gesunde Baseline gefallen ist.
• Kosteneffizienz: Das System verwendet einen e-Wealth-Eskalations-Trigger. Sobald Evidenz für Drift akkumuliert wird, steigt die Stichprobenwahrscheinlichkeit für den starken Judge. Dies ermöglicht es dem System, lokalisierte Blindspot-Regressionen mit etwa einem Drittel der Kosten einer vollständigen Evaluierung zu erkennen, während die Zeitunabhängigkeit (Guarantie, dass die Falschalarmrate zu jedem beliebigen Zeitpunkt begrenzt bleibt) gewahrt bleibt.

B. Die Anker-Konstruktion (Judge-Drift-Erkennung)
Um die Ambiguität der Attribuierung aufzulösen, führen die Autoren einen zweiten, unabhängigen e-Prozess ein, der an fixen menschlichen Labels verankert ist:

• Anker-Set ($A$): Eine feste, ausgelassene Sammlung von Items mit eingefrorenen menschlichen Labels ($h$), die vor Beginn der Überwachung erstellt wurde.
• Interleaving: In einem stetigen Rhythmus (z. B. alle $1/\rho$ Items) bewertet der aktuelle starke Judge ein zufällig ausgewähltes Anker-Item neu.
• Der e-Prozess: Ein „Betting e-Process“ verfolt die Differenz zwischen dem aktuellen Score des Judges auf dem Anker und dem eingefrorenen menschlichen Label.
• Asymmetrie: Da die Anker-Items und die menschlichen Labels fixiert sind, kann nur eine Änderung des Judges die Verteilung der Differenz verändern. System-Drift beeinflusst die eingehenden Items, lässt aber die Differenz beim Anker unverändert. Dies erzeugt einen „Einwegspiegel“, der ausschließlich Judge-Drift detektiert.

C. Die Attribuierungsregel (Guard Window)
Das System kombiniert die Stoppzeiten des Hauptprozesses ($\tau_{sys}$) und des Anker-Prozesses ($\tau_{anc}$) unter Verwendung eines Guard Windows ($W$), um ein Urteil in $\{keines, system, judge\}$ abzugeben:

• Judge-Urteil: Wenn der Anker-Prozess zuerst feuert ($\tau_{anc} < \infty$) und der Hauptprozess innerhalb des Guard Windows feuert ($\tau_{sys} \le \tau_{anc} + W$), lautet das Urteil judge. Die Logik ist, dass ein kontaminierter Judge den Hauptalarm invalisiert.
• System-Urteil: Wenn der Hauptprozess zuerst feuert und der Anker-Prozess nicht innerhalb des Guard Windows feuert, lautet das Urteil system.
• Race Condition: Das Design beruht auf einem „Attribuierungs-Rennen“. Um Fehlattributionen zu vermeiden, muss der Anker-Prozess so dimensioniert sein, dass er den Judge-Drift schneller erkennt, als der kontaminierte Hauptprozess einen falschen System-Alarm auslösen kann.

3. Kernbeiträge

1. Anker-Konstruktion & Attribuierungsregel: Eine neuartige Methode unter Verwendung eines menschen-basierten, zeitunabhängig validen e-Prozesses, um System-Drift explizit von Judge-Drift zu trennen und ein Drei-Zustands-Urteil statt eines binären Alarms auszugeben.
2. Theoretische Garantien:
   • Zeitunabhängige Validität (Anytime-Validity): Die Anker-Familie hält eine begrenzte Falschalarmrate ($\alpha_{judge}$) zu jedem datenabhängigen Stoppzeitpunkt ein.
   • Einweg-Identifikation: Der Anker-Prozess ist mathematisch garantiert unempfindlich gegenüber System-Drift; er kann nur durch eine Änderung des Judges ausgelöst werden.
   • Attribuierungs-Rennen: Das Paper etabliert ein Designgesetz, wonach der Anker-Prozess so bereitgestellt werden muss, dass er den Judge-Drift schneller „überholt“ als der kontaminierte Hauptprozess einen falschen System-Alarm auslösen kann.
   • Orthogonalität: Das Anker-Budget und die Konfiguration des Hauptprozesses sind unabhängig, was eine separate Abstimmung von Judge-Latenz und System-Power ermöglicht.
3. Empirische Validierung auf realen Drifts: Die Methode wurde auf zwei realen Judge-Änderungen (einem stillen Versionssprung und einer strengeren Prompt-Policy-Änderung) über zwei Domänen (HelpSteer2 und TL;DR Summarization) getestet, ohne Neukalibrierung.
4. Operationale Überlegenheit: Der vorgeschlagene e-Prozess schneidet signifikant besser ab als klassische Baselines (naive rollierende Z-Tests und kalibrierte Page–Hinkley-Detektoren) hinsichtlich der Kontrolle von Falschalarmen und der Detektion subtiler Drifts.

4. Ergebnisse

• Detektionsgenauigkeit:
  • Stiller Versionssprung: Wurde in 60/60 Durchläufen als Judge-Drift erkannt, mit null Fehlattribution von Judge zu System.
  • Strenge Prompt-Änderung: Wurde in 110/120 Durchläufen (bei Guard Width $W=300$) auf HelpSteer2 korrekt attribuiert. Auf der TL;DR-Domäne, in der der Prompt-Shift schwerwiegender war, war die Attribuierung perfekt (240/240).
  • Fehlattribution: Die Rate der falschen System-Alarme während eines Judge-Drifts sank monoton mit zunehmender Breite des Guard Windows ($W$), was die Theorie des „Attribuierungs-Rennens“ bestätigt.
• Vergleich mit Baselines:
  • Ein naiver rollierender Z-Test (Industriestandard) generierte bei 75 % der driftfreien Streams Fehlalarme.
  • Ein kalibrierter Page–Hinkley-Detektor hielt zwar sein Falschalarm-Budget ein, versagte aber bei der Detektion des subtilen realen Versionssprungs (nur 8 % Detektion auf HelpSteer2) und erforderte gehaltene Kalibrierungsdaten.
• Kosteneffizienz: Der Monitor arbeitet mit etwa 0,64 der Kosten einer vollständigen Bewertung jedes Items (oder 0,21 in einem „billigeren, aber trägeren“ Regime), während er valide Detektionsgarantien aufrechterhält.

5. Bedeutung und Ansprüche

Das Paper behauptet, eine kritische, bisher ungelöste Fehlerquelle in der LLM-Operation gelöst zu haben: die Unfähigkeit, zwischen Produktverschlechterung und Instabilität des Judges zu unterscheiden.

• Praktische Auswirkung: Die Konstruktion liefert eine präzise Garantie, dass Judge-Drift niemals über ein definiertes Fehlerrisiko ($\alpha_{judge}$) hinaus lautlos dem System zugeschrieben wird. Dies verhindert, dass Teams teure, falsche operative Entscheidungen treffen (z. B. das Zurückrollen gesunder Modelle).
• Theoretischer Beitrag: Es zeigt, dass Anytime-Validity nicht nur eine theoretische Feinheit, sondern eine praktische Notwendigkeit für die kontinuierliche Überwachung ist, da Standardmethoden mit festem Horizont bei sequenziellen Tests katastrophal versagen.
• Designgesetz: Das Paper etabliert, dass Attribuierung ein Wettlauf ist. Es bietet ein konkretes Rezept zur „Ko-Bereitstellung“: Das Anker-Budget muss so dimensioniert sein, dass der Anker-Prozess den Judge-Drift schneller erkennt, als der kontaminierte Hauptprozess einen falschen System-Alarm auslösen kann.
• Limitierungen: Die Autoren merken bescheiden an, dass die Methode voraussetzt, dass menschliche Labels eine gültige Referenz bleiben (was bei sich ändernden Standards eine regelmäßige Aktualisierung erfordert) und dass sie nicht auf die Optimierung von Betting-Strategien oder minimale Fehlattribution bei festen Budgets abzielt, sondern auf Validität und Identifikation.

Zusammenfassend präsentiert das Paper ein robustes, kostenbewusstes Framework, das den ambivalenten „Drift-Alarm“ in eine verifizierbare Attribuierung verwandelt und sicherstellt, dass das „Lineal“ genauso streng überwacht wird wie das „Produkt“, das es misst.