L’intégration LangChain ScaleDown remet en cause la taxe de contexte des modèles de pointe

LangChain a lancé l’intégration LangChain ScaleDown le 13 octobre, en déplaçant trois opérations récurrentes de contexte hors des coûteux modèles de pointe. Cette évolution remet en cause un schéma courant de conception d’agents : utiliser le modèle le plus capable pour la planification, la génération, la synthèse, l’extraction et toute autre décision de soutien.

Le nouveau package langchain-scaledown connecte LangChain et Deep Agents aux modèles de décodage contraint de ScaleDown, ou CDM. Ces modèles spécialisés limitent les sorties à ce qu’autorise une tâche étroite, comme une étiquette, un passage source ou un champ structuré. LangChain a également ajouté ScaleDown à son LangSmith LLM Gateway.

L’annonce ne constitue pas simplement une intégration de fournisseur supplémentaire. Elle transforme la gestion du contexte en une couche d’inférence distincte, avec ses propres modèles, contrôles et comportements de défaillance. OpenAI, Anthropic et les développeurs de frameworks d’agents ont abordé le même problème par la mise en cache, la compaction, la mémoire et des fenêtres de contexte plus larges. LangChain avance désormais une réponse différente : cesser de demander à un modèle généraliste d’exécuter chaque opération répétitive liée au contexte.

L’intégration LangChain ScaleDown scinde la pile d’agents

LangChain sépare le raisonnement à forte valeur ajoutée du travail de contexte répétitif qui l’entoure.

Selon l’intégration de contexte pour agents de LangChain, le package fournit des middlewares pour la synthèse de l’historique, la compression du contexte, la compression des résultats d’outils et l’extraction structurée. Le modèle principal de l’agent continue de planifier, rédiger et décider de l’étape suivante.

Cette séparation est importante, car un agent ne se contente pas de générer une réponse finale. Au cours d’une longue exécution, il lit les réponses d’outils, conserve l’historique pertinent, écarte les éléments obsolètes et transforme les messages des utilisateurs en état structuré. Ces opérations peuvent se répéter avant que l’utilisateur ne voie une nouvelle réponse.

L’intégration attribue ces opérations de soutien à quatre modèles ScaleDown :

• Summarize condense l’historique plus ancien de la conversation.

• Compress sélectionne les informations pertinentes pour une question donnée.

• Extract copie les champs demandés depuis le texte source.

• Classify évalue le contenu selon des étiquettes définies par le développeur.

Les modèles de décodage contraint de ScaleDown diffèrent des modèles de langage généralistes par leurs sorties autorisées. Un modèle généraliste peut générer presque n’importe quelle séquence de jetons. Un modèle contraint fonctionne dans un espace de réponses plus restreint, façonné autour d’une tâche unique.

LangChain affirme que cette restriction permet aux modèles de rester plus petits et d’exécuter des opérations limitées plus efficacement. La conception s’apparente à l’utilisation d’une requête de base de données plutôt qu’à demander à un assistant généraliste d’examiner chaque ligne et de rédiger une réponse en prose.

Le middleware publié donne à cette séparation des modèles des points d’entrée pratiques. ScaledownSummarizationMiddleware s’active lorsque l’historique de conversation dépasse un seuil configuré. Il remplace les messages plus anciens par une synthèse tout en conservant une partie récente de l’échange.

ScaledownToolCompressionMiddleware intervient après certains appels d’outils sélectionnés. Il ajoute un champ compression_query qui permet à l’agent d’indiquer les informations dont il a besoin dans le résultat. Le middleware supprime ce champ avant d’exécuter l’outil, puis compresse le texte renvoyé avant que le modèle principal ne le voie.

ScaledownExtractionMiddleware collecte des valeurs structurées à partir des messages des utilisateurs. Un workflow d’assistance peut demander un identifiant de commande, un message d’erreur, une adresse e-mail et une catégorie de problème. Les champs obtenus entrent dans l’état de l’agent, où les outils ultérieurs peuvent les lire sans répéter l’extraction dans la boucle de raisonnement du modèle principal.

Le package inclut également une compression générale du contexte pour les grands prompts système. La documentation du middleware de LangChain déconseille de l’appliquer à des prompts courts ou créatifs. La compression peut supprimer le ton, des instructions ou des détails dont le modèle a besoin.

