Évaluation hors ligne vs surveillance en ligne pour les agents IA

Définition de l'évaluation hors ligne

Composition de trajectoire

Une trajectoire est une liste ordonnée d'étapes que l'agent est censé suivre lorsqu'il reçoit une entrée spécifique. Chaque étape contient :

- l'énoncé de l'utilisateur ou l'événement du système qui déclenche l'agent - la pensée ou le raisonnement que l'agent devrait produire (si vous enregistrez la chaîne de pensée) - l'appel d'outil ou la requête d'API que l'agent devrait effectuer - la réponse attendue de l'outil ou la rétroaction de l'environnement - la sortie finale de l'agent qui devrait être affichée à l'utilisateur ou au système en aval

Lorsque vous collectez des trajectoires, vous commencez généralement par un petit ensemble d'histoires d'utilisateurs représentatives, puis vous les étendez en ajoutant des cas limites que vous avez vus dans les journaux ou que vous pouvez imaginer à partir de documents de exigences.

Rubrique de notation

L'évaluation hors ligne compare la trajectoire réelle de l'agent à la trajectoire dorée en utilisant une rubrique qui peut contenir plusieurs dimensions indépendantes :

- Correspondance exacte – l'agent produit-il la même séquence d'appels d'outils et de réponses ? - Similarité sémantique – les énoncés ou les sorties sont-ils équivalents de manière significative, même si la formulation diffère ? - Fidélité – le raisonnement de l'agent reste-t-il ancré dans les sorties d'outils fournies ? - Succès de la tâche – la sortie finale satisfait-elle aux critères de succès définis pour l'histoire ?

Chaque dimension reçoit une note entre 0 et 1. La note hors ligne globale est souvent une moyenne pondérée, mais vous pouvez également traiter chaque dimension comme une porte séparée.

Exécution de l'évaluation hors ligne dans CI

Puisque l'ensemble de trajectoires est statique et que la rubrique est déterministe, vous pouvez exécuter l'évaluation comme une étape dans votre pipeline d'intégration continue. L'étape vérifie généralement :

- la copie du code de l'agent et des fixtures de trajectoire - l'installation des dépendances requises - l'exécution de l'agent sur chaque trajectoire, en capturant la trace réelle - l'application de la rubrique et la rédaction d'un rapport JSON - l'échec de la construction si une note tombe en dessous d'un seuil prédéfini

Cela vous donne une rétroaction rapide sur les régressions que vous pouvez reproduire.

Définition de la surveillance en ligne

Ce que vous observez en production

La surveillance en ligne ne compare pas à un script préécrit. Au lieu de cela, elle diffuse des signaux en direct à partir de l'agent en cours d'exécution et recherche des déviations par rapport aux références établies. Les signaux typiques incluent :

- la distribution de la longueur ou du nombre de jetons de l'énoncé de l'utilisateur - la fréquence de chaque appel d'outil - les taux d'erreur renvoyés par les API externes - la latence de chaque étape de la boucle de l'agent - le taux de comportement de secours ou de répétition - la dérive sémantique de la sortie finale (mesurée avec la distance d'incrustation à un ensemble de référence récent)

Puisque le trafic de production est illimité, vous collectez ces signaux sur des fenêtres de temps (par exemple, des fenêtres glissantes de cinq minutes) et les comparez aux quantiles historiques.

Points d'instrumentation

Pour obtenir les données dont vous avez besoin, vous devez instrumenter l'agent à quelques endroits clés :

- au point d'entrée – capturer la demande brute de l'utilisateur et un horodatage - avant chaque appel d'outil – journaliser l'appel prévu et les arguments - après chaque réponse d'outil – journaliser le drapeau de réussite, le code d'erreur et la taille de la charge utile - après que l'agent produise sa sortie finale – journaliser le texte de sortie et les scores de sécurité - à intervalles réguliers – émettre un battement de cœur qui inclut l'utilisation de la mémoire et de la charge CPU

Ces journaux sont expédiés vers un backend d'observabilité (Prometheus, Loki ou un backend de série chronologique personnalisé) où vous pouvez créer des tableaux de bord et des alertes.

Règle d'alerte exemple

Une règle utile est de déclencher une alerte lorsque la proportion d'appels à une API externe particulière qui renvoie un code d'erreur 5xx dépasse le centile 99 des deux dernières semaines pendant trois fenêtres consécutives. Cela détecte une dégradation soudaine d'une dépendance que l'ensemble hors ligne n'a jamais couvert car le mode de défaillance n'apparaît qu'en charge réelle.

