Un asistent AI răspunde greu la o solicitare, dar durata totală nu spune unde s-a pierdut timpul: la model, într-un tool extern, într-o reîncercare sau în transferul datelor. OpenTelemetry încearcă să transforme acest lanț într-o singură trasă distribuită, în care fiecare operațiune poate fi măsurată separat.
În mai 2026, proiectul OpenTelemetry a publicat un exemplu dedicat observabilității GenAI, bazat pe convențiile semantice pentru inteligență artificială generativă. Aceste convenții oferă denumiri comune pentru operațiuni precum apelarea unui model, invocarea unui agent și executarea unui tool, indiferent de furnizorul către care sunt trimise datele.
Direcția este utilă pentru echipele care folosesc mai multe modele, framework-uri sau servicii de monitorizare. Totuși, convențiile GenAI sunt încă dezvoltate activ. Unele elemente sunt experimentale și se pot modifica, deci implementarea trebuie tratată ca o interfață versionată, nu ca un contract definitiv.
O întrebare trimisă agentului devine un arbore de operațiuni
O trasă OpenTelemetry reprezintă traseul complet al unei cereri. În interiorul ei, fiecare unitate de lucru este înregistrată ca un span, cu momentul începerii, durata, starea și atributele relevante.
Pentru un agent AI care caută informații într-un sistem intern și apoi formulează un răspuns, arborele poate arăta conceptual astfel:
cerere HTTP
└── invoke_agent
├── chat
├── execute_tool
└── chatPrimul span chat reprezintă apelul prin care modelul decide că are nevoie de un instrument. Spanul execute_tool urmărește execuția instrumentului, iar al doilea chat acoperă apelul prin care modelul folosește rezultatul primit pentru a construi răspunsul final.
Relația părinte–copil păstrează toate aceste operațiuni în aceeași trasă. Echipa poate vedea dacă întârzierea a apărut în serviciul propriu, la furnizorul modelului sau în API-ul accesat de tool. Pentru servicii separate, contextul trasării trebuie propagat între procese; altfel, operațiunile apar ca trase independente și investigația pierde legătura dintre ele.
Această vizibilitate nu înlocuiește controlul permisiunilor. Un span poate arăta că agentul a apelat un tool, dar nu demonstrează că instrumentul avea dreptul să citească sau să modifice acele date. Pentru această parte este necesară o politică separată, precum modelul descris în ghidul despre conectarea tool-urilor AI prin MCP cu permisiuni minime.
Convențiile GenAI dau același sens datelor provenite de la furnizori diferiți
Fără o convenție comună, o integrare poate numi operațiunea llm_request, alta completion, iar alta model_generate. Compararea lor sau mutarea către alt backend de observabilitate devine dificilă.
Convențiile OpenTelemetry folosesc atribute din spațiul gen_ai.*. Printre cele relevante se află:
gen_ai.operation.name, pentru tipul operațiunii;gen_ai.provider.name, pentru furnizorul serviciului GenAI;gen_ai.request.model, pentru modelul cerut;gen_ai.response.model, pentru modelul raportat în răspuns;gen_ai.usage.input_tokens, pentru tokenii de intrare;gen_ai.usage.output_tokens, pentru tokenii de ieșire.
Operațiunile pentru agenți includ denumiri precum invoke_agent, chat și execute_tool. Astfel, un backend compatibil poate grupa apelurile după model, furnizor sau instrument fără ca fiecare echipă să inventeze propriul vocabular.
Numele modelului cerut și cel returnat merită păstrate separat. Un furnizor poate rezolva un alias către o variantă concretă, iar diferența ajută la explicarea unei schimbări de latență sau comportament. Nu trebuie însă presupus că toate API-urile furnizează fiecare atribut.
Documentația principală OpenTelemetry indică faptul că materialele GenAI au fost mutate într-un repository separat. Echipele ar trebui să fixeze versiunea pachetului de convenții și să verifice schimbările înainte de upgrade. Versiunea instrumentării poate fi trecută și în registrul intern al tool-urilor AI aprobate, împreună cu proprietarul integrării și fluxurile de date.
Tokenii explică utilizarea, dar nu măsoară singuri costul sau calitatea
Dacă API-ul modelului furnizează numărul tokenilor, instrumentarea îl poate atașa spanului corespunzător. Echipa vede atunci ce apel a consumat tokenii, nu doar un total agregat pentru întreaga aplicație.
Acest lucru poate scoate la iveală situații precum:
- un context trimis integral la fiecare pas al agentului;
- un tool care întoarce rezultate prea voluminoase;
- o buclă care repetă același apel;
- răspunsuri neobișnuit de lungi;
- mai multe apeluri ale modelului pentru o singură cerere a utilizatorului.
Datele trebuie interpretate cu atenție. Numărul tokenilor nu este sinonim cu prețul, deoarece tarifele depind de furnizor, model și tipul tokenilor. Dacă firma calculează costuri, tabelul de prețuri trebuie versionat separat, cu data aplicării. OpenTelemetry furnizează telemetria; nu garantează corectitudinea formulei comerciale.
Nici calitatea răspunsului nu poate fi dedusă din latență sau consum. O cerere rapidă și ieftină poate produce un rezultat greșit. Pentru această dimensiune, trasarea operațională trebuie completată cu un benchmark reproductibil pentru tool-urile AI, folosind același set de date și aceleași criterii de evaluare.
Instrumentarea începe la cererea utilizatorului, nu doar la SDK-ul modelului
O implementare utilă urmărește fluxul de la intrarea în aplicație până la ultimul răspuns, nu doar durata apelului către model.
Ordinea practică este:
- Păstrează spanul cererii aplicației. Cererea HTTP, mesajul din coadă sau jobul programat trebuie să fie părintele fluxului AI.
- Creează un span pentru rularea agentului. Operațiunea
invoke_agentdelimitează o execuție completă, inclusiv apelurile repetate. - Instrumentează separat fiecare model call. Înregistrează operațiunea, furnizorul, modelul cerut, modelul returnat, durata, starea și tokenii raportați.
- Creează câte un span pentru fiecare tool call. Numele instrumentului, rezultatul tehnic și durata sunt mai utile decât un singur span care acoperă toate instrumentele.
- Propagă același context către serviciile interne. Un tool găzduit separat trebuie să continue trasa existentă, nu să pornească una nouă.
- Exportă datele prin OpenTelemetry Collector. Collectorul poate primi, procesa și trimite telemetria către backend-ul ales.
- Testează o cerere cunoscută. Verifică dacă arborele conține agentul, apelurile modelului și tool-urile în ordinea reală.
Înainte de lansare, echipa ar trebui să simuleze cel puțin un tool lent, un răspuns de eroare și o reîncercare controlată. Trasa trebuie să indice spanul afectat și să păstreze restul relațiilor. Dacă toate operațiunile apar pe același nivel sau ca trase independente, propagarea contextului este incompletă.
Prompturile și rezultatele unui tool nu trebuie trimise automat în telemetrie
O trasă poate deveni ea însăși o sursă de expunere. Prompturile pot conține date personale, documente interne sau secrete comerciale, iar rezultatul unui tool poate include date din CRM, tichete de suport ori sisteme financiare.
Colectarea conținutului complet trebuie să fie o decizie explicită. Pentru monitorizarea obișnuită sunt suficiente, de regulă, metadatele: tipul operațiunii, modelul, numărul tokenilor, durata, starea și un identificator intern pseudonimizat.
OpenTelemetry recomandă controlarea datelor sensibile înainte de export. Collectorul oferă procesoare care pot elimina sau modifica atribute, filtra elemente întregi ori aplica o listă permisă de câmpuri. Filtrarea centrală este utilă, dar nu justifică trimiterea necontrolată a prompturilor din aplicație.
O politică sigură ar trebui să precizeze:
- ce atribute pot fi colectate;
- dacă textul promptului este interzis sau permis doar într-un mediu controlat;
- cine poate consulta trasele;
- cât timp sunt păstrate;
- în ce regiune sunt stocate;
- cum sunt eliminate tokenurile de autentificare și datele personale;
- ce reguli se aplică mediilor de dezvoltare și producție.
Tool calls trebuie înregistrate ca operațiuni, nu ca depozite pentru argumente complete. Un nume de instrument și un rezultat tehnic, precum succes sau eroare, pot fi suficiente pentru diagnosticare.
Tabloul de bord trebuie să răspundă la decizii, nu doar să afișeze trase
După ce structura trasei este corectă, echipa poate construi vizualizări pentru latența fiecărui model, distribuția tokenilor, rata erorilor și durata tool-urilor. Alertele devin utile când sunt legate de un comportament clar: creșterea apelurilor repetate, un tool care depășește pragul operațional intern sau dispariția datelor de utilizare raportate de furnizor.
Eșantionarea necesită atenție. Dacă sunt păstrate numai cererile rapide și reușite, tocmai trasele scumpe ori defecte pot dispărea. Politica trebuie să favorizeze păstrarea erorilor, a latențelor neobișnuite și a execuțiilor cu multe operațiuni, fără a transforma telemetria într-o arhivă nelimitată.
Înainte ca observabilitatea să fie considerată funcțională, echipa poate aplica următorul control de lansare:
- ☐ un singur
trace IDleagă cererea, agentul, modelele și tool-urile; - ☐ fiecare apel extern are un span distinct;
- ☐ tokenii sunt înregistrați numai când există date raportate sau o metodă documentată;
- ☐ prompturile și rezultatele sensibile nu sunt exportate implicit;
- ☐ erorile și reîncercările pot fi localizate în arbore;
- ☐ versiunea convențiilor GenAI este fixată și urmărită;
- ☐ retenția și accesul la telemetrie au proprietari desemnați;
- ☐ un test controlat confirmă traseul înainte de activarea alertelor.
Întrebări frecvente
OpenTelemetry poate urmări model calls și tool calls în aceeași trasă?
Da. Apelurile modelului și execuțiile tool-urilor pot fi reprezentate prin spanuri părinte–copil în aceeași trasă, dacă aplicația propagă corect contextul între componente.
Numărul tokenilor arată direct costul unei cereri?
Nu. Tokenii descriu utilizarea, dar prețul depinde de furnizor, model și regulile comerciale aplicabile. Calculul costului necesită un tabel de prețuri separat și versionat.
Este necesară salvarea promptului complet pentru diagnosticare?
Nu. Durata, modelul, starea, tokenii și identificatorii pseudonimizați sunt adesea suficiente. Colectarea prompturilor trebuie activată numai după evaluarea datelor sensibile și a regulilor de acces.
Convențiile OpenTelemetry GenAI sunt definitive?
Nu. Proiectul precizează că acestea sunt dezvoltate activ, iar unele elemente sunt experimentale. Echipele trebuie să fixeze versiunile și să verifice schimbările înainte de actualizare.
