Pozorovatelnost LLM ve vícemodelové bráně API: Trasování, účetní knihy tokenů, analýza nájemců a bezpečné protokolování výzev

Souhrnné počty požadavků a měsíční výdaje nestačí, když se zákazník zeptá, proč byl jeden pracovní postup včera pomalejší, dražší nebo méně spolehlivý. Brána API pro více modelů může na tuto otázku odpovědět, pokud zachází s pozorovatelností jako se součástí řídicí roviny: každý požadavek získá trasování, každé volání modelu aktualizuje knihu použití, lze přiřadit každého tenanta a pracovní postup a citlivý obsah je ve výchozím nastavení chráněn.

Tento článek popisuje praktický návrh analýzy využití AI a sledovatelnosti LLM v bráně, která slouží více poskytovatelům prostřednictvím rozhraní API kompatibilního s OpenAI. Vzor je užitečný, i když nepoužíváte žádného konkrétního dodavatele: nástroj jednou na bráně, normalizaci telemetrie modelu, zachování přiřazení fakturace a zachycování obsahu výzev pouze na základě explicitních zásad.

Problém se čtečkou: „Který tenant, model, výzva nebo cesta načítání způsobily změnu?“

Většina týmů se nakonec potýká se stejnou mezerou v ladění. Protokoly aplikací ukazují, že některá funkce selhala. Panely poskytovatelů ukazují, že využití tokenů vzrostlo. Finance vidí účet. Žádný z těchto pohledů sám o sobě nevysvětluje celou cestu od požadavku nájemce přes volání modelu až po kontext načítání a opakování pokusu o fakturované náklady.

Cílem není další řídicí panel s celkovým počtem tokenů. Cílem je odpovědět na provozní otázky jako:

• Který tenant nebo klíč API způsobil prudký nárůst výdajů?
• Zvýšila se latence po změně aliasu modelu?
• Započítávají se náklady na opakované nebo záložní pokusy dvakrát?
• Která promptní verze spálí nejvíce chybového rozpočtu?
• Zdražil pracovní postup RAG, protože načítání přidalo příliš mnoho kontextových tokenů?
• Může podporovat ladění incidentu bez čtení výzev soukromých uživatelů?

Fakta, doporučení a předpovědi

Fakta: OpenTelemetry dokumentuje generativní sémantické konvence a atributy umělé inteligence pro modelové operace, včetně názvů operací, jako je chat, generation_content a text_completion. Stejná dokumentace varuje, že atributy vstupní a výstupní zprávy GenAI mohou obsahovat citlivé informace nebo PII a mohou vyžadovat filtrování nebo zkrácení. Hlavní poskytovatelé modelů také vystavují panely využití, rozhraní API nebo exporty, které mohou podporovat sladění na straně poskytovatele, ačkoli podrobnosti se u jednotlivých poskytovatelů liší.

Doporučení: Používejte OpenTelemetry pro trasování neutrální vůči poskytovatelům, ale ve svých vlastních atributech a účetních knihách ponechejte obchodní dimenze vlastněné bránou. Ve výchozím nastavení neukládejte nezpracované výzvy nebo výstupy. Nejprve ukládejte metadata, hashe, počty tokenů, ID šablon výzvy, názvy schémat, třídy chyb a bezpečnostní štítky. Přidejte zachycení obsahu pouze jako volitelnou funkci ladění s řízeným přístupem a krátkou dobou uchování.

Předpověď: Pozorovatelnost LLM bude méně o izolovaných řídicích panelech poskytovatelů a více o řídicích rovinách mezi různými poskytovateli. Týmy budou očekávat, že na jednom místě budou zkoumat latenci, náklady, kvalitu, události zásad, chování nájemců a rozdíly ve fakturaci napříč modely.

Referenční architektura: sledujte celou cestu požadavku

Brána může vidět celý životní cyklus požadavku, aniž by musel každý aplikační tým vytvářet vlastní telemetrii. Užitečný model trasování začíná jedním rodičovským rozsahem pro příchozí požadavek zákazníka a podřízeným rozsahem kroků, které ovlivňují cenu, latenci a kvalitu.

Doporučená struktura rozsahu

