Opazljivost LLM v prehodu API-ja z več modeli: sledi, knjige žetonov, analitika najemnikov in varno beleženje pozivov

Skupno število zahtev in mesečna poraba nista dovolj, ko stranka vpraša, zakaj je en potek dela včeraj postal počasnejši, dražji ali manj zanesljiv. Prehod API z več modeli lahko odgovori na to vprašanje, če obravnava opazljivost kot del nadzorne ravnine: vsaka zahteva dobi sled, vsak klic modela posodobi knjigo uporabe, vsakemu najemniku in delovnemu toku je mogoče pripisati, občutljiva vsebina pa je privzeto zaščitena.

Ta članek opisuje praktično zasnovo za analizo uporabe umetne inteligence in opazovanje LLM v prehodu, ki se sooča z več ponudniki prek API-ja, združljivega z OpenAI. Vzorec je uporaben, tudi če ne uporabljate nobenega določenega prodajalca: instrumentirajte enkrat na prehodu, normalizirajte telemetrijo modela, ohranite dodeljevanje zaračunavanja in zajemite vsebino poziva samo v skladu z izrecnim pravilnikom.

Težava z bralnikom: »Kateri najemnik, model, poziv ali pot pridobivanja je povzročila spremembo?«

Večina ekip se sčasoma sooči z isto vrzeljo pri odpravljanju napak. Dnevniki aplikacije kažejo, da funkcija ni uspela. Nadzorne plošče ponudnika kažejo, da se je uporaba žetonov povečala. Finance vidijo račun. Nobeden od teh pogledov sam po sebi ne pojasnjuje celotne poti od zahteve najemnika do klica modela do konteksta pridobivanja za ponovni poskus do zaračunanih stroškov.

Cilj ni še ena nadzorna plošča s skupnim številom žetonov. Cilj je odgovoriti na operativna vprašanja, kot so:

• Kateri najemnik ali ključ API-ja je povzročil skokovito povečanje porabe?
• Ali se je zakasnitev povečala po spremembi vzdevka modela?
• Ali ponovni poskusi ali nadomestni poskusi dvojno štejejo stroške?
• Katera različica poziva porabi največ proračuna za napake?
• Ali je potek dela RAG postal drag, ker je priklic dodal preveč kontekstnih žetonov?
• Ali lahko podpira odpravljanje napak pri incidentu brez branja zasebnih uporabniških pozivov?

Dejstva, priporočila in napovedi

Dejstva: OpenTelemetry dokumentira generativne semantične konvencije in atribute umetne inteligence za operacije modela, vključno z imeni operacij, kot so chat, generate_content in text_completion. Ista dokumentacija opozarja, da lahko atributi vhodnih in izhodnih sporočil GenAI vsebujejo občutljive informacije ali PII in lahko zahtevajo filtriranje ali obrezovanje. Glavni ponudniki modelov razkrivajo tudi nadzorne plošče uporabe, API-je ali izvoze, ki lahko podpirajo usklajevanje na strani ponudnika, čeprav se podrobnosti razlikujejo glede na ponudnika.

Priporočila: Uporabite OpenTelemetry za sledenja, nevtralna glede ponudnika, vendar obdržite poslovne razsežnosti v lasti prehoda v lastnih atributih in knjigah. Privzeto ne shranjujte neobdelanih pozivov ali izhodov. Najprej shranite metapodatke, zgoščene vrednosti, število žetonov, ID-je predlog pozivov, imena shem, razrede napak in varnostne oznake. Dodajte zajem vsebine samo kot možnost izbire, z nadzorovanim dostopom in kratkotrajno hrambo odpravljanja napak.

Napoved: Opazljivost LLM bo postala manj povezana z nadzornimi ploščami izoliranih ponudnikov in bolj nadzornimi ravninami med ponudniki. Ekipe bodo pričakovale, da bo na enem mestu mogoče preiskati zakasnitve, stroške, kakovost, dogodke pravilnikov, obnašanje najemnikov in delte zaračunavanja po modelih.

