Aģenti mūsdienās ir vismodernākā AI tēma, un tas ir pamatoti. AI aģenti darbojas savu lietotāju vārdā, autonomi veicot tādus uzdevumus kā pirkumi tiešsaistē, programmatūras izveide, biznesa tendenču izpēte vai ceļojumu rezervēšana. Izņemot ģeneratīvo AI no tērzēšanas saskarnes smilškastes un ļaujot tai iedarboties tieši uz pasauli, aģents AI ir lēciens uz priekšu AI jaudas un lietderības ziņā. Generatīvais AI izņemšana no tērzēšanas saskarnes aizsargātās smilškastes un ļaujot tai darboties tieši pasaulē ir lēciens uz priekšu AI jaudas un lietderības jomā.
Aģentiskais AI ir virzījies ļoti ātri: piemēram, viens no mūsdienu aģentu pamatelementiem, modeļa konteksta protokols (MCP), ir tikai gadu vecs! Tāpat kā jebkurā strauji mainīgā jomā, ir daudz konkurējošu definīciju, karstu pieņēmumu un maldinošu viedokļu.
Lai samazinātu troksni, es vēlos aprakstīt aģentu AI sistēmas galvenās sastāvdaļas un to saderību: tas tiešām nav tik sarežģīti, kā varētu šķist. Cerams, ka, kad būsit pabeidzis lasīt šo ziņu, aģenti nešķitīs tik noslēpumaini.
Aģentiskā ekosistēma
Vārdam “aģents” ir daudz definīciju, taču man patīk nelielas atšķirības no britu programmētāja Saimona Vilisona minimālisma:
LLM aģents palaiž rīkus cilpā, lai sasniegtu mērķi.
Lietotājs piedāvā lielu valodas modeli (LLM) ar mērķi: Piemēram, rezervēt galdiņu restorānā, kas atrodas netālu no konkrēta teātra. Kopā ar mērķi modelis saņem tā rīcībā esošo rīku sarakstu, piemēram, restorānu atrašanās vietu datubāzi vai lietotāja ēdienu izvēli. Pēc tam modelis plāno, kā sasniegt mērķi, un izsauc vienu no instrumentiem, kas sniedz atbildi; Pēc tam modelis izsauc jaunu rīku. Ar atkārtojumiem aģents virzās uz mērķa sasniegšanu. Dažos gadījumos modeļa orķestrēšanas un plānošanas izvēles tiek papildinātas vai uzlabotas ar imperatīvu kodu.
Guess kāda veida infrastruktūra ir nepieciešama, lai īstenotu šo pieeju? Aģentūras sistēmai ir nepieciešami daži galvenie komponenti:
-
Veids, kā veidot aģentu. Izvietojot aģentu, nevēlaties, lai tas būtu jākodē no jauna. Ir vairākas aģentu izstrādes sistēmas.
-
Kaut kur uz palaist AI modeli. Pieredzējis AI izstrādātājs var lejupielādēt atvērtā svara LLM, taču, lai to izdarītu pareizi, ir nepieciešamas zināšanas. Tam ir nepieciešama arī dārga aparatūra, kas vidusmēra lietotājam būs slikti izmantota.
-
Kaut kur uz palaidiet aģenta kodu. Izmantojot izveidotos ietvarus, lietotājs izveido kodu aģenta objektam ar noteiktu funkciju kopu. Lielākā daļa šo funkciju ietver uzvedņu nosūtīšanu uz AI modeli, taču kodam kaut kur ir jāpalaiž. Praksē lielākā daļa aģentu darbosies mākonī, jo mēs vēlamies, lai tie turpinātu darboties arī tad, kad mūsu klēpjdatori ir aizvērti, un mēs vēlamies, lai tie palielinātos un lai veiktu savu darbu.
-
Mehānisms tulkošanai starp tekstu balstītu LLM un rīku zvani.
-
A īstermiņa atmiņa aģentu mijiedarbības satura izsekošanai.
-
A ilgtermiņa atmiņa lai izsekotu lietotāja preferences un radniecības sesijās.
-
Veids, kā izsekot sistēmas izpildi, lai novērtētu aģenta darbību.
Sīkāk aplūkosim katru no šiem komponentiem.
Aģenta veidošana
Lūgšana LLM paskaidrot, kā tas plāno veikt konkrētu uzdevumu, uzlabo tā veiktspēju šajā uzdevumā. Šis “domu ķēdes pamatojums” tagad ir visuresošs AI.
Analogs aģentu sistēmās ir modelis ReAct (spriešana + darbība), kurā aģentam rodas doma (“Es izmantošu kartes funkciju, lai atrastu tuvumā esošos restorānus”), veic darbību (izdod API izsaukumu uz kartes funkciju), pēc tam veic novērojumu (“Kinoteātra divos kvartālos ir divas picas un viens indiešu restorāns”).
ReAct nav vienīgais aģentu veidošanas veids, wager tas ir visveiksmīgāko aģentu sistēmu pamatā. Mūsdienās aģenti parasti ir cilpas pāri doma-darbība-novērošana secība.
Aģentam pieejamie rīki var ietvert vietējos rīkus un attālos rīkus, piemēram, datu bāzes, mikropakalpojumus un programmatūru kā pakalpojumu. Rīka specifikācijā ir ietverts dabiskās valodas skaidrojums par to, kā un kad tas tiek izmantots, un tā API izsaukumu sintakse.
Izstrādātājs var arī likt aģentam būtībā izveidot savus rīkus lidojuma laikā. Pieņemsim, ka rīks izgūst tabulu, kas saglabāta kā komatatdalīts teksts, un, lai izpildītu savu mērķi, aģentam tabula ir jākārto.
Tabulas šķirošana, atkārtoti nosūtot to caur LLM un izvērtējot rezultātus, būtu milzīga resursu izšķērdēšana, un pat netiek garantēts, ka tas dos pareizo rezultātu. Tā vietā izstrādātājs var vienkārši uzdot aģentam ģenerēt savu Python kodu, kad tas saskaras ar vienkāršu, wager atkārtotu uzdevumu. Šie koda fragmenti var darboties lokāli kopā ar aģentu vai īpašā drošā koda tulka rīkā.
Pieejamie rīki var sadalīt atbildību starp LLM un izstrādātāju. Kad aģentam pieejamie rīki ir norādīti, izstrādātājs var vienkārši norādīt aģentam, kādus rīkus vajadzības gadījumā izmantot. Vai arī izstrādātājs var norādīt, kuru rīku izmantot kāda veida datiem un pat kādus datu vienumus izmantot kā argumentus funkciju izsaukšanas laikā.
Līdzīgi izstrādātājs var vienkārši likt aģentam ģenerēt Python kodu, ja nepieciešams, lai automatizētu atkārtotus uzdevumus, vai arī norādīt, kuri algoritmi jāizmanto kādiem datu tipiem, un pat nodrošināt pseidokodu. Pieeja var atšķirties atkarībā no aģenta.
Izpildes laiks
Vēsturiski bija divi galvenie veidi, kā izolēt kodu, kas darbojas koplietotajos serveros: konteineru ievietošana, kas bija efektīva, taču piedāvāja zemāku drošību; un virtuālās mašīnas, kas bija drošas, taču tām bija lielas skaitļošanas izmaksas.
2018. gadā tika izvietots Amazon Net Providers (AWS) Lambda bezservera skaitļošanas pakalpojums Petardejauna paradigma servera izolācijā. Firecracker izveido “mikroVM” ar aparatūras izolāciju un saviem Linux kodoliem, wager ar samazinātu pieskaitāmo slodzi (tikai daži megabaiti) un palaišanas laiku (tikai dažas milisekundes). Zemās izmaksas nozīmē, ka katrai Lambda serverī izpildītajai funkcijai var būt savs microVM.
Tomēr, tā kā aģenta instantiancei ir nepieciešams izvietot LLM kopā ar atmiņas resursiem, lai izsekotu LLM ievades un izvades, katras funkcijas izolācijas modelis ir nepraktisks. Tā vietā, izmantojot sesiju izolāciju, katrai sesijai tiek piešķirts savs microVM. Kad sesija beidzas, LLM stāvokļa informācija tiek kopēta ilgtermiņa atmiņā un microVM tiek iznīcināta. Tas nodrošina drošu un efektīvu aģentu resursdatoru izvietošanu.
Rīku izsaukumi
Tāpat kā pastāv vairākas aģentu izveides izstrādes sistēmas, ir vairāki esošie standarti saziņai starp aģentiem un rīkiem, no kuriem populārākais pašlaik ir modeļa konteksta protokols (MCP).
MCP izveido savstarpēju savienojumu starp aģenta LLM un speciālu MCP serveri, kas izpilda rīku izsaukumus, kā arī izveido standarta formātu dažāda veida datu pārsūtīšanai uz priekšu un atpakaļ starp LLM un tā serveri.
Daudzas platformas pēc noklusējuma izmanto MCP, taču tās ir arī konfigurējamas, tāpēc laika gaitā tās atbalstīs pieaugošu protokolu kopu.
Tomēr dažreiz nepieciešamais rīks nav pieejams ar API. Šādos gadījumos vienīgais veids, kā izgūt datus vai veikt kādu darbību, ir kursora kustības un klikšķi uz vietnes. Lai to paveiktu, ir pieejami vairāki pakalpojumi datora lietošana. Tas padara jebkuru vietni par potenciālu aģentu rīku, kas atver gadu desmitiem ilgu saturu un vērtīgus pakalpojumus, kas vēl nav pieejami tieši caur API.
Pilnvaras
Ar aģentiem autorizācija darbojas divos virzienos. Pirmkārt, protams, lietotājiem ir nepieciešama autorizācija, lai palaistu viņu izveidotos aģentus. Taču, tā kā aģents darbojas lietotāja vārdā, tam parasti ir nepieciešama sava atļauja, lai piekļūtu tīkla resursiem.
Ir daži dažādi veidi, kā risināt autorizācijas problēmu. Viens no tiem ir piekļuves deleģēšanas algoritms, piemēram, OAuth, kas būtībā novirza autorizācijas procesu caur aģentu sistēmu. Lietotājs ievada pieteikšanās akreditācijas datus pakalpojumā OAuth, un aģentu sistēma izmanto OAuth, lai pieteiktos aizsargātajos resursos, taču aģenta sistēmai nekad nav tiešas piekļuves lietotāja parolēm.
Citā pieejā lietotājs piesakās drošā sesijā serverī, un serverim ir savi pieteikšanās akreditācijas dati aizsargātajos resursos. Atļaujas ļauj lietotājam izvēlēties no dažādām autorizācijas stratēģijām un algoritmiem šo stratēģiju ieviešanai.
Atmiņa un pēdas
Īslaicīga atmiņa
LLM ir nākamā vārda prognozēšanas dzinēji. Viņus tik pārsteidzoši daudzpusīgu padara tas, ka viņu prognozes ir balstītas uz garām vārdu virknēm, kuras viņi jau ir redzējuši kontekstā. Konteksts pats par sevi ir sava veida atmiņa. Guess tas nav vienīgais veids, kas nepieciešams aģentu sistēmai.
Pieņemsim, ka aģents mēģina rezervēt restorānu netālu no kinoteātra, un no kartes rīka tas ir izguvis pāris desmitus restorānu jūdzes rādiusā. Tā nevēlas izmest informāciju par visiem šiem restorāniem LLM kontekstā: visa šī svešā informācija var radīt postījumus ar nākamā vārda varbūtību.
Tā vietā tas var saglabāt pilnu sarakstu īstermiņa atmiņā un izgūt vienu vai divus ierakstus vienlaikus, pamatojoties, piemēram, uz lietotāja cenu un virtuves vēlmēm un teātra tuvumu. Ja neviens no šiem restorāniem neizdodas, aģents var atgriezties īstermiņa atmiņā, nevis veikt citu rīka izsaukumu.
Ilgtermiņa atmiņa
Aģentiem arī jāatceras viņu iepriekšējā mijiedarbība ar klientiem. Ja pagājušajā nedēļā es teicu restorāna rezervēšanas aģentei, kāda veida ēdieni man garšo, es nevēlos, lai tas būtu jāstāsta šonedēļ. Tas pats attiecas uz manu cenu toleranci, tādu gaisotni, kādu meklēju, un tā tālāk.
Ilgtermiņa atmiņa ļauj aģentam uzzināt, kas tam jāzina par iepriekšējām sarunām ar lietotāju. Tomēr aģenti paši nerada ilgtermiņa atmiņas. Tā vietā pēc sesijas pabeigšanas visa saruna pāriet uz atsevišķu AI modeli, kas rada jaunas ilgtermiņa atmiņas vai atjaunina esošās.
Atmiņas izveide var ietvert LLM apkopošanu un “sadalīšanu”, kurā dokumenti tiek sadalīti sadaļās, kas sagrupētas atbilstoši tēmai, lai turpmāko sesiju laikā būtu vieglāk izgūt. Pieejamās sistēmas ļauj lietotājam izvēlēties stratēģijas un algoritmus apkopošanai, sadalīšanai un citiem informācijas ieguves paņēmieniem.
Novērojamība
Aģenti ir jauna veida programmatūras sistēma, un tiem ir nepieciešami jauni veidi, kā domāt par viņu uzvedības novērošanu, uzraudzību un auditēšanu. Daži no mūsu uzdotajiem jautājumiem izskatīsies pazīstami: vai aģenti darbojas pietiekami ātri, cik tie maksā, cik daudz rīka zvanu viņi veic un vai lietotāji ir apmierināti. Taču radīsies arī jauni jautājumi, un mēs ne vienmēr varam paredzēt, kādi dati mums būs nepieciešami, lai uz tiem atbildētu.
Novērojamības un izsekošanas rīki var nodrošināt pilnīgu skatījumu par sesijas izpildi ar aģentu, soli pa solim sadalot, kuras darbības tika veiktas un kāpēc. Aģentu veidotājam šīs pēdas ir būtiskas, lai saprastu, cik labi aģenti darbojas, un nodrošināt datus, lai tie darbotos labāk.
Es ceru, ka šis skaidrojums ir pietiekami demistificējis aģentu AI, lai jūs būtu gatavs mēģināt izveidot savus aģentus!
