AI-observability

Wat is AI-observability?

AI-observability is de praktijk van AI-systemen instrumenteren in productie, waarbij traces, prompts, tool-aanroepen, tokenkosten, latentie, en kwaliteitssignalen worden vastgelegd, zodat teams kunnen zien wat een model of agent daadwerkelijk deed en waarom. Het breidt traditionele observability uit naar systemen wier gedrag probabilistisch is en wier mislukkingen zelden een exception gooien. De industrie heeft het argument grotendeels geaccepteerd: bijna 89 procent van de organisaties die agents bouwen, heeft er observability voor geïmplementeerd, volgens LangChains onderzoek van eind 2025 onder meer dan 1.300 professionals [1].

De belangrijkste punten

• AI-systemen falen stilletjes. Een fout antwoord geeft HTTP 200 terug, dus zeggen foutpercentage- en uptime-dashboards dat alles goed is terwijl kwaliteit verbrandt.
• De kerneenheid is het trace: één gebruikersverzoek uitgebreid naar elke modelaanroep, prompt, retrieval, tool-aanroep, en tussenliggende beslissing onderweg, met kosten en latentie per stap.
• Observability sluit de lus met evaluatie. Productietraces onthullen echte mislukkingen, mislukkingen worden evalcases, en evals bewaken dan tegen hun terugkeer.
• Kosten zijn een eersteklas signaal. Tokenbesteding per verzoek varieert met ordes van grootte, en een misdragende agentlus kan je rekening stilletjes vermenigvuldigen.
• Standaardisatie is aangekomen: OpenTelemetry-conventies voor generatieve AI betekenen dat traces naar dezelfde backends kunnen stromen als de rest van je telemetrie.

Hoe het werkt

De basis is tracing. Elk verzoek door een AI-feature zendt een gestructureerd trace uit: de inkomende input, de exacte gerenderde prompt (wat ertoe doet omdat templates plus opgehaalde context iets heel anders kunnen produceren dan wat de developer zich voorstelde), elke modelaanroep met zijn parameters en tokenaantallen, elke tool-aanroep die een agent deed met argumenten en resultaten, en de uiteindelijke output. Voor een simpele RAG-query is dat een handvol spans; voor een agent kan het een boom van tientallen zijn. Platforms in deze ruimte, LangSmith, Langfuse, Braintrust, Arize, en de LLM-functies van algemene observability-leveranciers, verschillen vooral in hoe goed ze je door deze bomen laten navigeren en query'en.

Bovenop traces zitten metrieken en kwaliteitssignalen. De operationele laag oogt bekend: latentiepercentielen, fout- en retry-percentages, tokenkosten per verzoek, per feature, per klant. De kwaliteitslaag is wat deze discipline onderscheidt. Omdat correctheid niet van een statuscode af te lezen is, samplen teams productieverkeer en scoren het, met LLM-as-a-judge-beoordelaars voor getrouwheid of taakvoltooiing, deterministische checks voor formaat en beleid, en gebruikerssignalen zoals thumbs-down, retries, en afhaken als zwakke labels. Alarmen gaan af bij dalingen in deze scores, niet alleen bij 500'en, en dat is hoe je model drift en regressies van providerzijdige modelupdates vangt. Deze kwaliteitslaag blijft de minder geadopteerde helft van de discipline: hetzelfde LangChain-onderzoek vond online, realtime evaluatiemonitoring draaiend bij slechts 37,3 procent van de organisaties in totaal, oplopend tot 44,8 procent onder degenen met agents al in productie [2].

Het laatste stuk is de feedbacklus naar ontwikkeling. Wanneer een dienstdoende engineer een slecht trace vindt, wordt het trace een permanente evalcase; wanneer een promptwijziging uitgeleverd wordt, kunnen zijn evalscores en productiescores op dezelfde voet vergeleken worden. Volwassen teams behandelen observability en evaluatie als één systeem met twee uiteinden: evals voorspellen gedrag voor deploy, observability verifieert het erna.

Voorbeeld

