Résumé Technique : LEDGER – Graphes de Traçage de la Réclamation à la Preuve pour l'Audit des Agents LLM

Énoncé du Problème

Alors que les agents basés sur les Grands Modèles de Langage (LLM) évoluent de systèmes de réponse aux questions à un seul tour vers des travailleurs interactifs capables d'exécuter des flux de travail techniques à long horizon (impliquant l'utilisation d'outils, l'exécution de code, l'édition de fichiers et la génération d'artefacts), le principal goulot d'étranglement de la productivité s'est déplacé de la génération de contenu vers l'auditabilité. Les systèmes d'observabilité existants (par exemple, LangSmith) offrent une visibilité granulaire sur les événements d'exécution (prompts, appels d'outils, erreurs, sorties intermédiaires), mais cette visibilité ne équivaut pas à l'auditabilité.

Les examinateurs sont confrontés au problème du « registre plat » : ils doivent reconstruire manuellement la structure logique d'une session pour déterminer quels actions, artefacts et étapes de validation soutiennent une conclusion spécifique. Cette reconstruction manuelle est laborieuse, passe mal à l'échelle avec la complexité de la session et occulte la lignée directe entre une réclamation finale et les preuves sous-jacentes qui la produisent. L'article soutient qu'un audit efficace nécessite une approche centrée sur la preuve, où les examinateurs peuvent remonter d'un résultat rapporté vers les actions et les artefacts concrets qui l'ont produit, plutôt que de lire un journal linéaire.

Méthodologie : Le Système LEDGER

