De lovet oss agenter, men alt vi fikk var statiske kjeder

Om våren 2023 ble verden spennende over oppblomstringen av LLM-baserte AI-agenter. Kraftfulle demonstrasjoner som AutoGPT og BabyAGI viste potensialet til LLM-er som kjører i en løkke, velger neste handling, observerer resultater og velger neste handling, ett steg om gangen (også kjent som ReACT-rammeverket). Denne nye metoden skulle gi kraft til agenter som selvstendig og generisk utfører multi-stegsoppgaver. Gi dem et mål og et sett med verktøy, og de vil ta seg av resten. Ved slutten av 2024 vil landskapet være fullt av AI-agenter og AI-agensbyggingrammeverk. Men hvordan måler de seg opp mot løftet?

Det er trygt å si at agentene som er drevet av det naive ReACT-rammeverket lider under alvorlige begrensninger. Gi dem en oppgave som krever mer enn noen få steg, ved hjelp av mer enn noen få verktøy, og de vil mislykkes jammerlig. Forbi deres åpenbare latentproblemer, vil de miste sporet, ikke følge instruksjoner, stoppe for tidlig eller for sent, og produsere veldig forskjellige resultater hver gang. Og det er ingen under. ReACT-rammeverket tar begrensningene til uforutsigbare LLM-er og kompenserer dem med antall steg. Likevel, agentbyggere som søker å løse virkelige bruksområder, spesielt i bedriftsverdenen, kan ikke nøye seg med den type ytelse. De trenger pålitelige, forutsigbare og forklarbare resultater for komplekse multi-stegs arbeidsflyter. Og de trenger AI-systemer som mildner, snarere enn å forverre, den uforutsigbare naturen til LLM-er.

Så hvordan bygges agenter i bedriftsverdenen i dag? For bruksområder som krever mer enn noen få verktøy og noen steg (f.eks. konversasjonell RAG), har agentbyggere i stor grad forlatt den dynamiske og selvstendige løftet til ReACT for metoder som sterkt avhenger av statisk kjedning – opprettelse av forhåndsdefinerte kjeder designet for å løse et bestemt bruksområde. Denne tilnærmingen ligner tradisjonell programvareutvikling og er langt ifra den agensløftet til ReACT. Den oppnår høyere nivåer av kontroll og pålitelighet, men mangler selvstendighet og fleksibilitet. Løsningene er derfor utviklingsintensive, smale i anvendelse og for stive til å håndtere høye nivåer av variasjon i inndatarommet og miljøet.

For å være sikker, kan statisk kjedning praksis variere i hvor “statiske” de er. Noen kjeder bruker LLM-er bare for å utføre atomiske steg (for eksempel for å trekke ut informasjon, sammenfatte tekst eller utkaste en melding), mens andre også bruker LLM-er for å ta noen beslutninger dynamisk på kjøretid (for eksempel en LLM som ruter mellom alternative flyter i kjeden eller en LLM som validerer resultatet av et steg for å bestemme om det skal kjøres igjen). Uansett, så lenge LLM-er er ansvarlige for noen dynamiske beslutninger i løsningen – er vi uunngåelig fanget i en avveining mellom pålitelighet og selvstendighet. Jo mer en løsning er statisk, er mer pålitelig og forutsigbar, men også mindre selvstendig og derfor mer smal i anvendelse og mer utviklingsintensiv. Jo mer en løsning er dynamisk og selvstendig, er mer generisk og enkel å bygge, men også mindre pålitelig og forutsigbar.

Denne avveiningen kan representeres i følgende grafikk:

Dette stiller spørsmålet, hvorfor har vi ennå ikke sett et agensrammeverk som kan plasseres i øverste høyre kvadrant? Er vi dømt til å evig trade off pålitelighet for selvstendighet? Kan vi ikke få et rammeverk som gir den enkle grensesnittet til en ReACT-agent (ta et mål og et sett med verktøy og finn ut) uten å ofre pålitelighet?

