Ir svarīgi rūpīgi apsvērt, kā un kur jūsu aģentu sistēmā tiek pieņemti lēmumi.
Uzticot vairāk lēmumu LVM, sistēma var darboties ar plašāku uzdevumu klāstu, taču tas var mazināt ātrumu, uzticamību un noturību.
Kad vien iespējams, centieties pēc iespējas lielāku lēmumu pieņemšanas procesa daļu pārcelt no LVM uz skaidri definētu programmatūras kodu. Tas ir īpaši svarīgi augsta riska un/vai produkcijas darbplūsmās.
Projektējot uz LVM balstītu aģentu sistēmu, viens no svarīgākajiem lēmumiem ir noteikt, cik lielu lēmumu pieņemšanas daļu uzticēt LVM modelim un cik — skaidri definētai programmatūrai.
Lai šo izvēli būtu vieglāk izprast, varam to aplūkot kā spektru starp šādām pieejām:
Maršrutētāju arhitektūrās secība un loģika ir skaidri definēta kodā, nodrošinot šauras jomas uzdevumu testējamību, paredzamību un noturību (tās dēvē arī par „darbplūsmu aģentiem”).
Orķestrētāju aģenti paļaujas uz lielajiem valodu modeļiem (LVM), kas, izmantojot dabiskās valodas uzvednes, dinamiski nosaka uzdevumu izpildes plūsmu. Tie ir ideāli piemēroti atvērtai mijiedarbībai, kur iepriekš definēta loģika nav pietiekama vai iespējama.
Augsta riska produkcijas darbplūsmām parasti iesakām vairāk izmantot maršrutētāju funkcijas, bet orķestrētājus atstāt lietojumiem, kuros nepieciešamas elastīgas, universālas sarunas.
Maršrutētāju arhitektūras
Maršrutētāju aģentu sistēmas:
Skaidri definē lēmumu pieņemšanas plūsmu kodā vai programmatūrā un izmanto LVM, lai noteiktu, kuru maršrutu programmatūrai izvēlēties.
Vairāk līdzinās tradicionālām programmatūras sistēmām, jo tām ir skaidri un paredzami izpildes ceļi, kas nodrošina konsekventākus rezultātus.
Ir ideāli piemērotas precīzi definējamiem uzdevumiem.
Tālāk redzams vienkāršots aviokompānijas rezervēšanas tērzēšanas aģenta piemērs, kurā izmantota „maršrutētāja pieeja”. LVM palīdz klasificēt jautājuma nolūku, izvēloties vienu no trim iespējām, taču tieši programmatūra šo nolūku sasaista ar atbildes teksta veidni. Tā kā LVM darbība ir stingri ierobežota, lietotājs saņem konsekventāku pieredzi.
Orķestrētāju arhitektūras
Atšķirībā no maršrutētāju sistēmām orķestrētāju aģentu sistēmas:
Loģikas plūsmas definē ar dabiskās valodas uzvednēm, nevis programmatūru. Piezīme: salīdzinājumā ar programmēšanas valodu dabiskā valoda pēc būtības ir neviennozīmīga un elastīga (tai piemīt gan priekšrocības, gan trūkumi, ko apspriedīsim vēlāk). Mēs to raksturojam kā „nolūku, nevis instrukciju”.
Var piedāvāt vairākas apstrādes iespējas, ļaujot LVM noteikt izpildes secību un metodi.
Var dinamiski veidot jaunus loģikas ceļus, kurus programmatūrā būtu grūti skaidri definēt.
Šī neviennozīmība var radīt nekonsekventus rezultātus, taču veiksmīgā gadījumā iznākums var šķist „maģisks”.
Nākamajā piemērā orķestrētāja pieeja izmantota tai pašai vienkāršotajai aviokompānijas problēmai. Tā vietā, lai piemēroto atbildi noteiktu programmatūra, lēmumu pieņemšana tiek uzticēta LVM slānim. Šeit ir vairāku aģentu sistēma, kurā „galvenais” orķestrētāja aģents izvērtē lietotāja vaicājumu un nodod to aģentam, kas īpaši paredzēts lidojumu maiņai un beigās sniedz lietotājam atbildi.
Šajā piemērā LVM slānis pilda klasifikatora, maršrutētāja un atbildes sagatavotāja funkcijas. Maršrutētāja piemērā tas pildīja tikai klasifikatora funkciju, bet pārējo paveica programmatūra.
Kad vien iespējams, iesakām izmantot maršrutētāju pieeju, jo tai ir šādas priekšrocības:
Ātrums un efektivitāte: lokāli aprēķini ir ātrāki par orķestrētājiem, kas atkarīgi no ārējām API. Turklāt „IF/ELSE” loģiku apstrādāt Python kodā ir daudz lētāk nekā maksāt LVM pakalpojumu sniedzējam par tās apstrādi 400 miljardu parametru modelī.
Testējamība un paredzamība: izmantojot ierasto programmatūras izstrādes praksi, atkļūdošana, testēšana un uzturēšana ir ievērojami vienkāršāka.
Pārskatāmība un uzticamība: mazākas darbības atšķirības atvieglo problēmu novēršanu. Turklāt lielāka lietojumprogrammas plūsmas daļa ir izteikta pārskatāmā programmatūrā ar versiju kontroli, nevis LVM necaurredzamajos un neinterpretējamajos svaros.
Maršrutētāju pieeju trūkums ir to stingrība un neelastība, kas var apgrūtināt atvērtāku problēmu risināšanu. Tērzēšanas robots, kas vienmēr sniedz pilnīgi vienādas atbildes, lietotājiem var šķist garlaicīgs un stagnējošs.
Orķestrētāju risinājumiem ir plašas iespējas:
Plānošana: tie var dinamiski plānot atbildes.
Rīku izvēle un uzdevumu nodošana aģentam: izvēlas piemērotus rīkus vai deleģē uzdevumus aģentiem.
Rezultātu iteratīva apvienošana: iteratīvi un radoši pārveido un apvieno rezultātus.
Pabeigtības noteikšana: nosaka, kad ir savākts pietiekami daudz informācijas, lai pabeigtu atbildi.
Tādi ietvari kā Pydantic-AI vai OpenAI Agents SDK ļauj orķestrēšanu ieviest ātri un vienkārši. Tāpēc šī pieeja ir lieliski piemērota demonstrācijām un koncepcijas apliecinājumiem.
Šīs pieejas trūkumi ir šādi:
Nav garantijas, ka LVM plānošanas darbības un tām sekojošās darbības būs pareizas vai piemērotas. Maršrutētāju sistēmai ir tā pati problēma, taču stingrāku ierobežojumu dēļ tās darbība ir paredzamāka.
Vienkāršiem, precīzi definētiem uzdevumiem, visticamāk, nav vajadzīgas visas vairāku aģentu sistēmas iespējas. Piemēram, mūsu aviokompānijas aģenta gadījumā, visticamāk, ir tikai daži vaicājumu veidi, kurus lietotāji patiešām vēlas iesniegt aviokompānijas atbalsta sistēmai.
Tā kā LVM ietver vairāk loģikas, ļaunprātīgiem lietotājiem ir daudz vieglāk panākt ierobežojumu apiešanu vai to izmantot savā labā.
Lēmumu pieņemšana tiek abstrahēta un pārcelta uz LVM, tādēļ sistēmu ir grūtāk izprast (lai gan tādi uzraudzības rīki kā Langfuse vai Braintrust var daļēji palīdzēt).
Piezīme lasītājam: lai gan modeļu iespējas strauji attīstās, maz ticams, ka turpmāk minētais tuvākajā nākotnē mainīsies.
Nosakiet savas problēmas tvērumu.
Vai vēlamo lēmumu loģiku varat viegli attēlot diagrammā?
Vai kļūmes un neparedzama lietojumprogrammas darbība jums nav pieļaujama?
Atbilde „jā” uz kādu no iepriekš minētajiem jautājumiem liecina, ka piemērotākas būtu maršrutētāja funkcijas.
Kad vien iespējams, iesakām izmantot maršrutētāju pieeju tik ilgi, cik tā ir piemērota. Vispārīgais princips: ja kādu sistēmas daļu var izteikt kodā, dariet to kodā (proti, neizmantojiet LVM pārmērīgi, ja tas nav vajadzīgs).
Kad šīs pieejas iespējas ir izsmeltas, dažas atvērtā orķestrētāja priekšrocības var ierobežotā veidā atdarināt. Piemēram:
Rīku izvēle un uzdevumu nodošana aģentam: viegli īstenojama ar nosacījumu zariem vai LVM klasifikatoriem.
Pabeigtības noteikšana: vienkārši LVM klasifikatori var pārbaudīt atbildes pilnīgumu, pirms tā tiek nosūtīta lietotājam.
Tomēr stingrā maršrutētāju sistēmā „plānošanu” un „rezultātu iteratīvu apvienošanu” neapšaubāmi ir daudz grūtāk īstenot. Tāpēc, ja uzdevumam šīs iespējas ir vajadzīgas — kā to nosaka LVM klasifikators vai cita loģika —, iesakām sistēmā izveidot mazāk ierobežotu orķestrētāja zaru.
Izvēloties maršrutētāja vai orķestrētāja arhitektūru, jāņem vērā lietojumprogrammas skaidrība, sarežģītība un mijiedarbības veids. Pašlaik maršrutētāju pieejas precīzi definētiem uzdevumiem nodrošina uzticamību, efektivitāti un vienkāršu testēšanu. Orķestrētāji nodrošina lielāku elastību plašākai sarunveida mijiedarbībai.
LVM turpinot attīstīties, līdzsvars starp šīm pieejām var mainīties. Produkcijas darba slodzēm dodam priekšroku maršrutētāju vai hibrīdajām arhitektūrām, bet orķestrētājus izmantojam atvērtām problēmām, kur nepieciešama dinamiska, cilvēkam līdzīga mijiedarbība.