Les auteurs introduisent LEDGER (Layered Evidence and Decision Graphs for Execution Review — Graphes de Preuves et de Décisions par Couches pour la Revue d'Exécution), un système de traçage et de revue en mode "sidecar" qui fonctionne parallèlement à des sessions d'agents interactifs non modifiés. LEDGER ne remplace pas l'observabilité, mais réorganise les enregistrements capturés en un graphe de traces sémantiques à plusieurs couches conçu pour la revue humaine.

1. Capture et Enregistrements de Trace

Le fondement de LEDGER est le Trace Record (Enregistrement de Trace), un substrat stable et non interprétatif des données de session capturées.

• Mécanisme : Le système utilise des hooks de cycle de vie (ex: SessionStart, PreToolUse, PostToolUse) et la reconstruction de transcriptions pour capturer des payloads JSON contenant des messages, des invocations d'outils, des résultats et des interactions avec des fichiers.
• Intégrité : Ces enregistrements préservent l'ordre et le contenu originaux de la session, y compris les liens vers la transcription source. Ils servent de « source de vérité », distincte de toute structure inférée.

2. Construction de Graphes par Couches

LEDGER organise les Trace Records en une structure de graphe à trois niveaux :

• Nœuds de Preuve (Evidence Nodes) : Ils regroupent des Trace Records étroitement liés (ex: un appel d'outil et son résultat) en unités de travail inspectables. Ils sont classés par Type (Action vs Artefact) et par Catégorie (ex: user_message, tool_call, control, artifact). Les nœuds d'artefacts représentent spécifiquement des objets inspectables comme des correctifs de code, des graphiques, des tableaux ou des sorties de commande.
• Nœuds de Flux de Travail (Workflow Nodes) : Ils regroupent des Evidence Nodes liés en phases de tâches de plus haut niveau (ex: context, plan, inspect, execute, validate, claim). Cette abstraction permet aux examinateurs de visualiser la session au niveau des phases plutôt qu'au niveau des événements.
• Arêtes Sémantiques (Semantic Edges) : Des arêtes dirigées et typées connectent les nœuds pour définir les relations. Les types d'arêtes clés incluent :
  • uses (utilise) : Une unité de travail consomme un artefact.
  • produces (produit) : Une unité de travail crée ou modifie un artefact.
  • checked_by (vérifié par) : Un changement est validé par une étape spécifique.
  • supports (soutient) : Une preuve justifie une réclamation.
  • informs (informe) : Un résultat façonne un plan ultérieur.
  • frames (cadre) : Une exigence définit le contexte d'une tâche.

3. Interface et Flux de Revue

Le système fournit un tableau de bord local qui intègre :

• Vues de Graphe : Une visualisation à deux niveaux (couches Workflow et Evidence) permettant aux examinateurs de naviguer d'une phase de haut niveau vers la preuve spécifique.
• Inspection d'Artefacts : Un indexage direct dans les artefacts sous-jacents (ex: ouvrir un graphique, un patch ou un tableau spécifique) liés depuis le graphe.
• Audit de la Construction de la Trace : Des vues montrant les Trace Records bruts et les mises à jour du graphe, permettant aux examinateurs de distinguer les erreurs de l'agent des erreurs de traçage (c'est-à-dire vérifier comment le graphe a été construit à partir des données brutes).

Principales Contributions

1. Construction de Graphe de Traçage de la Réclamation à la Preuve : Une méthode pour analyser des sessions d'agents non modifiées en un graphe sémantique stratifié où les nœuds d'artefacts représentent des preuves inspectables et les arêtes typées connectent explicitement les réclamations aux actions de soutien et aux étapes de validation.
2. Interface de Revue Centrée sur la Preuve : Un tableau de bord qui unifie les chemins d'audit au niveau du graphe avec les enregistrements sources et les artefacts, permettant aux examinateurs de passer fluidement de la structure logique du flux de travail aux preuves brutes.
3. Séparation de la Capture et de l'Interprétation : Une conception qui sépare strictement les enregistrements sources déterministes (Trace Records) de la structure inférée (Evidence/Workflow Nodes), garantissant que le graphe reste une aide à l'audit et non une source de vérité opaque.

Résultats et Études de Cas

L'article valide LEDGER à travers deux études de cas utilisant un agent Codex avec traçage en direct activé :

• Étude de Cas 1 : Analyse de Données Tabulaires : Un agent a analysé des données de qualité de l'air pour générer un rapport de modèle quotidien. Le graphe de trace a exposé avec succès la lignée de l'artefact, reliant la réclamation finale à travers les graphiques et tableaux générés jusqu'aux étapes de nettoyage des données sources. Il a également mis en évidence une séquence d'erreur et de réparation, montrant comment une exécution de script échouée (due à une dépendance manquante) a été tracée, corrigée et re-validée, rendant le processus de réparation transparent.
• Étude de Cas 2 : Ajout de Fonctionnalité dans une Base de Code : Un agent a ajouté une utilité de recherche de chemin court à la bibliothèque NetworkX. Le graphe a distingué l'implémentation initiale des tests de régression et des correctifs de garde ultérieurs. Il a permis aux examinateurs de retracer le choix de conception (placer la fonction dans un module spécifique) jusqu'à l'inspection du dépôt et la lecture de la documentation, et vers l'avant jusqu'aux tests spécifiques qui ont validé le comportement.

Dans les deux cas, le système a démontré sa capacité à rendre le « chemin d'audit » explicite, permettant aux examinateurs de vérifier non seulement que une réclamation a été faite, mais comment elle a été soutenue par des artefacts et des vérifications spécifiques.

Signification et Revendications

L'article positionne LEDGER comme une évolution nécessaire de l'observabilité des agents. Sa signification réside dans le passage du paradigme de la visibilité (voir ce qui s'est passé) à celui de l'auditabilité (comprendre pourquoi une conclusion est fiable).

• Revendications Modestes : Les auteurs précisent explicitement que la construction du graphe n'est pas entièrement déterministe ; le traceur interprète quels enregistrements vont ensemble et assigne des arêtes sémantiques. Par conséquent, le graphe est présenté comme une aide à l'audit, et non comme une source de vérité. L'interface est conçue pour garder les enregistrements sous-jacents visibles afin que les examinateurs puissent vérifier la construction du graphe.
• Direction Future : L'article suggère que les travaux futurs devraient viser à remplacer la structure inférée par un modèle par une structure déterministe ou indépendamment vérifiable (ex: via une instrumentation plus forte ou des backends conscients de la provenance) et améliorer le vocabulaire visuel pour mieux distinguer les relations déterministes des relations inférées.

En fin de compte, LEDGER vise à soutenir le besoin croissant de supervision humaine dans les flux de travail complexes des agents en préservant l'accès aux enregistrements sources tout en rendant les connexions entre les actions, les artefacts et les conclusions inspectables et traversables.