Cet avertissement définit la limite de l’intégration. ScaleDown ne remplace pas le modèle central de l’agent. Il prend en charge des opérations délimitées dont les sorties attendues peuvent être décrites avant le début de l’inférence.

La documentation du package indique que les quatre chemins de middleware échouent de manière ouverte. Si ScaleDown refuse une requête, devient indisponible ou épuise son allocation, l’agent continue sans le résultat de ce middleware. Cela évite qu’une optimisation auxiliaire n’interrompe automatiquement le workflow principal.

Ce comportement soulève aussi une question opérationnelle importante. Un agent qui poursuit son exécution sans compression ou extraction peut rester disponible tout en se comportant différemment. Les équipes doivent donc surveiller à la fois la disponibilité et la cohérence sémantique entre les parcours optimisés et de repli.

Les agents de longue durée paient leur historique à répétition

La pression provient de coûts de contexte récurrents, et non d’un unique prompt exceptionnellement volumineux.

Un agent de longue durée accumule des instructions, des messages utilisateurs, des réponses de modèle, des appels d’outils et des résultats d’outils. Chaque nouvelle requête au modèle peut reprendre une grande partie de cet enregistrement. Même lorsque le modèle n’en a besoin que d’une petite partie, l’application doit encore décider quoi conserver.

Un agent de programmation illustre le problème. Il peut lire plusieurs fichiers, parcourir un dépôt, examiner les résultats de tests, modifier du code, lancer des tests et revenir sur des échecs antérieurs. Un seul résultat d’outil peut contenir des milliers de lignes, alors qu’une seule erreur ou définition de fonction peut influer sur l’étape suivante.

Sans une gestion délibérée du contexte des agents LangChain, l’enregistrement devient coûteux et source de distraction. Davantage de contexte accroît le traitement des entrées, tandis qu’un historique non pertinent peut diminuer la concentration du modèle. La synthèse introduit un autre appel de modèle, avec sa propre latence, son coût et un risque potentiel de perte d’informations.

L’exemple de LangChain montre que ScaleDown compresse un résultat de documentation de 18 402 caractères à 3 110 caractères. Cela représente près de 90 % de réduction du contenu envoyé au modèle principal de l’agent. Il s’agit d’une trace, et non d’une garantie générale de performance, mais elle illustre le mécanisme recherché.

Les économies peuvent se cumuler. Si le résultat non compressé reste présent dans chaque requête ultérieure, l’application paie à répétition pour le traiter. Compresser le résultat avant son entrée dans l’historique durable modifie le coût de chaque tour suivant.

La même logique s’applique à la synthèse. Lorsque les anciens messages approchent d’un seuil de contexte configuré, le middleware produit un enregistrement compact contenant des éléments tels que l’intention, la progression, les artefacts et les prochaines étapes. Les messages récents restent intacts, car ils sont plus susceptibles de compter mot pour mot.

Cette approche vise deux contraintes distinctes. Les fenêtres de contexte ont une capacité finie, et le traitement d’un contexte utile mais surdimensionné entraîne toujours latence et coût. Une fenêtre d’un million de jetons ne rend pas chaque jeton inclus gratuit ni pertinent.

ScaleDown indique que chacun de ses quatre modèles accepte jusqu’à un million de jetons d’entrée. LangChain précise que Extract, Summarize et Classify acceptent également les images et les PDF numérisés. Ces capacités pourraient réduire le besoin de découpage côté application, bien que les performances pratiques dépendent toujours de la structure du document et de la qualité de la tâche.

L’intégration LangChain ScaleDown atteint aussi le LangSmith LLM Gateway via un chemin dédié /scaledown. Les administrateurs d’espace de travail stockent une clé de fournisseur ScaleDown, tandis que les applications s’authentifient via LangSmith.

Le chemin de fournisseur de la passerelle conserve le comportement natif des requêtes et réponses de ScaleDown. LangSmith gère l’authentification, les secrets du fournisseur, les politiques et le traçage sans traduire l’API dans le schéma d’un autre fournisseur.

Cela rend l’optimisation du contexte visible dans la même couche opérationnelle qui suit le modèle principal. Les appels ScaleDown peuvent apparaître dans les traces et être comptabilisés dans les dépenses et limites de débit de l’espace de travail. Les équipes n’ont pas à traiter le middleware de contexte comme une collection invisible de requêtes annexes.

