Échecs des agents IA : l'architecture en cause

La plupart des agents d'IA échouent en production parce qu'ils sont construits à l'envers

Les bons modèles ne sauvent pas une mauvaise architecture, et la plupart des équipes apprennent cela à leurs dépens. Lorsqu'un système d'agent d'IA échoue en production, ce n'est pas dramatique. Il n'y a pas de crash ni de message d'erreur. Le système continue simplement à fonctionner et à produire des résultats qui semblent raisonnables jusqu'à ce que quelqu'un les lise attentivement et remarque qu'il y a un problème.

Quand une équipe décide d'examiner la situation, il peut leur falloir deux jours de débogage pour comprendre ce qui se passe. Étonnamment, le modèle ne fait pas d'hallucinations, et les outils d'entrée-sortie produisent les résultats corrects. Le problème, une fois qu'il est enfin trouvé, est architectural. Le modèle et les outils sont correctement configurés, mais l'idée est que le raisonnement relierait le tout, ce qui, comme on peut le deviner, échoue évidemment. Il s'avère que le raisonnement ne fait pas ce genre de choses.

Ce scénario explique pourquoi tant d'agents d'IA qui fonctionnent dans des démonstrations ne survivent pas vraiment à une utilisation dans le monde réel. Ce n'est pas un problème de capacité. C'est un problème architectural. Le schéma est familier : des systèmes construits de haut en bas, de l'objectif aux outils en passant par le modèle, avec l'hypothèse silencieuse que le comportement intelligent comblera les lacunes. Cette hypothèse est ce que signifie "construit à l'envers". Et c'est plus courant que la plupart des équipes ne le réalisent jusqu'à ce que quelque chose casse.

Les agents ne sont pas des entités. Ce sont des systèmes.

Un agent d'IA en production n'est pas une seule chose intelligente. Il s'agit plutôt d'un ensemble de pièces interagissantes avec différentes responsabilités, modes de défaillance et niveaux d'observabilité. Le LLM (modèle de langage de grande taille) est l'un de ces composants, pas l'ensemble du système. Juste une pièce de celui-ci.

Cela peut sembler évident quand on le dit à voix haute. Mais le cadre de "l'agent autonome" qui a dominé 2023 et la plupart de 2024 a constamment poussé les ingénieurs vers un modèle mental différent : une entité, une boucle de raisonnement, tout géré par le modèle. Tout ce dont vous avez besoin, ce sont des outils, un bon prompt système, et l'espoir que tout s'imbrique correctement.

En revanche, les ingénieurs qui ont expédié de véritables produits basés sur l'IA décrivent rarement leurs systèmes de cette manière. Ce qu'ils décrivent ressemble beaucoup plus à une architecture de systèmes distribués. Pas parce qu'ils ont lu un livre sur les modèles de conception, mais parce qu'ils ont été brûlés suffisamment de fois pour commencer à structurer leur flux de travail plus sérieusement.

Construire de haut en bas, en commençant par "que doit faire cet agent" et en travaillant à rebours vers les outils et les prompts, est rapide pour commencer. C'est aussi ainsi que l'on se retrouve avec un système où le modèle est responsable de trop de choses, et où rien n'est individuellement débogable. L'architecture a été décidée par l'objectif, pas par les exigences d'ingénierie. C'est cela, la partie "à l'envers".

Alors, que faut-il vraiment pour un système de production ?

La version abstraite est facile à accepter. Voici à quoi cela ressemble réellement. Chaque système d'IA en production qui fonctionne correctement a quelque chose comme une couche de décision, que l'équipe l'ait nommée ainsi ou non. C'est la partie où le modèle vit et fait son travail réel.

L'instinct est de tout pousser dans cette couche : analyser les demandes, gérer la mémoire, traiter les réessais, résoudre les échecs d'outils. C'est acceptable si l'on travaille dans un Jupyter notebook. En production, sous charge, avec de vrais utilisateurs, cela devient la partie du système où tout est de la faute de tout le monde, et la plupart du temps, rien ne peut être débogué.

La couche de décision doit bien faire une seule chose : décider quoi faire ensuite, étant donné un certain contexte déjà préparé pour cela. C'est tout le travail. Qui prépare le contexte ? Quelque chose d'autre. Qui agit sur la décision ? Également quelque chose d'autre.

Ce "quelque chose d'autre" est la couche d'orchestration, et dans la plupart des systèmes bien construits, c'est simplement du code : des conditionnels, des exécuteurs asynchrones, la gestion des réessais, le routage des files d'attente, peut-être même une machine à états selon la complexité du flux de travail. Au lieu de s'attendre à ce que le modèle fasse tout, il est traité comme un autre composant. Ici, le code standard fait le gros du travail avec l'état et les outils, de sorte que le LLM n'a qu'à se soucier de prendre la prochaine décision.

De nombreuses équipes se tournent vers des frameworks ici parce que le code d'orchestration nu semble trop simple, comme s'il devait y avoir plus d'infrastructure. Il n'y en a généralement pas. Moins cette couche contient de magie, plus les bugs sont rapidement trouvés lorsqu'ils apparaissent. Et ils apparaîtront.

Un exemple : sur un projet où l'orchestration vivait à l'intérieur du modèle d'exécution d'un framework, quelque chose était en train de réessayer des appels d'outils d'une manière qui corrompait l'état en aval. Il a fallu deux jours pour trouver le problème. Deux jours pour un bug qui aurait pu être résolu en un rien de temps si la logique de réessai avait tenu en trois lignes de Python écrites en interne.