Referenčna arhitektura: opazujte celotno pot zahteve

Prehod si lahko ogleda celoten življenjski cikel zahteve, ne da bi zahteval, da vsaka aplikacijska ekipa izdela telemetrijo po meri. Uporaben model sledenja se začne z enim nadrejenim razponom za dohodno zahtevo stranke in podrejenimi razponi za korake, ki vplivajo na stroške, zakasnitev in kakovost.

Priporočena struktura razpona

• Razpon zahtev za prehod: zahteva sprejeta, overjena, avtorizirana, omejena na hitrost in usmerjena.
• Razpon klica modela: ponudnik, model, delovanje, uporaba žetona, stanje odgovora in zakasnitev.
• Razpon pridobivanja: poizvedeni indeks, ID-ji dokumentov ali zgoščeni ID-ji, število kosov, zakasnitev pri pridobivanju in delež kontekstnega žetona.
• Razpon klica orodja: ime orodja, stanje, zakasnitev, razred napake in klasifikacija stranskih učinkov.
• Razpon ponovnega poskusa: razlog za ponovni poskus, številka poskusa, status ponudnika in inkrementalni strošek.
• Nadomestni razpon: izvirni model, nadomestni model, sprožilec, pravilnik o združljivosti in končni rezultat.
• Zaščitna ograja ali moderiranje: sproženi pravilnik, odločitev, oznake in ali je bil izhod blokiran ali preoblikovan.
• Obseg naknadne obdelave: preverjanje JSON, popravilo sheme, preverjanje navedb ali končno oblikovanje.

Nadrejeni razpon mora vsebovati stabilne identifikatorje korelacije. Podrejeni razpon mora imeti normalizirane tehnične lastnosti. Knjiga uporabe mora vsebovati trajne zapise o obračunavanju in analitiki. Izogibajte se vsiljevanju vseh informacij v oznake meritev; vrednosti z visoko kardinalnostjo, kot so ID-ji najemnikov, zgoščene vrednosti pozivov in ID-ji dokumentov, je bolje shraniti v sledovih, dnevnikih ali tabelah glavne knjige in jih nato združiti v nadzorne plošče.

Normalizirajte metapodatke, zajete ob vsakem klicu LLM

Vsaka vzorčna zahteva mora ustvariti dosleden zapis, ne glede na ponudnika. Natančna shema se bo razlikovala, praktični minimum pa izgleda takole:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "najemnik_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "ključ_789",
  "operacija": "klepet",
  "ponudnik": "ime_ponudnika",
  "model": "id-modela-ponudnika",
  "model_alias": "hitri-podporni-klepet",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "dokončano",
  "error_class": nič,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0,00492",
  "final_billed_cost_usd": nič,
  "finish_reason": "ustavi",
  "retry_count": 0,
  "fallback_used": napačno,
  "content_capture_policy": "samo metapodatki"
}

Dve ideji naj bosta ločeni: telemetrija pojasnjuje, kaj se je zgodilo, medtem ko knjiga uporabe beleži, kaj je treba zaračunati, uskladiti in poročati. Sklicujejo se drug na drugega z ID-ji zahtev in ID-ji sledenja, ni pa nujno, da živijo v istem sistemu za shranjevanje.

Izdelajte knjigo žetonov in stroškov, ne samo števcev

Števci žetonov so uporabni za grafikone, vendar ne zadostujejo za zaračunavanje ali preiskavo incidentov. Glavna knjiga bi morala predstavljati prehode stanj. Ustvarite vrstico, ko prehod sprejme zahtevo, nato pa jo posodobite, ko zahteva napreduje.

Uporabna stanja glavne knjige

