AgentOps : détecter la contamination d’un jeu d’évaluation avant de promouvoir un agent

Un agent candidat gagne douze points sur le jeu d’évaluation de référence. Les réponses sont plus précises, les appels d’outils mieux ciblés et les refus sensibles plus réguliers. La promotion paraît évidente. Pourtant, plusieurs cas ressemblent mot pour mot aux exemples ajoutés récemment au prompt système et certains documents utilisés comme vérité terrain ont aussi été indexés par le retrieval de préproduction.

Le problème n’est plus de savoir si l’agent obtient un bon score. Il faut déterminer s’il généralise vers des situations nouvelles ou s’il reconnaît des réponses qu’il a déjà vues. Le cas d’usage est un agent d’exploitation qui recherche des runbooks, qualifie un incident et prépare une action soumise à approbation. Avant de le promouvoir, l’équipe doit prouver que les cas d’évaluation restent séparés des prompts, des données de réglage, des exemples few-shot, des index documentaires et des traces réutilisées.

Geler le candidat et ses dépendances

Une enquête de contamination n’est fiable que si le système comparé ne bouge plus. Figez le bundle complet : modèle, prompt, outils, garde-fous, index, configuration d’évaluation et versions des jeux de données. Suspendre la promotion ne signifie pas arrêter la production ; la version active continue de servir les utilisateurs pendant que le candidat reste en quarantaine.

candidate_release: ops-agent-2026-08-25.1
promotion_status: quarantined

bundle:
model_deployment: candidate-v7
prompt_digest: sha256:<prompt-digest>
tool_contract: tools-v18
guardrail_policy: guardrails-v11
retrieval_snapshot: runbooks-2026-08-24
evaluator_version: eval-pipeline-v9

datasets:
development: agent-dev-v12
regression: agent-regression-v8
holdout: agent-holdout-v5
red_team: agent-redteam-v4

forbidden_until_decision:
- change_prompt
- rebuild_retrieval_index
- relabel_failed_cases
- publish_candidate
- overwrite_evaluation_traces

Conservez aussi les artefacts bruts : entrées normalisées, sorties, sources récupérées, appels d’outils, décisions de garde-fou et résultats des évaluateurs. Une correction immédiate du prompt peut faire disparaître la preuve sans répondre à la question centrale : d’où le candidat connaissait-il ce cas ?

Cartographier tous les chemins de fuite

La séparation classique entre train et test ne suffit pas pour un agent. Un cas peut atteindre le candidat sans avoir servi à entraîner le modèle : exemple copié dans le prompt, document présent dans l’index, trace de production transformée en démonstration, réponse attendue visible par un outil ou évaluation précédente utilisée pour corriger automatiquement le contexte.

Surfaces a comparer
cas de developpement et de regression
holdout de promotion
scenarios red team
prompt systeme et exemples few-shot
corpus retrieval et metadonnees associees
fixtures de simulation des outils
traces de production recyclees
donnees de fine-tuning ou preference
sorties des evaluateurs et commentaires humains

Fuites critiques
reponse attendue accessible au runtime candidat
identifiant de cas present dans prompt, index ou fixture
document holdout indexe avant l'evaluation
scenario red team transforme en exemple de refus
meme incident duplique entre development et holdout

Similarites a qualifier
gabarit commun mais valeurs differentes
meme runbook, symptome et decision differents
reformulation automatique d'un cas existant
doublon traduit entre corpus francais et anglais

Traitez les versions française et anglaise comme un même espace de risque. Traduire un cas de développement et placer sa version anglaise dans le holdout ne crée pas un scénario indépendant. Les noms de ressources, codes d’erreur, étapes de runbook et décisions attendues peuvent révéler la parenté même si les phrases diffèrent.

Donner une provenance exploitable à chaque cas

Un identifiant de fichier ne suffit pas. Chaque cas doit porter une provenance, une date d’entrée, une famille de scénario, un groupe de déduplication et la liste des surfaces auxquelles il a été exposé. Le groupe relie les traductions, paraphrases et variantes issues du même incident logique.

{
"caseId": "eval-inc-0427-fr",
"scenarioFamily": "tool-authorization-failure",
"language": "fr",
"sourceClass": "synthetic-reviewed",
"sourceRef": "scenario-pack-2026-08",
"createdAt": "2026-08-12T09:00:00Z",
"dedupGroup": "incident-logic-0427",
"split": "holdout",
"expectedDecision": "diagnose-identity-before-permission-change",
"exposure": {
  "prompt": false,
  "retrieval": false,
  "toolFixture": false,
  "fineTuning": false,
  "previousEvaluationFeedback": false
},
"contentDigest": "sha256:<normalized-case-digest>",
"reviewStatus": "approved"
}

Le digest aide à trouver les copies exactes, mais ne remplace pas une déduplication sémantique. Normalisez les espaces, la casse, les identifiants variables et les horodatages, puis comparez aussi les groupes de scénario et la décision attendue. Une proximité lexicale élevée est un signal de revue, pas une preuve automatique de fuite.

Scanner avant d’exécuter l’évaluation

Le contrôle doit intervenir lors de la construction du jeu, puis à nouveau contre le bundle réellement déployé en préproduction. Comparez les digests exacts, les fragments longs, les identifiants rares et les similarités sémantiques. Inspectez séparément le prompt rendu et les documents effectivement récupérables, pas seulement leurs dépôts sources.

