Seven simple steps for log analysis in AI systems

Cet article propose un pipeline standardisé en sept étapes pour l'analyse des journaux d'événements des systèmes d'IA, illustré par des exemples de code dans la bibliothèque Inspect Scout, afin d'établir des pratiques rigoureuses et reproductibles pour les chercheurs.

L'essentiel

Imagine que les systèmes d'intelligence artificielle (IA) sont comme de grands cuisiniers robots dans une cuisine ultra-moderne. Chaque fois qu'ils préparent un plat (répondent à une question, résolvent un problème), ils laissent derrière eux une trace : des notes sur les ingrédients utilisés, les erreurs de coupe, les temps de cuisson, et même leurs pensées intérieures ("Je vais d'abord éplucher la pomme de terre...").

Ces traces, c'est ce qu'on appelle les journaux d'activité (ou logs).

Le problème ? Un seul cuisinier laisse quelques notes. Mais des milliers de robots cuisiniers, pendant des mois, génèrent des montagnes de papiers illisibles, des grimoires incompréhensibles et des milliers de livres de recettes. C'est là que cette paper intervient. Elle propose 7 étapes simples pour transformer ce chaos de papiers en une histoire claire et utile.

Voici le guide, expliqué comme si on préparait un grand banquet :

1. Définir l'objectif : "Qu'est-ce qu'on cherche ?"

Avant de fouiller dans les tiroirs, demandez-vous : Pourquoi on fouille ?

• Est-ce pour vérifier si le robot a vraiment cuisiné le plat demandé ?
• Est-ce pour voir s'il a refusé d'utiliser un couteau dangereux ?
• Est-ce pour comprendre pourquoi il a brûlé la sauce ?
  L'analogie : C'est comme décider si vous êtes inspecteur des normes d'hygiène (pour vérifier la sécurité) ou critique gastronomique (pour juger le goût). Sans but précis, vous vous perdrez dans des montagnes de papiers inutiles.

2. Préparer la bibliothèque : "Ranger les dossiers"

Les notes sont souvent éparpillées, tachées de sauce ou incomplètes. Il faut les rassembler dans un classeur bien organisé.
L'analogie : Imaginez que vous transformez un tas de feuilles volantes en une bibliothèque numérique où chaque livre a une étiquette précise (date, type de plat, nom du robot). Si vous voulez trouver tous les cas où le robot a brûlé l'ail, vous devez pouvoir trier par "brûlé" et "ail" en une seconde.

3. Explorer le terrain : "Lire quelques pages au hasard"

Avant de construire un robot pour lire tous les livres, lisez-en quelques-uns vous-même.
L'analogie : C'est comme goûter un peu de la soupe avant de servir le banquet. Vous regardez quelques conversations pour voir : "Ah, tiens, le robot semble souvent confus quand on lui demande de faire des maths." ou "Oh, il refuse toujours de cuisiner du piment." Cette étape vous donne des idées sur ce qu'il faut chercher plus tard.

4. Affiner la question : "Devenir détective précis"

Maintenant que vous avez vu quelques exemples, transformez votre vague curiosité en une question précise.

• Vague : "Le robot est-il bizarre ?"
• Précis : "Le robot utilise-t-il des mots comme 'dangereux' ou 'je ne peux pas' quand on lui demande de hacker un site ?"
  L'analogie : Au lieu de chercher "un monstre" dans la forêt, vous cherchez spécifiquement "des traces de pas de loup avec une patte manquante". Plus la question est précise, plus vous trouverez la réponse.

5. Créer le détecteur (Scanner) : "Fabriquer un robot-chien"

C'est l'étape la plus technique. Vous créez un petit programme (un "scanner") qui va lire des milliers de pages à votre place pour trouver vos "traces de pas".
L'analogie : Vous ne pouvez pas lire 10 000 livres vous-même. Alors, vous entraînez un chien de police (le scanner) à renifler un mot précis.

• Attention : Si vous dites au chien "cherche un chien", il risque de chercher n'importe quel animal. Il faut lui donner des règles très claires : "Si tu vois le mot 'dangereux' suivi de 'je refuse', aboie !"
• Le papier conseille de bien définir ces règles (le "rubric") et de demander au chien de vous expliquer pourquoi il a aboie.

6. Vérifier le détecteur : "Le test de fiabilité"

Votre chien-chien est-il fiable ? Ou aboie-t-il sur des feuilles mortes ?
L'analogie : Vous prenez un échantillon de 100 livres que vous avez déjà lus et notés vous-même (la "vérité terrain"). Vous faites courir votre chien dessus.

