Pourquoi plus de contexte peut rendre les réponses de l'IA pires

Une fenêtre de contexte plus large offre plus de capacité à un système d'IA. Elle ne garantit pas pour autant que le modèle utilisera bien cette capacité. Dans les longues conversations, les pipelines RAG, les agents de recherche et les flux de travail utilisant de nombreux outils, ajouter plus d'historique, plus de documents, plus de sorties d'outils ou plus de mémoire peut rendre une réponse moins fiable plutôt que mieux informée.

Capacité de contexte n'est pas exploitabilité de contexte

La fenêtre de contexte annoncée pour un modèle décrit la quantité de données en entrée qu'il peut accepter. Elle n'implique pas que chaque jeton au sein de cette fenêtre reçoive une attention égale ou contribue de manière égale à la réponse finale. La distinction est importante, car les systèmes en production remplissent de plus en plus le contexte avec l'historique de conversation, des documents récupérés, des résultats d'outils, de la mémoire, des états structurés, des instructions et des artefacts intermédiaires.

L'étude classique « Lost in the Middle » a montré que les modèles à long contexte peuvent être moins performants lorsque les éléments de preuve pertinents apparaissent au milieu d'un long texte d'entrée plutôt qu'au début ou à la fin. La leçon d'ingénierie plus large n'est pas qu'un long contexte est néfaste. Elle est que la disponibilité au sein du contexte n'équivaut pas à une utilisation fiable.

Les recommandations d'OpenAI en matière de gestion du contexte aboutissent à la même conclusion opérationnelle sous un autre angle : même de très grandes fenêtres de contexte peuvent être submergées par un historique non trié, des sorties d'outils redondantes et une recherche documentaire bruitée. Anthropic traite de même le contexte comme une ressource finie qui exige une ingénierie active plutôt qu'une accumulation passive.

Cinq manières dont le contexte supplémentaire peut dégrader la qualité des réponses

1. Dilution du signal : les preuves pertinentes entrent en compétition avec tout le reste

Supposons qu'une question puisse être résolue à partir de deux courts passages. Un système RAG extrait ces passages ainsi que dix-huit autres de pertinence lointaine « par sécurité ». Le rappel de recherche documentaire peut s'améliorer, mais le générateur doit désormais distinguer les preuves décisives des informations d'arrière-plan. Si des formulations similaires apparaissent dans plusieurs documents, le contexte supplémentaire peut rendre la réponse moins précise.

Cela crée une distinction essentielle entre le rappel de recherche documentaire et l'utilité du contexte. Un volume plus important de contenu extrait peut accroître la probabilité que la réponse se trouve quelque part dans le contexte, tout en réduisant simultanément la probabilité que le modèle accorde un poids suffisant aux bonnes preuves.

2. Conflit de preuves : plus de sources peuvent signifier plus de versions de la réalité

Les contextes longs contiennent souvent des informations mutuellement contradictoires : ancienne et nouvelle documentation d'API, deux versions d'une politique, préférences utilisateur antérieures et actuelles, sources web concurrentes, état en cache, ou résumé généré par un modèle qui ne correspond plus à la source.

La défaillance ne relève pas nécessairement de l'hallucination. Le modèle peut combiner fidèlement des preuves contradictoires. L'architecture a donc besoin de règles de priorité : autorité de la source, version, horodatage, juridiction, locataire (tenant), révision du produit, état de l'utilisateur ou métadonnées explicites de remplacement.

Sans ces règles, augmenter le contexte peut accroître les contradictions plus vite que cela n'accroît les connaissances.

3. Sensibilité à la position : l'emplacement des preuves peut modifier le résultat

Les résultats de « Lost in the Middle » ont démontré que la simple modification de l'emplacement d'une information pertinente peut altérer sensiblement les performances du modèle. Ce constat est particulièrement important pour les systèmes qui concatènent de nombreux passages récupérés ou de longs historiques dans un ordre fixe.

Un test en production devrait donc faire varier l'ordre des documents, et non se contenter de tester un unique prompt canonique. Si le système ne répond correctement que lorsque la preuve décisive se trouve au début ou à la fin, l'application est plus fragile que ce qu'indique un simple score de référence.

