LLM-megfigyelhetőség többmodell API-átjáróban: nyomkövetések, token főkönyvek, bérlői elemzések és biztonságos prompt naplózás

Az összesített kérések száma és a havi költés nem elegendő, ha az ügyfél megkérdezi, miért lett tegnap egy munkafolyamat lassabb, drágább vagy kevésbé megbízható. A többmodelles API-átjáró akkor válaszolhat erre a kérdésre, ha a megfigyelést a vezérlősík részeként kezeli: minden kérés nyomkövetést kap, minden modellhívás frissít egy használati főkönyvet, minden bérlő és munkafolyamat hozzárendelhető, és az érzékeny tartalom alapértelmezés szerint védett.

Ez a cikk az AI-használati elemzés és az LLM-megfigyelhetőség gyakorlati tervezését írja le egy olyan átjáróban, amely OpenAI-kompatibilis API-n keresztül több szolgáltató előtt áll. A minta akkor is hasznos, ha nem használ semmilyen konkrét szállítót: egyszer az átjárónál eszközöl, normalizálja a modell telemetriáját, őrizze meg a számlázási hozzárendelést, és csak az explicit irányelvek alapján rögzítse a kérdőíves tartalmat.

Az olvasói probléma: „Melyik bérlő, modell, prompt vagy lekérési útvonal okozta a változást?”

A legtöbb csapat végül ugyanazzal a hibakeresési szakadékkal néz szembe. Az alkalmazásnaplók azt mutatják, hogy egy szolgáltatás meghiúsult. A szolgáltatói irányítópultok azt mutatják, hogy nőtt a tokenhasználat. A pénzügyek számlát látnak. Önmagukban ezek a nézetek egyike sem magyarázza meg a bérlői kéréstől a modellhívástól a visszakeresési kontextusig és a számlázott költségig való újrapróbálásig tartó teljes utat.

A cél nem egy újabb irányítópult teljes tokenekkel. A cél az, hogy megválaszoljuk a működési kérdéseket, például:

• Melyik bérlői vagy API-kulcs okozott költési csúcsot?
• Növekedett a várakozási idő a modellálnév megváltoztatása után?
• Az újrapróbálkozások vagy a tartalékok kétszeresen számolják a költségeket?
• Melyik prompt verzió írja a legtöbb hibaköltségkeretet?
• Drága lett egy RAG-munkafolyamat, mert a visszakeresés túl sok kontextusjogkivonatot adott hozzá?
• Támogatható egy incidens hibakeresése a privát felhasználói üzenetek elolvasása nélkül?

Tények, ajánlások és előrejelzések

Tények: Az OpenTelemetry generatív mesterséges intelligencia szemantikai konvenciókat és attribútumokat dokumentál a modellműveletekhez, beleértve a műveletneveket, például a chat, gener_content és text_completion. Ugyanez a dokumentáció arra figyelmeztet, hogy a GenAI bemeneti és kimeneti üzenetattribútumok érzékeny információkat vagy személyazonosításra alkalmas információkat tartalmazhatnak, és szűrést vagy csonkolást igényelhetnek. A főbb modellszolgáltatók olyan használati irányítópultokat, API-kat vagy exportokat is közzétesznek, amelyek támogatják a szolgáltatói oldali egyeztetést, bár a részletek szolgáltatónként eltérőek.

Javaslatok: Használja az OpenTelemetry-t a szolgáltató-semleges nyomkövetéshez, de tartsa meg az átjáró tulajdonában lévő üzleti dimenziókat saját attribútumaiban és főkönyveiben. Alapértelmezés szerint ne tároljon nyers promptokat vagy kimeneteket. Először tárolja a metaadatokat, a kivonatokat, a tokenszámokat, a prompt sablonazonosítókat, a sémaneveket, a hibaosztályokat és a biztonsági címkéket. A tartalomrögzítést csak választható, hozzáférés-vezérelt, rövid idejű hibakeresési funkcióként adja hozzá.

Előrejelzés: Az LLM-megfigyelhetőség kevésbé lesz az elszigetelt szolgáltatói irányítópultokról, hanem inkább a szolgáltatók közötti vezérlési síkokról. A csapatok egy helyen fogják vizsgálni a várakozási időt, a költségeket, a minőséget, az irányelvekkel kapcsolatos eseményeket, a bérlői viselkedést és a számlázási eltéréseket a különböző modelleken.

