🤖 machine learning

Toward User-Conditioned Evaluation of Personal LLM Agents under Temporal Interventions

Deze positiepaper betoogt dat bestaande benchmarks falen in het evalueren van persoonlijke LLM-agenten onder temporele interventies door geen rekening te houden met gebruikersgeconditioneerde staatsevolutie, en stelt een nieuw evaluatieprotocol voor met specifieke condities en metrieken om dit gat te dichten.

Oorspronkelijke auteurs: Pin Qian, Su Wang, Yihang Chen, Qiaolin Yu, Xiaoyuan Wang, Zhitong Guo, Zhicheng Wang, Junxian You

Gepubliceerd 2026-07-27

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pin Qian, Su Wang, Yihang Chen, Qiaolin Yu, Xiaoyuan Wang, Zhitong Guo, Zhicheng Wang, Junxian You

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

Stel je voor dat je een robotbutler bouwt. In de begindagen van de robotica testten we ze in een steriele labomgeving: we gaven ze een schoon kopje, vroegen ze om het te wassen, en controleerden of ze het deden zonder het kopje te breken. Als ze dat slaagden, waren ze "goed". Maar het echte leven is geen steriel lab. Het echte leven is rommelig. Jouw robotbutler woont bij jou. Hij onthoudt dat je je koffie met twee suikers drinkt, dat je het haat als het licht flikkert, en hij heeft een specifieke dans geleerd om je slimme koelkast te openen. Hij heeft een langetermijngeheugen van jouw gewoonten en een reeks vaardigheden die hij speciaal voor jouw huis heeft opgepikt.

Stel je nu voor dat de fabrikant van de slimme koelkast een software-update stuurt die verandert hoe de deur opengaat. In de oude labtests zou de robot misschien gewoon één keer falen bij het openen van de deur en dan stoppen. Maar in jouw huis zou de robot in paniek kunnen raken. Omdat hij zich de oude manier herinnert waarop de deur werkte, probeert hij de deur misschien met geweld open te duwen, breekt hij de handgreep, en morst hij vervolgens per ongeluk je koffie omdat hij in de war is. Het probleem is niet alleen dat de robot faalde; het is dat zijn persoonlijke herinneringen en geleerde gewoonten de fout lieten overslaan naar andere delen van je leven. Dit artikel gaat over het uitzoeken hoe je robots niet alleen test op het uitvoeren van een taak, maar ook op hoe ze omgaan met deze persoonlijke, rommelige, geheugenrijke rampen wanneer de wereld om hen heen verandert.

Het Paper: Waarom je Robotbutler je Zou Kunnen Vergeten (en Waarom We een Nieuwe Test Nodig Hebben)

De auteurs van dit paper, een team van onderzoekers van plekken zoals Carnegie Mellon en Georgia Tech, kijken naar een specifiek blinde vlek in hoe we "Persoonlijke AI-agenten" testen. Dit zijn de hippe AI-assistenten die bedoeld zijn om jou te kennen, jouw voorkeuren te onthouden en jouw routines in de loop van de tijd te leren.

Momenteel, wanneer wetenschappers deze AI-agenten testen, behandelen ze ze als afzonderlijke, geïsoleerde machines. Ze hebben een "Geheugentest" om te zien of de AI je verjaardag onthoudt. Ze hebben een "Tool-test" om te zien of de AI een rekenmachine kan gebruiken. Ze hebben een "Veiligheidstest" om te zien of de AI weigert iets gemeens te zeggen. Maar de auteurs stellen dat dit is alsof je de remmen, de motor en de GPS van een auto op drie verschillende dagen, in drie verschillende garages test, en dan zegt: "Geweldig, de auto is veilig!"

De realiteit is dat deze dingen allemaal verbonden zijn. Als de GPS een update krijgt (een "temporele interventie"), kan dit de motor in de war brengen, wat er weer toe kan leiden dat de remmen falen. In de wereld van AI, als een API (het hulpmiddel dat de AI gebruikt) verandert, kan een AI die "herinneringen" heeft aan de oude tool, proberen de oude instructies te gebruiken, wat een vaardigheid die hij heeft geleerd kan breken, wat er vervolgens weer toe kan leiden dat hij een veiligheidsregel overtreedt die hij juist moest naleven.

