AutoPodAutoPod

AI aģentu novērojamība un kontrole: jaunas uzraudzības sistēmas izveide

•13 min lasīŔanai
Audio raksts
AI aģentu novērojamība un kontrole: jaunas uzraudzības sistēmas izveide
0:000:00
AI aģentu novērojamība un kontrole: jaunas uzraudzības sistēmas izveide

Ievads

Uzņēmumiem ievieÅ”ot arvien vairāk autonomu AI aÄ£entu – no sarunu asistentiem lÄ«dz uzdevumu automatizējoÅ”iem ā€œrobotiemā€ – rodas jauns izaicinājums: novērojamÄ«ba. Å ie aÄ£enti pieņem vairākus lēmumus, izsauc API, atjaunina kontekstu un pat darbojas lietotāju vārdā. Tomēr tradicionālie uzraudzÄ«bas rÄ«ki nodroÅ”ina tikai Å”auru skatÄ«jumu. Praksē komandas bieži paļaujas uz izkaisÄ«tiem žurnāliem vai informācijas paneļiem, kas nebija paredzēti aÄ£enta daudzpakāpju sprieÅ”anas fiksēŔanai. Nesenā Dynatrace aptaujā atklājās, ka puse no AI virzÄ«tiem projektiem apstājas pilotposmā, jo organizācijas ā€œnevar pārvaldÄ«t, validēt vai droÅ”i mērogotā€ savus aÄ£entus (www.itpro.com). LÄ«dzÄ«gi, Microsoft droŔības vadÄ«tāji brÄ«dina, ka mēs ā€œnevaram aizsargāt to, ko neredzamā€ – uzsverot, ka AI aÄ£entiem ir nepiecieÅ”ama ā€œnovērojamÄ«bas kontroles plakneā€, pieaugot to adopcijai (www.itpro.com) (www.itpro.com). Å ajā rakstā mēs aplÅ«kojam uzraudzÄ«bas nepilnÄ«bas autonomiem un pusautonomiem aÄ£entiem (Ä«paÅ”i attiecÄ«bā uz rÄ«ku lietoÅ”anu, atmiņu un lēmumu pieņemÅ”anas ceļiem). Pēc tam mēs piedāvājam specializētu novērojamÄ«bas un kontroles platformu, kas fiksē pilnÄ«gas izsekoÅ”anas, nodroÅ”ina politiku izpildi, simulē darbplÅ«smas un var atsaukt nedroÅ”as darbÄ«bas. Mēs salÄ«dzinām Å”o pieeju ar tradicionālajiem APM (lietojumprogrammu veiktspējas uzraudzÄ«bas) rÄ«kiem, izskaidrojam, kāpēc aÄ£entam specifiska telemetrija ir kritiski svarÄ«ga, un izklāstām cenu/integrācijas modeli (piemēram, maksājumus par aÄ£enta minÅ«ti ar PagerDuty/Jira integrācijām).

AI aģentu uzraudzības nepilnības

