Het is belangrijk zorgvuldig te overwegen hoe en waar beslissingen in uw agentsysteem worden genomen.
Door meer beslissingen aan een LLM over te laten, kan het systeem mogelijk voor meer taken worden ingezet, maar dit kan ten koste gaan van snelheid, betrouwbaarheid en robuustheid.
Probeer waar mogelijk zo veel mogelijk besluitvorming uit de LLM te halen en in expliciete softwarecode onder te brengen. Dit geldt vooral voor risicovolle workflows en productieworkflows.
Bij het ontwerpen van een agentsysteem op basis van een LLM is een van de belangrijkste keuzes hoeveel besluitvorming u in een LLM-model onderbrengt en hoeveel in expliciete software.
Om deze keuze beter te begrijpen, kunnen we haar zien als een spectrum tussen de volgende benaderingen:
Routerarchitecturen leggen de volgorde en logica expliciet vast in code. Dit waarborgt de testbaarheid, voorspelbaarheid en robuustheid voor taken binnen een beperkt domein (ook wel "workflowagents" genoemd).
Orchestrator-agents gebruiken grote taalmodellen (LLM's) om op basis van prompts in natuurlijke taal dynamisch het taakverloop te bepalen. Ze zijn ideaal voor open interacties waarvoor vooraf gedefinieerde logica ontoereikend of onmogelijk is.
Voor risicovolle productieworkflows raden we doorgaans aan meer routerfuncties te gebruiken en orchestrators te reserveren voor toepassingen die flexibele, algemene gesprekken vereisen.
Routerarchitecturen
Agentsystemen met een router:
Leggen de besluitvormingsstroom expliciet vast in code of software en gebruiken een LLM om te bepalen welke route de software volgt.
Lijken meer op traditionele softwaresystemen, doordat ze duidelijke en voorspelbare paden hebben die consistentere resultaten opleveren.
Zijn ideaal voor taken die strikt kunnen worden afgebakend.
Hieronder staat een eenvoudig voorbeeld van een agent voor het boeken via een luchtvaartchatbot die de "routerbenadering" gebruikt. De LLM helpt om de bedoeling van de vraag in een van drie categorieën in te delen, maar uiteindelijk koppelt onze software die bedoeling aan een standaardantwoord. Doordat de LLM sterk is begrensd, ervaart de gebruiker consistenter gedrag.
Orchestrator-architecturen
In tegenstelling tot agentsystemen met een router doen agentsystemen met een orchestrator het volgende:
Ze definiëren logische stromen met prompts in natuurlijke taal in plaats van met software. Opmerking: vergeleken met een programmeertaal is natuurlijke taal per definitie dubbelzinnig en flexibel. Dat is zowel een voordeel als een nadeel, zoals we later bespreken. We noemen dit "intentie in plaats van instructie".
Ze kunnen meerdere verwerkingsopties bieden, waarbij de LLM de uitvoeringsvolgorde en werkwijze bepaalt.
Ze kunnen dynamisch nieuwe logische paden creëren die moeilijk expliciet in software vast te leggen zijn.
Deze dubbelzinnigheid kan tot inconsistente resultaten leiden, maar als het werkt, kan het "magisch" aanvoelen.
In het volgende voorbeeld wordt op hetzelfde vereenvoudigde luchtvaartprobleem een orchestratorbenadering toegepast. In plaats van software te laten bepalen welk antwoord passend is, wordt de besluitvorming aan de LLM-laag overgelaten. Hier hebben we een systeem met meerdere agents. Een centrale orchestrator-agent beoordeelt de vraag van de gebruiker en draagt die over aan een agent die specifiek is ontworpen om vluchten te wijzigen. Die agent geeft uiteindelijk antwoord aan de gebruiker.
In dit voorbeeld fungeert de LLM-laag als classificator, router en tekstschrijver voor het antwoord. In het routervoorbeeld fungeerde de LLM alleen als classificator; de software deed de rest.
Waar mogelijk raden we routerarchitecturen aan, omdat ze de volgende voordelen bieden:
Snelheid en efficiëntie: lokale berekeningen zijn sneller dan orchestrators die afhankelijk zijn van externe API's. Het is bovendien veel goedkoper om uw "IF/ELSE"-logica in Python te verwerken dan een LLM-provider te betalen om die door een model met 400 miljard parameters te laten verwerken.
Testbaarheid en voorspelbaarheid: dankzij beproefde softwarepraktijken zijn fouten veel eenvoudiger op te sporen en is het systeem gemakkelijker te testen en onderhouden.
Transparantie en betrouwbaarheid: minder variatie in het gedrag vereenvoudigt het oplossen van problemen. Een groter deel van het applicatieverloop is bovendien vastgelegd in transparante software met versiebeheer, in plaats van in de ondoorzichtige, niet te interpreteren gewichten van een LLM.
Nadelen van routerbenaderingen zijn dat ze star en inflexibel kunnen zijn en moeite kunnen hebben met opener geformuleerde problemen. Gebruikers kunnen een chatbot die altijd exact dezelfde antwoorden geeft saai of statisch vinden.
Orchestratorontwerpen bieden krachtige mogelijkheden:
Planning: ze kunnen antwoorden dynamisch plannen.
Toolselectie/overdracht aan een agent: ze selecteren geschikte tools of delegeren taken aan agents.
Iteratieve combinatie van resultaten: ze kunnen resultaten iteratief en creatief opnieuw combineren.
Voltooiing bepalen: ze bepalen wanneer voldoende informatie is verzameld om een antwoord af te ronden.
Met frameworks zoals Pydantic-AI of de Agents SDK van OpenAI kan orchestratie eenvoudig en snel worden geïmplementeerd. Daardoor is deze aanpak zeer geschikt voor demo's en proof-of-concepts.
De nadelen van deze aanpak zijn:
We hebben geen garantie dat de planningsstappen en daaropvolgende acties van de LLM correct of passend zijn. Het routersysteem heeft hetzelfde probleem, maar doordat het sterker begrensd is, is het gedrag voorspelbaarder.
Voor eenvoudige, duidelijk afgebakende taken hebben we waarschijnlijk niet alle mogelijkheden van een systeem met meerdere agents nodig. In ons voorbeeld met de luchtvaartagent is er waarschijnlijk maar een beperkt aantal soorten verzoeken dat iemand bij een klantenservicesysteem van een luchtvaartmaatschappij wil indienen.
Doordat de LLM meer logica bevat, is het systeem veel vatbaarder voor jailbreaks en misbruik door kwaadwillenden.
De besluitvorming wordt in de LLM ondergebracht, waardoor het systeem moeilijker te doorgronden is. Monitoringtools zoals Langfuse of Braintrust kunnen hierbij mogelijk gedeeltelijk helpen.
Opmerking voor de lezer: hoewel de mogelijkheden van modellen snel veranderen, zullen de onderstaande punten waarschijnlijk niet snel wijzigen.
Bepaal de reikwijdte van uw probleem.
Kunt u de gewenste beslislogica gemakkelijk in een diagram vastleggen?
Is falen of onverwacht gedrag in uw toepassing onaanvaardbaar?
Als u op een van deze vragen "ja" antwoordt, zijn routerfuncties waarschijnlijk geschikter.
Waar mogelijk raden we aan routerbenaderingen te gebruiken zolang dat volstaat. Als algemeen uitgangspunt geldt: kan een onderdeel van uw systeem in code worden uitgedrukt, leg het dan vast in code. Gebruik dus niet onnodig veel LLM's.
Wanneer de grenzen van deze benaderingen worden bereikt, kunnen sommige voordelen van open orchestrators op een begrensde manier worden nagebootst. Bijvoorbeeld:
Toolselectie/overdracht aan een agent: eenvoudig te implementeren met voorwaardelijke vertakkingen of LLM-classificatoren.
Voltooiing bepalen: eenvoudige LLM-classificatoren kunnen controleren of een antwoord volledig is voordat het naar de gebruiker wordt gestuurd.
"Planning" en "iteratieve combinatie van resultaten" zijn in een star routersysteem echter ongetwijfeld veel moeilijker te realiseren. Wanneer een taak deze mogelijkheden vereist, zoals vastgesteld door een LLM-classificator of andere logica, raden we daarom aan een minder begrensde orchestratortak in uw systeem te maken.
Uw keuze tussen een router- en orchestratorarchitectuur moet aansluiten bij de duidelijkheid en complexiteit van uw toepassing en de gewenste interactiestijl. Routerbenaderingen bieden momenteel betrouwbaarheid, efficiëntie en eenvoudige testbaarheid voor duidelijk afgebakende taken. Orchestrators bieden meer flexibiliteit voor bredere interacties in gespreksvorm.
Naarmate LLM's zich verder ontwikkelen, kan de balans tussen deze benaderingen verschuiven. Voor productieworkloads geven we de voorkeur aan router- of hybride architecturen. Orchestrators reserveren we voor open problemen die een dynamische, menselijke interactie vereisen.