Na pagaliau! Pirmas rimtesnis blynas – labai sudėtinga DI agentų bendravimo sistema, pritaikyta pajūrio regionui. Dar beveik be duomenų, tad labai kvaila 🙂
Man pusei metų eksperimentavimo su šiuo transformeriu. Apie verslą daug negalvoju, smugu kurti būtent tech, kai už tave kodą rašo Cursor, o konsultuoja visos neuronkės, kurioms dar likę kreditų
Ankstesnis darbas buvo Kietųjų įgūdžių diagrama
Šis tekstas sau pačiam, skaitau ir taip viskas pažįstama
Google ADK ir „Startup Technical Guide: AI Agents“: kaip Google iš naujo apibrėžia AI agentų kūrimą
Kai „Google Cloud“ pristato „Startup Technical Guide: AI Agents“ – tai ne tik eilinė dokumentacija, bet ir ženklinis įvykis. Kodėl? Todėl, kad aplink AI agentus dabar didelis ažiotažas, bet iki šiol nebuvo vientisos techninės gairės. Šią vasarą jau buvau pasinėręs į temą ir net parašiau „Habr“ straipsnį apie „Google ADK“ ir AI agento integravimą į individualų UI. Tačiau naujas „Google“ vadovas yra visiškai kitokio lygio: 64 puslapiai, apimantys kelią nuo idėjos iki gamybos (production).
Kuo gi jis skiriasi nuo kitų medžiagų? Pirma, mastu ir gyliu: „Google“ akivaizdžiai įdėjo savo komandų patirtį, kad aprašytų viską – nuo architektūros iki AgentOps (agentų operacijų ir priežiūros gamyboje). Antra, praktinio patikimumo akcentavimu: viduje žingsnis po žingsnio aprašyta, kaip prototipą paversti tvaria sistema su stebėjimu, testais ir saugumu. Trečia, dėmesiu „Google Cloud“ ekosistemai: gairės rodo, kaip naudoti Vertex AI, modelį Gemini, Agent Development Kit (ADK) ir kitus įrankius. Tačiau, kas vertinga, principai, išdėstyti gairėse, pritaikomi plačiau – jie bus naudingi bet kuriam LLM agentų kūrėjui, net jei naudojate alternatyvias platformas.
Taigi, perskaitęs visą dokumentą, sau užsirašiau penkias pagrindines įžvalgas.
1 įžvalga: AI agentai nėra pokalbių robotai – tai nauja DI darbo paradigma
Svarbiausia, ką gairės bando perteikti nuo pat pradžių: „paklausei – gavai atsakymą“ požiūris eina į praeitį. AI agentai – tai kitas žingsnis, kurio metu modeliui duodame sudėtingą tikslą, o ne konkretų klausimą. Agentas pats planuoja ir atlieka daugiapakopes užduotis, pasitelkdamas įrankius ir išorinius duomenis. Thomas Kurian (Google Cloud generalinis direktorius) taikliai pavadino agentų darbo eigą „naujuoju frontu“, kuriame DI galės, pavyzdžiui, „suplanuoti produkto paleidimą arba išspręsti problemą tiekimo grandinėje“, atliekant visus būtinus žingsnius. Tai esminis skirtumas nuo įprastų siauros paskirties robotų: agentas – tai lyg jūsų autonominis pagalbininkas, gebantis samprotauti, priimti sprendimus ir veikti.
Man, kaip kūrėjui, šis akcentas svarbus. Dažnai nusižengiame vadindami „AI agentu“ bet kokį scenarijų su GPT, prijungtu prie kelių API. Tačiau „Google“ kelia aukštesnę kartelę: agentas turi gebėti adaptyviai pasiekti tikslus, o ne tiesiog atsakinėti pagal šabloną. Ir tai tikrai paradigmos pokytis. Gairėse tiesiogiai sakoma, kad AI agentų atsiradimas yra „lūžio momentas programinės įrangos inžinerijoje“, leidžiantis automatizuoti anksčiau neįmanomas užduotis. Sąžiningai, aš tai pajutau net per savo eksperimentus: kai pirmą kartą surinkau paprasčiausią agentą, kuris pats ieško „Google“, skaičiuoja ir užrašo rezultatus – pasijutau darantis kažką daugiau nei pokalbių robotą. Dabar jau turime oficialų patvirtinimą: agentai – tai nauja sistemų klasė, reikalaujanti naujo mąstymo.
2 įžvalga: Vieno LLM nepakanka – reikalingas „pilnas stiklas“ infrastruktūros ir įrankių
„Google“ pabrėžia: neįmanoma sukurti rimto AI agento, tiesiog pasirinkus didelį kalbos modelį (LLM). Reikalinga keičiama infrastruktūra, duomenų integracija ir patikrinta architektūra. Gairėse net yra frazė, kad gamybinės kokybės agento kūrimui reikia kur kas daugiau nei LLM pasirinkimas. Ir toliau išvardijami pagrindiniai agento komponentai: modelis, įrankiai (tools) veiksmams atlikti, orkestravimo logika (pvz., ReAct šablonas), atmintis kontekstui, sesijų saugojimo mechanizmas ir t. t.
Skaitydamas šį skyrių, keletą kartų linktelėjau galva. Iš tiesų, praktikoje pirmieji bandymai sukurti agentą dažnai atrodo taip: „paimsime GPT-4, prijungsime API iškvietimus – paruošta“. Bet be tvirtos architektūros viskas greitai sugenda. Pavyzdžiui, nėra atminties – agentas pamiršta kontekstą, nėra normalios orkestracijos – pasimeta sudėtingose užduočių grandinėse. Gairėse tai sprendžiama: „Google ADK“ suteikia struktūrą, kurioje yra konteksto valdymas, įrankių registracija, agento konteinerizavimas diegimui, įmontuoti testavimo ir stebėjimo mechanizmai. Paprasčiau tariant, jie siūlo karkasą, kuris pašalina dalį galvos skausmo.
Atskirai man patiko akcentas „Automate workflows, not just conversations“ (liet. „Automatizuokite darbo eigas, ne tik pokalbius“). Mažam startuoliui, norint išlikti, nepakanka sukurti kalbančią galvą – reikia automatizuoti realius verslo procesus. Tam agentas turi įsilieti į infrastruktūrą: kreiptis į jūsų API, dirbti su jūsų duomenimis. Gairės pataria kurti „apsaugotą produktą“, kuriame agentas jungiasi prie vidinių sistemų, taip sukuriant konkurencinį pranašumą (juk konkurentai negalės taip lengvai pasiekti jūsų duomenų). Aš, kaip technikos direktorius, matau tai kaip išmintingą patarimą: pririškite agentą prie to, kas daro jūsų paslaugą unikalią – ir tada tai nebus žaislas, o dalis jūsų „moat“ (apsauginio griovio nuo konkurentų).
Išvada čia tokia: LLM – tai agento smegenys, bet kad šios smegenys veiktų realiame pasaulyje, joms reikia „organizmo“. Infrastruktūra, įrankiai, sąveikos schemos – be jų jūsų agentas liks tik demonstracija arba palūš nuo pirmosios apkrovos.
3 įžvalga: Įtvirtinimas (Grounding): mokome agentą remtis žiniomis, o ne fantazuoti
Viena mėgstamiausių LLM kūrėjų temų – kaip kovoti su modelio haliucinacijomis ir jo ribotomis žiniomis apie pasaulį. „Google“ atsako: Įtvirtinimas (Grounding). Gairės aiškiai skiria sąvokas: „Fine-tuning – tai ne grounding“. Modelio papildomas apmokymas užduočiai neužtikrina atsakymų aktualumo ir faktinio tikslumo. O štai grounding kaip tik „prijungia modelį prie aktualių patikimų duomenų šaltinių, kad jo atsakymai būtų faktiškai tikslūs“. Paprasčiau tariant, mes pririšame agentą prie tiesos šaltinių.
Praktikoje tai reiškia Retrieval-Augmented Generation (RAG) – kai prieš generuojant atsakymą, agentas atlieka paieškos užklausą arba ieško jūsų žinių bazėje, kad surastų atitinkamus faktus. Gairėse RAG vadinamas pirmuoju žingsniu link agento „įžeminimo“ į realybės dirvą. Toliau „Google“ aprašo evoliuciją: nuo įprasto RAG – iki GraphRAG (duomenų ryšių apskaita per žinių grafą) ir net iki Agentic RAG, kur agentas pats aktyviai gauna informaciją, o ne pasyviai gauna kontekstą. „Agentic RAG“ pavyzdys – integracija su „Google Search“, kai modelis moka ne tik skaityti rezultatus, bet ir nuspręsti, kada reikalingas paieškos žingsnis, ir kaip naudoti tai, kas rasta.
Mane tai sužavėjo: iš esmės, „Google“ siekia, kad agentas būtų proaktyvus tyrinėtojas. Jis aklai nepasitiki savo vidiniu pasauliu, o tikrina hipotezes, tikslina duomenis. Prisimenamas mūsų patyrimas: kažkada paleidome agentą techninei pagalbai, ir be RAG jis pradėjo išgalvoti atsakymus, priversdamas komandą griebtis už galvos. Išvada: net ir pats protingiausias LLM turi būti „įžemintas“. Gairės man, kaip kūrėjui, suteikia pasitikėjimo, kad geriausias sprendimas yra LLM + išorinis žinių indeksas junginys. Beje, „Google“ jau teikia tam skirtus įrankius (tame pačiame „Vertex AI“ yra API, skirta patikrinti, kiek atsakymas pagrįstas faktais – tekste minimas Check Grounding API).
Atskirai gairės primena apie multimodiškumą (multimodality) – palaikymą ne tik tekstui, bet ir paveikslėliams, lentelėms, garsui. Pavyzdžiui, „Gemini“ (naujas „Google“ modelis) – multimodiškas, o „Agentspace“ (jokio kodo (no-code) platformoje agentams) deklaruojama „teksto, vaizdų, diagramų, vaizdo sintezė“. Tai taip pat yra „grounding“ dalis: agentas gali priimti skirtingus duomenų tipus iš realaus pasaulio. Mano įžvalga čia: būsimi agentai semsis informacijos iš visur – iš dokumentų, iš interneto, iš jutiklių – kad tik nedirbtų savo žinių vakuume.
4 įžvalga: AgentOps – testavimas ir stebėjimas vietoje „gal pavyks“
Didžiausią įspūdį man paliko skyrius apie AgentOps – iš esmės MLOps, skirtas agentams. „Google“ atvirai sako: dauguma agentų gamyboje žlunga ne dėl blogų modelių, o todėl, kad niekas neatlieka „nuobodaus“ operacinio darbo. Gairės siūlo keturių sluoksnių požiūrį agento vertinimui: komponentų testai (kiekvienas įrankis ir funkcija tikrinami atskirai), mąstymo trajektorijų patikrinimas (ką agentas daro kiekviename žingsnyje), rezultatų patikrinimas (kiek galutiniai atsakymai yra teisingi) ir sisteminis stebėjimas gamyboje. Prisipažįstu, pajutau lengvą sąžinės priekaištą – juk dažnai apsiribodavome keliais rankiniais paleidimais ir manėme, kad „lyg ir veikia“.
Tačiau toks požiūris nepriimtinas, jei agentas yra produkto dalis. „Google“ tiesiogiai teigia: perėjimas nuo improvizuoto „vibe-testing“ prie sisteminės, automatizuotos ir atkartojamos procedūros – tai konkurencinis pranašumas. Frazė iš gairės: „sisteminės vertinimo sistemos priėmimas – ne tik geriausia praktika, bet ir konkurencinis pranašumas“ – mano nuomone, turėtų kabėti virš kiekvieno, kuriančio AI funkciją startuolyje, stalo.
Ką tai reiškia praktiškai? Man, kaip inžinieriui – peržiūrėti agento kūrimo procesą. Pridėti daugiau mažų testų: tikrinti, ar teisingai parseriuojamas kontekstas, ar teisingai iškviečiamos funkcijos, ar kas nors nesugedo atnaujinus modelį. Instrumentuoti „chain of thought“ (minčių grandinę): gairės pataria registruoti kiekvieną agento veiksmą ir net automatiškai paleisti scenarijus, fiksuojant, kur agentas nukrypo nuo kelio. Tai, beje, įdiegta ADK: ten yra įmontuotas žingsnių sekimas (tracing) ir atsakymo kokybės vertinimo mechanizmas (pavyzdžiui, atitikimas faktams).
Dar viena įžvalga – „Google“ jau įdiegė dalį šių praktikų į Agent Starter Pack: tai „Terraform“ šablonų, CI/CD konfigūracijų ir scenarijų rinkinys, kuris iš karto apima agentų stebėjimą, testavimą ir diegimą pagal geriausius standartus. Iš esmės, jie siūlo startuoliams ne išradinėti dviračio, o imti paruoštą karkasą, kuriame kiekvieno naujo agento kūrimo metu bus atliekami testai, vertinami atsakymai, tikrinamos apsaugos taisyklės. „Priešingybė „move fast and break things“ (judėti greitai ir laužyti daiktus), kaip pajuokavo „Reddit“ – ir tai tikrai taip. Tačiau, atvirai sakau, po bendravimo su dideliais įmonių klientais suprantu: geriau įdėti patikrinimus ir „smėlio dėžes“ nuo pat pradžių, nei vėliau aiškinti, kodėl jūsų AI robotas staiga kažką sulaužė klientui.
5 įžvalga: Saugumas ir etika: dabar privalomi reikalavimai, o ne pasirinkimas
Gairės nedviprasmiškai leidžia suprasti: kurdamas galingą AI agentą, automatiškai prisiimi atsakomybę už jo saugumą, duomenų apsaugą ir etinį elgesį. „Kuriant agentą, jūs prisiimate neatšaukiamą atsakomybę padaryti jį saugų, apsaugotą ir etiškai suderintą“ – rašoma tekste. Tai ne gražūs žodžiai: toliau detaliai aprašoma, kokios būna rizikos (modelis gali išduoti toksišką turinį, gali nutekėti konfidenciali informacija, agentas gali būti nulaužtas per prompt-injection ir t. t.) ir kokių reikia priemonių.
Skaitau tai ir galvoju: juk tiesa, mes iš esmės paleidžiame autonominę sistemą į išorinę aplinką. Prisiminkite, kiek buvo istorijų, kai kažkas bandė „išlaužti“ ChatGPT (angl. jailbreak), arba kaip robotai pradėjo elgtis netinkamai. Gamybiniame agente tokie dalykai nepriimtini. „Google“ siūlo „gynybos gyliu“ (defense-in-depth) požiūrį: daugiapakopė apsauga. Pirma, „dizainas su tvorelėmis“ – jau agento kūrimo etape įdiegti konteksto filtrus, įrankių apribojimus (minimalių privilegijų principas) ir pan. Antra, infrastruktūros apsauga: izoliuoti agento vykdymą, naudoti IAM vaidmenis, kad net ir kompromituotas agentas negalėtų pakenkti už savo „smėlio dėžės“ ribų. Trečia, stebėjimas ir auditas: registruoti kiekvieną veiksmą (ADK tam yra išsamus sekimas), saugoti žurnalus „BigQuery“, nustatyti įspėjimus (alerts). Ir galiausiai, įdiegti apsaugines užtvaras (guardrails): automatinius gaunamų promptų ir siunčiamų atsakymų patikrinimus dėl nepageidaujamo turinio ar bandymų atakuoti.
Mane sužavėjo, kad net šiuos patikrinimus „Google“ siūlo automatizuoti. Pavyzdžiui, jie mini, kad Agent Starter Pack integruoja injection atakų patikrinimą tiesiai į CI/CD: kiekvieną kartą, pakeitus agento kodą, atliekami testai, ar nėra pažeidžiamumų ar naujų saugumo „skylių“. Toks požiūris naujų agentų sistemų kūrėjams dar naujas. Tačiau jaučiamas „Google“ siekis nustatyti standartą: „saugumas pagal dizainą“ (secure by design) net ir eksperimentinėms AI funkcijoms. Kaip inžinierius, aš džiaugiuosi šia tendencija. Tai reiškia, kad bus mažiau atvejų, kai, vedini geriausių ketinimų, paleidžiame AI paslaugą, o ji kompromituoja vartotojų duomenis ar padaro etinių klaidų.
Atskirai pažymėsiu: gairės siunčia prie „Google Secure AI Framework (SAIF)“ – matyt, vidinio saugios AI kūrimo taisyklių rinkinio. Tai užsimena, kad didieji žaidėjai jau formuoja geriausias praktikas, o mūsų pareiga – jomis sekti. Jei anksčiau galėjai pasakyti „ai, paleiskime agentą, gal nieko baisaus“, tai dabar toks nerūpestingumas nepriimtinas. Saugumas, privatumas, atitikimas normoms – turi būti AI agento kūrimo kontroliniame sąraše nuo pat pradžių.
Išvada
Po atidaus gairės perskaitymo man susidarė įspūdis, kad rankose laikau bandymą fiksuoti naują pramonės standartą. „Google“ atliko didelį darbą, siekdama struktūrizuoti pastarųjų metų patirtį: nuo pirmųjų agentų prototipų – iki brandžių, valdomų sistemų. Jų žinią perskaičiau taip: „Kelias nuo prototipo iki gamybos – tai disciplinuota inžinerija“. Spontaniniai eksperimentai geri demonstracijoms, bet ateitis priklauso metodiškam požiūriui: patikrinta architektūra, nuolatinis ryšys su duomenimis (grounding), automatizuotas kiekvieno „minties žingsnio“ testavimas ir kruopštus rūpinimasis saugumu.
Kodėl ši gairė yra daugiau nei dokumentacija? Nes ji nustato bendrą kalbą ir gaires mums visiems, kurie kuriame AI agentus. Prisiminkite, kaip kažkada atsirado terminas DevOps ir praktikų rinkinys, be kurių dabar neįmanomas rimtų programų kūrimas? Panašu, kad stebime analogiškos koncepcijos, skirtos AI agentams, gimimą – tebūnie tai AgentOps. Ir labai tikėtina, kad po metų kitų klausimai iš gairės („Ar patikrinai savo agentą dėl haliucinacijų? Ar registruoji jo sprendimus?“) taps įprasta kodo peržiūros (code review) dalimi.
Asmeniškai aš nusprendžiau naudoti šias gaires kaip kontrolinį sąrašą ir geriausių praktikų šaltinį. Kai kur jos patvirtino mano spėjimus (pavyzdžiui, apie RAG ir atminties būtinybę), o kai kur apsaugojo nuo nereikalingų klaidų (pavyzdžiui, iš karto įdiegus CI agentui ir apribojus įrankių teises). Mūsų visų laukia dar daug darbo tobulinant šias naujas „normas“. Bet puiku, kad atsirado atskaitos taškas iš pačios „Google“. Disciplinuotas požiūris į agentus gali tapti tuo pranašumu, kuris leis startuoliams „iššauti“, o vartotojams – pasitikėti AI sprendimais. Naujas standartas nustatytas – toliau viskas priklauso nuo mūsų.
- Pradedančiųjų įmonių techninis vadovas: dirbtinio intelekto agentų kūrimas naudojant „Google Cloud“ https://services.google.com/fh/files/misc/startup_technical_guide_ai_agents_final.pdf
- Kaip integruoti „Google ADK“ su pasirinktine sąsaja: nuoseklus vadovas su pavyzdžiais https://habr.com/en/articles/933804/