AI aÄ£enti nav tikai vienkārÅ”i API izsaukumi; tie ir daudzpakāpju darbplÅ«smas, kas plāno, iegÅ«st informāciju, izsauc rÄ«kus un sintezē rezultātus neskaidrÄ«bas apstākļos (www.stackai.com). Å Ä« sarežģītÄ«ba rada aklos punktus parastajai uzraudzÄ«bai:

  • Fragmentēta telemetrija: Vairumā vides telemetrija ir nodalÄ«ta. Viena sistēma reÄ£istrē gala punkta notikumus, cita rāda tÄ«kla trafiku, treŔā satur autentifikācijas datus. TechRadar atzÄ«mē, ka ā€œlielākā daļa AI aÄ£entu paļaujas uz tām paŔām fragmentētajām telemetrijas sistēmām, ar kurām analÄ«tiÄ·i ir cÄ«nÄ«juÅ”ies gadiem ilgiā€ (www.techradar.com). NesalÄ«dzinot Å”os signālus, aÄ£entam trÅ«kst konteksta, lai pareizi spriestu. Piemēram, AI var aizdomāties par konta kompromitēŔanu tikai tad, ja tas redz gan neparastu pieteikÅ”anos (no žurnāliem), gan aizdomÄ«gu tÄ«kla modeli – bet, ja Å”ie signāli atrodas dažādos rÄ«kos, aÄ£ents ā€œvienkārÅ”i nezina pietiekami daudzā€ (www.techradar.com) (www.techradar.com). ÄŖsumā, fragmentēti dati rada redzamÄ«bas trÅ«kumu: aÄ£enti rÄ«kojas, pamatojoties uz nepilnÄ«gu informāciju, kas noved pie klusām kļūdām (nepareizām darbÄ«bām, kas paliek neatklātas).

  • Aklie punkti rÄ«ku izsaukumos: AÄ£enti bieži izsauc ārējos rÄ«kus vai API (piemēram, datubāzes, zināŔanu bāzes, tÄ«mekļa pakalpojumus). Tradicionālā uzraudzÄ«ba varētu reÄ£istrēt tikai to, ka noticis HTTP pieprasÄ«jums, taču aÄ£entiem pielāgotai novērojamÄ«bai ir jāreÄ£istrē kurÅ” rÄ«ks tika izvēlēts un kāpēc. NovērojamÄ«bas platformai ir jāfiksē precÄ«zs pieprasÄ«jums vai konteksts, kas noveda pie Ŕīs rÄ«ka izvēles, nodotie argumenti un pilnÄ«ga izvade vai kļūdas atbilde (www.braintrust.dev). Bez tā aÄ£ents varētu ievadÄ«t nepareizus parametrus vai nepareizi interpretēt rÄ«ka atbildi, un problēma paliktu slēpta. Piemēram, Braintrust novērojamÄ«bas rokasgrāmatā uzsvērts, ka katrs rÄ«ka izsaukums ir jāizseko ar tā ievadi un izvadi, lai inženieri varētu ā€œatklāt halucinētus parametrus, trÅ«kstoÅ”os laukus vai nepareizu formatējumuā€ (www.braintrust.dev).

  • Nepārredzamas atmiņas operācijas: Daudzi aÄ£enti izmanto atmiņas vai datu iegūŔanas sistēmas (piemēram, lietotāja profilu, RAG zināŔanu krātuvi). Å is dinamiskais konteksts var izraisÄ«t kļūdas, kuras nav iespējams noteikt bez reÄ£istrēŔanas, ā€œko aÄ£ents lasa un rakstaā€ (www.braintrust.dev). Piemēram, ja aÄ£ents iegÅ«st novecojuÅ”u atmiņas ierakstu vai nepareiza lietotāja datus, atbilde var klusi kļūt nepareiza. NovērojamÄ«bai ir jāreÄ£istrē iegūŔanas vaicājumi, atgrieztie vienumi, atbilstÄ«bas rādÄ«tāji un aktualitātes metadati, lai nepareizu izvadi varētu izsekot lÄ«dz novecojuÅ”ai vai nepareizi mērķētai atmiņas lasīŔanai (www.braintrust.dev). LÄ«dzÄ«gi, katrai atmiņas rakstīŔanas darbÄ«bai ir jābÅ«t reÄ£istrētai (kas tika saglabāts, ar kādu atslēgu), lai atklātu kumulatÄ«vas kļūdas vai datu noplÅ«des (piemēram, viena lietotāja informācija parādās cita sesijā) (www.braintrust.dev).

  • Neredzamas lēmumu trajektorijas: AtŔķirÄ«bā no tÄ«mekļa pieprasÄ«juma ar skaidru ā€œievadi kodu, saņem atbildiā€ plÅ«smu, aÄ£enti parasti izpilda plāno-darbojies-novēro ciklu. Tie Ä£enerē plānu, veic darbÄ«bu (piemēram, ā€œmeklēt zināŔanu bāzÄ“ā€), novēro rezultātu un pēc tam nolemj pārplānot vai turpināt. VienkārÅ”i žurnāli nevar atklāt Å”o zarojoÅ”o ceļu. NovērojamÄ«ba prasa katra soļa fiksēŔanu secÄ«gi, ar aÄ£enta ā€œiemesluā€ katrai darbÄ«bai. Bez tā mēs varētu redzēt tikai galÄ«go rezultātu un domāt, ka viss ir kārtÄ«bā – pat ja aÄ£ents pusceļā novirzÄ«jās no uzdevuma vai iestrēga. Piemēram, Braintrust izceļ ā€œplāna novirziā€ (aÄ£ents klusi maina mērÄ·us) un ā€œbezgalÄ«gas cilpasā€ kā kļūdu veidus, ko var atklāt tikai soļu lÄ«meņa izsekoÅ”ana (www.braintrust.dev). Pareiza izsekoÅ”ana reÄ£istrē katru apakÅ”-aÄ£enta izsaukumu, zarojoÅ”o lēmumu un cilpas ilgumu, skaidri parādot, vai aÄ£ents atbildēja uz nepareizu jautājumu vai atkārtoja soļus bez progresa.

  • Klusas kvalitātes kļūmes: Daudzas aÄ£enta kļūmes neizraisa HTTP kļūdas vai avārijas. Tā vietā aÄ£ents var halucinēt datus, pārkāpt lietotāja norādÄ«jumus vai novirzÄ«ties no politikas. Parastie monitori (piemēram, Datadog vai New Relic) pārbauda tikai latentumu vai kļūdu rādÄ«tājus (www.techradar.com)), tāpēc sistēma ziņotu ā€œviss ir zaÄ¼Å”ā€, pat ja atbilde bÅ«tu faktiski nepareiza. StackAI skaidro, ka tradicionālie APM rÄ«ki pieņem deterministisku programmatÅ«ru – taču aÄ£enti pārkāpj Å”os noteikumus (www.stackai.com). Piemēram, uzvednes maiņa vai modeļa jaunināŔana varētu smalki pazemināt atbildes kvalitāti, neizraisot acÄ«mredzamu brÄ«dinājumu (www.stackai.com). Tāpēc novērojamÄ«bai ir jāiekļauj semantiskās pārbaudes: piemēram, halucināciju rādÄ«tāju vai politikas pārkāpumu incidentu izsekoÅ”ana. Rezumējot, parastie monitori parāda, ka aÄ£ents atbildēja laikā, bet tikai aÄ£entam specifiska telemetrija var parādÄ«t, vai atbilde bija pareiza, atbilstoÅ”a vai droÅ”a.

  • PārvaldÄ«bas un droŔības riski: AI aÄ£enti ievieÅ” jaunus atbilstÄ«bas izaicinājumus (uzvedņu injekcijas, privātuma noplÅ«des, neatļautas darbÄ«bas). Bez pielāgotas telemetrijas Å”ie riski ir neredzami. StackAI atzÄ«mē, ka novērojamÄ«ba un pārvaldÄ«ba saplÅ«st: ā€œjÅ«s nevarat nodroÅ”ināt politikas izpildi, ja to nevarat atklātā€ (www.stackai.com). Piemēram, ja klientu atbalsta režīmā esoÅ”s aÄ£ents sāktu nopludināt personas datus, tikai detalizēti izsekoÅ”anas žurnāli varētu atklāt pārkāpuma avotu. Tāpēc mÅ«su platformai ir jāuzrauga politikas pārkāpumi reāllaikā (piemēram, PII atzÄ«mēŔana izvades datos, neatļautu API izsaukumu bloķēŔana) un jānodroÅ”ina audita pēdas atbilstÄ«bai.

