Mogućnost promatranja LLM-a u API pristupniku s više modela: tragovi, knjige tokena, analitika zakupaca i sigurno bilježenje upita

Ukupni broj zahtjeva i mjesečna potrošnja nisu dovoljni kada klijent pita zašto je jedan tijek rada jučer postao sporiji, skuplji ili manje pouzdan. API pristupnik s više modela može odgovoriti na to pitanje ako promatra vidljivost kao dio kontrolne razine: svaki zahtjev dobiva praćenje, svaki poziv modela ažurira knjigu korištenja, svaki zakupac i tijek rada mogu se pripisati, a osjetljivi sadržaj zaštićen je prema zadanim postavkama.

Ovaj članak opisuje praktičan dizajn za analizu korištenja umjetne inteligencije i promatranje LLM-a u pristupniku koji se suočava s više pružatelja putem API-ja kompatibilnog s OpenAI-jem. Uzorak je koristan čak i ako ne koristite nijednog određenog dobavljača: instrumentirajte jednom na pristupniku, normalizirajte telemetriju modela, očuvajte atribuciju naplate i uhvatite promptni sadržaj samo prema izričitim pravilima.

Problem s čitačem: “Koji je stanar, model, upit ili put dohvaćanja uzrokovao promjenu?”

Većina timova na kraju se suočava s istim nedostatkom u otklanjanju pogrešaka. Dnevnici aplikacije pokazuju da značajka nije uspjela. Nadzorne ploče pružatelja pokazuju da se upotreba tokena povećala. Financije vide račun. Nijedan od tih prikaza, sam po sebi, ne objašnjava cijeli put od zahtjeva stanara do poziva modela do konteksta dohvaćanja za ponovni pokušaj do naplaćenog troška.

Cilj nije još jedna nadzorna ploča s ukupnim brojem tokena. Cilj je odgovoriti na operativna pitanja kao što su:

• Koji je zakupac ili API ključ uzrokovao skok potrošnje?
• Je li se latencija povećala nakon promjene pseudonima modela?
• Računaju li se ponovni pokušaji ili rezervni troškovi dvostruko?
• Koja inačica upita troši najviše proračuna za pogreške?
• Je li tijek rada RAG-a postao skup jer je dohvaćanje dodalo previše kontekstnih tokena?
• Može li podržati otklanjanje pogrešaka u incidentu bez čitanja privatnih korisničkih upita?

Činjenice, preporuke i predviđanja

Činjenice: OpenTelemetry dokumentira generativne AI semantičke konvencije i atribute za operacije modela, uključujući nazive operacija kao što su chat, generate_content i text_completion. Ista dokumentacija upozorava da atributi GenAI ulaznih i izlaznih poruka mogu sadržavati osjetljive informacije ili PII i mogu zahtijevati filtriranje ili skraćivanje. Glavni pružatelji modela također izlažu nadzorne ploče upotrebe, API-je ili izvoze koji mogu podržati usklađivanje na strani pružatelja, iako se detalji razlikuju ovisno o pružatelju.

Preporuke: Koristite OpenTelemetry za tragove neovisne o pružatelju usluga, ali zadržite poslovne dimenzije u vlasništvu pristupnika u svojim vlastitim atributima i knjigama. Ne spremajte neobrađene upite ili izlaze prema zadanim postavkama. Najprije pohranite metapodatke, hashove, brojeve tokena, ID-ove predložaka upita, nazive shema, klase pogrešaka i sigurnosne oznake. Dodajte snimanje sadržaja samo kao značajku otklanjanja pogrešaka s kontroliranim pristupom i kratkim zadržavanjem po izboru.

Predviđanje: Mogućnost promatranja LLM-a postat će manje u vezi s izoliranim nadzornim pločama pružatelja usluga, a više u pogledu kontrolnih ravnina između pružatelja usluga. Timovi će očekivati da će jedno mjesto istražiti kašnjenje, cijenu, kvalitetu, događaje u vezi s pravilima, ponašanje stanara i delte naplate po modelima.

