Observabilitate LLM neutră pentru furnizor: Urmărirea utilizării, costurilor, latenței și riscurilor pe toate modelele

Ce înseamnă observabilitatea LLM neutră pentru furnizor

Observabilitatea LLM neutră pentru furnizor este practica de măsurare a apelurilor de model, a utilizării token-ului, a latenței, a erorilor, a deciziilor de rutare, a proprietății și a evenimentelor relevante pentru siguranță printr-un model de telemetrie comun între furnizori. Nu este doar un tablou de bord care arată mai mulți furnizori unul lângă altul. Lucrarea importantă este definirea a ceea ce trebuie să raporteze fiecare solicitare LLM, modul în care aceste câmpuri ar trebui normalizate, ce date pot fi păstrate în siguranță și modul în care organizația va folosi acele dovezi pentru controlul costurilor, răspunsul la incident și revizuirea operațională.

Acest lucru contează deoarece majoritatea companiilor nu rulează un singur model pentru totdeauna. O echipă de produs poate folosi un furnizor pentru chat, altul pentru extracție, un model mai mic pentru clasificare, un model de încorporare pentru recuperare și un model alternativ în timpul incidentelor. Finanța vrea să știe unde se duc cheltuielile. Engineering vrea latența p95 și ratele de eroare ale furnizorului. Securitatea dorește să înțeleagă utilizarea greșită cheie și expunerea datelor sensibile. Liderii de produse doresc să înțeleagă care clienți și fluxurile de lucru determină utilizarea. Un tablou de bord al furnizorului poate ajuta cu facturarea și sănătatea specifice furnizorului, dar rareori explică imaginea completă a afacerii în echipe, aplicații, API chei, clienți și rute.

Un program de observabilitate durabil începe cu un contract neutru. Fiecare solicitare ar trebui să poată fi urmărită de la fluxul de lucru al aplicației prin gateway sau wrapperul SDK până la răspunsul furnizorului și înapoi la unitatea de afaceri care o deține. Contractul ar trebui să păstreze suficiente detalii specifice furnizorului pentru reconciliere, oferind în același timp operatorilor o viziune consecventă asupra observabilității LLM cu mai multe modele în întregul patrimoniu.

De ce tablourile de bord ale furnizorilor nu sunt suficiente

Tablourile de bord ale furnizorilor sunt utile. Acestea pot afișa utilizarea la nivel de cont, eșecurile furnizorilor, tendințele de latență și înregistrările de facturare. Acestea sunt adesea cea mai apropiată sursă de versiunea de utilizare și facturare a furnizorului. Problema este că ei văd lumea din contul furnizorului, nu din modelul de operare al clientului.

Lacunele comune apar rapid. Un furnizor poate arăta consumul total de simboluri, dar nu care echipă internă, client chiriaș, caracteristică de produs, partener, mediu sau cheie API a cauzat acest lucru. Un alias de model utilizat de o aplicație se poate rezolva la diferiți furnizori de-a lungul timpului, ceea ce face analiza incidentului dificilă, cu excepția cazului în care stratul de rutare înregistrează modelul și furnizorul rezolvat. Reîncercările și alternativele pot fi considerate ca apeluri separate ale furnizorului, în timp ce experiența utilizatorului apare în continuare ca o singură solicitare logică. Răspunsurile transmise în flux pot avea latența primului simbol și eșecuri de ieșire parțială care sunt invizibile în valorile agregate ale furnizorului.

Observabilitatea neutră din punct de vedere al furnizorului umple acest gol prin conectarea datelor furnizorului cu contextul de afaceri. În practică, aceasta înseamnă adesea instrumentarea unui strat sau gateway unificat API, deoarece vede deja cererea, aliasul modelului, furnizorul rezolvat, cheia API, organizația, spațiul de lucru, ruta, metadatele răspunsului și câmpurile de utilizare. Echipele care utilizează un gateway AI multi-model API pot folosi acel strat ca punct central de colectare, în timp ce transmit contextul aplicației, cum ar fi numele fluxului de lucru, locatarul, clasa de utilizator sau mediul.

Straturile de bază ale observabilității LLM

Observabilitatea LLM este mai largă decât înregistrarea solicitărilor. Un program util acoperă de obicei cinci straturi.

Urmele fluxului de lucru al aplicației