Referencia architektúra: figyelje meg a teljes kérési útvonalat

Egy átjáró láthatja a kérés teljes életciklusát anélkül, hogy minden alkalmazáscsapatnak egyéni telemetriát kellene készítenie. Egy hasznos nyomkövetési modell a bejövő vevői kérelmek egyik szülői tartományával kezdődik, a költségeket, a késleltetést és a minőséget befolyásoló lépések alárendelt szakaszaival.

Ajánlott feszítőszerkezet

• Átjárókérés terjedelme: a kérés elfogadva, hitelesítve, engedélyezett, sebességkorlátozott és továbbítva.
• Modellhívás időtartama: szolgáltató, modell, művelet, tokenhasználat, válaszállapot és várakozási idő.
• Letöltési időtartam: lekérdezett index, dokumentumazonosítók vagy kivonatolt azonosítók, darabszám, lekérési várakozási idő és kontextusjogkivonat megosztása.
• Eszközhívás időtartama: az eszköz neve, állapota, várakozási ideje, hibaosztály és mellékhatások besorolása.
• Újrapróbálkozási időszak: az újrapróbálkozás oka, a kísérlet száma, a szolgáltató állapota és a járulékos költség.
• Tartalék tartomány: eredeti modell, tartalék modell, aktiválási szabály, kompatibilitási szabályzat és végeredmény.
• Várókorlát vagy moderálási tartomány: meghívott irányelv, döntés, címkék és a kimenet blokkolása vagy átalakítása.
• Utófeldolgozási időtartam: JSON-ellenőrzés, sémajavítás, hivatkozás-ellenőrzés vagy végső formázás.

A szülő tartománynak stabil korrelációs azonosítókat kell hordoznia. A gyermek kiterjedéseknek normalizált technikai jellemzőket kell hordozniuk. A használati főkönyvnek tartós számlázási és analitikai rekordokat kell tartalmaznia. Kerülje el, hogy minden információt a metrikacímkékbe kényszerítsen; A nagyszámú értékeket, például a bérlői azonosítókat, a prompt hash-eket és a dokumentumazonosítókat jobb nyomkövetési, napló- vagy főkönyvi táblákban tárolni, majd irányítópultokba összesíteni.

Normalizálja az összes LLM-hívás során rögzített metaadatokat

Minden modellkérelemnek konzisztens rekordot kell készítenie, függetlenül a szolgáltatótól. A pontos séma változhat, de egy gyakorlati minimum így néz ki:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "bérlő_azonosítója": "bérlő_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operation": "csevegés",
  "provider": "szolgáltató_neve",
  "modell": "szolgáltató-modell-azonosító",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "befejezett",
  "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": hamis,
  "content_capture_policy": "metadata_only"
}

Tartson két ötletet külön: a telemetria elmagyarázza a történteket, míg a használati főkönyv rögzíti, hogy mit kell felszámítani, egyeztetni és jelenteni. A kérésazonosítókkal és a nyomkövetési azonosítókkal hivatkoznak egymásra, de nem kell ugyanabban a tárolórendszerben élniük.

Hozzon létre tokent és költségkönyvet, ne csak számlálókat

A tokenszámlálók hasznosak diagramokhoz, de nem elegendőek a számlázáshoz vagy az események kivizsgálásához. A főkönyvnek az állapotátmeneteket kell ábrázolnia. Hozzon létre egy sort, amikor az átjáró elfogad egy kérést, majd frissítse a kérés előrehaladtával.

Hasznos főkönyvi állapotok

• elfogadva: a hitelesítés és az irányelvek ellenőrzése sikeres.
• továbbküldve: a kérést elküldték egy szolgáltatónak.
• streamelés: a szolgáltató megkezdte a token visszaküldését.
• befejezve: a válasz sikeresen befejeződött.
• user_aborted: az ügyfél a befejezés előtt megszakadt.
• újrapróbálva: újabb szolgáltatói kísérlet történt.
• fallback_used: más modellt vagy szolgáltatót választottak ki a hiba vagy az irányelvek egyezése után.
• sikertelen: a kérés használható válasz nélkül fejeződött be.
• egyeztetett: a szolgáltató oldali használati vagy költségadatokat összehasonlítottuk és alkalmaztuk.