Svaret er – vi kan og vi vil! Men for det, må vi innse at vi har gjort det feil hele tiden. Alle nåværende agentbyggingrammeverk deler en felles feil: de avhenger av LLM-er som den dynamiske, selvstendige komponenten. Likevel, den kritiske komponenten vi mangler—det vi trenger for å skape agenter som er både selvstendige og pålitelige—er planleggingsteknologi. Og LLM-er er IKKE gode planleggere.

Men først, hva er “planlegging”? Med “planlegging” mener vi evnen til å eksplisitt modellere alternative handlingsplaner som fører til et ønsket resultat og til å effektivt utforske og utnytte disse alternativene under budsjettbegrensninger. Planlegging bør gjøres på både makro- og mikronivå. En makro-plan bryter ned en oppgave i avhengige og uavhengige steg som må utføres for å oppnå det ønskede resultatet. Det som ofte oversees er behovet for mikro-planlegging rettet mot å garantere ønskede resultater på stegnivå. Det finnes mange tilgjengelige strategier for å øke pålitelighet og oppnå garantier på enkeltstegnivå ved å bruke mer inferens-tid beregning. For eksempel, kunne du parafrasere semantiske søkeforespørsler flere ganger, du kan hente mer kontekst per gitt forespørsel, kan bruke en større modell, og du kan få flere inferenser fra en LLM – alt resulterer i flere krav-tilfredsstillende resultater å velge det beste fra. En god mikro-planlegger kan effektivt bruke inferens-tid beregning til å oppnå de beste resultater under en gitt beregnings- og latent-budsjet. På den måten kan planmessige AI-systemer mildne den probabilistiske naturen til LLM-er og oppnå garanterte resultater på stegnivå. Uten slike garantier, er vi tilbake til feil-akkumuleringsproblemet som vil undergrave selv de beste makro-nivå planer.

Men hvorfor kan LLM-er ikke fungere som planleggere? Etter all, er de i stand til å oversette høynivå-instruksjoner til rimelige kjeder av tanker eller planer definert i naturlig språk eller kode. Grunnen er at planlegging krever mer enn det. Planlegging krever evnen til å modellere alternative handlingsplaner som kan rimelig fører til det ønskede resultatet OG til å resonnere om den forventede nytten og forventede kostnadene (i beregning og/eller latent) av hver alternativ. Mens LLM-er potensielt kan generere representasjoner av tilgjengelige handlingsplaner, kan de ikke forutsi deres korresponderende forventede nytte og kostnader. For eksempel, hva er den forventede nytten og kostnadene av å bruke modell X vs. modell Y for å generere et svar per en bestemt kontekst? Hva er den forventede nytten av å lete etter en bestemt informasjon i den indekserte dokumentkorpus vs. en API-kall til CRM? Din LLM har ikke en anelse. Og for god grund – historiske spor av disse probabilistiske egenskapene er sjelden funnet i villmarken og er ikke inkludert i LLM-treningdata. De tenderer også til å være spesifikke for det bestemte verktøyet og data-miljøet som AI-systemet vil operere i, i motsetning til den generelle kunnskapen som LLM-er kan tilegne seg. Og selv om LLM-er kunne forutsi forventede nytte og kostnader, er resonnement om dem for å velge den mest effektive handlingsplanen en logisk avgjørelsesteoretisk deduksjon, som ikke kan antas å bli pålitelig utført av LLM-ers neste token-forutsigelser.

Så hva er de manglende ingrediensene for AI-planleggingsteknologi? Vi trenger planleggingsmodeller som kan lære fra erfaring og simulering for å eksplisitt modellere alternative handlingsplaner og korresponderende nytte- og kostnadsprobasjoner per en bestemt oppgave i et bestemt verktøy- og data-miljø. Vi trenger et Plan-Definisjons-Språk (PDL) som kan brukes til å representere og resonnere om disse handlingsplanene og probasjoner. Vi trenger en eksekveringsmotor som kan deterministisk og effektivt eksekvere en gitt plan definert i PDL.

Noen mennesker er allerede hardt arbeidende med å levere på dette løftet. Inntil da, fortsett å bygge statiske kjeder. Bare vennligst ikke kall dem “agenter”.