Urmele aplicației explică ce încerca să facă utilizatorul sau procesul de afaceri. Aceștia conectează un apel LLM la un flux de lucru, cum ar fi triajul asistenței, revizuirea contractului, generarea de cod, îmbogățirea datelor sau execuția agentului. Fără acest strat, un apel de model poate fi vizibil din punct de vedere tehnic, dar fără sens operațional. Urmărirea ar trebui să includă identificatori stabili ai fluxului de lucru, metadate ale mediului, locatarului sau clientului, acolo unde este cazul, și link-uri către sistemele din aval utilizate de fluxul de lucru.

Gateway-ul și furnizorul se întinde

Gateway-ul și intervalul de furnizor explică modul în care cererea s-a mutat prin calea AI API. Acestea ar trebui să captureze aliasul de model solicitat, modelul rezolvat, furnizorul, punctul final, tipul operației, numărul de reîncercări, starea de rezervă, starea de expirare și rezultatul final. Aici monitorizarea LLM API devine neutră pentru furnizor, în loc de o colecție de diagrame izolate ale furnizorilor.

Token și telemetrie cost

Telemetria de utilizare a simbolurilor LLM înregistrează cât de multă muncă a efectuat modelul și modul în care se mapează utilizarea respectivă. Ar trebui să distingă câmpurile de intrare, de ieșire, de intrare în cache, de scriere în cache, de raționament, multimodale, legate de instrumente și de token facturate, unde furnizorii le expun. Telemetria costurilor ar trebui să separe costul estimat de costul decontat sau reconciliat, deoarece interpretarea prețului se poate modifica atunci când furnizorii expun credite, reduceri, prețuri pe lot, comportamentul în cache sau unitățile facturate specifice furnizorului.

Conținut și telemetrie de siguranță

Telemetria conținutului include solicitări, completări, documente de preluare, rezultate ale instrumentelor, clasificări, motive de refuz, semnale de moderare și indicatori de injectare promptă. Poate fi valoros pentru depanare și revizuire a siguranței, dar sunt date cu risc ridicat. Solicitările și completările brute pot conține secrete, date personale, context de proprietate, înregistrări ale clienților sau informații reglementate. Valorile prestabilite mai sigure includ telemetria numai pentru metadate, identificatorii de șablon prompt, hashuri, clasificări, starea redactării, eșantionarea, trunchierea, capturarea de înscriere, controlul strict al accesului și păstrarea scurtă.

Atribuirea companiei

Atribuirea afacerii conectează utilizarea cu persoanele și sistemele responsabile pentru aceasta. Dimensiunile utile includ organizație, spațiu de lucru, echipă, aplicație, mediu, client sau chiriaș, partener, cheie API, caracteristică de produs și clasa de volum de lucru. Aceste câmpuri fac analiza utilizării gateway-ului AI utilă pentru revizuirea financiară, raportarea clienților, planificarea capacității și proprietatea incidentelor.

Definiți mai întâi un model de telemetrie canonic

Cea mai frecventă greșeală este să începeți cu tablourile de bord înainte de a defini contractul de telemetrie. Tablourile de bord sunt la fel de bune ca și câmpurile care le alimentează. Înainte de a alege diagramele, definiți înregistrarea canonică pe care ar trebui să o producă fiecare solicitare LLM.

O schemă practică de telemetrie a cererii include request_id, trace_id, organizație, spațiu de lucru, echipă, mediu, aplicație, client sau chiriaș, API identitate cheie, alias de model, model rezolvat, furnizor, punct final, operare, semnalizare streaming, stare, clasă de eroare, faze de latență, câmpuri de simboluri, cost estimat, câmpuri pentru costuri decontate, stare de reîncercare și decizie de rezervă, câmpuri de retragere a politicii, stare de reîncercare și decizie de rezervă metadate. Nu fiecare câmp va fi prezent pentru fiecare furnizor sau punct final, dar schema oferă echipelor un loc stabil pentru a mapa ceea ce este cunoscut.

Canonic nu înseamnă supranormalizare. Telemetria neutră pentru furnizor ar trebui să păstreze obiectul original de utilizare a furnizorului sau metadatele brute relevante pentru reconciliere. Dacă un furnizor raportează prompt_tokens și completion_tokens, altul raportează jetoane de intrare și de ieșire, iar altul expune jetoane stocate în cache sau de raționament, platforma ar trebui să normalizeze câmpurile comparabile, păstrând în același timp detaliile care explică diferențele de facturare. Scopul este de a face tablourile de bord între furnizori comparabile fără a șterge comportamentul furnizorului care contează în timpul depanării sau examinării facturilor.