Rezumējot, esoŔās APM un žurnālu sistēmas vienkārÅ”i neuztver, kā AI aÄ£ents domā: domu ķēdi, zarojoÅ”o loÄ£iku un dinamisko kontekstu. Tas noved pie aklajiem punktiem rÄ«ku izsaukumos, atmiņas lietojumā un lēmumu pieņemÅ”anas trajektorijās. Neizlabojot Ŕīs nepilnÄ«bas, uzņēmumi riskē ar klusām aÄ£entu kļūmēm, droŔības pārkāpumiem un uzticÄ«bas zaudēŔanu.

AI aģentu novērojamības un kontroles platformas izveide

Lai aizpildÄ«tu Ŕīs nepilnÄ«bas, mēs piedāvājam specializētu AI aÄ£entu novērojamÄ«bas un kontroles platformu. Å is pakalpojums nodroÅ”inātu aÄ£entu instrumentāciju no sākuma lÄ«dz beigām, nodroÅ”inātu pārvaldÄ«bu un atļautu droÅ”u eksperimentēŔanu. Galvenās funkcijas ietver:

PilnÄ«ga izsekoÅ”ana un žurnālēŔana

Katrā aÄ£enta izpildē ir jārada izsekoÅ”anas ieraksts, kas reÄ£istrē pilnu izpildes grafiku. Iedvesmojoties no sadalÄ«to sistēmu prakses, katra aÄ£enta darbplÅ«sma ir izsekoÅ”anas ieraksts, un katra darbÄ«ba (LLM uzvedne, rÄ«ka izsaukums, atmiņas vaicājums, apakÅ”-aÄ£enta nodoÅ”ana) ir posms Å”ajā izsekoÅ”anas ierakstā (www.stackai.com) (www.braintrust.dev). Tas nozÄ«mē, ka inženieris var redzēt precÄ«zu secÄ«bu: kādu uzvedni aÄ£ents redzēja, kā tas sadalÄ«ja uzdevumu soļos un ko katrs rÄ«ks atgrieza. Piemēram, ja aÄ£ents vaicā dokumentu krātuvei, izsekoÅ”anas ieraksts reÄ£istrē vaicājumu un iegÅ«to saturu; ja tas pēc tam pārformulē vaicājumu, tas ir jauns posms. Sesijas identifikatori saista vairāku pagriezienu sarunas vai ilgstoÅ”us uzdevumus. Izmantojot standarta protokolus, piemēram, OpenTelemetry, Å”ie izsekoÅ”anas dati var ieplÅ«st esoÅ”ajos APM aizmugursistēmās. Kā norādÄ«ts vienā ceļvedÄ«, ā€œÅ”Ä«s primitÄ«vās funkcijas arvien labāk sader ar esoÅ”ajiem novērojamÄ«bas modeļiemā€ (www.stackai.com). Praksē tas ļauj korelēt aÄ£enta uzvedÄ«bu ar pamatā esoÅ”o infrastruktÅ«ru: CPU pīķus, tÄ«kla I/O vai datubāzes izsaukumus var aplÅ«kot kopā ar aÄ£enta sprieÅ”anas soļiem.