Een legal-tech-bedrijf draait een agent die contractsamenvattingen opstelt. Op een gegeven week beginnen gebruikers te klagen dat samenvattingen dun aanvoelen, terwijl elk dashboard groen toont: geen fouten, latentie normaal. Het team opent hun trace-explorer en filtert de traces van de afgelopen week op een getrouwheidsscore die hun nachtelijke judge toekent aan een steekproef van 5 procent. Scores daalden vier dagen geleden. Bij het uitdiepen van laagscorende traces zien ze dat de retrievalstap de helft van zijn gebruikelijke passageaantal teruggeeft, en de diff wijst naar een chunking-wijziging in documenten die stilletjes parsing brak voor één contractformaat, waardoor het model samenvatte vanuit gedeeltelijke context. Er werd nooit een exception gegooid; het model deed zijn best met wat het kreeg. Ze herstellen de parser, spelen de getroffen traces opnieuw af om te bevestigen dat scores herstellen, en voegen de twaalf slechtste traces toe aan hun evalsuite zodat het faalpatroon nooit meer stil kan uitleveren. Tijd van klacht tot hoofdoorzaak: onder een uur, volledig omdat de traces bestonden.

Veelvoorkomende misvattingen

De veelgemaakte fout is aannemen dat bestaande APM het dekt. Teams richten hun standaardmonitoring op de AI-service, zien gezonde latentie en nul fouten, en concluderen dat de feature werkt. Traditionele observability beantwoordt "is het up en snel"; AI-observability beantwoordt "is het juist en de kosten waard," en dat zijn verschillende instrumenten. Zonder prompt-niveau-traces en kwaliteitsscoring is het eerste teken van een verslechterd model, een gebroken retrievalstap, of een op hol geslagen agentlus, een klant-e-mail of een factuur. Als je dashboards je niet de exacte context kunnen tonen die een model zag voor een gegeven slecht antwoord, heb je monitoring, geen observability.

FAQ

Wat is het verschil tussen AI-observability en LLM-observability? Vooral scope. LLM-observability verwijst naar het instrumenteren van de modelaanroepen zelf: prompts, completions, tokens, latentie. AI-observability is de bredere paraplu die het hele systeem rond die aanroepen dekt, retrievalpipelines, agent-toolgebruik, meerstaps trajecten, en kwaliteitsscoring. In leveranciersmarketing lopen de termen door elkaar, en de trace-gecentreerde architectuur eronder is dezelfde.

Wat moet je loggen uit een AI-systeem? Op zijn minst: volledige prompts en completions (met toegepast PII-beleid), model en versie, tokenaantallen en kosten, latentie per aanroep, tool-aanroepen met argumenten en resultaten, retrieval-inputs en teruggegeven documenten, en gebruikersfeedback-events, allemaal gecorreleerd onder één trace-ID per verzoek. Het modelversieveld verdient zichzelf terug de eerste keer dat een providerupdate je gedrag verschuift en je het moet bewijzen.

Hebben kleine teams dedicated tooling hiervoor nodig? Eerder dan ze verwachten. Een single-model-feature kan beginnen met gestructureerde logs, maar zodra een agentlus of retrievalstap het systeem binnenkomt, stopt handgerolde logging met "waarom was dit antwoord fout" beantwoorden. Open-sourceopties maken de trace-explorer-capaciteit goedkoop, en OpenTelemetry GenAI-conventies betekenen dat vroege instrumentatie meegaat in plaats van weggegooid te worden.

Bronnen

1. LangChain. "State of Agent Engineering-onderzoek onder meer dan 1.300 professionals: bijna 89% van de organisaties die agents bouwen heeft observability geïmplementeerd." https://www.langchain.com/state-of-agent-engineering. Geraadpleegd augustus 2026.
2. LangChain. "State of Agent Engineering: online evaluatiemonitoring draait bij 37,3% van de organisaties in totaal en 44,8% van degenen met agents in productie." https://www.langchain.com/state-of-agent-engineering. Geraadpleegd augustus 2026.