Journaux d'exécution rejouables pour les agents : enregistrer chaque appel de modèle et d'outil

Ce que c'est

Un journal rejouable est un enregistrement d'une exécution d'agent à partir duquel chaque étape peut être reconstituée : la requête exacte envoyée au modèle (prompt système, messages, définitions d'outils, paramètres d'échantillonnage), la réponse (contenu, appels d'outils, raison d'arrêt, usage), et pour chaque appel d'outil ses arguments, son résultat et son statut d'erreur, dans l'ordre et avec des horodatages. Les conventions sémantiques GenAI d'OpenTelemetry définissent des noms d'attributs pour cela ; elles sont encore marquées comme en développement et résident désormais dans un dépôt séparé, semantic-conventions-genai, tandis que le registre d'attributs sur opentelemetry.io les liste avec une note indiquant qu'elles ont déménagé. Parmi eux figurent gen_ai.request.model, gen_ai.request.temperature, gen_ai.request.seed, gen_ai.response.id, gen_ai.response.finish_reasons, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.tool.call.id, gen_ai.tool.call.arguments, gen_ai.tool.call.result et gen_ai.conversation.id pour le regroupement. Les frameworks d'évaluation conservent la même information par échantillon ; Inspect, par exemple, écrit un fichier de journal pour chaque tâche évaluée et l'expose sous forme d'objet EvalLog.

Pourquoi c'est important

Les sorties de modèle ne sont pas déterministes, les résultats d'outils changent avec le monde, et une exécution peut compter des centaines d'étapes. Sans journal, « l'agent a supprimé le mauvais fichier » ne peut pas être retracé jusqu'à l'étape où le mauvais chemin est entré dans le contexte. Avec lui, la requête qui a produit une mauvaise décision peut être renvoyée telle quelle pour tester une correction de prompt, et les résultats d'outils peuvent être simulés à partir du journal pour que le reste de l'exécution se rejoue sans effets de bord.

Comment l'appliquer

• Journaliser à la frontière où la requête quitte le processus, pas depuis le modèle de prompt : ce sont les octets réellement envoyés qui comptent.
• Donner à chaque exécution un identifiant et à chaque étape un numéro de séquence ; relier les résultats d'outils à l'identifiant de l'appel d'outil plutôt que de se fier à l'ordre.
• Stocker le contenu complet, mais expurger les secrets et les données personnelles avant l'écriture (les mêmes règles que pour les journaux applicatifs) et fixer une durée de conservation.
• Enregistrer l'identifiant de réponse et, lorsque le fournisseur en propose une, une version ou une empreinte du modèle servi.
• Construire un mode de rejeu : à partir d'un journal, le harnais sert les résultats d'outils enregistrés pour les appels identiques et signale les appels qui divergent de l'enregistrement.
• Utiliser les mêmes identifiants dans les traces et les métriques pour que les tableaux de bord de coût et de latence renvoient vers une transcription.

Pièges

Ne journaliser que la réponse finale. Tronquer les résultats d'outils dans le journal, ce qui masque l'instruction injectée ou le contenu malformé à l'origine de l'échec. Traiter le rejeu contre un modèle en direct comme déterministe : le rejeu reproduit les entrées, pas la décision. Les journaux qui répètent tout l'ensemble de documents à chaque étape grossissent vite ; dédupliquer par empreinte de contenu.