AI-agenter går sjældent ned. De fejler i det skjulte – og forskning viser hvorfor

Agenter baseret på store sprogmodeller besvarer nu supportsager, søger i databaser og planlægger rejser. Når noget går galt, giver de som regel et selvsikkert svar og en successtatus. En voksende mængde forskning forklarer, hvorfor disse fejl er svære at få øje på, og hvordan ingeniørteams er ved at lære at måle dem.

En fejl, der ligner en succes

Traditionel software fejler som regel tydeligt. En funktion udløser en undtagelse, en server returnerer en fejlkode, og et overvågningsdashboard lyser rødt. En AI-agent opfører sig anderledes. Den arbejder i en løkke: En sprogmodel læser en prompt, beslutter sig for at kalde et værktøj, f.eks. et søge-API eller en database, læser resultatet og beslutter, hvad den skal gøre som det næste. Hvert trin kan gå galt, selv om alle netværksanmodninger i kæden stadig lykkes.

Tag et almindeligt eksempel. Et vejr-værktøj svigter og returnerer teksten »tjenesten er utilgængelig« i et ellers normalt svar. Modellen læser teksten og beklager høfligt, eller endnu værre: Den skriver en plausibel vejrudsigt ud fra sine træningsdata. Brugeren modtager et velformuleret svar. Serverloggene viser en vellykket anmodning med normal svartid. Intet i en konventionel overvågningsløsning registrerer, at noget gik galt.

Udbydere af modeller beskriver det samme problem i deres egen dokumentation. Googles vejledning til Gemini API’et bemærker, at modellen »ikke selv udfører funktionen«. Den foreslår kun et funktionsnavn og argumenter, mens udviklerens applikation udfører kaldet. Applikationen er derfor den eneste del af systemet, der ser det faktiske resultat. Anthropics tekniske vejledning til udvikling af agenter fremhæver en beslægtet pointe: Agenter har brug for »ground truth« fra omgivelserne ved hvert trin, f.eks. resultater fra værktøjer, for at kunne vurdere deres egne fremskridt. Når et værktøj rapporterer en fejl som almindelig tekst, er denne ground truth forkert, og agenten har ingen mulighed for at opdage det.

Det er ikke en ny type problem, men en skærpet udgave af et gammelt. I 2015 beskrev Google-ingeniører under ledelse af D. Sculley »skjult teknisk gæld« i maskinlæringssystemer. De argumenterede for, at størstedelen af risikoen i et ML-system i produktion ligger uden for modellens kode, i dataafhængigheder, konfiguration og integrationskode. Agenter føjer et nyt lag til den liste. Prompter og værktøjsbeskrivelser er konfiguration, der kan ændre et systems adfærd uden nogen ændring i dets kode.

Små ændringer, store konsekvenser

Hvor stor betydning kan en lille ændring af en prompt have? I en artikel fremlagt på ICLR 2024 ændrede Melanie Sclar fra University of Washington og hendes kolleger kun formateringen af few-shot-prompter: separatorer, mellemrum og brug af store og små bogstaver. Betydningen var den samme. Alligevel varierede ydeevnen på den samme opgave med op til 76 nøjagtighedspoint på LLaMA-2-13B. Følsomheden forsvandt ikke med større modeller, flere eksempler eller instruktionstilpasning.

Forfatterne anbefaler, at man rapporterer et interval for ydeevnen på tværs af plausible promptformater i stedet for ét enkelt tal. For ingeniørteams er den praktiske lære enklere: En ændring af en prompt er en kodeændring. Den kræver versionshistorik og skal testes, før den når ud til brugerne.

Det samme gælder værktøjsbeskrivelser, som modellen læser som en del af sin prompt. Anthropics vejledning anbefaler, at værktøjsdefinitioner får »lige så meget opmærksomhed i promptudformningen« som hovedprompten. Den beskriver en kodningsagent, der gentagne gange lavede fejl med relative filstier. Da værktøjet blev ændret, så det krævede absolutte stier, brugte modellen det uden fejl. Modellen ændrede sig ikke. Kun den beskrivelse, den læste, blev ændret.

Én succes siger ikke meget

En anden forskningsretning undersøger konsistens. τ-bench-benchmarket, som Shunyu Yao og kolleger hos Sierra offentliggjorde og fremlagde på ICLR 2025, simulerer kundeservicesamtaler, hvor en agent skal bruge værktøjer og følge forretningsregler. Forfatterne indførte et mål kaldet pass^k: sandsynligheden for, at en agent løser den samme opgave korrekt i alle k forsøg.

Resultaterne var nedslående. En GPT-4o-agent løste omkring 61 % af detailhandelsopgaverne i ét forsøg. Når den skulle løse den samme opgave korrekt otte gange i træk, faldt andelen til omkring 25 %. En demo, der virker én gang, siger ikke meget om, hvordan et system opfører sig ved den tusinde kørsel.

Hvor multiagentsystemer bryder sammen

Mange teams kæder nu flere agenter sammen, hvor én planlægger, en anden udfører opgaven, og en tredje kontrollerer arbejdet. En undersøgelse fra UC Berkeley i 2025, »Hvorfor fejler LLM-systemer med flere agenter?«, analyserede mere end 1.600 annoterede eksekveringsspor på tværs af syv populære frameworks til multiagentsystemer. Forfatterne, anført af Mert Cemri, udarbejdede en taksonomi kaldet MAST med 14 fejltyper fordelt på tre grupper: problemer med systemdesign, manglende overensstemmelse mellem agenter og kontrol af opgaver.

Deres centrale konklusion er, at mange fejl skyldes systemets udformning, ikke kun begrænsningerne i den underliggende model. Agenter ignorerer deres tildelte rolle, mister overblikket over samtalen eller erklærer en opgave for afsluttet uden at kontrollere resultatet. Disse fejl efterlader ingen fejlmeddelelse. De er kun synlige, hvis nogen kan læse, hvad hver agent faktisk gjorde. Unite.AI’s omtale af paradokset ved multiagentsystemer fremhæver en beslægtet pointe om arkitektur: Flere agenter kan forstærke en tidlig fejl i stedet for at udligne den.

Sådan gør man det usynlige synligt

Den tekniske løsning henter inspiration fra distribuerede systemer, hvor man længe har fulgt anmodninger på tværs af mange tjenester ved hjælp af en teknik, der kaldes sporing. Anvendt på agenter bliver hver brugerforespørgsel til et spor, og hvert modelkald eller værktøjskald bliver et »span« i sporet. Et span registrerer dets input, output, de anvendte tokens og tidsforbruget. OpenTelemetry, branchens standardiseringsorgan på området, udarbejder fælles konventioner for spans i generativ AI. I 2026 er disse konventioner stadig markeret som under udvikling, så attributnavnene kan stadig ændre sig.

Flere open source-projekter som Langfuse, Arize Phoenix og AcruxCore anvender allerede denne idé. Deres kildekode er offentlig, så teams kan undersøge, hvordan et spor lagres, og køre softwaren på deres egne servere. Projekterne registrerer modelkald og værktøjskald som spans i ét enkelt spor og giver teams mulighed for at knytte kvalitetsscorer til dem. Valget af værktøj er mindre vigtigt end én detalje: Et værktøjsspan skal registrere, hvad værktøjet faktisk returnerede, ikke kun om netværksanmodningen lykkedes. Ellers forbliver den ovenfor beskrevne fejl i vejrværktøjet usynlig.

Brancheundersøgelser tyder på, at sporing nu er udbredt, men at test halter bagefter. LangChains rapport om status for agentudvikling byggede på en undersøgelse blandt 1.340 fagfolk i slutningen af 2025. Kvalitet var den hyppigst nævnte hindring for at sætte agenter i produktion; det svarede 32 % af deltagerne. 89 % af organisationerne oplyste, at de havde en eller anden form for observabilitet for deres agenter, og 62 % havde detaljeret sporing af individuelle trin og værktøjskald. Kun 52,4 % foretog offline-evalueringer på testsæt, og 37,3 % evaluerede live-trafik. De fleste teams kan se, hvad deres agenter gjorde. Færre undersøger, om det var korrekt.

Vurdering af svar i stor skala

Spor viser, hvad der skete. De fortæller ikke, om svaret var godt. Det kan ikke skaleres at læse hver samtale manuelt, så teams bruger i stigende grad en anden model som bedømmer – en metode, der kaldes LLM-as-a-judge. En artikel fra NeurIPS 2023 af Lianmin Zheng og kolleger viste, at stærke modeller som GPT-4 var enige i menneskers præferencer i mere end 80 % af tilfældene, omtrent samme andel som når mennesker er enige med hinanden.

Den samme artikel beskrev metodens svagheder. Bedømmelsesmodeller foretrækker det svar, de får vist først, foretrækker længere svar og kan favorisere tekst, de selv har skrevet. Bedømmelsesscorer er derfor estimater. De er nyttige, når der skal vurderes mange svar, men de skal kontrolleres mod et lille sæt eksempler mærket af mennesker, hvor svarenes rækkefølge er tilfældig.

Fra praksis til politik

Dette målearbejde er også ved at blive et forventet led i governance. Det amerikanske National Institute of Standards and Technology offentliggjorde sin ramme for risikostyring inden for AI i januar 2023. En af dens fire centrale funktioner, »Måling«, beder organisationer om at kvantificere, følge og dokumentere AI-risici over tid. For en agent er spor og evalueringsscorer den dokumentation, funktionen efterspørger.

Hvad teams kan gøre nu

Det afspejler argumentet, der er blevet fremført på denne platform: pålidelighed er den egentlige prøve på agentisk AI. Forskningen ovenfor føjer de underliggende målinger til argumentet: Pålidelighed er ikke en egenskab, man observerer én gang; den er et spænd, man løbende skal måle.

Forskningen peger på en kort række gode vaner, og de store modeludbydere anbefaler mange af de samme. OpenAIs praktiske vejledning i at bygge agenter anbefaler teams at »opstille evalueringer for at fastlægge et udgangspunkt for ydeevnen«, før de optimerer, og at overlade kontrollen til et menneske, når en agent overskrider et fastsat antal mislykkede forsøg eller står over for en handling med høj risiko. Anthropic anbefaler »omfattende test i sandkassemiljøer«, før agenter handler på egen hånd.

I praksis betyder det nogle få konkrete skridt. Versionsstyr prompts og værktøjsbeskrivelser som kode. Test hver ændring af en prompt mod et fast datasæt, og forvent et interval af resultater frem for ét tal. Kør hver test flere gange, fordi en enkelt gennemgang skjuler inkonsistens. Registrer værktøjsoutput i sporene, så et værktøj ikke kan skjule en fejl bag en successtatus. Betragt automatiserede bedømmelsesscorer som estimater, og kontrollér dem med mennesker.

Ingen af disse vaner kræver et gennembrud i modellernes kapacitet. De kræver, at man behandler en AI-agent som det, den er: et probabilistisk system, der skal måles, fordi det sjældent selv vil gøre opmærksom på sine fejl.