Observerbarhed i LLM-applikationer: sporing, omkostninger, svartid og kvalitetsændringer

Applikationer baseret på store sprogmodeller (LLM’er) arver de almindelige fejltyper fra traditionel software og tilføjer probabilistisk variation i output, ændringer i modeller og prompts, værktøjsadfærd, kvaliteten af datahentningen og brugsafhængige omkostninger. Nogle fejl giver stakspor; andre viser sig kun i evaluerede output, brugerrapporter eller ændrede fordelinger.

Traditionel observerbarhed (Datadog, New Relic, Sentry) fortæller dig, at API-kaldet lykkedes på 8,4 sekunder og brugte 12.847 tokens i inputtet. Den fortæller ikke, om svaret var godt, om modellen hallucinerede, om det forkerte værktøj blev kaldt, eller om kvaliteten har ændret sig siden sidste uge.

Produktionsklare LLM-systemer har brug for yderligere semantiske data ud over almindelige spor, målinger og logfiler. Start med OpenTelemetry-konventionerne for generativ AI, og udvid kun, hvor dit produkt kræver flere detaljer. Denne artikel viser et illustrativt hændelsesformat; AIExpert har ikke offentliggjort et produktionsspor eller kontrolpanel, der dokumenterer, at alle felterne nedenfor er dækket.

Hvad er anderledes ved observerbarhed af LLM-systemer?

Nogle karakteristiske træk ved LLM-systemer, som traditionel observerbarhed ikke håndterer:

Ikke-determinisme på det enkelte kald. Det samme input giver forskelligt output fra kald til kald. Spørgsmålet »fungerede det korrekt?« kan ikke besvares ved blot at kontrollere statuskoder.

Kvalitet som den primære måling. Svartid og omkostninger er vigtige, men kvaliteten er vigtigst og samtidig sværest at måle.

Spor med flere trin. En brugerforespørgsel kan udløse flere kald til modeller, datahentning og værktøjer. Hver handling indgår i et større spor.

Brugsafhængige omkostninger. Omkostningerne varierer efter model, antal tokens, cachelagring, værktøjer og udbyderspecifikke gebyrer. Fordel den fakturerede brug på kald- eller batchniveau frem for at antage et universelt interval pr. kald.

Ændringer over tid. Modeller opdateres. Prompts udvikles. Inputfordelingen ændres. Kvaliteten ændrer sig, og du skal kunne følge udviklingen.

Følsomme nyttedata. Input og output er ofte de mest værdifulde data til fejlsøgning, men også de mest følsomme. Logning kræver disciplin.

Lange asynkrone forløb. Agentkørsler, der tager flere minutter. Batchjob i baggrunden. Svar, der streames. Traditionel observerbarhed af anmodninger og svar passer ikke her.

Dette er fejltyper, som instrumentationen bør udformes til at afdække. Hvilke af dem der dominerer, skal fastlægges ud fra din egen trafik.

Lagene i observerbarheden

Et praktisk design til LLM-observerbarhed kan omfatte disse lag, der vælges ud fra arbejdsbelastning og risiko:

1. Instrumentering på kaldniveau. Hvert LLM-kald udsender godkendt driftsmetadata såsom svartid, faktureret forbrug, model/revisionsnummer og status. Rå input eller output optages kun, når det er særskilt berettiget og kontrolleret.

2. Instrumentering på sporniveau. Arbejdsgange med flere kald samles i spor. Du kan se hele kæden af kald for en brugerforespørgsel.

3. Målinger på applikationsniveau. Aggregeringer pr. funktion, bruger og lejer.

4. Kvalitetsovervågning. Stikprøvevis eller fuldt automatisk kvalitetsvurdering.

5. Registrering af brugerfeedback. Eksplicitte signaler (tommel op/ned) og implicitte signaler (generering på ny, opgivelse).

