Hvorfor din eksisterende monitoring ikke virker på AI-applikationer

Lad mig være ærlig: hvis du overvåger din LLM-baserede applikation på samme måde som dine API-endpoints, så opererer du uden instrumentbræt.

Jeg ser det hele tiden. Teams sætter deres AI-service op, kobler den til den eksisterende observability-stack, og ser grønne statuslamper. Og så får de en fuldstændig overraskelse, når brugerne klager over kvaliteten af svarene — eller når regningen dukker op 300% højere end forventet.

Problemet handler ikke bare om at vælge andre metrics. Det er, at AI-systemer fundamentalt bryder med de antagelser, vores overvågningsinfrastruktur blev bygget på.

Den klassiske webservices-tilgang passer ikke

Traditionel webmonitoring arbejder med et klart signal: en request kommer ind, arbejde sker, et svar kommer ud. Succes eller fejl er binært. Latency er latency. Din 99. percentil giver mening.

LLM'er smadrer hver eneste af de antagelser.

Et svar kommer ikke helt på én gang — det genereres token for token. Det betyder, at "latency" reelt er mindst tre forskellige tal, afhængigt af hvor du står i genereringsforløbet. En 200 OK-svar siger ingenting om outputkvaliteten. Omkostninger skalerer med tokens, ikke requests. Og de mest skadelige fejl er fuldstændig stille: modellen leverer selvsikker vås med en perfekt HTTP-statuskode.

Time to First Token: Det nummer brugerne faktisk mærker

Når nogen sender en prompt til din AI-funktion, oplever de først og fremmest ventetid. Specifikt venter de på, at det første token vises på skærmen. Det er Time to First Token (TTFT), og det er den nærmeste ting til "oplevet latency", der findes i LLM-verdenen.

Det tricky ved TTFT er, at det vokser med prompt-længden. Hvis du bygger et RAG-system, der propper massive context windows ind i hver request for at forbedre nøjagtigheden, så torpederer du samtidig den oplevede performance. Det er en fundamental afvejning, som traditionel monitoring ikke vil vise dig.

Inter-Token Latency: Flow-faktoren

Når streaming først går i gang, udvikler brugerne forventninger om læsehastighed. Inter-Token Latency (ITL) — hullet mellem successive tokens — afgør, om output føles jævnt eller hakkende.

Brugere er overraskende tolerante over for en langsom, men konsistent stream. De hader en hurtigere stream, der fryser og stammer. Din monitoring bør skelne mellem de oplevelser, selv når rå throughput ser acceptabel ud.

End-to-End Latency: Kontekst er alt

Den p99-metrik, der fungerer perfekt til din REST API, vil vildlede dig fuldstændig for AI-requests. Hvorfor? Fordi en 50-token klassifikationsopgave og en 2.000-token rapportgenerering har vidt forskellige latency-profiler, og at samle dem i én gennemsnit giver et tal, der ikke repræsenterer noget som helst.

Track latency per use case. Hver metrik skal svare til én arbejdsbelastning med konsistente karakteristika. Ellers ender du med at optimere for en abstraktion, der ikke eksisterer.

Silent Failure-problemet

Her kommer den uhyggelige del: de værste produktionsproblemer med AI-systemer producerer ofte nul alarmer.

Din model begynder at generere selvsikre hallucinationer. Din prompt drift introducerer subtil bias. Den retrieved kontekst ignoreres til fordel for træningsminder. Alt dette returnerer HTTP 200, fuldføres på acceptabel tid, og ser perfekt sundt ud i dit dashboard.

Det fanger du ikke med uptime checks. Du har brug for output quality monitoring, og det er sværere at instrumentere — men absolut essentielt.

Hvad der faktisk betyder noget

Gruppér dine AI-metrics omkring de spørgsmål, de besvarer:

• Er det hurtigt? TTFT, ITL, per-use-case latency percentiler
• Kan det skalere? Token throughput, kødybder, kontekstudnyttelse
• Er det korrekt? Task completion rates, fejlmønstre i outputs
• Holder det? Omkostning per opgave, token-effektivitet, model-konsistens
• Hvordan opfører det sig? (For agents) Task completion, step counts, loop detection

Nogle af de tal får du gratis fra din infrastruktur. De fleste gør du ikke. At bygge custom instrumentation til AI-workloads er ikke valgfrit — det er den eneste måde at se, hvad der faktisk sker.

De teams, der får det til at virke, bruger ikke bedre dashboards. De stiller bedre spørgsmål.