Det är viktigt att noggrant överväga hur och var beslut fattas i ditt agentbaserade system.
Om fler beslut överlåts åt en LLM kan systemet potentiellt generalisera till fler uppgifter, men det kan ske på bekostnad av snabbhet, tillförlitlighet och robusthet.
Försök när det är möjligt att flytta så mycket som möjligt av beslutsprocessen från LLM:en till explicit programkod. Detta gäller särskilt arbetsflöden med hög risk och/eller i produktion.
När du utformar ett LLM-baserat agentsystem är ett av de viktigaste valen hur stor del av beslutsfattandet som ska inrymmas i en LLM-Modell respektive i explicit programvara.
För att göra valet lättare att förstå kan vi se det som ett spektrum mellan följande tillvägagångssätt:
Routerbaserade arkitekturer definierar uttryckligen ordningsföljd och logik i kod, vilket ger testbarhet, förutsägbarhet och robusthet för uppgifter inom ett avgränsat område (de kallas även ”arbetsflödesagenter”).
Orkestrerande agenter använder stora språkmodeller (LLM:er) för att dynamiskt bestämma uppgiftsflöden utifrån promptar på naturligt språk. De lämpar sig för öppna interaktioner där fördefinierad logik är otillräcklig eller omöjlig.
För produktionsflöden med hög risk rekommenderar vi vanligtvis fler routerbaserade funktioner och reserverar orkestrerare för tillämpningar som kräver flexibla samtal för allmänna ändamål.
Routerbaserade arkitekturer
Routerbaserade agentsystem:
Definierar beslutsflödet uttryckligen genom kod eller programvara och använder en LLM för att avgöra vilken väg programvaran ska ta.
Liknar traditionella programsystem genom att ha tydliga och förutsägbara vägar som ger mer konsekventa resultat.
Passar utmärkt för uppgifter som kan definieras strikt.
Nedan visas ett förenklat exempel på en bokningsagent för en flygbolagschattbot som använder ”routermetoden”. LLM:en hjälper oss att klassificera frågans avsikt utifrån tre möjliga alternativ, men det är i slutänden programvaran som kopplar avsikten till ett textbaserat standardsvar. Eftersom LLM:en är starkt begränsad får användaren ett mer konsekvent beteende.
Orkestrerande arkitekturer
Till skillnad från routersystem har orkestrerande agentsystem följande egenskaper:
De definierar logiska flöden med promptar på naturligt språk i stället för programvara. Obs! Jämfört med ett programmeringsspråk är naturligt språk i sig tvetydigt och flexibelt, vilket är både positivt och negativt, som vi diskuterar senare. Vi beskriver detta som ”avsikt snarare än instruktion”.
De kan erbjuda flera bearbetningsalternativ, där LLM:en bestämmer körordning och metod.
De kan dynamiskt skapa nya logiska vägar som är svåra att uttryckligen definiera i programvara.
Tvetydigheten kan leda till inkonsekventa resultat, men när det fungerar kan det kännas ”magiskt”.
I följande exempel tillämpas en orkestrerande metod på samma förenklade flygbolagsproblem. I stället för att låta programvaran avgöra vilket svar som är lämpligt överlåts beslutsfattandet åt LLM-skiktet. Här har vi ett system med flera agenter, där en överordnad orkestrerande Agent prioriterar användarens fråga och lämnar över den till en Agent som är särskilt utformad för flygändringar och som slutligen svarar användaren.
I det här exemplet fungerar LLM-skiktet som klassificerare, router och svarsskrivare. I routerexemplet fungerade det bara som klassificerare, medan programvaran skötte resten.
När det är möjligt rekommenderar vi routerbaserade lösningar eftersom de har följande fördelar:
Snabbhet och effektivitet: Lokala beräkningar är snabbare än orkestrerare som är beroende av externa API:er. Det är dessutom mycket billigare att bearbeta ”IF/ELSE”-logik i Python än att betala en LLM-leverantör för att köra den genom sin Modell med 400 miljarder parametrar.
Testbarhet och förutsägbarhet: Etablerade metoder för programvaruutveckling gör det betydligt enklare att felsöka, testa och underhålla.
Transparens och tillförlitlighet: Mindre variation i beteendet förenklar felsökningen. En större del av tillämpningens flöde uttrycks dessutom i transparent, versionshanterad programvara, i stället för i en LLM:s ogenomskinliga och svårtolkade vikter.
Nackdelarna med routerbaserade metoder är att de kan vara rigida och oflexibla samt ha svårt att hantera mer öppna problem. En chattbot som alltid ger exakt samma svar kan uppfattas som tråkig eller stillastående av användarna.
Orkestrerande lösningar har kraftfulla funktioner:
Planering: De kan planera svar dynamiskt.
Val av verktyg/överlämning till Agent: Väljer lämpliga verktyg eller delegerar uppgifter till agenter.
Iterativ kombination av resultat: Upprepar och kombinerar resultat på nytt och kreativt.
Fastställande av slutförande: Avgör när tillräckligt med information har samlats in för att färdigställa ett svar.
Ramverk som Pydantic-AI eller OpenAI:s Agents SDK gör orkestrering enkel och snabb att implementera. Det gör metoden utmärkt för demonstrationer och koncepttest.
Nackdelarna med den här metoden är följande:
Det finns inga garantier för att LLM:ens planeringssteg och efterföljande åtgärder är korrekta eller lämpliga. Routersystemet har samma problem, men eftersom det är mer begränsat är beteendet mer förutsägbart.
För enkla, väldefinierade uppgifter behöver vi sannolikt inte den fulla kapaciteten hos ett system med flera agenter. I vårt exempel med en flygbolagsagent finns det förmodligen bara ett begränsat antal typer av ärenden som någon faktiskt vill utföra i ett flygbolags supportsystem.
Eftersom mer logik finns i LLM:en är den betydligt mer sårbar för jailbreak och utnyttjande av illvilliga aktörer.
Beslutsfattandet abstraheras in i LLM:en, vilket gör systemet svårare att förstå, även om övervakningsverktyg som Langfuse eller Braintrust kan vara till viss hjälp.
Anmärkning till läsaren: även om Modellernas kapacitet förändras snabbt är det osannolikt att nedanstående ändras inom den närmaste framtiden.
Fastställ problemets omfattning.
Kan du enkelt beskriva den önskade beslutslogiken i ett diagram?
Är fel eller oväntat beteende oacceptabelt i din tillämpning?
Ett ”ja” på någon av frågorna ovan tyder på att routerfunktioner passar bättre.
När det är möjligt rekommenderar vi routerbaserade metoder så långt de räcker. Som allmän princip bör varje del av systemet som kan uttryckas i kod också uttryckas i kod – överanvänd alltså inte LLM:er när de inte behövs.
När dessa metoder når sina gränser går det att efterlikna vissa av orkestrerarens fördelar för öppna problem på ett mer begränsat sätt. Exempel:
Val av verktyg/överlämning till Agent: Kan enkelt implementeras med villkorsstyrda förgreningar eller LLM-klassificerare.
Fastställande av slutförande: Enkla LLM-klassificerare kan kontrollera att svaret är fullständigt innan det returneras till användaren.
”Planering” och ”iterativ kombination av resultat” är dock utan tvekan mycket svårare att åstadkomma i ett strikt routersystem. När en uppgift kräver dessa funktioner, enligt en LLM-klassificerare eller annan logik, föreslår vi därför att du skapar en mindre begränsad orkestrerargren i systemet.
Valet mellan router- och orkestrerararkitekturer bör spegla tillämpningens tydlighet, komplexitet och interaktionsform. Routerbaserade metoder ger för närvarande hög tillförlitlighet, effektivitet och enkel testning för tydligt definierade uppgifter. Orkestrerare ger större flexibilitet för bredare, samtalsbaserade interaktioner.
I takt med att LLM:er fortsätter att utvecklas kan balansen mellan metoderna förändras. Vi föredrar routerbaserade arkitekturer eller hybridarkitekturer för produktionsbelastningar och reserverar orkestrerare för öppna problem som kräver ett dynamiskt och människoliknande samspel.