Vaadeldavus LLM-rakendustes: trace'imine, kulud, latentsus, kvaliteeditriiv

LLM-rakendused murduvad traditsioonilisest tarkvarast erinevalt. Tavaline buug on stack trace; LLM-i „buug" on kvaliteeditriiv, mida sa märkad alles siis, kui kasutajad kurdavad. Tavaline latentsuse probleem on aeglane otspunkt; LLM-i latentsuse probleem on 30-sekundiline arutluse trace, kus kasutaja vahib spinnerit.

Traditsiooniline vaadeldavus (Datadog, New Relic, Sentry) ütleb sulle, et API-kõne õnnestus 8,4 sekundiga ja kasutas 12 847 sisenditokenit. See ei ütle, kas vastus oli hea, kas mudel hallutsineeris, kas vale tööriist kutsuti või kas kvaliteet on eelmise nädalaga võrreldes triivinud.

Toodangu LLM-süsteemid vajavad teistsugust vaadeldavuse virna. Vähemalt täiendavaid kihte traditsiooniliste peale. See artikkel käsitleb, mis on erinev, mida instrumenteerida ja mustreid, mis töötavad.

Mis on LLM-i vaadeldavuse juures erinev

Mõned LLM-süsteemide iseloomulikud omadused, millega traditsiooniline vaadeldavus ei tegele:

Mittedeterministlikkus ühiku tasemel. Sama sisend toodab kõnede üleselt erinevaid väljundeid. „Kas see töötas õigesti?" küsimusele ei saa vastata statuse koode kontrollides.

Kvaliteet kui peamine mõõdik. Latentsus ja kulu loevad, aga kvaliteet loeb kõige rohkem — ja seda on kõige raskem mõõta.

Mitmesammulised trace'id. Kasutaja päring võib käivitada 5–50 LLM-kõnet (agenditsüklid, RAG-otsing, struktureeritud ekstraktimine, refleksioon). Iga kõne on osa suuremast trace'ist.

Tokenitasemel kuluvarieeruvus. Üks kõne võib varieeruda 0,001 €-st 1,00 €-ni, sõltuvalt prompti suurusest, väljundi pikkusest, mudelist. Kogukulud vajavad kõnepõhist atribuutimist.

Triiv aja jooksul. Mudelid uuenevad. Promptid arenevad. Sisendijaotused nihkuvad. Kvaliteet liigub; sa pead seda liikumist nägema.

Tundlikud kandjad. Sisendid ja väljundid on sageli kõige väärtuslikum diagnostiline andmestik, kuid ka kõige tundlikum. Logimisdistsipliin loeb.

Pikad asünkroonsed vood. Agendijooksud, mis võtavad minuteid. Taustal jooksvad partiitööd. Voogedastatud vastused. Traditsiooniline päringu/vastuse vaadeldavus ei sobi.

Need ei ole teoreetilised mured. Iga LLM-süsteeme jooksutav toodangu tiim põrkub neisse.

Vaadeldavuse virn

Täielikul LLM-i vaadeldavuse virnal on need kihid:

1. Kõne tasemel instrumentatsioon. Iga LLM-kõne logitakse: sisend, väljund, latentsus, kulu, mudel, staatus.

2. Trace'i tasemel instrumentatsioon. Mitmekõneliste töövoogude trace'id õmmeldakse kokku. Sa näed täielikku kõneahelat kasutaja päringu jaoks.

3. Rakenduse tasemel mõõdikud. Funktsiooni-, kasutaja-, üürniku-põhised koondid.

4. Kvaliteediseire. Valimipõhine või täielik automaatne kvaliteedihindamine.

5. Kasutaja tagasiside kogumine. Selgesõnaline (pöial üles/alla) ja kaudne (regenereerimine, loobumine) signaalid.

6. Hoiatamine. Reaalajas hoiatused kulude hüpetel, latentsuse halvenemisel, kvaliteedi langustel, veamäära kasvul.

7. Silumistööriistad. Kui midagi murdub, leiad trace'i, näed sisendeid ja väljundeid, mõistad, mis juhtus.

Käime iga läbi.

Kõne tasemel instrumentatsioon

Iga LLM-kõne peaks tootma logikirje:

