Forklarbarhed i multi-agent-systemer: test

Forsyningskæden er et godt testlokale, fordi spørgsmålene krydser flere fagområder. Hvor er en forsendelse, hvilke lagre kan dække en mangel, og hvad koster en omlægning af ruten? Ingen enkelt agent bør svare på det hele. Her giver det mening at dele arbejdet mellem specialiserede agenter, der hver har deres værktøjer og deres ansvar.

Problemet opstår, når svaret lyder rigtigt, men er bygget på det forkerte grundlag. En agent kan have slået op i et lagersystem, hvor den skulle have spurgt transportdata, og stadig formulere sig overbevisende. Hvis du kun vurderer den endelige tekst, opdager du det først, når en beslutning er truffet på et skævt grundlag.

Derfor er spørgsmålet om forklarbarhed praktisk og ikke akademisk. En agent, der kan redegøre for sine valg, giver dig noget at efterprøve. En agent, der ikke kan, tvinger dig til at stole på tonen i svaret. Jeg stoler ikke på tonen. Jeg vil se sporet.

Strands Agents er et open source-framework til at bygge agenter, hvor en model får et sæt værktøjer og selv afgør, hvornår de skal bruges. I multi-agent-opsætningen fungerer en koordinerende agent som indgang. Den modtager brugerens spørgsmål, vurderer hvilken specialist der skal på sagen, og samler til sidst svarene.

Den arbejdsdeling har en konsekvens for testen. Hver beslutning efterlader et spor. Hvilken agent blev kaldt, hvilket værktøj brugte den, og hvad kom tilbage? Når sporene bliver gemt, kan de bruges som råmateriale til evaluering bagefter. Uden spor har du kun et spørgsmål og et svar og intet mellemled at vurdere.

Det er en vigtig pointe for alle, der planlægger agentløsninger. Observerbarhed er ikke et tilvalg, du kan tilføje til sidst. Den skal være tænkt ind fra første prototype, ellers har evalueringen ingenting at arbejde på. Kan jeg ikke se, hvad agenten gjorde, har jeg ikke en medarbejder. Jeg har en risiko.

Mønstret arbejder med tre niveauer, som supplerer hinanden.

Det første er de indbyggede evaluatorer i AgentCore Evaluations. De dækker de generelle kvalitetsspørgsmål, som gælder for næsten alle agenter, for eksempel om svaret er brugbart, og om agenten fulgte instruktionen. De er hurtige at tage i brug og giver et første billede af niveauet.

Det andet lag er brugerdefinerede evaluatorer. Her indkoder du de krav, der er specifikke for din virksomhed. I en forsyningskæde kan det være, at en leveringsdato altid skal bygge på transportdata, eller at en agent aldrig må love en kapacitet, den ikke har slået op. Generiske mål kan ikke fange den slags, fordi de ikke kender dine regler. Det er her grænsen for, hvad agenten må røre, bliver til noget, man kan teste.

Det tredje lag er forklarbarhed. Her bliver agentens egen begrundelse til noget, der kan vurderes. Giver forklaringen mening i forhold til det, der faktisk skete, og peger den på de rigtige værktøjer? Det er her, evalueringen går fra at spørge, om svaret er godt, til at spørge, om vejen til svaret er forsvarlig.

Alle tre lag er nødvendige. Indbyggede mål alene er for brede, brugerdefinerede regler alene er for snævre, og forklarbarhed uden de to andre siger kun noget om fortællingen, ikke om kvaliteten.

Værdien viser sig tydeligst i to situationer.

Den første er værktøjsvalg. Når en agent har adgang til mange værktøjer, kan to af dem ligne hinanden nok til at blive forvekslet. En forklarbarhedsevaluator sammenligner agentens begrundelse med de værktøjer, der blev kaldt, og markerer de tilfælde, hvor de ikke passer sammen. Du får altså et konkret sted at kigge, i stedet for en generel fornemmelse af, at noget er skævt.

Den anden er begrænsninger. En god agent skal kunne sige, hvad den ikke ved, eller hvad den ikke har adgang til. Hvis en agent forklarer sit svar, som om den havde fuld indsigt, men i virkeligheden manglede et datasæt, er det en fejl, som en ren korrekthedstest ofte overser. Forklarbarhed gør den synlig, fordi begrundelsen og den faktiske dataadgang ikke stemmer overens.

Det gælder også i modsat retning. Hvis evalueringen viser, at agenten systematisk vælger det rigtige værktøj, men forklarer det dårligt, ved du, at problemet ligger i instruktionerne til forklaringen og ikke i selve ræsonnementet. Det er en billigere rettelse end at bygge arkitekturen om.

En demo beviser, at en agent kan. Drift beviser, at den gør det igen, uden at nogen ser med, og på det dårlige input. Mønstret her peger på en rækkefølge, der fører dig fra det første til det andet, uanset hvilken branche du arbejder i.

Start med at afgøre, hvilke beslutninger agenten må træffe selv, og hvilke der kræver menneskelig kontrol. Evalueringen skal måle noget, der betyder noget, og grænsen er det svære ved agentarbejde, ikke selve prompten. Gem derefter sporene fra første dag. Hvert agentkald, værktøjsvalg og returværdi er data, du får brug for, og du kan ikke genskabe dem bagefter.

Brug først de indbyggede evaluatorer til at finde de grove fejl, og tilføj så brugerdefinerede evaluatorer for jeres egne regler. Læg forklarbarhed på som sidste lag, og læs et udvalg af afvigelserne manuelt. En automatisk vurdering er et filter, ikke en dommer. Gentag testen, hver gang du ændrer en prompt, et værktøj eller en model, for forklarbarhed er ikke en engangsgodkendelse.

En pragmatisk grænse er værd at huske. Evaluatorer, der selv bygger på en sprogmodel, kan tage fejl. Behandl deres resultater som en indikator, og lad stikprøver fra mennesker afgøre de uklare tilfælde. Jeg har ikke et rent tal for, hvor ofte det sker, og jeg vil ikke gætte på et.

Gevinsten er en agent, hvis opførsel du kan forsvare over for kolleger, kunder og revisorer. Det er den forskel, der afgør, om en multi-agent-løsning forbliver en demo, eller om den får lov til at træffe beslutninger i en rigtig forsyningskæde.