4. Persistance d'un contexte obsolète : le modèle voit la vérité et l'historique ensemble

Les agents à longue durée d'exécution reconduisent fréquemment leurs conclusions antérieures. Cette continuité est utile jusqu'à ce qu'un fait change. Si le résultat d'un outil d'hier indique qu'un déploiement est sain et qu'un résultat actuel indique qu'il est dégradé, les deux peuvent coexister dans le contexte, à moins que le système ne remplace ou ne délimite explicitement l'état ancien.

C'est pourquoi l'état opérationnel actuel devrait normalement provenir d'une source faisant autorité, tandis que la mémoire conserve le contexte durable tel que les décisions, les préférences ou les procédures. Un historique de conversation plus fourni ne remplace pas une relecture du présent.

5. Perte à la compression : un contexte plus réduit peut aussi devenir un contexte dégradé

L'intervention inverse — compresser le contexte — comporte également ses modes de défaillance. Les résumés peuvent omettre des exceptions, des questions non résolues, la provenance, des identifiants précis, des preuves négatives ou les conditions dans lesquelles une conclusion était valide.

Les travaux de Microsoft Research sur l'Agentic Context Engineering décrivent un problème similaire sous les termes de biais de brièveté et d'effondrement de contexte : les réécritures itératives peuvent éliminer des détails métier pourtant utiles. L'objectif n'est donc pas de « compresser autant que possible ». Il consiste à réduire le contexte tout en préservant les informations qui influent sur les décisions.

Le modèle de qualité du contexte

Un contexte utile peut être évalué selon six dimensions. Aucune d'entre elles ne se résume au simple nombre de tokens.

Le test de pression du contexte

Pour déterminer si une application tire profit d'un contexte plus étendu, testez la taille du contexte comme une variable expérimentale au lieu de présumer que plus grand équivaut à meilleur.

Ce qu'il faut mesurer au lieu du nombre de tokens

RAG : pourquoi augmenter le top-k peut nuire

Un schéma d'ajustement courant du RAG consiste à augmenter le top-k lorsque le système manque une réponse. Cela peut améliorer le rappel des candidats, mais aussi augmenter le contexte non pertinent, les preuves en double, les passages obsolètes et les documents contradictoires.

La vraie question est de savoir si la preuve décisive manque à la récupération ou si elle perd simplement de son influence après l'assemblage du contexte. Si le bon passage figure déjà dans l'ensemble des candidats, augmenter le top-k revient peut-être à résoudre le mauvais problème.

Agents à longue durée d'exécution : la continuité n'est pas l'accumulation

Un agent a besoin de continuité entre les étapes, mais la continuité n'exige pas de rejouer chaque token antérieur. OpenAI démontre l'élagage et la compression pour le contexte de sessions à longue durée d'exécution. Anthropic recommande le compactage, la prise de notes structurée et d'autres techniques pour préserver les informations utiles tout en limitant la pollution du contexte.

Une architecture robuste pour les agents à longue durée d'exécution sépare généralement la mémoire durable, l'état actuel, les artefacts externes, la récupération et le contexte présenté au modèle. Cela permet au système de préserver l'essentiel sans injecter de force chaque détail historique dans chaque inférence.

L'ordre du contexte doit être intentionnel

La construction du contexte relève de l'architecture de l'information. Les instructions critiques, l'état actuel, les preuves décisives et les contraintes spécifiques à la tâche ne doivent pas être placés arbitrairement. Lorsque les systèmes concatènent mécaniquement les sources, ils délèguent implicitement la priorisation aux effets de position et à l'attention du modèle.

Il n'existe pas d'ordre universel optimal pour tous les modèles et toutes les tâches ; l'ordonnancement doit donc être évalué empiriquement. Une suite de tests pertinente randomise ou fait varier systématiquement la position des documents et mesure si la même affirmation reste stable.

Préserver les limites de décision lors du compactage

