LLM novērojamība vairāku modeļu API vārtejā: pēdas, marķieru virsgrāmatas, nomnieka analīze un droša uzvedņu reģistrēšana

Ar kopējo pieprasījumu skaitu un ikmēneša tēriņiem nepietiek, ja klients jautā, kāpēc vakar viena darbplūsma kļuva lēnāka, dārgāka vai mazāk uzticama. Vairāku modeļu API vārteja var atbildēt uz šo jautājumu, ja novērojamība tiek uzskatīta par vadības plaknes daļu: katrs pieprasījums saņem izsekošanu, katrs modeļa izsaukums atjaunina lietošanas virsgrāmatu, katrs nomnieks un darbplūsma ir attiecināma, un sensitīvs saturs tiek aizsargāts pēc noklusējuma.

Šajā rakstā ir aprakstīts praktisks dizains AI lietojuma analīzei un LLM novērojamībai vārtejā, kas nodrošina vairākus pakalpojumu sniedzējus, izmantojot ar OpenAI saderīgu API. Modelis ir noderīgs pat tad, ja neizmantojat nevienu konkrētu pakalpojumu sniedzēju: vienreiz izmantojiet vārteju, normalizējiet modeļa telemetriju, saglabājiet norēķinu attiecinājumu un tveriet uzvednes saturu tikai saskaņā ar skaidru politiku.

Lasītāja problēma: “Kurš nomnieks, modelis, uzvedne vai izguves ceļš izraisīja izmaiņas?”

Lielākā daļa komandu galu galā saskaras ar tādu pašu atkļūdošanas trūkumu. Lietojumprogrammu žurnāli liecina, ka līdzeklis neizdevās. Pakalpojumu sniedzēju informācijas paneļi parāda, ka marķiera lietojums ir palielinājies. Finanses redz rēķinu. Neviens no šiem skatiem pats par sevi nepaskaidro pilnu ceļu no nomnieka pieprasījuma līdz modeļa izsaukumam līdz izguves kontekstam, lai atkārtoti mēģinātu izmantot rēķinā norādītās izmaksas.

Mērķis nav vēl viens informācijas panelis ar visiem marķieriem. Mērķis ir atbildēt uz tādiem darbības jautājumiem kā:

• Kura nomnieka vai API atslēga izraisīja tēriņu pieaugumu?
• Vai latentums palielinājās pēc modeļa aizstājvārda maiņas?
• Vai atkārtoti mēģinājumi vai rezerves uzskaita izmaksas?
• Kurā uzvednes versijā tiek izmantots vislielākais kļūdu budžets?
• Vai RAG darbplūsma kļuva dārga, jo izguve pievienoja pārāk daudz konteksta pilnvaru?
• Vai atbalsts var atbalstīt incidenta atkļūdošanu, neizlasot privāto lietotāju uzvednes?

Fakti, ieteikumi un prognozes

Fakti: OpenTelemetry dokumentē ģeneratīvās AI semantiskās konvencijas un atribūtus modeļa operācijām, tostarp darbību nosaukumus, piemēram, tērzēšana, ģenerēšanas_kontents un text_completion. Tā pati dokumentācija brīdina, ka GenAI ievades un izvades ziņojumu atribūti var saturēt sensitīvu informāciju vai PII un var būt nepieciešama filtrēšana vai saīsināšana. Lielākie modeļu nodrošinātāji atklāj arī lietojuma informācijas paneļus, API vai eksportēšanu, kas var atbalstīt nodrošinātāja puses saskaņošanu, lai gan informācija atšķiras atkarībā no pakalpojumu sniedzēja.

Ieteikumi: izmantojiet OpenTelemetry, lai veiktu neitrālu izsekošanu, bet vārtejai piederošās uzņēmējdarbības dimensijas saglabājiet savos atribūtos un virsgrāmatās. Neglabājiet neapstrādātas uzvednes vai izvades pēc noklusējuma. Vispirms uzglabājiet metadatus, jaucējvārdus, pilnvaru skaitu, uzvednes veidņu ID, shēmu nosaukumus, kļūdu klases un drošības uzlīmes. Pievienojiet satura uztveršanu tikai kā izvēles, ar piekļuvi kontrolētu, īslaicīgas saglabāšanas atkļūdošanas funkciju.

Prognoze: LLM novērojamība kļūs mazāka par izolētiem pakalpojumu sniedzēju informācijas paneļiem un vairāk par starpnodrošinātāju vadības plaknēm. Komandas sagaida, ka viena vieta izmeklēs latentumu, izmaksas, kvalitāti, politikas notikumus, nomnieku uzvedību un norēķinu deltas dažādos modeļos.

