LLM-applikationer går i stykker på andre måder end traditionel software. En almindelig fejl giver et stack trace; en LLM-”fejl” er en kvalitetsafdrift, som du først opdager, når brugerne klager. Et almindeligt problem med latenstid er et langsomt endpoint; et LLM-problem med latenstid er et ræsonneringsforløb på 30-sekunder, mens brugeren stirrer på en spinner.
Traditionel observabilitet (Datadog, New Relic, Sentry) fortæller dig, at API-kaldet lykkedes på 8.4 sekunder og brugte 12,847 inputtokens. Den fortæller dig ikke, om svaret var godt, om modellen hallucinerede, om det forkerte værktøj blev kaldt, eller om kvaliteten er drevet siden sidste uge.
LLM-systemer i produktion kræver en anden observabilitetsstack. Eller i det mindste ekstra lag oven på de traditionelle. Denne artikel gennemgår, hvad der er særligt, hvad du skal instrumentere, og hvilke mønstre der fungerer.
Hvad er anderledes ved LLM-observabilitet?
Her er nogle karakteristiske egenskaber ved LLM-systemer, som traditionel observabilitet ikke håndterer:
Ikke-determinisme på enhedsniveau. Det samme input giver forskellige output på tværs af kald. Spørgsmålet “Virkede dette korrekt?” kan ikke besvares ved at kontrollere statuskoder.
Kvalitet som primær måling. Latenstid og omkostninger betyder noget, men kvaliteten betyder mest — og er sværest at måle.
Flertrinsspor. En brugerforespørgsel kan udløse 5-50 LLM-kald (agentløkker, RAG-søgning, struktureret udtrækning, refleksion). Hvert kald indgår i et større spor.
Omkostningsvariation på tokenniveau. Et enkelt kald kan koste fra €0.001 til €1.00 afhængigt af promptstørrelse, outputlængde og model. Samlede omkostninger kræver fordeling pr. kald.
Afdrift over tid. Modeller opdateres. Prompts udvikler sig. Inputfordelinger ændrer sig. Kvaliteten flytter sig, og du skal kunne se bevægelsen.
Følsomme data. Input og output er ofte de mest værdifulde diagnosticeringsdata, men også de mest følsomme. Disciplin i logningen er afgørende.
Lange asynkrone forløb. Agentkørsler, der tager minutter. Batchjob i baggrunden. Streamede svar. Traditionel observabilitet baseret på request/response passer ikke.
Det er ikke teoretiske bekymringer. Alle produktionsteams, der driver LLM-systemer, møder dem.
Observabilitetsstacken
En komplet stack til LLM-observabilitet har disse lag:
1. Instrumentering på kaldniveau. Hvert LLM-kald logges: input, output, latenstid, omkostning, model og status.
2. Instrumentering på sporniveau. Arbejdsgange med flere kald samles i spor. Du kan se hele kaldkæden for en brugerforespørgsel.
3. Målinger på applikationsniveau. Aggregeringer pr. funktion, bruger og tenant.
4. Kvalitetsovervågning. Stikprøvebaseret eller fuldautomatisk kvalitetsvurdering.
5. Indsamling af brugerfeedback. Eksplicitte signaler (tommelfinger op/ned) og implicitte signaler (generér igen, afbryd).
6. Alarmering. Alarmer i realtid ved omkostningsspidser, forringet latenstid, kvalitetsfald og stigende fejlrate.
7. Fejlfindingsværktøjer. Når noget går galt, kan du finde sporet, se input og output og forstå hændelsesforløbet.
Vi gennemgår hvert lag.
Instrumentering på kaldniveau
Hvert LLM-kald bør oprette en logpost med:
{
"call_id": "uuid",
"timestamp": "2026-05-15T14:23:45Z",
"trace_id": "uuid", // for grouping into traces
"span_id": "uuid", // for parent-child relations
"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, // streaming
"status": "success",
"error": null,
"user_id": "user_123",
"tenant_id": "tenant_45",
"metadata": {
"session_id": "...",
"experiment_arm": "v3_test"
}
}
Det er det absolutte minimum. Registrér alt.
Vigtige implementeringsvalg:
Hvor skal der logges? Muligheder:
- Et dedikeret observabilitetsværktøj (Helicone, LangSmith, Phoenix, Braintrust, Arize).
- En generel observabilitetsplatform med LLM-udvidelser (Datadog LLM Observability, Sentry).
- Jeres egne logge eller database.
For de fleste teams: Vælg et dedikeret værktøj. De har brugergrænseflader, der er bygget specifikt til inspektion af LLM-kald. Læringskurven er beskeden sammenlignet med at bygge selv.
For større teams: Brug en kombination. Anvend et dedikeret værktøj til den LLM-specifikke brugergrænseflade, men send også data til den centrale observabilitetsplatform, så hændelser kan sammenholdes på tværs af systemer.
Hvordan skal der instrumenteres? Muligheder:
- En proxy mellem applikationen og LLM-udbyderen (Helicones model).
- Et SDK, der omslutter kaldene i applikationskoden.
- En wrapperklasse, som kaldes manuelt ved hver LLM-kørsel.
Proxyer er nemmest, men øger latenstiden. SDK’er er elegante, men kræver integration. Manuel indpakning er mest fleksibel, men nemmest at glemme.
En pragmatisk løsning er SDK-indpakning ved den grænse, hvor applikationen kalder LLM’en. Ét sted instrumenteres, og alt andet passerer gennem det.
Hvad skal logges? Nogle praktiske overvejelser:
- Afkort meget lange input/output (men log, at de er afkortet).
- Hash eller bortredigér personhenførbare oplysninger (mens originalen om nødvendigt kan hentes via et sikkert opslag).
- Log aldrig legitimationsoplysninger, heller ikke i fejlforløb.
- Ved streaming logges både latenstid til første token og samlet latenstid.
Instrumentering på sporniveau
En enkelt brugerhandling omfatter ofte mange LLM-kald. Uden instrumentering på sporniveau har du tusind kaldlogge uden mulighed for at se, hvilke kald der hørte til samme brugerhandling.
Implementering:
Generering af spor-id. Opret et unikt spor-id ved starten af en brugerforespørgsel. Send det med gennem alle efterfølgende kald.
Overordnede og underordnede spans. I et spor har hvert kald et span-id og eventuelt et overordnet span-id. Det skaber et træ, som viser kaldhierarkiet.
Navngivning af operationer. Hvert span navngives (“summarize_document”, “extract_entities”, “tool_call:search”). Sporet viser hele operationskæden.
En sporvisning i brugergrænsefladen:
Trace abc-123 (12.3s total)
├─ 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]
Nu kan du se, hvad systemet faktisk gjorde for denne brugerforespørgsel. Du kan finde langsomme, dyre og fejlede kald — i deres rette sammenhæng.
Værktøjer, der håndterer dette godt: LangSmith, Phoenix (Arize), Helicone med tilpasset integration. Hertil kommer generel observabilitet (Datadog, OpenTelemetry) til sporing på tværs af systemer.
Målinger på applikationsniveau
Ud over de enkelte kald skal målinger aggregeres:
Pr. funktion.
- Antal kald.
- Gennemsnitlig latenstid.
- p50-, p95- og p99-latenstid.
- Gennemsnitlig omkostning pr. forespørgsel.
- Fejlrate.
- Kvalitetsscore (hvis den måles).
Pr. bruger/pr. tenant.
- Kald pr. bruger pr. dag.
- Omkostning pr. bruger.
- Storforbrugere/mønstre for misbrug.
Pr. model.
- Antal pr. model.
- Omkostningsandel pr. model.
- Fejlrate pr. model.
- Kvalitet (hvor den måles) pr. model.
Pr. funktion × pr. model.
- Hvilke funktioner bruger hvilke modeller?
- Hvor kan vi dirigere trafik til billigere modeller?
Disse dashboards styrer driftsbeslutninger: Hvilke funktioner er dyre, hvilke er langsomme, og hvilke kræver optimering?
Kvalitetsovervågning
Det sværeste lag er automatiseret kvalitetsvurdering.
Evalueringer (som vi har behandlet særskilt) køres på et defineret datasæt. Ved online kvalitetsovervågning vurderer du produktionstrafikken.
Tilgange:
LLM som dommer på en stikprøve. Udtag eksempelvis 1% af produktionstrafikken. Kør for hvert tilfælde en LLM-dommer, der bedømmer svaret på relevante dimensioner. Følg scorerne over tid. Alarmér ved fald.
Implicitte signaler. Spor regenereringer, afbrydelser, fejlrater, tid til gennemførelse og hyppigheden af opfølgende beskeder. Det er svage, men billige signaler. Brug dem som tidlige indikatorer.
Eksplicit brugerfeedback. Tommelfinger op/ned, knapper med “Hjalp dette?” og eksplicitte indberetninger. Højeste signalværdi, men laveste volumen.
Mønstergenkendelse. Bestemte dårlige mønstre (“I cannot help with that”, “I’m just an AI”, gentagne afvisninger) markeres automatisk. Det opdager visse regressioner med det samme.
En typisk opsætning:
- Udtag 1% af produktionskaldene.
- Kør en LLM-dommer på hvert kald med flerdimensionel bedømmelse.
- Aggregér til daglige scorer pr. funktion.
- Alarmér, hvis en funktion falder >10% fra uge til uge.
Omkostningen er reel, men afgrænset (1% af trafikken × en lille dommermodel = håndterbart for de fleste teams).
Omkostningsobservabilitet
LLM-omkostninger kan løbe løbsk. En enkelt fejl — en løbsk genforsøgsløkke eller en funktion, der bruger 10x flere tokens end forventet — kan give en regning på 10x, før nogen opdager det.
Lag i omkostningsobservabilitet:
Omkostning pr. kald. Omkostningen for hvert kald beregnes ved logning. Aggregeringer er tilgængelige med det samme.
Budgetalarmer. Daglige, ugentlige og månedlige budgetter pr. funktion/tenant. Alarmér, når tærsklerne overskrides (50%, 75%, 90%, 100%).
Anomaliregistrering. Er dagens omkostning 5x det typiske? Alarmér. Koster et enkelt kald 100x det typiske? Alarmér.
Omkostningsfordeling. Omkostninger pr. funktion, tenant og bruger. Find storforbrugerne.
Prognose. Hvad bliver månedens regning ud fra den aktuelle udvikling?
En nyttig dashboardvisning er et enkelt panel, der viser dagens omkostning sammenlignet med resten af denne uge og sidste uge, opdelt efter funktion.
Praktisk råd: Sæt hårde grænser, hvor det er muligt. En funktion, der bør koste €X/day, skal lukkes automatisk ved 10X. Omkostninger kan løbe hurtigt løbsk; grænsen standser det.
Observabilitet for latenstid
LLM-latenstid er mere nuanceret end for typiske API’er:
Samlet latenstid. Fra forespørgsel til endeligt svar.
Tid til første token (TTFT). Hvornår ser brugeren det første tegn ved streaming? Det har størst betydning for den oplevede latenstid i chatbrugerflader.
Tid til sidste token (TTLT). Hvor lang tid går der, før svaret er komplet?
Tokens pr. sekund. Outputhastigheden. Nogle modeller streamer langsommere end andre.
Latenstid for værktøjskald. I agentforløb: tid brugt på værktøjskald sammenlignet med LLM-kald.
Følg dem alle. Forskellige optimeringsstrategier retter sig mod forskellige målinger.
I brugervendt chat betyder TTFT mest. Et langsomt første token føles som en fejl; få tokens pr. sekund føles som gradvis fremdrift.
Ved batchbehandling betyder samlet latenstid noget; gennemløb betyder mere.
For agenter dominerer værktøjskaldenes latenstid ofte; optimering af LLM’en hjælper ikke, hvis værktøjerne er langsomme.
Fejlobservabilitet
LLM-specifikke fejl:
API-fejl. Hastighedsbegrænsninger, godkendelsesfejl og serverfejl. Som ved enhver anden API.
Valideringsfejl. Struktureret output overholdt ikke skemaet. Spor hyppigheden pr. funktion.
Indholdsfilterfejl. Udbyderen blokerede forespørgslen. Spor dem for at opdage promptproblemer.
Værktøjsfejl. Bestemte værktøjer fejler. Spor pr. værktøj.
Kvalitetsfejl. LLM-dommeren gav outputtet en dårlig score. Følg udviklingen over tid.
Signaler om hallucination. Registrering af sandsynlige hallucinationer (modellen hævdede noget, som ikke stod i kilden). Svært at opdage automatisk, men kan tilnærmes.
Omkostningsfejl. Kald, der koster langt mere end forventet. De tyder ofte på en fejl.
Hver type får sit eget dashboard. Hver type kan udløse alarmer.
Fejlfindingsværktøjer
Når noget går galt, skal du kunne finde og forstå det. Fejlfindingsfladen omfatter:
Søgning i spor. Find en bestemt brugerforespørgsel efter spor-id, bruger-id eller tidsstempel.
Inspektion af kald. Se hele forespørgslen, svaret, parametrene, latenstiden og omkostningen for ethvert kald.
Tidslinje for spor. Se kaldkæden visuelt i komplekse forløb.
Mulighed for genafspilning. Kan du køre et gammelt kald igen med en anden prompt/model og se, hvad der ville være sket? Afgørende for at teste rettelser.
Forskelvisning. Sammenlign to kald — forskellige versioner af samme prompt eller forskellige modeller — side om side.
Søgning efter indhold. Søg i samlingen af tidligere kald efter bestemte mønstre (“vis kald, hvor modellen sagde ‘I cannot help’”).
Det er disse funktioner, dedikerede værktøjer til LLM-observabilitet leverer. Det er et betydeligt arbejde at bygge dem selv; et værktøj er normalt billigere.
Privatliv og personhenførbare oplysninger
Logge fra LLM-observabilitet er følsomme. Input kan indeholde personhenførbare oplysninger, og output kan citere dem. Nogle gange kan de ikke undgås i loggen — de er nødvendige for fejlfinding.
Fremgangsmåder:
Tokenisering/hashing. Erstat identifikatorer med tokens. Originalen kan hentes via et særskilt, sikkert opslag. Hovedparten af loggene er fri for personhenførbare oplysninger.
Bortredigering ved logning. Registrér og bortredigér personhenførbare oplysninger, før de lander i observabilitetslageret. Bestemte mønstre (e-mailadresser, telefonnumre, personnumre) erstattes med pladsholdere.
Tenantisolering. Observabilitetsdata fra flere tenants isoleres pr. tenant. Data fra én tenant er ikke synlige for en anden.
Adgangskontrol. Hvem må se rå input/output? Adgangen logges.
Opbevaringspolitikker. Logge, der er ældre end X dage, slettes eller flyttes til koldt lager. Opbevaring af personhenførbare oplysninger er underlagt juridiske grænser i mange jurisdiktioner.
Retten til at blive glemt. Når en bruger anmoder om sletning (GDPR), skal vedkommendes logge kunne findes og slettes.
Dette er ikke valgfrit for systemer, der behandler personhenførbare oplysninger. Få det på plads tidligt; eftermontering er smertefuld.
Alarmering
Tærskler og signaler, der bør udløse alarmer:
Omkostning.
- Daglig omkostning > 2x det typiske.
- Omkostning for et enkelt kald > €5.
- Spids i omkostning pr. time > 5x.
Latenstid.
- p95-latenstid > 2x basislinjen.
- TTFT > 5s i chatbrugerfladen.
- Stigende antal timeouts ved værktøjskald.
Fejlrate.
- Fejlrate > 1% (typisk basislinje er 0.1-0.5%).
- Spids i en bestemt fejltype (valideringsfejl, hastighedsbegrænsninger).
Kvalitet.
- Kvalitetsscoren faldt > 10% fra uge til uge for en funktion.
- Andel negativ brugerfeedback > basislinjen.
- Regenereringsrate > basislinjen.
Mønster.
- Bestemte dårlige formuleringer optræder oftere.
- Pludselig ændring i inputfordelingen.
Hver alarm skal være konkret og handlingsanvisende. “Omkostningen er høj” hjælper ikke; “funktion X har brugt 10x sit budget i de seneste 30 minutter — sandsynligvis et løbsk forløb i kunde Y’s session” kan handles på.
Overvejelser ved flere tenants
Til B2B SaaS-applikationer:
Målinger pr. tenant. Hver kunde kan se eget forbrug, egne omkostninger og egen kvalitet.
Alarmer pr. tenant. Tilpasset kundens tærskler.
Fejlfinding pr. tenant. Support kan se en kundes spor (med passende adgangskontrol).
Konfiguration pr. tenant. Nogle kunder kan have andre modeller, prompts eller politikker. Observabilitetslaget afspejler dette.
Det øger kompleksiteten, men er afgørende for B2B i stor skala. Kundesupport kan ikke fejlfinde udsagnet “AI’en virker ikke for mig” uden adgang til spor for den pågældende tenant.
Værktøjsøkosystemet (2026)
Et overblik over værktøjer til LLM-observabilitet på skrivetidspunktet:
Dedikeret LLM-observabilitet:
- Helicone. Proxybaseret, nemt at integrere, stærke dashboards.
- LangSmith. Knyttet til LangChain-økosystemet, dybdegående sporing.
- Phoenix (Arize). Velegnet til open source, stærk inden for kvalitetsovervågning.
- Braintrust. Stærk kombination af evalueringer + observabilitet.
- PromptLayer. Fokuseret på prompts, stærk versionssporing.
- Weights & Biases Weave. Velegnet til ML-teams, integrerer med W&B’s bredere suite.
Generel APM med LLM-udvidelser:
- Datadog LLM Observability. Enterprisekvalitet, dyr.
- New Relic LLM Observability. Tilsvarende.
- OpenTelemetry + din foretrukne APM. OTel har semantiske GenAI-konventioner; instrumentér én gang, og vis data i mange værktøjer.
Byg selv:
- En Postgres-tabel med én række pr. kald rækker langt for de fleste teams.
- Tilføj en enkel brugergrænseflade til søgning og visning.
- Integrér med den eksisterende logningsinfrastruktur.
Det rette valg afhænger af teamstørrelse, skala, budget og eksisterende værktøjer. De fleste teams begynder med et dedikeret værktøj og overgår til en mere omfattende opsætning, når de vokser.
En praktisk opsætning
For et typisk mellemstort team, der begynder fra nul:
Uge 1: Vælg et værktøj (Helicone er ofte et nemt udgangspunkt). Integrér det i den primære kaldsti til LLM’en. Kontrollér, at kaldene logges.
Uge 2: Opsæt grundlæggende dashboards. Omkostning, latenstid og fejlrate pr. funktion.
Uge 3: Opsæt alarmer for omkostningsspidser og stigende fejlrate.
Uge 4: Tilføj instrumentering på sporniveau. Forbind spans på tværs af forløb med flere kald.
Måned 2: Implementér kvalitetsstikprøver. Vælg nogle få funktioner. Opsæt bedømmelse med LLM som dommer på 1% af trafikken.
Måned 3: Tilføj indsamling af brugerfeedback. Forbind tommelfinger op/ned eller tilsvarende.
Måned 4: Understøttelse af flere tenants, fintmaskede alarmer og fejlfindingsværktøjer.
Det er en fungerende observabilitetsstack. Hvert lag tilføjer funktionalitet. Hvert lag er værd at bygge. Springer du et af dem over, skaber du en blind vinkel.
Hvad går galt uden den?
Her er et kort katalog over hændelsesmønstre, der går igen hos teams uden ordentlig LLM-observabilitet:
-
En fejl fik en funktion til at gentage kald i en tæt løkke. Uventede omkostninger på et femcifret beløb hobede sig op i løbet af en weekend. Det blev først opdaget, da månedsregningen kom. (Varianter af denne historie forekommer så ofte, at mønstret er vigtigere end de konkrete tal.)
-
En modelopdatering ændrede adfærden ubemærket. Kvaliteten faldt i en vigtig funktion. Brugerne klagede, men udviklerne troede, det var “lejlighedsvis mærkelig adfærd”. Der gik to måneder, før det blev koblet til modelændringen.
-
En ny promptversion blev udrullet. Den skabte ved en fejl en regression i et vigtigt brugerforløb. Uden målinger pr. forløb opdagede ingen det i flere uger.
-
Et agentsystem begyndte at køre i ring. Nogle brugersessioner havde 200+ LLM-kald. Det tog flere timers undersøgelse at finde løkken, fordi der ikke var instrumentering på sporniveau.
-
En godkendelsesfejl i et værktøj udviklede sig til forvirring hos agenten. Agenten blev ved med at “prøve ting” og øge omkostningerne. Uden alarmer fortsatte det i timevis.
-
En promptinjektion fik AI’en til at lække systeminstruktioner. Personhenførbare oplysninger blev videregivet. Uden observabilitet kunne teamet ikke uden videre identificere de berørte brugere.
Det er ikke teori. Det sker. Observabilitet forebygger det meste eller opdager det hurtigt.
Instrumentér før hændelsen
LLM-observabilitet er en selvstændig disciplin. Traditionel APM er nødvendig, men utilstrækkelig. De særlige lag — kaldniveau, sporniveau, kvalitet, omkostning, latenstid, fejl og fejlfinding — er alle nødvendige.
Værktøjerne findes. Vælg ét. Integrér tidligt. Investér i dashboards, alarmer og processer, der opdager problemerne før brugerne.
Teams, der gør det:
- Opdager fejl på timer frem for uger.
- Styrer omkostningerne forudsigeligt i stedet for at få overraskende regninger.
- Fastholder kvaliteten over tid i stedet for at lade den drive.
- Fejlfinder systematisk i stedet for at gætte.
Teams, der ikke gør det, oplever før eller siden en hændelse, der tvinger dem til det. Det er bedre at instrumentere før hændelsen end efter.
