Pourquoi les ingénieurs en IA vont au-delà de LangChain vers des architectures d’agents natifs

Je suis resté étroitement sur ce sujet et cela m’a ramené quelques expériences de travail sur quelques projets.

Prenons ce scénario : vous fournissez une fonctionnalité basée sur LLM, la démo est propre et toutes les parties prenantes sont satisfaites. Puis, trois semaines après le début de la production, quelque chose se brise d’une manière que personne ne peut expliquer.

Vous passez un après-midi à regarder des journaux qui vous disent quoi c’est arrivé mais pas pourquoi.

Ensuite, il s’avère que le framework a avalé le contexte quelque part entre la troisième et la quatrième étape, et maintenant vous lisez du code source que vous n’avez pas écrit.

Ce n’est pas un rapport de bug ; c’est un signal d’alarme sur l’architecture.

Des frameworks tels que LangChain permettent aux ingénieurs de créer des systèmes basés sur LLM sans comprendre au préalable comment ces systèmes fonctionnent sous pression. Au début, on dirait que la cavalerie est arrivée.

Mais croyez-moi, le coût n’apparaît que lorsque vous êtes plongé dans un incident de production, et vous vous demandez maintenant pourquoi votre agent a ignoré l’étape de vérification qu’il était censé exécuter.

Cet article traite de ce coût et des raisons pour lesquelles de plus en plus d’ingénieurs, après l’avoir découvert, construisent désormais eux-mêmes la couche d’orchestration.

Donnez à LangChain son crédit

Je me souviens avoir vu un collègue construire un pipeline RAG fonctionnel en une quarantaine de minutes au début de 2023.

Il est passé du magasin de vecteurs à travers la chaîne de récupération, les modèles d’invite et l’appel LLM, tous connectés à l’heure du déjeuner.

Six mois auparavant, cela aurait représenté un projet d’au moins deux semaines.

À bien y penser, c’est en fait comment et pourquoi LangChain s’est répandu si rapidement.

La plupart des ingénieurs n’avaient jamais créé d’applications LLM auparavant. Personne n’avait d’opinion bien arrêtée sur la bonne façon de structurer une chaîne de récupération ou de gérer la mémoire de conversation et d’autres choses de ce genre.

LangChain s’est présenté avec des réponses modulaires, composables et documentées, et bien sûr, les équipes les ont immédiatement récupérées, y compris la mienne.

Alors quand je dis que cela crée des problèmes de production, je ne fais pas de dédain. Il a été optimisé pour la phase dans laquelle se trouvaient la plupart des équipes lorsqu’elles l’ont adopté. Les problèmes sont survenus plus tard, lorsque la phase a changé.

Là où l’abstraction se brise

Lorsque j’apprenais la programmation orientée objet au cours de ma deuxième année, l’un des premiers concepts qui a fait mouche a été l’abstraction : cacher les détails internes du fonctionnement de quelque chose et n’exposer que ce dont l’utilisateur a besoin.

LangChain applique cette même idée à l’orchestration LLM. Il cache une grande partie de ce qui se passe à l’intérieur de votre système afin que vous puissiez avancer plus rapidement.

Mais les systèmes d’IA de production exigent quelque chose qui va à l’encontre de cela : clarté.

Vous devez savoir exactement ce que votre système a fait, dans quel ordre, avec quelles entrées et pourquoi. Pas grossièrement. Exactement.

Les abstractions échangent cette visibilité contre de la vitesse. C’est un échange équitable au début, jusqu’à ce que la complexité cachée devienne exactement ce que vous devez comprendre.

Et cela se manifeste de plusieurs manières.

Le débogage est pire qu’il n’y paraît : Lorsqu’une chaîne en plusieurs étapes donne un résultat incorrect, vous ne déboguez pas simplement votre propre code. Vous essayez également de comprendre le flux d’exécution du framework et ce que faisait la couche de rappel en coulisses.

Une fois, j’ai passé trois heures à rechercher une panne qui s’est avérée être un module de mémoire coupant silencieusement le contexte. Le correctif lui-même a pris quatre minutes. Trouver la cause de ce phénomène a pris une demi-journée, car l’abstraction rendait le comportement réel invisible.

L’observabilité atteint un plafond : Vous pouvez intégrer LangSmith et obtenez des traces utiles, mais vous voyez toujours les choses à travers le prisme du cadre, limité aux étendues qu’il choisit d’exposer. Lorsque vous avez besoin de visibilité sur quelque chose de spécifique à votre logique métier, vous finissez par travailler autour du modèle de données du framework au lieu de simplement mesurer ce qui compte réellement.

C’est dans l’état multi-agent que les choses s’effondrent vraiment : Le moment que tu as agents coordonnantun planifiant, d’autres exécutant et un autre vérifiant, l’état partagé devient le véritable problème.

Qui a créé cette information, quand et est-elle toujours valable ?

Un agent met à jour la mémoire, un autre lit une version obsolète et le coordinateur prend une décision basée sur un contexte qui ne correspond plus à la réalité.

L’état géré par le framework a tendance à fonctionner très bien pour le chemin heureux et s’effondre discrètement dans les cas extrêmes. Les systèmes de production vivent dans ces cas extrêmes.

La latence s’accumule : Chaque couche d’abstraction ajoute une surcharge via la sérialisation, la validation, le déclenchement de rappels et le routage interne qui s’exécute, que vous en ayez besoin ou non.