Atsauces arhitektūra: novērojiet visu pieprasījuma ceļu

Vārteja var redzēt visu pieprasījuma dzīves ciklu, neprasot katrai lietojumprogrammu komandai izveidot pielāgotu telemetriju. Noderīgs izsekošanas modelis sākas ar vienu sākuma diapazonu ienākošajam klienta pieprasījumam un pakārtotajiem diapazoniem darbībām, kas ietekmē izmaksas, latentumu un kvalitāti.

Ieteicamā laiduma struktūra

• Vārtejas pieprasījuma ilgums: pieprasījums ir pieņemts, autentificēts, autorizēts, ierobežots ātrums un maršrutēts.
• Modeļa zvana ilgums: nodrošinātājs, modelis, darbība, pilnvaras lietojums, atbildes statuss un latentums.
• Izguves ilgums: indeksa vaicājums, dokumentu ID vai jauktie ID, gabalu skaits, izguves latentums un konteksta pilnvaras daļa.
• Rīka izsaukuma diapazons: rīka nosaukums, statuss, latentums, kļūdu klase un blakusparādību klasifikācija.
• Atkārtotā mēģinājuma ilgums: atkārtota mēģinājuma iemesls, mēģinājuma numurs, pakalpojumu sniedzēja statuss un papildu maksa.
• Atkāpšanās diapazons: sākotnējais modelis, rezerves modelis, aktivizētājs, saderības politika un gala rezultāts.
• Aizsargmargas vai regulēšanas diapazons: izsauktā politika, lēmums, iezīmes un tas, vai izvade tika bloķēta vai pārveidota.
• Pēcapstrādes ilgums: JSON validācija, shēmas labošana, citātu pārbaudes vai galīgais formatējums.

Sākotnējā diapazonā ir jābūt stabiliem korelācijas identifikatoriem. Pakārtotajiem laidumiem jābūt normalizētiem tehniskajiem atribūtiem. Lietošanas virsgrāmatā ir jābūt noturīgiem norēķinu un analītikas ierakstiem. Nepiespiediet visu informāciju metrikas etiķetēs; Augstas kardinalitātes vērtības, piemēram, nomnieku ID, uzvednes jaucējkodoli un dokumentu ID, labāk tiek saglabātas trasēšanas, žurnālu vai virsgrāmatas tabulās un pēc tam apkopotas informācijas paneļos.

Normalizējiet metadatus, kas tiek tverti katrā LLM izsaukumā

Katram modeļa pieprasījumam ir jāveido konsekvents ieraksts neatkarīgi no pakalpojumu sniedzēja. Precīza shēma var atšķirties, taču praktiskais minimums izskatās šādi:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "īrnieka_id": "īrnieks_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operācija": "tērzēšana",
  "provider": "provider_name",
  "modelis": "provider-model-id",
  "model_alias": "ātrā atbalsta tērzēšana",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "statuss": "pabeigts",
  "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": nepatiess,
  "content_capture_policy": "metadata_only"
}

Saglabājiet divas idejas atsevišķi: telemetrija izskaidro notikušo, savukārt lietojuma virsgrāmatā tiek reģistrēts, kas jāiekasē, jāsaskaņo un jāziņo. Tie atsaucas viens uz otru, izmantojot pieprasījumu ID un izsekošanas ID, taču tiem nav jāatrodas vienā krātuves sistēmā.

Izveidojiet pilnvaru un izmaksu virsgrāmatu, nevis tikai skaitītājus

Tokenu skaitītāji ir noderīgi diagrammām, taču ar tiem nepietiek rēķinu izrakstīšanai vai incidentu izmeklēšanai. Virsgrāmatai jāatspoguļo stāvokļa pārejas. Izveidojiet rindu, kad vārteja pieņem pieprasījumu, un pēc tam atjauniniet to, kad pieprasījums turpinās.

Noderīgi virsgrāmatas stāvokļi

• pieņemts: autentifikācijas un politikas pārbaudes ir izietas.
• pārsūtīts: pieprasījums tika nosūtīts pakalpojumu sniedzējam.
• straumēšana: pakalpojumu sniedzējs sāka atdot pilnvaras.
• pabeigts: atbilde ir veiksmīgi pabeigta.
• user_aborted: klients tika atvienots pirms pabeigšanas.
• mēģināja vēlreiz: tika veikts papildu nodrošinātāja mēģinājums.
• fallback_used: pēc neveiksmes vai politikas atbilstības tika atlasīts cits modelis vai pakalpojumu sniedzējs.
• neizdevās: pieprasījums beidzās bez izmantojamas atbildes.
• saskaņots: pakalpojumu sniedzēja lietojuma vai izmaksu dati tika salīdzināti un lietoti.

Šis stāvokļa modelis palīdz uztvert izplatītākās norēķinu un analīzes kļūdas: straumētas atbildes, kad klients pārtrauca savienojumu, atkārtota mēģinājuma mēģinājumi, par kuriem pakalpojumu sniedzējs ir iekasējis maksu, bet slēpts no lietotāja, rezerves ceļi, kas skaitīja nepareizu modeli, un kešatmiņas uzskaites atšķirības starp pakalpojumu sniedzējiem.

Izmantojiet OpenTelemetry GenAI konvencijas un pēc tam uzmanīgi paplašiniet

OpenTelemetry GenAI semantiskās konvencijas nodrošina pārnēsājamu vārdu krājumu modeļa darbībām. Izmantojiet šos noteikumus attiecībā uz tādiem izplatītiem atribūtiem kā darbības nosaukums, nodrošinātājs, modelis, pieprasījuma parametri, atbildes pabeigšanas iemesli, pilnvaras lietojums un kļūdas statuss, ja tie ir piemēroti.

Tomēr pakalpojumu sniedzēju neitrālas konvencijas neaptvers visas vārtejas uzņēmējdarbības dimensijas. Pievienojiet vārtejai piederošus atribūtus vai virsgrāmatas kolonnas:

• īrnieka ID, komandas ID, tālākpārdevēja klienta ID un lietotnes ID;
• vārtejas API atslēgas ID un atslēgas darbības joma;
• norēķinu plāns, tēriņu ierobežojums un budžeta politika;
• modeļa aizstājvārds un maršrutēšanas politikas versija;
• uzvednes veidnes ID un uzvednes versija;
• darbplūsmas nosaukums un darbplūsmas darbība;
• aptuvenās izmaksas, galīgās rēķina izmaksas un saskaņošanas statuss.

Kompromiss ir kardinalitāte. Šie lauki ir vērtīgi izmeklēšanai, taču tie var padarīt metriku dārgu un trokšņainu, ja tos visur izmanto kā metrikas etiķetes. Praktisks noteikums ir šāds: zemas kardinalitātes agregāti tiek izmantoti metrikā; augstas kardinalitātes identifikatori tiek novirzīti uz pēdām, žurnāliem un virsgrāmatām.

Izstrādājiet drošu uzvedni un izvades reģistrēšanu

Pilnīga tūlītēja reģistrēšana atvieglo atkļūdošanu, bet palielina privātumu, atbilstību, glabāšanu un iekšējās informācijas risku. Drošāka noklusējuma ir metadatu novērošanas iespēja.

Noklusējums: tikai metadati

Lielākajai daļai produkcijas datplūsmas uzglabājiet:

• uzvednes veidnes ID un versija;
• normalizēto uzvedņu un izvadu jaucējvārdi;
• ievades, izvades, kešatmiņā saglabāto un konteksta pilnvaru skaits;
• atbildes shēmas nosaukums un validācijas rezultāts;
• drošības etiķetes un politikas lēmumi;
• kļūdu kopsavilkumi un nodrošinātāja kļūdu klases;
• izgūstiet metadatus, nevis neapstrādātus dokumentus.

Izvēlēties: kontrolēta satura uztveršana

Ja dziļai atkļūdošanai nepieciešams neapstrādāts vai rediģēts saturs, ir nepieciešama skaidra politika. Labas vadīklas ietver vides atļaušanas sarakstus, nomnieka piekrišanu, paraugu ņemšanu, maksimālo lietderīgās slodzes garumu, automātisku rediģēšanu, īsus saglabāšanas logus, šifrēšanu, piekļuvi, kas balstīta uz lomām, audita žurnālus un sensitīvu incidentu apstiprināšanas ceļu.

Neuztveriet rediģēšanu kā perfektu. Tas samazina risku; tas to nenovērš. Regulētas vai augstas jutības darba slodzes gadījumā apsveriet iespēju saglabāt tikai jaucējus un atkārtoti atskaņot problēmas sintētiskā instalācijā ar apstiprinātiem testa datiem.

Pievienojiet RAG novērojamību kā atsevišķu slāni

Izguves papildināšana var mainīt gan kvalitāti, gan izmaksas. Reģistrējot tikai galīgo modeļa izsaukumu, tiek paslēpts galvenais iemesls, kad retrīvers atgriež pārāk daudz gabalu, novecojušu dokumentu vai neatbilstošu kontekstu.

Katrai izguves darbībai tveriet:

• rādītāja vai kolekcijas nosaukums;
• izguves stratēģija un iegulšanas modelis;
• dokumentu ID vai jauktie ID;
• gabalu skaits un kopējais konteksta pilnvaras;
• izguves latentums;
• augstāko punktu sadalījums, ja pieejams;
• atsauces pārklājums;
• vai gala atbildē tika izmantots izgūtais konteksts.

Tas ļauj atšķirt “modelis pasliktinājās” no “retrīvers sāka sūtīt zemas kvalitātes vai pārmērīgu kontekstu”. Tas arī palīdz noteikt darbplūsmas, kurās konteksta marķieri dominē kopējās izmaksās.

Saskaņojiet vārtejas lietošanu ar pakalpojumu sniedzēja norēķiniem

Vārtejas aprēķini ir pieejami nekavējoties. Pakalpojumu sniedzēja puses norēķinu dati parasti ir lēnāki, bet autoritatīvāki. Izmantojiet abus.

Ikdienas saskaņošanas darbā ir jāsalīdzina vārtejas virsgrāmatas rindas ar pakalpojumu sniedzēja lietošanas API, izmaksu API, informācijas paneļa eksportēšanu vai rēķinu eksportēšanu. Grupējiet deltas pēc pakalpojumu sniedzēja, modeļa, projekta un laika loga. Izsekojiet atšķirības atsevišķi ievades marķieriem, izvades marķieriem, kešatmiņā saglabātajiem marķieriem, pieprasījumu skaitam un izmaksām.

Biežākās saskaņošanas atšķirības

• Straumēšana tiek pārtraukta: vārteja var redzēt pārtrauktu klientu, kamēr pakalpojumu sniedzējs joprojām izraksta rēķinu par ģenerētajiem marķieriem.
• Atkārtoti mēģinājumi: par vairākiem mēģinājumiem var tikt iekasēta maksa pat tad, ja tiek atgriezta tikai viena pēdējā atbilde.
• Tūlītēja kešatmiņa: pakalpojumu sniedzēji kešatmiņā saglabāto marķieru uzskaiti var parādīt atšķirīgi.
• Noapaļošana: nelielas atšķirības pēc pieprasījuma var kļūt redzamas mērogā.
• Pakešu vai līmeņa atlaides: pakalpojumu sniedzēja rēķinos var tikt piemērotas cenas, kuras reāllaika aprēķins vēl nezināja.
• Pakalpojumu sniedzēja puses izmaiņas: modeļa cenu noteikšana, pilnvaru darbība vai rēķinu eksportēšana laika gaitā var mainīties.

Kad saskaņošana atrod delta, izvairieties no virsgrāmatas klusas pārrakstīšanas. Saglabājiet sākotnējo aprēķinu, nodrošinātāja saskaņoto vērtību, saskaņošanas avotu un iemesla kodu, ja tas ir zināms.

Informācijas paneļi, kas atbild uz darbības jautājumiem

Sāciet informācijas paneļus no lasītāja problēmām, nevis no iedomības rādītājiem. Noderīgi skati:

• maksa par nomnieku, komandu, lietotni un darbplūsmu;
• maksa par veiksmīgu uzdevumu, nevis tikai maksa par pieprasījumu;
• p50, p95 un p99 latentums pēc pakalpojumu sniedzēja, modeļa un modeļa aizstājvārda;
• atkāpšanās biežums un atkārtoto mēģinājumu biežums pēc maršruta;
• noildzes rādītājs un pakalpojumu sniedzēja kļūdu klases tendences;
• kešatmiņas trāpījumu koeficients un kešatmiņas marķiera ietaupījuma aprēķins;
• strukturētās izvades validācijas kļūdu īpatsvars;
• labākās uzvednes versijas pēc kļūdas budžeta sadedzināšanas;
• RAG konteksta marķiera koplietošana pēc darbplūsmas;
• aizsargmargu bloki un tūlītējas iesmidzināšanas klasifikatora trāpījumi.

Lai brīdinātu, apvienojiet tehniskos un biznesa signālus. Pēkšņs īrnieka tēriņu pieaugums var būt steidzamāks nekā neliels globāls latentuma pieaugums. Atkāpšanās ātruma lēciens pēc modeļa aizstājvārda maiņas var norādīt uz saderības problēmu. Atkārtotas 401, 429 vai 5xx atbildes var norādīt uz galvenajām problēmām, kvotas izsmelšanu vai pakalpojumu sniedzēja nestabilitāti.