blocking:
- exact_match_with_prompt_example
- holdout_document_in_retrieval_snapshot
- expected_answer_in_tool_fixture
- same_dedup_group_across_development_and_holdout
- red_team_case_used_as_candidate_demonstration

review_required:
- semantic_similarity_above_review_threshold
- shared_rare_identifiers
- translated_or_paraphrased_candidate
- provenance_missing
- split_changed_after_result_review

allowed_with_evidence:
- shared_public_runbook_with_distinct_incident_state
- common_operational_template_with_independent_values
- repeated policy rule_testing_different_decision_boundaries

outputs:
- immutable_scan_report
- excluded_case_manifest
- reviewer_decisions
- clean_holdout_digest

Un seuil de similarité ne doit jamais supprimer silencieusement des cas. Il peut rapprocher des candidats, puis un reviewer décide s’ils mesurent la mémorisation, la généralisation ou une compétence réellement différente. Journalisez les exclusions ; sinon, il devient trop facile d’améliorer le score en retirant après coup les scénarios difficiles.

Lire les scores par provenance

Une contamination ne produit pas toujours un score parfait. Elle peut apparaître comme un gain anormalement concentré sur les cas anciens, les scénarios présents dans le retrieval ou les familles ayant servi à corriger le prompt. Segmentez le résultat par origine, date de création, groupe de déduplication et type d’exposition suspectée.

AgentEvaluationResults
| where TimeGenerated > ago(14d)
| where CandidateReleaseId == "ops-agent-2026-08-25.1"
| summarize
  Cases = dcount(CaseId),
  PassRate = 100.0 * countif(Outcome == "pass") / count(),
  ToolBoundaryFailures = countif(CheckName == "tool_boundary" and Outcome == "fail"),
  MedianCreatedAgeDays = percentile(datetime_diff("day", TimeGenerated, CaseCreatedAt), 50)
by Split, SourceClass, ExposureClass, ScenarioFamily
| order by Split asc, PassRate desc

AgentEvaluationResults représente ici une table normalisée à adapter. Cherchez surtout les ruptures : candidat excellent sur les cas exposés mais ordinaire sur le holdout récent, progrès absent sur une famille nouvelle, ou réussite associée à la présence d’un document qui contient presque la décision attendue. Comparez avec la version active ; un biais peut affecter les deux agents et rester invisible dans le seul delta.

Reconstruire un holdout défendable

Si la contamination est confirmée ou impossible à exclure, ne déplacez pas simplement les fichiers concernés vers un nouveau dossier. Construisez un holdout à partir de sources indépendantes, postérieures au gel du candidat ou générées par des reviewers qui n’ont pas accès à ses échecs détaillés. Séparez les personnes qui corrigent le prompt de celles qui valident la nouvelle référence lorsque l’enjeu le justifie.

Le nouveau jeu doit conserver les familles critiques : refus d’action sans preuve, ambiguïté de périmètre, erreur d’outil, source contradictoire, approbation manquante et rollback. Faites varier les détails qui encouragent la généralisation : ordre des symptômes, vocabulaire, langue, ressources et informations inutiles. Ne changez pas la frontière opérationnelle attendue uniquement pour rendre le cas différent.

Rejouez la version active et le candidat sur ce holdout propre. Un candidat réellement meilleur doit conserver une partie significative de son avantage, en particulier sur les invariants bloquants. Une chute brutale indique que le score initial mesurait surtout l’exposition au corpus.

Décider promotion, quarantaine ou rollback

La promotion peut reprendre lorsque la provenance est complète, que les scans bloquants sont vides, que le holdout indépendant confirme le gain et que les scénarios sensibles ont été relus. Le rapport doit identifier le bundle, le digest du jeu propre et les exclusions retenues.

Gardez le candidat en quarantaine si la fuite est probable mais non localisée, si les documents accessibles au retrieval ne sont pas versionnés ou si le nouveau holdout manque de couverture. Rollbackez le pipeline d’évaluation si des résultats contaminés ont déjà servi à sélectionner un modèle, ajuster un prompt ou élargir des outils. Revenez alors au dernier bundle promu sur un jeu dont la provenance est défendable, puis reconstruisez la chaîne d’évaluation avant toute nouvelle promotion.

Le rollback ne consiste pas seulement à restaurer le modèle actif. Il faut aussi retirer les cas holdout des index et des exemples, invalider les rapports contaminés, conserver leur audit, et empêcher les automatisations de promotion de les réutiliser.

Conclusion

Un score AgentOps n’est une preuve que si le candidat n’a pas pu apprendre l’examen. Pour un agent connecté à des sources et à des outils, cette séparation traverse prompts, retrieval, fixtures, traces, données de réglage et feedback d’évaluation.

La décision finale doit rester opérationnelle : promouvoir sur un holdout indépendant et traçable, maintenir la quarantaine quand la provenance reste incomplète, ou rollbacker le pipeline de sélection lorsque la contamination a déjà influencé une version. Le but n’est pas de protéger un benchmark. Il est d’éviter qu’un agent apparemment meilleur découvre ses limites au premier incident vraiment nouveau.