Nesten alle forsøk er bortkastet

Når en AI-agent mislykkes med en oppgave og prøver på nytt, skulle man anta at gjentakelsene gradvis bringer den nærmere målet. Men ifølge en analyse publisert av Towards Data Science er virkeligheten en helt annen: I et kontrollert benchmark bestående av 200 oppgaver ble hele 90,8 prosent av alle retry-forsøk brukt på feiltyper som per definisjon aldri kan lykkes.

Årsaken er ikke at de underliggende språkmodellene er for svake. Problemet er arkitektonisk — og det betyr at mer trening eller bedre prompter ikke løser det.

Hva er ReAct-agenter?

ReAct (Reasoning and Acting) er et av de mest brukte paradigmene for AI-agenter i dag. Systemet lar en språkmodell veksle mellom resonering og faktiske handlinger i en iterativ løkke kalt Thought-Action-Observation (TAO). Dette gjør agentene fleksible og i stand til å håndtere komplekse, sammensatte oppgaver.

Men fleksibiliteten har en pris.

9 av 10 retry-forsøk i AI-agenter er bortkastet — her er løsningen

Hallusinerte verktøykall er kjerneproblemet

Det som gjør retry-problemet særlig alvorlig, er at feilene ikke er tilfeldige. Analysen viser at størsteparten av mislykkede forsøk skyldes at agenten kaller på verktøy som ikke eksisterer, eller bruker dem på måter som er strukturelt umulige. Disse hallusinerte verktøykallene kan gjentas i det uendelige uten at agenten noen gang lykkes — og de tapper systemets retry-budsjett uten å gi noen verdi.

Prompt-tuning, som er den mest utbredte tilnærmingen for å forbedre agentadferd, har ingen effekt på denne typen feil fordi problemet ligger i selve agentarkitekturen.

Å finjustere prompter på et strukturelt brutt system er som å justere navigasjonen på et skip med hull i skroget.
9 av 10 retry-forsøk i AI-agenter er bortkastet — her er løsningen

Tre strukturelle endringer som hjelper

Ifølge Towards Data Science finnes det tre typer arkitekturendringer som i praksis kan eliminere bortkastede retries. Disse støttes av bredere forskning på alternative agentdesign.

1. Refleksjon før handling

Varianten kalt REBACT legger inn et refleksjonssteg før hver handlingsfase, ikke etter. Dette gir agenten mulighet til å korrigere kurs umiddelbart i stedet for å oppdage feilen i etterkant. Resultater fra benchmark-testen ALFWorld viser en suksessrate på 98,51 prosent — en økning på 24 prosentpoeng over basismodellen — og en tilsvarende nedgang i kumulative feil og API-kall.

2. Fokusert kontekst og tidlig stopp

«Focused ReAct» adresserer et fenomen kalt kontekstdrift, der agenten gradvis mister av syne hva den opprinnelig ble bedt om å gjøre. Løsningen er enkel: gjenta den originale oppgaven ved hvert resonneringssteg, og stopp tidlig dersom en handling gjentar seg. Ifølge forskningen øker dette nøyaktigheten med opptil 530 prosent på Gemma 2B-modellen og reduserer kjøretiden med opptil 34 prosent.

3. FlerAgent-arkitektur med hierarkisk planlegging

Systemet CoAct bruker en global planlegger til å styre lokale utførende agenter. Sammenlignet med en standard ReAct-basert agent på GPT-3.5 økte gjennomsnittlig suksessrate på komplekse oppgaver fra 9,4 til 13,8 prosent — en forbedring på rundt 47 prosent. Enda mer drastiske resultater rapporteres fra GLM-arkitekturen, som kombinerer flerAgent-struktur med grafbasert resonnering.

90,8 %
Bortkastede retries i benchmark
530 %
Nøyaktighetsøkning med Focused ReAct

Hva betyr dette for praksis?

For team som bygger og drifter produksjonssystemer basert på ReAct-agenter, er budskapet fra analysen tydelig: Effektiviseringsarbeidet bør rettes mot selve agentstrukturen, ikke mot prompt-design eller modellvalg. Det er lite å hente på å forbedre resonnementet til en agent som systematisk prøver å utføre umulige operasjoner.

Forskningsmiljøene peker mot en fremtid der agentarkitektur, ikke bare modellstørrelse, blir den avgjørende faktoren for ytelse og kostnadseffektivitet i AI-systemer. GLM-arkitekturen illustrerer potensialet: 95,7 prosent reduksjon i tokenkostnader og 90,3 prosent lavere inferenslatens sammenlignet med sammenlignbare systemer, ifølge forskningsgrunnlaget som er lagt til grunn for denne artikkelen.

Kilden presiserer at tallene stammer fra kontrollerte benchmarks, og at overføringsverdien til produksjonsmiljøer vil variere avhengig av oppgavetype og systemkonfigurasjon.