{
  "call_id": "uuid",
  "timestamp": "2026-05-15T14:23:45Z",
  "trace_id": "uuid",  // trace'ideks rühmitamiseks
  "span_id": "uuid",   // vanem-laps suhete jaoks
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "claude-4-sonnet",
  "provider": "anthropic",
  "input_messages": [...],
  "output_message": "...",
  "input_tokens": 1842,
  "output_tokens": 384,
  "total_tokens": 2226,
  "cost_usd": 0.0084,
  "latency_ms": 2340,
  "first_token_ms": 1240,  // voogedastus
  "status": "success",
  "error": null,
  "user_id": "user_123",
  "tenant_id": "tenant_45",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

See on absoluutne miinimum. Salvesta kõike.

Peamised teostusvalikud:

Kus logida. Valikud:

• Pühendatud vaadeldavuse tööriist (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• Üldine vaadeldavuse platvorm LLM-laiendustega (Datadog LLM Observability, Sentry).
• Sinu enda logid/andmebaas.

Enamikule tiimidele: vali pühendatud tööriist. Neil on eesmärgipäraselt ehitatud UI-d LLM-kõnede inspekteerimiseks. Õppimiskõver on leebe võrreldes oma ehitamisega.

Suurematele tiimidele: segu. Kasuta pühendatud tööriista LLM-spetsiifilise UI jaoks, aga toru andmed ka oma keskmisse vaadeldavuse platvormi süsteemideülese korrelatsiooni jaoks.

Kuidas instrumenteerida. Valikud:

• Proksi, mis on sinu rakenduse ja LLM-pakkuja vahel (Helicone'i mudel).
• Ümbritsev SDK su rakenduse koodis.
• Ümbritsevklass, mida kutsud iga LLM-väljakutse jaoks käsitsi.

Proksid on lihtsaimad, kuid lisavad latentsust. SDK-d on puhtad, kuid nõuavad integratsiooni. Käsitsi ümbritsemine on kõige paindlikum, kuid kõige lihtsam unustada.

Pragmaatiline lähenemine: SDK ümbritsemine piiril, kus su rakendus LLM-i kutsub. Üks koht instrumenteerida; kõik muu voolab läbi.

Mida logida. Mõned praktilised kaalutlused:

• Lõika väga pikad sisendid/väljundid (aga logi lõikamine).
• Räsi või redigeeri PII (originaal on vajadusel turvalise otsingu kaudu kättesaadav).
• Ära logi volitusi, isegi mitte veateedel.
• Voogedastuse jaoks logi nii esimese tokeni latentsus kui koguladentsus.

Trace'i tasemel instrumentatsioon

Üks kasutaja tegevus hõlmab sageli paljusid LLM-kõnesid. Ilma trace'i tasemel instrumentatsioonita on sul tuhat kõnelogi ja pole võimalust teada saada, millised kõned olid millise kasutaja tegevuse osa.

Teostus:

Trace ID genereerimine. Genereeri unikaalne trace ID kasutaja päringu alguses. Edasta seda kõigi järgnevate kõnede kaudu.

Vanem-laps span'id. Trace'i sees on igal kõnel span ID ja (valikuliselt) vanema span ID. See loob puu, mis näitab kõneahelaid.

Operatsioonide nimetamine. Igale span'ile pannakse nimi („summarize_document", „extract_entities", „tool_call:search"). Trace näitab täielikku operatsiooniahelat.

Trace'i vaade sinu UI-s:

Trace abc-123 (12.3s kokku)
├─ classify_intent (450ms) [gpt-5-mini]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [claude-4-sonnet]
│   ├─ tool_call: search_internal (320ms)
│   ├─ tool_call: lookup_customer (180ms)
│   └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-4-haiku]

Nüüd sa näed, mida su süsteem selle kasutaja päringu jaoks tegelikult tegi. Sa võid leida aeglasi kõnesid, kalleid kõnesid, ebaõnnestunud kõnesid — kontekstis.

Tööriistad, mis seda hästi käsitlevad: LangSmith, Phoenix (Arize), Helicone kohandatud integratsiooniga. Pluss üldine vaadeldavus (Datadog, OpenTelemetry) süsteemideüleseks trace'imiseks.

Rakenduse tasemel mõõdikud

Lisaks üksikutele kõnedele koondmõõdikud:

Funktsiooni kaupa.

• Kõnede maht.
• Keskmine latentsus.
• p50, p95, p99 latentsus.
• Keskmine kulu päringu kohta.
• Veamäär.
• Kvaliteediskoor (kui mõõdetud).

Kasutaja/üürniku kaupa.

• Kõnesid kasutaja kohta päevas.
• Kulu kasutaja kohta.
• Rasked kasutajad / kuritarvituse mustrid.

Mudeli kaupa.

• Maht mudeli kaupa.
• Kuluosa mudeli kaupa.
• Veamäär mudeli kaupa.
• Kvaliteet (kus mõõdetud) mudeli kaupa.

Funktsioon × mudel.

• Millised funktsioonid kasutavad milliseid mudeleid?
• Kus saaksime suunata odavamatele mudelitele?

Need dashboard'id ajavad operatiivseid otsuseid: millised funktsioonid on kallid, millised aeglased, millised vajavad optimeerimist.

Kvaliteediseire

Raskeim kiht: automaatne kvaliteedihindamine.

Hindamiste jaoks (mida käsitleme eraldi) jooksed defineeritud andmestikku. Online'i kvaliteediseireks hindad toodanguliiklust.

Lähenemised:

LLM kohtunikuna valimi peal. Võta valim, näiteks 1% toodanguliiklusest. Iga jaoks jookseta kohtunikuLLM, mis skoorib vastuse asjakohastel dimensioonidel. Jälgi skoore aja jooksul. Hoiata languste korral.

Kaudsed signaalid. Jälgi regenereerimisi, loobumisi, veamäärasid, lõpuni jõudmise aega, järgmiste sõnumite sagedust. Need on nõrgad signaalid, kuid odavad. Kasuta varase märguandena.

Selgesõnaline kasutaja tagasiside. Pöial üles/alla, „kas see aitas?" nupud, selgesõnalised teated. Kõrgeim signaal, kuid madalaim maht.

Mustri tuvastamine. Konkreetsed halvad mustrid („Ma ei saa sellega aidata", „Ma olen lihtsalt AI", korduvad keeldumised) automaatselt märgistatud. Püüab mõned regressioonid kohe kinni.

Tüüpiline seadistus:

• Valimi 1% toodangukõnedest.
• Jookseta LLM-kohtunikku igal, skoorides mitmedimensiooniliselt.
• Koonda funktsiooni põhisteks päevaskoorideks.
• Hoiata, kui mis tahes funktsioon langeb nädal-nädala vastu >10%.

Kulu on reaalne, kuid piiratud (1% liiklusest × väike kohtunikumudel = hallatav enamikele tiimidele).

Kulude vaadeldavus

LLM-i kulud võivad spiraalida. Üks buug — kontrolli alt väljunud korduskatsete tsükkel, funktsioon, mis kasutab 10x rohkem tokeneid kui oodatud — võib toota 10x arve, enne kui keegi seda märkab.

Kulude vaadeldavuse kihid:

Kõnepõhine kulu. Iga kõne kulu arvutatakse logimisel. Koondid kohe saadaval.

Eelarvehoiatused. Päevased, iganädalased, kuised eelarved funktsiooni/üürniku kohta. Hoiata künniste ületamisel (50%, 75%, 90%, 100%).

Anomaaliate tuvastamine. Päevane kulu on 5x tüüpilisest? Hoiata. Üksikkõne kulu on 100x tüüpilisest? Hoiata.

Kulu atribuutimine. Funktsiooni, üürniku, kasutaja põhised kulud. Leia rasked koormajad.

Prognoos. Praeguse trajektoori põhjal, milline saab kuu lõpu arve olema?

Kasulik dashboard'i vaade: üks paneel, mis näitab tänast kulu vs ülejäänud sellest nädalast vs eelmine nädal, jaotatuna funktsiooni kaupa.

Praktiline näpunäide: pane kõvad limiidid, kus võimalik. Funktsioonil, mis peaks maksma X €/päev, on automaatne väljalülitus 10X juures. Kuluraskendamine juhtub kiiresti; limiit püüab selle kinni.

Latentsuse vaadeldavus

LLM-i latentsus on nüansirikkam kui tüüpilistel API-del:

Koguladentsus. Päringust lõpliku vastuseni.

Aeg-esimese-tokenini (TTFT). Voogedastuse jaoks, millal kasutaja näeb esimest tähemärki? See domineerib tajutavat latentsust chat-UX-i jaoks.

Aeg-viimase-tokenini (TTLT). Kui kaua kuni vastus on täielik?

Tokeneid sekundis. Väljundi määr. Mõned mudelid voogedastavad aeglasemalt kui teised.

Tööriistakõne latentsus. Agendivoogude jaoks aeg, mis on kulutatud tööriistakõnedes vs LLM-kõnedes.

Jälgi neid kõiki. Erinevad optimeerimisstrateegiad sihivad erinevaid mõõdikuid.

Kasutajaga kokku puutuva chati jaoks: TTFT on see, mis loeb. Aeglane esimene token tundub katki; aeglane tokenite sagedus tundub järk-järguline.

Partii jaoks: koguladentsus loeb; läbilaskevõime loeb rohkem.

Agentide jaoks: tööriistakõne latentsus sageli domineerib; LLM-i optimeerimine ei aita, kui tööriistad on aeglased.

Vigade vaadeldavus

LLM-spetsiifilised vead:

API vead. Päringukiiruse piirid, autentimise ebaõnnestumised, serverivead. Sama nagu mis tahes API.

Valideerimisvead. Struktureeritud väljund ei vastanud skeemile. Jälgi sagedust funktsiooni kaupa.

Sisufiltri vead. Pakkuja blokeeris päringu. Jälgi prompti probleemide tuvastamiseks.

Tööriista vead. Konkreetsed tööriistad ebaõnnestuvad. Jälgi tööriista kaupa.

Kvaliteedivead. Kohtuniku LLM skooris väljundi halvaks. Jälgi aja jooksul.

Hallutsinatsioonisignaalid. Tõenäoliste hallutsinatsioonide tuvastamine (mudel väitis midagi, mis pole allikas). Raske automaatselt tuvastada, kuid saab lähendada.

Kuluvead. Kõned, mis maksavad palju rohkem kui oodatud. Sageli viitavad buugile.

Igaüks saab oma dashboard'i. Igaüks võib käivitada hoiatusi.

Silumistööriistad

Kui midagi murdub, on sul vaja leida ja mõista. Silumispind hõlmab:

Trace'i otsing. Leia konkreetse kasutaja päring trace ID, kasutaja ID või ajatempli abil.

Kõne inspekteerimine. Iga kõne jaoks näed täielikku päringut, vastust, parameetreid, latentsust, kulu.

Trace'i ajaskaala. Keerukate voogude jaoks näed kõneahela visuaalselt.

Taasesituse võimekus. Vana kõne põhjal — kas saad selle uuesti jooksutada erineva prompti/mudeliga ja näha, mis oleks juhtunud? Kriitiline paranduste testimiseks.

Diff-vaade. Võrdle kahte kõnet — sama prompti erinevad versioonid, erinevad mudelid — kõrvuti.

Otsing sisu järgi. Otsi mineviku kõnede korpusest konkreetseid mustreid („näita mulle kõnesid, kus mudel ütles 'ma ei saa aidata'").

Need võimekused on see, mida pühendatud LLM-i vaadeldavuse tööriistad pakuvad. Nende ise ehitamine on märkimisväärne töö; tööriista kasutamine on tavaliselt odavam.

Privaatsus ja PII

LLM-i vaadeldavuse logid on tundlikud. Sisendid võivad sisaldada PII-d; väljundid võivad PII-d tsiteerida. Mõnikord ei saa sa nende logimist vältida — neid on vaja silumiseks.

Tavad:

Tokeniseerimine/räsimine. Asenda identifikaatorid tokenitega. Originaal kättesaadav eraldi turvalise otsingu kaudu. Suurem osa logidest on PII-vabad.

Logimisaegne redigeerimine. Tuvasta ja redigeeri PII enne, kui see vaadeldavuse hoidlasse jõuab. Konkreetsed mustrid (e-postid, telefoninumbrid, isikukoodid) asendatakse kohatäidetega.

Üürniku isolatsioon. Mitmeüürniku vaadeldavusandmed isoleeritakse üürniku kaupa. Ühe üürniku andmed pole teisele nähtavad.

Ligipääsukontrollid. Kes saab vaadata toorseid sisendeid/väljundeid? Logitud.

Säilitamispoliitikad. Logid, mis on vanemad kui X päeva, kustutatakse või liigutatakse külma hoidlasse. PII säilitamisel on paljudes jurisdiktsioonides juriidilised piirid.

Õigus unustusele. Kui kasutaja taotleb kustutamist (GDPR), peavad tema logid olema leitavad ja kustutatavad.

Need ei ole valikulised ühegi PII-d käitleva süsteemi jaoks. Saa need varakult õigeks; tagantjärele paigaldamine on valus.

Hoiatamine

Künnised ja signaalid, mis vajavad hoiatusi:

Kulu.

• Päevane kulu > 2x tüüpiline.
• Üksikkõne kulu > 5 €.
• Tunnikulu hüpe > 5x.

Latentsus.

• p95 latentsus > 2x põhitase.
• TTFT > 5s chat-UX-i jaoks.
• Tööriistakõne timeoutid kasvavad.

Veamäär.

• Veamäär > 1% (tüüpiline põhitase on 0,1–0,5%).
• Konkreetse veatüübi hüpe (valideerimisvead, päringukiiruse piirid).

Kvaliteet.

• Kvaliteediskoor langes mis tahes funktsioonil > 10% nädal nädala vastu.
• Kasutaja tagasiside negatiivne määr > põhitase.
• Regenereerimise määr > põhitase.

Muster.

• Konkreetsed halvad fraasid ilmuvad sagedamini.
• Äkiline muutus sisendijaotuses.

Iga hoiatus peaks olema konkreetne ja tegevuskõlblik. „Kulu on kõrge" pole abiks; „funktsiooni X kulu oli viimase 30 minuti jooksul 10x eelarvest — tõenäoliselt kontrollist väljunud kliendi Y sessioonis" on tegevuskõlblik.

Mitmeüürniku kaalutlused

B2B SaaS-rakenduste jaoks:

Üürniku põhised mõõdikud. Iga klient saab näha oma kasutust, kulusid ja kvaliteeti.

Üürniku põhised hoiatused. Spetsiifilised nende künnistele.

Üürniku põhine silumine. Tugi saab näha kliendi trace'e (sobivate ligipääsukontrollidega).

Üürniku põhine konfiguratsioon. Mõnedel klientidel võivad olla erinevad mudelid, promptid või poliitikad. Vaadeldavuse kiht peegeldab seda.

See lisab keerukust, kuid on B2B-le mastaabis hädavajalik. Klienditugi ei saa siluda „AI ei tööta mu jaoks" ilma üürniku põhise trace-ligipääsuta.

Tööriista ökosüsteem (2026)

Maastikuvaade LLM-i vaadeldavuse tööriistadest kirjutamise hetkel:

Pühendatud LLM-i vaadeldavus:

• Helicone. Proksipõhine; lihtne integreerida; tugevad dashboard'id.
• LangSmith. Seotud LangChaini ökosüsteemiga; sügav trace'imine.
• Phoenix (Arize). Avatud lähtekoodisõbralik; tugev kvaliteediseires.
• Braintrust. Tugev hindamiste + vaadeldavuse kombinatsioonis.
• PromptLayer. Prompti-keskne; tugev versioonide jälgimises.
• Weights & Biases Weave. ML-tiimisõbralik; integreerub W&B laiema komplektiga.

Üldine APM LLM-laiendustega:

• Datadog LLM Observability. Ettevõtte tasemel; kallis.
• New Relic LLM Observability. Sarnane.
• OpenTelemetry + sinu valitud APM. OTel'il on GenAI semantilised konventsioonid; instrumenteerib korra, vaata paljudes tööriistades.

Ehita ise:

• Postgres-tabel, kus on üks rida kõne kohta, viib enamiku tiimideni kaugele.
• Lisa lihtne UI otsingu ja kuvamise jaoks.
• Integreeri oma olemasoleva logimisinfrastruktuuriga.

Õige valik sõltub tiimi suurusest, mastaabist, eelarvest ja olemasolevast tööriistastikust. Enamik tiime alustab pühendatud tööriistaga ja migreerib mastaabi kasvades terviklikumale seadistusele.

Praktiline seadistus

Tüüpilisele keskmise suurusega tiimile, kes alustab nullist:

Nädal 1: Vali tööriist (Helicone on tavaline lihtne algus). Integreeri oma peamise LLM-kõneteega. Kontrolli, et kõnesid logitakse.

Nädal 2: Sea üles põhilised dashboard'id. Funktsiooni põhine kulu, latentsus, veamäär.

Nädal 3: Sea üles hoiatused kuluhüpetel ja veamäära kasvul.

Nädal 4: Lisa trace'i tasemel instrumentatsioon. Ühenda span'id mitmekõneliste voogude üle.

Kuu 2: Rakenda kvaliteedi valim. Vali mõned funktsioonid. Sea üles LLM-kohtuniku skoorimine 1% liikluse peal.

Kuu 3: Lisa kasutaja tagasiside kogumine. Pane käima pöial üles/alla või sarnane.

Kuu 4: Mitmeüürniku tugi, peenhäälestatud hoiatused, silumistööriistastik.

See on töötav vaadeldavuse virn. Iga kiht lisab võimekust. Iga on ehitamist väärt. Mis tahes vahelejätmine loob pimeala.

Mis läheb valesti ilma selleta

Lühike kataloog vahejuhtumitest, mida me oleme näinud tiimidel ilma korraliku LLM-i vaadeldavuseta:

• Buug pani funktsiooni kõnesid tihedas tsüklis korduvalt proovima. Viiekohalised ootamatud tasud akumuleerusid nädalavahetuse jooksul. Püüti kinni alles siis, kui kuine arve saabus. (Oleme näinud selle loo variante piisavalt palju, et konkreetsed numbrid loevad vähem kui muster.)

• Mudeliuuendus muutis vaikselt käitumist. Kvaliteet langes võtmefunktsiooni juures. Kasutajad kurtsid, kuid inseneerimine arvas, et tegu on „juhusliku veidrusega". Kaks kuud kuni mudelimuutusega korreleerimiseni.

• Uus prompti versioon juurutati. See regresseeris kogemata olulise kasutajavoo. Ilma vookohaste mõõdikuteta keegi nädalateks ei märganud.

• Agendisüsteem hakkas tsüklis jooksma. Mõnedel kasutajasessioonidel oli 200+ LLM-kõnet. Võttis tunde uurimist, et tsüklit leida, sest kellelgi polnud trace'i tasemel instrumentatsiooni.

• Tööriista autentimise ebaõnnestumine kaskadis agendi segadusse. Agent jätkas „asjade proovimist" ja kulusid kuhjus. Ilma hoiatusteta jooksis see tunde.

• Prompti süstimine põhjustas AI-l süsteemi juhiste lekitamist. PII avalikustati. Ilma vaadeldavuseta ei saanud tiim kergesti tuvastada, milliseid kasutajaid see oli mõjutanud.

Need ei ole teoreetilised. Need juhtuvad. Vaadeldavus hoiab enamiku ära või püüab need kiiresti kinni.

Kokkuvõte

LLM-i vaadeldavus on oma distsipliin. Traditsiooniline APM on vajalik, kuid ebapiisav. Spetsiifilised kihid — kõne tasemel, trace'i tasemel, kvaliteet, kulu, latentsus, viga, silumine — on kõik vajalikud.

Tööriistad on olemas. Vali üks. Integreeri varakult. Investeeri dashboard'idesse, hoiatustesse ja protsessidesse, mis püüavad probleemid kinni enne kasutajaid.

Tiimid, kes seda teevad:

• Püüavad buugid kinni tundides, mitte nädalates.
• Halduvad kulusid ennustatavalt, mitte ei saa üllatusarveid.
• Säilitavad kvaliteeti aja jooksul, mitte ei triivi.
• Siluvad süsteemselt, mitte ei arva.

Tiimid, kes ei tee, saavad lõpuks vahejuhtumi, mis sunnib neid. Parem instrumenteerida enne vahejuhtumit kui pärast.