De lovede os agenter, men alt vi fik var statiske kæder

Om foråret 2023 blev verden begejstret over opdukken af LLM-baserede AI-agenter. Kraftfulde demos som AutoGPT og BabyAGI demonstrerede potentialet i LLM’er, der kører i en løkke, vælger den næste handling, observerer resultaterne og vælger den næste handling, ét skridt ad gangen (også kendt som ReACT-rammen). Denne nye metode skulle være i stand til at aktivere agenter, der selvstændigt og generisk udfører multi-skridtsopgaver. Giv dem et mål og et sæt værktøjer, og de vil klare resten. Ved udgangen af 2024 vil landskabet være fuldt af AI-agenter og AI-agent-rammer. Men hvordan måler de op imod løftet?

Det er sikkert at sige, at agenterne, der er drevet af den naive ReACT-ramme, lider under alvorlige begrænsninger. Giv dem en opgave, der kræver mere end få skridt, ved brug af mere end få værktøjer, og de vil mislykkes jammerligt. Ud over deres åbenlyse latency-problemer vil de miste overblikket, ikke følge instruktionerne, stoppe for tidligt eller for sent og producere vildt forskellige resultater ved hver forsøg. Og det er ikke underligt. ReACT-rammen tager LLM’ernes begrænsninger og forstærker dem med antallet af skridt. Men agent-byggere, der søger at løse virkelige brugstilfælde, især i virksomheder, kan ikke klare sig med det niveau af præstation. De har brug for pålidelige, forudsigelige og forklarlige resultater for komplekse multi-skridts-arbejdsgange. Og de har brug for AI-systemer, der mildner, snarere end forværre, LLM’ernes upålidelige natur.

Så hvordan bygges agenter i virksomheder i dag? Til brugstilfælde, der kræver mere end få værktøjer og få skridt (f.eks. konversations-RAG), har agent-byggere i stor udstrækning forladt ReACT-rammens dynamiske og selvstændige løfte for metoder, der stærkt afhænger af statisk kæding – oprettelse af foruddefinerede kæder, der er designet til at løse et bestemt brugstilfælde. Denne tilgang ligner traditionel software-ingeniørarbejde og er langt fra ReACT-rammens agente-løfte. Den opnår højere niveauer af kontrol og pålidelighed, men mangler selvstændighed og fleksibilitet. Løsningerne er derfor udviklingsintensive, snævre i anvendelse og for stive til at tackle høje niveauer af variation i input-rummet og miljøet.

Det er dog sikret, at statisk kæding kan variere i, hvor “statisk” de er. Nogle kæder bruger LLM’er kun til at udføre atomare skridt (f.eks. til at trække information, sammenfatte tekst eller udarbejde en besked), mens andre også bruger LLM’er til at træffe nogle beslutninger dynamisk på køretidspunktet (f.eks. en LLM, der routerer mellem alternative floder i kæden eller en LLM, der validerer resultatet af et skridt for at bestemme, om det skal køres igen). Uanset hvad, så længe LLM’er er ansvarlige for nogen dynamisk beslutningstagning i løsningen – er vi uundgåeligt fanget i en afvejning mellem pålidelighed og selvstændighed. Jo mere en løsning er statisk, jo mere pålidelig og forudsigelig er den, men også mindre selvstændig og derfor mere snæver i anvendelse og mere udviklingsintensiv. Jo mere en løsning er dynamisk og selvstændig, jo mere generisk og enkel er den at bygge, men også mindre pålidelig og forudsigelig.

Denne afvejning kan repræsenteres i følgende grafik:

Dette stiller spørgsmålet, hvorfor vi endnu ikke har set en agente-ramme, der kan placeres i det øverste højre kvadrant? Er vi dømt til at skulle afveje pålidelighed for selvstændighed? Kan vi ikke få en ramme, der giver den enkle grænseflade af en ReACT-agent (tag et mål og et sæt værktøjer og figur det ud) uden at ofre pålidelighed?

