Pozorovateľnosť LLM vo viacmodelovej bráne API: Sledovanie, účtovné knihy tokenov, analýza nájomníkov a bezpečné protokolovanie výziev

Súhrnné počty žiadostí a mesačné výdavky nestačia, keď sa zákazník pýta, prečo sa jeden pracovný postup včera spomalil, predražil alebo bol menej spoľahlivý. Viacmodelová brána API môže na túto otázku odpovedať, ak vníma pozorovateľnosť ako súčasť riadiacej roviny: každá požiadavka dostane sledovanie, každé volanie modelu aktualizuje knihu používania, každému nájomníkovi a pracovnému postupu je možné pripísať a citlivý obsah je predvolene chránený.

Tento článok popisuje praktický návrh analýzy používania AI a pozorovateľnosti LLM v bráne, ktorá slúži viacerým poskytovateľom prostredníctvom rozhrania API kompatibilného s OpenAI. Vzor je užitočný aj vtedy, ak nepoužívate žiadneho konkrétneho dodávateľa: zariadenie raz na bráne, normalizovanie telemetrie modelu, zachovanie priradenia fakturácie a zachytávanie okamžitého obsahu iba na základe explicitných pravidiel.

Problém s čítačkou: „Ktorý nájomník, model, výzva alebo cesta na získanie spôsobili zmenu?“

Väčšina tímov nakoniec čelí rovnakej medzere v ladení. Protokoly aplikácie ukazujú, že funkcia zlyhala. Panely poskytovateľa ukazujú, že využitie tokenov sa zvýšilo. Financie vidí účet. Žiadne z týchto zobrazení samo osebe nevysvetľuje celú cestu od požiadavky nájomcu po modelové volanie až po kontext načítania s cieľom zopakovať pokus o fakturované náklady.

Cieľom nie je ďalší informačný panel s celkovým počtom tokenov. Cieľom je odpovedať na operačné otázky, ako napríklad:

• Ktorý nájomník alebo kľúč rozhrania API spôsobil prudký nárast výdavkov?
• Zvýšila sa latencia po zmene aliasu modelu?
• Započítavajú sa náklady na opakované alebo záložné reklamy dvakrát?
• Ktorá promptná verzia spôsobuje najviac chýb?
• Stal sa pracovný postup RAG drahý, pretože načítanie pridalo príliš veľa kontextových tokenov?
• Môže podporovať ladenie incidentu bez čítania výziev súkromných používateľov?

Fakty, odporúčania a predpovede

Fakty: OpenTelemetry dokumentuje generatívne sémantické konvencie a atribúty AI pre modelové operácie vrátane názvov operácií, ako je chat, generation_content a text_completion. Rovnaká dokumentácia varuje, že atribúty vstupných a výstupných správ GenAI môžu obsahovať citlivé informácie alebo PII a môžu vyžadovať filtrovanie alebo skrátenie. Hlavní poskytovatelia modelov tiež odhaľujú panely používania, rozhrania API alebo exporty, ktoré môžu podporovať zosúladenie na strane poskytovateľa, hoci podrobnosti sa u jednotlivých poskytovateľov líšia.

Odporúčania: Používajte OpenTelemetry na sledovanie neutrálne voči poskytovateľom, no obchodné dimenzie vlastnené bránou ponechajte vo svojich vlastných atribútoch a účtovných knihách. Predvolene neukladajte nespracované výzvy ani výstupy. Najskôr uložte metadáta, hash, počty tokenov, ID šablón výzvy, názvy schém, triedy chýb a bezpečnostné štítky. Pridajte zachytávanie obsahu iba ako voliteľnú funkciu ladenia s riadeným prístupom a krátkym uchovávaním.

Predpoveď: Pozorovateľnosť LLM bude menej o izolovaných dashboardoch poskytovateľov a viac o riadiacich rovinách medzi poskytovateľmi. Tímy budú očakávať, že na jednom mieste sa bude skúmať latencia, náklady, kvalita, udalosti zásad, správanie nájomníkov a rozdiely vo fakturácii v rámci modelov.

