Pourquoi les ingénieurs seniors rencontrent-ils des difficultés lors de la conception d'agents d'IA ? @philschmid a partagé un paradoxe intéressant : pourquoi les ingénieurs seniors expérimentés progressent-ils souvent plus lentement et plus difficilement dans le développement d’agents d’IA que les ingénieurs juniors ? Selon Schmid, la cause profonde réside dans le fait que le génie logiciel traditionnel privilégie le déterminisme et la désambiguïsation, tandis que le génie des agents est intrinsèquement probabiliste, ce qui exige des ingénieurs qu’ils apprennent à « faire confiance » aux modèles locaux (LLM) pour gérer les processus non linéaires et les entrées en langage naturel. Il analyse les difficultés liées à ce changement de mentalité à travers cinq défis majeurs et propose des pistes concrètes pour aider les ingénieurs à s’adapter à ce paradigme. Points clés : Un changement de paradigme, du déterminisme au probabilisme. Le développement logiciel traditionnel privilégie la prévisibilité : entrées fixes, sorties déterministes et isolation des erreurs par la gestion des exceptions. À l’inverse, les agents intelligents s’appuient sur des modèles linéaires logiques (MLL) comme « cerveau », prenant des décisions grâce au langage naturel et permettant des interactions à plusieurs tours, des embranchements et une adaptation. Cependant, l’instinct des ingénieurs expérimentés est de « supprimer l’incertitude », ce qui, paradoxalement, freine le potentiel des agents intelligents. Schmid souligne que les ingénieurs juniors ont tendance à appréhender l’incertitude plus intuitivement et peuvent produire des prototypes fonctionnels plus rapidement, tandis que les ingénieurs expérimentés doivent se défaire d’habitudes acquises au fil des années. Les cinq principaux défis mettent en lumière cinq points de conflit entre les pratiques d'ingénierie traditionnelles et le développement d'agents. Chaque défi est accompagné d'explications et d'exemples, illustrant comment adopter une approche plus flexible. 1. Le texte est le nouvel état Les systèmes traditionnels utilisent des données structurées (telles que des valeurs booléennes comme `is_approved: true/false`) pour représenter les états, garantissant ainsi discrétion et prévisibilité. Cependant, les intentions réelles sont souvent dissimulées dans les nuances du langage naturel, comme le suggère le commentaire d'un utilisateur : « Ce plan semble intéressant, mais veuillez vous concentrer sur le marché américain. » Imposer une structure binaire à un système entraînerait la perte de ces nuances, empêchant l'agent de réagir de manière dynamique. Idée : Conserver le texte original comme état, permettant aux modèles de langage naturel (MLN) de l’interpréter dans son contexte. Par exemple, stocker les préférences de l’utilisateur telles que « Je préfère le Celsius pour la météo, mais j’utilise le Fahrenheit pour la cuisine » plutôt que de simples valeurs booléennes. Cela exige des ingénieurs qu’ils passent d’une approche axée sur la structure à une approche privilégiant la flexibilité sémantique. 2. Transfert du contrôle Les architectures traditionnelles, comme les microservices, s'appuient sur des routes fixes et des points de terminaison d'API pour contrôler les processus. Or, un agent ne dispose que d'un unique point d'entrée en langage naturel, le LLM déterminant l'étape suivante en fonction des outils et du contexte – potentiellement par des boucles, des retours en arrière ou des redirections. Par exemple, une intention de « désabonnement » pourrait être négociée pour « proposer une réduction afin de conserver l'agent ». Le codage rigide de ces processus limite l'adaptabilité de l'agent. Conseil : Faites confiance au LLM pour gérer le flux de contrôle et tirez parti de sa compréhension globale du contexte. Les ingénieurs devraient concevoir des systèmes qui prennent en charge cette « navigation non linéaire », plutôt que de prédéfinir toutes les branches. 3. Les erreurs ne sont que des entrées. Dans le code traditionnel, les erreurs (comme les variables manquantes) déclenchent des exceptions, entraînant des plantages ou des tentatives de réexécution. Or, chaque exécution d'un agent consomme du temps et des ressources, rendant une défaillance totale inacceptable. Les auteurs soulignent que les erreurs doivent être traitées comme de nouvelles données d'entrée, renvoyées à l'agent pour permettre l'auto-réparation. Idée clé : Concevoir un mécanisme robuste qui réintègre les erreurs dans le modèle LLM pour permettre leur correction, plutôt que de les isoler. Cette approche repose sur une vision probabiliste : l’échec n’est pas une fatalité, mais une opportunité d’amélioration. 4. Des tests unitaires aux évaluations Les tests unitaires reposent sur des assertions binaires (réussite/échec), adaptées aux résultats déterministes. Or, le résultat d'un agent est probabiliste ; par exemple, la commande « résumer cet e-mail » peut produire une multitude de variations valides. De plus, les tests simulant des modèles logiques logiques (LLM) ne vérifient que les détails d'implémentation, et non le comportement global. Recommandation : privilégier les « évaluations », qui prennent en compte la fiabilité (taux de réussite, par exemple 45/50), la qualité (un expert juridique évalue l’utilité et l’exactitude) et le suivi (vérification des étapes intermédiaires, comme la consultation d’une base de connaissances). L’objectif n’est pas une certitude absolue, mais une forte probabilité de succès. 5. Les agents évoluent, les API non. Les API sont conçues en partant du principe que les utilisateurs humains peuvent déduire le contexte, mais les agents intelligents sont « littéralistes » : si « email » dans get_user(id) est interprété à tort comme un UUID, la réponse risque d’être erronée. L’ambiguïté des API accentue les limitations des modèles linéaires logiques. Conseil : Concevez des API robustes grâce à des types sémantiques détaillés (comme `delete_item_by_uuid(uuid: str)`) et des docstrings. Les agents intelligents peuvent s’adapter instantanément aux modifications de l’API, ce qui les rend plus flexibles que le code traditionnel. Solutions et implications Schmid ne préconise pas l'abandon total des principes d'ingénierie, mais recherche plutôt un équilibre entre confiance et vérification : construire des systèmes résilients en évaluant et en suivant une gestion probabiliste. Parallèlement, il reconnaît que les agents ne sont pas omnipotents ; les tâches linéaires simples sont mieux adaptées aux flux de travail qu'aux agents. Citons par exemple la préservation de l'état textuel des retours utilisateurs, la mise en place de boucles de récupération basées sur les erreurs et la quantification des performances des agents par des évaluations (par exemple, un taux de réussite de 90 % ou une note de qualité de 4,5/5). Adresse du blog :
