🤖 AI

Deployment-Relevant Alignment Cannot Be Inferred from Model-Level Evaluation Alone

Dit artikel betoogt dat implementatie-relevante uitlijning niet kan worden afgeleid uitsluitend uit modelniveau-evaluaties, en toont via audits en stress-tests aan dat huidige benchmarks verwaarlozen van gebruikersgerichte verificatie en processtuurbaarheid, waardoor een verschuiving naar systeemniveau-evaluatiekaders noodzakelijk is die expliciet rekening houden met interactieve contexten en opbouwwerkafhankelijkheden.

Oorspronkelijke auteurs: Varad Vishwarupe, Nigel Shadbolt, Marina Jirotka, Ivan Flechais

Gepubliceerd 2026-05-07

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Varad Vishwarupe, Nigel Shadbolt, Marina Jirotka, Ivan Flechais

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

De Kernidee: De "Autotest" versus de "Wegtocht"

Stel je voor dat je wilt weten of een nieuwe zelfrijdende auto veilig is om op echte snelwegen te rijden.

Huidige Praktijk (Modelniveau-evaluatie):
Op dit moment testen onderzoekers het "brein" van de auto (het AI-model) in een rustige, lege garage. Ze vragen het: "Als ik op de rem trap, stopt hij dan?" of "Als ik om de tijd vraag, geef je dan de juiste tijd?"
Als de auto in de garage correct antwoordt, gaan we ervan uit dat hij overal veilig kan rijden. We geven hem een hoge score en zeggen: "Deze auto is in lijn met veiligheidsregels."

Het Argument van het Artikel:
De auteurs zeggen dat dit een gevaarlijke vergissing is. Alleen omdat het brein van de auto perfect werkt in een garage, betekent niet dat hij een regenachtige snelweg, een verwarde passagier of een plotselinge omleiding aankan.

De Garage = De huidige benchmarks (het testen van het model alleen).
De Snelweg = De echte wereld (waar de AI daadwerkelijk wordt gebruikt).

Het artikel betoogt dat je niet kunt afleiden hoe de auto zich op de snelweg gedraagt door hem alleen in de garage te testen. Om te weten of de AI in de echte wereld echt "in lijn" is (veilig en behulpzaam), moet je hem testen terwijl hij rijdt, met passagiers en met verkeer.

De Vier Niveaus van Testen

De auteurs splitsen AI-testen op in vier verschillende "verdiepingen" van een gebouw. Huidig testen gebeurt grotendeels op de tweede verdieping, maar we maken beweringen over de vierde.

Verdieping 1: Het Model (Het Brein): Testen van de ruwe code en gewichten. ("Werkt de wiskunde?")
Verdieping 2: Het Antwoord (Het Antwoord): Het model een vaste vraag geven en zijn enkele antwoord beoordelen. ("Gaf het '42' als antwoord op 6x9?") Hier vindt bijna al het huidige testen plaats.
Verdieping 3: De Interactie (Het Gesprek): Kijken hoe de AI over meerdere beurten praat. Vraagt het om verduidelijking? Laat het de gebruiker het plan aanpassen? Erkent het wanneer het onzeker is?
Verdieping 4: De Implementatie (De Echte Baan): De AI die werkt binnen een specifiek bedrijf, met echte regels, echte bazen en echte gebruikers.

Het Probleem: We testen op Verdieping 2, maar we doen beloften over Verdieping 4. Het gat tussen deze verdiepingen is enorm.

De Twee Grote Studies (Het Bewijs)

De auteurs zeiden dit niet zomaar; ze deden twee studies om het te bewijzen.

Studie 1: De "Werkbank"-Audit

Ze keken naar 11 van de beroemdste AI-testtools (benchmarks) om te zien wat ze eigenlijk meten. Ze gebruikten een checklist met 8 belangrijke "interactieve vaardigheden", zoals:

Verificatieondersteuning: Laat de AI haar werk zien zodat de gebruiker kan controleren of het juist is? (Zoals je wiskundehuiswerk tonen).
Stuurbaarheid van het Proces: Kan de gebruiker de AI vertellen om hoe het probleem wordt opgelost, te veranderen? (Zoals zeggen: "Nee, probeer een andere route.")

De Bevindingen:

Het "Verificatie"-Vacuüm: Nul van de 11 benchmarks controleerde of de AI de gebruiker helpt het antwoord te verifiëren. Ze controleerden alleen of het antwoord "correct" was, niet of de gebruiker erop kon vertrouwen.
Het "Stuurbaarheid"-Gat: Bijna geen enkele benchmark controleerde of de gebruiker het proces kon sturen.
Fragmentatie: De weinige tests die interactieve vaardigheden wel controleerden, waren verspreid. Eén testte het geheugen, een ander het gebruik van tools, maar geen enkele testte het hele plaatje. Het is alsof je een gereedschapskist hebt waar één tool een hamer is, een ander een schroevendraaier, maar je hebt geen steeksleutel.

De Metafoor: Stel je voor dat je een kok oordeelt alleen op basis van hoe goed hij uien snijdt in een stille keuken. Je ziet ze nooit de soep proeven, de klant vragen of ze allergisch zijn voor noten, of het recept aanpassen aan de stemming van de klant. Je weet niet of ze een goede kok zijn, alleen een goede uien-snijder.

Studie 2: De "Stress-test: Dezelfde Auto, Verschillende Wegen"

De auteurs namen drie verschillende AI-modellen (Claude, GPT-4o en Llama) en hielden hun "hersenen" exact hetzelfde. Vervolgens veranderden ze de steigers (de instructies en het interface dat het model omhult).

Ze gaven de modellen vier verschillende "outfits":

Gewone Chat: Gewoon praten.
Verduidelijkingmodus: De AI dwingen om vragen te stellen voordat hij antwoordt.
Planmodus: De AI dwingen om een plan te tonen voordat het handelt.
Verificatiemodus: De AI dwingen om zijn aannames te tonen en hoe het antwoord gecontroleerd kan worden.

Het Schokkende Resultaat:

Model A (Claude): Toen het in de "Verificatiemodus" werd geplaatst, werd het geweldig in het helpen van gebruikers om antwoorden te controleren.
Model B (GPT-4o): Toen het in exact dezelfde "Verificatiemodus" werd geplaatst, veranderde het helemaal niet. Het bleef hetzelfde.
Model C (Llama): Het veranderde nauwelijks, en in sommige gevallen werd het slechter in het volgen van instructies.

De Les: De "outfit" (het systeemontwerp) is net zo belangrijk als het "brein" (het model). Je kunt niet voorspellen hoe een model zich in een echt systeem zal gedragen door alleen naar het model te kijken. Dezelfde instructies werken wonderen voor één AI en doen niets voor een andere.

Wat Moeten We In plaats Dienen?

Het artikel stelt een nieuwe manier voor om AI-resultaten te rapporteren, genaamd een "Alignementprofiel".

In plaats van te zeggen: "Deze AI heeft een score van 95/100 en is veilig voor ziekenhuizen." (Dit is een leugen gebaseerd op garagetesten).

Zouden we moeten zeggen: "Deze AI, wanneer gebruikt met [Specifieke Instructies] en [Specifieke Gebruikersinterface], toonde deze specifieke gedragingen. We hebben het niet getest in een echt ziekenhuis, dus we kunnen niet beweren dat het veilig is voor die specifieke baan."

Het Voorstel:

Stop met doen alsof één score alles dekt.
Test het hele systeem: Test het model plus de instructies plus de gebruikersinterface samen.
Wees eerlijk over het gat: Geef duidelijk aan: "We hebben dit getest in een garage. We hebben het nog niet op de snelweg getest."

Samenvatting

Het artikel betoogt dat AI-alignement geen eigenschap is van het brein alleen; het is een eigenschap van het hele systeem. Je kunt een zelfrijdende auto niet beoordelen door zijn motor in een lab te testen. Je moet hem op de weg rijden, met een passagier, in de regen. Totdat we beginnen met het testen van AI in die context, zijn onze beweringen over zijn veiligheid en behulpzaamheid slechts gissingen.

Technische Samenvatting: Implementatie-relevante Uitlijning Kan Niet Alleen Worden Afgeleid uit Model-niveau Evaluatie

Probleemstelling

De huidige uitlijningsevaluatie in machine learning richt zich voornamelijk op model-niveau of antwoord-niveau metrieken. Invloedrijke benchmarks scoren modeloutput onder vaste invoer (bijvoorbeeld waarheidsgetrouwheid, instructie-gevolgzaamheid, paarwijze voorkeur) en behandelen deze scores als voldoende bewijs voor claims over implementatie-uitlijning.