Tā vietā, lai reÄ£istrētu neapstrādātu tekstu brÄ«vā formā, platforma glabā strukturētus posmus. Piemēram, posms varētu reÄ£istrēt: RÄ«ks: emailSender, Ievade: JSON datu bloks, Izvade: panākumi vai kļūda, Latentums: 200ms. Ieliekot posmus (piemēram, rÄ«ku izsaukumus zem vecāka LLM izsaukuma), inženieri var iedziļināties, kur tika tērēts laiks vai kurÅ” solis izraisÄ«ja kļūmi. SvarÄ«gi ir tas, ka visas lietotāja ievades, sistēmas instrukcijas un atmiņas lasÄ«jumi kļūst par izsekoÅ”anas datiem. Å Ä« strukturētā žurnālēŔana aizstāj nogurdinoÅ”o ā€œprintēŔanas atkļūdoÅ”anuā€ un ļauj meklēt un filtrēt žurnālus (piemēram, parādÄ«t visus izpildes gadÄ«jumus, kuros aÄ£ents izmantoja rÄ«ku financialAPI).

Reāllaika politikas izpilde

Platforma darbojas arÄ« kā kontroles plakne pārvaldÄ«bai. Tā nepārtraukti pārbauda aÄ£enta telemetriju, salÄ«dzinot to ar droŔības un biznesa politikām. Piemēram, ja aÄ£ents mēģina izpildÄ«t neatļautu darbplÅ«smu (piemēram, piekļūt personāla algām, kad tam nevajadzētu), politikas dzinējs var nekavējoties iejaukties. Noteikumus var definēt uz izsekoÅ”anas datiem: piemēram, ā€œBrÄ«dināt, ja izvade satur kredÄ«tkartes numuru modeļusā€ vai ā€œBloķēt jebkuru datubāzes ierakstu ārpus klientu atbalsta darba laika no 9:00 lÄ«dz 17:00ā€. Tā kā ā€œjÅ«s nevarat nodroÅ”ināt politikas izpildi, ja to nevarat atklātā€ (www.stackai.com), Å”ie novērojamÄ«bas dati padara izpildi iespējamu. Praksē pārkāpumi var izraisÄ«t automatizētu ierobežoÅ”anu: platforma var apturēt aÄ£entu, eskalēt brÄ«dinājumu vai atsaukt visas tā veiktās izmaiņas. IebÅ«vēts ā€œaÄ£enta apturēŔanas slēdzisā€ ļauj administratoriem apturēt vai ierobežot nepareizi funkcionējoÅ”us aÄ£entus (atkārtojot padomu, ka vadÄ«bai jāzina ā€œKas ir apturēŔanas slēdzis?ā€ (www.techradar.com)). Piemēram, ja ļaunprātÄ«gas programmatÅ«ras skenera aÄ£ents kļūst nekontrolējams, tiklÄ«dz telemetrija atzÄ«mē anomālo uzvedÄ«bu, sistēma var nekavējoties izolēt tā atļaujas un brÄ«dināt dežurējoÅ”o inženieri.

