Repository navigation
[API Proposal]: Add evaluation and calibration support for probabilistic decision models #7809
Description
Background
The decision-model proposal in [dotnet/extensions#7764] intentionally makes probabilities and complete distributions part of the portable contract.
The experimental implementation in [#7795] strengthens this further with:
Binary probabilities
Choice distributions
Score distributions
declared precision
provenance
model identity
usage
strict response validation
The proposal also explicitly distinguishes:
reported probability
from:
empirical calibration guarantee
That distinction raises a natural follow-up question for Microsoft.Extensions.AI.Evaluation:
Should MEAI provide reusable evaluation metrics for probabilistic decision-model outputs?
Why this matters
Suppose two models produce:
Model A:
P(true) = 0.90
Model B:
P(true) = 0.70
Neither number tells us, by itself, which model is more useful or better calibrated.
Across a labelled dataset we may discover:
predictions near 0.90 are correct 91% of the time
or:
predictions near 0.90 are correct only 65% of the time
These are materially different systems even though both satisfy the IDecisionClient contract.
Applications also need to choose operating thresholds.
For example:
threshold 0.50
→ high recall
→ more false positives
threshold 0.90
→ lower false positives
→ more false negatives
That policy should remain outside IDecisionClient, but MEAI Evaluation could provide standard tools for measuring the trade-off.
Potential Binary metrics
For labelled Binary decisions:
Brier score
log loss
accuracy
precision
recall
F1
ROC / AUC where appropriate
threshold sweep
calibration error
reliability bins
Choice metrics
For categorical distributions:
multiclass log loss
multiclass Brier score
top-1 accuracy
top-k accuracy
calibration metrics
Because [#7795] preserves the full categorical distribution, these metrics can operate on the actual probabilistic evidence rather than only SelectedCandidateId.
Score / ordinal metrics
For ordered decisions:
expected-score error
ordinal distance
distribution error
native-score error where available
The distinction introduced in [#7795] between provider-reported native Score and distribution-derived ExpectedScore should be preserved when defining evaluation semantics.
Abstention-aware evaluation
If the underlying decision contract eventually represents semantic abstention / undecided outcomes, evaluation should also be able to measure:
coverage
accuracy at coverage
selective risk
abstention rate
This is important because a system that answers only 50% of cases with 99% accuracy is different from one that answers 100% with 90% accuracy.
Provenance enables meaningful comparison
The DecisionProvenance work in [#7795] is especially useful here.
Evaluation records can retain:
provider
resolved model
model/version identity
decision definition
observed distribution
ground truth
allowing comparisons across model revisions without making provenance part of the metric itself.
Separation of responsibilities
I would keep the layering explicit:
Microsoft.Extensions.AI.Abstractions
IDecisionClient
→ inference capability
Microsoft.Extensions.AI.Evaluation
→ measurement of decision quality
application/framework policy
→ thresholds and resulting actions
Evaluation should not change the semantics of IDecisionClient, and IDecisionClient should not make calibration guarantees simply because evaluation utilities exist.
Open questions
- Does probabilistic decision evaluation belong in the existing
Microsoft.Extensions.AI.Evaluationpackage? - Should metrics consume
DecisionResponsedirectly or a smaller normalized observation/ground-truth model? - Which metrics are sufficiently general to ship initially?
- Should threshold analysis be a reusable result type rather than each evaluator implementing its own sweep?
- How should ordinal
Scoreevaluation distinguish native score from expected score? - If abstention is introduced, should coverage/selective-risk metrics be first-class?
- Should calibration results be model/workload evaluation artifacts only, rather than exposed through
DecisionClientMetadata?
The intent is not to claim that a probability returned by a provider is calibrated.
It is the opposite: provide standard tooling to measure whether it is calibrated and useful for a particular workload.
Activity
mo3in commentedon Oct 6, 2026
One architectural distinction seems important for this proposal: per-observation scoring and dataset-level statistical evaluation are different operations, and the existing
IEvaluatorshape may not naturally represent both.The current
Microsoft.Extensions.AI.Evaluation.IEvaluatorevaluates oneChatResponseat a time:Decision-model metrics fall into at least two categories.
Pointwise metrics
Some metrics can be computed for one labelled observation:
These can later be aggregated across a dataset.
Dataset-level metrics
Other useful metrics fundamentally require a collection of observations:
A calibration curve, for example, cannot meaningfully be produced from one
DecisionResponse.For that reason, I would avoid requiring the entire proposal to fit directly into the existing per-response
IEvaluatorcontract.A useful layering might conceptually be:
The exact public API can remain open, but API review should probably decide whether decision evaluation needs:
rather than only another
IEvaluatorimplementation.There is another important calibration detail: metrics such as Expected Calibration Error are not uniquely defined without choices such as binning strategy and bin count.
For example:
can produce different ECE values for the same predictions.
So I would prefer not to expose a single apparently canonical
CalibrationErrorvalue without making its computation policy explicit.It may also help to distinguish three related but different concerns:
A model can have strong discrimination but poor calibration, or good calibration but weak ranking performance. Threshold selection is yet another consumer policy concern.
This suggests a few additional review questions: