Agenttijärjestelmää suunniteltaessa on tärkeää harkita tarkoin, miten ja missä päätökset tehdään.
Kun päätöksiä siirretään enemmän suuren kielimallin tehtäväksi, järjestelmä voi yleistyä useampiin tehtäviin, mutta nopeus, luotettavuus ja vikasietoisuus voivat kärsiä.
Pyri mahdollisuuksien mukaan siirtämään mahdollisimman suuri osa päätöksenteosta suurelta kielimallilta eksplisiittiseen ohjelmakoodiin. Tämä koskee erityisesti suuren riskin työnkulkuja ja tuotantotyönkulkuja.
Suureen kielimalliin perustuvaa agenttijärjestelmää suunniteltaessa yksi tärkeimmistä valinnoista on se, kuinka suuri osa päätöksenteosta sisällytetään suureen kielimalliin ja kuinka suuri osa toteutetaan eksplisiittisesti ohjelmistossa.
Valintaa voi havainnollistaa jatkumona seuraavien lähestymistapojen välillä:
Reititinpohjaisissa arkkitehtuureissa suoritusjärjestys ja logiikka määritetään eksplisiittisesti koodissa. Tämä varmistaa rajatun aihealueen tehtävissä testattavuuden, ennakoitavuuden ja vikasietoisuuden. Näitä kutsutaan myös työnkulkuagenteiksi.
Orkestroija-agentit käyttävät suuria kielimalleja tehtävien kulun dynaamiseen määrittämiseen luonnollisen kielen kehotteiden perusteella. Ne sopivat avoimiin vuorovaikutustilanteisiin, joissa ennalta määritetty logiikka ei riitä tai ole mahdollinen.
Suuren riskin tuotantotyönkulkuihin suosittelemme yleensä enemmän reititinpohjaisia ominaisuuksia. Orkestroijat kannattaa varata sovelluksiin, jotka edellyttävät joustavia, yleiskäyttöisiä keskusteluja.
Reititinpohjaiset arkkitehtuurit
Reititinpohjaiset agenttijärjestelmät:
Määrittävät päätöksenteon kulun eksplisiittisesti koodissa tai ohjelmistossa ja käyttävät suurta kielimallia valitsemaan ohjelmiston käyttämän reitin.
Muistuttavat perinteisiä ohjelmistojärjestelmiä, sillä niiden selkeät ja ennakoitavat etenemisreitit tuottavat yhdenmukaisempia tuloksia.
Sopivat erinomaisesti tarkasti määriteltäviin tehtäviin.
Seuraava yksinkertaistettu esimerkki kuvaa lentovarauksia hoitavaa chatbot-agenttia, joka käyttää reititinmallia. Suuri kielimalli luokittelee kysymyksen tarkoituksen kolmen vaihtoehdon perusteella, mutta ohjelmisto yhdistää tarkoituksen lopulta valmiiseen vastauspohjaan. Koska suuren kielimallin toimintaa on rajattu voimakkaasti, käyttäjä saa yhdenmukaisemman käyttökokemuksen.
Orkestroija-arkkitehtuurit
Toisin kuin reititinjärjestelmissä, orkestroivissa agenttijärjestelmissä:
Logiikan kulku määritetään ohjelmiston sijasta luonnollisen kielen kehotteilla. Huomautus: ohjelmointikieleen verrattuna luonnollinen kieli on luontaisesti monitulkintaista ja joustavaa. Kuten jäljempänä käsitellään, tästä on sekä hyötyä että haittaa. Ajattelemme tätä periaatteena ”tavoite ohjeen sijaan”.
Voivat tarjota useita käsittelyvaihtoehtoja, joiden suoritusjärjestyksen ja menetelmät suuri kielimalli määrittää.
Voivat luoda dynaamisesti uusia loogisia etenemisreittejä, joita on vaikea määrittää eksplisiittisesti ohjelmistossa.
Monitulkintaisuus voi johtaa epäjohdonmukaisiin tuloksiin, mutta onnistuessaan toiminta voi tuntua ”taianomaiselta”.
Seuraavassa esimerkissä samaan yksinkertaistettuun lentoyhtiöongelmaan sovelletaan orkestroijamallia. Sen sijaan, että ohjelmisto päättäisi sopivan vastauksen, päätöksenteko siirretään suuren kielimallin kerrokselle. Tässä moniagenttijärjestelmässä orkestroinnista vastaava pääagentti arvioi käyttäjän kyselyn ja siirtää sen lentojen muuttamiseen suunnitellulle agentille, joka antaa lopullisen vastauksen käyttäjälle.
Tässä esimerkissä suuren kielimallin kerros toimii luokittelijana, reitittimenä ja vastauksen laatijana. Reititinesimerkissä se toimi vain luokittelijana, ja ohjelmisto hoiti loput.
Suosittelemme käyttämään mahdollisuuksien mukaan reititinpohjaisia ratkaisuja, sillä niillä on seuraavat edut:
Nopeus ja tehokkuus: Paikallinen laskenta on nopeampaa kuin ulkoisista rajapinnoista riippuvien orkestroijien käyttö. Lisäksi ”IF/ELSE”-logiikan käsittely Pythonilla on huomattavasti halvempaa kuin sen lähettäminen suuren kielimallin tarjoajan 400 miljardin parametrin mallille.
Testattavuus ja ennakoitavuus: Vianmääritys, testaus ja ylläpito ovat huomattavasti helpompia vakiintuneiden ohjelmistokäytäntöjen avulla.
Läpinäkyvyys ja luotettavuus: Toiminnan vähäisempi vaihtelu helpottaa vianmääritystä. Suurempi osa sovelluksen kulusta ilmaistaan myös läpinäkyvänä, versionhallittuna ohjelmistona eikä suuren kielimallin vaikeaselkoisina ja tulkitsemattomina painoina.
Reititinmallien haittapuolena on niiden mahdollinen jäykkyys ja joustamattomuus. Ne voivat myös suoriutua heikosti avoimemmista ongelmista. Käyttäjät voivat pitää aina täsmälleen samoja vastauksia antavaa chatbotia tylsänä tai kaavamaisena.
Orkestroijaratkaisuilla on tehokkaita ominaisuuksia:
Suunnittelu: Ne voivat suunnitella vastauksia dynaamisesti.
Työkalun valinta ja siirto agentille: Ne voivat valita sopivat työkalut tai siirtää tehtäviä agenteille.
Tulosten iteratiivinen yhdistäminen: Ne voivat kehittää ja yhdistellä tuloksia luovasti uudelleen.
Valmistumisen arviointi: Ne voivat määrittää, milloin vastauksen viimeistelyyn on kerätty riittävästi tietoa.
Pydantic-AI:n tai OpenAI Agents SDK:n kaltaisten kehysten avulla orkestrointi on helppo ja nopea toteuttaa. Siksi se sopii erinomaisesti demoihin ja konseptitoteutuksiin.
Tällä lähestymistavalla on seuraavia haittapuolia:
Emme voi taata, että suuren kielimallin suunnitteluvaiheet ja niitä seuraavat toimet ovat oikeita tai tarkoituksenmukaisia. Reititinjärjestelmällä on sama ongelma, mutta tiukempien rajoitusten ansiosta sen toiminta on ennakoitavampaa.
Yksinkertaisiin ja tarkasti määriteltyihin tehtäviin ei todennäköisesti tarvita moniagenttijärjestelmän kaikkia ominaisuuksia. Esimerkiksi lentoyhtiöagenttiamme koskevassa esimerkissä lentoyhtiön tukijärjestelmän käyttäjällä on todennäköisesti vain rajallinen määrä erilaisia asiointitarpeita.
Koska suuri kielimalli sisältää enemmän logiikkaa, haitalliset toimijat voivat käyttää rajoitusten kiertämistä (jailbreak) tai muita hyökkäyksiä huomattavasti helpommin.
Päätöksenteko kätkeytyy suuren kielimallin sisään, mikä vaikeuttaa järjestelmän ymmärtämistä. Langfusen tai Braintrustin kaltaiset seurantatyökalut voivat kuitenkin auttaa osittain.
Huomautus lukijalle: vaikka mallien ominaisuudet kehittyvät nopeasti, seuraavat periaatteet tuskin muuttuvat lähitulevaisuudessa.
Määritä ongelman laajuus.
Voitko määrittää halutun päätöksentekologiikan helposti kaaviona?
Voiko sovelluksessasi hyväksyä virheitä tai odottamatonta toimintaa?
Myöntävä vastaus kumpaan tahansa kysymykseen viittaa siihen, että reititinominaisuudet sopivat paremmin.
Suosittelemme käyttämään reititinmalleja mahdollisimman pitkälle. Yleisenä periaatteena järjestelmän koodina ilmaistavat osat kannattaa toteuttaa koodina. Suuria kielimalleja ei siis pidä käyttää tarpeettomasti.
Kun niiden rajat tulevat vastaan, osan orkestroijien avoimiin tehtäviin liittyvistä eduista voi toteuttaa hallitusti. Esimerkkejä:
Työkalun valinta ja siirto agentille: Helppo toteuttaa ehtopohjaisella haarautumisella tai suuren kielimallin luokittelijoilla.
Valmistumisen arviointi: Yksinkertaiset suuren kielimallin luokittelijat voivat tarkistaa vastauksen kattavuuden ennen sen palauttamista käyttäjälle.
”Suunnittelu” ja ”tulosten iteratiivinen yhdistäminen” ovat kuitenkin selvästi paljon vaikeampia toteuttaa jäykässä reititinjärjestelmässä. Kun tehtävä vaatii näitä ominaisuuksia suuren kielimallin luokittelijan tai muun logiikan perusteella, suosittelemme luomaan järjestelmään vähemmän rajoitetun orkestroijahaaran.
Reititin- ja orkestroija-arkkitehtuurien välisessä valinnassa on huomioitava sovelluksen selkeys, monimutkaisuus ja vuorovaikutustapa. Reititinpohjaiset ratkaisut tarjoavat tällä hetkellä luotettavuutta, tehokkuutta ja helppoa testattavuutta tarkasti määriteltyihin tehtäviin. Orkestroijat tarjoavat enemmän joustavuutta laaja-alaisiin, keskusteleviin vuorovaikutustilanteisiin.
Suurten kielimallien kehittyessä näiden lähestymistapojen välinen tasapaino voi muuttua. Suosimme tuotantotyökuormissa reititinpohjaisia tai hybridiarkkitehtuureja ja varaamme orkestroijat avoimiin ongelmiin, jotka vaativat dynaamista ja ihmismäistä vuorovaikutusta.