Observerbarhet för LLM-appar: spårning, kostnader, latens och kvalitetsdrift

LLM-applikationer går sönder på andra sätt än traditionell programvara. Ett vanligt programfel ger en stackspårning; ett LLM-”fel” är en kvalitetsdrift som du upptäcker först när användarna klagar. Ett vanligt latensproblem är en långsam slutpunkt; ett latensproblem med en LLM är ett 30 sekunder långt resonemangsspår där användaren stirrar på en snurrande laddningsindikator.

Traditionell observerbarhet (Datadog, New Relic, Sentry) berättar att API-anropet lyckades på 8,4 sekunder och använde 12 847 indatatoken. Den berättar inte om svaret var bra, om modellen hallucinerade, om fel verktyg anropades eller om kvaliteten har försämrats sedan förra veckan.

LLM-system i produktion behöver en annan observerbarhetsstack. Eller åtminstone ytterligare lager ovanpå de traditionella. Den här artikeln beskriver vad som är annorlunda, vad du bör instrumentera och vilka mönster som fungerar.

Vad som skiljer LLM-observerbarhet

Några utmärkande egenskaper hos LLM-system som traditionell observerbarhet inte hanterar:

Icke-determinism på enhetsnivå. Samma indata ger olika utdata mellan anrop. Frågan ”Fungerade detta korrekt?” kan inte besvaras genom att kontrollera statuskoder.

Kvalitet som primärt mätetal. Latens och kostnad är viktiga, men kvaliteten är viktigast – och svårast att mäta.

Flerstegsspår. En användarfråga kan utlösa 5–50 LLM-anrop (agentloopar, RAG-hämtning, strukturerad extraktion och reflektion). Varje anrop ingår i ett större spår.

Kostnadsvariation på tokennivå. Ett enda anrop kan kosta mellan 0,001 och 1,00 euro beroende på promptstorlek, utdatalängd och modell. Aggregerade kostnader kräver fördelning per anrop.

Drift över tid. Modeller uppdateras. Prompter utvecklas. Indatafördelningar förändras. Kvaliteten rör sig och du måste kunna se rörelsen.

Känsliga nyttolaster. Indata och utdata är ofta de mest värdefulla diagnostiska uppgifterna, men också de känsligaste. Loggningsdisciplin är viktig.

Långa asynkrona flöden. Agentkörningar som tar flera minuter. Bakgrundskörningar i batch. Strömmade svar. Traditionell observerbarhet för begäran och svar passar inte.

Det här är inga teoretiska problem. Alla produktionsteam som kör LLM-system stöter på dem.

Observerbarhetsstacken

En fullständig observerbarhetsstack för LLM:er har följande lager:

1. Instrumentering på anropsnivå. Varje LLM-anrop loggas: indata, utdata, latens, kostnad, modell och status.

2. Instrumentering på spårnivå. Arbetsflöden med flera anrop fogas samman till spår. Du kan se hela anropskedjan för en användarbegäran.

3. Mätetal på applikationsnivå. Aggregeringar per funktion, användare och kundorganisation.

4. Kvalitetsövervakning. Automatiserad kvalitetsbedömning av ett urval eller av samtliga anrop.

5. Insamling av användaråterkoppling. Uttryckliga signaler (tummen upp/ned) och underförstådda signaler (generera om, avbryt).

6. Aviseringar. Aviseringar i realtid om kostnadstoppar, försämrad latens, kvalitetssänkningar och ökade felfrekvenser.

7. Felsökningsverktyg. När något går sönder kan du hitta spåret, se indata och utdata samt förstå vad som hände.

Vi går igenom varje lager.

Instrumentering på anropsnivå

Varje LLM-anrop bör skapa en loggpost med:

