J’ai créé un flux de travail IA dans n8n pour nos opérations internes, et j’aimerais bien avoir des retours de personnes qui ont fait face à des problèmes similaires.
Le flux de travail traite différentes demandes selon le contexte. Il récupère des données, achemine les tâches, met à jour les systèmes et transfère le travail au bon processus. Ça fonctionnait bien au départ, mais au fur et à mesure que nous avons étendu le flux, l’agent a commencé à prendre de mauvaises décisions sur quel outil ou flux de travail appeler.
Parfois, il saute la récupération quand il devrait interroger une base de connaissances. D’autres fois, il appelle la mauvaise branche ou répond de mémoire au lieu d’utiliser les données les plus récentes. Le prompt a grandi au fil du temps, et je me demande si c’est en partie le problème ou si l’architecture globale doit changer.
Pour l’instant, nous utilisons n8n avec OpenAI, une base de données vectorielle pour la récupération, et quelques API internes. Nous avons aussi testé Workbeaver pour les tâches de bureau qui ne sont pas exposées par des API, tout en gardant n8n comme couche d’orchestration principale.
Pour ceux qui construisent des agents IA plus importants dans n8n :
Gardez-vous un seul orchestrateur, ou divisez-vous les responsabilités entre plusieurs agents ?
Comment réduisez-vous les hallucinations quand plusieurs outils sont disponibles ?
Vous fiez-vous surtout à l’ingénierie des prompts, ou avez-vous constaté que les changements architecturaux étaient plus efficaces ?
Avez-vous des bonnes pratiques pour décider quand un agent devrait récupérer des données au lieu de répondre directement ?
J’aimerais vraiment entendre ce qui a fonctionné pour vos projets. Merci d’avance.
Ça ressemble moins à un problème de prompt et plus au fait que tu as dépassé le capacités d’un seul orchestrateur. Quand un agent détient tous les outils, il choisit parmi un grand menu à chaque tour, et les descriptions d’outils plus ton prompt qui a grandi se battent tous pour le même budget attentionnel, donc la sélection d’outils devient floue exactement au moment où tu ajoutes des branches. C’est le pattern que tu décris.
Ce qui a arrangé les choses pour moi, c’était de splitter. Garde un agent routeur léger dont le seul travail est de choisir la voie, puis délègue à de petits sous-agents qui possèdent chacun 2 ou 3 outils. Un espace de décision plus petit par agent, un prompt plus court pour chacun, une sélection d’outils bien plus fiable. L’orchestrateur unique et massif a l’air élégant mais il se dégrade avec chaque outil que tu ajoutes.
Pour le truc du saut de la récupération, arrête de laisser la récupération être un outil que l’agent peut choisir de sauter. Sur les branches où la réponse doit être fondée, lance la récupération comme une étape fixe avant même que l’agent ne voit la demande, donc il a toujours du contexte frais et ne peut pas répondre de mémoire. Ôte cette décision au modèle là où la justesse compte.
Prompt engineering versus architecture, passé une certaine taille l’architecture gagne et c’est sans discussion. Les ajustements de prompt ont un plafond, le routage plus les sous-agents délimités, c’est ce qui tient quand la surface continue de croître.
J’ai construit quelques-unes de ces configurations multi-agents en production, ravi d’aller plus loin sur la structure de routage si ça aide.
Vous avez atteint le mur que presque tous les agents n8n en croissance heurtent : un seul orchestrateur avec un prompt obèse et une douzaine d’outils. La précision de sélection d’outils du modèle s’effondre à mesure que le nombre d’outils et la longueur du prompt augmentent, donc les symptômes que vous observez (récupération omise, mauvaise branche, réponse à partir de la mémoire) sont le mode de défaillance attendu, et non un problème d’ajustement dont vous pourriez vous sortir en retouchant le prompt.
En répondant à vos questions dans l’ordre.
Orchestateur unique vs architecture divisée. Divisée. Transformez un ou deux gros workflows en quatre ou cinq plus petits, chacun responsable d’une seule tâche, et faites appeler l’orchestrateur via webhook ou Execute Workflow. Le seul travail de l’orchestrateur devient le routage : classer la demande, la transmettre au bon sous-workflow, récupérer le résultat. Il ne doit pas récupérer, mettre à jour ou toucher les API lui-même. Chaque sous-agent ne voit alors que les 3 à 5 outils pertinents pour sa tâche au lieu du menu complet, et le modèle choisit correctement bien plus souvent quand le menu est court. En bonus, vous pouvez vraiment le déboguer, car un échec est maintenant isolé à un petit workflow au lieu d’être enfoui dans un monolithe.
Réduire les hallucinations avec plusieurs outils disponibles. Deux leviers. D’abord, réduisez l’ensemble d’outils par agent, comme expliqué ci-dessus. Deuxièmement, ôtez les décisions au modèle partout où la décision est en fait déterministe. Si une branche peut être choisie à partir d’un champ connu avec un nœud Switch, faites-le et ne demandez pas au LLM de décider. Réservez le jugement de l’agent aux cas véritablement ambigus. La plupart des problèmes « il a appelé la mauvaise branche » sont vraiment « j’ai demandé au modèle de faire un choix qu’une règle aurait pu faire ».
Ajustement du prompt vs architecture. L’ajustement du prompt a un plafond et il semble que vous l’atteigniez. Au-delà d’une certaine taille, le prompt est le problème, pas la solution, car vous poussez la fenêtre de contexte assez loin pour que le modèle oublie les instructions antérieures. Un agent serré avec 3 outils et un prompt court bat chaque fois un agent avec 15 outils et un prompt géant. Corrigez d’abord l’architecture, puis ajustez les prompts à l’intérieur des petites pièces.
Décider entre récupérer ou répondre directement. Ne laissez pas cela à la discrétion du modèle, car « répondre à partir de la mémoire au lieu des données les plus récentes » signifie que vous lui avez donné la possibilité de sauter la récupération. Dans la branche qui a besoin de données fraîches, rendez la récupération une étape obligatoire du flux, et non un outil que l’agent peut ou non appeler. S’il doit passer par la base de données vectorielle ou l’API pour atteindre la réponse, il ne peut pas contourner la mémoire. Forcez le chemin plutôt que d’espérer que le prompt le convainc.
Une chose de plus vaut la peine d’être mentionnée puisque vous exécutez ceci en production : une fois que vous divisez en sous-workflows liés par webhook, surveillez les défaillances silencieuses entre eux. Un sous-agent peut retourner vert tout en perdant tranquillement du travail, et l’orchestrateur continuera joyeusement avec des données obsolètes ou vides. Cela vaut la peine de surveiller les comptages d’éléments à chaque transmission.
Je serais heureux d’approfondir le modèle de routage si c’est utile.
@James198 Un point de plus en faveur de la division du workflow : maintenant tu peux adapter chaque job (sous-workflow) et ses outils au modèle qui fonctionne le mieux pour cette partie. Haiku est nul pour l’appel d’outils, tout comme GPT 4 mini, mais Sonnet et GPT 5 fonctionnent incroyablement bien avec. Et en séparant les parties de ton workflow, tu peux vraiment peaufiner et optimiser ta sortie.
Le problème de mauvaise branche est intéressant. Quand il choisit la mauvaise voie, est-ce généralement le même couple de branches qui se confond, ou c’est aléatoire partout ? Et quand il répond de mémoire au lieu d’interroger le vector store, c’est sur un type spécifique de requête (comme les recherches de statut ou les démarrages de processus) ?
J’ai construit des couches d’évaluation pour exactement ce motif et je serais curieux de connaître le taux d’échec sur une journée typique. La division des sous-agents que d’autres ont mentionnée aide, mais il y a généralement une décision classifier-puis-router qui reste fragile même après la division.
La partie utile, c’est le truc du skip-retrieval / wrong-branch / answer-from-memory. Je prends un workflow de production pendant cinq jours et j’envoie une carte expurgée de deux ou trois défaillances reproduites, plus le premier changement et une restauration. Écrit uniquement. Tu écris le miss et le workflow, tu paies, tu lâches les traces expurgées. Pas d’appels, pas de réécriture. Combien a coûté le dernier miss ?