Referentna arhitektura: promatrajte cijeli put zahtjeva

Gateway može vidjeti cijeli životni ciklus zahtjeva bez potrebe da svaki aplikacijski tim izgradi prilagođenu telemetriju. Korisni model praćenja počinje s jednim nadređenim rasponom za dolazni zahtjev korisnika i podređenim rasponom za korake koji utječu na cijenu, kašnjenje i kvalitetu.

Preporučena struktura raspona

• Raspon zahtjeva pristupnika: zahtjev prihvaćen, autentificiran, autoriziran, ograničen brzinom i usmjeren.
• Raspon poziva modela: pružatelj, model, operacija, upotreba tokena, status odgovora i latencija.
• Raspon dohvaćanja: upitani indeks, ID-ovi dokumenata ili raspršeni ID-ovi, broj dijelova, latencija dohvaćanja i dijeljenje tokena konteksta.
• Raspon poziva alata: naziv alata, status, latencija, klasa pogreške i klasifikacija nuspojava.
• Razdoblje ponovnog pokušaja: razlog ponovnog pokušaja, broj pokušaja, status pružatelja usluga i inkrementalni trošak.
• Zamjenski raspon: izvorni model, zamjenski model, okidač, pravila kompatibilnosti i konačni ishod.
• Zaštitna ograda ili raspon moderiranja: pokrenuta pravila, odluka, oznake i je li izlaz blokiran ili transformiran.
• Raspon naknadne obrade: JSON provjera valjanosti, popravak sheme, provjere citata ili konačno oblikovanje.

Nadređeni raspon treba sadržavati stabilne identifikatore korelacije. Dječji rasponi trebaju imati normalizirane tehničke atribute. Knjiga korištenja trebala bi sadržavati trajne zapise o naplati i analitici. Izbjegavajte forsiranje svih informacija u oznake metrike; vrijednosti visoke kardinalnosti kao što su ID-ovi stanara, brzi hashovi i ID-ovi dokumenata bolje je pohraniti u tragovima, zapisnicima ili tablicama glavne knjige, a zatim ih agregirati u nadzorne ploče.

Normalizirajte metapodatke snimljene na svakom LLM pozivu

Svaki model zahtjeva trebao bi proizvesti konzistentan zapis, bez obzira na davatelja. Točna shema će se razlikovati, ali praktični minimum izgleda ovako:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "stanar_id": "stanar_123",
  "team_id": "tim_456",
  "app_id": "support_bot",
  "gateway_key_id": "ključ_789",
  "operacija": "čavrljanje",
  "provider": "provider_name",
  "model": "id-modela-davatelja",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "dovršeno",
  "greška_klase": nula,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0,00492",
  "final_billed_cost_usd": null,
  "finish_reason": "zaustavi",
  "broj_ponovnih pokušaja": 0,
  "fallback_used": netočno,
  "content_capture_policy": "samo metapodaci"
}

Razdvojite dvije ideje: telemetrija objašnjava što se dogodilo, dok knjiga korištenja bilježi što treba naplatiti, uskladiti i prijaviti. Međusobno se referiraju ID-ovima zahtjeva i ID-ovima praćenja, ali ne moraju živjeti u istom sustavu pohrane.

Izradite knjigu tokena i troškova, a ne samo brojače

Brojači tokena korisni su za grafikone, ali nisu dovoljni za naplatu ili istragu incidenta. Glavna knjiga bi trebala predstavljati prijelaze stanja. Napravite red kada gateway prihvati zahtjev, a zatim ga ažurirajte kako zahtjev napreduje.

Korisna stanja glavne knjige

• prihvaćeno: provjere autentičnosti i pravila su prošle.
• proslijeđeno: zahtjev je poslan pružatelju.
• streaming: pružatelj je počeo vraćati tokene.
• dovršeno: odgovor je uspješno završen.
• user_aborted: klijent je prekinuo vezu prije završetka.
• ponovno: napravljen je dodatni pokušaj pružatelja.
• fallback_used: drugi model ili pružatelj odabran je nakon greške ili podudaranja pravila.
• nije uspio: zahtjev je završio bez upotrebljivog odgovora.
• usklađeno: podaci o korištenju ili cijeni na strani pružatelja uspoređeni su i primijenjeni.

