LangChain en production : Habr AI a expliqué pourquoi les systèmes multi-agents passent au Python pur

Sur Habr AI, une analyse détaillée a été publiée sur la raison pour laquelle les systèmes multi-agents en production ne bénéficient pas toujours de LangChain. L'auteur décrit une pile en Python pur et montre où les abstractions LLM universelles cessent d'économiser du temps et commencent à casser la prévisibilité.

Où l'Abstraction S'Effondre

La critique principale de LangChain dans l'article est que la promesse de "changer un modèle avec une ligne" ne fonctionne presque jamais aussi simplement dans un service réel. En pratique, même les modèles du même fournisseur se comportent différemment : la version coûteuse retourne JSON de manière cohérente, tandis que la moins chère commence à modifier les clés, oublier les instructions système et se confondre dans les exemples few-shot. Si vous ajoutez un autre fournisseur comme YandexGPT à cela, cela casse non seulement le format de réponse, mais aussi les catégories elles-mêmes, sur lesquelles dépend la logique en aval.

"L'abstraction est nuisible quand elle prétend que des choses

différentes sont identiques."

Cela conduit à une deuxième réflexion : le basculement entre OpenAI et YandexGPT est une tâche d'ingénierie distincte, pas une simple case à cocher dans la config. Chaque agent a besoin de prompts distincts, d'un schéma de validation unifié et d'un ensemble de test de demandes réelles. Dans le système décrit, le seuil d'acceptation pour un fournisseur de secours est de 85%, et chaque résultat d'appel passe par un schéma Pydantic avant d'être envoyé au client. En plus de cela, l'auteur place les fournisseurs dans des interfaces Protocol afin que le comportement commun soit unifié, tandis que les différences dans les prompts, l'autorisation et les formats restent explicites.

RAG Sans Magie

Une section séparée de l'article est consacrée à RAG, où "trois lignes de code" se terminent également rapidement. Changer le modèle d'embedding sans réindexer la base de connaissances annule essentiellement le but de la recherche vectorielle : les requêtes et les documents se retrouvent dans des espaces différents, et le système continue formellement à fonctionner, trouvant simplement les mauvais passages de texte. Il en va de même lors du changement de taille de chunk : les anciens documents sont découpés d'une manière, les nouveaux d'une autre, et la qualité de la recherche devient une loterie que les utilisateurs remarquent avant l'équipe.

Par conséquent, en production, selon l'auteur, ce qui importe plus qu'une chaîne pratique est le contrôle total du pipeline de retrieval. Lorsqu'une réponse va à un vrai client, l'équipe a besoin de voir non seulement le beau texte final, mais tout le chemin jusqu'à lui : quel filtre a été appliqué, quels chunks ont entré dans le contexte, quels étaient les scores et pourquoi un document a prévalu sur un autre. Sans cette transparence, le débogage devient de la devinette, et les problèmes surgissent seulement après des plaintes d'utilisateurs.

• score et métadonnées de chaque chunk
• candidats qui n'ont pas passé la sélection
• filtrage par produit, client ou scénario
• mise à jour de la base de connaissances sans temps d'arrêt

Le Contrôle est Plus Important que l'Agent

La partie la plus fragile, selon l'auteur, est l'appel d'outil. Le modèle peut choisir le mauvais outil, passer des paramètres incorrects, ou refuser d'appeler et confidentement halluciner une réponse. L'article explique cela par un exemple simple : un utilisateur demande son horaire personnel, mais l'agent ne va pas au CRM mais à la base de connaissances et retourne une description générale du cours.

Essayer de corriger de telles erreurs avec des prompts seuls mène souvent à de nouveaux edge cases, car le modèle prend des décisions de manière probabiliste, pas déterministe. Pour cette raison, dans sa propre architecture, l'auteur déplace le routage critique hors du LLM dans un classificateur basé sur des règles, et garde le modèle uniquement pour les cas ambigus. Au-dessus de cela se trouvent des contrats explicites pour les agents, des clients distincts pour le CRM et la base de connaissances, des réponses typées, des tentatives pour les défaillances temporaires et une escalade vers un humain si un résultat valide n'est pas obtenu.

Un argument supplémentaire est la sécurité : plus petit est le framework et ses dépendances transitives, plus petite est la surface d'attaque et plus facile d'entendre ce qui protège exactement le système. Le système résultant s'exécute sur FastAPI, utilise directement les SDKs de fournisseurs, ChromaDB et l'API Bitrix24, plutôt qu'une couche d'orchestration générale. Dans la version open-source, le projet compte environ 4500 lignes de code, 170 tests et 84% de couverture.

C'est plus de travail manuel que dans un scénario avec un framework prêt, mais chaque étape peut être enregistrée, reproduite et vérifiée séparément. Pour la production, c'est le compromis clé : moins de magie, plus de code, mais un comportement plus prévisible en cas de défaillances, de basculements et de requêtes non-standard.

Ce Que Cela Signifie

L'analyse de Habr AI capture bien le changement dans le développement LLM : les frameworks sont toujours pratiques pour les prototypes et les démos, mais en production, la valeur se déplace vers les contrats explicites, la validation et l'observabilité. Plus un système a de fournisseurs, d'intégrations et de risques commerciaux, plus difficile est de masquer les différences derrière une abstraction unique, et plus important est de contrôler manuellement chaque point de connexion.