Ez az állapotmodell segít elkapni a gyakori számlázási és elemzési hibákat: a streamelt válaszokat, amikor az ügyfél megszakadt a kapcsolat, a szolgáltató által felszámított, de a felhasználó elől rejtett újrapróbálkozási kísérleteket, a rossz modellt számláló tartalék útvonalakat és a gyorsítótár-elszámolási különbségeket a szolgáltatók között.

Használja az OpenTelemetry GenAI konvencióit, majd óvatosan bővítse ki

Az OpenTelemetry GenAI szemantikai konvenciói hordozható szókincset biztosítanak a modellműveletekhez. Használja ezeket a konvenciókat az olyan általános attribútumokhoz, mint a művelet neve, szolgáltatója, modellje, kérési paraméterei, válaszbefejezési okai, tokenhasználat és hibaállapot, ahol érvényesek.

A szolgáltató-semleges konvenciók azonban nem fedik le az átjáró minden üzleti dimenzióját. Adjon hozzá átjáróhoz tartozó attribútumokat vagy főkönyvi oszlopokat:

• bérlőazonosító, csapatazonosító, viszonteladói ügyfél-azonosító és alkalmazásazonosító;
• átjáró API kulcsazonosítója és kulcshatóköre;
• számlázási terv, kiadási korlát és költségvetési szabályzat;
• modellalias és útválasztási szabályzat verziója;
• prompt sablonazonosító és prompt verzió;
• munkafolyamat neve és lépése;
• becsült költség, végső számlázott költség és egyeztetési állapot.

A kompromisszum a kardinalitás. Ezek a mezők értékesek a vizsgálathoz, de drágává és zajossá tehetik a mérőszámokat, ha mindenhol metrikacímkéként használják őket. Gyakorlati szabály: az alacsony kardinalitású aggregátumok a metrikákba kerülnek; a nagyszámú azonosítók a nyomkövetésekhez, naplókhoz és főkönyvekhez kerülnek.

Biztonságos prompt és kimeneti naplózás tervezése

A teljes azonnali naplózás megkönnyíti a hibakeresést, de növeli az adatvédelmet, a megfelelőséget, a tárolást és a bennfentes kockázatok kitettségét. A biztonságosabb alapértelmezés a metaadat-első megfigyelhetőség.

Alapértelmezett: csak metaadatok

A legtöbb éles forgalomhoz tárolja:

• sablon azonosítója és verziója;
• normalizált promptok és kimenetek kivonatai;
• bemeneti, kimeneti, gyorsítótárazott és kontextusjogkivonatok száma;
• válaszséma neve és az ellenőrzés eredménye;
• biztonsági címkék és politikai döntések;
• hibaösszefoglalók és szolgáltatói hibaosztályok;
• metaadatok lekérése, nem nyers dokumentumok.

Feliratkozás: szabályozott tartalomrögzítés

Ha nyers vagy szerkesztett tartalomra van szüksége a mélyreható hibakereséshez, kérjen kifejezett szabályzatot. A megfelelő vezérlőelemek közé tartoznak a környezeti engedélyezési listák, a bérlői hozzájárulás, a mintavétel, a maximális hasznos adathossz, az automatikus szerkesztés, a rövid megőrzési időszakok, a titkosítás, a szerepkör alapú hozzáférés, az ellenőrzési naplók és az érzékeny incidensekre vonatkozó jóváhagyási útvonal.

Ne tekintse tökéletesnek a szerkesztést. Csökkenti a kockázatot; nem szünteti meg. Szabályozott vagy nagy érzékenységű munkaterhelések esetén fontolja meg, hogy csak kivonatokat tároljon, és a problémákat egy szintetikus kábelkötegben játssza le jóváhagyott tesztadatokkal.

A RAG-megfigyelhetőség hozzáadása külön rétegként

A visszakereséssel kiegészített generálás a minőséget és a költségeket egyaránt megváltoztathatja. Csak a végső modellhívás naplózása elrejti a kiváltó okot, amikor a retriever túl sok darabot, elavult dokumentumot vagy irreleváns kontextust ad vissza.