Un résumé qui indique « utiliser l'approche X » est plus faible qu'un résumé qui conserve la raison pour laquelle X a été choisi et ce qui invaliderait cette décision. Le compactage de contexte doit conserver les variables susceptibles de modifier la réponse : version, date, hypothèses, état, autorité, désaccord non résolu et provenance des preuves.

Cela relie directement l'ingénierie de contexte à la validité des réponses. Si le compactage préserve une conclusion mais supprime ses limites de validité, les réponses futures peuvent demeurer cohérentes en interne tout en devenant factuellement erronées.

Une politique pratique de construction du contexte

• Partir de la tâche en cours, et non de tout ce que le système sait.
• Relire l'état volatile auprès des systèmes de référence avant de prendre des décisions conséquentes.
• Récupérer des preuves pour la question en cours plutôt que de véhiculer de volumineux corpus statiques.
• Supprimer les sorties d'outils redondantes ou à faible valeur ajoutée.
• Conserver la version source, l'horodatage, l'autorité et la provenance avec les preuves importantes.
• Rendre la priorité explicite en cas de conflit entre informations actuelles et historiques.
• Préserver les règles avec leurs exceptions et leurs prérequis.
• Stocker les décisions pérennes et les procédures réutilisables en dehors du contexte immédiat lorsqu'elles ne nécessitent pas de reproduction intégrale.
• Ne compacter l'historique qu'avec des tests de rétention des contraintes, identifiants, exceptions et provenances.
• Évaluer la taille, l'ordre et le bruit du contexte par des essais répétés plutôt qu'avec un prompt unique.

Qu'est-ce qui changerait cette réponse ?

Le compromis évolue en fonction de l'architecture du modèle, de son entraînement, du type de tâche et de la longueur du contexte. Les futurs modèles pourraient devenir nettement plus robustes face à la position, au bruit et aux informations contradictoires. Une tâche s'appuyant sur un corpus restreint et propre peut également tirer profit de la simple fourniture de la source complète plutôt que de l'élaboration d'un pipeline de récupération complexe.

La recommandation change également lorsque l'omission est plus préjudiciable que le bruit. Dans les tâches de recherche ou d'exploration à haut rappel, un contexte de candidats plus étendu peut être justifié avant une étape ultérieure de filtrage ou de synthèse. Dans les systèmes de production sensibles à la latence, une sélection de contexte plus stricte est souvent préférable.

Le principe fondamental ne changerait que si les modèles devenaient systématiquement insensibles aux informations non pertinentes, à la position, aux contradictions et aux données obsolètes. D'ici là, le contexte doit être traité comme une ressource d'exécution minutieusement organisée plutôt que comme un stockage passif.

Limites

Le comportement en contexte long varie considérablement selon les modèles et les charges de travail. Les expériences initiales de « Lost in the Middle » ont utilisé des générations antérieures de modèles ; l'ampleur exacte de leurs effets ne doit donc pas être présumée représentative des systèmes actuels. Cette observation demeure utile en tant que schéma de défaillance à tester, et non comme une courbe de performance fixe et universelle.

De même, réduire le contexte peut éliminer des éléments de preuve essentiels. Le compactage introduit un risque lié au résumé, et un filtrage agressif lors de la récupération peut faire baisser le rappel. L'objectif n'est pas d'atteindre un nombre minimal de jetons à tout prix, mais de fournir un contexte suffisant, à jour et traçable pour éclairer la décision à prendre.

Conclusion

La question « Quelle quantité de contexte le modèle peut-il accepter ? » est moins pertinente que « Dans quelle mesure ce contexte améliore-t-il la décision ? ». Davantage de jetons peuvent apporter des preuves supplémentaires, mais ils peuvent aussi introduire de la distraction, des contradictions, des états obsolètes, une fragilité positionnelle et une dette de compression.

Envisagez le contexte comme un ensemble de travail soigneusement conçu. Commencez avec le minimum de preuves suffisantes. N'ajoutez des informations que lorsqu'elles améliorent les performances mesurées. Évaluez explicitement le bruit, les conflits, l'agencement et le compactage. Une grande fenêtre de contexte relève de la capacité ; la qualité du contexte relève de l'architecture.

FAQ

Glossaire

Sources principales et lectures complémentaires