Ovaj model stanja pomaže u otkrivanju uobičajenih pogrešaka u naplati i analitici: strujani odgovori u kojima je klijent prekinuo vezu, pokušaji ponovnih pokušaja koje je naplatio pružatelj, ali su skriveni od korisnika, rezervni putovi koji su prebrojavali krivi model i predmemorirane računovodstvene razlike među pružateljima.

Koristite OpenTelemetry GenAI konvencije, a zatim pažljivo proširite

Semantičke konvencije OpenTelemetry GenAI pružaju prijenosni rječnik za operacije modela. Koristite te konvencije za uobičajene atribute kao što su naziv operacije, pružatelj usluga, model, parametri zahtjeva, razlozi završetka odgovora, upotreba tokena i status pogreške tamo gdje se primjenjuju.

Međutim, konvencije neutralne prema pružatelju usluga neće pokriti svaku poslovnu dimenziju pristupnika. Dodajte atribute u vlasništvu pristupnika ili stupce glavne knjige za:

• ID stanara, ID tima, ID kupca preprodavača i ID aplikacije;
• ID ključa API-ja pristupnika i opseg ključa;
• plan naplate, ograničenje potrošnje i proračunska politika;
• pseudonim modela i verzija pravila usmjeravanja;
• ID predloška upita i verzija upita;
• naziv tijeka rada i korak tijeka rada;
• procijenjeni trošak, konačni naplaćeni trošak i status usklađivanja.

Kompromis je kardinalnost. Ova su polja vrijedna za istraživanje, ali mogu učiniti metriku skupom i bučnom ako se svugdje koriste kao metričke oznake. Praktično pravilo je: agregati niske kardinalnosti idu u metriku; identifikatori visoke kardinalnosti idu u tragove, zapisnike i knjige.

Dizajnirajte sigurnu obavijest i izlaznu evidenciju

Potpuno brzo bilježenje olakšava otklanjanje pogrešaka, ali povećava privatnost, usklađenost, pohranu i izloženost riziku od insajdera. Sigurnija zadana vrijednost je mogućnost promatranja na prvom mjestu metapodataka.

Zadano: samo metapodaci

Za većinu proizvodnog prometa pohranite:

• ID predloška upita i verzija;
• rasprskavanja normaliziranih upita i izlaza;
• ulazni, izlazni, predmemorirani i kontekstni tokeni se broje;
• naziv sheme odgovora i ishod provjere;
• sigurnosne oznake i odluke o politici;
• sažeci grešaka i klase grešaka pružatelja;
• metapodatke za pronalaženje, a ne neobrađene dokumente.

Uključivanje: kontrolirano snimanje sadržaja

Ako trebate neobrađeni ili redigirani sadržaj za dubinsko otklanjanje pogrešaka, zahtijevajte eksplicitna pravila. Dobre kontrole uključuju popise dopuštenih okruženja, pristanak stanara, uzorkovanje, maksimalnu duljinu korisnog opterećenja, automatsko uređivanje, kratke prozore zadržavanja, enkripciju, pristup temeljen na ulogama, revizijske zapisnike i stazu odobrenja za osjetljive incidente.

Nemojte redakciju smatrati savršenom. Smanjuje rizik; ne eliminira ga. Za regulirana ili visokoosjetljiva radna opterećenja, razmislite o pohranjivanju samo raspršenih oznaka i ponavljanju problema u sintetičkom paketu s odobrenim testnim podacima.

Dodajte RAG vidljivost kao zaseban sloj

Generacija proširenog dohvaćanja može promijeniti kvalitetu i cijenu. Bilježenje samo posljednjeg poziva modela skriva glavni uzrok kada dohvaćač vrati previše dijelova, ustajale dokumente ili nevažan kontekst.

Za svaki korak dohvaćanja, snimite:

• indeks ili naziv zbirke;
• strategija dohvaćanja i model ugradnje;
• ID-ovi dokumenata ili raspršeni ID-ovi;
• broj dijelova i ukupni kontekst tokena;
• kašnjenje dohvaćanja;
• distribucija najboljih rezultata, ako je dostupna;
• citiranost;
• je li dohvaćeni kontekst korišten u konačnom odgovoru.

Ovo vam omogućuje razlikovanje "model se pogoršao" od "retriver je počeo slati kontekst niske kvalitete ili pretjeran." Također pomaže identificirati tijekove rada u kojima kontekstualni tokeni dominiraju ukupnim troškom.

Uskladite korištenje pristupnika s naplatom davatelja usluge

Procjene pristupnika dostupne su odmah. Podaci o naplati na strani pružatelja usluge obično su sporiji, ali vjerodostojniji. Koristite oboje.

Dnevni posao usklađivanja trebao bi usporediti redove glavne knjige pristupnika s API-jima za korištenje pružatelja usluga, API-jima za troškove, izvozima nadzorne ploče ili izvozima faktura. Grupirajte delte prema dobavljaču, modelu, projektu i vremenskom prozoru. Odvojeno pratite razlike za ulazne tokene, izlazne tokene, predmemorirane tokene, broj zahtjeva i cijenu.

Uobičajene razlike u usklađivanju

• Streaming prekida vezu: pristupnik može vidjeti prekinutog klijenta dok pružatelj još uvijek naplaćuje generirane tokene.
• Ponovni pokušaji: višestruki pokušaji mogu se naplatiti čak i ako je vraćen samo jedan konačni odgovor.
• Brzo predmemoriranje: pružatelji usluga mogu drugačije izložiti računovodstvo predmemoriranih tokena.
• Zaokruživanje: male razlike po zahtjevu mogu postati vidljive u mjerilu.
• Popusti na serije ili razine: fakture dobavljača mogu primjenjivati cijene koje procjena u stvarnom vremenu još nije znala.
• Promjene na strani pružatelja usluga: cijene modela, ponašanje tokenizacije ili izvozi naplate mogu se promijeniti tijekom vremena.

Kada se usklađivanjem pronađe delta, izbjegavajte tiho prepisivanje vaše glavne knjige. Pohranite izvornu procjenu, vrijednost koju je usklađivao pružatelj usluga, izvor usklađivanja i šifru razloga ako je poznata.

Nadzorne ploče koje odgovaraju na operativna pitanja

Pokrenite nadzorne ploče od problema s čitačem, a ne od metrike taštine. Korisni pogledi uključuju:

• cijena po zakupcu, timu, aplikaciji i tijeku rada;
• cijena po uspješnom zadatku, a ne samo cijena po zahtjevu;
• kašnjenje p50, p95 i p99 po pružatelju, modelu i aliasu modela;
• stopa zamjene i stopa ponovnih pokušaja po ruti;
• stopa čekanja i trendovi klasa grešaka pružatelja;
• omjer pogodaka predmemorije i procjena uštede predmemoriranih tokena;
• stopa neuspjeha provjere valjanosti strukturiranog izlaza;
• najbolje verzije upita prema pogrešci proračuna;
• dijeljenje tokena RAG konteksta po tijeku rada;
• blokovi zaštitne ograde i pogoci klasifikatora s brzim ubacivanjem.

Za uzbunjivanje, kombinirajte tehničke i poslovne signale. Iznenadni skok potrošnje stanara može biti hitniji od malog globalnog povećanja latencije. Skok povratne stope nakon promjene aliasa modela može ukazivati ​​na problem kompatibilnosti. Ponovljeni odgovori 401, 429 ili 5xx mogu ukazivati na ključne probleme, iscrpljenost kvota ili nestabilnost pružatelja usluga.