C’est particulièrement pertinent pour les acheteurs en entreprise. Réduire la facture liée aux modèles compte, mais gouverner le nouveau fournisseur compte aussi. Des traces centralisées peuvent montrer quand la synthèse a eu lieu, à quelle fréquence la compression s’est exécutée et si les appels auxiliaires ont ajouté une latence imprévue.

La pression immédiate s’exerce sur les équipes qui utilisent des modèles de pointe pour chaque opération. Elles doivent désormais justifier pourquoi l’extraction, la classification et la compaction de l’historique exigent le même modèle que celui chargé de la planification ouverte.

Des modèles spécialisés prennent en charge l’entretien du contexte

Le pari central est que des sorties contraintes peuvent préserver l’utilité sans payer le prix d’une génération sans restriction.

Les modèles de décodage contraint de ScaleDown réduisent l’espace de sortie avant le début du traitement. Classify renvoie des scores pour des étiquettes autorisées. Extract identifie les passages source et les champs. Compress sélectionne le contenu pertinent pour la question. Summarize produit une représentation délimitée plutôt qu’une réponse ouverte.

Cette conception rend le mécanisme plus important que le benchmark mis en avant. Un modèle contraint n’a pas besoin de la même ampleur qu’un assistant censé écrire du code, planifier une enquête ou arbitrer des instructions contradictoires. Il doit faire preuve de cohérence sur une opération définie.

L’intégration LangChain ScaleDown transforme cette distinction en middleware. Les développeurs peuvent conserver le modèle d’agent de leur choix tout en déléguant certaines transformations. L’architecture est donc compositionnelle plutôt qu’une migration complète de modèle.

La compression des résultats d’outils en est l’exemple le plus clair. Supposons qu’un agent d’assistance récupère l’intégralité d’une politique de retours alors qu’il examine une question précise sur un remboursement européen. Le modèle principal peut fournir une requête de compression décrivant le passage nécessaire. ScaleDown filtre alors le résultat avant qu’il ne devienne partie intégrante de la conversation visible par le modèle.

Le modèle principal peut demander à nouveau le résultat non compressé si la version condensée est insuffisante. Cette voie d’échappement est importante, car la pertinence dépend de la question fournie au compresseur. Une requête faible ou prématurée peut exclure un fait dont l’agent aura besoin ultérieurement.

L’extraction constitue un autre cas délimité. Un agent qui crée un ticket peut avoir besoin d’un code d’erreur exact. Un modèle génératif peut paraphraser le code ou le reproduire incorrectement. Un système d’extraction conçu pour copier des passages depuis la source a une tâche plus limitée et une cible d’évaluation plus claire.

LangChain indique que le middleware d’extraction lit les messages des utilisateurs plutôt que les réponses de l’agent. Cette règle de provenance aide à empêcher le système de traiter ses propres spéculations antérieures comme des données fournies par l’utilisateur. Les champs qui ne sont pas encore apparus restent vides.

La classification peut servir de contrôle d’exécution. LangChain présente un exemple qui étiquette un agent comme progressant, tournant en boucle ou dérivant. Un seuil de confiance défini par le développeur peut arrêter l’exécution ou ajouter un retour correctif.

Toutefois, LangChain ne fournit pas de middleware prédéfini de détection de dérive dans cette version. Les développeurs doivent définir les étiquettes, la grille d’évaluation, le seuil et la réponse. Cette distinction évite de confondre un exemple avec un système de sécurité prêt à l’emploi.

Le changement architectural plus large correspond à un passage d’agents à modèle unique vers des portefeuilles de modèles. L’agent visible reste généraliste, mais des modèles spécialisés prennent en charge les opérations prévisibles qui l’entourent. Le routage devient un élément de conception de l’application plutôt qu’un détail d’implémentation au niveau du fournisseur.

Cela ressemble à l’ingénierie logicielle ordinaire. Les équipes n’utilisent pas la même base de données, file d’attente, moteur de recherche et environnement d’exécution pour chaque opération simplement parce qu’un système peut approximativement remplacer les autres. La spécialisation peut améliorer l’efficacité lorsque les interfaces et les cas de défaillance sont compris.

Les systèmes d’IA compliquent cette analogie, car le middleware transforme le sens, et pas seulement les octets. Un compresseur peut omettre une réserve. Un résumé peut aplanir l’incertitude. Un classificateur peut attribuer la mauvaise route tout en affichant un niveau de confiance élevé.