• Si le chien aboie sur les bons livres et se tait sur les autres : Excellent !
• S'il aboie sur des livres normaux (faux positif) ou ignore les livres dangereux (faux négatif) : Recyclage ! Il faut retravailler ses règles d'entraînement.

7. Utiliser les résultats : "Servir le banquet"

Une fois que votre détecteur est fiable, vous lancez l'analyse sur toute la base de données.
L'analogie : Maintenant, vous avez une carte complète de la forêt. Vous pouvez dire : "80% des robots refusent de cuisiner du piment, mais seulement 10% refusent de cuisiner des légumes."
Ces données vous permettent de :

• Corriger les robots : "Hé, arrête de refuser les légumes !"
• Améliorer la sécurité : "Oh, ils refusent trop souvent, il faut peut-être changer la recette."
• Comprendre l'avenir : "Si on leur donne plus de temps, vont-ils accepter le piment ?"

En résumé

Ce papier est un manuel de survie pour ne pas se noyer dans l'océan de données que produisent les IA. Il dit : "Ne vous contentez pas de regarder les chiffres. Lisez les histoires, posez-vous les bonnes questions, créez des outils précis pour les vérifier, et utilisez ces découvertes pour rendre les IA plus sûres et plus intelligentes."

C'est passer du chaos des papiers éparpillés à la clarté d'une carte au trésor.

Résumé technique

1. Problématique

Les systèmes d'IA modernes (agents autonomes et chatbots) génèrent des volumes massifs de journaux d'activité (logs) lors de leurs interactions avec des outils et des utilisateurs. Ces journaux contiennent des données non structurées riches (réponses, appels d'outils, traces de raisonnement, métadonnées) essentielles pour évaluer les capacités, les propensions et les comportements des modèles.

Cependant, l'analyse de ces données présente plusieurs défis majeurs :

• Manque de standardisation : Il n'existe pas encore d'approche unifiée ou normalisée pour analyser ces logs à grande échelle.
• Complexité croissante : Avec l'évolution des capacités des modèles et la complexité des évaluations (ex: évaluations d'agents multi-tours), l'analyse manuelle devient impossible.
• Fiabilité des méthodes actuelles : Bien que des scanners basés sur les LLM (Large Language Models) émergent, leur efficacité varie selon le contexte et les types de signaux (explicites vs implicites).
• Risque de biais et d'erreurs : Sans méthodologie rigoureuse, les chercheurs risquent de tirer des conclusions erronées basées sur des anecdotes ou des biais d'analyse.

2. Méthodologie : Le Pipeline en 7 Étapes

Les auteurs proposent un pipeline structuré en sept étapes pour transformer l'analyse de logs en une pratique rigoureuse et reproductible. Ce cadre est illustré par des exemples concrets utilisant la bibliothèque open-source Inspect Scout.

Étape 1 : Définir l'objectif de l'analyse

Il est crucial de formuler une question de recherche claire, qu'elle soit primaire (ex: "L'agent peut-il résoudre cette tâche ?") ou secondaire (ex: "L'évaluation a-t-elle fonctionné comme prévu ?"). Cela permet de circonscrire le contexte (configuration du modèle, environnement, tâches) et d'éviter des analyses trop larges.

Étape 2 : Préparer la base de données de logs

Organisation des logs bruts dans une base de données structurée. Cette étape implique :

• Le filtrage des runs incomplets ou erronés.
• L'enrichissement des métadonnées (ex: ajout de notes de solution).
• La standardisation des formats pour permettre des requêtes efficaces et le filtrage par métadonnées.

Étape 3 : Explorer les logs

Une phase d'exploration indispensable avant l'automatisation :

• Exploration des métadonnées : Comprendre la structure des données (timestamps, tokens, scores).
• Exploration manuelle : Échantillonnage stratégique (par score, par longueur, par cas limites) pour identifier des motifs, des échecs inattendus ou des comportements surprenants.
• Exploration automatique (sans LLM) : Utilisation de statistiques descriptives, de correspondance de chaînes de caractères (string matching) ou de classificateurs pré-entraînés pour détecter des erreurs ou des motifs simples.
• Exploration avec LLM : Utilisation de LLM pour interroger les données (RAG) ou pour prototyper des scanners afin de détecter des motifs subtils.

Étape 4 : Affiner la question de recherche

Transformation de la question abstraite en une question concrète avec des signaux mesurables.

• Distinction entre les problèmes liés à l'environnement (outils manquants, instructions floues) et ceux liés au système d'IA (refus, hallucinations, incohérence).
• Définition précise des signaux à détecter (ex: "refus direct" vs "évitement du sujet") qui seront opérationnalisés dans les scanners.

