Monitor model performance, drift, safety events, and grounding quality
AI-103 › Unit 1: Plan and manage an Azure AI solution › Manage, monitor, and secure AI systems › Monitor model performance, drift, safety events, and grounding quality
Monitor model performance, drift, safety events, and grounding quality
A generative system can degrade for months without a single alert firing, because the things that break are not the things ordinary monitoring measures. This lesson is about closing that gap: what tracing, monitoring, and evaluation each see, and which one answers "are the answers still good?"
Why This Matters
The central problem is that operational health and answer quality are independent.
A degraded answer is still an HTTP 200, delivered in the usual time, with normal token counts. Latency is flat, error rates are flat, throughput is flat — and the system is wrong. Any monitoring practice built only on operational metrics will report a healthy service indefinitely.
The second problem is attribution. Even once you are scoring answers, a falling score has two possible causes: the system changed, or the questions changed. Distinguishing them requires holding one of the two constant, which is a design decision made when you choose what to evaluate against.
The third is that the failure surface is unusually wide. Quality, safety, and grounding are separate properties that fail independently — an answer can be perfectly grounded and unsafe, or safe and ungrounded, or both and still not address the question.
Prerequisites
- That Foundry observability integrates with Azure Monitor Application Insights.
- Basic evaluator concepts: an evaluator scores a response against something.
- That RAG answers depend on a retrieval step and a generation step.
- Familiarity with distributed tracing as a concept.
Learning Objectives
By the end of this lesson you will be able to:
- Distinguish tracing, monitoring, and evaluation and say what each answers.
- Choose between scheduled and continuous evaluation to detect drift.
- Select the right evaluator for a quality, grounding, or safety question.
- Configure alerts on quality and safety thresholds.
- Run the alert → evaluate → cluster → trace investigation path.
Building Blocks
The three core capabilities. Foundry provides "three core capabilities that work together": Evaluation ("Evaluators measure the quality, safety, and reliability of AI responses"), Monitoring ("real-time dashboards tracking operational metrics, token consumption, latency, error rates, and quality scores"), and Tracing ("captures the execution flow… providing visibility into LLM calls, tool invocations, agent decisions, and inter-service dependencies"), built on OpenTelemetry and integrated with Application Insights.
Post-production practices. "Operational metrics: Regular measurement of key AI agent operational metrics. Continuous evaluation: Quality and safety evaluation of production traffic at a sampled rate. Scheduled evaluation: Scheduled quality and safety evaluation using test datasets to detect system drift. Scheduled red teaming: Scheduled adversarial testing to probe for safety and security vulnerabilities. Azure Monitor alerts: Notifications when outputs fail quality thresholds or produce harmful content."
Quality evaluators. General purpose — Coherence ("logical consistency and flow") and Fluency ("natural language quality and readability"). RAG — Retrieval ("how effectively the system retrieves relevant information"), Groundedness ("how grounded the response is in the retrieved context… a score from 1–5 using a model-based judgment"), Groundedness Pro (preview; "using the Azure AI Content Safety service… a binary pass/fail without requiring a model deployment"), Relevance ("how relevant the response is with respect to the query"), Document Retrieval ("accuracy in retrieval results given ground truth"), and Response Completeness (preview).
Safety evaluators. Hate and Unfairness, Sexual, Violence, Self-Harm, Protected Materials, Indirect Attack (XPIA) ("whether the response fell for an indirect jailbreak attempt injected through retrieved context"), Code Vulnerability, Ungrounded Attributes, Prohibited Actions, Sensitive Data Leakage.
Evaluation levels. turn (default, "evaluates individual agent responses") and conversation ("evaluates entire multi-turn conversations"). The constraint: "All evaluators in a run must support the specified evaluation_level. You can't mix evaluators with incompatible levels in the same evaluation run."
Cluster analysis. The documented answer to "How can I improve?" is "Analyze evaluation failures with cluster analysis. Optimize agents and re-evaluate."
What each capability answers
| Attribute | ||
|---|---|---|
| Tracing | What happened on one request — calls, tools, decisions | Whether the answer was any good |
| Monitoring | System health — latency, tokens, error rates | Answer correctness entirely |
| Evaluation | Answer quality, safety, grounding | Per-request execution detail |
Deep Dive
Drift: hold something constant
Both post-production evaluation modes score production quality, and only one can prove drift.
Scheduled evaluation runs against fixed test datasets. Because the input is held constant, a change in score is attributable to the system — that is precisely why it is documented as the mode that detects drift.
Continuous evaluation scores production traffic at a sampled rate. It tells you what real users are actually receiving, which is valuable and different. But its score moves when the traffic mix moves, so a decline might be the system or might be a change in what people are asking.
The mature answer is to run both: scheduled evaluation proves the system changed, continuous evaluation proves it matters to real users. A stem that says "independently of what this week's questions happen to be" is asking for the first; one that says "what users are actually getting" is asking for the second.
Choosing an evaluation mode
Fixed input?
Scheduled evaluation against test datasets — proves drift.
Choosing an evaluator
The reliable method is to ask which two things are being compared.
- Retrieval — the query against the retrieved material. Did search find the right documents?
- Groundedness — the answer against the retrieved material. Did the model stay inside it?
- Relevance — the answer against the query. Did it address what was asked?
- Coherence / Fluency — the answer against itself. Does it hold together and read well?
That framing prevents the most common error, which is answering every RAG quality question with Groundedness. Retrieval and Groundedness fail in opposite directions: retrieval can be excellent while the model ignores what came back, and groundedness can pass while the model faithfully summarizes the wrong documents. Neither detects the other, which is why the recommended RAG combination is "Retrieval + Groundedness + Relevance + Content Safety."
Two practical variants matter. Groundedness Pro uses the Content Safety service and returns a binary pass/fail without requiring a model deployment — useful as a release gate, or in an environment where you cannot deploy a judge model. Document Retrieval is sharper than Retrieval but requires ground truth, so it costs labelled expectations to maintain.
Safety events
Safety is measured, not assumed. The risk-and-safety evaluators cover the four harm categories plus several failure modes specific to generative systems: Protected Materials for copyrighted content, Indirect Attack (XPIA) for whether the response fell for an injection arriving through retrieved context, Code Vulnerability, Ungrounded Attributes for fabricated inferences about people, and for agents Prohibited Actions and Sensitive Data Leakage.
The guidance on scope is unqualified: "All applications: Add risk and safety evaluators (Hate and Unfairness, Sexual, Violence, Self-Harm) for responsible AI practices." An internal tool is not exempt.
Separately, scheduled red teaming probes for weaknesses adversarially rather than scoring ordinary traffic — a different question from "are our answers safe today", and one that a purely observational practice never asks.
Alerts, and what they can watch
Azure Monitor alerts are the push channel: "Notifications when outputs fail quality thresholds or produce harmful content." That is worth stating plainly because the instinct is to assume alerts cover infrastructure only. Quality and safety thresholds are first-class alert conditions.
Everything else in this lesson is pull: dashboards you visit, traces you open, evaluations you schedule. A monitoring design with no alerting relies on somebody looking.
From alert to cause
Once an alert fires, the investigation has a documented shape, and it is not "read the traces".
Start from evaluation results — how much is wrong, on which metric. Then apply cluster analysis to group failures into recurring patterns; this is what converts thousands of individually unreadable failures into a handful of causes. Only then open traces, and open them for a representative case from each cluster, so the requests you read are chosen rather than sampled by luck. Fix, then re-evaluate to confirm the score moved.
Reading traces first is the natural instinct and scales badly: an alert window can contain thousands of requests, and arrival order finds the common cause last as often as first.
Worked Examples
Example 1 — six months, no measurement. A deployed assistant passed every gate at release. Operational dashboards have been flat and healthy since. A reviewer insists quality has slipped.
Run scheduled evaluation against a fixed test dataset. The flat dashboards are consistent with degradation, because they measure the system rather than the answers. Continuous evaluation would tell you what users receive but could not separate a system change from a change in the questions.
Example 2 — an alert on 4,000 traces. A quality alert fires; the team has 4,000 scored traces and cannot read them individually.
Evaluation results → cluster analysis → traces for representative cases → fix → re-evaluate. Reading every trace does not scale; raising the threshold silences the signal and leaves the system degraded and unmonitored; local reproduction assumes you already know which input fails.
Example 3 — RAG answers that cite the wrong clause. Answers are fluent, coherent, and faithful to the documents retrieved — but the documents are wrong.
Retrieval is the evaluator that isolates it. Groundedness passes precisely because the model was faithful to what it was given, which is why the two must be run together rather than treated as interchangeable.
Visual Explanations
Three capabilities, three questions:
Which two things an evaluator compares:
Common Mistakes
Treating operational health as a quality signal. They are independent.
Using continuous evaluation to prove drift. Sampled traffic moves with the users; drift needs a fixed dataset.
Answering every RAG question with Groundedness. It passes when the model faithfully summarizes wrongly retrieved material.
Mixing evaluation levels in one run. All evaluators in a run must support the specified level.
Skipping safety evaluators on internal tools. The guidance says all applications.
Opening traces before clustering. Thousands of failures in arrival order is not an investigation.
Assuming alerts cannot watch quality. They fire on quality thresholds and harmful content.
Reading a missing span layer as a platform limit. Tracing captures tool invocations and agent decisions; a missing layer is an instrumentation gap.
Practice Exercises
- Dashboards are flat and healthy; a reviewer says quality has slipped. What do you run, and why is the dashboard evidence not contradictory?
- Distinguish Retrieval from Groundedness with a failure each detects and the other misses.
- Which evaluator gives a binary pass/fail without a judge model deployment, and when is that useful?
- A quality alert fires over 4,000 traces. Give the investigation order.
- Traces arrive but stop at the model call. What is the likely cause?
▶Answers
- Scheduled evaluation against fixed test datasets, which detects system drift. Operational metrics measure the system, not the answers — a degraded answer is still a fast HTTP 200.
- Retrieval detects search returning the wrong documents (Groundedness may still pass, because the model was faithful to them). Groundedness detects the model departing from correctly retrieved material (Retrieval would look fine).
- Groundedness Pro — uses the Azure AI Content Safety service, returns binary pass/fail without requiring a model deployment. Useful as a pipeline gate and where a judge model cannot be deployed.
- Evaluation results → cluster analysis → traces for a representative case per cluster → fix → re-evaluate.
- The framework tracing integration is not enabled. Tracing is documented to capture LLM calls, tool invocations, and agent decisions, so a missing layer inside otherwise healthy traces is an instrumentation gap, not a platform limit.
Summary & Concept Map
Monitoring a generative system means accepting that operational health says nothing about answer quality. Tracing shows one request in full; monitoring shows aggregate health and pushes alerts on quality and safety thresholds; evaluation is the only thing that scores the answers. To detect drift you must hold the input constant, which is scheduled evaluation against fixed datasets — continuous evaluation on sampled traffic tells you what users receive but cannot separate system change from question change. Choose evaluators by asking which two things are compared, run Retrieval and Groundedness together because they fail in opposite directions, and investigate by clustering failures into patterns before opening any traces.
Sources and freshness
Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.