Validation metrics — match the family to the model

The syllabus says create validation criteria of custom AI models. Criteria are
numbers with thresholds — and which numbers depends entirely on what kind of model
it is. Picking from the wrong family is a common and very visible error.

Classification — precision, recall, F1

Precision — of everything the model flagged, how much was actually right. Low
precision means false alarms.

Recall — of everything it should have flagged, how much did it catch. Low
recall means misses.

F1 — the harmonic mean of the two, for when you need a single number.

A confusion matrix shows you which classes get mistaken for which, which is
what actually tells you how to fix it.

In plain terms: precision is how much of what it said was true. Recall is how much
of the truth it said.

You always buy one with the other

Which is why "high accuracy" is never the criterion. The real question is which
error can you least afford.

A compliance-breach detector needs recall — missing one is unacceptable, and a
few false alarms are just review effort. A customer-facing automatic refund needs
precision — a wrong refund is real money leaving the business.

Vision and object detection — and the one people forget

Precision and recall again, plus mean average precision (mAP). mAP accounts for
how well-placed the detections are as well as how many were right. It is
routinely left out when someone is asked to name the evaluation metrics for a
fine-tuned vision model.

Generative models and agents — evaluators, not accuracy

There is no single right answer to compare against, so Microsoft Foundry supplies
built-in evaluators in families.

General-purpose quality — coherence, fluency.
RAG-specific — groundedness, relevance.
Safety and security — hate and unfairness, violence, protected material.
Agent-specific — tool call accuracy, task completion, task adherence.

You can also write custom evaluators for your domain, and for a business
solution you usually should — "did it apply our eligibility rule correctly" is not
a built-in metric, and it is the thing the business actually cares about.

Evaluation runs against your own data through the Foundry portal wizard or the
SDK. Worth knowing operationally: playground evaluations are on by default in
every Foundry project and bill as consumption.

The process around the numbers

Hold data back. Validate on examples the model never saw. Obvious, routinely
violated, and a model validated on its training data looks excellent and fails in
production.

Compare against the baseline you would otherwise use. The question is never "is
it good" but "is it better than the general model, by enough to justify the cost".

Test the distribution you will actually see, including the rare classes. A
classifier at 97% accuracy that fails on the 3% category that matters is not fit
for purpose.

Check for bias explicitly, especially where people are affected.

Define the re-validation trigger — base model update, data drift, or a
schedule.

Exam trap. Watch the family mismatch: accuracy offered for a generative
agent, groundedness for an image classifier, or precision and recall alone for
object detection when mAP belongs there. All look plausible.

The one line to carry: a criterion needs a metric, a threshold and a named
consequence — "we'll check groundedness" is not one, and a threshold agreed after
seeing the number is not a threshold.