Politikas izpilde attiecas arÄ« uz privātuma un droŔības pārbaudēm. Sistēma varētu palaist automatizētus PII detektorus visos izejoÅ”ajos ziņojumos vai izmantot ā€œLLM kā tiesneÅ”aā€ moduli, lai meklētu halucinācijas vai politikas novirzes. JebkurÅ” droŔības pārkāpums tiek reÄ£istrēts kā incidents. Iekļaujot Ŕīs pārbaudes novērojamÄ«bas slānÄ«, uzņēmumi papildus veiktspējas metrikai iegÅ«st arÄ« reāllaika droŔības informācijas paneli.

Bezsaistes simulācija un ā€œsmilÅ”kastesā€ testēŔana

Pirms jebkādu nozÄ«mÄ«gu izmaiņu ievieÅ”anas ir vērts simulēt scenārijus. MÅ«su platforma ietver smilÅ”kastes vidi, lai atkārtoti atskaņotu vai imitētu aÄ£entu darbplÅ«smas. Komandas var aÄ£entam pieŔķirt testu gadÄ«jumu kopumu (atspoguļojot biežus lietotāju pieprasÄ«jumus vai robežgadÄ«jumus) un vākt izsekoÅ”anas žurnālus izmēģinājuma veidā. Å Ä« bezsaistes novērtēŔana nodroÅ”ina, ka jaunas uzvednes vai modeļu jauninājumi nepārkāpj politikas vai nesamazina kvalitāti (www.braintrust.dev). Piemēram, pirms finanÅ”u aÄ£entam pieŔķirt jaunas API privilēģijas, inženieri varētu simulēt mēneÅ”a beigu slēgÅ”anas uzdevumus, lai pārliecinātos, ka tas ievēro apstiprināŔanas plÅ«smas. Sistēma var arÄ« atklāt regresijas: ja atjaunināta aÄ£enta versija pēkŔņi nepareizi konfigurē rÄ«kus, testu izsekoÅ”anas ieraksti atklāj kļūdu, pirms tā nonāk ražoÅ”anā.

BÅ«tÄ«bā tas ir kā haosa inženierija AI jomā: apzināta aÄ£enta pakļauÅ”ana draudu scenārijiem vai nepareiziem datiem, lai redzētu, vai tas nenovirzās no kursa. TechRadar iesaka uzņēmumiem ā€œnovērtēt gatavÄ«bu ar smilÅ”kastes novērtējumiem… lai lēmumu pieņemÅ”ana tiktu pārbaudÄ«ta un atgūŔanas laiki bÅ«tu saprotamiā€ (www.techradar.com). Platforma var automatizēt Ŕīs pārbaudes pēc grafika, reÄ£istrējot katru izpildi. Tas palÄ«dz savlaicÄ«gi atklāt slēptās kļūmes (piemēram, novecojuÅ”u konteksta indeksēŔanu). Integrējot novērtēŔanu izstrādes plÅ«smā, komandas panāk atgriezenisko saiti: ražoÅ”anas kļūdas kļūst par jauniem testu gadÄ«jumiem, un katrai laidienu versijai ir jāiziet bezsaistes pārbaude.