• sprejeto: preverjanje pristnosti in pravilnika opravljeno.
• Posredovano: zahteva je bila poslana ponudniku.
• pretakanje: ponudnik je začel vračati žetone.
• končano: odgovor je bil uspešno končan.
• user_aborted: odjemalec je prekinil povezavo pred zaključkom.
• ponovni poskus: izveden je bil dodaten poskus ponudnika.
• fallback_used: po napaki ali ujemanju s pravilnikom je bil izbran drug model ali ponudnik.
• ni uspelo: zahteva se je končala brez uporabnega odgovora.
• usklajeno: podatki o uporabi ali stroških na strani ponudnika so bili primerjani in uporabljeni.

Ta model stanja pomaga odkriti običajne napake pri zaračunavanju in analitiki: pretočni odgovori, kjer je odjemalec prekinil povezavo, poskusi ponovnih poskusov, ki jih je zaračunal ponudnik, vendar so bili skriti pred uporabnikom, nadomestne poti, ki so štele napačen model, in predpomnilniške razlike v obračunavanju med ponudniki.

Uporabite konvencije OpenTelemetry GenAI in nato previdno razširite

Semantične konvencije OpenTelemetry GenAI zagotavljajo prenosljiv besednjak za operacije modelov. Uporabite te konvencije za običajne atribute, kot so ime operacije, ponudnik, model, parametri zahteve, razlogi za dokončanje odgovora, uporaba žetona in stanje napake, kjer veljajo.

Vendar konvencije, nevtralne glede ponudnika, ne bodo pokrivale vseh poslovnih razsežnosti v prehodu. Dodajte atribute v lasti prehoda ali stolpce glavne knjige za:

• ID najemnika, ID ekipe, ID stranke prodajalca in ID aplikacije;
• ID ključa API prehoda in obseg ključa;
• obračunski načrt, omejitev porabe in proračunska politika;
• vzdevek modela in različica pravilnika o usmerjanju;
• ID predloge poziva in različica poziva;
• ime delovnega toka in korak delovnega toka;
• ocenjeni stroški, končni zaračunani stroški in stanje usklajevanja.

Kompromis je kardinalnost. Ta polja so dragocena za preiskavo, vendar lahko povzročijo, da so meritve drage in hrupne, če se povsod uporabljajo kot oznake meritev. Praktično pravilo je: agregati z nizko kardinalnostjo gredo v metrike; identifikatorji z visoko kardinalnostjo gredo v sledi, dnevnike in poslovne knjige.

Oblikujte varen poziv in izhodno beleženje

Popolno hitro beleženje olajša odpravljanje napak, vendar poveča zasebnost, skladnost, shranjevanje in izpostavljenost tveganju notranjih informacij. Varnejša privzeta vrednost je možnost opazovanja metapodatkov.

Privzeto: samo metapodatki

Za večino produkcijskega prometa shranite:

• ID in različica predloge poziva;
• zgoščene vrednosti normaliziranih pozivov in rezultatov;
• vhodni, izhodni, predpomnjeni in kontekstni žetoni štejejo;
• ime odzivne sheme in izid preverjanja;
• varnostne oznake in politične odločitve;
• povzetki napak in razredi napak ponudnika;
• pridobivanje metapodatkov, ne neobdelanih dokumentov.

Privolitev: nadzorovan zajem vsebine

Če potrebujete neobdelano ali urejeno vsebino za globoko odpravljanje napak, zahtevajte izrecno politiko. Dobre kontrole vključujejo sezname dovoljenih okolja, soglasje najemnika, vzorčenje, največjo dolžino koristnega tovora, samodejno redigiranje, kratka obdobja hrambe, šifriranje, dostop na podlagi vlog, revizijske dnevnike in pot odobritve za občutljive incidente.

Ne obravnavajte redakcije kot popolne. Zmanjšuje tveganje; ga ne odpravi. Za regulirane ali visoko občutljive delovne obremenitve razmislite o shranjevanju samo zgoščenih vrednosti in ponovnem predvajanju težav v sintetičnem snopu z odobrenimi preskusnimi podatki.

Dodajte opaznost RAG kot ločeno plast

Generacija, razširjena s pridobivanjem, lahko spremeni kakovost in ceno. Beleženje le končnega klica modela skrije temeljni vzrok, ko pridobitelj vrne preveč kosov, zastarelih dokumentov ali nepomembnega konteksta.

Za vsak korak pridobivanja zajemite:

• indeks ali ime zbirke;
• strategija iskanja in model vdelave;
• ID-ji dokumentov ali zgoščeni ID-ji;
• število kosov in skupni žetoni konteksta;
• zakasnitev pri pridobivanju;
• porazdelitev najboljših rezultatov, če je na voljo;
• citiranost;
• ali je bil pridobljeni kontekst uporabljen v končnem odgovoru.

To vam omogoča razlikovanje med »model se je poslabšal« in »prinašalec je začel pošiljati nizkokakovosten ali pretiran kontekst«. Pomaga tudi pri prepoznavanju delovnih tokov, kjer kontekstni žetoni prevladujejo nad skupnimi stroški.

Uskladite uporabo prehoda z zaračunavanjem ponudnika

Ocene prehoda so na voljo takoj. Podatki o zaračunavanju na strani ponudnika so običajno počasnejši, vendar bolj verodostojni. Uporabi oboje.

Dnevno opravilo usklajevanja bi moralo primerjati vrstice glavne knjige prehoda z API-ji za uporabo ponudnika, API-ji za stroške, izvozi nadzorne plošče ali izvozi računov. Združi delte glede na ponudnika, model, projekt in časovno okno. Sledite razlikam ločeno za vhodne žetone, izhodne žetone, predpomnjene žetone, število zahtev in stroške.

Pogoste razlike pri usklajevanju

• Pretakanje prekine povezavo: prehod lahko vidi prekinjenega odjemalca, medtem ko ponudnik še vedno zaračunava ustvarjene žetone.
• Ponovni poskusi: večkratni poskusi se lahko zaračunajo, tudi če je vrnjen le en končni odgovor.
• Takojšnje predpomnjenje: ponudniki lahko obračunavanje predpomnjenih žetonov izpostavijo drugače.
• Zaokroževanje: majhne razlike na zahtevo lahko postanejo vidne v velikem obsegu.
• Popusti na pakete ali stopnje: računi ponudnika lahko uporabljajo cene, ki jih ocena v realnem času še ni poznala.
• Spremembe na strani ponudnika: cene modela, vedenje tokenizacije ali izvozi zaračunavanja se lahko sčasoma spremenijo.

Ko usklajevanje najde delto, se izogibajte tihemu prepisovanju vaše glavne knjige. Shranite prvotno oceno, vrednost, ki jo je uskladil ponudnik, vir uskladitve in kodo vzroka, če je znana.

Nadzorne plošče, ki odgovarjajo na operativna vprašanja

Začnite nadzorne plošče s težavami z bralci, ne z meritvami nečimrnosti. Uporabni pogledi vključujejo:

• cena na najemnika, ekipo, aplikacijo in potek dela;
• cena na uspešno nalogo, ne le cena na zahtevo;
• zakasnitev p50, p95 in p99 glede na ponudnika, model in vzdevek modela;
• nadomestna stopnja in stopnja ponovnih poskusov glede na pot;
• stopnja časovne omejitve in trendi razreda napak ponudnika;
• razmerje zadetkov predpomnilnika in ocena prihrankov predpomnilnika;
• stopnja napak pri validaciji strukturiranih izhodov;
• najboljše različice pozivov glede na napako pri porabi proračuna;
• Deljenje kontekstnega žetona RAG glede na potek dela;
• zaščitne ograje in zadetki klasifikatorja s hitrim vstavljanjem.

Za opozarjanje združite tehnične in poslovne signale. Nenaden porast porabe najemnika je lahko bolj nujen kot majhno globalno povečanje zakasnitve. Skok nadomestne stopnje po spremembi vzdevka modela lahko kaže na težavo združljivosti. Ponavljajoči se odgovori 401, 429 ali 5xx lahko kažejo na ključne težave, izčrpanost kvote ali nestabilnost ponudnika.