De Grote Ontdekking: De "Perfect Storm"-test Bestaat Niet

De onderzoekers gingen op zoek naar een test die dit specifieke soort rommeligheid kon vangen. Ze stelden vier regels op voor hoe een "Perfect Storm"-test eruit zou moeten zien:

De Verandering: Er moet iets in de wereld veranderen (zoals een tool-update) terwijl de AI aan het werk is.
Het Geheugen: De AI moet zijn persoonlijke geschiedenis (herinneringen, vaardigheden, instellingen) meedragen over die verandering heen.
De Rimpeling: De test moet meten hoe die verandering andere dingen die de AI aan het doen was, verstoort (zoals een herinnering die een tool doet falen).
De Persoon: De test moet laten zien dat dezelfde verandering verschillende mensen anders raakt. Een "lichte gebruiker" (die niet veel van de AI afhankelijk is) is misschien oké, maar een "power user" (die de AI zijn hele leven heeft laten onthouden) kan een totale meltdown krijgen.

De auteurs gingen vervolgens op een detectivespel. Ze bekeken 15 van de meest populaire, publieke tests voor AI-agenten die er op dat moment waren. Ze controleerden deze tegen hun vier regels.

Het Resultaat? Ze vonden geen enkele test die aan alle vier de regels voldeed.

Het is een beetje alsof je zoekt naar een crashtest voor een auto die simuleert dat er een botsing plaatsvindt terwijl de bestuurder een berichtje typt, de radio hard staat en de GPS een nieuwe route berekent, terwijl je tegelijkertijd test hoe verschillende bestuurders reageren. Ze vonden tests voor de crash, tests voor het typen en tests voor de GPS. Maar ze vonden nul tests die ze allemaal combineerden om te zien hoe de persoonlijke context de uitkomst verandert.

Waarom Dit Belangrijk Is

Het paper suggereert dat we zonder deze nieuwe tests blind vliegen. We bouwen misschien een AI die perfect lijkt in een lab, maar die in de echte wereld uit elkaar valt omdat zijn "persoonlijke staat" (zijn herinneringen en gewoonten) hem kwetsbaar maakt.

Om dit op te lossen, stellen de auteurs een nieuwe manier voor om tests te ontwerpen. Ze suggereren het creëren van "Gebruikersprofielen" voor de tests. Stel je een test voor waarbij je twee versies van dezelfde AI hebt:

Gebruiker A (De Lichte Gebruiker): Heeft geen speciale herinneringen of vaardigheden. Wanneer de tool verandert, probeert hij het gewoon opnieuw en slaagt hij.
Gebruiker B (De Power User): Heeft een herinnering aan de oude tool, een vaardigheid die hij leerde op basis van de oude tool, en een veiligheidsinstelling die ervan uitgaat dat de oude tool er nog is. Wanneer de tool verandert, kan deze AI in de war raken, proberen de oude tool te gebruiken, falen, en vervolgens per ongeluk een veiligheidsregel overtreden terwijl hij probeert het te herstellen.

Het paper stelt voor om zaken te meten zoals "Adaptatie-latentie" (hoe lang het duurt om te herstellen) en "Regressieratio" (hoeveel oude taken plotseling niet meer werken). Ze hebben zelfs een voorbeeld van een "benchmark card" (een recept voor een test) gemaakt waarbij een rapportage-assistent te maken krijgt met een plotselinge verandering in de manier waarop gegevens worden opgeslagen.

De Kern van het Verhaal

De auteurs beweren niet dat ze de perfecte AI al hebben gebouwd. Ze zeggen zelfs niet dat de huidige AI's kapot zijn. Ze zeggen: "We hebben geen liniaal die dit specifieke type falen kan meten." Ze roepen de gemeenschap op om deze nieuwe, complexere tests te bouwen die rekening houden met het feit dat persoonlijke AI niet alleen een hulpmiddel is; het is een partner met een geheugen, en wanneer de wereld verandert, kan dat geheugen een last worden. Totdat we deze tests bouwen, zullen we niet echt weten of onze persoonlijke AI-agenten klaar zijn voor de echte wereld.

