Deze blog is het eerste deel van een serie blogs, waarin ik ga proberen een uitgebreide overview van agentframeworks te maken door ze te gebruiken bij het bouwen van een aantal kleine agentic applicaties.
Note vooraf: in deze blog gebruik ik zo nu en dan een anthropomorfisme om acties of output van AI te beschrijven. AI modellen kunnen uiteraard niet “denken” of “begrijpen”.
Agents
Definitie
Als 2023 binnen de wereld van LLMs het jaar van RAG was, dan is 2024 ongetwijfeld het jaar van Agents. Je zou kunnen beargumenteren dat een agent in de context van een LLM kort gezegd een systeem is dat autonoom de controle over de stroom van een applicatie neemt door zelf beslissingen te maken op basis van AI-output. Maar de mate waarin LLM's de output van applicaties bepalen verschilt nogal per toepassing. Een zwart-wit definitie op basis waarvan je met een harde ja of nee kunt bepalen of iets "agentic" is, schiet daarom tekort. In plaats daarvan is het nuttiger om te denken in termen van een spectrum van agentic gedrag. Net zoals autonome voertuigen verschillende niveaus van autonomie hebben, kunnen AI-systemen verschillende gradaties van zelfstandigheid tonen. Hoe meer een systeem in staat is om zelf keuzes te maken en zijn gedrag aan te passen op basis van nieuwe informatie, hoe meer we het “agentic” kunnen noemen. Hier een leuke blog die dit in wat meer detail bespreekt.
“Een zwart-wit definitie op basis waarvan je met een harde ja of nee kunt bepalen of iets "agentic" is, schiet daarom tekort. In plaats daarvan is het nuttiger om te denken in termen van een spectrum van agentic gedrag”
Autogen en CrewAI
Het concept “Agent” begon voor mij te leven na de release van AutoGen van Microsoft. AutoGen maakt het mogelijk om eenvoudig multi-agent systemen te creëren en te orkestreren. Het was een was een van de eerste frameworks die een toegankelijke manier bood om interactieve AI-systemen te bouwen. AutoGen stelt ontwikkelaars in staat om verschillende AI-agenten te definiëren, elk met hun eigen rol en expertise, en deze te laten samenwerken om taken uit te voeren. Het AutoGen concept kreeg snel navolging van andere frameworks, een bekend voorbeeld hiervan is CrewAI. Net als AutoGen richt CrewAI zich op het faciliteren van multi-agent systemen, maar met een unieke benadering. CrewAI legt de nadruk op het creëren van een 'bemanning' van AI-agenten, waarbij elke agent een specifieke rol en expertise heeft. Het framework biedt een intuïtieve manier om de samenwerking tussen deze gespecialiseerde agenten te structureren, waardoor complexe taken efficiënt kunnen worden aangepakt.
Microsoft introduceerde AutoGen2 afgelopen januari
Role play agents
Veel mensen zullen bij de term “agent” of “agentic” in de context van LLM’s vooral denken aan deze bijna persona gedreven methode, zeker ook omdat we al vrij snel wisten dat “Role-Play prompting” een handige manier is om LLM output te verbeteren. Bovendien maakt de benadering met rollen en taakomschrijvingen de flow of logica van een applicatie makkelijk te begrijpen.
Controle vs autonomie
Voor mij heeft de wat technischer omschreven definitie uit de intro meer waarde. De mate van controle of autonomie die we AI toevertrouwen is voor iedereen die met AI werkt een super fundamentele vraag. Waarbij zich vaak een klein dilemma voordoet:
“Hoe autonomer een agent kan opereren, hoe waardevoller of veelzijdiger die agent potentieel is, maar hoe minder betrouwbaar. “
Een klein voorbeeld in een klantenservice-context
In mijn optiek zijn multi-agent systemen vaak een manier om de balans tussen autonomie en betrouwbaarheid te optimaliseren. In de manier waarop je de relaties tussen de agents onderling en met de rest van de applicatie definieert definieer je ook de mate van autonomie. De rest van je code inrichting bevat de kaders voor je agents.
Complexiteit
Wanneer je met agents werkt in je applicatie, kan de complexiteit van je inrichting om verschillende redenen snel toenemen. Zo kan het basisproces waarbinnen je de agents wil integreren al complex zijn, of kan het zijn dat je om de output van je agents te optimaliseren verschillende controle en optimalisatie stappen toevoegt.
Voorbeeldje
Laten we ons een situatie indenken waarin een groot ziekenhuis deze basis RAG-applicatie gebruikt om medisch personeel te ondersteunen bij het beantwoorden van complexe vragen over diagnoses en behandelplannen.
Kort gezegd werkt de applicatie dan als volgt:
- De arts voert een vraag in.
- De vraag wordt verwerkt en relevante documenten worden opgehaald uit de kennisbank.
- De meest relevante context wordt geselecteerd.
- Een prompt wordt opgesteld met de vraag en de context.
- De agent (een groot taalmodel) genereert een antwoord.
- Het antwoord wordt aan de arts getoond.
Er zijn verschillende schakels en omstandigheden binnen deze basis inrichting die er voor kunnen zorgen dat de output van de applicatie niet optimaal is:
- Onnauwkeurige query verwerking: De vraag van de arts wordt mogelijk niet goed geïnterpreteerd.
- Onvolledige document ophaling: Relevante informatie wordt mogelijk gemist.
- Beperkte context selectie: Belangrijke nuances kunnen verloren gaan.
- Enkele agent beperkingen: Één model kan mogelijk niet alle medische specialismes beheersen.
- Gebrek aan kwaliteitscontrole: Er is geen mechanisme om de juistheid van het antwoord te verifiëren.
Er zijn verschillende optimalisatie technieken binnen RAG frameworks om dit soort punten te verbeteren, maar een manier om er aan te werken is een multi agent inrichting, waarin je de zwakke punten adresseert en de output optimaliseert:
In dit verbeterde multi-agent systeem zitten veel verbeteringen:
- Een query analyse agent verfijnt en verduidelijkt de vraag van de arts.
- Een document retrieval agent zoekt in een kennisbank.
- Een context selectie agent kiest de meest relevante informatie.
- Meerdere specialisme agents analyseren de vraag vanuit verschillende medische perspectieven.
- Een synthese agent combineert de inzichten van de specialisme agents.
- Een fact-checking agent verifieert de informatie met betrouwbare bronnen.
- Een taaloptimalisatie agent zorgt voor een heldere en begrijpelijke output.
Dit is puur hypothetisch natuurlijk, en het gaat nu niet om deze specifieke case. Wat duidelijk is: het begin en eindpunt van ons hypothetische procesje is nog steeds hetzelfde, maar door verschillende agents toe te voegen vergroten we in zekere zin de controle die we over de output hebben; we sturen het proces meer. We hopen dat we daarmee de uiteindelijke output van onze applicatie vergroten, dit vraagt wel wat extra complexiteit.
Je zou mogen verwachten dat naarmate LLM modellen verder verbeterd worden, de noodzaak van het toevoegen van deze extra checks en balances wat afneemt, althans, uit het oogpunt van de kwaliteit van de output. Voorlopig echter, zal voor de meeste cases een te autonoom opererende agentic applicatie te onbetrouwbaar zijn.
Flexibiliteit
Ook als we de flow zelf verder niet aanraken qua logica, zouden we op bepaalde momenten onze applicatie fors kunnen verbeteren, namelijk als nieuwe modellen worden gelanceerd. Je mag er van uit gaan dat nieuwere modellen vaak beter presteren dan oudere modellen*.
*Een mooi voorbeeld hiervan is cursor.ai. Cursor.ai is een IDE waarin AI je helpt met programmeren. De feature die Cursor het afgelopen jaar waarschijnlijk het meest heeft verbeterd, was geen extra fuctionaliteit in de UX, het was ook geen aanpassing in de structuur van agents, het was de aanpassing om cursor gebruik te laten maken van Sonnet 3.5.
De hoge mate van verandering qua onderlinge verhoudingen tussen LLM’s maakt dat het noodzakelijk is dat je snel kunt schakelen tussen de modellen
Het kan natuurlijk voorkomen dat een ander model vraagt om een net wat andere benadering. Wellicht heeft het nieuwe model wel een heel andere contextwindow, of vraagt het om een andere prompting methodiek. Het optimaliseren en testen van de manier waarop applicaties LLMs gebruiken, en welke LLMs gekozen worden voor welke taken zou naar mijn idee zomaar een nieuwe beroepsgroep kunnen creëren. Net zoals je, om maar wat te noemen, SEO optimalisatie specialisten of UX specialisten hebt. Wat hoe dan ook nu al wel duidelijk is, is dat je niet locked in wil zijn bij 1 provider, zoals OpenAI. Het loont om te zorgen dat je snel en makkelijk gebruik kunt maken van LLM modellen van meerdere providers.
“Agent optimalisatie, zou heel goed, net zoals UX optimalisatie of SEO optimalisatie een gespecialiseerde beroepsgroep kunnen zijn over een tijdje.”
LLM Frameworks
Abstractie
Naarmate de complexiteit van agentic systemen toeneemt, wordt de noodzaak om een abstractielaag toe te voegen aan je applicatie waarschijnlijk ook groter. Met het al eerder genoemde hoge tempo waarin er nieuwere, betere modellen krijgen, is het cruciaal om flexibel te blijven en snel te kunnen inspelen op nieuwe ontwikkelingen. Het is cruciaal dat je in staat bent om snel aanpassingen te maken in modelkeuze, LLM-provider, promptstructuur of bijvoorbeeld toolgebruik door de agents. Een goed ontworpen abstractielaag maakt het mogelijk om deze veranderingen door te voeren zonder de hele applicatie te hoeven herschrijven, waardoor je systeem toekomstbestendig blijft in een snel evoluerend AI-landschap.
Uitdagingen
Het creëren van een slimme abstractielaag voor de inrichting van je agentic applicatie kan een behoorlijke uitdaging zijn. Zoals hiervoor al omschreven volgen de ontwikkelingen qua nieuwe releaseses elkaar razend snel op, en waarschijnlijk wil je veel liever werken aan de core functionaliteit van je applicatie dan de hele tijd te zorgen dat je abstractielaag up to date is met de laatste updates van LLM providers.
Er is een bekende talk van Jeff Bezos bij de Y Combinator startup school in 2008. In de talk daagt hij zijn publiek uit om zich te richten op “dat wat hun bier lekkerder laat smaken”. Het is een verwijzing naar bierbrouwerijen aan het begin van de 20e eeuw. Niet AI maar elektriciteit was toen de baanbrekende nieuwe technologie waar iedereen dezelfde soort vragen over had als veel mensen nu over AI hebben; “Hoe integreren we deze technologie in ons bedrijf?”. De eerste brouwerijen die elektriciteit gebruikten, konden dat doen doordat ze zelf hun eigen krachtcentrales hadden gebouwd. Hoewel ze met deze centrales inderdaad nieuwe machines van stroom konden voorzien, waren de centrales erg arbeids- en kapitaalintensief.
Na verloop van tijd, toen het gebruik van stroom toegankelijker werd, kwamen er andere brouwerijen die ook stroom gingen gebruiken in hun fabrieken. Zij bouwden echter geen eigen centrales, maar kochten simpelweg de stroom van nutsbedrijven. Dit bleek een stuk voordeliger en efficienter. Het gevolg was dat deze nieuwe generatie brouwerijen de eerste generatie uit de markt concurreerde.
Bezos beargumenteert in de talk dat bedrijven vandaag de dag hier ook veel van kunnen leren*, ze zouden zich naar zijn idee moeten richten op wat een bedrijf onderscheid en zich niet laten afleiden door dingen die dat niet doen. Kort gezegd “Focus on what the beer taste better”.
De inhoudelijke flow of logica van je applicatie, de sets business ruling die je er in verwerkt, laten je bier absoluut beter smaken, ze raken aan de kern van wat je met je applicatie biedt. De exacte manier waarop je diensten van derden, zoals LLM providers, verbindt met je applicatie niet.
De rol van LLM frameworks
In dit gat zijn verschillende bedrijven en opensource projecten gesprongen. Er zijn inmiddels een groot aantal frameworks beschikbaar die ons in staat stellen agentic applicaties te bouwen waarmee we flows kunnen inrichten waarin we gebruik maken van agents. De frameworks helpen je om makkelijk te integreren met LLM’s maar ook met VectorStore aanbieders, een breed scala aan tools die agents kunnen gebruiken (bijvoorbeeld zoeken op internet) en nog veel meer. Door te leunen op zo’n framework als smeermiddel tussen je applicatie en de LLM, vergemakkelijk je de inrichting en het onderhoud van je applicatie behoorlijk. Bovendien bieden veel frameworks een aantal tools die cruciaal zijn voor het verbeteren van je agentic applicatie. Denk bijvoorbeeld aan een module waarmee je de in- en output van llm calls kunt visualiseren.
Conclusie
Tot nu toe hebben we gekeken naar wat agents zijn, de balans tussen controle en autonomie, en hoe de complexiteit van agentic systemen kan toenemen. Ook hebben we de noodzaak van flexibiliteit besproken in het snel evoluerende AI-landschap en de rol die LLM-frameworks spelen in het vergemakkelijken van de ontwikkeling van agentic applicaties.
Een goed LLM-framework voorziet voor mij in de behoefte aan een krachtige abstractielaag die ons in staat stelt om geavanceerde AI-systemen te bouwen zonder ons te verliezen in de technische details van elke LLM-provider. Het stelt ons in staat om snel te schakelen tussen modellen, onze systemen te optimaliseren, en te blijven innoveren in een veld dat constant in beweging is.
De volgende keer wil ik wat dieper ingaan op de werking van een aantal van deze frameworks, door in in een aantal van deze frameworks steeds dezelfde agentic applicatie te bouwen.
Mocht je feedback hebben op deze of 1 van de andere blogs, dan hoor ik heel graag van je.