Este important să analizați cu atenție cum și unde sunt luate deciziile în sistemul cu agenți.
Delegarea mai multor decizii unui LLM poate permite sistemului să se generalizeze la mai multe sarcini, însă poate afecta viteza, fiabilitatea și robustețea.
Când este posibil, încercați să transferați cât mai mult din procesul decizional din LLM în cod software explicit. Acest lucru este valabil mai ales pentru fluxurile de lucru cu risc ridicat și/sau din producție.
Când proiectați un sistem cu agenți bazat pe LLM, una dintre cele mai importante alegeri este cât din procesul decizional să fie inclus într-un model LLM și cât să fie implementat în software explicit.
Pentru a înțelege mai ușor, putem privi această alegere ca pe un spectru între următoarele abordări:
Arhitecturile bazate pe router definesc explicit ordinea și logica în cod, asigurând posibilitatea de testare, predictibilitatea și robustețea pentru sarcini din domenii restrânse (acestea se mai numesc și „agenți pentru fluxuri de lucru”).
Agenții orchestratori se bazează pe modele lingvistice mari (LLM-uri) pentru a decide dinamic fluxul sarcinilor folosind prompturi în limbaj natural, fiind ideali pentru interacțiuni deschise, în care logica predefinită este insuficientă sau imposibilă.
Pentru fluxurile de lucru cu risc ridicat, utilizate în producție, recomandăm de obicei mai multe funcții bazate pe router, păstrând orchestratorii pentru aplicațiile care necesită conversații flexibile și de uz general.
Arhitecturi bazate pe router
Sistemele cu agenți bazate pe router:
Definesc explicit fluxul decizional prin cod/software și folosesc un LLM pentru a stabili ce rută urmează software-ul.
Se apropie mai mult de sistemele software tradiționale, deoarece au trasee clare și previzibile, care generează rezultate mai consecvente.
Sunt ideale pentru sarcini care pot fi definite strict.
Mai jos este un exemplu simplificat de agent conversațional pentru rezervări aeriene care folosește „abordarea bazată pe router”. Deși LLM-ul ne ajută să clasificăm intenția întrebării alegând dintre trei opțiuni, software-ul este cel care asociază în final această intenție cu un răspuns-text șablon. Deoarece LLM-ul este foarte strict limitat, utilizatorul va beneficia de un comportament mai consecvent.
Arhitecturi cu orchestrator
Spre deosebire de sistemul bazat pe router, sistemele cu agenți orchestratori:
Definesc fluxurile logice prin prompturi în limbaj natural, nu prin software. Notă: spre deosebire de un limbaj de programare, limbajul natural este inerent ambiguu și flexibil (caracteristici atât pozitive, cât și negative, după cum vom discuta ulterior). Considerăm că aceasta înseamnă „intenție, nu instrucțiune”.
Pot oferi mai multe opțiuni de procesare, LLM-ul stabilind ordinea și metoda de execuție.
Pot crea dinamic trasee logice noi, dificil de definit explicit în software.
Această ambiguitate poate genera rezultate inconsecvente, dar, când funcționează, poate părea „magică”.
Exemplul următor aplică o abordare cu orchestrator aceleiași probleme simplificate din domeniul aerian. În loc ca software-ul să decidă ce răspuns este adecvat, procesul decizional este delegat stratului LLM. Aici avem un sistem cu mai mulți agenți, în care un agent orchestrator „principal” evaluează solicitarea utilizatorului și o transferă unui agent conceput special pentru schimbarea zborurilor, care îi oferă în final răspunsul utilizatorului.
În acest exemplu, stratul LLM îndeplinește rolurile de clasificator, router și autor al răspunsului. În exemplul cu router, acesta îndeplinea doar rolul de clasificator (software-ul ocupându-se de restul).
Când este posibil, recomandăm abordările bazate pe router, deoarece oferă următoarele avantaje:
Viteză și eficiență: calculele locale sunt mai rapide decât orchestratorii care depind de API-uri externe. De asemenea, este mult mai ieftin să procesați logica „IF/ELSE” în Python decât să plătiți un furnizor de LLM pentru a o trece prin modelul său cu 400 de miliarde de parametri.
Testabilitate și predictibilitate: depanarea, testarea și întreținerea sunt mult mai ușoare prin practicile software consacrate.
Transparență și fiabilitate: variațiile mai mici de comportament simplifică depanarea. O proporție mai mare a fluxului aplicației este exprimată și în software transparent, gestionat prin controlul versiunilor, spre deosebire de ponderile opace și neinterpretabile ale unui LLM.
Dezavantajele abordărilor bazate pe router sunt rigiditatea, inflexibilitatea și dificultatea de a gestiona probleme mai deschise. Un chatbot care oferă mereu exact aceleași răspunsuri poate fi considerat plictisitor sau inert de către utilizatori.
Arhitecturile cu orchestrator oferă funcții puternice:
Planificare: pot planifica dinamic răspunsurile.
Selectarea instrumentelor/transferul către agenți: selectează instrumentele potrivite sau deleagă sarcini agenților.
Combinarea iterativă a rezultatelor: iterează și recombină creativ rezultatele.
Stabilirea finalizării: determină când au fost colectate suficiente informații pentru definitivarea unui răspuns.
Cadre precum Pydantic-AI sau Agents SDK de la OpenAI fac orchestrarea simplă și rapid de implementat. Prin urmare, această abordare este excelentă pentru demonstrații sau validări de concept.
Dezavantajele acestei abordări sunt următoarele:
Nu avem nicio garanție că etapele de planificare ale LLM-ului și acțiunile ulterioare vor fi corecte sau adecvate. Sistemul bazat pe router are aceeași problemă, dar, fiind mai strict limitat, comportamentul său este mai previzibil.
Pentru sarcini simple și bine definite, probabil că nu avem nevoie de toate funcțiile unui sistem cu mai mulți agenți. De exemplu, în cazul agentului nostru pentru companii aeriene, probabil există doar un număr limitat de tipuri de solicitări pe care o persoană dorește să le adreseze unui sistem de asistență al unei companii aeriene.
Deoarece LLM-ul conține mai multă logică, este mult mai vulnerabil la atacuri de tip jailbreak sau la exploatarea de către actori rău intenționați.
Mută procesul decizional în LLM, făcând sistemul mai greu de înțeles (deși instrumente de monitorizare precum Langfuse sau Braintrust pot ajuta parțial).
Notă pentru cititori: deși capacitățile modelelor evoluează rapid, este puțin probabil ca cele de mai jos să se schimbe în viitorul apropiat.
Stabiliți domeniul problemei.
Puteți defini cu ușurință logica decizională dorită într-o diagramă?
Aplicația dumneavoastră nu tolerează erorile sau comportamentul neașteptat?
Un răspuns afirmativ la oricare dintre întrebările de mai sus sugerează că funcțiile bazate pe router ar fi mai potrivite.
Când este posibil, recomandăm să folosiți abordări bazate pe router atât timp cât permit cerințele și, ca principiu general, dacă o parte a sistemului poate fi exprimată în cod, implementați-o în cod (adică nu folosiți excesiv LLM-uri când nu sunt necesare).
Când sunt atinse limitele acestor abordări, unele avantaje deschise ale orchestratorului pot fi reproduse într-o manieră controlată. De exemplu:
Selectarea instrumentelor/transferul către agenți: se implementează ușor prin ramificații condiționale sau clasificatoare LLM.
Stabilirea finalizării: clasificatoarele LLM simple pot verifica dacă răspunsul este complet înainte de a-l transmite utilizatorului.
Totuși, „planificarea” și „combinarea iterativă a rezultatelor” sunt, fără îndoială, mult mai greu de realizat într-un sistem rigid bazat pe router. Prin urmare, când o sarcină necesită aceste funcții (potrivit unui clasificator LLM sau altei logici), recomandăm crearea în sistem a unei ramuri cu orchestrator mai puțin constrânse.
Alegerea între arhitecturile bazate pe router și cele cu orchestrator trebuie să reflecte claritatea, complexitatea și stilul de interacțiune ale aplicației. În prezent, abordările bazate pe router oferă fiabilitate, eficiență și testare facilă pentru sarcini clar definite. Orchestratorii oferă mai multă flexibilitate pentru interacțiuni conversaționale mai ample.
Pe măsură ce LLM-urile continuă să evolueze, echilibrul dintre aceste abordări se poate schimba. Pentru sarcinile de producție, preferăm arhitecturile bazate pe router sau cele hibride și păstrăm orchestratorii pentru probleme deschise, care necesită interacțiuni dinamice, asemănătoare celor umane.