Minden visszakeresési lépéshez rögzítse:

• index vagy gyűjtemény neve;
• lekérési stratégia és beágyazási modell;
• dokumentumazonosítók vagy kivonatolt azonosítók;
• darabok száma és a kontextus tokenek teljes száma;
• lekérési késleltetés;
• a legjobb pontszám eloszlása, ha elérhető;
• hivatkozási tudósítás;
• hogy a beolvasott kontextust használták-e a végső válaszban.

Ez lehetővé teszi a „modell rosszabbá vált” és „a retriever rossz minőségű vagy túlzott kontextus küldésének” megkülönböztetését. Segít azonosítani azokat a munkafolyamatokat is, ahol a kontextus tokenek uralják a teljes költséget.

Az átjáró használatának egyeztetése a szolgáltatói számlázással

Az átjáró becslései azonnal elérhetők. A szolgáltató oldali számlázási adatok általában lassabbak, de hitelesebbek. Használja mindkettőt.

A napi egyeztetési feladatnak össze kell hasonlítania az átjáró főkönyvi sorait a szolgáltatói használati API-kkal, a költség API-kkal, az irányítópult-exportálásokkal vagy a számlaexportálásokkal. Csoportosítsa a deltákat szolgáltató, modell, projekt és időablak szerint. Külön nyomon követheti a különbségeket a bemeneti tokenek, a kimeneti tokenek, a gyorsítótárazott tokenek, a kérelmek száma és a költség tekintetében.

Gyakori egyeztetési különbségek

• A streamelés megszakad: az átjáró láthat egy megszakított klienst, miközben a szolgáltató továbbra is számlázza a generált tokeneket.
• Újrapróbálkozás: előfordulhat, hogy több kísérletet is számlázunk ki, még akkor is, ha csak egy végső választ adunk vissza.
• Azonnali gyorsítótárazás: a szolgáltatók eltérően tehetik közzé a gyorsítótárazott token elszámolást.
• Kerekítés: kérésenkénti kis eltérések léptékben láthatóvá válhatnak.
• Tömeges vagy lépcsős engedmények: a szolgáltatói számlák olyan árazást alkalmazhatnak, amelyet a valós idejű becslés még nem tudott.
• Szolgáltatóoldali változások: a modell árazása, a tokenizálási viselkedés vagy a számlázási exportálások idővel változhatnak.

Ha az egyeztetés deltát talál, kerülje a főkönyv csendes felülírását. Tárolja az eredeti becslést, a szolgáltató által egyeztetett értéket, az egyeztetési forrást és az okkódot, ha ismert.

Működési kérdésekre válaszoló irányítópultok

Indítsa el az irányítópultokat az olvasói problémákból, ne a hiúsági mutatókból. Hasznos nézetek a következők:

• bérlőnként, csapatonként, alkalmazásonként és munkafolyamatonkénti költség;
• sikeres feladatonkénti költség, nem csak kérésenkénti költség;
• p50, p95 és p99 késleltetés szolgáltató, modell és modellálnév szerint;
• tartalékarány és újrapróbálkozási arány útvonalonként;
• időtúllépési arány és a szolgáltatói hibaosztály trendjei;
• gyorsítótár találati aránya és gyorsítótárazott token megtakarítási becslése;
• strukturált kimenet érvényesítési hibaaránya;
• a legjobb kérdőíves verziók hiba miatti költségkeret elégetése;
• RAG kontextusjogkivonat megosztása munkafolyamat szerint;
• védőkorlát blokkok és azonnali befecskendezési osztályozó találatok.

A riasztáshoz kombinálja a műszaki és az üzleti jelzéseket. A bérlői kiadások hirtelen megugrása sürgetőbb lehet, mint egy kis globális késleltetési időnövekedés. A modellálnév megváltoztatása utáni visszaesési arány ugrás kompatibilitási problémát jelezhet. Az ismétlődő 401-es, 429-es vagy 5xx-es válaszok kulcsfontosságú problémákra, a kvóta kimerülésére vagy a szolgáltató instabilitására utalhatnak.

Minimális megvalósítási folyamat egy OpenAI-kompatibilis proxyhoz

A /chat/completions proxy esetében a folyamat egyszerű lehet:

1. Kérje a kérést, és rendelje hozzá a request_id paramétert és nyomon követheti a kontextust.
2. Hitelesítse az átjárókulcsot, és határozza meg a bérlő, a csapat, az alkalmazás és a házirend hatókörét.
3. Hozza létre a szülőátjáró-tartományt.
4. Hozzon létre egy főkönyvi sort elfogadva állapottal.
5. A modellálnév megoldása a szolgáltatói modellre és az útválasztási szabályzat verziójára.
6. Metaadatok rögzítése: művelet, prompt sablonazonosító, sémanév, prompt hash és tartalomrögzítési szabályzat.
7. Indítsa el a modellhívási tartományt a GenAI szemantikai attribútumok használatával, ahol alkalmazható.
8. Továbbítsa a kérést a kiválasztott szolgáltatónak.
9. Streamelés esetén frissítse az állapotot, amikor az első darab megérkezik, és a szolgáltató válaszának megfelelően pontosan számolja a használatot.
10. Befejezéskor elemezze a szolgáltató használatát, a befejezés okát, állapotát és hibaosztályát.
11. Frissítse a főkönyvet a tokenekkel, a becsült költséggel, az újrapróbálkozás/tartalék részletekkel és a kérés végső állapotával.
12. Mutatók kibocsátása a főkönyvi és span adatokból.
13. Futtassa le a napi egyeztetést és a bolti szolgáltató által megerősített költségeket az eredeti becsléstől elkülönítve.

Közzétételi ellenőrzőlista

• Határozza meg a kanonikus kérésazonosítókat és nyomkövetési azonosítókat.
• OpenTelemetry GenAI attribútumok elfogadása a szokásos telemetriai modellekhez.
• Hozzon létre egy átjáróhasználati főkönyvet kérésállapot-átmenetekkel.
• Normalizálja a szolgáltató, a modell, a modellálnév, a bérlő, az alkalmazás és a munkafolyamat dimenzióit.
• Tartsa távol a nagy számosságú vizsgálati adatokat a metrikacímkéken.
• A nyers prompt és a kimenet rögzítését alapértelmezés szerint tiltsa le.
• Adjon hozzá kifejezett irányelveket a mintavételhez, a szerkesztéshez, a megőrzéshez és a hozzáférés-szabályozáshoz.
• Rögzítse lekérési metaadatait a RAG-munkafolyamatokhoz.
• Készítsen irányítópultokat a költségek, a késleltetés, a megbízhatóság, az érvényesítés és a bérlői viselkedés szempontjából.
• Összehangolja az átjáró becsléseit a szolgáltatói használattal és a költségexporttal.
• Figyelmeztetés a költéscsúcsokról, a várakozási idő regressziójáról, a tartalék ugrásokról, az érvényesítési hibákról és a biztonsággal kapcsolatos eseményekről.

Következtetés

A többmodelles átjáró a megfelelő hely az LLM-megfigyelhetőség megvalósítására, mert látja a kéréseket, mielőtt azok bármelyik szolgáltatóhoz eljutnának, és olyan üzleti kontextust tud csatolni, amelyet a szolgáltatók nem ismernek. A legerősebb kialakítás nem az, hogy „mindent naplózzon”. Ez egy többrétegű modell: szolgáltatósemleges nyomkövetések a végrehajtáshoz, tartós token és költségkönyv a számlázáshoz, bérlői elemzések az irányításhoz, RAG-metaadatok a lekérdezés minőségéhez, és az adatvédelem előtt álló azonnali naplózás a biztonságos hibakereséshez.

Kezdje a metaadatokkal, az állapotátmenetekkel és az egyeztetéssel. Csak akkor adja hozzá a tartalomrögzítést, ha a házirend, a megőrzés és a hozzáférés-vezérlés készen áll. Ez a szekvencia megadja a fejlesztőknek a szükséges bizonyítékokat a késleltetés, a minőség és a költés hibakereséséhez anélkül, hogy a megfigyelhetőséget új adatexpozíciós kockázatgá változtatnák.

Kapcsolódó olvasmányok

• reális viselkedési LLM3/falbacks útválasztás
• prompt gyorsítótárazás és kötegelt költségszabályozási minták
• csapat API-kulcskezelés és költési korlátok