{
  "call_id": "uuid",
  "timestamp": "2026-05-15T14:23:45Z",
  "trace_id": "uuid",  // för gruppering i spår
  "span_id": "uuid",   // för relationer mellan överordnade och underordnade spann
  "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,  // strömning
  "status": "success",
  "error": null,
  "user_id": "user_123",
  "tenant_id": "tenant_45",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Det här är ett absolut minimum. Samla in allt.

Viktiga implementeringsval:

Var du loggar. Alternativ:

• Ett särskilt observerbarhetsverktyg (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• En generell observerbarhetsplattform med LLM-tillägg (Datadog LLM Observability, Sentry).
• Egna loggar eller en egen databas.

För de flesta team: välj ett särskilt verktyg. De har gränssnitt som är byggda för att inspektera LLM-anrop. Inlärningskurvan är måttlig jämfört med att bygga ett eget.

För större team: en kombination. Använd ett särskilt verktyg för det LLM-specifika gränssnittet, men skicka även data till den centrala observerbarhetsplattformen för korrelation mellan system.

Hur du instrumenterar. Alternativ:

• En proxy mellan appen och LLM-leverantören (Helicones modell).
• Ett inkapslande SDK i applikationskoden.
• En wrapper-klass som du anropar manuellt för varje LLM-anrop.

Proxyer är enklast men ökar latensen. SDK:er är rena men kräver integrering. Manuell inkapsling är mest flexibel men också lättast att glömma.

Ett pragmatiskt tillvägagångssätt: SDK-inkapsling vid gränsen där appen anropar LLM:en. Ett enda ställe att instrumentera; allt annat går genom det.

Vad du loggar. Några praktiska överväganden:

• Korta av mycket långa indata och utdata (men logga att de har kortats av).
• Hasha eller maskera personuppgifter (och gör originalet åtkomligt via säker uppslagning vid behov).
• Logga inte autentiseringsuppgifter, inte ens i felvägar.
• För strömning loggar du både latens till första token och total latens.

Instrumentering på spårnivå

En enda användaråtgärd innefattar ofta många LLM-anrop. Utan instrumentering på spårnivå har du tusen anropsloggar utan möjlighet att se vilka anrop som hörde till vilken användaråtgärd.

Implementering:

Generering av spår-ID. Skapa ett unikt spår-ID i början av en användarbegäran. Skicka det genom alla efterföljande anrop.

Överordnade och underordnade spann. Inom ett spår har varje anrop ett spann-ID och (valfritt) ett överordnat spann-ID. Det skapar ett träd som visar anropshierarkin.

Namn på operationer. Varje spann namnges (”summarize_document”, ”extract_entities”, ”tool_call:search”). Spåret visar hela operationskedjan.

En spårvy i gränssnittet:

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 vad systemet faktiskt gjorde för den här användarbegäran. Du kan hitta långsamma, dyra och misslyckade anrop – i sitt sammanhang.

Verktyg som hanterar detta väl: LangSmith, Phoenix (Arize) och Helicone med anpassad integrering. Därtill generell observerbarhet (Datadog, OpenTelemetry) för spårning mellan system.

Mätetal på applikationsnivå

Aggregera mätetal utöver enskilda anrop:

Per funktion.

• Anropsvolym.
• Genomsnittlig latens.
• p50-, p95- och p99-latens.
• Genomsnittlig kostnad per begäran.
• Felfrekvens.
• Kvalitetspoäng (om den mäts).

Per användare/kundorganisation.

• Anrop per användare och dag.
• Kostnad per användare.
• Tunga användare och missbruksmönster.

Per modell.

• Volym per modell.
• Kostnadsandel per modell.
• Felfrekvens per modell.
• Kvalitet per modell (där den mäts).

Per funktion × per modell.

• Vilka funktioner använder vilka modeller?
• Var kan vi dirigera till billigare modeller?

Dessa instrumentpaneler driver operativa beslut: vilka funktioner är dyra, vilka är långsamma och vilka behöver optimeras?

Kvalitetsövervakning

Det svåraste lagret: automatiserad kvalitetsbedömning.

För utvärderingar (som vi har behandlat separat) kör du mot ett definierat dataset. Vid kvalitetsövervakning online bedömer du produktionstrafik.

Metoder:

En LLM som bedömare för ett urval. Välj exempelvis 1 % av produktionstrafiken. Kör för varje anrop en bedömnings-LLM som poängsätter svaret i relevanta dimensioner. Följ poängen över tid. Avisera vid sänkningar.

Underförstådda signaler. Följ omgenereringar, avbrutna flöden, felfrekvenser, tid till slutförande och frekvensen av följdmeddelanden. Det är svaga signaler, men de är billiga. Använd dem som tidiga indikatorer.

Uttrycklig användaråterkoppling. Tummen upp/ned, knappar med ”var det här till hjälp?” och uttryckliga rapporter. Starkast signal men lägst volym.

Mönsterdetektering. Specifika dåliga mönster (”Jag kan inte hjälpa till med det”, ”Jag är bara en AI”, upprepade avslag) flaggas automatiskt. Det upptäcker vissa regressioner omedelbart.

En typisk uppsättning:

• Välj 1 % av produktionsanropen.
• Kör en LLM-baserad bedömare på vart och ett, med flerdimensionell poängsättning.
• Aggregera till dagliga poäng per funktion.
• Avisera om någon funktion sjunker mer än 10 % vecka för vecka.

Kostnaden är verklig men begränsad (1 % av trafiken × en liten bedömningsmodell = hanterbart för de flesta team).

Kostnadsobserverbarhet

LLM-kostnader kan skena. Ett enda fel – en okontrollerad omförsöksloop eller en funktion som använder 10 gånger fler token än väntat – kan ge en tiofaldig faktura innan någon märker något.

Lager för kostnadsobserverbarhet:

Kostnad per anrop. Kostnaden för varje anrop beräknas när det loggas. Aggregeringar är omedelbart tillgängliga.

Budgetaviseringar. Dagliga, veckovisa och månatliga budgetar per funktion/kundorganisation. Avisera när trösklar passeras (50 %, 75 %, 90 %, 100 %).

Avvikelsedetektering. Är dagskostnaden 5 gånger högre än normalt? Avisera. Är ett enskilt anrop 100 gånger dyrare än normalt? Avisera.

Kostnadsfördelning. Kostnader per funktion, kundorganisation och användare. Hitta storförbrukarna.

Prognos. Vad blir fakturan vid månadens slut utifrån den nuvarande utvecklingen?

En användbar instrumentpanel: en enda panel som visar dagens kostnad jämfört med resten av veckan och förra veckan, uppdelad efter funktion.

Praktiskt tips: sätt hårda gränser där det går. En funktion som bör kosta X euro per dag stängs automatiskt av vid 10X. Kostnader skenar snabbt; gränsen stoppar det.

Latensobserverbarhet

LLM-latens är mer nyanserad än för vanliga API:er:

Total latens. Från begäran till slutgiltigt svar.

Tid till första token (TTFT). Vid strömning: när ser användaren det första tecknet? Det här dominerar den upplevda latensen i chattgränssnitt.

Tid till sista token (TTLT). Hur lång tid tar det innan svaret är färdigt?

Token per sekund. Utdatatakt. Vissa modeller strömmar långsammare än andra.

Latens för verktygsanrop. För agentflöden: tid i verktygsanrop jämfört med LLM-anrop.

Följ samtliga. Olika optimeringsstrategier riktar sig mot olika mätetal.

För användarinriktad chatt är TTFT viktigast. En långsam första token känns som om något är trasigt; långsam tokenproduktion känns gradvis.

För batchjobb är total latens viktig, men genomströmning är ännu viktigare.

För agenter dominerar ofta verktygsanropens latens; det hjälper inte att optimera LLM:en om verktygen är långsamma.

Felobserverbarhet

LLM-specifika fel:

API-fel. Hastighetsbegränsningar, autentiseringsfel och serverfel. Samma som för alla API:er.

Valideringsfel. Strukturerade utdata följde inte schemat. Följ frekvensen per funktion.

Innehållsfilterfel. Leverantören blockerade begäran. Följ detta för att upptäcka promptproblem.

Verktygsfel. Specifika verktyg fallerar. Följ per verktyg.

Kvalitetsfel. En bedömnings-LLM gav dåliga poäng. Följ över tid.

Hallucinationssignaler. Upptäckt av sannolika hallucinationer (modellen påstod något som inte fanns i källan). Svårt att upptäcka automatiskt, men kan approximeras.

Kostnadsfel. Anrop som kostar mycket mer än väntat. De tyder ofta på ett programfel.

Varje kategori får en egen instrumentpanel. Var och en kan utlösa aviseringar.

Felsökningsverktyg

När något går sönder måste du kunna hitta och förstå det. Felsökningsytan omfattar:

Spårsökning. Hitta en viss användares begäran efter spår-ID, användar-ID eller tidsstämpel.

Anropsinspektör. Se fullständig begäran, svar, parametrar, latens och kostnad för varje anrop.

Spårtidslinje. Se anropskedjan visuellt för komplexa flöden.

Möjlighet till omkörning. Kan du köra om ett gammalt anrop med en annan prompt eller modell och se vad som skulle ha hänt? Avgörande för att testa korrigeringar.

Differensvy. Jämför två anrop – olika versioner av samma prompt eller olika modeller – sida vid sida.

Sökning efter innehåll. Sök bland tidigare anrop efter specifika mönster (”visa anrop där modellen sade ’Jag kan inte hjälpa till’”).

Det är sådana funktioner som särskilda observerbarhetsverktyg för LLM:er erbjuder. Att bygga dem själv är ett omfattande arbete; ett verktyg är vanligtvis billigare.

Integritet och personuppgifter

LLM-observerbarhetsloggar är känsliga. Indata kan innehålla personuppgifter och utdata kan citera personuppgifter. Ibland kan du inte undvika att logga dem – de behövs för felsökning.

Arbetssätt:

Tokenisering/hashning. Ersätt identifierare med token. Originalet kan hämtas via en separat säker uppslagning. Merparten av loggarna saknar personuppgifter.

Maskering vid loggning. Identifiera och maskera personuppgifter innan de hamnar i observerbarhetslagringen. Specifika mönster (e-postadresser, telefonnummer, personnummer) ersätts med platshållare.

Isolering per kundorganisation. Observerbarhetsdata för flera kunder isoleras per kundorganisation. En kunds data är inte synliga för en annan.

Åtkomstkontroller. Vem får se råa indata och utdata? Det loggas.

Lagringspolicyer. Loggar äldre än X dagar raderas eller flyttas till kallagring. Lagring av personuppgifter omfattas av rättsliga tidsgränser i många jurisdiktioner.

Rätten att bli bortglömd. När en användare begär radering (GDPR) måste personens loggar gå att hitta och radera.

Det här är inte valfritt för system som hanterar personuppgifter. Gör rätt från början; efterhandsanpassning är smärtsam.

Aviseringar

Trösklar och signaler som motiverar aviseringar:

Kostnad.

• Dagskostnad > 2 gånger det normala.
• Kostnad för ett enskilt anrop > 5 euro.
• Timkostnadstopp > 5 gånger.

Latens.

• p95-latens > 2 gånger baslinjen.
• TTFT > 5 s för chattgränssnitt.
• Allt fler tidsgränsöverskridanden i verktygsanrop.

Felfrekvens.

• Felfrekvens > 1 % (typisk baslinje är 0,1–0,5 %).
• Topp för en viss feltyp (valideringsfel, hastighetsbegränsningar).

Kvalitet.

• Kvalitetspoängen har sjunkit > 10 % vecka för vecka för någon funktion.
• Andelen negativ användaråterkoppling > baslinjen.
• Omgenereringsfrekvens > baslinjen.

Mönster.

• Specifika dåliga fraser förekommer oftare.
• Plötslig förändring av indatafördelningen.

Varje avisering ska vara specifik och åtgärdbar. ”Kostnaden är hög” hjälper inte; ”funktion X har kostat 10 gånger mer än budgeterat de senaste 30 minuterna – troligen en okontrollerad körning i kund Y:s session” går att agera på.

Överväganden för flera kundorganisationer

För B2B-SaaS-appar:

Mätetal per kundorganisation. Varje kund kan se sin egen användning, sina kostnader och sin kvalitet.

Aviseringar per kundorganisation. Specifika för kundens tröskelvärden.

Felsökning per kundorganisation. Supporten kan se en kunds spår (med lämpliga åtkomstkontroller).

Konfiguration per kundorganisation. Vissa kunder kan ha andra modeller, prompter eller policyer. Observerbarhetslagret återspeglar det.

Det ökar komplexiteten men är nödvändigt för storskalig B2B. Kundsupporten kan inte felsöka ”AI:n fungerar inte för mig” utan åtkomst till spår per kundorganisation.

Verktygsekosystemet (2026)

En översikt över verktyg för LLM-observerbarhet i skrivande stund:

Särskild LLM-observerbarhet:

• Helicone. Proxybaserat, enkelt att integrera, starka instrumentpaneler.
• LangSmith. Kopplat till LangChain-ekosystemet, djup spårning.
• Phoenix (Arize). Vänligt mot öppen källkod, starkt inom kvalitetsövervakning.
• Braintrust. Starkt på kombinationen utvärdering och observerbarhet.
• PromptLayer. Promptinriktat, starkt på versionsspårning.
• Weights & Biases Weave. Anpassat för ML-team, integreras med W&B:s bredare svit.

Generell APM med LLM-tillägg:

• Datadog LLM Observability. För företag, dyrt.
• New Relic LLM Observability. Liknande.
• OpenTelemetry + valfri APM. OTel har semantiska GenAI-konventioner; instrumentera en gång och visa i många verktyg.

Bygg själv:

• En Postgres-tabell med en rad per anrop räcker långt för de flesta team.
• Lägg till ett enkelt gränssnitt för sökning och visning.
• Integrera med den befintliga loggningsinfrastrukturen.

Rätt val beror på teamstorlek, skala, budget och befintliga verktyg. De flesta team börjar med ett särskilt verktyg och går över till en mer heltäckande lösning när de växer.

En praktisk uppsättning

För ett typiskt medelstort team som börjar från noll:

Vecka 1: Välj ett verktyg (Helicone är en vanlig och enkel start). Integrera med den huvudsakliga anropsvägen till LLM:en. Kontrollera att anrop loggas.

Vecka 2: Skapa grundläggande instrumentpaneler. Kostnad, latens och felfrekvens per funktion.

Vecka 3: Konfigurera aviseringar för kostnadstoppar och ökade felfrekvenser.

Vecka 4: Lägg till instrumentering på spårnivå. Koppla ihop spann i flöden med flera anrop.

Månad 2: Implementera kvalitetsurval. Välj några funktioner. Konfigurera poängsättning med en LLM-baserad bedömare för 1 % av trafiken.

Månad 3: Lägg till insamling av användaråterkoppling. Koppla in tummen upp/ned eller motsvarande.

Månad 4: Stöd för flera kundorganisationer, detaljerade aviseringar och felsökningsverktyg.

Det här är en fungerande observerbarhetsstack. Varje lager tillför en förmåga. Varje lager är värt att bygga. Om du hoppar över något skapas en blind fläck.

Vad som går fel utan den

En kort katalog över incidentmönster som återkommer hos team utan ordentlig LLM-observerbarhet:

• Ett programfel fick en funktion att försöka anropa om i en tät loop. Oväntade kostnader på femsiffriga belopp ackumulerades under en helg. Felet upptäcktes först när månadsfakturan kom. (Varianter av berättelsen återkommer så ofta att det specifika beloppet är mindre viktigt än mönstret.)

• En modelluppdatering förändrade beteendet i tysthet. Kvaliteten sjönk för en viktig funktion. Användarna klagade, men utvecklingsteamet trodde att det rörde sig om ”enstaka konstigheter”. Det tog två månader innan sambandet med modelländringen hittades.

• En ny promptversion driftsattes. Den orsakade av misstag en regression i ett viktigt användarflöde. Utan mätetal per flöde märkte ingen det på flera veckor.

• Ett agentsystem började loopa. Vissa användarsessioner gjorde fler än 200 LLM-anrop. Det tog flera timmars utredning att hitta loopen eftersom det saknades instrumentering på spårnivå.

• Ett autentiseringsfel i ett verktyg ledde vidare till förvirring hos agenten. Agenten fortsatte att ”prova olika saker” och drog på sig kostnader. Utan aviseringar pågick det i timmar.

• En promptinjektion fick AI:n att läcka systeminstruktioner. Personuppgifter röjdes. Utan observerbarhet kunde teamet inte enkelt identifiera vilka användare som hade drabbats.

Det här är inte teori. Det händer. Observerbarhet förebygger det mesta eller upptäcker problemen snabbt.

Instrumentera före incidenten

LLM-observerbarhet är en egen disciplin. Traditionell APM är nödvändig men otillräcklig. De särskilda lagren – anropsnivå, spårnivå, kvalitet, kostnad, latens, fel och felsökning – behövs alla.

Verktygen finns. Välj ett. Integrera tidigt. Investera i instrumentpanelerna, aviseringarna och processerna som upptäcker problem före användarna.

Team som gör detta:

• Upptäcker fel inom timmar i stället för veckor.
• Hanterar kostnader förutsägbart i stället för att få överraskande fakturor.
• Upprätthåller kvaliteten över tid i stället för att låta den driva.
• Felsöker systematiskt i stället för att gissa.

Team som inte gör det råkar till slut ut för en incident som tvingar dem. Bättre att instrumentera före incidenten än efter.