LLM Evaluation in Microsoft Foundry: Lessons from an Imaging Workflow

Why imaging changes the evaluation problem

An imaging-grounded assistant is a pipeline, not a single model call. An input may pass through image or document extraction, metadata normalization, retrieval, model reasoning, and one or more business-system tools before a user sees an answer.

A fluent final response can hide an upstream failure. The system might read the wrong field, retrieve an adjacent record, omit a critical qualifier, or call the correct tool with the wrong input. Evaluation has to isolate those stages so a team can identify what actually improved or regressed.

Build a representative task set before tuning

Start with real workflow shapes using approved, privacy-safe examples. The goal is not a giant benchmark; it is a small, reviewed set that represents the ambiguity, quality variation, and exceptions the production system will encounter.

• Include clear, borderline, incomplete, low-quality, and out-of-scope inputs.
• Record the expected facts, acceptable answer range, required evidence, and correct abstention behavior.
• Label failure types such as extraction error, retrieval miss, unsupported claim, incorrect tool input, and workflow-policy violation.
• Keep a protected holdout set so prompt or model changes are not tuned directly against every example.

Evaluate the pipeline, not only the prose

Microsoft Foundry supports quality, safety, RAG, and agent-oriented evaluators, while Azure Document Intelligence provides structured extraction for text, layout, fields, and document types. Use those capabilities as separate checkpoints rather than collapsing everything into one subjective score.

• Extraction: field accuracy, normalization, confidence, and review-queue precision.
• Retrieval: source recall, relevance, permissions, citation coverage, and freshness.
• Generation: groundedness, completeness, clarity, and correct uncertainty language.
• Agent behavior: task completion, tool selection, tool-input accuracy, and escalation.
• Operations: latency, error rate, token or inference cost, and failure recovery.

Use evaluation and tracing together

Aggregate scores tell you whether quality moved. Traces tell you why. Foundry tracing is based on OpenTelemetry and can capture model calls, tool invocations, intermediate steps, timing, and errors in connected telemetry systems such as Azure Monitor Application Insights.

For sensitive imaging or document workflows, trace design is also a data-handling decision. Capture enough identifiers and metadata to debug the workflow, while minimizing raw customer content and applying the same retention, access, and regional controls expected of the source system.

A production release loop

A useful operating loop combines offline evaluation, release gates, sampled production evaluation, alerts, and structured human review. Every prompt, model, retrieval, extraction, or tool change should be compared against the current baseline before release.

• Run deterministic checks for schemas, citations, tool arguments, and business rules.
• Run model-based and custom evaluators for qualities that cannot be captured by exact matching.
• Block releases on critical regressions instead of averaging safety or task failures into one headline score.
• Review sampled production traces and feed confirmed failures back into the test set.
• Track quality, latency, and cost together so an improvement remains operationally viable.

The practical takeaway

The evaluation system is part of the product. For an imaging workflow, the minimum credible production package is a versioned test set, stage-specific metrics, traceable runs, explicit release thresholds, privacy-aware telemetry, and a named owner for failures after launch.