Det er viktig å tenke nøye gjennom hvordan og hvor beslutninger tas i det agentbaserte systemet.
Når flere beslutninger overlates til en LLM, kan systemet potensielt generalisere til flere oppgaver, men det kan gå ut over hastighet, pålitelighet og robusthet.
Prøv om mulig å flytte så mye som mulig av beslutningsprosessen fra LLM-en til eksplisitt programkode. Dette gjelder særlig arbeidsflyter med høy risiko og/eller arbeidsflyter i produksjon.
Når du utformer et LLM-basert agentsystem, er et av de viktigste valgene hvor mye av beslutningstakingen som skal ligge i en LLM-modell, og hvor mye som skal ligge i eksplisitt programvare.
For å gjøre valget lettere å forstå kan vi se det som et spekter mellom følgende tilnærminger:
Ruterbaserte arkitekturer definerer rekkefølgen og logikken eksplisitt i kode. Det gir god testbarhet, forutsigbarhet og robusthet for oppgaver innenfor et avgrenset domene (disse kalles også «arbeidsflytagenter»).
Orkestratoragenter bruker store språkmodeller (LLM-er) til dynamisk å bestemme oppgaveflyten ved hjelp av instruksjoner i naturlig språk. Dette passer godt for åpne interaksjoner der forhåndsdefinert logikk er utilstrekkelig eller umulig.
For produksjonsarbeidsflyter med høy risiko anbefaler vi vanligvis flere ruterbaserte funksjoner, mens orkestratorer forbeholdes bruksområder som krever fleksible samtaler for generelle formål.
Ruterbaserte arkitekturer
Ruterbaserte agentsystemer:
Definerer beslutningsflyten eksplisitt gjennom kode/programvare og bruker en LLM til å avgjøre hvilken rute programvaren skal følge.
Ligner mer på tradisjonelle programvaresystemer ved at de har tydelige og forutsigbare flyter som gir mer konsistente resultater.
Passer svært godt til oppgaver som kan defineres presist.
Nedenfor følger et forenklet eksempel på en bestillingsagent for en chatbot hos et flyselskap som bruker «rutertilnærmingen». LLM-en bidrar til å klassifisere hensikten med spørsmålet ut fra tre mulige alternativer, men det er til syvende og sist programvaren som knytter denne hensikten til et tekstsvar fra en mal. Fordi LLM-en har svært stramme rammer, vil brukeren oppleve mer konsekvent atferd.
Orkestratorarkitekturer
I motsetning til rutersystemer gjør orkestratorbaserte agentsystemer følgende:
Definerer logiske flyter gjennom instruksjoner i naturlig språk i stedet for programvare. Merk: Sammenlignet med et programmeringsspråk er naturlig språk i seg selv tvetydig og fleksibelt (både en positiv og negativ egenskap, som vi kommer tilbake til senere). Vi beskriver dette som «hensikt fremfor instruksjon».
Kan tilby flere behandlingsalternativer, der LLM-en bestemmer utførelsesrekkefølgen og fremgangsmåten.
Kan dynamisk opprette nye logiske flyter som er vanskelige å definere eksplisitt i programvare.
Denne tvetydigheten kan gi inkonsekvente resultater, men når det fungerer, kan det føles «magisk».
Følgende eksempel bruker en orkestratortilnærming på det samme forenklede flyselskapsproblemet. I stedet for å la programvaren bestemme hvilket svar som passer, delegeres beslutningen til LLM-laget. Her har vi et system med flere agenter, der en overordnet orkestratoragent vurderer brukerens spørsmål og sender det videre til en agent som er utviklet spesielt for å endre flyreiser. Denne agenten gir til slutt brukeren et svar.
I dette eksempelet fungerer LLM-laget som klassifikator, ruter og svarforfatter. I rutereksempelet fungerte det bare som klassifikator (programvaren håndterte resten).
Der det er mulig, anbefaler vi ruterbaserte løsninger fordi de har følgende fordeler:
Hastighet og effektivitet: Lokale beregninger er raskere enn orkestratorer som er avhengige av eksterne API-er. Det er også mye billigere å behandle «IF/ELSE»-logikken i Python enn å betale en LLM-leverandør for å kjøre den gjennom en modell med 400 milliarder parametere.
Testbarhet og forutsigbarhet: Betydelig enklere å feilsøke, teste og vedlikeholde ved hjelp av etablerte metoder for programvareutvikling.
Åpenhet og pålitelighet: Mindre variasjon i atferden gjør feilsøkingen enklere. En større andel av applikasjonsflyten uttrykkes dessuten i transparent, versjonskontrollert programvare, i motsetning til de ugjennomsiktige og ufortolkelige vektene i en LLM.
Ulempen med rutertilnærminger er at de kan være rigide og lite fleksible, og at de kan få problemer med mer åpne problemstillinger. En chatbot som alltid gir nøyaktig de samme svarene, kan oppleves som kjedelig eller stillestående av brukerne.
Orkestratordesign har kraftige funksjoner:
Planlegging: De kan planlegge svar dynamisk.
Valg av verktøy/overføring til agent: Velger egnede verktøy eller delegerer oppgaver til agenter.
Iterativ kombinasjon av resultater: Bearbeider og kombinerer resultater på nytt og på kreative måter.
Fastslå når oppgaven er fullført: Avgjør når det er samlet inn nok informasjon til å ferdigstille et svar.
Rammeverk som Pydantic-AI eller OpenAIs Agents SDK gjør orkestrering enkel og rask å implementere. Det gjør tilnærmingen velegnet til demoer og konseptutprøving.
Ulempene med denne tilnærmingen er at:
Vi har ingen garanti for at LLM-ens planleggingstrinn og påfølgende handlinger er riktige eller hensiktsmessige. Rutersystemet har samme problem, men siden det har strammere rammer, er atferden mer forutsigbar.
For enkle, veldefinerte oppgaver trenger vi neppe hele kapasiteten til et system med flere agenter. I eksempelet med flyselskapsagenten finnes det sannsynligvis bare et begrenset antall typer forespørsler som noen faktisk ønsker å utføre gjennom flyselskapets kundestøttesystem.
Fordi mer av logikken ligger i LLM-en, er den langt mer utsatt for at ondsinnede aktører utfører jailbreak eller utnytter den.
Beslutningstakingen abstraheres inn i LLM-en, noe som gjør systemet vanskeligere å forstå (selv om overvåkingsverktøy som Langfuse eller Braintrust kan avhjelpe dette noe).
Merknad til leseren: Selv om modellen utvikler seg raskt, er det lite sannsynlig at punktene nedenfor vil endre seg i nær fremtid.
Fastsett problemets omfang.
Kan du enkelt beskrive den ønskede beslutningslogikken i et diagram?
Tåler applikasjonen din dårlig feil eller uventet atferd?
Hvis du svarer «ja» på ett av spørsmålene ovenfor, tyder det på at ruterfunksjoner passer bedre.
Der det er mulig, anbefaler vi å bruke rutertilnærminger så langt de strekker til. Som et generelt prinsipp bør alt i systemet som kan uttrykkes i kode, uttrykkes i kode (altså bør LLM-er ikke brukes mer enn nødvendig).
Når disse tilnærmingene når grensene sine, kan noen av orkestratorens fordeler ved åpne problemstillinger gjenskapes under mer kontrollerte rammer. Eksempel:
Valg av verktøy/overføring til agent: Kan enkelt implementeres gjennom betingede forgreninger eller LLM-klassifikatorer.
Fastslå når oppgaven er fullført: Enkle LLM-klassifikatorer kan kontrollere at svaret er fullstendig før det sendes til brukeren.
«Planlegging» og «iterativ kombinasjon av resultater» er imidlertid utvilsomt langt vanskeligere å få til i et rigid rutersystem. Når en oppgave krever dette (slik det fastslås av en LLM-klassifikator eller annen logikk), foreslår vi derfor å opprette en orkestratorgren med friere rammer i systemet.
Valget mellom ruter- og orkestratorarkitekturer bør gjenspeile hvor tydelig og kompleks applikasjonen er, samt hvordan brukerne samhandler med den. Ruterbaserte tilnærminger gir i dag pålitelighet, effektivitet og enkel testing for klart definerte oppgaver. Orkestratorer gir større fleksibilitet ved bredere, samtalebaserte interaksjoner.
Etter hvert som LLM-er blir mer avanserte, kan balansen mellom disse tilnærmingene endre seg. For produksjonsarbeidsbelastninger foretrekker vi ruterbaserte eller hybride arkitekturer, mens orkestratorer forbeholdes åpne problemstillinger som krever dynamisk, menneskelignende samhandling.