Dans le logiciel, le code documente l’application. En IA, les traces le sont.

Publié le 2024-11-16 10:00:00. Avec l’essor des agents d’intelligence artificielle, la manière dont les développeurs comprennent et déboguent leurs applications est en pleine mutation : le code source n’est plus la source de vérité, mais les traces d’exécution des modèles.

• Dans les logiciels traditionnels, le code est la documentation et la source de vérité.
• Avec les agents IA, la logique de décision réside dans le modèle et se manifeste au moment de l’exécution.
• Les traces d’exécution deviennent alors l’outil essentiel pour comprendre, déboguer et optimiser ces systèmes.

Dans le développement logiciel classique, face à un dysfonctionnement ou pour comprendre une fonctionnalité, on se tourne vers le code source. On profile le code pour optimiser les performances. Le code est la référence ultime, la documentation vivante du système. Mais cette approche devient caduque avec l’avènement des agents d’intelligence artificielle.

La particularité des agents IA réside dans le fait que le code ne constitue plus qu’une infrastructure de base. Il définit les composants – quel modèle utiliser, quels outils mettre à disposition, quelles instructions générales donner – mais ne contient pas la logique de décision proprement dite. Cette logique émerge au moment de l’exécution, au sein du modèle d’IA.

Prenons un exemple simple : un agent chargé de traiter les soumissions de formulaires. Dans un logiciel traditionnel, on examinerait la fonction handleSubmit() pour comprendre comment les données sont validées, l’authentification vérifiée et l’API appelée. Le processus est déterministe : mêmes entrées, même code, même résultat. Avec un agent IA, le code pourrait ressembler à ceci :

agent = Agent(
    model="gpt-4",
    tools=[search_tool, analysis_tool, visualization_tool],
    system_prompt="You are a helpful data analyst..."
)
result = agent.run(user_query)

Ce code orchestre simplement les appels au modèle de langage (LLM). Les décisions cruciales – quel outil utiliser, comment raisonner sur le problème, quand s’arrêter, quoi prioriser – sont prises par le modèle au moment de l’exécution. Il devient donc de plus en plus difficile de prévoir le comportement de l’application en se basant uniquement sur le code.

Les traces d’exécution, quant à elles, documentent la séquence d’étapes suivies par l’agent, le raisonnement à chaque étape, les outils utilisés et les résultats obtenus. Elles constituent la nouvelle documentation, la source de vérité sur le comportement réel de l’application.

Dans un logiciel traditionnel, des sorties différentes impliquent généralement des entrées ou un code différents. Avec les agents IA, la même entrée et le même code peuvent produire des résultats variables en raison des différents appels d’outils, des chaînes de raisonnement distinctes et des résultats divergents. Seules les traces permettent de comprendre ces variations.

Comment ce changement impacte le développement d’agents

Ce basculement de la source de vérité du code aux traces a des implications profondes sur l’ensemble du processus de développement. Le débogage devient une analyse de trace : au lieu de chercher une erreur logique dans le code, on examine où le raisonnement de l’agent a déraillé. Le problème n’est plus une erreur de programmation, mais une erreur de raisonnement.

Par exemple, un agent qui réessaie un appel d’API échoué cinq fois avant d’abandonner ne présente pas de bug dans le code de gestion des tentatives. Le problème réside dans l’incapacité de l’agent à tirer les leçons du message d’erreur, une information visible uniquement dans la trace.

Il est impossible de définir un point d’arrêt dans le raisonnement d’un modèle d’IA. Cependant, on peut utiliser les traces et des environnements de test interactifs (les “playgrounds”) pour analyser l’état de l’agent à un moment donné, examiner son contexte, sa mémoire et les outils disponibles, et expérimenter différentes approches pour améliorer ses décisions.

Les tests doivent également évoluer vers une approche axée sur l’évaluation des traces. Il est nécessaire de mettre en place un système pour collecter et analyser les traces en production afin de détecter toute dégradation des performances ou dérive de la qualité. L’évaluation continue devient indispensable, car les agents IA ne sont pas déterministes.

L’optimisation des performances se concentre désormais sur l’identification des schémas de décision inefficaces dans les traces : appels d’outils inutiles, raisonnements redondants, chemins coûteux. Le goulot d’étranglement se situe dans les décisions de l’agent, et celles-ci ne sont visibles que dans les traces.

La surveillance doit passer de la simple vérification de la disponibilité du système à l’évaluation de la qualité des décisions : taux de réussite des tâches, qualité du raisonnement, efficacité de l’utilisation des outils. Cette évaluation nécessite l’analyse des traces.

La collaboration entre développeurs se déplace vers des plateformes d’observabilité où les traces sont centralisées. Au lieu de réviser le code, les développeurs partagent des traces, commentent des points de décision spécifiques et expliquent les choix de l’agent. La plateforme d’observabilité devient un outil de collaboration à part entière.

Enfin, l’analyse des produits fusionne avec le débogage. Comprendre le comportement des utilisateurs nécessite de comprendre le comportement de l’agent. Les analyses de produits doivent être construites sur l’analyse des traces pour identifier les causes des frustrations des utilisateurs ou les fonctionnalités demandées.

En résumé, dans le développement logiciel traditionnel, le code est la documentation. Dans le monde des agents IA, la trace est la documentation. Pour réussir, il est impératif de faire ce changement et de s’équiper d’outils d’observabilité performants pour collecter, analyser et comprendre les traces d’exécution. Sans cela, on travaille à l’aveugle, ignorant la logique qui guide réellement le système.