Évaluation de l'IA expliquée : des bases aux agents auto-améliorants

Mode facile : C'est quoi un eval - Un eval est un test pour voir si ce qu'un agent IA a fait est correct - Le secret du « correct » est d'encoder ce que toi / ton organisation considère comme correct dans un logiciel - Exemple : un agent GTM qui enregistre la réunion client, rédige un brouillon de suivi et s'arrête avant l'envoi - Dans ce contexte, un eval peut vérifier si la réunion client a été enregistrée, si le brouillon de suivi a été rédigé, si l'agent a fait une pause avant l'envoi - Les evals ne sont en fait pas nouveaux, ce sont juste une version évoluée des tests unitaires, quelque chose qui a toujours existé en logiciel - La recette pour mettre en place un eval est en réalité assez simple : agent + système + tâches + vérificateur - Dans l'exemple de l'agent GTM, vous avez votre agent, un accès en lecture/écriture à Salesforce, un ensemble de tâches (comme mettre à jour le statut du lead, enregistrer l'appel, rédiger le suivi), et un vérificateur (un outil dont le rôle est de déterminer si la tâche a été bien ou mal réalisée) - Les vérificateurs peuvent être une simple fonction Python ou des vérifications de contenu/prose - Les rubriques sont un excellent moyen de codifier ce qu'est un bon résultat pour les tâches non vérifiables afin que les vérificateurs puissent toujours fonctionner - Une fois les rubriques créées, si l'agent ne performe pas, la cause racine pourrait être : liste de contrôle incomplète, modèle pas assez intelligent, contexte mauvais/incomplet ou prompt pas assez bon Mode difficile : C'est quoi les environnements d'agents - Environnement = l'endroit où un agent fait son travail et où nous mesurons sa performance - Les environnements sont devenus nécessaires lorsque nous sommes passés de l'ère ChatGPT de texte entrant et texte sortant à l'ère agentique de prompt entrant et travail réel sortant - Exemple : pour Claude Code/Codex, lorsqu'ils travaillent sur votre ordinateur, l'environnement est constitué de fichiers, navigateur, e-mails, applications, permissions - Lorsque vous construisez des environnements d'agents aujourd'hui = recréations/simulations d'outils existants qui semblent réels à l'agent mais ne le sont pas (ne vont pas écraser la production) - En gros, vous voulez pouvoir tester la performance de vos agents sans toucher aux systèmes/données en direct de votre entreprise - Besoins lors de la construction d'agents et d'evals : (1) gérer les tâches par équipe (GTM ≠ SWE), (2) environnements spécifiques à chaque équipe, (3) exécuter à grande échelle sans construire toute l'infrastructure vous-même - Un outil populaire pour configurer des environnements d'agents est un framework open source appelé Harbor, qui fournit toutes les abstractions d'environnement d'agents nécessaires pour exécuter des evals afin que vous ne gériez pas tout, mais puissiez descendre au niveau bas si nécessaire - Les primitives de Harbor couvrent : construction d'environnement, construction de vérificateur, construction d'instructions, infrastructure sandbox - Parcours débutant : prenez un eval existant au format Harbor → demandez à Claude Code/Codex de l'expliquer → ajustez-le pour votre agent - LangSmith Engine : créez des evals à grande échelle ; interface utilisateur pour les personnes qui peuvent juger les bons/mauvais résultats et veulent donner des retours sans vivre dans le code - Validez les environnements en exécutant plusieurs agents/modèles réels dedans (par exemple frontier + GLM + petit Qwen) et en cherchant des schémas étranges - L'ingénierie d'environnement est itérative comme l'ingénierie d'agents ; les humains construisent et examinent les résultats - Pour faire des evals à grande échelle, vous avez besoin d'une suite d'evals. Une suite d'evals est une collection de tâches d'agents que vous exécutez en tant qu'entreprise. Chaque tâche est composée d'un prompt d'entrée, d'un vérificateur et de l'environnement. - À chaque fois qu'un nouveau modèle sort, vous exécutez votre suite d'evals (ou une sélection de tâches de la suite), et pesez les compromis entre coût vs vitesse vs intelligence Mode Dieu : C'est quoi un agent auto-améliorant - Cycle continu d'agent dans le monde réel → données de production → transformer la production en evals (et utiliser les evals pour améliorer) → améliorer continuellement l'agent - Avis tranché : si votre équipe est vraiment douée pour transformer les données de production en evals, vous pouvez améliorer continuellement les agents - Les evals existent pour trouver les échecs ; puis modifiez l'agent pour que cet échec ne se reproduise plus jamais - Deux catégories d'amélioration : ingénierie du harnais et fine-tuning d'un petit modèle - Ingénierie du harnais : (endroit bon marché pour commencer) : ajustez les prompts, définitions/descriptions d'outils, choix du modèle, combinaisons de modèles (par exemple Sol+Opus, GLM+Opus) - Fine-tuning (sur votre tâche de production étroite) : modèles ouverts + infrastructure de fine-tuning existent ; peut égaler Opus sur *cette* tâche à environ 10x moins cher ; un agent GTM n'a pas besoin de mathématiques de pointe - Mode Dieu = collecter les données de production réelles → les transformer en evals/environnements → choisir comment améliorer (harnais d'abord ; plus tard posséder une intelligence fine-tunée pour des tâches spécifiques) - Le goulot d'étranglement est souvent la mise à jour humaine des vérificateurs/rubriques - Deux questions pour l'autonomie : comment tourner plus vite ; peut-il fonctionner sans humain dans la boucle ? - Objectif : minimiser les points de contact humains dans la boucle - Les traces d'agents sont la première étape pratique pour les organisations utilisant des agents - Trace = journal de chaque action : appels d'outils - Les humains ne peuvent pas bien raisonner sur ce qu'un agent *va* faire ; regarder le comportement en direct (c'est-à-dire les traces) rend l'évidence du bon/mauvais claire - Voir un mauvais résultat → lire les traces (reçus) → trouver l'étape erronée → modifier l'agent pour qu'il ne répète pas - Les points de contact humains diminuent à chaque sortie de modèle plus intelligent - Le rôle humain d'aujourd'hui n°1 (en amont) : expliquer à l'agent d'exploitation/amélioration ce qu'est un bon vs mauvais résultat (prompt des comportements à rechercher) ; principalement en amont avec quelques modifications au fil du temps - Ensuite, un agent peut trouver des appels d'outils échoués, des échecs de suivi d'instructions, etc., et proposer des améliorations (nouveau prompt, nouvel outil/différent, etc.) - Avec une bonne suite d'evals ou une bonne mesure des mauvais comportements en production, un agent exécuté pendant la nuit peut être très bon pour proposer des correctifs - Rôle humain n°2 : lors de la transformation de la production en evals/environnements, examiner ce que *l'entreprise* considère comme important - Acte organisationnel à plus fort effet de levier : les humains écrivent ce qu'est un bon résultat