Minimalni tijek implementacije za proxy kompatibilan s OpenAI

Za /chat/completions proxy tijek može biti jednostavan:

1. Primite zahtjev i dodijelite request_id i kontekst praćenja.
2. Provjerite autentičnost ključa pristupnika i razriješite zakupca, tim, aplikaciju i opseg pravila.
3. Stvorite nadređeni raspon pristupnika.
4. Stvorite red glavne knjige sa stanjem accepted.
5. Razriješite pseudonim modela prema modelu pružatelja usluga i verziji pravila usmjeravanja.
6. Metapodaci za snimanje: operacija, ID predloška upita, naziv sheme, hash upita i politika snimanja sadržaja.
7. Započnite raspon poziva modela koristeći semantičke atribute GenAI gdje je primjenjivo.
8. Proslijedite zahtjev odabranom pružatelju usluga.
9. Za strujanje, ažurirajte stanje kada stigne prvi dio i brojite korištenje onoliko precizno koliko dopušta odgovor pružatelja.
10. Nakon završetka, raščlanite upotrebu pružatelja usluga, razlog završetka, status i klasu pogreške.
11. Ažurirajte glavnu knjigu tokenima, procijenjenim troškovima, pojedinostima o ponovnim pokušajima/rezervnim pokušajima i konačnim stanjem zahtjeva.
12. Emitira mjerne podatke iz glavne knjige i podatke raspona.
13. Pokrenite dnevno usklađivanje i trošak koji je potvrdio dobavljač odvojeno od izvorne procjene.

Kontrolni popis za uvođenje

• Definirajte kanonske ID-ove zahtjeva i ID-ove praćenja.
• Usvojite OpenTelemetry GenAI atribute za uobičajeni model telemetrije.
• Stvorite knjigu korištenja pristupnika s prijelazima stanja zahtjeva.
• Normalizirajte dimenzije dobavljača, modela, pseudonima modela, stanara, aplikacije i tijeka rada.
• Držite podatke istraživanja visoke kardinalnosti dalje od metričkih oznaka.
• Učini neobrađeni upit i snimanje izlaza onemogućenim prema zadanim postavkama.
• Dodajte eksplicitna pravila za uzorkovanje, uređivanje, zadržavanje i kontrolu pristupa.
• Snimite metapodatke za dohvaćanje za RAG tijekove rada.
• Izradite nadzorne ploče za troškove, kašnjenje, pouzdanost, provjeru valjanosti i ponašanje stanara.
• Uskladite procjene pristupnika s upotrebom pružatelja usluga i izvozom troškova.
• Upozorenje o porastu potrošnje, regresiji latencije, povratnim skokovima, pogrešnim provjerama valjanosti i događajima relevantnim za sigurnost.

Zaključak

Gateway s više modela pravo je mjesto za implementaciju promatranja LLM-a jer vidi zahtjeve prije nego što dođu do bilo kojeg pružatelja i može priložiti poslovni kontekst koji pružatelji ne znaju. Najjači dizajn nije "bilježiti sve". To je slojeviti model: tragovi za izvršavanje neutralni prema pružatelju usluga, trajni token i knjiga troškova za naplatu, analitika zakupca za upravljanje, RAG metapodaci za kvalitetu dohvaćanja i bilježenje upita na prvom mjestu privatnosti za sigurno otklanjanje pogrešaka.

Počnite s metapodacima, prijelazima stanja i usklađivanjem. Dodajte snimanje sadržaja samo kada su pravila, zadržavanje i kontrole pristupa spremni. Taj slijed daje programerima dokaze koji su im potrebni za otklanjanje pogrešaka u kašnjenju, kvaliteti i potrošnji bez pretvaranja vidljivosti u novi rizik izloženosti podacima.

Povezano čitanje

• ponašanje ponovnog pokušaja i vraćanja u LLM API usmjeravanje
• brzo predmemoriranje i skupni obrasci kontrole troškova
• upravljanje ključevima timskog API-ja i ograničenja potrošnje