AgentOps : calibrer l'évaluateur avant de faire confiance au quality gate d'un agent

Une release d’agent passe le quality gate lundi et échoue mardi alors que son prompt, ses outils et son index de retrieval n’ont pas changé. Le premier réflexe consiste souvent à rollbacker l’agent ou à baisser le seuil. Ces deux décisions sont prématurées : le déploiement du juge peut avoir changé, une rubrique peut avoir été éditée, un mapping peut désormais omettre les appels d’outils, ou la variabilité du scoring peut faire franchir la limite à un petit échantillon.

Le cas fil rouge est un agent d’exploitation Microsoft Foundry qui lit des runbooks approuvés et prépare des actions de production bornées. Son gate combine respect de la tâche, exactitude des paramètres d’outils, groundedness et rubrique spécifique. Ce runbook détermine si le candidat a régressé ou si le système d’évaluation a dérivé, puis aboutit à l’une de trois décisions : promouvoir l’agent, restaurer ou recalibrer l’évaluateur, ou bloquer la release.

Figer les deux côtés de la mesure

Un résultat d’évaluation compare deux systèmes : l’agent qui produit une trace et l’évaluateur qui l’interprète. Traitez-les comme deux dépendances de production versionnées. Avant tout rejeu, capturez le bundle complet de l’agent et celui de l’évaluation.

agent_bundle:
release: ops-agent-2026-09-22.2
model_deployment: agent-runtime-prod-v7
prompt_digest: sha256:<digest>
tool_schema_digest: sha256:<digest>
retrieval_index: runbooks-prod-42

evaluation_bundle:
dataset: ops-regression-v18
evaluator_config: agent-gate-v11
rubric_version: production-actions-v6
judge_deployment: eval-judge-v4
data_mapping_digest: sha256:<digest>
thresholds_digest: sha256:<digest>

evidence:
agent_outputs: URI immuable ou artifact ID
evaluation_run_ids: [baseline_run, suspect_run]
change_window_utc: <start>/<end>

Conservez réponses originales, appels d’outils, résultats et identifiants de corrélation. Si le rejeu réinvoque immédiatement l’agent, la variabilité de l’agent se mélange à celle du juge. Commencez par scorer des sorties figées identiques avec les bundles précédent et actuel. Rejouez l’agent seulement ensuite.

Construire un jeu d’ancrage arbitré

Le gate a besoin de cas dont le verdict attendu ne dépend pas du juge en cours d’audit. Sélectionnez un petit jeu difficile dans la suite de régression : diagnostic read-only valide, demande ambiguë, écriture interdite, preuve périmée, mauvais paramètre d’outil et refus sûr. Deux experts du domaine classent chaque cas ; un troisième tranche les désaccords.

anchor_set: ops-agent-gate-v3
cases:
- id: valid_read_only_diagnostic
expected: pass
critical_dimensions: [task_adherence, tool_input_accuracy]
- id: restart_without_evidence
expected: fail
required_reason: state_change_without_approval
- id: stale_runbook_citation
expected: fail
required_reason: stale_operational_evidence
- id: safe_refusal_for_broad_scope
expected: pass
critical_dimensions: [policy_adherence]

adjudication:
reviewers: [platform_ops, ai_safety]
resolver: service_owner
evidence_required: [agent_trace, tool_contract, active_policy]
approved_at: <timestamp>

Ne transformez pas ce jeu en second dataset d’entraînement. Gardez-le petit, stable et à accès contrôlé. Ajoutez des cas seulement après revue et conservez une suite holdout séparée pour la décision de release. Un évaluateur qui s’accorde seulement avec les cas utilisés pour régler sa rubrique n’est pas calibré.

Mesurer les désaccords, pas seulement la moyenne

Un pass rate global peut masquer l’échec important. Comparez l’évaluateur à l’arbitrage humain, cas par cas et par classe de risque. Comptez faux positifs, faux négatifs et décisions instables.

Pour chaque evaluateur et classe de risque
true_pass: humain pass / evaluateur pass
true_fail: humain fail / evaluateur fail
false_pass: humain fail / evaluateur pass
false_fail: humain pass / evaluateur fail
unstable: decision variable sur scorings identiques repetes

Priorites de release
Action production interdite: zero false_pass sur les ancrages
Refus sur attendu: false_fail = defaut de qualite
Qualite reponse read-only: inspecter distribution et exemples
Parametres outil: revoir les arguments exacts, pas seulement la prose finale

Pour un agent capable d’agir, accepter à tort un appel d’outil dangereux n’équivaut pas à rejeter à tort une formulation moyenne. Définissez l’acceptation par dimension et conséquence. Les cas critiques utilisent des conditions d’arrêt strictes ; les scores agrégés peuvent avoir une tolérance bornée et une revue humaine près du seuil.

Répéter un scoring identique pour révéler la variance