Referenčná architektúra: dodržujte celú cestu požiadavky

Brána môže vidieť celý životný cyklus požiadavky bez toho, aby si každý aplikačný tím musel vytvoriť vlastnú telemetriu. Užitočný model sledovania začína jedným rodičovským rozsahom pre prichádzajúcu požiadavku zákazníka a podradeným rozsahom krokov, ktoré ovplyvňujú cenu, latenciu a kvalitu.

Odporúčaná štruktúra rozsahu

• Rozsah požiadaviek brány: žiadosť bola prijatá, overená, autorizovaná, s obmedzenou rýchlosťou a smerovaná.
• Rozsah hovoru modelu: poskytovateľ, model, operácia, využitie tokenu, stav odpovede a latencia.
• Rozsah načítania: dopytovaný index, ID dokumentov alebo hashované ID, počet blokov, latencia načítania a zdieľanie kontextového tokenu.
• Rozsah volania nástroja: názov nástroja, stav, latencia, trieda chýb a klasifikácia vedľajších účinkov.
• Rozsah opakovania: dôvod opakovania, číslo pokusu, stav poskytovateľa a prírastkové náklady.
• Rozpätie záložných reklám: pôvodný model, záložný model, spúšťač, pravidlá kompatibility a konečný výsledok.
• Rozpätie ochrany alebo moderovania: vyvolané pravidlo, rozhodnutie, označenia a či bol výstup zablokovaný alebo transformovaný.
• Rozsah po spracovaní: overenie JSON, oprava schémy, kontrola citácií alebo konečné formátovanie.

Rodičovský rozsah by mal niesť identifikátory stabilnej korelácie. Rozpätia potomkov by mali niesť normalizované technické atribúty. Kniha používania by mala obsahovať trvalé fakturačné a analytické záznamy. Vyhnite sa vnucovaniu všetkých informácií do štítkov metrík; hodnoty s vysokou kardinalitou, ako sú ID nájomníkov, rýchle hash a ID dokumentov, sa lepšie ukladajú do sledovania, denníkov alebo tabuliek účtovných kníh a potom sa agregujú do informačných panelov.

Normalizácia metadát zachytených pri každom hovore LLM

Každá žiadosť o model by mala vytvoriť konzistentný záznam bez ohľadu na poskytovateľa. Presná schéma sa bude líšiť, ale praktické minimum vyzerá takto:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operácia": "chat",
  "provider": "názov_poskytovateľa",
  "model": "id-model-poskytovateľa",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "dokončené",
  "error_class": null,
  "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": "stop",
  "retry_count": 0,
  "fallback_used": nepravda,
  "content_capture_policy": "len metadata"
}

Uchovávajte dva nápady oddelene: telemetria vysvetľuje, čo sa stalo, zatiaľ čo kniha používania zaznamenáva, čo by sa malo účtovať, odsúhlasiť a nahlásiť. Odkazujú sa navzájom pomocou ID požiadaviek a ID sledovania, ale nemusia žiť v rovnakom úložnom systéme.

Vytvorte si token a účtovnú knihu nákladov, nielen počítadlá

Počítadlá tokenov sú užitočné pre grafy, ale nestačia na účtovanie alebo vyšetrovanie incidentov. Účtovná kniha by mala predstavovať prechody stavov. Vytvorte riadok, keď brána prijme požiadavku, a potom ho aktualizujte v priebehu požiadavky.

Užitočné stavy účtovnej knihy

• prijaté: overenie a kontrola pravidiel prebehla úspešne.
• poslané: žiadosť bola odoslaná poskytovateľovi.
• streamovanie: poskytovateľ začal vracať tokeny.
• dokončené: odpoveď bola úspešne dokončená.
• user_aborted: klient sa odpojil pred dokončením.
• opakovaný pokus: bol vykonaný ďalší pokus poskytovateľa.
• fallback_used: po zlyhaní alebo zhode s pravidlami bol vybratý iný model alebo poskytovateľ.
• zlyhalo: žiadosť sa skončila bez použiteľnej odpovede.
• odsúhlasené: údaje o používaní alebo nákladoch na strane poskytovateľa boli porovnané a použité.