6. Alarmer. Realtidsalarmer ved omkostningsspring, forringet svartid, kvalitetsfald og stigende fejlrater.

7. Fejlsøgningsværktøjer. Når noget går galt, kan autoriserede beredskabsansvarlige undersøge det mindste godkendte datagrundlag, der er nødvendigt for at forstå problemet; rå input og output gemmes ikke nødvendigvis eller er ikke tilgængelige overalt.

Vi gennemgår hvert lag.

Instrumentering på kaldniveau

Hvert LLM-kald bør oprette en godkendt metadatapost. De kommenterede felter med nyttedata og identitetsoplysninger nedenfor er valgfrie følsomme felter, ikke standardfelter:

{
  "call_id": "uuid",
  "timestamp": "2026-08-04T14:23:45Z",
  "trace_id": "uuid",  // til gruppering i spor
  "span_id": "uuid",   // til overordnede-underordnede relationer
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "provider-model-revision",
  "provider": "anthropic",
  "input_messages": null,  // valgfrit; kun godkendte stikprøver med maskerede nyttedata
  "output_message": null,  // valgfrit; kun godkendte stikprøver med maskerede nyttedata
  "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,
  "subject_ref": "pseudonymous_ref",  // valgfrit, formålsspecifikt opslag
  "tenant_ref": "tenant_scoped_ref",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Dette er en illustrativ applikationshændelse, ikke et obligatorisk skema. Registrér kun det minimum, der er nødvendigt til et bestemt driftsformål. Rå prompts og output er følsomme nyttedata, som aktivt skal tilvælges, ikke almindelig telemetri.

Vigtige implementeringsvalg:

Hvor skal du logge. Muligheder:

• Et dedikeret observerbarhedsværktøj (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• En generel observerbarhedsplatform med LLM-udvidelser (Datadog LLM Observability, Sentry).
• Dine egne logfiler eller din egen database.

Vælg ud fra kravene til OpenTelemetry-eksport, visualisering af spor og værktøjskald, dataplacering, selvhosting, maskering, adgangskontrol, API’er til opbevaring og sletning, vedligeholdelse af modelpriser, evalueringsunderstøttelse og samlede omkostninger. Et dedikeret værktøj, en eksisterende APM-løsning eller en lille egen implementering kan alle være rigtige valg. Test eksport og sletning, før du binder dig.

Hvordan skal du instrumentere. Muligheder:

• En proxy, der ligger mellem din applikation og LLM-udbyderen (Helicones model).
• Et indpakkende SDK i din applikationskode.
• En indpakningsklasse, som du kalder manuelt ved hvert LLM-kald.

Proxyer centraliserer instrumenteringen, men tilføjer et ekstra netværkstrin og endnu et muligt fejlpunkt. Indpakning med et SDK holder instrumenteringen i processen, men kobler koden til integrationen. Manuelle indpakninger kan være præcise, men kræver test af dækningen. Mål merbelastningen og adfærden ved fejl for den valgte tilgang.

En pragmatisk tilgang er SDK-indpakning ved den grænseflade, hvor applikationen kalder LLM’en. Der er ét sted at instrumentere, og alt andet passerer igennem det.

Hvad skal du logge. Anvend dataklassificering og regler for opbevaringsperioder, før du aktiverer registrering af nyttedata. Under GDPR gælder principperne i artikel 5 om dataminimering og opbevaringsbegrænsning stadig for observerbarhedsdata.

• Foretræk promptversion, hashværdier, tokenantal, politikbeslutninger og afledte målinger frem for råt indhold.
• Hvis registrering af nyttedata er berettiget, skal du tage stikprøver, maskere dem før eksport, kryptere dem, begrænse adgangen og fastsætte en kort opbevaringsperiode.
• Bevar ikke en automatisk tilgængelig rå original, blot fordi en maskeret kopi blev logget. Det genskaber det følsomme datalager og kræver sit eget lovlige formål og egne kontroller.
• Log ikke legitimationsoplysninger, heller ikke i fejlforløb.
• Ved streaming skal du logge både tiden til første token og den samlede svartid.

Instrumentering på sporniveau

En enkelt brugerhandling omfatter ofte mange LLM-kald. Uden instrumentering på sporniveau har du tusindvis af kaldlogfiler, men ingen måde at vide, hvilke kald der hører til den samme brugerhandling.

Implementering:

Oprettelse af spor-id. Opret et entydigt spor-id ved begyndelsen af en brugerforespørgsel. Viderefør det gennem alle efterfølgende kald.

Overordnede og underordnede delspor. Inden for et spor har hvert kald et delspor-id og eventuelt et id for det overordnede delspor. Det danner et træ, der viser kaldhierarkiet.

Navngivning af handlinger. Hvert delspor har et navn (“summarize_document”, “extract_entities”, “tool_call:search”). Sporet viser hele handlingskæden.

En sporvisning i brugerfladen:

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

Nu kan du se, hvad dit system faktisk gjorde for denne brugerforespørgsel. Du kan finde langsomme kald, dyre kald og fejlede kald – i kontekst.

Mulige implementeringer omfatter dedikerede produkter til LLM-observerbarhed og generelle APM-systemer med OpenTelemetry. Kontrollér videreførelse af spor, repræsentation af værktøjskald, eksport, maskering, sletning, adgangskontrol og fejlhåndtering i en repræsentativ prøve frem for at stole på en produktliste.

Målinger på applikationsniveau

Ud over individuelle kald skal du bruge aggregerede målinger:

Pr. funktion.

• Kaldvolumen.
• Gennemsnitlig svartid.
• p50-, p95- og p99-svartid.
• Gennemsnitlige omkostninger pr. anmodning.
• Fejlrate.
• Kvalitetsscore (hvis målt).

Pr. bruger og pr. lejer.

• Kald pr. bruger pr. dag.
• Omkostninger pr. bruger.
• Storforbrugere og misbrugsmønstre.

Pr. model.

• Volumen pr. model.
• Omkostningsandel pr. model.
• Fejlrate pr. model.
• Kvalitet pr. model, hvor den måles.

Pr. funktion × pr. model.

• Hvilke funktioner bruger hvilke modeller?
• Hvor kunne vi rute til billigere modeller?

Disse kontrolpaneler understøtter driftsmæssige beslutninger: Hvilke funktioner er dyre, hvilke er langsomme, og hvilke skal optimeres?

Kvalitetsovervågning

Det sværeste lag: automatisk kvalitetsvurdering.

Ved evalueringer bruger du et defineret datasæt. Ved løbende kvalitetsovervågning vurderer du produktionstrafikken.

Tilgange:

LLM som dommer for et udsnit. Definér et udsnit ud fra trafikmængde, risikosegmenter, databeskyttelsesbegrænsninger, detektionsmål og budget. Kør en kalibreret model på egnede eksempler, bevar menneskelig bedømmelse ved tvivlsomme tilfælde eller tilfælde med store konsekvenser, og følg resultatet pr. prompt- og modelversion. Dommermodeller kan være påvirket af svarenes placering og længde samt have en tilbøjelighed til at foretrække egne svar. De leverer målinger, der skal valideres, ikke en grundsandhed.

Implicitte signaler. Følg svar, der genereres på ny, afbrudte forløb, fejlrate, tid til gennemførelse og hyppigheden af efterfølgende beskeder. Det er svage, men billige signaler. Brug dem som tidlige indikatorer.

Eksplicit brugerfeedback. Tommel op/ned, knapper med “Hjalp dette?” og eksplicitte rapporter. Højeste signalstyrke, men lavest volumen.

Mønstergenkendelse. Specifikke dårlige mønstre (“Jeg kan ikke hjælpe med det”, “Jeg er bare en AI”, gentagne afvisninger) markeres automatisk. Fanger nogle regressioner øjeblikkeligt.

Implementeringsdokumentationen bør angive reglen for stikprøver, udelukkede data, vurderingsskema, dommermodellens version, materiale til menneskelig kalibrering, usikkerhed, aggregeringsvindue, alarmtærskel og omkostningsloft. Udled ændringstærskler fra gentagne referencekørsler og alvoren af regressioner, der ikke blev opdaget; en kopieret procentsats har ingen statistisk eller forretningsmæssig betydning for en anden arbejdsbelastning.

Omkostningsobserverbarhed

Gentagne forsøg, løkker, uventet lange input eller output, ændret dirigering og prisændringer hos udbyderen kan hurtigt øge omkostningerne. Opdag hver mekanisme direkte frem for at antage en multiplikator.

Lagene for omkostningsobserverbarhed:

Omkostning pr. kald. Omkostningen for hvert kald beregnes, når det logges. Aggregeringerne er straks tilgængelige.

Budgetadvarsler. Daglige, ugentlige eller månedlige budgetter pr. funktion og lejer med advarsels- og håndhævelsestærskler valgt ud fra prognosens usikkerhed og forretningskritikalitet.

Registrering af afvigelser. Sammenlign omkostninger og brug med det korrekte referencegrundlag for trafikfordelingen, og sæt særskilte grænser for ukontrollerede løkker i en enkelt kørsel, tokens, værktøjer, gentagne forsøg, varighed og udgifter.

Fordeling af omkostninger. Fordel omkostningerne pr. funktion, lejer og bruger. Find de største omkostningskilder.

Prognose. Hvad bliver regningen ved månedens slutning ud fra den nuværende udvikling?

En nyttig kontrolpanelvisning er et enkelt panel, der sammenligner dagens omkostninger med resten af denne uge og sidste uge, opdelt pr. funktion.

Sæt budgetgrænser ud fra målt trafik og forretningskritikalitet. Foretræk trinvis styring: advarsel, hastighedsbegrænsning, nedprioritering af en ikke-kritisk sti og derefter afbrydelse. En universel regel om “sluk ved 10×” kan reagere alt for sent eller standse en afgørende arbejdsgang.

Observerbarhed af svartid

LLM-svartid er mere nuanceret end svartiden for typiske API’er:

Samlet svartid. Fra anmodning til endeligt svar.

Tid til første token (TTFT). Ved streaming: Hvornår ser du det første tegn? Dette har stor betydning for den oplevede svartid i en chatbrugerflade.

Tid til sidste token (TTLT). Hvor lang tid går der, før svaret er fuldført?

Tokens pr. sekund. Outputhastighed. Nogle modeller streamer langsommere end andre.

Svartid for værktøjskald. For agentarbejdsgange: tid brugt på værktøjskald sammenlignet med LLM-kald.

Følg dem alle. Forskellige optimeringsstrategier retter sig mod forskellige målinger.

For brugervendte chatløsninger er TTFT en vigtig interaktionsmåling; samlet gennemførelsestid, outputhastighed, afbrydelser, opgavesucces og tilgængelighed betyder også noget. Sæt mål ud fra observeret brugeradfærd frem for at antage, at én måling for svartid dominerer i enhver brugerflade.

For batchkørsler betyder den samlede svartid noget; gennemløbet betyder mere.

For agenter dominerer svartiden for værktøjskald ofte; optimering af LLM’en hjælper ikke, hvis værktøjerne er langsomme.

Observerbarhed af fejl

LLM-specifikke fejl:

API-fejl. Hastighedsbegrænsninger, godkendelsesfejl og serverfejl. Det er de samme fejl som for ethvert andet API.

Valideringsfejl. Det strukturerede output overholdt ikke skemaet. Følg hyppigheden pr. funktion.

Fejl fra indholdsfilter. Udbyderen blokerede anmodningen. Følg disse fejl for at opdage problemer med prompts.

Værktøjsfejl. Bestemte værktøjer fejler. Følg fejlene pr. værktøj.

Kvalitetsfejl. En LLM-dommer har vurderet outputtet som dårligt. Følg udviklingen over tid.

Signaler om hallucinationer. Registrering af sandsynlige hallucinationer, hvor modellen påstår noget, der ikke findes i kilden. Det er svært at registrere automatisk, men kan estimeres.

Omkostningsfejl. Kald, der kostede meget mere end forventet. De tyder ofte på en programfejl.

Hver type får sit eget kontrolpanel og kan udløse alarmer.

Fejlfindingsværktøjer

Når noget går galt, skal du finde fejlen og forstå den. Fejlfindingsfladen omfatter:

Søgning i spor. Find en hændelse ved hjælp af spor-id, en godkendt pseudonymiseret reference til den berørte person eller et tidsstempel uden at eksponere andre data fra lejeren.

Inspektion af kald. Vis metadata som standard. Vis kun godkendte og minimerede felter fra anmodninger og svar efter rollekontrol og under logning af adgang, formålsbegrænsning og opbevaringsregler; mange udrulninger bør aldrig gemme alle nyttedata.

Tidslinje for spor. Ved komplekse forløb kan du se kaldkæden visuelt.

Kontrolleret genafspilning. Kan et godkendt og minimeret input køres igen i et isoleret miljø, hvor værktøjerne er deaktiveret eller afskærmet? Genafspil aldrig produktionskald mod aktive systemer med bivirkninger, og antag ikke, at gemte nyttedata er berettigede, blot fordi genafspilning er nyttig.

Sammenligningsvisning. Sammenlign to kald – forskellige versioner af samme prompt eller forskellige modeller – side om side.

Søgning efter godkendt indhold eller afledte felter. Søg efter definerede mønstre uden at omdanne telemetrisystemet til en uberettiget samling af kundeprompts. Autorisation, minimering, indeksering, opbevaring og logning af adgang gælder både ved søgning og lagring.

Produkter adskiller sig væsentligt i disse funktioner. Verificér dem i en repræsentativ prøve, og medtag integration, lagring, databeskyttelsesgennemgang, migration og driftsarbejde i sammenligningen. Listeprisen alene beviser ikke, at køb er billigere.

Databeskyttelse og personoplysninger

Logfiler til LLM-observerbarhed er følsomme. Input kan indeholde personoplysninger, og output kan gengive dem. Registrering af rå nyttedata foreslås undertiden til fejlsøgning, men er ikke automatisk nødvendig eller lovlig. Definér formålet, og overvej først syntetisk reproduktion, afledte felter eller kortvarige kontrollerede prøver.

Tiltag:

Pseudonymisering og tokenisering. Erstat direkte identifikatorer med formålsspecifikke tokens, og beskyt ethvert opslag til genidentifikation særskilt. Hvis genidentifikation fortsat er mulig, er posterne stadig personoplysninger og ikke anonyme data.

Maskering ved logning. Opdag og maskér personoplysninger, før de lagres i observerbarhedssystemet. Bestemte mønstre som e-mailadresser, telefonnumre og amerikanske personnumre erstattes med pladsholdere.

Isolation mellem lejere. Observerbarhedsdata i et system med flere lejere isoleres pr. lejer. Én lejers data er ikke synlige for en anden.

Adgangskontroller. Hvem kan se rå input og output? Adgangen logges.

Regler for opbevaring. Logfiler, der er ældre end X dage, slettes eller flyttes til kold lagring. Opbevaring af personoplysninger er juridisk begrænset i mange jurisdiktioner.

Arbejdsgang for sletning og begrænsning. Gør telemetriposter søgbare via de identifikatorer, der er godkendt til formålet, og gennemfør den handling, som den juridiske rådgiver fastlægger, i det primære lager, indeks, eksportfiler og sikkerhedskopier. Omsæt ikke det uformelle udtryk »retten til at blive glemt« til et ubetinget løfte. Sletning efter GDPR har betingelser og undtagelser.

Systemets kontroller skal stå i et rimeligt forhold til personoplysningerne og formålet. Den nøjagtige kombination varierer, men isolation mellem lejere, autoriseret adgang, minimering, opbevaring, håndtering af sletning og begrænsning samt revisionsmuligheder skal være besluttet, før telemetri med nyttedata aktiveres. Europa-Kommissionen opsummerer betingelserne og undtagelserne for anmodninger om sletning.

Alarmering

Tærskler og signaler, der berettiger til alarmer:

Omkostninger.

• Forbrug eller prognose overstiger funktionens målte budgetramme.
• Omkostning pr. anmodning overstiger en øvre grænse, der er fastlagt for arbejdsbelastningen.
• Ændringshastigheden overstiger referenceintervallet for den samme trafikfordeling.

Svartid.

• Svartiden for de langsomste anmodninger overskrider produktets målte servicemål.
• Tiden til første token eller til et færdigt svar overskrider det mål, der er fastlagt for interaktionen.
• Tidsudløb for værktøjer eller køtid afviger fra referenceintervallet.

Fejlrate.

• Fejlraten overskrider arbejdsbelastningens fejlbudget.
• En bestemt fejltype afviger fra sit referenceinterval, herunder valideringsfejl og hastighedsbegrænsninger.

Kvalitet.

• En kalibreret måling ændrer sig mere end variationen mellem gentagne kørsler, eller et sikkerhedskritisk udsnit registrerer et ikke-tilladt resultat.
• Andelen af negativ brugerfeedback overstiger referenceværdien.
• Andelen af svar, der genereres på ny, overstiger referenceværdien.

Mønster.

• Bestemte uønskede formuleringer forekommer oftere.
• Pludselig ændring i inputfordelingen.

Hver alarm skal identificere funktion, tidsvindue, observeret og forventet værdi, berørt udsnit, links til spor og driftsvejledning. Beskriv ikke en ukontrolleret kørsel som årsagen i alarmteksten, medmindre telemetri om løkker eller gentagne forsøg understøtter diagnosen.

Systemer med flere lejere

For B2B SaaS-applikationer:

Målinger pr. kunde. Hver kunde kan se sin egen brug, omkostninger og kvalitet.

Advarsler pr. kunde. Tilpasset deres tærskelværdier.

Fejlsøgning pr. kunde. Supporten kan se en kundes spor med passende adgangskontrol.

Konfiguration pr. kunde. Nogle kunder har forskellige modeller, prompts eller politikker. Observerbarhedslaget afspejler dette.

I systemer med flere lejere kan tilknytning og isolation af lejere være nødvendig for support og fakturering, men ubegrænset adgang til spor er ikke automatisk berettiget. Giv supporten den mindst mulige datamængde og de færrest mulige rettigheder, log adgangen, og sørg for en eskaleringsvej for følsomme nyttedata.

Værktøjsøkosystem (2026)

Et overblik over værktøjer til LLM-observerbarhed på nuværende tidspunkt:

Dedikerede værktøjer til LLM-observerbarhed:

• Helicone, LangSmith, Phoenix (Arize), Braintrust, PromptLayer og Weights & Biases Weave er kandidater, der kan verificeres mod kravene ovenfor.

Generel APM med LLM-udvidelser:

• Datadog LLM Observability og New Relic AI Monitoring er kandidater, hvis organisationen allerede bruger disse platforme.
• OpenTelemetry + din foretrukne APM. OTel har semantiske konventioner for generativ AI; instrumentér én gang, og vis dataene i flere værktøjer.

Byg selv:

• En lille database kan være tilstrækkelig for et afgrænset system, når det implementerer de krævede kontrolmekanismer for isolation, adgang, opbevaring, sletning og indeksering.
• Tilføj en enkel brugerflade til søgning og visning.
• Integrér med din eksisterende infrastruktur til logning.

Dokumentér valget, de forkastede alternativer, gennemgangen af dataflowet, testen af eksport og leverandørskifte samt datoen for genevaluering. Der findes ingen standardmigrationsvej, der passer til alle teams.

En praktisk opsætning

Fastlæg rækkefølgen efter afhængigheder og risiko frem for en generel kalender:

Fase 1: Vælg en kandidat ud fra kravene, og kør den på syntetiske, ikke-følsomme spor. Kontrollér eksport, adgang, maskering, dataopbevaring, sletning, fejlhåndtering og muligheder for leverandørskifte – ikke kun indlæsning.

Fase 2: Tilføj kontrolpaneler for de definerede servicemål, herunder omkostninger pr. funktion, fordelinger af svartid, fejlklasser, model- og promptversioner samt andelen af manglende telemetri.

Fase 3: Opsæt alarmer, der er afledt af arbejdsbelastningen, for omkostninger, løkker, svartid og fejlklasser.

Fase 4: Forbind delspor på tværs af forløb med flere kald, og kontrollér, at sporene videreføres gennem værktøjer og køer.

Fase 5: Indfør godkendte stikprøver af kvaliteten, og kalibrér automatiske scorer mod menneskelige vurderinger.

Fase 6: Tilføj kun brugerfeedback, når fortolkning, databeskyttelse og arbejdsgangen for svar er defineret.

Fase 7: Tilføj lejerspecifikke visninger og fejlfindingsfunktioner med autorisation og revision af adgangen.

Godkendelsesdokumentationen for hver fase skal omfatte test, dataklassifikationer, ejere, adfærd ved fejl og tilbagerulning. Spring kun en funktion over med en udtrykkelig begrundelse og en kompenserende kontrolforanstaltning.

Hvad går galt uden det

Et kort katalog over hændelsesmønstre, der gentager sig hos teams uden ordentlig LLM-observerbarhed:

• En funktion gentager kald i en tæt løkke og ophober uventede omkostninger før den næste fakturagennemgang.

• En modelopdatering ændrer adfærden, men anmodningerne registrerer ikke modelversionen, hvilket forsinker arbejdet med at finde årsagen.

• En promptversion forringer et vigtigt forløb, men spor fra udrulning og svar kan ikke sammenlignes pr. version.

• En agent går i løkke, men manglende budgetter pr. trin og instrumentering på sporniveau skjuler den gentagne tilstand.

• En godkendelsesfejl i et værktøj udløser gentagne forsøg, men telemetrien om fejlklasse og gentagelser er ikke forbundet.

• En vej for promptinjektion medfører en usikker videregivelse, men manglende telemetri om dataenes oprindelse og regelbeslutninger forhindrer en vurdering af konsekvenserne.

Det er fejlsituationer, der skal testes. Observerbarhed skaber dokumentation til opdagelse og undersøgelse; den forhindrer ikke det underliggende svigt, medmindre håndhævelsesmekanismer reagerer på signalerne.

Instrumentér før hændelsen

Observerbarhed af LLM’er udvider frem for at erstatte almindelig APM. Vælg de signaler om kald, spor, kvalitet, omkostninger, svartid, fejl og fejlsøgning, der er berettigede ud fra arbejdsbelastningen og trusselsmodellen, og forbind dem med afprøvede reaktionsmekanismer.

En påstand om produktionsklarhed bør i stedet dokumentere registreringstid pr. scenarie, sporenes fuldstændighed, alarmers præcision og genfinding, hvor det kan måles, budgetstyringens adfærd, databeskyttelsestest samt gendannelse eller tilbagerulning. Instrumentér før lanceringen, øv driftsvejledningerne, og offentliggør kun resultater, du faktisk har målt.