Pièges courants lorsqu'on ne compte que sur une seule couche

- Expédition avec uniquement des notes hors ligne – vous pouvez passer la porte mais toujours publier un agent qui échoue sur une formulation rare de l'utilisateur ou sur un comportement d'outil qui n'apparaît qu'en concurrence élevée. - Expédition avec uniquement des tableaux de bord – vous pouvez remarquer un problème des jours après que le changement incriminé a été fusionné, ce qui rend le retour arrière plus difficile et augmente l'impact sur l'utilisateur. - Comparaison des chiffres de production sur une période au cours de laquelle le modèle, l'invite ou la liste d'outils a également changé – la dérive observée pourrait être due à la mise à niveau intentionnelle plutôt qu'à une régression, ce qui conduit à de fausses alertes. - Utilisation du même seuil pour les signaux hors ligne et en ligne – les notes hors ligne sont généralement serrées (on s'attend à des correspondances presque parfaites) tandis que les métriques en ligne sont bruyantes ; appliquer une seule coupe peut causer soit trop de faux positifs, soit des détections manquées. - Négligence de la version du jeu de trajectoires – si vous mettez à jour les trajectoires dorées sans ré...

paras

Construction d'une porte de régression dans CI

Ci-dessous se trouve un exemple concret de la façon dont vous pourriez structurer la porte pour un agent de support client qui utilise un modèle de langage, un outil de récupération et une API de création de ticket.

Étape | Outil ou script | Sortie | Fréquence Checkout du code et des fixtures | git clone + git checkout | espace de travail propre | une fois par exécution de pipeline Installation des dépendances | pip install -r requirements.txt | environnement isolé | une fois par exécution de pipeline Exécution de l'agent sur chaque trajectoire | python run_agent.py --trajectories data/trajectories.jsonl | fichier JSONL avec les traces réelles | une fois par exécution de pipeline Application de la rubrique | python score_traces.py --rubric config/rubric.yaml | notes par dimension et globale | une fois par exécution de pipeline Vérification des seuils | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | état de réussite/échec | une fois par exécution de pipeline Publication du rapport | curl -X POST -d @report.json https://metrics.example.com/ingest | enregistrement dans la série chronologique | une fois par exécution de pipeline

Chaque étape est délibérément maintenue idempotente afin que la réexécution du pipeline produise le même résultat. Si une étape échoue, le pipeline s'arrête et la demande de fusion est bloquée.

Configuration des alertes de production qui comptent

La surveillance en ligne efficace se concentre sur les signaux qui changent rapidement lorsque quelque chose ne va pas, plutôt que sur les métriques qui ne dérivent que lentement.

Taux d'erreur d'outil

Mesurez le rapport entre les appels d'outils échoués et les appels d'outils totaux pour chaque service externe. Une augmentation soudaine indique souvent une panne en aval ou un changement dans le contrat de service que l'agent n'a pas adapté.

Compte de répétition de boucle

Certains agents répètent un appel d'outil lorsqu'ils reçoivent une réponse ambiguë. Suivez le nombre moyen de répétitions par demande d'utilisateur. Une augmentation peut signifier que le modèle produit des sorties plus incertaines ou que l'outil renvoie des erreurs vagues.

Dérive d'incrustation de sortie

Calculez une incrustation de phrase pour chaque sortie finale de l'agent et comparez sa distance à la médiane de l'incrustation de la dernière semaine stable. Si la distance du centile 95 dépasse une limite prédéfinie, déclenchez une investigation.

Surveilleur de signal de sécurité

Si vous exécutez un détecteur d'injection d'invite ou un filtre de profanité sur la sortie de l'agent, journalisez la fraction de demandes qui sont signalées. Utilisez la feuille de triche OWASP LLM Prompt Injection Prevention (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) pour décider quels modèles à surveiller. Une augmentation des demandes signalées peut indiquer que le modèle devient plus susceptible aux tentatives de jailbreak.

Toutes ces alertes doivent être acheminées vers une rotation de garde avec un runbook clair qui décrit comment revenir en arrière à la version de l'agent, comment patcher à chaud un wrapper d'outil ou comment collecter des trajectoires supplémentaires pour les tests hors ligne.

Fermeture de la boucle : transformation des résultats de surveillance en tests hors ligne

Le véritable pouvoir de disposer des deux couches apparaît lorsque vous utilisez les observations de production pour améliorer votre batterie de tests.

Capture d'une défaillance nouvelle

