Därför fungerar inte din vanliga övervakning för AI-appar

Låt mig vara rak: om du övervakar din LLM-drivna applikation på samma sätt som du övervakar dina API-endpoints, så blundar du för verkligheten.

Jag ser det hela tiden. Team sätter upp sin AI-tjänst, kopplar in den i befintlig infrastruktur, nickar åt de gröna lamporna – och får sedan problemedelande från användare om svar som inte håller måttet, eller en faktura som är tre gånger högre än väntat. Dashboardsen visar att allt är frid och fröjd. Det är det inte.

Problemet handlar inte bara om att välja andra mätvärden. Det är att AI-system bryter mot de grundläggande antaganden som all övervakningsarkitektur bygger på.

Webbtjänster-passningen håller inte

Traditionell webbövervakning utgår från en ren signal: en förfrågan kommer in, arbete utförs, ett svar skickas ut. Framgång eller misslyckande är binärt. Svarstid är svarstid. Din 99:e percentil säger något vettigt.

LLM:er förstör varje ett av de antagandena.

Ett svar levereras inte i ett stycke – det genereras token för token, vilket betyder att "svarstid" egentligen är minst tre olika siffror beroende på var i genereringsprocessen du befinner dig. Ett HTTP 200-svar säger ingenting om utdatakvalitet. Kostnaden skalas med tokens, inte förfrågningar. Och de mest skadliga felen är helt tysta: modellen返回er självsäkert nonsens med en perfekt HTTP-statuskod.

Time to First Token: Siffran användarna faktiskt märker

När någon skickar en prompt till din AI-funktion upplever de först en sak: väntan. Specifikt väntar de på att första tokenen ska dyka upp på skärmen. Det är Time to First Token (TTFT), och det är det närmaste vi kommer "upplevd svarstid" i LLM-världen.

Det som gör TTFT knepigt är att det växer med prompt-längden. Bygger du ett RAG-system som proppar massiva context windows i varje förfrågan för att förbättra noggrannheten, så saboterar du samtidigt den upplevda prestandan. Det är en fundamental avvägning som traditionell övervakning inte kommer att visa upp för dig.

Inter-Token Latency: Flödesfaktorn

När streamingen väl börjar utvecklar användarna förväntningar om läshastighet. Inter-Token Latency (ITL) – mellanrummet mellan konsekutiva tokens – avgör om output känns slät eller hackig.

Användare är förvånansvärt toleranta mot en långsam men konsekvent ström. De hatar en snabbare ström som fryser och hackar. Din övervakning bör skilja mellan dessa upplevelser, även när råthroughput ser acceptabel ut.

End-to-End Latency: Kontext är allt

Den p99-metriken som fungerar strålande för ditt REST API kommer att vilseleda dig helt för AI-förfrågningar. Varför? Eftersom en 50-token klassificeringsuppgift och en 2 000-token rapportgenerering har helt olika svarstidsprofiler, och att slå ihop dem till ett genomsnitt producerar en siffra som inte representerar någonting.

Spåra svarstid per användningsfall. Varje metric bör motsvara en arbetslast med konsekventa egenskaper. Annars optimerar du för en abstraktion som inte existerar.

Tysta fel: Den skrämmande biten

Här är det läskigaste: de värsta produktionsproblemen med AI-system genererar ofta noll larm.

Din modell börjar generera självsäkra hallucinationer. Din prompt-drift introducerar subtil bias. Den hämtade kontexten ignoreras till förmån för träningsminnen. Allt detta returnerar HTTP 200, slutförs inom acceptabel tid, och ser helt friskt ut på din dashboard.

Uptime-kontroller kommer inte att fånga de här problemed. Du behöver output-kvalitetsövervakning, och det är svårare att instrumentera men absolut nödvändigt.

Vad som faktiskt spelar roll

Gruppera dina AI-metrics kring de frågor de besvarar:

• Är det snabbt? TTFT, ITL, per-use-case latency percentiler
• Kan det skala? Token throughput, ködjup, kontextutnyttjande
• Är det korrekt? Task completion rates, felmönster i outputs
• Håller det måttet? Kostnad per uppgift, token-effektivitet, modellkonsistens
• Hur beter det sig? (För agenter) Task completion, step counts, loop-detection

Några av de här siffrorna får du gratis från din infrastruktur. De flesta får du inte. Att bygga custom-instrumentering för AI-arbetsbelastningar är inte valfritt – det är det enda sättet att se vad som faktiskt händer.

Teamen som får det här rätt använder inte bättre dashboards. De ställer bättre frågor.