Technische Samenvatting: Naar Gebruikersgeconditioneerde Evaluatie van Persoonlijke LLM-agenten onder Temporele Interventies

1. Probleemformulering

Het artikel identificeert een kritieke kloof in de evaluatie van persoonlijke Large Language Model (LLM) agenten. Terwijl bestaande benchmarks capaciteiten in isolatie evalueren — door het testen van tool-aanroepen onder vaste API's, geheugenopname/vergeten, of statische beleidsnaleving — falen zij om te vatten hoe temporele interventies (bijv. API-schema-updates, aanscherping van beleid, of het intrekken van tools) door een persistente, gebruikersgeconditioneerde staat propageren.

Persoonlijke agenten verschillen van algemene assistenten doordat zij langetermijngeheugens, geleerde vaardigheden, tool-configuraties en beleidsstaten bijhouden die evolueren met specifieke gebruikers. De auteurs stellen dat een unieke foutmodus voor persoonlijke agenten optreedt wanneer een verouderd geheugen of een verouderde geleerde vaardigheid, geconditioneerd op een specifieke gebruikersgeschiedenis, interageert met een nieuwe systeembeperking (de interventie), wat leidt tot cascadefouten in ongerelateerde workflows. Huidige evaluatieprotocollen behandelen de gebruikersstaat als statische input of negeren deze volledig, waarbij ze generieke robuustheid ( $Q(A, e_i)$ ) meten in plaats van gebruikersgeconditioneerde adaptatiekwaliteit ( $Q(A, e_i | u_j)$ ).

2. Methodologie: Het C1–C4 Raamwerk en de Audit

Om de vereisten voor het evalueren van persoonlijke agenten te formaliseren, stellen de auteurs vier noodzakelijke voorwaarden (C1–C4) voor een benchmarkprotocol voor:

C1 (Expliciete Temporele Interventie): De benchmark moet een specifieke, exogene veranderingsgebeurtenis injecteren (bijv. een API-update) die een adaptatiedimensie verstoort.
C2 (Persistente Staat): De agent moet een persistente staat (geheugens, vaardigheden, beleidsregels) meedragen over deze interventie heen.
C3 (Cross-Dimensionale Effecten): Het protocol moet meten hoe de interventie effecten induceert in andere dimensies (bijv. hoe een API-wijziging een geleerde vaardigheid breekt of een veiligheidsbeleid schendt).
C4 (Gebruikersgeconditioneerde Variatie): Het protocol moet de gebruikersgeconditioneerde staat variëren (bijv. "lichte" versus "power" gebruikers met verschillende geaccumuleerde geschiedenissen) om te meten hoe hetzelfde evenement verschillende patronen van foutpropagatie produceert.

De Audit:
De auteurs voerden een gerichte audit uit op 24 unieke benchmarks en systemen, waarbij ze de scope beperkten tot 15 publieke protocollen die LLM-agent taaksuites met reproduceerbare metrieken definiëren. Zij hebben deze protocollen gescreend tegen de C1–C4 criteria.

Coderingregels: Een dimensie wordt als "gedekt" beschouwd als dit een primair evaluatiemodel is. Cross-dimensionale effecten vereisen expliciete perturbatie van één component en de meting van geïnduceerde effecten op een andere.
Betrouwbaarheid: Twee onafhankelijke coders bereikten een gemiddelde overeenkomst van .947 en een Gwet's AC1 van .898 op de C1–C4 labels.

3. Belangrijkste Bijdragen

Het artikel levert drie primaire bijdragen:

Probleemformulering: Het definieert gebruikersgeconditioneerde evaluatie als een afzonderlijk probleem waarbij de persistente gebruikersstaat fungeert als uitvoerbare context, niet enkel als input.
Ontwerdeisen (C1–C4): Het stelt deze vier voorwaarden vast als een falsifieerbare vereiste voor toekomstige benchmarks. De audit laat zien dat geen enkel protocol in de geauditeerde set aan alle vier de voorwaarden tegelijkertijd voldoet. Hoewel sommige protocollen "dichtbij" komen (bijv. ToolSandbox is stateful, MemoryArena is multi-sessie), meet geen enkel protocol de propagatie van een vaste interventie door gevarieerde gebruikersstaten.
Minimaal Benchmarkontwerp & Metrieken: Het artikel stelt een concreet ontwerp voor een minimale benchmark voor en een reeks van vijf kandidaat-metrieken om de adaptatiekwaliteit te rapporteren.

