Satunnainen paasaus siitä, missä olemme tekoälyagenttien kanssa:

Jotkut eivät kutsu heitä agenteiksi, mutta "työnkulkuagentteja", joilla on deterministisiä virtoja, on kaikkialla ja toimii. kuka tahansa voi rakentaa yksinkertaisia työnkulkuagentteja, jopa aloittamalla koodittomilla työkaluilla, kuten Zapier ja n8n. Monimutkaiset työnkulkuagentit vaativat paljon enemmän harkintaa rakentaakseen luotettavasti ja tehokkaasti. monimutkainen työnkulku yleiseen ja arvokkaaseen käyttötapaukseen, johon on sisällytetty asiaankuuluvat integraatiot, voi toimia itsenäisenä yrityksenä, ja myös loistava GTM, jota voidaan myöhemmin laajentaa muihin työnkulkuihin tai itsenäisempään työhön.

dynaamisemmat ja autonomisemmat toimijat alkavat toimia ja niistä on hyötyä tutkimuksessa (varsinkin jos verkkopohjainen) ja koodauksessa. vähemmän luotettava, kun alat lisätä lisää tietolähteitä (esim. ohjelmointirajapintoja). Vain luku -agentit tuntuvat turvallisilta ja helpoilta testata, mutta autonomisten agenttien antaminen toimiin (kirjoittamiseen) on pelottavaa. (Satunnainen idea tästä: olisi siistiä, jos CRM:n kaltaiset työkalut antaisivat sinun "haarukoida" kehittäjäpeilin ja suorittaa automaatiokokeiluja, joihin voit palata tai yhdistää takaisin.)

Dynaamiset agentit toimivat hyvin, kun he voivat (1) luoda ja seurata hyvää suunnitelmaa ja (2) suorittaa tehtävät oikein ja (3) löytää oikean kontekstin jokaiseen vaiheeseen (sekä suunnitteluun että jokaiseen tehtävään). Lopuksi sen on (4) pohdittava matkan varrella (joko ihmisen panoksella tai ilman), jotta se voi mukauttaa suunnitelmaa asianmukaisesti ja myös parantaa tapaa, jolla se suorittaa epäonnistuneita tai huonosti suoriutuvia tehtäviä.

Tehtävien suunnittelu: LLM:n päättelykyky Toimii hyvin yksinkertaisissa tehtäväluetteloissa, jotka eivät vaadi yksityistä kontekstia (kuten syvällinen tutkimus, vain sarja verkkohakuja yhteenvedon aikana). Jos haluat tutkia paljon kokonaisuuksia, syvällinen tutkimus ei toimi yhtä hyvin, koska tehtäväluettelon hallinta on suhteellisen yksinkertaista. taulukkolaskentapohjaiset tekoälytyökalut toimivat paremmin monien entiteettien tutkimisessa, koska siirrät tehtävien hallinnan tehokkaasti laskentataulukkoon, koska pitkien tehtäväluetteloiden välittäminen kehotteiden välillä ei toimi tässä. Koodausagenttien tehtävienhallinta toimii yksinkertaisten ongelmien, yksinkertaisen koodin kanssa tai kun aloitat tyhjästä. Kun siirryt monimutkaisempiin jo olemassa oleviin projekteihin, ne ovat vähemmän luotettavia - ja kehittäjät lisäävät luotettavuutta dokumentoimalla, miten heidän koodinsa toimii ja on järjestetty (.md-tiedostot), jonka avulla agentti voi rakentaa paremmin tietoon perustuvia tehtäväluetteloita. Monimutkainen koodi vaatii enemmän asiakirjoja ja lopulta dynaamisesti vain relevantin kontekstin hakemista näistä asiakirjoista. Monilla ihmisillä/yrityksillä on vahvoja dokumentoimattomia mielipiteitä oikeasta järjestyksestä/lähestymistavasta/työkaluista projektin hoitamiseksi, ja tarvitsemme lisää lähestymistapoja tämän dokumentointiin etukäteen ja lennossa. Toinen syy, miksi koodaus ja verkkopohjaiset tutkimusagentit toimivat hyvin, on se, että ne kaikki käyttävät samoja työkaluja, joten sinun ei tarvitse "oppia" käyttämään näitä työkaluja (lisää tästä seuraavaksi).

Tehtävien suorittaminen: Tehtävät ovat yleensä API-kutsuja (edellyttävät todentamista ja ymmärrystä API:n käytöstä ja taustalla olevasta tietorakenteesta - joka voi olla ainutlaatuinen, kuten CRM:ssä tai DB:ssä, jossa on mukautettuja taulukoita/sarakkeita), LLM-päättelyä (esim. yhteenveto), yhdistelmää ja jopa työnkulkuagentteja*. Tutkimusagentti on oikeastaan vain verkkohaku ja yhteenveto silmukassa. koodausagentit ovat CRUD koodipohjassasi ja ehkä verkkohaku oppimisen API:ille. Todennus ja perussovellusliittymä tuntuvat ratkaistuilta (MCP:t sopivat tähän), mutta haluaisin nähdä enemmän työkalukohtaisesta kontekstista (kysy käyttäjältä, mutta myös analysoi ensimmäisen yhteyden yhteydessä, kaivaudu olemassa oleviin tietoihin ymmärtääksesi, miten työkalua käytetään, miten tiedot on jäsennelty, mihin skenaarioihin/projekteihin käytämme työkalua.), virheet/pohdinta/palaute on muutettava organisoiduiksi opeiksi, jotka palautetaan kontekstissa tarvittaessa. Samoja työkaluja voidaan käyttää eri tarkoituksiin ja eri tavoin organisaatioiden välillä, ja meidän on tallennettava/dokumentoitava tämä jotenkin, jotta voimme suorittaa tehtävät hyvin.