Telemetria de utilizare a simbolurilor nu este un numărător

Telemetria token-ului merită o proiectare atentă, deoarece contabilitatea token-ului nu este uniformă între furnizori. Unele API-uri fac distincție între jetoanele prompt, completare și total. Alții raportează jetoane de intrare și de ieșire. Unele expun introducerea în cache, crearea memoriei cache, indicative de raționament, simboluri imagine, simboluri audio sau candidați. Punctele finale de streaming pot oferi utilizare finală numai după finalizarea răspunsului. În cazurile de eșec, utilizarea poate lipsi sau este incompletă.

Un model canonic bun separă cel puțin aceste concepte: jetoane de intrare, jetoane de ieșire, jetoane de intrare stocate în cache, jetoane de scriere cache, jetoane de raționament, jetoane multimodale, jetoane legate de instrumente, jetoane consumate total, jetoane facturate și starea lipsă de utilizare. Tokenurile facturate contează deoarece unii furnizori pot expune atât conturile consumate, cât și cele facturate, iar facturarea poate depinde de comportamentul în cache, familia de modele, modalitatea, punctul final sau planul de prețuri.

Această separare este ceea ce face ca monitorizarea costurilor și a latenței LLM să fie acționabilă. Dacă cheltuielile cresc, echipele trebuie să știe dacă cauza sunt solicitări mai lungi, mai multe rezultate generate, pierderi de memorie cache, sarcini de lucru grele de raționament, noi intrări de imagini, reîncercări, trafic alternativ sau trecerea la un model mai scump. Restrângerea totul în total_tokens poate fi acceptabilă pentru un prototip, dar nu este suficientă pentru guvernarea costurilor operaționale.

Observabilitatea costurilor și atribuirea

Observabilitatea costurilor are două părți: capturarea utilizării și interpretarea prețului. Câmpurile de utilizare explică ce s-a întâmplat la momentul solicitării. Interpretarea prețului explică ce înseamnă această utilizare din punct de vedere financiar. Cele două ar trebui să fie conectate, dar nu confundate.

Pentru analiza la momentul solicitării, costul estimat este adesea suficient pentru a detecta vârfurile, a compara sarcinile de lucru și a alerta asupra pragurilor bugetare. Pentru raportarea financiară și a clienților, costul decontat poate avea nevoie de reconciliere cu facturile furnizorilor, prețurile negociate, creditele sau condițiile de distribuire. Echipele care au nevoie de LLM API atribuire mai profundă a costurilor ar trebui să trateze metadatele de proprietate ca date solicitate necesare, nu ca pe ceva de dedus mai târziu din jurnalele.

Tablourile de bord utile ale costurilor răspund la întrebările de afaceri: ce echipe cheltuiesc cel mai mult, care clienți generează cea mai mare utilizare, care API chei sunt anormale, ce modele de migrare au schimbat economia unității, unde stocarea în cache reduce costurile și ce rute creează o utilizare neregulată. Pentru planificarea și controalele bugetare mai ample, această telemetrie poate alimenta fluxuri de lucru pentru gestionarea costurilor LLM, cum ar fi alerte de prag, revizuire a cotelor, modificări ale politicii modelului și analize periodice ale cheltuielilor.

Măsurarea latenței și a streamingului

Latența medie este rareori suficientă pentru operațiunile LLM. Utilizatorii simt o latență, nu medii. Operatorii au nevoie de latență p50, p95 și p99 în funcție de model, furnizor, rută, mediu și clasă de clienți. De asemenea, trebuie să știe ce fază a solicitării a cauzat întârzierea.

Timpul de procesare separat al gateway-ului, timpul de solicitare a furnizorului, timpul de coadă, întârzierea reîncercării, întârzierea de rezervă, timpul până la primul octet sau primul simbol, durata fluxului, timpul instrumentului în aval și timpul total al fluxului de lucru de la un capăt la altul. Pentru streaming, latența primului token și timpul de finalizare a fluxului ar trebui urmărite separat. Un model se poate simți receptiv dacă pornește rapid, dar totuși durează mult pentru a se termina. Reversul este, de asemenea, adevărat: un răspuns final scurt poate fi lent dacă primul simbol sosește cu întârziere.

Transmiterea în flux creează, de asemenea, cazuri marginale de observabilitate. Utilizarea poate ajunge doar la finalizare. Un client se poate deconecta înainte de a primi utilizarea finală. Un furnizor poate returna o ieșire parțială și apoi eșuează. Un gateway poate reîncerca înainte ca orice token să fie livrat sau poate să nu poată reîncerca după ce ieșirea parțială a ajuns la client. Aceste stări ar trebui să fie explicite, nu ascunse sub o etichetă generică de expirare sau de eșec.