Svaret er – vi kan og vi vil! Men for det skal vi erkende, at vi har gjort det hele forkert. Alle nuværende agent-bygge-rammer deler en fælles fejl: de afhænger af LLM’er som den dynamiske, selvstændige komponent. Men det afgørende element, vi mangler – det, vi har brug for for at skabe agenter, der er både selvstændige og pålidelige – er planlægnings-teknologi. Og LLM’er er IKKE gode planlæggere.

Men først, hvad er “planlægning”? Ved “planlægning” mener vi evnen til at udtrykkeligt modelere alternative handlinger, der fører til et ønsket resultat, og til at effektivt udforske og udnytte disse alternativer under budget-begrænsninger. Planlægning skal ske både på makro- og mikro-niveau. En makro-plan bryder en opgave ned i afhængige og uafhængige skridt, der skal udføres for at opnå det ønskede resultat. Det, der ofte overses, er behovet for mikro-planlægning, der sikrer ønskede resultater på skridt-niveau. Der er mange tilgængelige strategier for at øge pålideligheden og opnå garantier på skridt-niveau ved at bruge mere beregningsressourcer på køretidspunktet. F.eks. kunne du omskrive semantiske søgeforespørgsler flere gange, du kan hente mere kontekst per given forespørgsel, kan bruge en større model og kan få flere slutninger fra en LLM – alt sammen resulterer i flere krav-tilfredstillende resultater, som du kan vælge det bedste ud af. En god mikro-planlægger kan effektivt bruge beregningsressourcer på køretidspunktet til at opnå de bedste resultater under en given beregnings- og ventetidsbudget. På den måde kan planfulde AI-systemer mildne den probabilistiske natur af LLM’er og opnå garantier på skridt-niveau. Uden sådanne garantier er vi tilbage til det kompounderings-fejl-problem, der vil undergrave selv den bedste makro-niveau-plan.

Men hvorfor kan LLM’er ikke fungere som planlæggere? De er jo i stand til at oversætte højt-niveau-instruktioner til rimelige kæder af tanker eller planer defineret i naturlig sprog eller kode. Årsagen er, at planlægning kræver mere end det. Planlægning kræver evnen til at modelere alternative handlinger, der kan føre til det ønskede resultat, OG til at resonere om den forventede nytte og forventede omkostninger (i beregnings- og/eller ventetid) af hver alternativ. Mens LLM’er potentielt kan generere repræsentationer af tilgængelige handlinger, kan de ikke forudsige deres korresponderende forventede nytte og omkostninger. F.eks. hvad er den forventede nytte og omkostning ved at bruge model X vs. model Y til at generere et svar per en bestemt kontekst? Hvad er den forventede nytte af at lede efter en bestemt stykke information i den indekserede dokument-samling vs. en API-kald til CRM? Din LLM har ikke en anelse. Og med god grund – historiske spor af disse probabilistiske egenskaber er sjældent fundet i naturen og er ikke inkluderet i LLM-træningsdata. De tenderer også til at være specifikke for det bestemte værktøj og data-miljø, hvori AI-systemet vil operere, i modsætning til den generelle viden, som LLM’er kan tilegne sig. Og selv hvis LLM’er kunne forudsige forventede nytte og omkostninger, ville resonering om dem til at vælge den mest effektive handling være en logisk beslutningsteoretisk deduktion, som ikke kan antages at blive pålideligt udført af LLM’ernes næste token-forudsigelser.

Så hvad er de manglende ingredienser for AI-planlægnings-teknologi? Vi har brug for planlægnings-modeller, der kan lære fra erfaring og simulation for at udtrykkeligt modelere alternative handlinger og korresponderende nytte- og omkostnings-sandsynligheder per en bestemt opgave i et bestemt værktøj og data-miljø. Vi har brug for en Plan Definition Language (PDL), der kan bruges til at repræsentere og resonere om nævnte handlinger og sandsynligheder. Vi har brug for en eksekverings-motor, der kan deterministisk og effektivt eksekvere en given plan defineret i PDL.

Nogle mennesker er allerede hårdt arbejdende for at levere på dette løfte. Indtil da, fortsæt med at bygge statiske kæder. Bare lad være med at kalde dem “agenter”.