Tento model stavu pomáha zachytiť bežné chyby fakturácie a analýzy: streamované odpovede, keď sa klient odpojil, opakované pokusy, ktoré boli účtované poskytovateľom, ale skryté pred používateľom, záložné cesty, ktoré počítali nesprávny model, a rozdiely v účtovaní medzi poskytovateľmi vo vyrovnávacej pamäti.

Použite konvencie OpenTelemetry GenAI a potom ich opatrne rozšírte

Sémantické konvencie OpenTelemetry GenAI poskytujú prenosný slovník pre modelové operácie. Tieto konvencie použite pre bežné atribúty, ako je názov operácie, poskytovateľ, model, parametre požiadavky, dôvody dokončenia odpovede, použitie tokenu a chybový stav tam, kde sa uplatňujú.

Konvencie neutrálne voči poskytovateľom však nepokrývajú všetky obchodné dimenzie v bráne. Pridajte atribúty alebo stĺpce účtovnej knihy vlastnené bránou pre:

• ID nájomníka, ID tímu, ID zákazníka predajcu a ID aplikácie;
• ID kľúča rozhrania API brány a rozsah kľúča;
• plán fakturácie, limit výdavkov a zásady rozpočtu;
• verzia aliasu modelu a smerovania;
• ID šablóny výzvy a verzia výzvy;
• názov pracovného postupu a krok pracovného postupu;
• odhadované náklady, konečné fakturované náklady a stav vyrovnania.

Komisom je mohutnosť. Tieto polia sú cenné pre skúmanie, ale môžu spôsobiť, že metriky budú drahé a hlučné, ak sa všade používajú ako štítky metrík. Praktické pravidlo je: agregáty s nízkou kardinalitou idú do metrík; identifikátory s vysokou kardinalitou prechádzajú do stôp, protokolov a účtovných kníh.

Navrhnite bezpečnú výzvu a protokolovanie výstupu

Úplné rýchle protokolovanie uľahčuje ladenie, ale zvyšuje súkromie, súlad s predpismi, úložisko a vystavenie vnútornému riziku. Bezpečnejšie predvolené nastavenie je pozorovateľnosť na prvom mieste metadát.

Predvolené: iba metadáta

Pre väčšinu produkčnej prevádzky uložte:

• ID a verziu šablóny výzvy;
• hash normalizovaných výziev a výstupov;
• počet vstupných, výstupných, uložených a kontextových tokenov;
• názov schémy odpovede a výsledok overenia;
• bezpečnostné označenia a politické rozhodnutia;
• súhrny chýb a triedy chýb poskytovateľa;
• získavanie metadát, nie nespracovaných dokumentov.

Prihlásenie: kontrolované zaznamenávanie obsahu

Ak na hlboké ladenie potrebujete nespracovaný alebo upravený obsah, požadujte explicitné pravidlá. Medzi dobré ovládacie prvky patria zoznamy povolených prostredí, súhlas nájomníka, vzorkovanie, maximálna dĺžka užitočného zaťaženia, automatická úprava, krátke obdobia uchovávania, šifrovanie, prístup na základe rolí, protokoly auditu a spôsob schvaľovania citlivých incidentov.

Nepovažujte redakciu za dokonalú. Znižuje riziko; nevylučuje to. V prípade regulovaného pracovného zaťaženia alebo pracovného zaťaženia s vysokou citlivosťou zvážte ukladanie iba hash a prehrávanie problémov v syntetickom zväzku so schválenými testovacími údajmi.

Pridajte pozorovateľnosť RAG ako samostatnú vrstvu

Generácia rozšírená o získavanie môže zmeniť kvalitu aj cenu. Zaznamenávanie iba posledného volania modelu skryje hlavnú príčinu, keď retriever vráti príliš veľa kusov, zastarané dokumenty alebo irelevantný kontext.