Erori, reîncercări, alternative și rutare

Eșecurile LLM ar trebui clasificate în moduri care să conducă la acțiune. O taxonomie utilă a erorilor separă erorile de validare a clientului, eșecurile de autentificare, eșecurile de cotă, limitele ratei furnizorului, supraîncărcarea furnizorului, erorile de model de furnizor, expirarea timpului de gateway, refuzurile de siguranță a conținutului, refuzurile politicilor, ieșirile incorecte, eșecurile instrumentelor din aval și rezultatele necunoscute. Acest lucru ajută echipele să decidă dacă modifică solicitările, ajustează cotele, rotesc tastele, contactează un furnizor, ajustează ruta sau corectează codul aplicației.

Reîncercările și alternativele necesită o atenție specială. Din perspectiva utilizatorului, o solicitare poate avea succes. Din perspectiva platformei, aceeași cerere logică poate să fi produs trei apeluri de furnizor, latență suplimentară și costuri suplimentare. Observabilitatea ar trebui să urmărească numărul de reîncercări, motivul reîncercării, întârzierea retragerii, încercarea de rezervă, motivul de rezervă, modelul selectat, furnizorul rezolvat, starea întrerupătorului și dacă contractul de răspuns s-a modificat după retragere.

Telemetria de rutare este, de asemenea, esențială în timpul migrărilor de model. Dacă o aplicație solicită un alias de model, înregistrarea de observabilitate ar trebui să captureze atât alias-ul, cât și ID-ul de furnizor/model rezolvat. În caz contrar, echipele nu pot compara în mod fiabil latența, costurile, ratele de eroare sau incidentele de calitate înainte și după migrare.

Confidențialitate și guvernare pentru solicitări și completări

Jurnalele de solicitare și finalizare nu sunt jurnalele de depanare obișnuite. Acestea pot conține date despre clienți, secrete, informații despre produse nepublicate, text legal, date de sănătate, acreditări lipite de utilizatori, context de recuperare sau rezultate ale instrumentelor din sistemele interne. Înregistrarea lor implicită poate crea un al doilea depozit de date sensibile în afara controalelor aplicate sistemelor sursă.

Un design mai sigur separă telemetria solicitărilor de telemetria conținutului. Solicitarea de telemetrie, cum ar fi modelul, furnizorul, latența, numărul de simboluri, starea și proprietarul, pot fi adesea reținute pe scară largă. Telemetria conținutului ar trebui să fie guvernată separat, cu o politică explicită de captare, redactare, acces, eșantionare, păstrare și ștergere. Multe echipe încep cu capturarea numai cu metadate, apoi permit capturarea de conținut cu participare restrânsă pentru medii aprobate, incidente sau fluxuri de lucru de evaluare.

Alternativele obișnuite la conținutul brut includ ID-urile șablonului prompt, numerele versiunii prompte, hash-urile, lungimea conținutului, limba, clasificarea sensibilității, ID-urile sursei de preluare, deciziile de politică, categoriile de refuz și marcatorii de redactare. Aceste câmpuri sprijină investigarea și analiza tendințelor fără a stoca fiecare prompt și răspuns literal. Când este necesar conținutul complet, accesul ar trebui să fie limitat, auditat și limitat în timp.

Convenții OpenTelemetry și GenAI

OpenTelemetry oferă echipelor un vocabular comun pentru intervale, valori, jurnale, evenimente și convenții semantice. Convențiile sale GenAI sunt utile deoarece oferă nume comune pentru atribute precum funcționarea, modelul, furnizorul și utilizarea token-ului. Acest lucru facilitează trimiterea datelor de urmărire a solicitărilor LLM în sistemele de observabilitate existente în loc să creeze o stivă de monitorizare complet separată.

Alinierea OpenTelemetry este o bază bună, dar nu este un model de guvernanță complet. Echipele au nevoie în continuare de decizii interne cu privire la metadatele de proprietate, API atribuirea cheilor, dimensiunile clienților, politica de confidențialitate, păstrarea, câmpurile de cost și reconcilierea specifică furnizorului. De asemenea, trebuie să decidă ce sistem este autorizat pentru înregistrările de utilizare și costuri, astfel încât analiza de facturare să nu fie duplicată sau numărată de două ori în jurnalele de gateway, urmele aplicațiilor și exporturile furnizorilor.