• Rozsah požadavků brány: požadavek přijat, ověřen, autorizován, s omezenou rychlostí a směrován.
• Rozpětí volání modelu: poskytovatel, model, operace, využití tokenu, stav odezvy a latence.
• Rozpětí načítání: dotaz na index, ID dokumentů nebo hashovaná ID, počet bloků, latence načítání a sdílení kontextového tokenu.
• Rozsah volání nástroje: název nástroje, stav, latence, třída chyb a klasifikace vedlejších účinků.
• Rozpětí opakování: důvod opakování, číslo pokusu, stav poskytovatele a přírůstkové náklady.
• Rozpětí záložních reklam: původní model, záložní model, spouštěč, zásady kompatibility a konečný výsledek.
• Rozpětí zábrany nebo moderování: vyvolané zásady, rozhodnutí, štítky a to, zda byl výstup blokován nebo transformován.
• Rozsah po zpracování: Ověření JSON, oprava schématu, kontrola citací nebo konečné formátování.

Rodičovský rozsah by měl nést stabilní identifikátory korelace. Podřízené rozpětí by mělo nést normalizované technické atributy. Kniha použití by měla obsahovat trvalé fakturační a analytické záznamy. Vyhněte se vynucení všech informací do štítků metrik; hodnoty s vysokou kardinalitou, jako jsou ID tenantů, hash výzev a ID dokumentů, se lépe ukládají do trasování, protokolů nebo tabulek hlavní knihy a poté agregují do řídicích panelů.

Normalizovat metadata zachycená při každém volání LLM

Každý požadavek modelu by měl vytvářet konzistentní záznam bez ohledu na poskytovatele. Přesné schéma se bude lišit, ale praktické minimum vypadá 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",
  "operace": "chat",
  "provider": "název_poskytovatele",
  "model": "id-model-poskytovatele",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "dokončeno",
  "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": false,
  "content_capture_policy": "pouze metadata"
}

Uchovávejte dva nápady odděleně: telemetrie vysvětluje, co se stalo, zatímco hlavní kniha použití zaznamenává, co by mělo být účtováno, odsouhlaseno a hlášeno. Odkazují se navzájem pomocí ID požadavků a ID sledování, ale nemusí žít ve stejném úložném systému.

Sestavte si token a účetní knihu nákladů, nejen počítadla

Počítadla tokenů jsou užitečná pro grafy, ale nestačí pro fakturaci nebo vyšetřování incidentů. Hlavní kniha by měla představovat přechody stavů. Vytvořte řádek, když brána přijme požadavek, a poté jej aktualizujte, jak požadavek postupuje.

Užitečné stavy účetní knihy

• přijato: ověření a kontrola zásad prošla.
• přeposláno: požadavek byl odeslán poskytovateli.
• streamování: poskytovatel začal vracet tokeny.
• dokončeno: odpověď byla úspěšně dokončena.
• user_aborted: klient byl před dokončením odpojen.
• opakovaný pokus: byl proveden další pokus o poskytovatele.
• fallback_used: po selhání nebo shodě zásad byl vybrán jiný model nebo poskytovatel.
• selhal: požadavek skončil bez použitelné odpovědi.
• odsouhlaseno: Údaje o využití nebo nákladech na straně poskytovatele byly porovnány a použity.

Tento model stavu pomáhá zachytit běžné chyby fakturace a analýzy: streamované odpovědi, kdy se klient odpojil, opakování pokusů, které byly účtovány poskytovatelem, ale skryté před uživatelem, záložní cesty, které počítaly nesprávný model, a rozdíly v účtování mezi poskytovateli mezipaměti.

Používejte konvence OpenTelemetry GenAI a poté opatrně rozšiřujte

Sémantické konvence OpenTelemetry GenAI poskytují přenosný slovník pro modelové operace. Tyto konvence použijte pro běžné atributy, jako je název operace, poskytovatel, model, parametry požadavku, důvody dokončení odpovědi, použití tokenu a chybový stav tam, kde se používají.

Konvence neutrální vůči poskytovatelům však nepokryjí všechny obchodní dimenze brány. Přidejte atributy nebo sloupce hlavní knihy vlastněné bránou pro:

• ID nájemce, ID týmu, ID zákazníka distributora a ID aplikace;
• ID klíče rozhraní API brány a rozsah klíče;
• plán fakturace, limit útraty a zásady rozpočtu;
• alias modelu a verze zásad směrování;
• ID šablony výzvy a verze výzvy;
• název pracovního postupu a krok pracovního postupu;
• odhadované náklady, konečné fakturované náklady a stav odsouhlasení.

Komisem je mohutnost. Tato pole jsou cenná pro zkoumání, ale mohou způsobit, že metriky budou drahé a hlučné, pokud se všude používají jako štítky metrik. Praktickým pravidlem je: agregáty s nízkou mohutností jdou do metrik; identifikátory s vysokou kardinalitou jdou do tras, protokolů a účetních knih.