Izpildes kontrole un atcelŔana

Pat ar profilaksi var rasties kļūdas. MÅ«su platforma nodroÅ”ina laboÅ”anas rÄ«kus. Pirmkārt, reāllaika ā€œapturēŔanasā€ komanda var nekavējoties apturēt aÄ£enta darbÄ«bas. IlgstoÅ”iem vai asinhroniem uzdevumiem sistēma var izsaukt atcelÅ”anas punktus, ja tiek pārkāpta politika (piemēram, pārtraukt darÄ«jumu, ja aÄ£ents mēģina izņemt lÄ«dzekļus bez apstiprinājuma). Otrkārt, tā kā visas darbÄ«bas tiek izsekotas, platforma var atkārtot vai atcelt efektus. Piemēram, ja aÄ£ents kļūdaini nosÅ«tÄ«ja e-pastu klientiem vai atjaunināja CRM, operatori var izmantot žurnālus, lai rekonstruētu stāvokli pirms izmaiņām. Kombinācijā ar nemainÄ«giem audita žurnāliem tas ļauj atsaukt datubāzes transakcijas vai failu sistēmas izmaiņas, ko veicis aÄ£ents. TechRadar uzsver Ŕī nepiecieÅ”amÄ«bu: ā€œorganizācijām ir jāpārvērtē… atcelÅ”anas ceļi katrā AI ievieÅ”anÄā€ (www.techradar.com). Praksē platforma varētu saglabāt stāvokli pirms izpildes vai integrēties ar versiju datu krātuvēm, nodroÅ”inot, ka neveiksmÄ«gas aÄ£enta darbÄ«bas var atcelt kā kļūdainu programmatÅ«ras izvietoÅ”anu.

Integrācija ar incidentu reaģēŔanu un biļeÅ”u sistēmām

NovērojamÄ«ba ir tikai puse no cīņas; inženieri ir efektÄ«vi jābrÄ«dina. Platforma tiks integrēta ar moderniem incidentu pārvaldÄ«bas un sadarbÄ«bas rÄ«kiem. Piemēram, tā var nosÅ«tÄ«t kritiskus aÄ£enta brÄ«dinājumus uz PagerDuty, izveidojot dežurējoÅ”a personāla incidentu, kad notiek nopietns politikas pārkāpums. Tā var publicēt kopsavilkumus Slack vai Microsoft Teams kanālos (PagerDuty atzÄ«mē, ka viņu paÅ”u sistēmai ir ā€œuzlabotas Slack un Microsoft Teams integrācijasā€, lai reaģētāji saglabātu fokusu (www.pagerduty.com))). Integrācija ar biļeÅ”u sistēmām ir arÄ« bÅ«tiska: kad tiek aktivizēts brÄ«dinājums, platforma var automātiski izveidot Jira vai ServiceNow biļeti, kas iepriekÅ” aizpildÄ«ta ar izsekoÅ”anas ID, skarto sarunu un politikas detaļām. Tas nodroÅ”ina, ka aÄ£enta incidenti nonāk tajās paŔās triāžas darbplÅ«smās kā citi pārtraukumi. PagerDuty arÄ« izceļ savas vairāk nekā 700 rÄ«ku integrācijas (Datadog, Grafana utt.), lai sasaistÄ«tu novērojamÄ«bu un reaģēŔanu (www.pagerduty.com). LÄ«dzÄ«gi, mÅ«su platforma piedāvātu savienotājus ar žurnāliem (piemēram, Splunk), metriku (Prometheus) un CI/CD sistēmām, lai katrs telemetrijas elements iekļautos esoÅ”ajos informācijas paneļos un diagrammās.

Tradicionālā APM pret aģenta telemetriju

