AgentOps : déployer un prompt ou un modèle en trafic fantôme avant la bascule

Une nouvelle version de prompt système améliore les évaluations hors ligne. Un modèle plus récent réduit les refus inutiles. La tentation est de remplacer directement la version active, puis de surveiller les tickets. Le risque apparaît après la bascule : les vraies requêtes sont plus ambiguës que le jeu de test, le retrieval ne retourne pas les mêmes sources et un outil reçoit des arguments que personne n’avait anticipés.

Le cas d’usage est un agent interne qui aide une équipe d’exploitation à qualifier des incidents. Il lit des runbooks, consulte des métadonnées et peut préparer une action soumise à approbation. Le runtime actuel reste responsable de la réponse utilisateur. Le candidat reçoit une copie contrôlée des mêmes entrées, mais ses sorties et appels d’outils ne doivent produire aucun effet. L’objectif est de décider si le bundle candidat peut passer en canary, doit retourner en évaluation ou doit être abandonné.

Versionner le bundle réellement comparé

Un changement d’agent ne se résume pas au nom du modèle. Le comportement dépend du prompt, du modèle, des paramètres, des sources, des schémas d’outils, des garde-fous et de la politique d’approbation. Enregistrez ces éléments sous un identifiant immuable pour la référence et le candidat.

reference:
release_id: ops-agent-2026-08-01.2
prompt_sha: <immutable-digest>
model_deployment: <reference-deployment>
retrieval_index: runbooks-2026-08-01
tool_contract: tools-v14
guardrail_policy: guardrails-v9
approval_policy: approvals-v6

candidate:
release_id: ops-agent-2026-08-07.1
prompt_sha: <immutable-digest>
model_deployment: <candidate-deployment>
retrieval_index: runbooks-2026-08-01
tool_contract: tools-v14
guardrail_policy: guardrails-v9
approval_policy: approvals-v6

change_scope:
intended: [system_prompt, model_deployment]
forbidden_drift: [retrieval_index, tool_contract, approval_policy]
rollback_target: ops-agent-2026-08-01.2

Si plusieurs composants changent volontairement, assumez cette surface dans la décision. En revanche, une dérive non prévue de l’index ou du contrat d’outil rend la comparaison ambiguë : on ne sait plus attribuer une régression au prompt, au modèle ou à une dépendance.

Construire une frontière fantôme sans effet de bord

Le trafic fantôme n’est pas un deuxième chemin de production. C’est une duplication asynchrone et bornée après les contrôles d’accès, avec une politique de données explicite. La requête de référence continue seule vers l’utilisateur et les systèmes métiers.

Chemin actif
requete autorisee -> runtime de reference -> outils autorises -> reponse utilisateur

Chemin fantome
copie echantillonnee -> minimisation/redaction -> runtime candidat
-> retrieval en lecture -> outils simules ou read-only -> evaluation et traces

Interdictions
aucune reponse du candidat vers l'utilisateur
aucune ecriture dans un ticket, un job ou une ressource cloud
aucun partage de cache conversationnel avec le runtime actif
aucun retry non borne
aucune conservation au-dela de la politique approuvee

Ne dupliquez pas aveuglément toutes les conversations. Échantillonnez par famille de cas, sensibilité, langue, longueur et présence d’outils. Excluez les flux qui ne peuvent pas être minimisés correctement. Les identifiants de corrélation doivent permettre de comparer les deux exécutions sans recopier l’identité complète de l’utilisateur dans les traces d’évaluation.

Pour les outils, trois modes sont défendables : simulation déterministe à partir de réponses enregistrées, appel read-only vers un environnement de test, ou validation de schéma sans exécution. Un simple paramètre dryRun n’est une protection que si le serveur l’impose ; une consigne dans le prompt ne constitue pas une barrière d’exécution.

Capturer une paire comparable

Chaque exécution fantôme doit conserver assez de contexte pour expliquer un écart, sans transformer la plateforme d’évaluation en copie de données de production. L’enveloppe relie entrée redigée, versions, sources, décisions, outils et résultat d’évaluation.

{
"comparisonId": "cmp-7f82",
"capturedAt": "<timestamp>",
"scenario": "incident-triage",
"dataClass": "internal-redacted",
"reference": {
  "releaseId": "ops-agent-2026-08-01.2",
  "traceId": "trace-reference",
  "decision": "draft-diagnostic",
  "tools": ["search_runbooks", "read_service_metadata"]
},
"candidate": {
  "releaseId": "ops-agent-2026-08-07.1",
  "traceId": "trace-candidate",
  "decision": "draft-diagnostic",
  "tools": ["search_runbooks", "read_service_metadata"],
  "toolMode": "simulated"
},
"checks": {
  "approvedSourcesOnly": true,
  "forbiddenToolCall": false,
  "approvalBoundaryRespected": true,
  "candidateOutputDelivered": false
}
}

Les deux runtimes doivent partir d’une entrée logique identique. Si une dépendance change entre les exécutions, conservez sa version ou sa réponse. Sinon, un résultat différent peut provenir d’un index actualisé, d’un statut de service qui a évolué ou d’un outil non déterministe plutôt que du candidat.