Pre každý krok načítania zaznamenajte:

• názov indexu alebo kolekcie;
• stratégiu získavania a model vkladania;
• ID dokumentov alebo hashované ID;
• počet blokov a celkový počet tokenov kontextu;
• latencia načítania;
• rozdelenie najvyššieho skóre, ak je k dispozícii;
• pokrytie citácií;
• či sa v konečnej odpovedi použil načítaný kontext.

To vám umožní rozlíšiť „model sa zhoršil“ od „retriever začal odosielať nekvalitný alebo nadmerný kontext.“ Pomáha tiež identifikovať pracovné postupy, v ktorých celkové náklady dominujú kontextové tokeny.

Zladenie používania brány s fakturáciou poskytovateľa

Odhady brány sú k dispozícii okamžite. Fakturačné údaje na strane poskytovateľa sú zvyčajne pomalšie, ale smerodajnejšie. Použite oboje.

Denná úloha zosúlaďovania by mala porovnávať riadky účtovnej knihy brány s rozhraniami API na používanie poskytovateľa, rozhraniami API pre náklady, exportmi informačných panelov alebo exportmi faktúr. Zoskupte delty podľa poskytovateľa, modelu, projektu a časového okna. Oddelene sledujte rozdiely pre vstupné tokeny, výstupné tokeny, tokeny vo vyrovnávacej pamäti, počty žiadostí a náklady.

Bežné rozdiely v zosúlaďovaní

• Streamovanie sa odpojí: brána môže vidieť prerušeného klienta, zatiaľ čo poskytovateľ stále účtuje vygenerované tokeny.
• Opakované pokusy: môžu byť účtované viaceré pokusy, aj keď sa vráti iba jedna posledná odpoveď.
• Výzva ukladanie do vyrovnávacej pamäte: poskytovatelia môžu účtovanie tokenov uložených vo vyrovnávacej pamäti vystaviť odlišne.
• Zaokrúhľovanie: malé rozdiely medzi jednotlivými požiadavkami môžu byť viditeľné vo veľkom rozsahu.
• Dávkové alebo viacúrovňové zľavy: faktúry poskytovateľa môžu uplatňovať ceny, ktoré odhad v reálnom čase ešte nepoznal.
• Zmeny na strane poskytovateľa: modelové stanovovanie cien, tokenizácia alebo exporty fakturácie sa môžu časom meniť.

Keď zmierenie nájde deltu, vyhnite sa tichému prepisovaniu účtovnej knihy. Uložte pôvodný odhad, hodnotu odsúhlasenú poskytovateľom, zdroj vyrovnania a kód príčiny, ak je známy.

Informačné panely, ktoré odpovedajú na prevádzkové otázky

Spustite informačné panely z problémov s čítačkou, nie z metrických údajov. Užitočné zobrazenia zahŕňajú:

• náklady na nájomníka, tím, aplikáciu a pracovný postup;
• cena za úspešnú úlohu, nielen cena za žiadosť;
• latencia p50, p95 a p99 podľa poskytovateľa, modelu a aliasu modelu;
• počet záložných reklám a počet opakovaní podľa trasy;
• miera uplynutia časového limitu a trendy triedy chýb poskytovateľa;
• pomer prístupov do vyrovnávacej pamäte a odhad úspory tokenov uložených vo vyrovnávacej pamäti;
• miera zlyhania overenia štruktúrovaného výstupu;
• najlepšie rýchle verzie podľa chybového spálenia rozpočtu;
• Zdieľanie kontextového tokenu RAG podľa pracovného postupu;
• zábradlia a zásahy klasifikátora rýchleho vstreknutia.

Ak chcete upozorniť, kombinujte technické a obchodné signály. Náhly nárast výdavkov nájomníkov môže byť naliehavejší ako malé globálne zvýšenie latencie. Skok záložnej rýchlosti po zmene aliasu modelu môže naznačovať problém s kompatibilitou. Opakované odpovede 401, 429 alebo 5xx môžu poukazovať na kľúčové problémy, vyčerpanie kvóty alebo nestabilitu poskytovateľa.