Kā tas salÄ«dzināms ar mantoto Lietojumprogrammu veiktspējas uzraudzÄ«bas (APM) risinājumu? ÄŖsumā, tradicionālā APM (Datadog, New Relic, Dynatrace utt.) izceļas ar infrastruktÅ«ras un koda lÄ«meņa metriku, taču tā uz aÄ£entiem skatās kā uz melnajām kastēm. Piemēram, Datadog var ā€œautomātiski ievadÄ«t, parsēt un analizēt žurnālus no visas jÅ«su sistēmasā€ un tā APM modulis ā€œizseko pieprasÄ«jumus sadalÄ«tajās sistēmāsā€ (www.techradar.com)). LÄ«dzÄ«gi, tā tÄ«kla uzraudzÄ«ba sniedz vispārēju pārskatu par serveriem, CPU, atmiņu un tÄ«kla plÅ«smām (www.techradar.com). Å ie rÄ«ki brÄ«dinās, ja aÄ£ents patērē pārāk daudz CPU vai izmet izņēmumu. Bet neviens no tiem neuztver, ko aÄ£ents domā. Tie nereÄ£istrēs faktisko uzvednes tekstu (privātuma noteikumu dēļ) vai LLM izsaukumu secÄ«bu. Tie nezinās, vai tā radÄ«tā atbilde balstÄ«jās uz nepareizu atmiņu vai vai tā pārkāpa kādu biznesa noteikumu. No viņu viedokļa ā€œviss izskatās zaÄ¼Å”ā€, kad API izsaukums atgriež 200 OK (www.stackai.com).

Praksē varētu mēģināt pielāgot APM aÄ£entiem (piemēram, marķējot katru tērzēŔanas pieprasÄ«jumu un meklējot žurnālos). Bet bez aÄ£entam specifiskiem posmiem nepilnÄ«bas saglabājas. APM pieņem deterministiskas darbplÅ«smas: kļūmes gadÄ«jumā mēs atkļūdojam koda ceļus. Taču ar AI aÄ£entiem kļūmes ir klusās (nepareiza atbilde) vai semantiskās (politikas pārkāpums), nevis izņēmumu meÅ”ana. StackAI novēro, ka aÄ£enti ā€œpārkāpj daudzus [APM] pieņēmumusā€ – piemēram, aÄ£entam nav kļūdas koda, ja tas vienkārÅ”i halucinē (www.stackai.com). Turklāt daudzpakāpju aÄ£entu ķēdes aptver daudzas komponentes (modeļus, indeksus, rÄ«kus); ja jÅ«s uzraugāt tikai galÄ«go tÄ«mekļa pieprasÄ«jumu, jÅ«s zaudējat visu kontekstu par to, kā aÄ£ents tur nonāca. Visbeidzot, APM rÄ«ki parasti ignorē AI specifiskās izmaksas (piemēram, marÄ·ieru lietojumu) un kvalitātes signālus.

Å o iemeslu dēļ uzņēmumi, kas veido aÄ£entu sistēmas, arvien vairāk saskata vajadzÄ«bu pēc specializētas telemetrijas. Kā ziņoja Dynatrace, ā€œNovērojamÄ«ba… ir bÅ«tiska veiksmÄ«gas aÄ£entu AI stratēģijas sastāvdaļa. Komandām ir nepiecieÅ”ama reāllaika redzamÄ«ba par to, kā AI aÄ£enti uzvedas, mijiedarbojas un pieņem lēmumusā€ (www.itpro.com). Piedāvātā platforma nodroÅ”ina tieÅ”i to slāņveida skatu, ko APM rÄ«ki nevar: no augsta lÄ«meņa veselÄ«bas metrikas lÄ«dz aÄ£enta kognitÄ«vajiem soļiem. BÅ«tÄ«bā tas paplaÅ”ina APM zelta signālus (latentums, kļūda, caurlaidÄ«ba) ar aÄ£entam specifiskiem kvalitātes rādÄ«tājiem (pamatotÄ«ba, pabeigÅ”anas rādÄ«tājs, halucināciju biežums) (www.stackai.com) (www.stackai.com).

Cenu modelis