Minimalni tok implementacije za proxy, združljiv z OpenAI

Za posredniški strežnik /chat/completions je tok lahko preprost:

1. Prejmite zahtevo in dodelite request_id ter kontekst sledenja.
2. Preverite pristnost ključa prehoda in razrešite obseg najemnika, ekipe, aplikacije in pravilnika.
3. Ustvarite nadrejeni prehodni razpon.
4. Ustvarite vrstico glavne knjige s stanjem accepted.
5. Razreši vzdevek modela glede na model ponudnika in različico pravilnika usmerjanja.
6. Zabeleži metapodatke: operacijo, ID predloge poziva, ime sheme, zgoščeno vrednost poziva in pravilnik za zajemanje vsebine.
7. Začnite razpon klica modela z uporabo semantičnih atributov GenAI, kjer je to primerno.
8. Posredujte zahtevo izbranemu ponudniku.
9. Za pretakanje posodobite stanje, ko prispe prvi kos, in preštejte uporabo tako natančno, kot to dopušča odgovor ponudnika.
10. Po zaključku razčleni uporabo ponudnika, razlog zaključka, stanje in razred napake.
11. Posodobite knjigo z žetoni, ocenjenimi stroški, podrobnostmi o ponovnem poskusu/nadomestnem načinu in stanjem končne zahteve.
12. Oddajanje meritev iz glavne knjige in podatkov o razponu.
13. Zaženite dnevno uskladitev in shranite stroške, ki jih je potrdil ponudnik, ločeno od prvotne ocene.

Kontrolni seznam za uvedbo

• Določite ID-je kanoničnih zahtev in ID-je sledenja.
• Sprejmite atribute OpenTelemetry GenAI za skupno modelsko telemetrijo.
• Ustvarite knjigo uporabe prehoda s prehodi stanj zahtev.
• Normalizirajte dimenzije ponudnika, modela, vzdevka modela, najemnika, aplikacije in poteka dela.
• Izogibajte se visokokardinalnim raziskovalnim podatkom iz metričnih oznak.
• Privzeto naj bo neobdelani poziv in zajem izhoda onemogočen.
• Dodajte izrecne pravilnike za vzorčenje, urejanje, hrambo in nadzor dostopa.
• Zajemite metapodatke za pridobivanje za poteke dela RAG.
• Izdelajte nadzorne plošče za stroške, zakasnitev, zanesljivost, preverjanje in vedenje najemnikov.
• Uskladite ocene prehoda z izvozi uporabe in stroškov ponudnika.
• Opozorilo o skokih porabe, regresijah zakasnitev, nadomestnih skokih, napakah pri preverjanju in dogodkih, pomembnih za varnost.

Zaključek

Prehod z več modeli je pravo mesto za implementacijo opazovanja LLM, ker vidi zahteve, preden dosežejo katerega koli ponudnika, in lahko priloži poslovni kontekst, ki ga ponudniki ne poznajo. Najmočnejši dizajn ni "beleži vse." To je večplastni model: ponudniku nevtralne sledi za izvajanje, vzdržljiv žeton in knjiga stroškov za zaračunavanje, analitika najemnikov za upravljanje, metapodatki RAG za kakovost pridobivanja in zasebnostno hitro beleženje za varno odpravljanje napak.

Začnite z metapodatki, prehodi stanj in usklajevanjem. Zajem vsebine dodajte šele, ko so pravilnik, hramba in nadzor dostopa pripravljeni. To zaporedje daje razvijalcem dokaze, ki jih potrebujejo za odpravljanje napak v zakasnitvi, kakovosti in porabi, ne da bi opaznost spremenili v novo tveganje izpostavljenosti podatkov.

Sorodno branje

• ponovno poskusno in nadomestno vedenje v LLM API usmerjanje
• prompt predpomnjenje in paketni vzorci za nadzor stroškov
• upravljanje ključev API ekipe in omejitve porabe