Het artikel betoogt dat deze inferentie ongeldig is. Implementatie-relevante uitlijning is een systeem-niveau fenomeen dat afhankelijk is van de interactie tussen het model ( $M$ ), de steigerstructuur ( $S$ —prompten, geheugen, tools, UI) en de implementatiecontext ( $C$ —gebruikerspopulatie, toezicht, beleid). Omdat huidige benchmarks $S$ en $C$ vasthouden of negeren, kunnen ze geen eigenschappen meten die essentieel zijn voor ingezette systemen, zoals ondersteuning bij verificatie, stuurbaarheid van het proces, of de verdeling van de last van herstel. Het artikel postuleert een "niet-identificeerbaarheids"-probleem: het evalueren van $M$ alleen kan niet onderscheid maken tussen verschillende implementaties van hetzelfde model die sterk verschillende uitlijningsrelevante gedragingen vertonen als gevolg van verschillen in $S$ .

Methodologie

Het artikel hanteert twee primaire empirische studies om zijn positie te onderbouwen:

1. Gestructureerde Benchmark Audit

Scope: Een dubbel-coderende audit van 11 primaire benchmarks (plus een meta-evaluatie controle, JudgeBench) en een uitbreiding tot in totaal 16 benchmarks.
Rubriek: Een rubriek met acht dimensies, afgeleid uit literatuur over interactieve en implementatie-niveau uitlijning (Terry et al., Shen et al., en empirisch werk over grounding/herstel). De dimensies zijn:
- D1: Specificatie Uitlijning (omgaan met ondergespecificeerde verzoeken).
- D2: Proces Uitlijning/Stuurbaarheid (gebruikerscontrole over het redeneerproces).
- D3: Evaluatie Uitlijning/Verificatie Ondersteuning (gebruikers helpen bij het verifiëren van output).
- D4: Meerdere-rondes Contextbehoud.
- D5: Grounding/Gemeenschappelijke Grond.
- D6: Verdeling van de Last van Herstel.
- D7: Personalisatie/Gebruikers-specifieke Uitlijning.
- D8: Werkstroom/Toezicht Realisme.
Protocol: Twee getrainde externe coderders scoorden onafhankelijk benchmarks op een 0–2 verankerde schaal (0: afwezig, 1: gedeeltelijk/bijzaak, 2: substantieel). Onenigheid werd opgelost via verankering-gedreven reconciliatie.
Betrouwbaarheid: Cohen's $\kappa$ was 0,87 over de 128 cellen van het corpus van 16 benchmarks.

2. Blinde Cross-Model Stress Test

Ontwerp: Een studie waarbij modelgewichten ( $M$ ) en implementatiecontext ( $C$ ) ongeveer vastgehouden werden terwijl alleen de interactie-steigerstructuur ( $S$ ) varieerde.
Variabelen:
- Modellen: Drie frontier-modellen (Claude-Opus-4.7, GPT-4o, Llama-4-Scout).
- Steigers: Vier condities variërend van een gewone chatbot (C1) tot expliciete prompten voor verificatie-ondersteuning (C4).
- Data: 180 transcripten (60 per model) over medische, juridische en technische domeinen.
Protocol: Transcripten werden geblind, ontdaan van systeem-prompten, en gecodeerd door twee beoordelaars voor D1, D2 en D3. Onenigheid werd opgelost met een conservatief-min beleid.

Belangrijkste Bevindingen

Uit de Benchmark Audit

Het D3 Vacuüm: Verificatie-ondersteuning (D3) is afwezig in alle 11 geauditeerde benchmarks. Geen enkele benchmark evalueert expliciet of de output van een model een gebruiker helpt bij het verifiëren, bekritiseren of begrijpen van het antwoord.
Bijna-Afwezigheid van Stuurbaarheid: Proces-stuurbaarheid (D2) is bijna afwezig, met een niet-nul score in slechts één benchmark ( $\tau$ -bench) en zelfs daar slechts als een gedeeltelijke score, niet als expliciete gebruikerscontrole.
Fragmentatie van Interactieve Benchmarks: De vier geïdentificeerde interactieve benchmarks (CURATe, Rifts, $\tau$ -bench, Common Ground) meten verschillende, niet-overlappende subsets van dimensies. Er is geen geünificeerd evaluatiedoel voor interactieve uitlijning.
Constructie Bepaalt Meting: De structuur van de evaluatie (hoe de benchmark is opgebouwd) bepaalt wat er wordt gemeten, niet de data-bron. Bijvoorbeeld, WildBench gebruikt echte gebruikerslogs maar scoort single-response checklists, waardoor het interactieve eigenschappen niet vastlegt ondanks zijn ecologisch realisme.