Dans un prototype, cette surcharge est invisible. Sous trafic réel, cela apparaît dans latence centileen particulier dans les gammes p95 et p99 où les utilisateurs le ressentent réellement.

Le coût par appel peut être faible, mais dans un système agent effectuant quatre, cinq ou même six appels modèles par demande utilisateur, ces petits coûts s’accumulent rapidement.

À un moment donné, vous devez vous demander si ces frais généraux valent toujours ce qu’ils vous rapportent.

Rien de tout cela n’est impossible à résoudre dans un cadre. Mais les correctifs commencent à donner l’impression de contourner le framework au lieu de travailler avec lui. Et une fois sur place, il devient plus difficile de dire ce que le cadre vous offre encore.

Alors, à quoi ressemble réellement « le construire soi-même » ?

L’« architecture d’agents natifs » semble plus complexe qu’elle ne l’est en réalité. Cela signifie simplement écrire vous-même la logique d’orchestration en tant que code que vous possédez, au lieu de vous fier à l’abstraction d’un framework.

L’état est quelque chose que vous définissez et mettez à jour explicitement. Les outils sont des fonctions claires que vous pouvez tester vous-même. La mémoire est du code que vous avez écrit. Il est donc plus facile de déboguer, de contrôler et de comprendre ce qui est stocké et comment il est récupéré.

L’appel du modèle est votre code, ce qui signifie que vous pouvez l’instrumenter directement et tracer ce qui compte.

Bien sûr, il y aura plus de code dès le départ. Mais quand quelque chose tombe en panne, l’échec est dans votre code et non quelque part dans un modèle d’exécution écrit par quelqu’un d’autre.

N’oublions pas que les flux de travail complexes s’articulent plus naturellement ici. Des éléments tels que l’exécution parallèle, le branchement conditionnel et les tâches asynchrones de longue durée fonctionnent bien mieux dans modèles basés sur des événements d’une manière que l’exécution en chaîne synchrone ne gère pas proprement.

Plus de travail de conception en amont signifie moins de lutte contre les incendies plus tard.

---

J’ai vu des équipes reconstruire un prototype LangChain parfaitement performant en une couche d’orchestration personnalisée simplement parce que les architectures natives semblaient plus « sérieuses ». Ils ont passé trois semaines supplémentaires dessus et ont livré le même système avec plus de code à maintenir.

Pour moi, ce n’est pas un progrès.

Si vous vérifiez si une fonctionnalité vaut la peine d’être créée, un framework vous y amènera plus rapidement. Si trois personnes utilisent le système en interne et que personne n’y est connecté, la surcharge d’abstraction est correcte.

La question n’est pas « framework ou natif ? » C’est ce pour quoi vous devez optimiser en ce moment. Une itération rapide sur des exigences incertaines signifie que le cadre a du sens. De vrais utilisateurs, de vrais SLA, la coordination des agents et la surveillance opérationnelle signifient que l’architecture native gagne son coût initial.

La plupart des équipes atteignent ce tournant plus tôt que prévu, généralement lors de la première session de débogage sérieuse ou la première fois que quelqu’un demande des mesures détaillées, et la réponse honnête est « non sans beaucoup de travail supplémentaire ».

C’est le moment de repenser l’architecture, pas après six mois passés à trouver des solutions de contournement.

Les cadres sont la manière dont les connaissances sont transférées dans un nouveau domaine. LangChain a rendu le développement d’applications LLM accessible à une génération d’ingénieurs. Cette contribution est réelle.

Mais la maturité dans un domaine revient à passer de « Je configure le framework pour faire la chose » à « Je comprends ce que faisait le framework et je prends ces décisions moi-même ».

Non pas parce que les frameworks sont mauvais, mais parce que posséder votre architecture signifie que vous savez ce qui se passe sous le capot.

Les ingénieurs qui construisent les systèmes d’IA de production les plus fiables ne sont pas ceux qui disposent des outils les plus sophistiqués.

Ce sont eux qui peuvent expliquer exactement ce que fait leur système à tout moment. Quelle invite est construite, à partir de quel contexte, dans quelles conditions et avec quelle solution de repli.

Cette clarté est difficile à maintenir à travers d’épaisses couches d’abstraction.

---

Réflexions finales

La dette d’abstraction est silencieuse jusqu’à ce qu’elle devienne bruyante. Vous ne le remarquerez pas pendant la construction. Vous le remarquerez lorsque quelque chose échoue d’une manière que le message d’erreur du framework ne peut pas expliquer.

Ce moment arrive plus tôt que prévu, généralement déclenché par une session de débogage ou une demande de surveillance plutôt que par une réunion de planification.

L’état et l’observabilité ne sont pas facultatifs. Si vous ne pouvez pas retracer ce que votre agent a fait et pourquoi, vous n’améliorez pas vraiment le système. Vous espérez simplement le meilleur à chaque fois que vous vous redéployez.

Traitez l’orchestration comme une véritable décision architecturale. Choisissez-le exprès, avec les compromis visibles.

Les ingénieurs qui construisent des systèmes d’IA durables ne sont pas ceux qui ont évité les frameworks. Ce sont eux qui ont su arrêter de laisser le cadre décider à leur place.

---

Avant de partir !

J’écris davantage sur les véritables décisions d’ingénierie derrière les systèmes d’IA, sur les domaines dans lesquels les abstractions sont utiles, là où elles font mal et ce qu’il faut pour construire de manière fiable.

Tu peux abonnez-vous à ma newsletter si vous en voulez plus.

Connectez-vous avec moi