Navrhněte bezpečnou výzvu a protokolování výstupu

Úplné rychlé protokolování usnadňuje ladění, ale zvyšuje soukromí, dodržování předpisů, úložiště a vystavení vnitřnímu riziku. Bezpečnější výchozí nastavení je pozorovatelnost na prvním místě metadat.

Výchozí: pouze metadata

Pro většinu produkčního provozu uložte:

• ID šablony výzvy a její verze;
• haše normalizovaných výzev a výstupů;
• počet vstupů, výstupů, mezipaměti a kontextových tokenů;
• název schématu odpovědí a výsledek ověření;
• bezpečnostní štítky a politická rozhodnutí;
• souhrny chyb a třídy chyb poskytovatele;
• načítání metadat, nikoli nezpracovaných dokumentů.

Přihlášení: řízené zachycování obsahu

Pokud potřebujete nezpracovaný nebo upravený obsah pro hluboké ladění, požadujte explicitní zásady. Mezi dobré ovládací prvky patří seznamy povolených prostředí, souhlas nájemce, vzorkování, maximální délka užitečného zatížení, automatická redakce, krátká období uchovávání, šifrování, přístup na základě rolí, protokoly auditu a cesta schvalování pro citlivé incidenty.

Nepovažujte redakci za dokonalou. Snižuje riziko; nevylučuje to. U regulovaného nebo vysoce citlivého pracovního zatížení zvažte ukládání pouze hashů a přehrávání problémů v syntetickém svazku se schválenými testovacími daty.

Přidat pozorovatelnost RAG jako samostatnou vrstvu

Generování rozšířené o načítání může změnit kvalitu i cenu. Protokolování pouze posledního volání modelu skryje hlavní příčinu, když retriever vrátí příliš mnoho kusů, zastaralé dokumenty nebo irelevantní kontext.

Pro každý krok načítání zachyťte:

• název indexu nebo kolekce;
• strategie načítání a model vkládání;
• ID dokumentů nebo hashovaná ID;
• počet bloků a celkový kontext tokenů;
• latence načítání;
• nejvyšší rozdělení skóre, je-li k dispozici;
• pokrytí citací;
• zda byl v konečné odpovědi použit načtený kontext.

To vám umožní rozlišit „model se zhoršil“ od „retrívru začal odesílat nekvalitní nebo nadměrný kontext.“ Pomáhá také identifikovat pracovní postupy, kde kontextové tokeny dominují celkovým nákladům.

Sladit používání brány s fakturací poskytovatele

Odhady brány jsou k dispozici okamžitě. Fakturační údaje na straně poskytovatele jsou obvykle pomalejší, ale směrodatnější. Použijte obojí.

Úloha denního odsouhlasení by měla porovnávat řádky hlavní knihy brány s rozhraními API pro využití poskytovatele, rozhraními API pro náklady, exporty řídicího panelu nebo exporty faktur. Seskupte delty podle poskytovatele, modelu, projektu a časového okna. Sledujte rozdíly odděleně pro vstupní tokeny, výstupní tokeny, tokeny uložené v mezipaměti, počty požadavků a náklady.

Běžné rozdíly v odsouhlasení

• Streamování se odpojí: brána může vidět přerušeného klienta, zatímco poskytovatel stále účtuje vygenerované tokeny.
• Opakování: více pokusů může být účtováno, i když je vrácena pouze jedna poslední odpověď.
• Výzva k ukládání do mezipaměti: poskytovatelé mohou vystavit účtování tokenů uložených v mezipaměti odlišně.
• Zaokrouhlení: malé rozdíly mezi jednotlivými požadavky se mohou projevit v měřítku.
• Dávkové nebo víceúrovňové slevy: faktury poskytovatelů mohou uplatňovat ceny, které odhad v reálném čase ještě neznal.
• Změny na straně poskytovatele: ceny modelu, chování tokenizace nebo exporty fakturace se mohou v průběhu času měnit.

Když usmíření najde deltu, vyhněte se tichému přepsání účetní knihy. Uložte původní odhad, hodnotu odsouhlasenou poskytovatelem, zdroj odsouhlasení a kód příčiny, pokud je znám.

Panely, které odpovídají na provozní otázky

Spouštějte řídicí panely z problémů se čtečkami, nikoli z marných metrik. Mezi užitečné pohledy patří:

