What is LLM observability?
A customer forwards an answer your assistant gave in March and asks how it reached that. Without this, the honest reply is that nobody can tell.
LLM observability
AI observabilityLLM tracing
LLM observability is the practice of recording what an AI feature saw and said on every request: the input, the documents it pulled, the tools it called and the reply. The point is to rebuild any single answer later. A language model can fail without raising an error, so nothing else catches it.
Ordinary monitoring watches whether a service responded and how fast. Both stay healthy while a model returns confident nonsense, so the dashboard reports a system in perfect health.
A useful trace holds more than the reply. Keep the prompt version, the passages pulled, the model name, and the tools it called. Add what the user did next. Token counts ride along, which is how anyone answers where the bill came from.
You cannot fix what you cannot replay
Every AI feature will one day give an answer somebody disputes. The question that follows is always the same. What did the system see when it said that? A team with no traces is left guessing, then changing the prompt and hoping.
Drift is the second reason. Model vendors ship new versions, your documents change, and users start asking things nobody planned for. None of that fires an alert. It shows up as a slow decline, and only logged history makes it visible.
Regulated buyers ask for it by name. Show them that every decision was recorded with its prompt version, and you have answered a question no process description ever will.
- 01Store the prompt version beside every output, or you cannot reproduce last quarter's behaviour.
- 02Capture retrieval results, not only the final answer. Most wrong answers start there.
- 03Record when a human overrode the system. That log is the eval set you wish you had built.
- InputThe request, and who sent it.
- RetrievedPassages, with their sources.
- PromptVersion, pinned to the code.
- OutputReply, model and token count.
- OutcomeAccepted, edited or escalated.
The last station is the one teams skip, and it is the only one that tells you whether the answer was any good.
Common questions
01How is this different from normal application monitoring?
Normal monitoring asks whether the service worked. This asks whether the answer was right. A model returns 200 OK while giving a wrong reply, so latency graphs and error rates stay clean through the exact failure you care about. Run both. Neither replaces the other.
02What should we log first, if we log one thing?
The passages it pulled, paired with the final answer. That one pairing tells you whether search failed or thinking failed, which is the first fork in almost every hunt. Add the prompt version next.
03Do traces contain personal data?
Usually yes, which surprises teams. A support question includes whatever the customer typed, and a retrieved passage may contain records from your own systems. Treat the trace store with the same rules as the database it drew from, and set a retention period before you turn logging on.
04Does observability replace evals?
No. Observability tells you what happened in production; evals tell you whether a change is safe before it ships. They feed each other, because the failures you find in traces become the test cases that stop the same mistake twice.
AI running where somebody checks the answer
Related
- AI evals →Turning logged failures into a gate on releases.
- production-grade AI →Where this sits in the wider standard.
- dataset shift →A quiet decline these traces are there to catch.
- how do you know if an AI agent is production ready →The checklist buyers should be asking for.
- from prototype to production →What the demo still needs before it runs unattended.
