🤖 AI

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

Dit artikel introduceert een anytime-valid attributiekader dat de ambiguïteit tussen productdegradatie en LLM-judge drift in continue evaluatiepipelines oplost door gebruik te maken van een vaste menselijk gelabelde ankerset en een betting e-proces om betrouwbaar onderscheid te maken tussen systeem- en judge-fouten, waarbij het standaard statistische methoden overtreft in nauwkeurigheid en kostenefficiëntie.

Oorspronkelijke auteurs: Yitao Li

Gepubliceerd 2026-06-16

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yitao Li

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Kernprobleem: De "Gebroken Liniaal"

Stel je voor dat je een bakkerij runt. Je wilt weten of je taarten in de loop der tijd slechter worden. Om dit te controleren, huur je een zeer dure, hoogopgeleide "Meesterproever" in (de Sterke Rechter) om elke taart te proeven en een score te geven.

Echter, de Meesterproever is te duur om elke taart te proeven. Daarom huur je een goedkopere, snellere "Assistentproever" in (de Goedkope Rechter) om elke enkele taart te proeven. Je vraagt de Meesterproever alleen om een paar willekeurige taarten te proeven om te controleren of de Assistent zijn werk goed doet.

De Catch: De Meesterproever is geen mens; het is een AI-model achter een API. Soms past het bedrijf dat de Meesterproever heeft gebouwd de software stilletjes aan (een "version bump") of verandert de instructies. Plotseling wordt de Meesterproever veel strenger of juist veel milder.

Nu heb je een crisis:

Als de scores van je taarten dalen, is de bakker dan een slechte taart gaan maken? (Systeemdrift)
Of heeft de Meesterproever gewoon van mening veranderd over wat een "goede" taart is? (Judge Drift)

Als je de bakker de schuld geeft terwijl het eigenlijk de Proever was, word je een goede bakker ontslagen. Als je de Proever de schuld geeft terwijl de bakker daadwerkelijk een fout maakte, blijf je slechte taarten verkopen. Het paper noemt dit de "Ambiguity of the Drift" (de ambiguïteit van de drift).

De Oplossing: De "Anchor" Set

De auteurs stellen een slimme oplossing voor om dit mysterie op te lossen. Ze introduceren een speciale groep taarten genaamd de "Anchor Set" (Ankerset).

De Bevroren Anker: Voordat je begint met monitoren, neem je een specifieijke set taarten, laat je een Mens deze proeven en schrijf je de "Ware Score" op een papiertje. Je legt deze taarten in een vriezer. Ze veranderen nooit.
De Race: Af en toe haal je een van deze bevroren taarten uit de vriezer en vraag je de huidige Meesterproever om de taart opnieuw te proeven.
- Als de score van de Meesterproever op deze bevroren taart verandert, weten we dat de Proever is veranderd. (De taart is niet veranderd; de Proever wel).
- Als de score van de Meesterproever op de bevroren taart gelijk blijft, maar de scores op de nieuwe taarten dalen, weten we dat de Bakker is veranderd. (De Prover is consistent; het product is slechter geworden).

Hoe het werkt: De "Guard Window"

Het systeem draait twee aparte alarmen tegelijkertijd:

Alarm A (De Bakker): Houdt de nieuwe taarten in de gaten. Als de scores dalen, schreeuwt het: "Slechte Bakker!"
Alarm B (De Prover): Houdt de bevroren Anker-taarten in de gaten. Als de scores veranderen, schreeuwt het: "Slechte Prover!"

Het paper introduceert een "Guard Window" regel om te beslissen wie de schuld krijgt:

Als Alarm B (Prover) eerst afgaat, of als Alarm A afgaat maar Alarm B kort daarna ook afgaat, zegt het systeem: "Het is de Rechter." (De Prover is veranderd, dus we kunnen het alarm van de Bakker niet vertrouwen).
Als Alarm A (Bakker) afgaat en Alarm B (Prover) nooit afgaat (of pas heel lang later), zegt het systeem: "Het is het Systeem." (De Prover is stabiel; het product is kapot).

Het "Race" Concept

Het paper beschrijft dit als een race.