4. Voorgesteld Benchmarkontwerp en Metrieken

De auteurs stellen een minimaal benchmarkontwerp voor dat bestaat uit:

Domein: Tool-rijke omgevingen (bijv. analytische/rapportage-assistenten).
Profielen: Distincte gebruikersstaten (bijv. een "lichte" gebruiker zonder tool-afhankelijke vaardigheden versus een "power" gebruiker met verouderde API-geheugens en geleerde rapportagevaardigheden).
Gebeurtenis: Een vaste interventie (bijv. een API-schema wijziging of aanscherping van beleid) toegepast op alle profielen.
Oracles: Controles voor tool-schema validiteit, beleidsnaleving en het succes van ongerelateerde taken.

Kandidaat-metrieken (Tabel 1):

$\alpha_L$ (Adaptatielatentie): Het aantal relevante interacties dat vereist is voordat er sprake is van een aanhoudend correct gedrag na de verandering.
$\gamma$ (Graceful Degradation / Gratieus Verval): Het deel van de fouten dat onzekerheid erkent, geen ononderbouwde claims maakt en een concrete volgende stap biedt.
$\sigma$ (Veiligheid/Privacy Preservatie): Absolute ratio's en delta's van beleidsnaleving vóór en na de adaptatie.
$\kappa$ (Cross-Dimensionale Coherentie): Stabiliteit van dimensies die niet door de verandering zijn geraakt (bijv. blijven ongerelateerde taken stabiel?).
$\rho$ (Gebruikersgeconditioneerde Regressierate): De snelheid waarmee taken die voorheen voor een specifieke gebruiker werden opgelost, falen na de adaptatie.

5. Resultaten en Bevindingen

De audit leverde een "beperkt negatief resultaat" op: Geen enkel bestaand protocol in de gescreende set voldoet aan de operationalisering van C1–C4.

Veelvoorkomende Patronen: De meeste benchmarks richten zich op de evaluatie van de doelcapaciteit (bijv. "Kan de agent onthouden?" of "Kan hij de tool aanroepen?").
De Kloof: De propagatie van een vaste interventie door de geaccumuleerde staten van verschillende gebruikers (geheugens, vaardigheden, permissies) blijft ongemeten.
Bijna-overeenkomsten: Protocollen zoals ToolSandbox (stateful), MemoryArena (multi-sessie) en WAREX (stress testing) adresseren delen van het probleem, maar falen in het koppelen van een vaste temporele gebeurtenis aan gevarieerde gebruikersgeconditioneerde staten om cross-dimensionale regressie te meten.

6. Betekenis en Claims

Het artikel positioneert zichzelf als een "gerichte gat-analyse" in plaats van een uitgebreide survey. De betekenis ligt in:

Herformulering van Evaluatie: Het beargumenteert dat persoonlijke intelligentie vereist dat adaptatie over meerdere agent-componenten onder gebruikersgeconditioneerde staten wordt geëvalueerd, waarbij men verder gaat dan snapshot-evaluaties.
Definiëren van een Vereiste: Het behandelt C1–C4 als een concrete ontwerdeis voor toekomstige benchmarks, waarbij gesteld wordt dat generieke cross-component robuustheid onvoldoende is zonder gebruikersgeconditioneerde variatie.
Het Bieden van een Blauwdruk: Het biedt een minimaal taakfamilie-ontwerp en specifieke rapportagemetrieken ( $\alpha_L, \gamma, \sigma, \kappa, \rho$ ) om onderzoekers in staat te stellen te testen of dezelfde update verschillende fouten veroorzaakt voor verschillende gebruikers.

De auteurs concluderen dat hoewel een uitputtende enumeratie van alle geheugen-vaardigheid-tool-beleid interacties onhaalbaar is, toekomstige benchmarks profielstaten, event-scripts, afhankelijkheidsannotaties en per-gebruiker regressie-suites moeten bieden om deze gebruikersgeconditioneerde foutmodi te isoleren en te meten.