Lorsqu'une alerte se déclenche, la première étape consiste à extraire la séquence exacte de demande-réponse qui a causé le problème. La plupart des systèmes d'observabilité vous permettent de télécharger un ID de trace qui inclut :

- l'énoncé de l'utilisateur original - chaque appel d'outil et ses arguments - chaque réponse d'outil - la sortie finale de l'agent

Enregistrez cette trace comme un nouveau fichier de trajectoire.

Étiquetage du comportement attendu

Travaillez avec le propriétaire de produit ou le responsable de la sécurité pour décider quel doit être le comportement correct. Si la défaillance était due à un bogue de l'outil, vous pouvez décider de simuler la réponse de l'outil pour simuler la version corrigée. Si la défaillance était due au raisonnement du modèle, vous pouvez écrire une chaîne de pensée qui conduit à la bonne réponse.

Ajout à l'ensemble hors ligne

Placez la nouvelle trajectoire dans le répertoire de trajectoires contrôlé par version. Mettez à jour la documentation pour noter la source (par exemple, « ajouté à partir d'un incident de production INC-2024-09-12-07 »).

Ajustement de la rubrique si nécessaire

Parfois, une nouvelle trajectoire révèle une dimension qui était précédemment ignorée. Par exemple, vous pouvez découvrir que l'agent produit parfois une réponse correcte mais inclut une phrase d'excuse inutile qui agace les utilisateurs. Vous pouvez ajouter une dimension « concision » à la rubrique et lui attribuer un poids.

Réexécution de la porte

Réexécutez le pipeline CI. Si la nouvelle trajectoire fait chuter la note globale en dessous du seuil, vous savez que le code actuel aurait échoué à la porte – ce qui est exactement ce que vous vouliez détecter avant la publication.

La répétition de ce cycle crée une boucle de rétroaction où la production enseigne à la batterie de tests ce qu'il faut tester, et la batterie de tests empêche les régressions connues d'atteindre les utilisateurs.

Ce que cela n'est PAS

Cette discussion ne promet pas que l'évaluation hors ligne détectera chaque bogue possible avant la publication. Elle ne prétend pas que la surveillance en ligne ne manquera jamais une défaillance ou que les deux couches ensemble fournissent une garantie de correction à 100 %. Elle ne déclare pas que l'utilisation de ces méthodes rendra votre agent impeccable ou que vous pouvez sauter les examens de sécurité, les exercices de rédaction ou la vérification formelle. Elle ne suggère pas que les signaux décrits sont suffisants pour la conformité réglementaire dans les domaines à haut risque. Elle n'affirme pas que le flux de travail éliminera le besoin de surveillance humaine ou que vous pouvez vous fier uniquement aux notes automatisées pour les décisions de publication. Elle ne garantit pas qu'un seuil particulier fonctionnera pour chaque équipe ou chaque architecture de modèle. Elle n'affirme pas que le tableau ci-dessus est la seule façon de configurer une porte CI ou que les règles d'alerte répertoriées sont universellement optimales. Elle…

Références

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Questions fréquentes

Avez-vous besoin des deux ?

Oui, si l'agent touche quelque chose qu'un utilisateur ou un système se soucie de. Ils détectent différentes classes de défaillance.

Les tests hors ligne peuvent-ils remplacer la surveillance ?

Non. Votre jeu de tests ne peut contenir que des entrées que vous avez déjà pensées.

La surveillance peut-elle remplacer les tests hors ligne ?

Non. La surveillance vous indique que quelque chose a changé après le fait ; une porte vous indique avant la publication.

Sur quoi devrions-nous alerter en production ?

Taux de changement des signaux de défaillance, taux d'erreur d'outil et modèles de boucle ou de répétition inhabituels — et non seulement le volume.

Comment gardons-nous les notes comparables dans le temps ?

Épinglez la rubrique et les trajectoires, et enregistrez les modifications du modèle, de l'invite et des outils aux côtés des notes.

L'une ou l'autre couche est-elle une certification de sécurité ?

Non. Les deux sont des signaux d'ingénierie. L'examen de sécurité est un exercice distinct.

Références

- NIST — AI Risk Management Framework - Stanford CRFM — HELM (Holistic Evaluation of Language Models)

Essayez le produit : AgentGrade

2026-09-20 · sources primaires uniquement · pas de métriques de trafic fabriquées · prise en charge de décision uniquement

Articles liés

- Les rubriques d'évaluation d'agent qui voyagent à travers les piles - Explorez la matrice complète de sujets de micro-SaaS AI →