Kako z OpenTelemetry zgraditi nevtralno LLM opazovalnost ponudnika

Opazljivost LLM je motena, ko vsaka aplikacijska skupina beleži odgovore ponudnika v svojem formatu. Med incidentom morajo ekipe platforme odgovoriti na konkretna vprašanja: katera ekipa je vložila zahtevo, kateri obseg ključa API je bil uporabljen, kateri model je bil zahtevan, kateri ponudnik ga je dejansko stregel, ali je prišlo do ponovnega poskusa ali nadomestnega načina, koliko žetonov je bilo porabljenih, katero vedro zakasnitve je bilo spremenjeno in kateri razred napake je povzročil napako. Potrebujejo tudi te odgovore brez kopiranja neobdelanih pozivov, dokončanj, ključev ponudnika ali identifikatorjev strank v generične shrambe dnevnikov.

Praktičen odgovor je instrumentirati večmodelni prehod API kot nadzorno točko opazovanja. Sledenje na ravni aplikacije je še vedno pomembno, vendar je prehod tam, kjer je mogoče normalizirati izbiro ponudnika, ponovne poskuse, nadomestne možnosti, obračunavanje uporabe, lastništvo zahtev in uveljavljanje zasebnosti, preden telemetrija doseže nadaljnja orodja. Za ekipe, ki upravljajo podjetniški LLM API, to postane razlika med razpršenimi podatki za odpravljanje napak in ponudnikom nevtralnim operativnim modelom.

Najprej definirajte pogodbo o opazovanju

Začnite s pisno pogodbo o atributih, ne s posnetki zaslona nadzorne plošče. Pogodba mora opredeliti minimalne metapodatke, ki jih mora oddati vsaka zahteva LLM, katera polja smejo zapustiti prehod, katera polja so omejena in katera polja se nikoli ne izvozijo.

Uporabna osnovna pogodba vključuje metapodatke o lastništvu, usmerjanju, modelu, uporabi, zakasnitvi in ​​rezultatih. Atributi lastništva identificirajo organizacijo, ekipo, okolje, delovno obremenitev, aplikacijo in obseg ključa API. Atributi usmerjanja identificirajo prehodno pot, različico pravilnika, zahtevanega ponudnika, zahtevani model, izbranega ponudnika, izbrani model, število ponovnih poskusov, nadomestno število in ali je bilo uporabljeno pretakanje. Atributi uporabe zajamejo vhodne žetone, izhodne žetone, predpomnjene vhodne žetone, razumne žetone, ko so na voljo, število zahtev in ocenjeni stroškovni razred. Atributi izida zajamejo stanje, kodo napake ponudnika, ko je varno, normaliziran razred napake, rezultat preverjanja, stanje časovne omejitve in model končnega odziva.

Pogodbeni ponudnik naj bo nevtralen. Napaka, specifična za ponudnika, kot je odziv z omejitvijo hitrosti, odziv preobremenjenega modela, napaka pri preverjanju sheme, varnostna zavrnitev, časovna omejitev ali napaka kontekstnega okna, bi se morala preslikati v normaliziran razred napak, ki ga lahko nadzorne plošče združijo med ponudniki. Prvotna koda napake ponudnika je lahko uporabna, vendar jo je treba obravnavati kot omejene diagnostične podatke in ne kot primarno dimenzijo nadzorne plošče.

Uporabite model razpona s središčem na prehodu

Jasna struktura sledenja preprečuje, da bi telemetrija LLM postala ploski kup razponov. Za delo, ki ga opravlja prehod, uporabite en obseg zahtev za vhodno aplikacijo, en obseg logične operacije LLM in podrejene obsege.

Običajna hierarhija je videti takole:

inbound.http_request
  llm.operation
    llm.provider_attempt
    llm.provider_attempt.retry
    llm.provider_attempt.fallback
    retrieval.query
    tool.call
    output.validation

