Observabilitatea agenților AI ar trebui să ajute un operator să explice ce s-a întâmplat cu o sarcină de afaceri. Un grafic al latenței modelului sau al consumului de tokenuri nu poate arăta ce înregistrare de client s-a modificat, de ce a fost refuzată o cerere sau cine răspunde de o operațiune al cărei rezultat rămâne incert.
Observă sarcina completă, de la agent și instrumentele sale până la sistemele țintă. Păstrează identificatori cu domeniu clar, tranziții de stare relevante și dovezi independente ale rezultatului, fără a colecta neîngrădit conținut sensibil. Generează alerte pentru activitățile care necesită intervenție și atribuie fiecărei alerte un responsabil clar pentru investigație.
Imaginează-ți un agent care creează o activitate de urmărire în CRM după verificarea unei comenzi. Îi spune utilizatorului că sarcina este finalizată, dar echipa de vânzări nu o găsește. Investigația trebuie să coreleze cererea inițială cu contul selectat, apelul instrumentului, referința din sistemul țintă și rezultatul observat. Un jurnal al răspunsurilor modelului nu este suficient.
Acest ghid privește operarea în producție. Ghidul nostru de evaluare a agenților AI tratează acceptarea înainte de lansare. Cele două domenii ar trebui să folosească aceleași definiții ale rezultatelor, păstrându-și scopurile distincte.
Definește observabilitatea agenților AI în jurul sarcinii
Identifică unitatea de lucru pe care un coleg o poate recunoaște. Poate fi o solicitare, o întrebare despre o comandă sau aprobarea unei schițe. Atribuie sarcinii o referință stabilă și definește stările acceptate, inclusiv în așteptare, refuzată, finalizată și nerezolvată.
Separă succesul execuției de succesul comercial. Un instrument poate returna un răspuns tehnic acceptat, în timp ce sistemul țintă pune activitatea într-o coadă de revizuire. Proiectarea observabilității trebuie să facă această diferență vizibilă, fără a considera finalizat orice rezultat care nu este o eroare.
| Stare | Semnificația operațională de definit | Dovezile necesare operatorului |
|---|---|---|
| Primită | Sarcina a intrat în fluxul de lucru acceptat | Referința sursei și domeniul |
| În așteptare | Se așteaptă o dependență sau o decizie umană | Motivul așteptării și responsabilul |
| Refuzată | Fluxul permis nu poate continua | Regula sau limita care a împiedicat continuarea |
| Finalizată | Rezultatul comercial convenit este confirmat | Referința din sistemul țintă și starea observată |
| Incertă | O operațiune este posibil să fi produs efecte | Referința operațiunii și calea de reconciliere |
Folosește aceste definiții consecvent în interfață, telemetrie și procedura de suport. Dacă utilizatorul vede finalizată, iar tabloul operațional arată în coadă, sistemul trebuie să explice diferența. Altfel, observabilitatea aparentă poate produce relatări contradictorii despre aceeași sarcină.
Corelează cererea, instrumentele și sistemul țintă
Conceptele de trasare OpenTelemetry descriu segmente de trasare și context propagat pentru corelarea operațiunilor. Aceste mecanisme pot conecta activitatea tehnică între servicii. Ele nu definesc regula de finalizare comercială; aplicația trebuie să adauge dovezile adecvate ale rezultatului.
Păstrează relația dintre o sarcină, încercările sale de execuție și operațiunile externe. O sarcină poate implica mai multe apeluri ale modelului și reîncercări. O execuție poate crea și activități care continuă asincron. Nu echivala numărul cererilor către model cu numărul sarcinilor de afaceri finalizate.
Transmite contextul prin cozi și transferuri către oameni, acolo unde este potrivit. Operatorul ar trebui să poată trece de la referința sarcinii la instrumentul relevant și la rezultatul din sistemul țintă, fără a compara manual marcaje temporale din tablouri fără legătură.
Înregistrează versiunea care a determinat comportamentul: implementarea aplicației, definițiile instrumentelor relevante și configurația instrucțiunilor. Controlează accesul la instrucțiunile sensibile. Scopul este identificarea a ceea ce a rulat, nu expunerea fiecărei valori interne de configurare tuturor utilizatorilor tabloului.
Colectează dovezi utile fără a jurnaliza totul
Pornește de la întrebările investigației. Ce cont a fost selectat? Ce operațiune s-a cerut? Ce autoritate s-a aplicat? Ce răspuns s-a observat? La multe dintre ele se poate răspunde prin referințe, stări și coduri de motiv, fără conținut neîngrădit din mesaje sau documente.
Recomandările OWASP privind jurnalizarea tratează datele sensibile care trebuie excluse sau gestionate atent. Aplică acest principiu înainte de a exporta prompturi, răspunsuri sau argumentele instrumentelor către un furnizor de telemetrie. Comoditatea depanării nu justifică păstrarea nelimitată a înregistrărilor clienților.
| Dovadă | De ce poate ajuta | Întrebare privind gestionarea |
|---|---|---|
| Referințele sarcinii și operațiunii | Corelează încercările și efectele din sistemul țintă | Identificatorul însuși poate dezvălui context sensibil? |
| Domeniul utilizatorului și al tenantului | Permite investigarea deciziilor de autorizare | Cine poate consulta informațiile de identitate? |
| Numele instrumentului și starea rezultatului | Identifică limita la care apare eșecul | Se colectează prea multe argumente sau rezultate? |
| Referințele versiunilor | Permit reproducerea comportamentului relevant | Unde se păstrează configurația cu acces controlat? |
| Referința aprobării umane | Explică autoritatea unei acțiuni | Se poate recupera versiunea aprobată? |
Definește retenția în funcție de scop și consecințe. Datele de diagnostic cu durată scurtă și o înregistrare de aprobare comercială păstrată mult timp pot necesita tratamente diferite. Documentează cine poate recupera conținutul și cum se revizuiește accesul, în loc să pui toate înregistrările într-un depozit general de jurnale.
Separă problemele modelului de problemele integrării
O sarcină eșuată poate proveni dintr-o interpretare greșită, lipsa permisiunilor, date sursă învechite, un sistem țintă indisponibil sau o regulă de afaceri pe care nicio componentă nu a codificat-o. Păstrează suficient context pentru a diferenția aceste situații înainte de a schimba modelul sau promptul.
De exemplu, alegerea corectă a instrumentului poate totuși eșua din cauza expirării acreditărilor sistemului țintă. Invers, un răspuns API sănătos poate însoți asocierea cu un client greșit. Metricile disponibilității tehnice și verificările rezultatelor răspund unor întrebări diferite, iar ambele pot fi utile.
Păstrează vizibile rezultatele incerte
Când o scriere depășește timpul de așteptare, înregistrează incertitudinea și referința pentru verificare. Nu jurnaliza încercarea ca eșec sigur doar fiindcă răspunsul nu a sosit. Următorul operator trebuie să știe dacă reluarea ar putea produce încă un efect comercial.
Ghidul nostru de dezvoltare a serverelor MCP explică această limită pentru o integrare prin protocol. Același principiu de investigare se aplică atunci când agentul folosește un API direct sau alt mecanism: verifică sistemul țintă înainte de a afirma dacă scrierea s-a produs.
Generează alerte pentru situații care cer acțiune
O alertă trebuie să identifice activitatea care necesită intervenția cuiva. Exemplele includ o scriere incertă fără responsabil, o coadă de revizuire care depășește așteptarea convenită sau un număr tot mai mare de sarcini acceptate care nu ajung la confirmarea din sistemul țintă. Alege pragurile în funcție de nevoile operaționale ale fluxului.
Evită alerta pentru fiecare refuz obișnuit. O cerere respinsă corect poate să nu necesite intervenție. Separă comportamentul de politică așteptat de un tipar care sugerează permisiuni defecte, date ostile sau un caz de client care nu mai este acceptat.
Specifică primul pas al investigației și responsabilul escaladării. O alertă care spune eroare de agent, fără referința sarcinii sau contextul sistemului țintă, încurajează presupunerile repetate. Un ghid operațional cu responsabil desemnat trebuie să explice ce se poate reîncerca, ce trebuie verificat și ce acțiuni necesită aprobare.
Testează traseul alertei printr-un incident controlat. Verifică primirea de către coada sau operatorul vizat și confirmă că referințele duc la dovezi utilizabile. O regulă vizibilă în consola de monitorizare nu dovedește că un coleg de gardă poate rezolva eșecul.
Fă tablourile să reflecte rezultatele acceptate
Raportează separat familiile de sarcini acceptate. Căutările obișnuite pot domina un total agregat și ascunde performanța slabă a unui grup mai mic de scrieri importante. Arată activitățile în așteptare și incerte alături de sarcinile finalizate și refuzate.
Măsoară durata între limitele comerciale relevante. Timpul de răspuns al modelului poate exclude așteptarea într-o coadă de revizuire sau un job întârziat în sistemul țintă. Decide dacă utilizatorul urmărește prima confirmare de primire, schița aprobată sau operațiunea externă finalizată, apoi numește metrica în consecință.
Observă corecțiile și sarcinile redeschise. Un agent care finalizează rapid, dar produce înregistrări pe care personalul trebuie să le repare, poate părea eficient într-un tablou al cererilor. Leagă reparațiile de sarcina inițială, unde este posibil, astfel încât imaginea operațională să includă consecințele.
Explică limitele acoperirii telemetriei. Eșantionarea, limitele furnizorilor și lipsa înregistrărilor istorice pot restrânge investigația. Precizează dovezile păstrate pentru operațiunile critice și nu sugera că orice sarcină trecută poate fi reconstruită când datele nu sunt disponibile.
Alege deliberat convențiile și furnizorii
Preferă contracte de date și căi de export documentate în locul unui tablou pe care îl înțelege doar autorul său inițial. Verifică starea actuală a convențiilor de telemetrie specifice agenților înainte să le adopți. Acest ghid nu presupune că o convenție semantică în schimbare este o schemă permanent stabilă.
Notificarea OpenTelemetry despre convențiile pentru AI generativ trimite cititorii la depozitul menținut în prezent. Urmărește acea sursă la implementare. Păstrează documentate semnificațiile proprii ale sarcinilor și rezultatelor aplicației chiar dacă denumirile atributelor bibliotecii se schimbă.
Compară furnizorii după capacitatea de investigare, gestionarea datelor, retenție, controlul accesului și costul operațional. Un vizualizator de trase care impresionează grafic este util doar dacă primește dovezile necesare fluxului și operatorul autorizat le poate interpreta.
Include defecțiunile telemetriei în proiectare. Decide ce înregistrări comerciale trebuie păstrate chiar dacă destinația de monitorizare este indisponibilă. Pierderea unei trase de diagnostic nu trebuie să șteargă în tăcere singura înregistrare a unei acțiuni externe aprobate.
Delimitează costurile și un prim rezultat util
Solicită o propunere în GBP care separă proiectarea stărilor sarcinii, instrumentarea, corelarea cu sistemul țintă, alertele și predarea operațională. Include costurile recurente de stocare, ingestie și revizuire. Jurnalizarea fiecărui token și a fiecărei încărcături de instrument poate crea cheltuieli fără valoare proporțională pentru investigație.
| Pachet de lucru | Livrabil | Factor de dimensionare |
|---|---|---|
| Maparea rezultatelor | Stări ale sarcinilor și dovezi acceptate | Numărul operațiunilor comerciale distincte |
| Instrumentare | Referințe tehnice și comerciale corelate | Servicii, cozi și limite externe |
| Controale asupra datelor | Politica de retenție și acces | Sensibilitatea conținutului capturat |
| Alertare | Situații cu responsabil și ghiduri testate | Răspunsul necesar și acoperirea suportului |
| Predare | Exemple de investigație și responsabilitatea întreținerii | Responsabilitățile echipei și furnizorului |
Pilotul nostru delimitat pentru integrarea AI poate începe cu o sarcină pe care echipa ta o explică greu în prezent. Trimite-ne rezultatul care lipsește și dovezile disponibile astăzi pentru a discuta instrumentarea care susține o decizie operațională concretă.
Întrebări frecvente
Ce este observabilitatea agenților AI? Este capacitatea de a investiga comportamentul și rezultatele comerciale ale unui agent folosind dovezi tehnice și operaționale corelate. Acoperirea utilă include starea sarcinii, activitatea instrumentelor, autoritatea, efectele din sistemul țintă și transferurile către oameni.
Este suficient un jurnal al prompturilor? Nu. Poate arăta ce a primit și returnat modelul, dar poate să nu dovedească finalizarea unei operațiuni externe sau contul afectat. Păstrează dovezi din sistemul țintă și referințe stabile.
Ar trebui să capturăm fiecare argument și răspuns al instrumentelor? Nu în mod implicit. Pornește de la întrebările investigației și colectează dovezile cel mai puțin sensibile care răspund la ele. Orice conținut păstrat necesită un scop explicit, o politică de acces și reguli de retenție.
Prin ce diferă de evaluare? Evaluarea verifică cazurile convenite pentru a susține o decizie de lansare. Observabilitatea susține investigarea activității în producție. Ar trebui să folosească aceleași definiții ale rezultatelor, dar o suită de teste care trece nu înlocuiește dovezile operaționale.
Ce ar trebui să declanșeze o alertă? Situațiile care necesită intervenție, precum scrierile incerte fără responsabil sau sarcinile care depășesc așteptarea convenită. Nu orice refuz așteptat trebuie să cheme un operator. Testează că alertele includ o referință utilizabilă și o cale de investigare.
Putem diagnostica orice sarcină istorică? Doar în măsura în care dovezile necesare au fost păstrate și pot fi corelate. Eșantionarea, retenția și vizibilitatea furnizorilor externi impun limite. Documentează-le și păstrează deliberat înregistrările necesare acțiunilor comerciale importante.
Care este un prim proiect util? Alege o problemă de investigație recurentă. Mapează stările sarcinii, adaugă referințele lipsă, verifică dovezile din sistemul țintă și exersează traseul alertei sau al suportului. Extinde atunci când echipa poate folosi cu succes acele dovezi.