AI glossary · Basic · MLOps & LLMOps · Agents
LLM observability
LLM observability means recording and being able to inspect what an LLM-based service actually received as input, which steps it went through, and what it answered. It is used to find the cause when something goes wrong and to manage quality and cost.
About this term
- Level
- Basic · Technical terms you often meet in AI news
- Category
- Data, ops & platforms
- Fields
- MLOps & LLMOps, Agents
- Added
- 2026-10-08
How it works
A single user request goes through steps such as prompt assembly, document retrieval, LLM calls, tool use and the final answer. Observability tools group these steps into one flow (a trace) and record each step's input, output, elapsed time and number of tokens used. Looking at the collected records on a dashboard, you find slow steps, expensive requests and points where errors occurred. Feedback such as users' likes and dislikes, and automated evaluation scores, are attached as well.
What to log for each request
Flow
- Which steps it went through
- Input and output of each step
- Where errors occurred
Performance · cost
- Time taken per step
- Number of tokens used
Quality
- User feedback
- Automated evaluation scores
Why it matters
LLMs give slightly different answers to the same question and sometimes produce plausible but wrong answers (hallucinations). Unlike ordinary programs that stop when an error occurs, they present wrong answers naturally, so problems are hard to notice without looking at the logs. For systems like agents that take multiple steps on their own, tracing where they went off track matters even more. Watching token usage also helps you catch sudden cost increases early.
Things to know
Conversation logs can contain personal information or company secrets, so they need management, such as masking before storage or setting retention periods. Accumulating logs alone does not improve quality; it works best when collected failure cases are turned into Evals (evaluation sets) and checked every time the prompt or model changes. Automatically scoring answer quality with LLM-as-a-Judge and logging it alongside is also common. A common form is traditional service monitoring tools with LLM-specific features added.
Example
When a complaint comes in that an internal document search chatbot's 'answers are off,' the person in charge opens that conversation's trace in the observability tool. The step-by-step records show whether the retrieval step pulled the wrong documents, or whether the documents were right but the LLM summarized them incorrectly. If retrieval is the cause, they adjust chunking or the reranker, then add this case to the evaluation set to check that the same mistake does not recur with the next change.