Razpon vhodnih zahtev predstavlja zahtevo klicatelja do prehoda. Logični razpon delovanja LLM predstavlja uporabniku vidno nalogo LLM, tudi če prehod večkrat poskusi ponudnika. Obseg poskusov ponudnika zajame vsak dejanski klic v model navzgor API. Razponi pridobivanja, orodja in preverjanja morajo biti podrejeni logični operaciji, ko so del izdelave končnega odgovora.

Ta ločitev je pomembna med incidenti. Če se zahteva vrne z enega modela na drugega, lahko logična operacija uspe, medtem ko prvi poskus ponudnika ne uspe. Če končni rezultat ne uspe preveriti veljavnosti sheme, je lahko poskus ponudnika tehnično uspešen, medtem ko logična operacija ne uspe. Brez ločenih razponov nadzorne plošče bodisi skrijejo napake ponudnika za uspešnimi odzivi končnega uporabnika bodisi pretiravajo z napakami, ki so bile uspešno obnovljene.

Preslikava atributov OpenTelemetry GenAI za notranjim preslikavom

Obstajajo semantične konvencije OpenTelemetry, tako da proizvajalci telemetrije uporabljajo skupna imena in atribute v kodnih bazah, knjižnicah in platformah.Projekt OpenTelemetry zdaj usmerja konvencije Generative AI v ločeno skladišče GenAI, te konvencije pa določajo atribute zahteve in odgovora modela, kot so ime ponudnika, zahtevani model, model odziva, vhodni žetoni, izhodni žetoni, žetoni za sklepanje in predpomnjeni vhodni žetoni.

Uporabite te atribute GenAI, kjer ustrezajo, vendar ne razpršite neobdelanih imen atributov po kodi prehoda. Ovijte jih za majhen telemetrični kartograf. Ta preslikava bi morala sprejeti interni zapis zahteve in izdelati standardizirane atribute razpona.

record LlmTelemetryContext {
  organization_id
  team_id
  environment
  api_key_scope
  route_name
  route_policy_version
  workload_class
  provider_requested
  model_requested
  provider_selected
  model_response
  input_tokens
  output_tokens
  cached_input_tokens
  reasoning_tokens
  retry_count
  fallback_count
  normalized_error_class
}

Preslikovalnik lahko odda atribute OpenTelemetry GenAI za standardna polja in atribute zasebnega prehoda za poslovni kontekst. Zasebne atribute hranite pod nadzorovanim imenskim prostorom, na primer llm_gateway.organization_id, llm_gateway.team_id, llm_gateway.key_scope, llm_gateway.route_policy in llm_gateway.workload_class.

Ta zasnova vam omogoča telemetrijo, ki je nevtralna glede prodajalca, hkrati pa ščiti kodno zbirko pred odlivom. Konvencije GenAI se še vedno razvijajo, zato je preslikava tista, kjer se lahko spremenijo imena brez urejanja vsakega obdelovalca, modula za ponovni poskus, adapterja za pretakanje in komponente za preverjanje veljavnosti.

Ločite metapodatke od občutljive vsebine

Sledi LLM so nenavadno občutljive, ker so lahko najuporabnejši podatki za razhroščevanje isti podatki, ki jih ne bi smeli hraniti na splošno: pozivi, pridobljeni dokumenti, orodje parametri, zaključki, identifikatorji uporabnikov, identifikatorji strank in neobdelane poverilnice ponudnika. Privzeta drža bi morala biti opaznost najprej metapodatkov.

Priporočena privzeta polja vključujejo zgoščeno vrednost poziva, ID predloge poziva, različico poziva, ID sheme, ime orodja, zbirko pridobivanja, ime poti, število žetonov, zakasnitev, normalizirani razred napak in status preverjanja. Ta polja odgovarjajo na mnoga operativna vprašanja brez izvoza neobdelane vsebine.