Étape 5 : Développer le Scanner

Conception d'un automate (scanner) pour détecter les signaux définis.

• Décisions de conception : Choix du niveau d'analyse (message, transcript complet, population) et du type de score (binaire, multi-classe, quantitatif, relatif).
• Meilleures pratiques :
  • Rédaction de prompts clairs avec des rubriques détaillées (définitions, exemples, catégories "autre").
  • Demande d'explications et de citations de sections du transcript pour réduire les hallucinations.
  • Utilisation de formats de sortie structurés (JSON) et de modèles récents.
• Itération : Affinement itératif du scanner basé sur les erreurs de classification initiales.

Étape 6 : Valider le Scanner

Évaluation rigoureuse de la performance du scanner avant son déploiement à grande échelle.

• Échantillonnage stratifié : Création d'un ensemble de validation couvrant tous les types de résultats (positifs, négatifs, cas limites, faible confiance).
• Étiquetage de vérité terrain (Ground Truth) : Utilisation d'annotateurs humains (experts ou généralistes) en aveugle des sorties du scanner.
• Métriques : Calcul de la précision, du rappel, du F1-score, de l'accord inter-annotateurs (Kappa de Fleiss) et de la calibration des scores de confiance.

Étape 7 : Utiliser les résultats

Interprétation et application des données structurées issues des scanners.

• Signalement (Flagging) : Détection en temps réel de comportements critiques (ex: refus, contournements de sécurité) pour déclencher des actions immédiates.
• Recherche : Analyse statistique rigoureuse (modèles bayésiens hiérarchiques, visualisation) pour tirer des conclusions généralisables sur le comportement des modèles, en évitant le piège des anecdotes.

3. Contributions Clés

• Cadre méthodologique unifié : Première proposition d'un pipeline standardisé pour l'analyse de logs dans les systèmes d'IA, comblant le vide entre les rapports internes et la recherche académique.
• Outils pratiques : Illustration complète via Inspect Scout, une bibliothèque open-source qui facilite l'exploration, la création de scanners et l'analyse à grande échelle.
• Guidance sur les pièges courants : Identification détaillée des biais potentiels (biais de position, biais de longueur, sur-ajustement aux cas spécifiques) et des stratégies pour les atténuer.
• Distinction Environnement vs Agent : Mise en avant de la nécessité de distinguer les échecs dus à l'infrastructure (outils, sandbox) de ceux dus aux capacités du modèle.
• Liste de questions ouvertes : Identification de zones de recherche futures (ex: impact de la longueur du transcript sur la fiabilité des LLM, optimisation des stratégies d'échantillonnage).

4. Résultats et Illustrations

L'article ne présente pas de résultats expérimentaux nouveaux sur un modèle spécifique, mais utilise un cas d'étude concret (l'évaluation de modèles sur des tâches de Capture The Flag en cybersécurité via le benchmark Cybench) pour démontrer l'efficacité du pipeline :

• Détection de refus : L'analyse initiale a révélé que les modèles refusaient souvent des tâches de cybersécurité. Un scanner basé sur des mots-clés s'est avéré insuffisant (faux négatifs).
• Amélioration par itération : Après exploration manuelle et raffinement de la question (Étape 4), un scanner basé sur LLM a été développé avec une rubrique multi-classe (pas de refus, refus partiel, refus indirect, refus critique).
• Validation : Le scanner final a atteint un score F1 de 0,998 sur une tâche de classification binaire et une précision d'étiquetage de 99,0% sur quatre classes, démontrant la viabilité de l'approche proposée.

5. Signification et Impact

Ce travail est fondamental pour l'avenir de la sécurité et de l'évaluation des IA :

• Reproductibilité : Il établit un langage commun et des méthodes standardisées, permettant aux chercheurs de comparer leurs résultats de manière fiable.
• Passage à l'échelle : Il permet de passer d'une analyse qualitative et manuelle (impossible à grande échelle) à une analyse quantitative et semi-automatisée, essentielle pour évaluer les modèles de plus en plus complexes.
• Sécurité et Alignement : En permettant de détecter systématiquement des comportements indésirables (refus, reward hacking, prise de conscience de l'évaluation), ce cadre renforce la capacité de la communauté à auditer et sécuriser les systèmes d'IA avant leur déploiement.
• Fondation pour la recherche future : Il ouvre la voie à des études empiriques rigoureuses sur l'efficacité des différentes stratégies d'analyse de logs.

En résumé, cet article fournit la "boîte à outils" méthodologique nécessaire pour transformer les logs bruts en preuves scientifiques solides concernant le comportement des systèmes d'IA.