Tommelfingerregler for design af agentsystemer

• Det er vigtigt nøje at overveje, hvordan og hvor beslutninger træffes i dit agentbaserede system.

• Når flere beslutninger overlades til en LLM, kan systemet potentielt generalisere til flere opgaver, men det kan gå ud over hastighed, pålidelighed og robusthed.

• Forsøg så vidt muligt at flytte mest muligt af beslutningsprocessen fra LLM'en til eksplicit softwarekode. Det gælder især arbejdsgange med høj risiko og/eller i produktion.

Når du designer et LLM-baseret agentsystem, er en af de vigtigste beslutninger, hvor stor en del af beslutningsprocessen der skal ligge i en LLM-model frem for i eksplicit software.

For at forstå dette valg kan vi betragte det som et spektrum mellem følgende tilgange:

• Routerbaserede arkitekturer definerer rækkefølge og logik eksplicit i kode. Det sikrer testbarhed, forudsigelighed og robusthed ved opgaver inden for et afgrænset domæne (de kaldes også »workflow-agenter«).

• Orkestratoragenter bruger store sprogmodeller (LLM'er) til dynamisk at fastlægge opgaveforløb ud fra prompts i naturligt sprog. De er velegnede til åbne interaktioner, hvor foruddefineret logik er utilstrækkelig eller umulig.

Til produktionsarbejdsgange med høj risiko anbefaler vi typisk flere routerbaserede funktioner og forbeholder orkestratorer til anvendelser, der kræver fleksible samtaler til generelle formål.

Routerbaserede arkitekturer

Routerbaserede agentsystemer:

• Definerer beslutningsforløbet eksplicit gennem kode/software og bruger en LLM til at afgøre, hvilken rute softwaren skal følge.

• Minder mere om traditionelle softwaresystemer, fordi de har klare og forudsigelige forløb, som giver mere ensartede resultater.

• Er ideelle til opgaver, der kan defineres præcist.

Følgende er et forenklet eksempel på en bookingagent i en chatbot for et flyselskab, som bruger »routertilgangen«. LLM'en hjælper med at klassificere hensigten med spørgsmålet ud fra tre mulige valg, men i sidste ende er det vores software, der knytter hensigten til et skabelonbaseret tekstsvar. Fordi LLM'en er stærkt begrænset, vil brugeren opleve en mere ensartet adfærd.

Orkestratorarkitekturer

I modsætning til routersystemer gør orkestratorbaserede agentsystemer følgende:

• Definerer logiske forløb gennem prompts i naturligt sprog frem for software. Bemærk: Sammenlignet med et programmeringssprog er naturligt sprog i sig selv tvetydigt og fleksibelt. Det er både en fordel og en ulempe, som vi kommer ind på senere. Vi betragter det som »hensigt frem for instruktion«.

• Kan tilbyde flere behandlingsmuligheder, mens LLM'en fastlægger rækkefølgen og metoden for udførelsen.

• Kan dynamisk skabe nye logiske forløb, som er vanskelige at definere eksplicit i software.

• Denne tvetydighed kan føre til uensartede resultater, men når det fungerer, kan det føles »magisk«.

Følgende eksempel anvender en orkestratortilgang på det samme forenklede flyselskabsproblem. I stedet for at lade softwaren afgøre, hvilket svar der er passende, overlades beslutningen til LLM-laget. Her har vi et multiagentsystem, hvor en overordnet orkestratoragent sorterer brugerens forespørgsel og sender den videre til en agent, der er udviklet specifikt til at ændre flyrejser og i sidste ende svarer brugeren.

I dette eksempel fungerer LLM-laget som klassifikator, router og svarskribent. I routereksemplet fungerede det kun som klassifikator, mens softwaren håndterede resten.

Hvor det er muligt, anbefaler vi routerbaserede tilgange, fordi de har følgende fordele:

• Hastighed og effektivitet: Lokale beregninger er hurtigere end orkestratorer, der er afhængige af eksterne API'er. Det er også langt billigere at behandle din »IF/ELSE«-logik i Python end at betale en LLM-udbyder for at køre den gennem sin model med 400 milliarder parametre.

• Testbarhed og forudsigelighed: Langt nemmere at fejlfinde, teste og vedligeholde ved hjælp af veletablerede softwaremetoder.

• Gennemsigtighed og pålidelighed: Mindre variation i adfærden gør fejlfinding enklere. En større del af applikationsforløbet er desuden udtrykt i gennemsigtig, versionsstyret software i modsætning til en LLM's uigennemsigtige vægte, som ikke kan fortolkes.

Ulemperne ved routertilgange er, at de kan være rigide og ufleksible og have svært ved mere åbne problemstillinger. En chatbot, der altid giver præcis de samme svar, kan af brugerne opfattes som kedelig eller stillestående.

Orkestratordesign har effektive funktioner:

1. Planlægning: De kan planlægge svar dynamisk.

2. Valg af værktøj/overdragelse til agent: Vælger egnede værktøjer eller uddelegerer opgaver til agenter.

3. Iterativ kombination af resultater: Bearbejder og kombinerer resultater på nye, kreative måder.

4. Vurdering af færdiggørelse: Afgør, hvornår der er indsamlet nok oplysninger til at færdiggøre et svar.

Frameworks som Pydantic-AI eller OpenAI's Agents SDK gør orkestrering nem og hurtig at implementere. Det gør tilgangen velegnet til demoer og proof of concept-projekter.

Ulemperne ved denne tilgang er:

• Der er ingen garanti for, at LLM'ens planlægningstrin og efterfølgende handlinger er korrekte eller hensigtsmæssige. Routersystemet har det samme problem, men fordi det er mere begrænset, er dets adfærd mere forudsigelig.

• Til enkle, veldefinerede opgaver har vi næppe brug for alle funktionerne i et multiagentsystem. I vores eksempel med en flyselskabsagent er der sandsynligvis kun et begrænset antal typer forespørgsler, som brugere af et flyselskabs supportsystem reelt ønsker at foretage.

• Fordi mere logik ligger i LLM'en, er den langt mere sårbar over for jailbreak og anden udnyttelse fra ondsindede aktører.

• Tilgangen abstraherer beslutningsprocessen ind i LLM'en og gør derfor systemet sværere at forstå, selvom overvågningsværktøjer som Langfuse eller Braintrust kan afhjælpe problemet delvist.

Bemærkning til læseren: Selvom modellernes funktioner udvikler sig hurtigt, vil nedenstående næppe ændre sig i den nærmeste fremtid.

Fastlæg problemets omfang.

• Kan du nemt illustrere den ønskede beslutningslogik i et diagram?

• Er fejl eller uventet adfærd uacceptabel i din applikation?

Et »ja« til et af ovenstående spørgsmål tyder på, at routerfunktioner vil være bedre.

Hvor det er muligt, anbefaler vi at bruge routertilgange, så længe de slår til. Som hovedregel bør en del af systemet udtrykkes i kode, hvis det er muligt. Undgå med andre ord at bruge LLM'er unødigt.

Når disse tilgange når deres grænse, kan nogle af orkestratorens fordele ved åbne problemstillinger efterlignes på en kontrolleret måde. For eksempel:

1. Valg af værktøj/overdragelse til agent: Kan nemt implementeres med betingede forgreninger eller LLM-klassifikatorer.

2. Vurdering af færdiggørelse: Enkle LLM-klassifikatorer kan kontrollere, om svaret er fyldestgørende, før det sendes til brugeren.

»Planlægning« og »iterativ kombination af resultater« er dog uden tvivl langt sværere at opnå i et rigidt routersystem. Når en opgave kræver disse funktioner, hvilket kan afgøres af en LLM-klassifikator eller anden logik, foreslår vi derfor at oprette en mindre begrænset orkestratorgren i systemet.

Dit valg mellem router- og orkestratorarkitekturer bør afspejle applikationens tydelighed, kompleksitet og interaktionsform. Routerbaserede tilgange giver i dag pålidelighed, effektivitet og nem testning ved klart definerede opgaver. Orkestratorer giver større fleksibilitet ved bredere, samtalebaserede interaktioner.

Efterhånden som LLM'er udvikler sig, kan balancen mellem disse tilgange ændre sig. Vi foretrækker routerbaserede eller hybride arkitekturer til produktionsbelastninger og forbeholder orkestratorer til åbne problemer, der kræver dynamisk, menneskelignende interaktion.