Neobdelani poziv in zajem dokončanja je treba omogočiti, časovno omejiti, nadzorovati dostop in redigirati pred izvozom. Ne omogočite ga globalno kot priročno funkcijo. Ko je za produkcijski incident potreben zajem vsebine, pripnite zastavico za odpravljanje napak ozkemu naboru zahtev, usmerite te sledi v omejeno zaledje in nastavite kratko obdobje hrambe.

Identifikatorji zgoščevanja niso samodejno anonimizirani. Če je vnosni prostor majhen ali predvidljiv, je mogoče zgoščene vrednosti obrniti z ugibanjem. Za občutljive identifikatorje strank ali uporabnikov razmislite o brisanju, nadomestnih ID-jih, razvrščanju v segmente, obrezovanju ali zgoščevanju s ključi s strogim nadzorom ključev. Zgoščene vrednosti uporabite predvsem za stabilno korelacijo, ko razumete tveganje, in ne kot splošen odgovor glede zasebnosti.

Uveljavite zasebnost v zbiralniku

Smernice OpenTelemetry pravijo, da je treba občutljive podatke obdelati pred izvozom. Zbiralnik lahko odstrani, zgosti, filtrira, redigira ali preoblikuje atribute telemetrije z uporabo procesorjev, kot so atributi, filtriranje, redigiranje in preoblikovanje. Zaradi tega je Collector druga obrambna linija po sami instrumentaciji prehoda.

Praktičen cevovod Collectorja bi moral uporabljati seznam dovoljenih za atribute z nizkim tveganjem, privzeto brisati neobdelana polja za pozive in odzive, maskirati vrednosti, ki se ujemajo z blokiranimi vzorci, in ločeno usmerjati bolj občutljive sledi, ko je zajem vsebine izrecno omogočen. Procesor atributov OpenTelemetry Collector podpira dejanja, kot sta brisanje in zgoščevanje. Procesor redigiranja je zasnovan za brisanje atributov, ki niso na seznamu dovoljenih, in prikrivanje vrednosti, ki se ujemajo z blokiranimi vzorci.

Na primer, prehod se lahko privzeto izogne ​​oddajanju neobdelane vsebine, medtem ko zbiralnik še vedno izbriše atribute, kot so llm.prompt.raw, llm.completion.raw, provider.api_key, authorization in cookie, če se pojavijo zaradi napake ali integracije knjižnice. Obravnavajte to kot poglobljen nadzor obrambe in ne kot razlog za naključno oddajanje nevarnih podatkov.

Ponovni poskusi instrumenta, nadomestne rešitve in preverjanje ločeno

Ponovni poskusi in nadomestne rešitve so pogosto nevidni v skupnih API meritvah. Ta nevidnost povzroča dve operativni težavi. Prvič, zakasnitev se lahko poslabša, ker lahko uspešen odgovor skrije več neuspelih poskusov.Drugič, stroški se lahko povečajo, ker lahko ena zahteva uporabnika ustvari več klicev modela navzgor.

Vsak obseg poskusov ponudnika mora vključevati število poskusov, razlog za ponovni poskus, izbranega ponudnika, izbrani model, proračun časovne omejitve, zakasnitev, uporabo žetona, ko je na voljo, in rezultat. Če pride do nadomestnega cilja, mora nadomestni razpon identificirati prvotno politiko poti, razlog za nadomestni način in model, ki je dejansko uporabljen za končni odziv.

Vrednotenje strukturiranega izhoda mora biti lasten razpon ali dogodek. Zajemite ID sheme, različico sheme, rezultat preverjanja, število poskusov popravila in končni status. Privzeto ne shranjujte celotnega neveljavnega izhoda. Napaka pri preverjanju veljavnosti se operativno razlikuje od napake pri prenosu ponudnika in nadzorne plošče ju ne bi smele zamegliti skupaj.

Izdelajte nadzorne plošče okrog vprašanj, ne ponudnikov