Scorez plusieurs fois les mêmes sorties figées avec le même déploiement de juge et la même configuration. Conservez verdict brut par cas, métadonnées de raisonnement, latence, erreurs et consommation quand elles sont disponibles. Il ne s’agit pas de rendre un juge probabiliste déterministe, mais de vérifier que le gate est assez stable pour la décision qu’il pilote.

Controle de repetabilite
Scorer chaque sortie d'ancrage 5 fois
Garder juge et configuration fixes
Comparer verdict binaire et score par dimension

Bloquer la promotion si
Un ancrage critique recoit des verdicts pass/fail contradictoires
Une action interdite obtient un pass
Des appels d'outils absents sont scores conformes
Une erreur evaluateur est silencieusement comptee comme pass

Revoir manuellement si
Un score non critique franchit le seuil une seule fois
Le raisonnement du juge contredit la trace enregistree
L'evaluateur ne supporte pas le type d'outil present dans la trace

Ne moyennez jamais un faux pass critique. Pour les dimensions non critiques, les répétitions permettent de définir une bande de revue autour du seuil. Un score dans cette bande exige une lecture de l’échantillon, pas une promotion ou un rejet automatique.

Séparer dérive de l’évaluateur et régression de l’agent

Utilisez un rejeu à quatre voies. Scorez les sorties de l’agent de référence et du candidat avec les bundles d’évaluation précédent et actuel.

                         Evaluateur precedent   Evaluateur actuel
Sorties agent reference   A                       B
Sorties agent candidat    C                       D

Interpretation
A differe de B: evaluateur ou mapping a change la decision
A = B, C differe de D: inspecter le traitement des traces du candidat
A = C et B = D: aucune regression agent mesuree
A differe de C avec l'ancien evaluateur: regression candidat probable
Champs de trace absents dans B ou D: corriger l'ingestion avant le score

Inspectez les échecs, pas seulement les cellules. Le nouvel évaluateur peut être meilleur et exposer un ancien angle mort. Dans ce cas, ne le restaurez pas uniquement pour retrouver le pass rate historique. Mettez à jour la baseline, documentez le risque désormais détecté et faites réarbitrer les ancrages concernés.

Faire échouer le gate CI de manière explicite

Le pipeline doit publier le bundle de preuves et une décision lisible. Résultat absent, schéma incompatible ou contenu de trace non supporté ne doivent jamais devenir un pass. Séparez le gate du déploiement afin qu’un opérateur puisse relire les preuves sans accorder l’accès production.

gate:
require_pinned:
- dataset
- evaluator_config
- rubric_version
- judge_deployment
- data_mapping_digest
hard_fail:
- critical_anchor_false_pass
- missing_tool_calls
- evaluator_error
- unsupported_trace_type
manual_review:
- non_critical_score_in_review_band
- evaluator_disagreement
promote_when:
- no_hard_fail
- anchor_repeatability_accepted
- candidate_delta_within_budget
- evidence_artifact_published
rollback: restore_previous_evaluator_bundle_and_hold_candidate

Après réussite offline, exposez le candidat à une cohorte canari en lecture seule. Comparez les traces de production au schéma évalué et gardez les outils d’écriture désactivés jusqu’à confirmation de leur complétude et du comportement de l’évaluateur. La calibration offline ne prouve pas que la télémétrie de production transporte tous les champs requis.

Décider recalibration, restauration ou blocage

Recalibrez lorsque l’évaluateur actuel est manifestement plus proche de l’arbitrage humain mais que son seuil ne représente plus le risque voulu. Versionnez seuil et baseline ; ne les modifiez jamais en place pour faire passer une release.

Restaurez le bundle précédent lorsque le nouveau juge, la rubrique ou le mapping augmente les désaccords inexpliqués, perd des champs de trace requis ou rend les décisions critiques instables. Cette restauration rollbacke le système de mesure, pas l’agent candidat, qui reste bloqué.

Bloquez ou rollbackez le candidat quand les deux versions de l’évaluateur identifient la même régression dans la trace, surtout une action dangereuse, un mauvais paramètre d’outil ou un refus absent. Ne rouvrez la promotion qu’après réussite du jeu d’ancrage figé et de la suite holdout séparée.

Conclusion

Le quality gate d’un agent est lui-même un système de production. Dataset, mappings, rubrique, déploiement du juge, seuils et schéma de trace peuvent dériver même si l’agent ne change pas. La confiance vient du gel des deux côtés, de la comparaison avec des ancrages arbitrés, de la mesure des faux verdicts et du rejeu de la référence et du candidat avec les deux versions de l’évaluateur.

La décision finale doit nommer ce qui a changé. Promouvez quand le candidat progresse sous un gate calibré et répétable. Restaurez ou recalibrez l’évaluateur quand la mesure a bougé. Bloquez l’agent quand la trace prouve une vraie régression. Un score sans cette attribution n’est pas une décision de release.