Modelul practic este să folosiți nume și o structură de urmărire compatibile cu OpenTelemetry acolo unde este posibil, apoi să extindeți înregistrarea cu dimensiunile de afaceri cerute de organizație. Acest lucru menține telemetria portabilă, păstrând în același timp contextul necesar pentru analiza utilizării AI API, rambursarea, raportarea clienților și examinarea incidentelor.

Observabilitate pentru sistemele agentice și care utilizează instrumente

Încărcările de lucru cu agenție necesită mai mult decât monitorizarea răspunsului final. Când un LLM poate apela instrumente, sisteme de recuperare a interogărilor, acces la memorie, scrie în sistemele din aval sau poate declanșa acțiuni de flux de lucru, observabilitatea trebuie să includă acele decizii intermediare și efecte secundare.

Cel puțin, telemetria agentului ar trebui să captureze numele instrumentului, starea apelului instrumentului, decizia de autorizare, clasificarea intrărilor și ieșirii, sistemul din aval, comportamentul de reîncercare, timpul scurs, costul acolo unde este cazul și dacă a apărut un efect secundar. Telemetria de preluare ar trebui să includă identificatori de sursă, clase de documente, numărătoare de bucăți, metadate de clasare și filtre de politică, fără a stoca în mod inutil documentele brute. Accesul la memorie ar trebui să fie urmăribil, mai ales atunci când este implicată memorie specifică utilizatorului sau locatarului.

Aceasta este atât o cerință operațională, cât și o cerință de securitate. Dacă un agent creează un bilet neașteptat, actualizează o înregistrare CRM, trimite un mesaj sau inițiază o tranzacție, echipele au nevoie de suficientă telemetrie pentru a reconstrui motivul pentru care a avut loc acțiunea, ce model și calea promptă au fost implicate, ce permisiuni au fost verificate și ce date au fost expuse.

Tabloul de bord și modelele de alertă care funcționează

Tablourile de bord bune de observabilitate LLM sunt construite în jurul deciziilor, nu a unor valori vanitare. O vizualizare de conducere poate arăta utilizarea totală, costul în funcție de echipă, costul în funcție de segmentul de clienți, combinația de modele și tendința cheltuielilor. O vizualizare de inginerie poate afișa latența p95, rata de eroare a furnizorului, rata de reîncercare, rata de rezervă, câmpurile de utilizare lipsă și ieșirea incorectă în funcție de rută. O vizualizare de securitate sau guvernanță poate arăta un comportament neobișnuit al cheii, starea de înregistrare promptă, respingerea politicilor, anomalii de apelare la instrumente și acces la fluxuri de lucru sensibile.

Alertele ar trebui să poată fi acționate. Alertele utile includ vârfuri bruște de simboluri, comportament neobișnuit cu API cheie, abordarea pragului limită de cheltuieli, rate ridicate ale furnizorului 429 sau 5xx, latență ridicată p95 sau p99, furtuni de rezervă, date de utilizare lipsă, vârfuri de deconectare a clienților, refuzuri repetate privind siguranța conținutului și anomalii de apelare a instrumentelor. Alertele zgomotoase la variația normală creează oboseală; lipsa alertelor privind cheltuielile nerezolvate sau degradarea furnizorului lasă compania expusă.

Tablourile de bord ar trebui să accepte și ritualuri de examinare. Analiza săptămânală a costurilor, revizuirea migrației modelului, autopsia incidentelor, evaluarea utilizării clienților și evaluarea periodică a riscurilor AI necesită toate telemetrie stabilă. Guvernarea riscului AI în stil NIST pune accent pe monitorizarea continuă, responsabilitățile definite, inventarul și revizuirea periodică. Observabilitatea LLM oferă baza de dovezi pentru aceste practici.

Model de implementare pentru un mediu cu mai multe modele

O implementare practică combină de obicei instrumentarea gateway-ului, contextul aplicației și reconcilierea furnizorilor.

Mai întâi, definiți contractul de telemetrie. Decideți ce câmpuri sunt obligatorii, opționale, specifice furnizorului, sensibile, cu cardinalitate ridicată sau păstrate numai pentru perioade scurte. Faceți metadatele de proprietate obligatorii pentru apelurile de producție.

În al doilea rând, instrumentați gateway-ul sau stratul unificat API. Identitatea solicitării de captare, alias-ul modelului, furnizorul rezolvat, identitatea cu API cheie, organizație, spațiu de lucru, punct final, operare, semnalizare streaming, stare, clasa de eroare, faze de latență, câmpuri de utilizare, reîncercări, alternative și starea de redactare. B2B LLM este relevant aici deoarece accesul API unificat, controalele organizației, analiza utilizării, gestionarea costurilor, guvernanța cu APIcheie și capabilitățile de partener API pot oferi un punct central pentru colectare și atribuire în mediile cu mai mulți furnizori.

În al treilea rând, treceți contextul aplicației în cerere. Poarta de acces nu poate deduce fiecare dimensiune a afacerii în mod fiabil. Aplicațiile trebuie să transmită metadate stabile, cum ar fi fluxul de lucru, chiriașul, zona de produs, mediul și clasa logică de utilizator, acolo unde politica o permite.

În al patrulea rând, mapați utilizarea furnizorului în câmpuri canonice, păstrând în același timp detaliile brute ale furnizorului. Acest lucru acceptă tablourile de bord și reconcilierea. Utilizarea lipsă sau cu întârziere ar trebui să fie reprezentată în mod explicit, mai degrabă decât convertită în tăcere la zero.

În al cincilea rând, separați telemetria solicitărilor de telemetria conținutului. Stocați conținutul prompt și completat numai în conformitate cu regulile aprobate. Urmăriți starea redactării și politica de captare pentru fiecare înregistrare.

În al șaselea rând, creați tablouri de bord și alerte în jurul întrebărilor de afaceri care contează: cheltuieli, latență, fiabilitate, proprietate, comportament cheie, sănătatea furnizorului și reconstrucția incidentelor.

Greșeli frecvente de evitat

Cea mai mare greșeală este tratarea observabilității LLM neutră pentru furnizori ca pe un proiect de vizualizare în loc de un proiect de contract de telemetrie. Dacă înregistrările solicitării nu conțin câmpuri privind proprietatea, utilizarea, rutarea și furnizorul, tablourile de bord nu le pot recupera ulterior.

Un alt eșec comun este utilizarea totalurilor de facturare a furnizorului ca singura sursă de adevăr. Totalurile de facturare pot fi exacte din punct de vedere financiar, dar totuși inutile pentru alocarea cheltuielilor către echipe, clienți, chei, produse sau sarcini de lucru. Alocarea costurilor trebuie să fie proiectată în calea solicitării.

De asemenea, echipele își pierd vizibilitatea prin prăbușirea jetoanelor într-un singur total. Unitățile de intrare, de ieșire, stocate în cache, de raționament, multimodale și facturate pot avea implicații diferite de cost și performanță. Tratarea acestora ca un număr ascunde cauza modificărilor costurilor.

Înregistrarea implicită a promptului brut și a finalizării este o altă eroare gravă. Poate crea confidențialitate, conformitate și expunere de securitate evitabilă. Observabilitatea în primul rând metadate este, de obicei, o variantă prestabilită mai bună, cu captarea conținutului atent guvernată pentru nevoi specifice.

În sfârșit, multe echipe nu măsoară reîncercări, alternative, eșecuri de streaming și apeluri la instrumente. Acestea sunt exact locurile în care costul, latența și riscul se pot multiplica. Un răspuns final de succes nu înseamnă că calea cererii de bază a fost eficientă, fiabilă sau sigură.

Concluzie: transformați observabilitatea într-o decizie a planului de control

Observabilitatea LLM neutră pentru furnizori oferă liderilor de afaceri și de inginerie o viziune operațională comună între modele și furnizori. Scopul nu este de a ascunde diferențele dintre furnizori. Scopul este de a normaliza câmpurile care ar trebui să fie comparabile, de a păstra detaliile care explică comportamentul furnizorului și de a conecta fiecare solicitare la echipa, aplicația, clientul, cheia și fluxul de lucru responsabil pentru aceasta.

Abordarea durabilă este simplă: definiți o schemă de telemetrie canonică, instrumentați gateway-ul și straturile de aplicație, separați metadatele cererii de conținutul sensibil, urmăriți câmpurile de simboluri și costuri cu suficientă precizie, măsurați latența pe fază, clasificați clar erorile și construiți tablouri de bord în jurul deciziilor. Odată ce această fundație există, echipele pot schimba modelele, adăuga furnizori, impune guvernanța, revizuiesc incidente și pot gestiona cheltuielile fără a reconstrui observabilitatea de fiecare dată când stiva AI se schimbă.