• náklady na nájemce, tým, aplikaci a pracovní postup;
• cena za úspěšný úkol, nejen cena za požadavek;
• latence p50, p95 a p99 podle poskytovatele, modelu a aliasu modelu;
• počet záložních reklam a počet opakování podle trasy;
• rychlost vypršení časového limitu a trendy třídy chyb poskytovatele;
• poměr přístupů do mezipaměti a odhad úspory tokenů v mezipaměti;
• četnost selhání ověření strukturovaného výstupu;
• nejvyšší verze s výzvou k chybovému spálení rozpočtu;
• sdílení kontextového tokenu RAG podle pracovního postupu;
• zábradlí a zásahy klasifikátoru prompt-injection.

Pro upozornění kombinujte technické a obchodní signály. Náhlý nárůst výdajů nájemců může být naléhavější než malé globální zvýšení latence. Skok v nouzových rychlostech po změně aliasu modelu může znamenat problém s kompatibilitou. Opakované odpovědi 401, 429 nebo 5xx mohou poukazovat na klíčové problémy, vyčerpání kvóty nebo nestabilitu poskytovatele.

Minimální tok implementace pro proxy kompatibilní s OpenAI

U /chat/completions proxy může být postup jednoduchý:

1. Přijměte požadavek a přiřaďte request_id a sledujte kontext.
2. Ověřte klíč brány a vyřešte rozsah tenanta, týmu, aplikace a zásad.
3. Vytvořte nadřazený rozsah brány.
4. Vytvořte řádek hlavní knihy se stavem přijato.
5. Vyřešte alias modelu na model poskytovatele a verzi zásad směrování.
6. Metadata záznamu: operace, ID šablony výzvy, název schématu, hash výzvy a zásady zachycování obsahu.
7. V případě potřeby zahajte rozsah volání modelu pomocí sémantických atributů GenAI.
8. Předejte požadavek vybranému poskytovateli.
9. U streamování aktualizujte stav, když dorazí první blok, a počítejte využití tak přesně, jak to dovolí odpověď poskytovatele.
10. Po dokončení analyzujte využití poskytovatele, důvod dokončení, stav a třídu chyb.
11. Aktualizujte účetní knihu o tokeny, odhadované náklady, podrobnosti o opakování/záložním postupu a konečný stav požadavku.
12. Odešlete metriky z dat hlavní knihy a rozsahu.
13. Spouštějte denní odsouhlasení a ukládejte náklady potvrzené poskytovatelem odděleně od původního odhadu.

Kontrolní seznam zavedení

• Definujte kanonická ID požadavků a ID trasování.
• Přijměte atributy OpenTelemetry GenAI pro běžnou modelovou telemetrii.
• Vytvořte knihu použití brány s přechody stavu požadavku.
• Normalizujte dimenze poskytovatele, modelu, aliasu modelu, tenanta, aplikace a pracovního postupu.
• Uchovejte údaje z vyšetřování s vysokou mohutností mimo štítky metrik.
• Ve výchozím nastavení deaktivovat nezpracované výzvy a zachycení výstupu.
• Přidejte explicitní zásady pro vzorkování, redigování, uchovávání a řízení přístupu.
• Zachyťte metadata načítání pro pracovní postupy RAG.
• Vytvářejte řídicí panely pro náklady, latenci, spolehlivost, ověřování a chování nájemců.
• Sladit odhady brány s využitím poskytovatele a exportem nákladů.
• Upozornění na špičky výdajů, regrese latence, záložní skoky, selhání ověření a události související se zabezpečením.

Závěr

Multimodelová brána je tím správným místem pro implementaci pozorovatelnosti LLM, protože vidí požadavky dříve, než se dostanou k jakémukoli poskytovateli, a může připojit obchodní kontext, který poskytovatelé neznají. Nejsilnější design není „zaznamenat všechno“. Jedná se o vrstvený model: trasování neutrální vůči poskytovateli pro provádění, odolný token a účetní kniha nákladů pro fakturaci, analytika nájemců pro správu, metadata RAG pro kvalitu načítání a protokolování na prvním místě na ochranu soukromí pro bezpečné ladění.

Začněte metadaty, přechody stavů a odsouhlasením. Zachycení obsahu přidejte pouze tehdy, když jsou připraveny zásady, uchovávání a řízení přístupu. Tato sekvence poskytuje vývojářům důkazy, které potřebují k odladění latence, kvality a utrácení, aniž by se pozorovatelnost změnila v nové riziko vystavení dat.

Související informace

• rychlé ukládání do mezipaměti a vzory dávkové kontroly nákladů
• správa klíčů týmového rozhraní API a limity výdajů