Cela amène à la couche d'outils et d'exécution, où toute la communication se produit. Maintenant, la couche d'outils et d'exécution est l'endroit où les choses parlent au monde extérieur. Cette couche a généralement un seul travail, qui est de prendre une entrée bien définie et de produire une sortie prévisible.

Mais l'échec qui revient constamment vient d'outils qui essaient d'être utiles en faisant plus d'une chose. Une seule fonction qui appelle une API, met à jour un cache et fait d'autres choses. Dans une configuration comme celle-là, quand ça casse, on ne sait pas où. Même lorsque l'on essaie de remplacer l'API, on démêle une logique qui n'aurait pas dû être entremêlée en premier lieu.

La mémoire et l'état sont les domaines où il faut pousser le plus fort, car c'est là que la plupart des équipes sont le plus sous-préparées. La plupart des équipes pensent à la mémoire comme "ce que le modèle sait". La question la plus importante est ce que le système sait, et si cette connaissance est à jour.

Il peut falloir un après-midi pour déboguer ce qui semble être une simple "hallucination du modèle". Le modèle continue à faire référence aux préférences des utilisateurs, qui ont pourtant été mises à jour vingt minutes auparavant. Ce n'est pas un problème de modèle. C'est un problème de système. Et c'est étonnamment courant.

Dans les systèmes multi-agents, en particulier, l'état partagé est l'endroit où des défaillances subtiles se développent. Un agent met à jour quelque chose. Les autres ne le savent pas. Tout le monde avance avec assurance dans des directions légèrement différentes. La sortie semble presque correcte, ce qui est presque pire que de sembler incorrect.

Et puis il y a l'évaluation et l'observabilité, que presque tout le monde remet toujours à plus tard jusqu'à ce que quelque chose tourne mal. La différence à garder à l'esprit est que le logging vous dit ce qui s'est passé. L'observabilité vous dit si ce qui s'est passé était correct. Dans un système déterministe, ces deux choses sont presque identiques.

Dans un système d'IA, ce n'est pas le cas. Il faut être capable de suivre la demande spécifique du début à la fin, y compris quelles informations le modèle devait considérer, quelle décision il a prise, quel appel API externe il a invoqué et comment il a agi sur sa réponse.

Construire de la bonne manière

Cela commence par l'approche de haut en bas : on veut qu'un agent fasse X, donc on va lui donner les outils, un bon prompt système, et si le modèle est assez intelligent, tout ira bien. Et c'est exactement ce que les gens utilisent pour faire des prototypes, et pourquoi ne le feraient-ils pas ? Ils n'ont pas tort.

Mais voici le problème : cela traite l'architecture comme une conséquence de l'objectif plutôt que comme quelque chose que l'on conçoit délibérément. Ensuite, le système grandit. Vous savez, plus d'outils, plus de flux de travail, plus de cas limites, plus d'utilisateurs, et soudain, il n'y a plus de véritable fondation sous tout cela.

L'approche de bas en haut prend plus de temps, mais elle est beaucoup plus confortable. On commence par les blocs de construction de base et on s'assure qu'ils fonctionnent réellement. Ensuite, on détermine ce que chaque partie doit communiquer, quelles données elle possède et ce dont elle est responsable. Finalement, le système prend forme naturellement à partir de l'interaction de ses parties.

Ce n'est pas un argument du type "les vrais ingénieurs construisent tout à partir de zéro". Ce n'est même pas vraiment une question d'outils. C'est une question du modèle mental que l'on construit. Certains ingénieurs utilisent des frameworks sophistiqués et construisent des systèmes propres parce qu'ils comprennent ce que chaque couche doit faire. D'autres écrivent du Python basique et créent un désordre indébogable parce qu'ils pensent encore en termes de "l'agent décide de tout". Les outils découlent du modèle dans votre tête, et non l'inverse.

Un exemple de système multi-agents particulièrement robuste n'avait presque aucune infrastructure spécifique à l'IA. À première vue, on aurait cru se tromper de dépôt. Une file de messages, des processus de travail avec des portées distinctes, un stockage d'état partagé avec des contrats de lecture/écriture explicites, et un coordinateur prenant des décisions de routage.

Les requêtes du modèle de langage étaient effectuées par les travailleurs eux-mêmes, chacun recevant un ensemble de contexte créé en amont par un autre processus. Au total, le tout faisait environ mille lignes de Python. Certains agents de démonstration comptent plus de code que cela. Chaque partie était traçable. Lorsque quelque chose se comportait de manière inattendue, le problème était généralement trouvé en moins d'une heure parce qu'il n'y avait pas de magie à examiner. Juste du code avec un chemin clair à travers lui.

Ce système a été construit de bas en haut. L'objectif était défini, mais l'architecture n'était pas dérivée de celui-ci. Les composants ont été conçus en premier, évalués individuellement, puis assemblés pour mettre en œuvre la fonctionnalité souhaitée. Ce dernier aspect est le plus important, pas le premier.

Où cela va

Le secteur évolue lentement, passant des "frameworks d'agents" vers une infrastructure appropriée, avec des systèmes pour l'évaluation, le routage des modèles, les solutions de secours et la gestion de l'état. Au moins une partie de cela existe déjà. La majorité reste à venir alors que les gens résolvent des problèmes de production difficiles dans cet espace.

Un constat revient encore et encore : les personnes qui construisent les systèmes les plus fiables n'utilisent souvent même pas les meilleurs modèles.