Konteksti: Kuvittele olevasi uusi työntekijä yrityksessä. Opit paljon perehdytyksen aikana (ja mitä parempi perehdytys, sitä tehokkaampi olet portista), ja sitten on työssä oppimista, joka jakautuu oppimiseen organisaation kokemuksesta ("näin me teemme asioita") ja omasta kokemuksesta oppimiseen - aiemmin hallitsevampaa suurissa organisaatioissa. Kontekstinhallinta on samanlaista. On olemassa kontekstikerroksia, kuten Meta (käyttäjä/yritys), projekti-/osastokohtainen, tehtäväkohtainen, työkalukohtainen jne. Olemme kehittyneet yksinkertaisista järjestelmäkehotteista hybridi-RAG-strategioihin (vektori, avainsana, kaavio), mutta datan/kontekstin lisäksi tarvitsemme ohjeita siitä, milloin ja miten konteksti haetaan, mistä näemme nykypäivän varhaisia versioita - mutta paljon parantamisen varaa. Tämä ei ole vain tekninen ongelma, vaan myös liiketoiminnallinen ongelma - koska sinun on periaatteessa luotava perehdytysasiakirja, joka kattaa kaikki odottamasi skenaariot. Projektien monimutkaistuessa kontekstin oikea karsiminen vaatii enemmän harkintaa, jotta vain olennainen tieto sisällytetään promptiin, samalla kun epäolennainen konteksti minimoidaan.

Pohdinta: meillä on agenttien seurantatyökalut, jotka kattavat LLM/API-kustannukset, havainnoinnin, mutta onnistumisen/epäonnistumisen määrittäminen on haaste - yksi alue, jolla koodausagenteilla on etulyöntiasema muihin, on deterministinen tapa havaita epäonnistumiset (koodin testaamisen kautta). Monissa muissa agenttitehtävissä selvitämme edelleen oikeaa tapaa kerätä ihmisen panosta tulevan tuotoksen parantamiseksi. AFAIK, pohdinta on nykyään ihmis-in-the-loop, jossa palaute syötetään suurelta osin ihmiskehittäjille agentin parantamiseksi, mutta avaus tapahtuu, kun keksimme, miten reflektio voidaan muuttaa itsensä kehittämiseksi - jossa agentti ottaa oivalluksia tehtäväluettelon luomisen ja suorittamisen epäonnistumisista tehdäkseen sen paremmin ensi kerralla. Pohjimmiltaan pohdinnan on muututtava hyvin organisoiduksi kontekstiksi, joka voidaan vetää kehotteiksi silloin ja vain silloin, kun se on tarkoituksenmukaista. tämä kehittyy agentin hienosäätöosiksi ja sitten agenttiseksi RL-ympäristöksi - tuntuu vielä melko aikaiselta tässä

*Aiemmin mainitsin tehtävien luovuttamisen työnkulkuagenteille, mikä alkaa olla järkevää, kun agenttisi hyötyisi siitä, että työkaluina ei ole työnkulkuagentteja (verrattuna siihen, että joka kerta selvität tunnetun tehtäväluettelon) tai kun järjestelmäsi on tarpeeksi monimutkainen, jotta erikoistuneet agentit erikoistuneella kontekstilla ja työkaluilla toimivat paremmin. Tai jos hyödynnät muiden PPL:ien rakentamia agentteja (yksi malli, jonka olen alkanut nähdä täällä, on luonnollisen kielen API-päätepisteet agenttien yhteistyön helpottamiseksi).

jos meillä olisi nykypäivän mallin laatu äärettömällä sisältöikkunalla (ei laadun heikkenemistä), äärettömällä laskennalla, äärettömällä tallennustilalla, selaimen käytöllä ja maksutavalla, yksi LLM-silmukka riittää luultavasti saamaan paljon aikaan yllä olevan turhan kohdan (mikään ei ole ääretöntä) pointti on, että agenttien orkestrointi on suurelta osin rajoitusten hallintaa suunnittelemalla tapoja purkaa työtä LLM:stä rakenteen ja koodin avulla.

Tuotannossa olevia agentteja on eri makuisia: sisäisinä työkaluina, erillisinä tuotteina, jotka yhdistävät erilaisia työkaluja, ja leivottuna ydintyökalun ominaisuutena. ne voivat olla yleisiä tai erikoistuneita. Chat-, ääni- ja taustaagentit näyttävät olevan yleisin käyttöliittymä agenttivirtojen käynnistämiseen.

Mitä muuta minulta puuttuu?