C’est pourquoi l’évaluation doit suivre les conséquences pour l’application. Une phrase manquante dans un assistant de connaissances générales peut produire une réponse incomplète. Une exception manquante dans une politique de conformité peut déclencher une action incorrecte.

Les équipes devraient comparer des trajectoires complètes d’agents, et non uniquement des sorties isolées. Le bon test consiste à déterminer si l’agent optimisé atteint le même résultat valide, utilise moins de ressources et maintient un comportement de défaillance acceptable sur un grand nombre d’exécutions.

La promesse des benchmarks est importante, mais les mesures restent celles du fournisseur

Les affirmations de ScaleDown en matière d’efficacité attirent l’attention, mais elles ne démontrent pas des économies de bout en bout pour les agents.

LangChain cite l’affirmation de ScaleDown selon laquelle ses modèles peuvent être 200 fois plus rapides et 467 fois moins chers que les modèles de pointe pour des tâches ciblées. Ces chiffres proviennent du fournisseur, et non d’une évaluation indépendante d’agents LangChain en production.

La comparaison de benchmarks de ScaleDown propose des chiffres plus spécifiques à certaines tâches. Par rapport à la moyenne de trois modèles OpenAI listés, elle indique que Summarize est 41 fois moins cher et 2,7 fois plus rapide. Elle indique que Compress est 138 fois moins cher et 1,8 fois plus rapide.

La même page revendique une précision supérieure pour ces opérations. Toutefois, il s’agit des mesures de ScaleDown sur les jeux de données, configurations de modèles, prix et environnement de latence qu’il a sélectionnés. Les lecteurs devraient les considérer comme des résultats fournis par le fournisseur jusqu’à ce que des équipes indépendantes les reproduisent.

Les économies au niveau d’une tâche diffèrent aussi des économies au niveau d’un flux de travail. Un agent de support a toujours besoin de son modèle principal, de ses outils, de ses systèmes de récupération, de traçage et de son infrastructure applicative. Réduire le coût de la synthèse ne réduit pas chaque composant du même pourcentage.

La part des dépenses totales consacrée au travail sur le contexte variera fortement. Un agent qui effectue un bref appel d’outil peut peu en bénéficier. Un agent de recherche qui traite à répétition de longues pages pourrait en bénéficier beaucoup plus.

La latence présente des limites similaires. L’ajout d’un middleware crée une requête réseau supplémentaire, même lorsque le modèle spécialisé répond rapidement. Le fait que l’utilisateur obtienne un résultat plus rapide dépend de ce que le middleware élimine, de l’endroit où les appels s’exécutent et de la possibilité d’exécuter les opérations simultanément.

La conception en échec ouvert du package doit également être évaluée. Si un appel de synthèse échoue près de la limite de contexte, le modèle principal reçoit l’historique inchangé. L’agent reste actif, mais il peut approcher sa capacité maximale ou générer une requête plus importante.

Un échec de compression peut augmenter le coût sans modifier l’exactitude. Un échec d’extraction peut être plus visible, car un outil en aval peut ne pas recevoir les champs attendus. La logique applicative doit distinguer une valeur vide d’un service d’extraction indisponible.

Il existe aussi une limite liée à la préversion. La documentation du package indique que sd_summarize est en préversion privée et requiert l’activation de ScaleDown. Ce détail importe aux équipes qui supposent que chaque voie annoncée est immédiatement disponible dans des conditions identiques.

La confidentialité et la gouvernance des données exigent un autre examen. Les métadonnées du package indiquent que le middleware n’envoie aux endpoints de ScaleDown que le texte nécessaire et n’inclut aucune télémétrie du package. Cela introduit néanmoins un processeur supplémentaire pour l’historique des conversations, les documents ou les champs extraits.

Une équipe doit examiner quel middleware accède à quel contenu. La synthèse traite les messages plus anciens. La compression d’outils traite des résultats sélectionnés. L’extraction peut traiter des identifiants et coordonnées fournis par les utilisateurs. La classification peut examiner l’historique complet d’un agent.

LangSmith centralise les identifiants et les traces, mais une observabilité centralisée ne répond pas à toutes les questions de gouvernance. Les acheteurs ont toujours besoin de détails sur la conservation, la résidence, la sécurité, l’audit et les contrats auprès de chaque fournisseur.

Les risques liés à l’exactitude méritent une attention égale. La compression est intentionnellement avec perte. L’indicateur important n’est pas seulement la réduction de jetons, mais la question de savoir si le contenu supprimé s’avère ensuite nécessaire. Un agent peut ne pas savoir qu’il a besoin d’une réserve écartée avant plusieurs étapes.

La dérive des résumés pose un problème connexe. Résumer à répétition des résumés peut progressivement modifier l’intention, le niveau de confiance ou l’historique causal. Les messages récents restent disponibles, mais les détails plus anciens peuvent devenir de plus en plus dépendants d’une représentation compressée.

LangChain répond partiellement à ce problème dans Deep Agents en conservant l’historique évincé dans un fichier que l’agent peut relire. Cela offre une voie de récupération. Cela ne garantit pas que l’agent reconnaîtra le moment où une récupération est nécessaire.

Les équipes qui évaluent la gestion du contexte des agents LangChain devraient donc tester le rappel, la précision des outils en aval, les taux d’achèvement, les nouvelles tentatives et la latence totale. Le coût par appel est utile, mais le coût par tâche menée à bien est une mesure plus importante.

ScaleDown concurrence la mise en cache, la compaction et la mémoire

La principale confrontation oppose le traitement spécialisé du contexte au maintien du travail sur le contexte dans la pile de modèles généralistes.

Les fournisseurs de modèles proposent déjà des moyens de rendre les interactions longues moins coûteuses. La mise en cache des prompts évite de recalculer un préfixe inchangé. La compaction remplace les anciens éléments de conversation par une représentation plus petite. Les outils de mémoire préservent des informations sélectionnées entre les sessions.

Les conseils sur la mise en cache des prompts d’OpenAI décrivent la mise en cache comme la réutilisation d’états précédemment calculés pour des préfixes de prompts correspondants. Elle peut réduire le coût de traitement et la latence sans supprimer le contexte mis en cache lui-même.

La mise en cache et la compression de ScaleDown résolvent des problèmes différents. La mise en cache rend le traitement du contexte répété moins coûteux. La compression réduit la quantité de contexte présentée aux appels ultérieurs. Une application peut utiliser les deux, mais leur interaction exige de la prudence.

Modifier le contexte antérieur par compaction ou synthèse peut interrompre la réutilisation des préfixes au-delà du point modifié. Les développeurs doivent déterminer si la réduction du nombre de jetons compense la perte de hits de cache. La réponse dépend de la stabilité du contexte et du nombre d’appels ultérieurs qui réutilisent le même préfixe.

Anthropic a suivi une autre voie avec la compaction, la mémoire, les fichiers et des schémas de harnais d’agents. Sa recherche sur les agents de longue durée soutient que la compaction seule ne garantit pas des progrès cohérents sur de nombreuses fenêtres de contexte.

Cette observation encadre le défi auquel fait face ScaleDown. Une synthèse efficace ne résout qu’une partie de l’autonomie de longue durée. Un agent a aussi besoin d’artefacts durables, d’un suivi explicite de ses progrès, d’une décomposition cohérente des tâches et d’une récupération fiable après un échec.

Les approches ne s’excluent pas mutuellement. Un agent de programmation pourrait conserver un fichier de progression écrit, mettre en cache des instructions stables, compresser de grands résultats d’outils et résumer l’ancien historique conversationnel. Chaque couche traite une forme différente de répétition ou de perte d’information.

La pression concurrentielle concerne plutôt le contrôle. Les fonctionnalités natives des fournisseurs maintiennent davantage d’opérations de contexte au sein d’une même plateforme de modèles. Le middleware de framework permet aux développeurs de combiner des fournisseurs et d’ajuster chaque couche séparément.

La passerelle LangSmith renforce la seconde voie. Elle offre aux utilisateurs de LangChain une couche commune de politiques et de traçage tout en préservant les API propres à chaque fournisseur. ScaleDown devient un autre composant gouverné plutôt qu’un appel externe ad hoc.

Cette flexibilité apporte de la complexité. Les équipes doivent évaluer davantage d’endpoints, d’identifiants, de limites, de traces et de modes d’incident. Une pile monofournisseur comporte moins d’éléments mobiles, même si certaines opérations coûtent davantage.

La bonne architecture dépend de la forme de la charge de travail. De grands résultats d’outils répétitifs favorisent la compression. Les conversations de support structurées favorisent l’extraction. Les échanges créatifs courts offrent moins de gains évidents et présentent un risque plus élevé de perte de nuance.

Les agents riches en connaissances ont aussi besoin d’accéder à des sources durables. Une base de connaissances interrogeable peut préserver les documents originaux tandis que le contexte actif ne contient que le matériel pertinent pour la tâche. Cette séparation rend la compression plus facile à inverser lorsque l’agent a besoin d’un autre passage source.

L’argument le plus fort de ScaleDown n’est pas que les grands modèles sont inutiles. LangChain les conserve explicitement pour la planification, le code, la rédaction et d’autres travaux ouverts. L’affirmation est que l’inférence de pointe est devenue un choix par défaut coûteux pour des opérations aux résultats étroits et mesurables.

Si des tests indépendants étayent cette affirmation, le routage des modèles s’intégrera plus profondément aux frameworks d’agents. Les développeurs choisiront les modèles par opération au lieu de sélectionner un seul modèle pour toute une application.

Si le compromis sur l’exactitude s’avère difficile à maîtriser, la mise en cache et la compaction natives des fournisseurs conserveront un avantage. Elles minimisent la complexité d’intégration et maintiennent le traitement sémantique plus près du modèle responsable de la tâche.

Trois signaux détermineront l’importance de l’intégration

L’adoption dépendra de résultats indépendants sur l’exactitude, de traces de production et des réponses des grands fournisseurs de modèles.

Le premier signal est une évaluation reproductible. Les développeurs ont besoin de tests publics montrant si ScaleDown préserve les faits requis par les étapes ultérieures de l’agent. Les résultats devraient couvrir les longues conversations, les sorties d’outils bruitées, les documents numérisés et les champs présentant une similarité trompeuse.

Ces évaluations doivent mesurer plus que le ratio de compression. Parmi les indicateurs utiles figurent l’achèvement des tâches, la précision des champs exacts, la fréquence de récupération, les erreurs d’outils en aval et la latence sur l’ensemble du flux de travail. Un appel intermédiaire moins cher a une valeur limitée s’il génère une nouvelle tentative supplémentaire.

Le deuxième signal est la preuve issue des traces de production. L’intégration de LangSmith rend cela plus réalisable, car les équipes peuvent observer ensemble les appels principaux et ceux du middleware. Les études de cas devraient montrer la fréquence d’activation de chaque middleware et le pourcentage des dépenses totales d’inférence qu’il modifie.

Surveillez également les données relatives aux chemins de défaillance. Les équipes devraient indiquer à quelle fréquence le middleware échoue en mode ouvert, si les agents détectent un état manquant et comment les exécutions de secours se comparent aux exécutions optimisées. La disponibilité sans cohérence comportementale peut produire des incidents subtils.

Le troisième signal est la réponse concurrentielle. Les fournisseurs de modèles peuvent améliorer la mise en cache native, la compaction, l’extraction structurée ou des endpoints spécialisés moins coûteux. Les frameworks d’agents peuvent aussi ajouter des abstractions de routage qui font de ScaleDown une option parmi plusieurs.

ScaleDown n’a pas besoin de remplacer ces systèmes pour valider l’approche. Il doit montrer que des opérations spécialisées sur le contexte apportent des gains fiables parmi les fournisseurs et les types d’agents.

L’intégration de LangChain avec ScaleDown arrive alors que les agents sont censés travailler plus longtemps et consommer des informations plus hétérogènes. Cette tendance fait de la gestion du contexte une préoccupation centrale d’exécution plutôt qu’un détail de prompt engineering.

Pour les développeurs, l’étape suivante consiste en une comparaison contrôlée. Exécutez des trajectoires représentatives avec et sans modèles de décodage contraint de ScaleDown, puis examinez l’enregistrement complet. Comparez les faits conservés, les actions achevées, les nouvelles tentatives, la latence et l’utilisation totale des modèles. Gardez le contexte original récupérable pendant le test.

La question décisive n’est pas de savoir si un modèle spécialisé peut raccourcir un document. C’est de savoir si l’agent atteint toujours le bon résultat après que ce document a été raccourci. Si la réponse se vérifie sur des charges de travail réelles, la répartition des modèles de LangChain offrira une alternative crédible au paiement de la taxe de contexte des modèles de pointe à chaque tour.