Ponudnikovo nevtralno opazovanje bi moralo neposredno odgovarjati na operativna vprašanja. Uporabne nadzorne plošče vključujejo zakasnitev p95 in p99 po modelu, ponudniku, ekipi, okolju in razredu delovne obremenitve; uporaba žetona po ekipi in poti; stopnja napak po normaliziranem razredu napak; ponovno poskusite povečati s politiko poti; pomožna frekvenca glede na zahtevani model; napake kontekstnega okna s predlogo poziva; napake validacije strukturiranih izhodov po shemi; in vzorčeni primeri sledenja za neuspešne, drage ali počasne zahteve.

Izključite poročanje o obračunavanju in skupni uporabi iz vzorčenih sledenj. Vzorčenje repa je uporabno za odpravljanje napak, vendar lahko popači skupne vrednosti. Skupni zneski žetonov, štetje zahtev in knjige stroškov morajo izhajati iz nevzorčenih števcev, knjig zahtev ali sistemov za usklajevanje zaračunavanja. Sledi bi morale pojasniti, zakaj je prišlo do drage ali počasne zahteve; ne bi smeli biti edini vir finančne resnice.

Uporabite repno vzorčenje za sledi visoke vrednosti

Procesor repnega vzorčenja OpenTelemetry Collector lahko sprejema odločitve o vzorčenju po zaključku razponov, vključno s pravilniki, ki temeljijo na atributih in številskih vrednostih. To je uporabno za promet LLM, ker pogosto veste, ali je sledenje dragoceno šele po končanem odgovoru.

Ohranite sledi za napake ponudnika, neuspešne potrditve, zelo visoko zakasnitev, nenavadno drago uporabo žetonov, napake kontekstnega okna, nadomestne poskuse in zahteve z ročno oznako za odpravljanje napak. Vzorčite rutinsko uspešen promet po nižji stopnji. To ohranja sledi, ki bodo najverjetneje razložile incidente, medtem ko nadzoruje prostornino shranjevanja.

Razumen model politike je preprost: vedno ohrani napake, vedno ohrani zahteve nad zakasnitvijo ali pragom žetona, vedno ohrani sledi z oznako za odpravljanje napak in verjetnostno vzorči običajne uspešne zahteve. Ko se promet spremeni, ponovno preglejte pragove. Prag, ki je uporaben med zgodnjo uvedbo, bo morda prenizek, ko se produkcijski promet poveča.

Dodajte pogodbene preizkuse za telemetrijo

Telemetrijo je treba preizkusiti kot API pogodbo, ker so nadzorne plošče, opozorila, nadzori stroškov in poteki dela odvisni od tega. Dodajte preizkuse, ki izvajajo reprezentativne zahteve prehoda, in potrdite, da so oddani zahtevani razponi in atributi.

Preizkusi morajo preveriti, ali uspešna zahteva odda logični razpon delovanja LLM, razpon poskusa ponudnika, zahtevani model, odzivni model, ime ponudnika, število žetonov, ko je na voljo, metapodatke skupine ali obsega ključa, različico pravilnika o poti in končno stanje. Preskusi ponovnega poskusa morajo navesti število poskusov in razloge za ponovni poskus. Nadomestni testi morajo potrditi neuspeli poskus in končni uspešen poskus ponudnika. Preizkusi preverjanja morajo potrditi ID sheme, status preverjanja in število poskusov popravila.

Varnostni preizkusi so enako pomembni. Potrdite, da v izvoženi telemetriji ni neobdelanih ključev ponudnika, avtorizacijskih glav, piškotkov, neobdelanih pozivov, neobdelanih dokončanj in neodobrenih identifikatorjev strank.Ti testi ne bi smeli biti zaključeni, ko razvijalec doda nov atribut razpona, ne da bi ga razvrstil.

Kontrolni seznam za implementacijo

• Pogodba o atributu: Definirajte obvezne, neobvezne, omejene in prepovedane atribute.
• Hirarhija razpona: Ločite vhodne zahteve, logične operacije LLM, poskusi ponudnika, ponovni poskusi, nadomestne možnosti, klici za iskanje, klici orodij in preverjanje veljavnosti.
• Semantično preslikavo: Uporabite atribute OpenTelemetry GenAI, kjer ustrezajo, in atribute zasebnega prehoda za lastništvo in kontekst usmerjanja.
• Politika zasebnosti: Privzeto na zgoščene vrednosti, ID-je predlog, ID-je shem, imena orodij, število žetonov, zakasnitev in razrede napak namesto neobdelane vsebine.
• Zbiralni procesorji: Brisanje prepovedanih polj, redigiranje blokiranih vzorcev, atributi nizkega tveganja na seznamu dovoljenih in ločeno usmerjanje občutljivih sledi.
• Vzorčenje pravilnik: Zadnje vzorčne sledi z visoko vrednostjo in ohranjanje združenih meritev nevzorčenih.
• Nadzorne plošče: Ustvarite poglede okoli zakasnitve, uporabe, napak, ponovnih poskusov, nadomestnih vrednosti, preverjanja veljavnosti in dejavnikov stroškov.
• Opozorila: Opozorilo o normalizirani napaki razredi, premiki zakasnitve p99, ojačanje ponovnega poskusa, nadomestni skoki, napake pri validaciji in anomalije žetonov.
• Pogodbeni preizkusi: Potrdite, da je zahtevana telemetrija prisotna, občutljiva telemetrija pa odsotna.

Kompromisi, o katerih se je treba odločiti Eksplicitno

Instrumentacija na ravni prehoda hitro zagotavlja dosledne metapodatke, vendar lahko zgreši kontekst, specifičen za aplikacijo, razen če ekipe posredujejo metapodatke strukturirane zahteve, kot so najemnik, potek dela, predloga poziva in ime funkcije. Naj bodo ti metapodatki del pogodbe o zahtevi prehoda, namesto da se zanašate na dnevnike v prosti obliki.

Popoln zajem vsebine izboljša odpravljanje napak in vrednotenje, vendar poveča zasebnost, varnost, hrambo in obremenitev nadzora dostopa. Številne ekipe bi morale začeti z zgoščenimi vrednostmi, ID-ji predlog, ID-ji shem in samo redigiranimi odlomki.

Razredi napak, nevtralni glede ponudnika, omogočajo uporabo nadzornih plošč v več API-jih modelov, vendar stisnejo podrobnosti, specifične za ponudnika. Neobdelane kode napak ponudnika hranite le, ko so varne, in omejite dostop do njih.

Konvencije OpenTelemetry GenAI zmanjšujejo zaklenjenost, vendar se bodo konvencije še naprej razvijale. Notranji preslikavec vam nudi prednosti standardizacije, ne da bi dovolili, da nestabilna imena atributov uhajajo skozi kodno zbirko.

Zaključek

Opazljivost LLM, nevtralna glede ponudnika, ni samo sledenje, dodano klicem modela. To je operativna pogodba na ravni prehoda: dosledni razponi, normalizirani model in metapodatki ponudnika, kontekst lastništva, uporaba žetona, vidnost ponovnih poskusov in nadomestnih možnosti, nadzor zasebnosti, pravila vzorčenja in testi, ki preprečujejo uhajanje občutljivih podatkov.

Začnite s prehodom, ker že vidi odločitve, ki so najpomembnejše: kdo je dal zahtevo, kateri pravilnik jo je usmeril, kateri ponudnik jo je stregel, kaj stalo je v žetonih, koliko časa je trajalo, ali je logika obnovitve delovala in kaj je odpovedalo. Ko je ta osnova stabilna, lahko aplikacijske skupine dodajo bogatejši kontekst delovnega toka, ne da bi si vsaka ekipa izmislila lasten sistem opazovanja LLM.

Sorodno branje

• nadomestna telemetrija usmerjanja