Comparer les décisions avant le style

Une similarité textuelle élevée ne prouve pas que les agents ont pris la même décision. Comparez d’abord les invariants opérationnels : source autorisée, outil choisi, portée des arguments, demande d’approbation, traitement de l’incertitude et absence d’effet de bord.

blocking_checks:
- candidate_output_reached_user
- write_tool_executed
- forbidden_tool_selected
- approval_boundary_bypassed
- source_outside_approved_scope
- tool_error_reported_as_success

comparative_checks:
- task_outcome
- evidence_quality
- tool_argument_scope
- correct_refusal
- unnecessary_tool_calls
- latency_budget
- token_and_tool_cost

review_rules:
critical_disagreement: mandatory_human_review
evaluator_uncertainty: keep_unresolved
aggregate_score: never_overrides_blocking_check

Un évaluateur automatique peut accélérer le tri, mais il ne doit pas être l’unique juge de cas critiques. Conservez un échantillon revu par des opérateurs et surreprésentez les désaccords : mauvais outil, portée plus large, refus manquant ou réponse confiante malgré une preuve insuffisante.

Lire les écarts comme un signal de production

Les moyennes cachent les petits segments à fort risque. Regroupez les résultats par scénario, langue, outil demandé, type de source et politique d’approbation. Une régression limitée aux demandes ambiguës avec action sensible mérite plus d’attention qu’une légère hausse de latence sur des questions documentaires.

AgentShadowComparisons
| where TimeGenerated > ago(24h)
| where CandidateReleaseId == "ops-agent-2026-08-07.1"
| extend Critical = CandidateOutputDelivered == true
  or WriteToolExecuted == true
  or ForbiddenToolSelected == true
  or ApprovalBoundaryRespected == false
  or ApprovedSourcesOnly == false
| summarize
  Samples = count(),
  CriticalDisagreements = countif(Critical),
  ToolScopeRegressions = countif(ToolArgumentScope == "broader"),
  P95CandidateLatencyMs = percentile(CandidateLatencyMs, 95)
by Scenario, Language, RequestedTool
| order by CriticalDisagreements desc, ToolScopeRegressions desc

AgentShadowComparisons représente ici une table normalisée à adapter au schéma de télémétrie réel. Journalisez aussi les échecs du pipeline fantôme. Une baisse brutale du nombre de comparaisons n’est pas une amélioration : elle peut signaler une duplication cassée, une limite de débit ou un évaluateur indisponible.

Passer du trafic fantôme au canary

Le shadowing observe des requêtes réelles, mais pas les réactions réelles des utilisateurs ni toutes les conséquences d’un outil. Il qualifie donc un candidat pour un canary ; il ne justifie pas à lui seul une bascule globale.

Autoriser un canary borne
volume representatif atteint pour chaque scenario critique
zero violation bloquante
desaccords sensibles revus et expliques
latence et cout dans le budget d'exploitation
traces reference et candidat completes
bundle de rollback encore deployable

Garder en shadow
volume insuffisant sur un segment important
evaluation automatique instable
derive non attribuable entre bundles
hausse de refus a qualifier

Bloquer
ecriture ou reponse utilisateur issue du chemin fantome
appel d'outil interdit ou scope elargi
approbation contournee
source sensible ou non autorisee
erreur de dependance masquee comme succes

Le canary doit limiter utilisateurs, scénarios et outils. Commencez par les cas read-only, gardez l’approbation humaine renforcée et augmentez le pourcentage par étapes. À chaque palier, comparez les traces canary au baseline fantôme au lieu de regarder uniquement le taux d’erreur HTTP.

Décider la bascule et préparer le rollback

Promouvez le candidat quand les invariants bloquants restent intacts, que les segments critiques disposent d’un volume suffisant et que le canary confirme le comportement avec de vrais utilisateurs. Documentez l’identifiant exact du bundle promu et conservez la route de retour testée.

Rollbackez si une violation de garde-fou apparaît, si la portée des outils dérive, si les traces deviennent incomplètes ou si le canary dégrade un scénario critique. Le rollback doit restaurer ensemble prompt, modèle, paramètres, index, contrat d’outil, garde-fous et politique d’approbation. Désactiver seulement le nouveau modèle laisse en place les autres sources possibles de régression.

Après retour, rejouez les comparaisons fautives contre le bundle restauré. Si elles échouent encore, le changement candidat n’était probablement pas la seule cause. Conservez alors l’incident ouvert et isolez la dépendance commune avant une nouvelle promotion.

Conclusion

Le trafic fantôme transforme une bascule de prompt ou de modèle en décision observable. Il expose le candidat aux vraies formes de requêtes sans lui donner le droit de répondre ou d’agir, puis compare les décisions, les sources, les outils et les approbations avant le style.

La sortie du runbook est volontairement binaire : autoriser un canary borné avec preuves, poursuivre l’observation faute de couverture, ou bloquer et restaurer le bundle précédent. Cette discipline permet de faire évoluer un agent en production sans confondre amélioration moyenne et sécurité opérationnelle.