Google Cloud AI-forskere har sammen med forskere fra University of Illinois Urbana-Champaign og Yale University præsenteret ReasoningBank, et memory-framework til AI-agenter. Ideen er ret enkel at forstå, selv om den tekniske indpakning er tung nok: Systemet skal ikke nøjes med at gemme, hvad en agent gjorde, men forsøge at udlede hvorfor en tilgang virkede eller gik galt og gemme det som noget, der kan bruges igen.
Det rammer et ret konkret problem i agentbølgen. Mange agenter møder stadig nye opgaver som om alt er jomfrueligt land. De har været der før, de har lavet samme fejl før, og alligevel starter de næsten forfra. Det er den slags, der gør dem ustabile og i praksis dyre at have kørende.
Et memory-problem
ReasoningBank bliver præsenteret ind i det, forskerne kalder et amnesi-problem. En agent kan browse, løse GitHub-opgaver eller finde rundt i en shoppingplatform, men erfaringerne fra sidste opgave hænger ikke nødvendigvis ved på en måde, der hjælper på den næste. Den udfører, afslutter, glemmer.
For os er det interessante, at historien dermed lander som arkitektur mere end modelhype. Hvis en agent føles inkonsekvent, er forklaringen ikke altid, at modellen er svag. Ofte ligger fejlen i hukommelsen omkring den, eller i mangel på samme. Det lyder måske tørt. Det er det også lidt. Men det er også dér, mange driftsproblemer gemmer sig.
Det er også derfor forskningsideen er mere relevant end overskriften måske først antyder. Ikke fordi alt er bevist i praksis på tværs af alle agentsystemer, men fordi den peger direkte på et sted, hvor mange bygger forkert eller for let. Man gemmer logs og håber, at det ligner læring.
To tilgange som ikke helt slår til
Forskerne sætter ReasoningBank op mod to kendte memory-greb. Den ene er trajectory memory, altså rå handlingslogs. Klik, scroll, søgninger, trin for trin. Problemet er ret jordnært: Den slags bliver hurtigt langt, rodet og svært at genbruge i en ny opgave.
Den anden er workflow memory, hvor systemet udtrækker genbrugelige procedurer fra succesfulde forløb. Det er i sig selv mere nyttigt end en ren logbog. Men det har en ret åbenlys svaghed: Hvis man kun lærer af det, der gik godt, smider man en stor del af virkeligheden væk. Agenter fejler jo ikke ligefrem sjældent.
Og her er ReasoningBank faktisk et lille brud. Ikke et dramatisk et, men et reelt et. Hukommelsen skal samle strategier op fra både succeser og fiaskoer, så agenten ikke kun får en pæn best practice-mappe, men også et katalog over faldgruber.
Fra spor til strategi
Kernen i ReasoningBank er skiftet fra handlinger til begrundelser. I stedet for at gemme en fortid som en lang liste af trin, prøver frameworket at destillere mere generelle strategier ud af forløbet. Altså ikke bare at agenten klikkede tre steder og skrev en søgning, men hvorfor den tilgang gav mening, eller hvorfor den viste sig at være forkert.
Det lyder måske som en sproglig finesse, men det er ret vigtigt. En rå log hjælper kun, hvis næste opgave ligner den forrige næsten én til én. En strategi eller en advarsel kan derimod være brugbar på tværs af beslægtede opgaver. Det er i hvert fald ambitionen her.
Den del med fejlene er nok den mest interessante. Succeser giver validerede strategier. Fejl giver noget andet: mod-eksempler, faldgruber, forebyggende læring. Og hvis man har set bare få agentforløb i praksis, ved man godt hvad der fylder mest.
En lukket sløjfe omkring hver opgave
Frameworket beskrives som en lukket memory-proces med tre trin: memory retrieval, memory extraction og memory consolidation. Det kører omkring hver afsluttet opgave. Før agenten går i gang med noget nyt, henter den relevante memory-items fra banken. Når opgaven er færdig, bliver ny læring udtrukket og lagt tilbage.
Retrieval-delen er forholdsvis konkret beskrevet. Agenten bruger embedding-baseret lighedssøgning til at hente de mest relevante memory-items og lægger dem ind i systemprompten som ekstra kontekst. Med andre ord: før opgaven starter, får agenten et lille stikordskort med sig fra tidligere erfaringer.
Derefter kommer extraction og consolidation. Her bliver den afsluttede opgave analyseret, og ny læring føjes til banken. Materialet beskriver de tre trin klart, men går vi længere ned i de mere detaljerede metodevalg, bliver grundlaget tyndere. Så det lader vi ligge.
Mere hukommelse var ikke bedre
Den mest håndfaste detalje i omtalen handler om retrieval. Standardopsætningen er k=1. Agenten henter altså ét memory-item per opgave som udgangspunkt. Det kan næsten lyde for beskedent, men tallet er interessant netop fordi resten af AI-verdenen ofte har en svaghed for at hælde mere kontekst oveni og kalde det fremskridt.
I den beskrevne opsætning gav mere retrieval dårligere resultater. Succesraten faldt fra 49,7 procent ved k=1 til 44,4 procent ved k=4. Det er ikke bevis for, at ét memory-item altid er bedst, men det er et ret godt vink med en vognstang om, at mere historik også kan blive til støj.
Praktisk er den pointe større end den ser ud. Hvis man bygger agentsystemer til support, intern hjælp eller browseropgaver, er det ikke nok bare at have hukommelse. Man skal have selektiv hukommelse. Ellers ender man med at overfylde prompten og gøre agenten mere forvirret, ikke klogere.
Det betyder noget i drift
Det er også her historien bliver relevant uden at blive højtravende. En agent, der ikke lærer af tidligere fejl, bruger flere modelkald, flere værktøjstrin og efterlader mere oprydning til mennesker. Regningen ligger sjældent i én spektakulær fejl. Den ligger i gentagelserne. I de små omveje. I de samme dumme forsøg igen og igen.
Så når leverandører lover mere autonome agenter, er det værd at kigge mindre på selve løftet og mere på læringssløjfen rundt om agenten. ReasoningBank peger på, at det svære måske ikke er at få agenten til at handle, men at få den til at lære på en måde, der faktisk holder fra opgave til opgave.
Det gør ikke frameworket til et færdigt svar på alt. Vi har her en forskningsomtale og ikke et fuldt produktløfte. Men som arkitektur-idé er det mere interessant end mange modelnyheder, netop fordi det handler om den del af agentarbejdet, som først bliver synlig, når systemet skal leve i drift og ikke bare imponere i en demo.
Det nøgterne take
Der er nok til at tage historien alvorligt, og ikke nok til at overdrive den. Det understøttede er ret klart: hvem der står bag ReasoningBank, hvad frameworket prøver at gemme, hvordan det adskiller sig fra trajectory memory og workflow memory, og at retrieval-delen i den beskrevne opsætning faktisk så ud til at fungere bedre med ét memory-item end med fire.
Det er egentlig også nok. Hvis en agent i dag føles inkonsekvent, er det ikke sikkert, at løsningen er en ny model. Det kan lige så godt være, at systemet omkring den mangler hukommelse, disciplin og en måde at lære af sine egne fejl på. Man opdager først forskellen, når agenten møder sin tredje eller tiende lignende opgave.
