Heurístiques per dissenyar sistemes basats en agents

Heurístiques pràctiques per decidir quins comportaments dels agents corresponen al model de llenguatge i quins requereixen programari explícit.

Resum executiu

  • És important valorar amb cura com i on es prenen les decisions en un sistema basat en agents.

  • Delegar més decisions a un LLM pot permetre que el sistema es generalitzi a més tasques, però pot comportar costos en velocitat, fiabilitat i robustesa.

  • Sempre que sigui possible, traslladeu del LLM al codi de programari explícit tantes parts del procés de presa de decisions com pugueu. Això és especialment important en fluxos de treball d'alt risc o de producció.

Introducció

En dissenyar un sistema basat en agents i LLM, una de les decisions més importants és fins a quin punt la presa de decisions queda encapsulada en un model LLM o en programari explícit.

Per entendre-ho millor, podem considerar que aquesta elecció se situa en un espectre entre els enfocaments següents:

  • Les arquitectures basades en encaminadors defineixen explícitament l'ordre i la lògica mitjançant codi, fet que garanteix la capacitat de prova, la predictibilitat i la robustesa en tasques d'àmbit restringit (també s'anomenen "agents de flux de treball").

  • Els agents orquestradors es basen en models de llenguatge grans (LLM) per decidir dinàmicament els fluxos de tasques mitjançant instruccions en llenguatge natural. Són ideals per a interaccions obertes en què una lògica predefinida resulta insuficient o impossible.

Diagrama que il·lustra la introducció.

En fluxos de treball de producció i d'alt risc, normalment recomanem prioritzar les funcions basades en encaminadors i reservar els orquestradors per a aplicacions que exigeixin converses flexibles i d'ús general.

Encaminador o orquestrador: entendre'n la diferència

Arquitectures basades en encaminadors

Els sistemes basats en agents encaminadors:

  • Defineixen explícitament el flux de presa de decisions mitjançant codi o programari i utilitzen un LLM per determinar quina ruta ha de seguir el programari.

  • S'assemblen més als sistemes de programari tradicionals perquè tenen recorreguts clars i previsibles que generen resultats més coherents.

  • Són ideals per a tasques que es poden definir estrictament.

A continuació es mostra un exemple simplificat d'un agent de reserves d'una aerolínia en forma de chatbot que utilitza l'"enfocament d'encaminador". Tot i que el LLM ens ajuda a classificar la intenció de la pregunta entre tres opcions possibles, és el programari qui acaba associant aquesta intenció a una resposta de text predefinida. Com que el LLM està molt restringit, l'usuari percebrà un comportament més coherent.

Diagrama que il·lustra les diferències entre l'encaminador i l'orquestrador.

Arquitectures d'orquestradors

A diferència dels sistemes d'encaminadors, els sistemes basats en agents orquestradors:

  • Defineixen els fluxos lògics mitjançant instruccions en llenguatge natural en lloc de programari. Nota: en comparació amb un llenguatge de programació, el llenguatge natural és ambigu i flexible per naturalesa (característiques que poden ser positives i negatives, com veurem més endavant). Ho entenem com a "intenció en lloc d'instrucció".

  • Poden oferir diverses opcions de processament, mentre el LLM determina l'ordre i la metodologia d'execució.

  • Poden crear dinàmicament recorreguts lògics nous que resulten difícils de definir explícitament mitjançant programari.

  • Aquesta ambigüitat pot generar resultats incoherents, però, quan funciona, pot semblar "màgica".

L'exemple següent aplica un enfocament d'orquestrador al mateix problema simplificat de l'aerolínia. En lloc de deixar que el programari decideixi quina resposta és adequada, la presa de decisions es delega a la capa del LLM. Aquí tenim un sistema multiagent en què un agent orquestrador "principal" avalua la consulta de l'usuari i la deriva a un agent dissenyat específicament per canviar vols, que acaba proporcionant la resposta a l'usuari.

En aquest exemple, la capa del LLM exerceix les funcions de classificador, encaminador i redactor de la resposta. En l'exemple de l'encaminador, només exercia la funció de classificador (el programari s'encarregava de la resta).

Diagrama que il·lustra les diferències entre l'encaminador i l'orquestrador.

Punts forts i reptes de les arquitectures d'encaminadors

Sempre que sigui possible, recomanem utilitzar enfocaments basats en encaminadors, perquè ofereixen els avantatges següents:

  • Velocitat i eficiència: els càlculs locals són més ràpids que els orquestradors que depenen d'API externes. També és molt més barat processar la lògica "IF/ELSE" amb Python que pagar perquè un proveïdor de LLM la processi mitjançant el seu model de 400.000 milions de paràmetres.

  • Capacitat de prova i predictibilitat: són considerablement més fàcils de depurar, provar i mantenir mitjançant pràctiques de programari consolidades.

  • Transparència i fiabilitat: una menor variació del comportament simplifica la resolució de problemes. A més, una proporció més gran del flux de l'aplicació s'expressa mitjançant programari transparent i controlat per versions, en lloc dels pesos opacs i ininterpretables d'un LLM.

Els inconvenients dels enfocaments d'encaminador són que poden resultar rígids i poc flexibles, i tenir dificultats davant de problemes més oberts. Els usuaris podrien considerar avorrit o monòton un chatbot que sempre respongui exactament de la mateixa manera.

Punts forts i reptes de les arquitectures d'orquestradors

Els dissenys d'orquestradors ofereixen funcions potents:

  1. Planificació: poden planificar respostes dinàmicament.

  2. Selecció d'eines i derivació a agents: seleccionen les eines adequades o deleguen tasques a agents.

  3. Combinació iterativa de resultats: iteren i recombinen resultats de manera creativa.

  4. Determinació de la finalització: determinen quan s'ha recopilat prou informació per enllestir una resposta.

L'ús de marcs de treball com Pydantic-AI o l'Agents SDK d'OpenAI permet implementar l'orquestració de manera ràpida i senzilla. Per això, és una opció excel·lent per a demostracions o proves de concepte.

Els inconvenients d'aquest enfocament són els següents:

  • No tenim cap garantia que els passos de planificació del LLM i les accions posteriors siguin correctes o adequats. El sistema d'encaminador té el mateix problema, però, com que està més restringit, el seu comportament és més previsible.

  • En tasques senzilles i ben definides, és poc probable que necessitem totes les capacitats d'un sistema multiagent. Per exemple, en el nostre cas de l'agent d'una aerolínia, probablement només hi ha un nombre limitat de tipus de consulta que una persona voldria fer realment en interactuar amb el servei d'assistència d'una aerolínia.

  • Com que el LLM conté més lògica, és molt més susceptible que els actors maliciosos eludeixin les proteccions de seguretat o l'explotin.

  • Abstreu la presa de decisions i la trasllada al LLM, fet que dificulta entendre el sistema (tot i que eines de monitoratge com Langfuse o Braintrust poden ajudar-hi parcialment).

Les nostres heurístiques per dissenyar sistemes basats en agents

Nota per al lector: tot i que les capacitats dels models canvien ràpidament, és poc probable que el que s'exposa a continuació canviï a curt termini.

Entendre les decisions que requereix l'aplicació

Determineu l'abast del problema.

  • Podeu definir fàcilment en un diagrama la lògica de decisió que voleu?

  • L'aplicació no pot tolerar errors ni comportaments inesperats?

Respondre "sí" a qualsevol de les dues preguntes anteriors indica que les funcions d'encaminador serien més adequades.

Primer l'encaminador; després, els enfocaments híbrids

Sempre que sigui possible, recomanem utilitzar enfocaments d'encaminador fins que n'assoliu els límits. Com a principi general, si una part del sistema es pot expressar en codi, expresseu-la en codi; és a dir, no feu un ús excessiu dels LLM quan no calgui.

Quan s'arriba als límits d'aquests enfocaments, alguns dels avantatges oberts dels orquestradors es poden reproduir de manera restringida. Per exemple:

  1. Selecció d'eines i derivació a agents: es pot implementar fàcilment mitjançant ramificacions condicionals o classificadors LLM.

  2. Determinació de la finalització: classificadors LLM senzills poden comprovar que la resposta estigui completa abans de retornar-la a l'usuari.

Tanmateix, la "planificació" i la "combinació iterativa de resultats" són sens dubte molt més difícils d'aconseguir en un sistema d'encaminador rígid. Per tant, quan una tasca requereixi aquestes funcions —segons ho determini un classificador LLM o una altra lògica—, suggerim crear una branca d'orquestrador menys restringida dins del sistema.

Conclusió i perspectives de futur

L'elecció entre arquitectures d'encaminadors i d'orquestradors ha de reflectir el grau de definició, la complexitat i l'estil d'interacció de l'aplicació. Actualment, els enfocaments basats en encaminadors ofereixen fiabilitat, eficiència i facilitat de prova per a tasques ben definides. Els orquestradors ofereixen més flexibilitat per a interaccions conversacionals i més àmplies.

A mesura que els LLM continuïn avançant, l'equilibri entre aquests enfocaments pot evolucionar. Ens inclinem per arquitectures basades en encaminadors o híbrides per a les càrregues de treball de producció, i reservem els orquestradors per a problemes oberts que exigeixen una interacció dinàmica i semblant a la humana.

Autor

Andrew Liubinas