Uit de Cross-Model Stress Test

Model-afhankelijke Steiger Effectiviteit: Dezelfde steigerstructuur ( $S$ $S$ ) produceert categorisch verschillende gedragsuitkomsten over modellen heen.
- Claude-Opus-4.7: Zeer plastisch; de C4 verificatie-steiger tilde zijn D3-score van 0,42 naar 2,00 (plafond).
- GPT-4o: Verzadigd; dezelfde C4-steiger had geen meetbaar effect op D3 (bleef op 0,33).
- Llama-4-Scout: Gedeeltelijk omgekeerd; toonde zwakke gevoeligheid en categorische afwezigheid van D2 over alle steigers heen.
Implicatie: De in de audit geïdentificeerde kloof (ontbrekende metingen van interactieve eigenschappen) kan niet op model-niveau worden gedicht, omdat steiger-effectiviteit op zichzelf een functie is van de modelgewichten.

Belangrijkste Bijdragen

Niveau-geïndexeerde Framing: Het artikel stelt voor om vier niveaus van uitlijningsevaluatie te onderscheiden: Model-niveau (gewichten/doelen), Antwoord-niveau (output onder vaste invoer), Interactie-niveau (meerdere-rondes eigenschappen) en Implementatie-niveau (systeem-in-werkstroom). Het betoogt dat claims moeten worden geïndexeerd aan het niveau van het bewijs.
Gestructureerde Audit Bewijs: Levert empirisch bewijs dat het huidige benchmark-ecosysteem systematisch faalt in het meten van kritieke interactieve dimensies (specifiek D2 en D3).
Niet-identificeerbaarheids Bewijs: Demonstreert via de stress test dat $B = f(M, S, C)$ niet kan worden afgeleid uit $M$ alleen, omdat $S$ op model-afhankelijke manieren met $M$ interageert.
Evaluatie Agenda: Stelt een verschuiving voor van enkele uitlijningsscores naar uitlijningsprofielen. Dit omvat:
- Het rapporteren van bewijs over de acht dimensies.
- Het gebruik van protocollen met vaste steigers voor vergelijkbare interactieve evaluatie.
- Een rapportage-sjabloon met zes rijen (Bijlage G.1) dat auteurs dwingt om expliciet de reikwijdte van hun claims te specificeren (welke $M, S, C$ configuraties het bewijs ondersteunt).

Betekenis en Claims

Het artikel claimt dat de afhankelijkheid van het veld van antwoord-niveau benchmarks om claims over implementatie-uitlijning te legitimeren, structureel gebrekkig is. De "inferentiële kloof" tussen benchmarkprestaties en ingezet gedrag is groter dan momenteel wordt erkend.

De betekenis van het werk ligt in:

Correctie van de Reikwijdte van Claims: Betogen dat model-niveau bewijs onvoldoende is voor implementatie-niveau claims en dat het toevoegen van meer antwoord-niveau benchmarks het probleem niet zal oplossen.
Methodologische Discipline: Het introduceren van een kader waarin uitlijningsclaims expliciet worden geschaald naar het niveau van het verzamelde bewijs, waardoor het vermengen van model-eigenschappen met systeem-gedrag wordt voorkomen.
Empirische Validatie: Het leveren van direct bewijs dat interactieve eigenschappen niet intrinsiek zijn aan het model, maar emergente eigenschappen van het systeem ( $M+S+C$ ) zijn, en dat deze eigenschappen aanzienlijk variëren tussen modellen, zelfs met identieke steigers.

Het artikel claimt niet dat model-niveau evaluatie nutteloos is, maar wel dat het onvoldoende is voor claims over implementatie. Het roept de gemeenschap op om evaluatieve vocabulaires en protocollen te ontwikkelen die rekening houden met het systeem, de interactie en de gebruiker, in plaats van uitsluitend te focussen op het model.