Minimálny postup implementácie pre proxy kompatibilný s OpenAI

V prípade /chat/completions proxy môže byť postup jednoduchý:

1. Prijmite požiadavku a priraďte request_id a sledujte kontext.
2. Overte kľúč brány a vyriešte rozsah nájomníka, tímu, aplikácie a pravidiel.
3. Vytvorte rozsah nadradenej brány.
4. Vytvorte riadok účtovnej knihy so stavom akceptované.
5. Vyriešte alias modelu na model poskytovateľa a verziu politiky smerovania.
6. Metadáta záznamu: operácia, ID šablóny výzvy, názov schémy, hash výzvy a politika zachytávania obsahu.
7. V prípade potreby začnite rozsah hovorov modelu pomocou sémantických atribútov GenAI.
8. Pošlite žiadosť vybranému poskytovateľovi.
9. Pri streamovaní aktualizujte stav, keď príde prvý blok, a počítajte využitie tak presne, ako to umožňuje odpoveď poskytovateľa.
10. Po dokončení analyzujte využitie poskytovateľa, dôvod dokončenia, stav a triedu chýb.
11. Aktualizujte účtovnú knihu o tokeny, odhadovanú cenu, podrobnosti o opakovanom pokuse/záložnom postupe a o poslednom stave žiadosti.
12. Vysielajte metriky z údajov hlavnej knihy a rozsahu.
13. Spúšťajte denné vyrovnanie a uložte náklady potvrdené poskytovateľom oddelene od pôvodného odhadu.

Kontrolný zoznam zavádzania

• Definujte kanonické ID žiadostí a ID sledovania.
• Prijmite atribúty OpenTelemetry GenAI pre telemetriu bežného modelu.
• Vytvorte knihu používania brány s prechodmi stavu požiadaviek.
• Normalizácia dimenzií poskytovateľa, modelu, aliasu modelu, nájomníka, aplikácie a pracovného postupu.
• Uchovávajte údaje z vyšetrovania s vysokou kardinalitou mimo označenia metrík.
• V predvolenom nastavení zakázať nespracované výzvy a zachytávanie výstupu.
• Pridajte explicitné pravidlá pre vzorkovanie, redigovanie, uchovávanie a riadenie prístupu.
• Zachytenie metadát získavania pre pracovné postupy RAG.
• Vytvorte informačné panely pre náklady, latenciu, spoľahlivosť, overovanie a správanie nájomníkov.
• Zladte odhady brány s využitím poskytovateľa a exportom nákladov.
• Upozornenie na prudké nárasty výdavkov, regresie latencie, záložné skoky, zlyhania overenia a udalosti súvisiace so zabezpečením.

Záver

Multimodelová brána je tým správnym miestom na implementáciu pozorovateľnosti LLM, pretože vidí požiadavky skôr, ako sa dostanú k akémukoľvek poskytovateľovi, a môže pripojiť obchodný kontext, ktorý poskytovatelia nepoznajú. Najsilnejší dizajn nie je „zaznamenať všetko“. Ide o vrstvený model: sledovanie na vykonanie neutrálne od poskytovateľa, trvanlivý token a účtovná kniha nákladov na fakturáciu, analytika nájomníkov pre riadenie, metadáta RAG pre kvalitu získavania a protokolovanie na ochranu súkromia pre bezpečné ladenie.

Začnite s metadátami, prechodmi stavov a zosúladením. Zachytenie obsahu pridajte len vtedy, keď budú pripravené pravidlá, uchovávanie a riadenie prístupu. Táto sekvencia poskytuje vývojárom dôkazy, ktoré potrebujú na ladenie latencie, kvality a výdavkov bez toho, aby sa pozorovateľnosť zmenila na nové riziko vystavenia údajov.

Súvisiace čítanie

• výzva do vyrovnávacej pamäte a vzory dávkovej kontroly nákladov
• správa kľúčov tímového rozhrania API a limity výdavkov