Het "Anker-proces" (het bewaken van de bevroren taarten) moet snel genoeg zijn om de verandering van de Prover te vangen voordat het "Hoofdproces" (het bewaken van de nieuwe taarten) de Bakker onterecht beschuldigt.
Als het Anker te traag is, kan het Hoofdproces "Slechte Bakker!" roepen voordat het Anker beseft: "Wacht even, de Prover is net veranderd!"
Het paper bewijst wiskundig dat als je het Anker correct instelt (genoeg bevroren taarten, ze vaak genoeg proeven), het Anker de race tegen een veranderende Prover altijd zal winnen.

Wat ze vonden (De Resultaten)

De auteurs testten dit met echte AI-modellen (Google's Gemini) en echte data (nuttige assistent-antwoorden en samenvattings-taken).

Stille Updates: Ze simuleerden een "stille version bump" waarbij de AI-Prover iets milder werd.
- Resultaat: Hun systeem identificeerde dit 100% van de tijd correct als een "Judge Drift". Het gaf de Bakker nooit onterecht de schuld.
- Falen van de oude methode: De industriestandaard methode (een eenvoudige statistische test) riep 75% van de tijd "Slechte Bakker!" wanneer er eigenlijk niets was veranderd. Het was een machine voor valse alarmen.
Strenge Updates: Ze simuleerden een Prover die plotseling veel strenger werd.
- Resultaat: Het systeem identificeerde dit bijna altijd correct als een "Judge Drift".
- De "Race" in actie: Op één dataset veranderde de Prover zo drastisch dat de Ankers het onmiddellijk oppikten en de race perfect wonnen. Op een andere dataset was de verandering subtieler, waardoor de Ankers iets langer nodig hadden, maar de "Guard Window" regel redde de dag nog steeds.
Kosten:
- Elke individuele item controleren met de dure Meesterproever is te kostbaar.
- Hun methode gebruikt de goedkope Assistent voor alles, de dure Meester voor een paar willekeurige items, en de Ankers voor een kleine, constante stroom.
- Kosten: Het kost ongeveer 64% van de prijs van het controleren van alles met de Meesterprover, maar het is veel slimmer en geeft geen valse beschuldigingen. Er is ook een "goedkopere maar doofdere" versie die slechts 21% kost, maar mogelijk sommige slechte taarten mist.

Samenvatting

Het paper lost het probleem van "Wie is er gedrift?" op door gebruik te maken van bevroren, door mensen gelabelde voorbeelden als referentiepunt.

Als het referentiepunt beweegt, is de Rechter veranderd.
Als het referentiepunt stilstaat maar de nieuwe producten bewegen, is het Systeem veranderd.

Ze hebben bewezen dat dit werkt via de wiskunde en laten zien dat het de huidige industriestandaard verslaat, die gevoelig is voor valse alarmen. Het is als het hebben van een "waarheid-anker" dat de kwaliteitscontrole eerlijk houdt, zelfs wanneer de persoon die oordeelt van mening verandert.

Technische Samenvatting: Wie dreef er? Anytime-Valid Attributie in LLM-evaluatiepijplijnen

1. Het Probleem

De continue evaluatie van Large Language Model (LLM) producten leunt steeds vaker op "LLM-as-judge"-pijplijnen, waarbij een sterker model interacties scoort om alerts te triggeren wanneer de prestaties verslechteren. De fundamentele aanname in deze systemen is dat de rechter fungeert als een vaste meetlat; een daling in scores impliceert dus een regressie in het product. De rechter zelf is echter een API-gebaseerd model dat onderhevig is aan stille versie-updates, prompt-updates of beleidswijzigingen.

Wanneer een monitoringsysteem een alarm afgeeft, ontstaat er een ambiguïteit: is de kwaliteit van het product verslechterd, of is het scoringsgedrag van de rechter veranderd? Het handelen op de verkeerde attributie is kostbaar: teams kunnen een gezond product terugdraaien (rollback) of een regressie introduceren door het alarm af te doen als "judge drift". Klassieke statistische methoden, zoals rollende z-tests, falen in deze context van continue monitoring omdat ze niet anytime-valid zijn; het herhaaldelijk uitvoeren van een test met een vaste $\alpha$ bij elke stap leidt tot een inflatie van het aantal vals-positieven, wat resulteert in spookdetecties zelfs bij drift-vrije stromen.

2. Methodologie

Het paper stelt een raamwerk voor om systeemdrift te onderscheiden van judge drift met behulp van anytime-valid e-processes en een menselijk-geankerde attributieregel.

A. De Budgetted Main Monitor (Systeemdriftdetectie)
Het systeem gebruikt een gestratificeerde, prediction-powered monitor (volgens Csillag et al., 2025b; Angelopoulos et al., 2023) om kwaliteitsregressies te detecteren:

Architectuur: Een goedkope rechter ( $\mu$ ) scoort elk item, terwijl een dure, sterkere rechter ( $y$ ) een gesamplede subset scoort onder een vast budget.
Mechanisme: Voor elke (rubriek $\times$ stratum) cel accumuleert een prediction-powered e-process "welvaart" (wealth) om de nulhypothese te testen dat het gemiddelde score niet onder een gezonde baseline is gezakt.
Kostenefficiëntie: Het systeem gebruikt een e-wealth escalation trigger. Naarmate er meer bewijs van drift wordt verzameld, neemt de kans op sampling door de sterkere rechter toe. Dit stelt het systeem in staat om gelokaliseerde blind spot-regressies te detecteren tegen ongeveer een derde van de kosten van een volledige evaluatie, terwijl de anytime-validiteit behouden blijft (het garandeert dat de fout-alarm-ratio op elk willekeurig tijdstip begrensd blijft).

B. De Anchor Constructie (Judge Driftdetectie)
Om de ambiguïteit in attributie op te lossen, introduceren de auteurs een tweede, onafhankelijke e-process dat geankerd is aan vaste menselijke labels:

Anchor Set ( $A$ ): Een vaste, uit de reserve gehouden collectie items met bevroren menselijke labels ( $h$ ), verzameld voordat de monitoring begon.
Interleave: Met een constante frequentie (bijv. elke $1/\rho$ items) scoort de huidige sterke rechter opnieuw een willekeurig gekozen anchor-item.
De E-Process: Een betting e-process volgt het gat tussen de huidige score van de rechter op de anchor en het bevroren menselijke label.
Asymmetrie: Omdat de anchor-items en menselijke labels vaststaan, kan alleen een verandering in de rechter de verdeling van het gat veranderen. Systeemdrift beïnvloedt binnenkomende items, maar laat het gat van de anchor onveranderd. Dit creëert een "eenrichtingsspiegel" die uitsluitend judge drift detecteert.

C. De Attributieregel (Guard Window)
Het systeem combineert de stoppertijden van het hoofdproces ( $\tau_{sys}$ ) en het anchor-proces ( $\tau_{anc}$ ) met behulp van een guard window ( $W$ ) om een oordeel te vellen in de categorieën $\{geen, systeem, rechter\}$ :

Rechter-oordeel: Als het anchor-proces eerst afgaat ( $\tau_{anc} < \infty$ ) en het hoofdproces binnen het guard window afgaat ( $\tau_{sys} \le \tau_{anc} + W$ ), dan is het oordeel rechter. De logica is dat een besmette rechter de validiteit van het hoofdalarm ongeldig maakt.
Systeem-oordeel: Als het hoofdproces eerst afgaat en het anchor-proces niet binnen het guard window afgaat, dan is het oordeel systeem.
Race Condition: Het ontwerp rust op een "attribution race". Om misattributie te voorkomen, moet het anchor-proces zodanig geprovisioneerd zijn dat het judge drift sneller detecteert dan de besmette hoofdproces een vals systeemalarm kan triggeren.

3. Belangrijkste Bijdragen

Anchor Constructie & Attributieregel: Een nieuwe methode die gebruikmaakt van een menselijk-geankerde, anytime-valid e-process om systeemdrift expliciet te scheiden van judge drift, waarbij een driestands-oordeel wordt afgegeven in plaats van een binair alarm.
Theoretische Garanties:
- Anytime-validiteit: De anchor-familie behoudt een begrensde fout-alarm-rate ( $\alpha_{judge}$ ) op elk data-afhankelijk stoppertijdstip.
- Eenzijdige Identificatie: Het anchor-proces is wiskundig gegarandeerd ongevoelig voor systeemdrift; het kan alleen worden getriggerd door een verandering in de rechter.
- Attribution Race: Het paper stelt een ontwerpregel vast waarbij het anchor-proces moet worden geprovisioneerd om de "race" te winnen van het hoofdproces. Misattributie (valse systeemalarmen tijdens judge drift) is een functie van de breedte van het guard window, de anchor-frequentie en de grootte van de anchor-set.
- Orthogonaliteit: Het anchor-budget en de configuratie van het hoofdproces zijn onafhankelijk, wat aparte afstemming van de latency van de rechter en de power van het systeem mogelijk maakt.
Empirische Validatie op Echte Drifts: De methode werd getest op twee echte judge-veranderingen (een stille versie-update en een strikte prompt-beleidswijziging) over twee domeinen (HelpSteer2 en TL;DR samenvatting) zonder her-afstemming.
Operationele Superioriteit: Het voorgestelde e-process presteert aanzienlijk beter dan klassieke baselines (naïeve rollende z-tests en gekalibreerde Page–Hinkley detectoren) wat betreft controle over fout-alarmen en de detectie van subtiele drifts.

4. Resultaten

Detectie-accuratesse:
- Stille Versie-update: Gedetecteerd als judge drift in 60/60 runs met nul judge-naar-systeem misattributie.
- Strikte Prompt-wijziging: Correct geattribueerd in 110/120 runs (bij een guard width $W=300$ ) op HelpSteer2. Op het TL;DR domein, waar de prompt-verschuiving ernstiger was, was de attributie perfect (240/240).
- Misattributie: Het percentage valse systeemalarmen tijdens judge drift nam monotoon af naarmate het guard window ( $W$ ) groter werd, wat de "attribution race"-theorie bevestigt.
Vergelijking met Baselines:
- Een naïeve rollende z-test (industriestandaard) genereerde fout-alarmen op 75% van de drift-vrije stromen.
- Een gekalibreerde Page–Hinkley detector hield weliswaar het fout-alarm budget in stand, maar faalde in het detecteren van de subtiele echte versie-update (slechts 8% detectie op HelpSteer2) en vereiste uitgestelde kalibratiedata.
Kostenefficiëntie: De monitor werkt op ongeveer 0,64 van de kosten van het volledig evalueren van elk item (of 0,21 in een "goedkoper-maar-minder-gevoelige" regime), terwijl de geldige detectiegaranties behouden blijven.

5. Betekenis en Claims

Het paper beweert een kritieke, onbehandelde faalmodus in LLM-operations op te lossen: het onvermogen om onderscheid te maken tussen productdegradatie en instabiliteit van de rechter tijdens continue monitoring.

Praktische Impact: De constructie biedt een scherpe garantie dat judge drift nooit stilzwijgend aan het systeem wordt toegeschreven boven een gedefinieerd foutenbudget ( $\alpha_{judge}$ ). Dit voorkomt dat teams dure, onjuiste operationele beslissingen nemen (bijv. het terugdraaien van gezonde modellen).
Theoretische Bijdrage: Het demonstreert dat anytime-validity niet slechts een theoretische luxe is, maar een praktische noodzaak voor continue monitoring, aangezien standaard fixed-horizon methoden catastrofaal falen onder sequentiële testen.
Ontwerpregel: Het paper stelt vast dat attributie een race is. Het biedt een concreet "co-provisioning" recept: het anchor-budget moet zo worden bepaald dat het anchor-proces de judge drift sneller detecteert dan de besmette hoofdproces een vals systeemalarm kan triggeren.
Beperkingen: De auteurs merken bescheiden op dat de methode ervan uitgaat dat menselijke labels een geldige referentie blijven (wat periodieke verversing vereist als standaarden evolueren) en dat het geen aanspraak maakt op optimaliteit in betting-strategieën of minimale misattributie bij vaste budgetten, maar op validiteit en identificatie.

Samenvattend presenteert het paper een robuust, kostenbewust raamwerk dat het ambigue "drift alarm" transformeert in een verifieerbare attributie, waardoor wordt gewaarborgd dat de "meetlat" net zo strikt wordt gemonitord als het "product" dat zij meet.