Minimāla ieviešanas plūsma ar OpenAI saderīgam starpniekserveram

Starpniekserveram /chat/completions plūsma var būt vienkārša:

1. Saņemiet pieprasījumu un piešķiriet request_id un izsekojiet kontekstu.
2. Autentificējiet vārtejas atslēgu un nosakiet nomnieka, komandas, lietotnes un politikas darbības jomu.
3. Izveidojiet vecākvārtejas diapazonu.
4. Izveidojiet virsgrāmatas rindu ar statusu pieņemts.
5. Atrisiniet modeļa aizstājvārdu atbilstoši nodrošinātāja modelim un maršrutēšanas politikas versijai.
6. Ierakstīt metadatus: darbība, uzvednes veidnes ID, shēmas nosaukums, uzvednes jaucējkods un satura uztveršanas politika.
7. Sāciet modeļa izsaukuma posmu, izmantojot GenAI semantiskos atribūtus, ja piemērojams.
8. Pārsūtiet pieprasījumu atlasītajam pakalpojumu sniedzējam.
9. Straumēšanai atjauniniet stāvokli, kad tiek saņemts pirmais gabals, un uzskaitiet lietojumu tik precīzi, cik to atļauj pakalpojumu sniedzēja atbilde.
10. Pabeidzot, parsējiet nodrošinātāja lietojumu, pabeigšanas iemeslu, statusu un kļūdu klasi.
11. Atjauniniet virsgrāmatu ar marķieriem, aptuvenajām izmaksām, atkārtotā mēģinājuma/atkāpšanās informāciju un galīgā pieprasījuma statusu.
12. Emitēt metriku no virsgrāmatas un diapazona datiem.
13. Izpildiet ikdienas saskaņošanu un veikala nodrošinātāja apstiprinātās izmaksas atsevišķi no sākotnējās aplēses.

Izklāšanas kontrolsaraksts

• Definējiet kanonisko pieprasījumu ID un izsekošanas ID.
• Pieņemt OpenTelemetry GenAI atribūtus parastā modeļa telemetrijai.
• Izveidojiet vārtejas lietojuma virsgrāmatu ar pieprasījuma stāvokļa pārejām.
• Normalizē pakalpojumu sniedzēja, modeļa, modeļa aizstājvārda, nomnieka, lietotnes un darbplūsmas dimensijas.
• Neturiet augstas kardinalitātes izmeklēšanas datus no metrikas etiķetēm.
• Pēc noklusējuma atspējojiet neapstrādātas uzvednes un izvades tveršanu.
• Pievienojiet precīzas politikas attiecībā uz izlasi, rediģēšanu, saglabāšanu un piekļuves kontroli.
• Tveriet izguves metadatus RAG darbplūsmām.
• Izveidojiet informācijas paneļus izmaksām, latentumam, uzticamībai, validācijai un nomnieka uzvedībai.
• Saskaņojiet vārtejas aprēķinus ar pakalpojumu sniedzēja lietojumu un izmaksu eksportēšanu.
• Brīdinājums par tēriņiem, latentuma regresiju, atkāpšanās lēcieniem, validācijas kļūmēm un ar drošību saistītiem notikumiem.

Secinājums

Vairāku modeļu vārteja ir īstā vieta LLM novērojamības ieviešanai, jo tā redz pieprasījumus, pirms tie sasniedz jebkuru pakalpojumu sniedzēju, un var pievienot biznesa kontekstu, ko pakalpojumu sniedzēji nezina. Spēcīgākais dizains nav “visu reģistrē”. Tas ir slāņveida modelis: pakalpojumu sniedzējam neitrālas izsekošanas izpildei, izturīgs marķieris un izmaksu virsgrāmata norēķiniem, nomnieka analītika pārvaldībai, RAG metadati izguves kvalitātei un tūlītēja reģistrēšana, lai nodrošinātu drošu atkļūdošanu.

Sāciet ar metadatiem, stāvokļa pārejām un saskaņošanu. Pievienojiet satura tveršanu tikai tad, kad ir gatava politika, saglabāšana un piekļuves vadīklas. Šī secība sniedz izstrādātājiem nepieciešamos pierādījumus, lai atkļūdotu latentumu, kvalitāti un tēriņus, nepārvēršot novērojamību par jaunu datu iedarbības risku.

Saistīta informācija

• API uzvedību un LMA3 fallback. maršrutēšana
• uzvednes kešatmiņas un pakešu izmaksu kontroles modeļi
• komandas API atslēgu pārvaldība un tēriņu ierobežojumi