Oluline on hoolikalt läbi mõelda, kuidas ja kus teie agendipõhises süsteemis otsuseid tehakse.
Kui jätta rohkem otsuseid LLM-i teha, võib süsteem sobida rohkemate ülesannete jaoks, kuid see võib vähendada kiirust, töökindlust ja vastupidavust.
Võimaluse korral püüdke võimalikult suur osa otsustusprotsessist LLM-ist selgesõnalisse tarkvarakoodi üle viia. See kehtib eriti suure riskiga ja/või tootmiskeskkonna töövoogude puhul.
LLM-il põhineva agendisüsteemi kavandamisel on üks tähtsamaid valikuid see, kui suur osa otsustamisest toimub LLM-mudelis ja kui suur osa selgesõnalises tarkvaras.
Selle valiku mõistmiseks võib käsitleda seda skaalana järgmiste lähenemisviiside vahel:
Marsruuteripõhistes arhitektuurides määratletakse järjestus ja loogika selgelt koodis, mis tagab kitsalt piiritletud ülesannete testitavuse, prognoositavuse ja vastupidavuse (neid nimetatakse ka „töövooagentideks“).
Orchestraatoragendid kasutavad suuri keelemudeleid (LLM-e), et määrata loomulikus keeles viipade põhjal dünaamiliselt ülesannete kulg. Need sobivad avatud suhtluseks, kus eelmääratletud loogikast ei piisa või seda pole võimalik luua.
Suure riskiga tootmistöövoogudes soovitame üldjuhul kasutada rohkem marsruuteripõhiseid funktsioone ja jätta orchestraatorid rakendustele, mis vajavad paindlikku üldotstarbelist vestlust.
Marsruuteripõhised arhitektuurid
Marsruuteripõhised agendisüsteemid:
Määratlevad otsustusvoo selgelt koodis või tarkvaras ning kasutavad LLM-i, et otsustada, millist tarkvaras määratud teed valida.
Sarnanevad traditsiooniliste tarkvarasüsteemidega, sest nende selged ja prognoositavad teed annavad ühtlasemaid tulemusi.
Sobivad ideaalselt täpselt määratletavate ülesannete jaoks.
Järgneb lihtsustatud näide lennufirma vestlusroboti broneerimisagendist, mis kasutab „marsruuteripõhist lähenemist“. LLM aitab liigitada küsimuse eesmärgi kolme võimaliku valiku alusel, kuid lõpuks seob meie tarkvara selle eesmärgi mallipõhise tekstvastusega. Kuna LLM tegutseb rangetes piirides, kogeb kasutaja ühtlasemat käitumist.
Orchestraatorarhitektuurid
Erinevalt marsruuterisüsteemist toimivad orchestraatoripõhised agendisüsteemid järgmiselt:
Määratlevad loogikavood tarkvara asemel loomulikus keeles viipadega. Märkus: erinevalt programmeerimiskeelest on loomulik keel olemuselt mitmetähenduslik ja paindlik. Sellel on nii eeliseid kui ka puudusi, mida käsitleme hiljem. Nimetame seda põhimõtteks „eesmärk juhise asemel“.
Võivad pakkuda mitut töötlemisvõimalust, kus LLM määrab täitmise järjekorra ja meetodi.
Võivad dünaamiliselt luua uusi loogikateid, mida on keeruline tarkvaras selgelt määratleda.
See mitmetähenduslikkus võib anda ebaühtlasi tulemusi, kuid õnnestumise korral võib mõju tunduda „maagiline“.
Järgmises näites rakendatakse sama lihtsustatud lennufirmaülesande puhul orchestraatoripõhist lähenemist. Selle asemel et lasta sobiv vastus valida tarkvaral, antakse otsustamine üle LLM-kihile. Siin on mitme agendiga süsteem, kus „juhtiv“ orchestraatoragent hindab kasutaja päringut ja suunab selle lendude muutmiseks loodud agendile, kes annab lõpuks kasutajale vastuse.
Selles näites täidab LLM-kiht liigitaja, marsruuteri ja vastuse koostaja rolli. Marsruuterinäites täitis see ainult liigitaja rolli, ülejäänu tegi tarkvara.
Võimaluse korral soovitame kasutada marsruuteripõhist lahendust, sest sellel on järgmised eelised:
Kiirus ja tõhusus: kohalikud arvutused on välisest API-st sõltuvatest orchestraatoritest kiiremad. Samuti on palju odavam töödelda „IF/ELSE“-loogikat Pythonis kui maksta LLM-i pakkujale selle töötlemise eest 400 miljardi parameetriga mudelis.
Testitavus ja prognoositavus: väljakujunenud tarkvarapraktikate abil on süsteemi märksa lihtsam siluda, testida ja hooldada.
Läbipaistvus ja töökindlus: väiksem käitumise varieeruvus lihtsustab probleemide lahendamist. Suurem osa rakenduse töövoost on esitatud ka läbipaistva, versioonihaldusega tarkvarana, mitte LLM-i läbipaistmatute ja tõlgendamatute kaaludena.
Marsruuteripõhiste lahenduste puuduseks on jäikus ja vähene paindlikkus ning need võivad avatumate probleemidega hätta jääda. Kasutajad võivad pidada alati täpselt samu vastuseid andvat vestlusrobotit igavaks või üheülbaliseks.
Orchestraatoripõhistel lahendustel on võimekad funktsioonid:
Planeerimine: need saavad vastuseid dünaamiliselt kavandada.
Tööriista valimine ja agendile üleandmine: sobivate tööriistade valimine või ülesannete agentidele delegeerimine.
Väljundite iteratiivne kombineerimine: väljundite korduv ja loominguline ümbertöötamine ning ühendamine.
Valmimise tuvastamine: otsustamine, millal on lõpliku vastuse koostamiseks kogutud piisavalt teavet.
Selliste raamistike nagu Pydantic-AI või OpenAI Agents SDK abil saab orkestreerimise kiiresti ja lihtsalt kasutusele võtta. Seetõttu sobib see hästi demode ja kontseptsiooni tõestavate prototüüpide jaoks.
Selle lähenemisviisi puudused on järgmised:
Miski ei taga, et LLM-i kavandatud sammud ja neile järgnevad toimingud oleksid õiged või sobivad. Marsruuterisüsteemil on sama probleem, kuid rangemate piirangute tõttu on selle käitumine prognoositavam.
Lihtsate ja täpselt määratletud ülesannete jaoks pole mitme agendiga süsteemi täielikku võimekust tõenäoliselt vaja. Näiteks meie lennufirmaagendi puhul soovivad lennufirma klienditoega suhtlevad inimesed tõenäoliselt esitada vaid piiratud hulka eri tüüpi päringuid.
Kuna LLM sisaldab rohkem loogikat, on kurjategijatel palju lihtsam seda jailbreak-ründega piirangutest vabastada või muul viisil ära kasutada.
See peidab otsustamise LLM-i sisse ja raskendab seetõttu süsteemi mõistmist, kuigi seiretööriistad nagu Langfuse või Braintrust võivad osaliselt aidata.
Märkus lugejale: kuigi mudelite võimekus areneb kiiresti, ei muutu alljärgnev lähitulevikus tõenäoliselt.
Määrake oma probleemi ulatus.
Kas saate soovitud otsustusloogikat hõlpsasti diagrammina kirjeldada?
Kas teie rakenduses on tõrked või ootamatu käitumine vastuvõetamatud?
Kui vastate vähemalt ühele neist küsimustest „jah“, sobivad marsruuteripõhised funktsioonid paremini.
Võimaluse korral soovitame kasutada marsruuteripõhiseid lahendusi nii kaua, kui need vajadusi täidavad. Üldpõhimõte on, et kui süsteemi mõnda osa saab väljendada koodina, siis tehke seda koodis ehk ärge kasutage LLM-e tarbetult.
Nende võimaluste piirini jõudes saab mõnda orchestraatori avatud lähenemise eelist piiratud kujul jäljendada. Näiteks:
Tööriista valimine ja agendile üleandmine: seda saab hõlpsasti rakendada tingimuslike harude või LLM-liigitajatega.
Valmimise tuvastamine: lihtsad LLM-liigitajad saavad enne vastuse kasutajale tagastamist kontrollida selle täielikkust.
„Planeerimist“ ja „väljundite iteratiivset kombineerimist“ on jäigas marsruuterisüsteemis siiski kahtlemata palju raskem saavutada. Kui ülesanne neid nõuab, nagu tuvastab LLM-liigitaja või muu loogika, soovitame luua süsteemis vähem piiratud orchestraatoriharu.
Marsruuteri- ja orchestraatorarhitektuuri vahel valides arvestage oma rakenduse eesmärgi selgust, keerukust ja suhtlusviisi. Marsruuteripõhised lahendused tagavad praegu selgelt määratletud ülesannete puhul töökindluse, tõhususe ja hõlpsa testimise. Orchestraatorid pakuvad laiahaardeliseks vestluslikuks suhtluseks suuremat paindlikkust.
LLM-ide arenedes võib nende lähenemisviiside tasakaal muutuda. Tootmiskoormuste puhul eelistame marsruuteripõhiseid või hübriidarhitektuure ning kasutame orchestraatoreid avatud probleemide jaoks, mis nõuavad dünaamilist ja inimlikku suhtlust.