VienkārÅ”s cenu modelis ir uz lietoÅ”anu balstÄ«ts. Viena pieeja ir iekasēt maksu par aÄ£enta minÅ«ti (laiku, ko aÄ£ents aktÄ«vi veic uzdevumus). Piemēram, pakalpojuma cena varētu bÅ«t aptuveni $0.05–$0.10 par aÄ£enta minÅ«ti, lÄ«dzÄ«gi kā mākoņu funkciju rēķini. Tas sedz izsekoÅ”anas/posmu datu fiksēŔanas un glabāŔanas, novērtēŔanas pārbaužu veikÅ”anas un žurnālu glabāŔanas izmaksas. (Var bÅ«t pamata ikmēneÅ”a maksa par piekļuvi platformai plus maksa par pārtēriņu.) Papildu datu glabāŔana vai žurnālu apjoms varētu tikt rēķināts par GB. Apjoma atlaides vai korporatÄ«vie plāni varētu piedāvāt zemākas likmes par minÅ«ti lielām izvietoÅ”anām. Tas saskaņo izmaksas ar patēriņu: sporādiski aktÄ«vs robots rada minimālas izmaksas, lÄ«dz tas darbojas. Kontekstam, daudzi uzraudzÄ«bas un bezserveru produkti izmanto detalizētu lietoÅ”anas cenu. MÅ«su ā€œaÄ£enta minÅ«tesā€ metrika ir analoga – lietotāji precÄ«zi zina, cik viņi maksā par katru aÄ£enta darbÄ«bas stundu, veicinot efektÄ«vu lietoÅ”anu.

Secinājums

Autonomie AI aÄ£enti sola ievērojamus produktivitātes ieguvumus, bet tikai tad, ja mēs varam redzēt un kontrolēt to darbÄ«bas. Jaunā AI novērojamÄ«bas joma risina tieÅ”i to: padarÄ«t aÄ£entu ā€œdomāŔanas procesusā€ pārredzamus un pārvaldāmus. Instrumentējot rÄ«ku izsaukumus, atmiņas piekļuves un lēmumu pieņemÅ”anas soļus kā izsekoÅ”anas ierakstus, mēs iegÅ«stam ieskatu neskaidrās kļūmēs un pārvaldÄ«bas nepilnÄ«bās. Speciāli izstrādāta uzraudzÄ«bas platforma (ar politikas izpildi, simulāciju, atcelÅ”anas iespējām un incidentu reaģēŔanas integrāciju) nodroÅ”ina, ka aÄ£enti droÅ”i darbojas ražoÅ”anā. AtŔķirÄ«bā no mantotajiem APM rÄ«kiem, aÄ£entam specifiska telemetrija uzskata paÅ”u AI sistēmu par pilnvērtÄ«gu pilsoni, nevis tikai tās serverus.

Kā brÄ«dina aptaujas un eksperti, novērojamÄ«bas trÅ«kums ir Ŕķērslis aÄ£entu AI mērogoÅ”anai (www.itpro.com) (www.itpro.com). Izveidojot Å”eit aprakstÄ«to jauno uzraudzÄ«bas sistēmu, organizācijas var pārvērst ā€œcerÄ«gu minēŔanuā€ par uzticamu automatizāciju (www.techradar.com). Galvenokārt, Ŕāda pieeja veido uzticÄ«bu, ka aÄ£enti darbosies, kā paredzēts, un ļauj inovatÄ«vi darboties ar pārliecÄ«bu. Ja kaut kas noiet greizi, tas vairs nebÅ«s noslēpumains pārkāpums vai halucinācija – izsekoÅ”anas žurnāli un kontroles plakne precÄ«zi norādÄ«s kļūmes veidu, nodroÅ”inot ātru mazināŔanu un mācīŔanos. Autonomo aÄ£entu laikmetā novērojamÄ«ba nav izvēles iespēja; tā ir droÅ”as, mērogojamas AI paÅ”os pamatos.

Patīk Ŕis saturs?

Abonējiet mūsu biļetenu, lai saņemtu jaunākos satura mārketinga ieskatus un izaugsmes ceļvežus.

Å is raksts ir paredzēts tikai informatÄ«viem nolÅ«kiem. Saturs un stratēģijas var atŔķirties atkarÄ«bā no jÅ«su specifiskajām vajadzÄ«bām.
AI aģentu novērojamība un kontrole: jaunas uzraudzības sistēmas izveide | AutoPod