Fenêtre de contexte : pourquoi donner tout le dossier au modèle peut réduire la qualité

Ce qu’il faut retenir

• La taille maximale d’une fenêtre de contexte décrit une capacité d’entrée ; elle ne garantit ni que le modèle retrouvera chaque information, ni qu’il accordera le bon poids aux pièces pertinentes.
• Un dossier complet mélange preuves, doublons, versions, correspondances et éléments sans rapport avec la question. Le transmettre tel quel augmente le travail de discrimination confié au modèle.
• Le bon objet de conception est un paquet de contexte propre à la question : instructions, faits structurés, extraits probants, provenance, contradictions et budget de réponse.
• Quatre tests révèlent les fragilités du contexte long : déplacer la preuve, ajouter des distracteurs, injecter une version contradictoire et dépasser volontairement le budget.
• Contexte et mémoire ne sont pas synonymes. Une fenêtre concerne une exécution ; la conservation entre deux interactions exige une politique distincte de sélection, durée, droits et effacement.

Une capacité technique n’est pas un budget de preuve

La fenêtre de contexte est la quantité maximale d’unités que le modèle peut recevoir et produire au cours d’une exécution, selon l’interface et le modèle utilisés. Elle peut contenir les instructions, la question, l’historique conservé, des extraits documentaires, des données structurées et la place réservée à la réponse. Remplir cette capacité n’est pas un objectif.

La recherche sur le contexte long invite précisément à distinguer longueur acceptée et information effectivement utilisée. Dans Lost in the Middle, les auteurs observent, sur les tâches et modèles évalués, une performance sensible à la position de l’information pertinente, souvent meilleure lorsque celle-ci se trouve au début ou à la fin. LongBench évalue pour sa part plusieurs catégories de tâches longues plutôt qu’une simple capacité de rappel. Ces résultats ne prouvent pas que tout contexte long dégrade toute réponse ; ils montrent qu’une taille annoncée ne suffit pas à qualifier l’usage réel.

Dans un dossier assurance, la difficulté est accrue par la nature des pièces : scans, courriels en chaîne, tableaux, courriers reprenant des faits antérieurs, versions successives, documents d’identité, expertises et notes internes. L’archive répond à un besoin de conservation. Le contexte répond à une question immédiate. Confondre les deux revient à demander au modèle de reconstituer seul le périmètre, la chronologie, les droits et la hiérarchie des preuves.

Composer le contexte par fonction

Un contexte fiable se construit comme un paquet versionné. Chaque bloc possède une fonction et une règle d’inclusion. Cette discipline permet de comprendre une erreur : pièce manquante, ordre défavorable, version incorrecte, instruction ambiguë ou génération non soutenue.

Bloc	Contenu	Règle d’inclusion	Risque à contrôler
Contrat de tâche	Question, sortie attendue, limites et comportement d’abstention	Toujours présent, court et séparé des documents	Objectif flou ou décision implicite
Faits structurés	Dates, identifiants, type de pièce et chronologie déjà validée	Seulement les champs nécessaires, avec origine	Valeur périmée ou déduite sans preuve
Extraits probants	Passages sélectionnés pour la question	Chaque extrait porte document, version, page et droits	Passage hors contexte ou mauvais avenant
Contradictions	Pièces ou passages qui ne racontent pas la même chose	Conservés explicitement au lieu d’être fusionnés	Synthèse artificiellement cohérente
Budget de sortie	Format, champs, citations et place réservée à la réponse	Fixé avant de remplir les extraits	Contexte saturé ou réponse tronquée

Le paquet ne doit pas effacer la provenance. Une chronologie produite en amont peut accélérer la lecture, mais chaque événement conserve un lien vers sa pièce. Une synthèse antérieure est une aide, pas une source primaire ; si elle entre dans le contexte, son statut doit être visible afin que le modèle ne la traite pas comme un fait indépendant.

L’ordre est une hypothèse à tester

Placer les instructions, la question, les preuves et les contradictions dans un ordre fixe facilite la reproductibilité, mais aucun ordre ne doit être déclaré optimal sans test. La bonne recette permute les mêmes informations et vérifie si la conclusion, les citations et l’abstention restent stables. Une réponse qui change parce qu’une pièce probante passe du début au milieu du contexte révèle une dépendance que le score moyen d’exactitude ne montre pas.

Compresser sans faire disparaître la preuve

La compression peut prendre plusieurs formes : retirer les signatures répétées d’une chaîne de courriels, dédupliquer des pièces identiques, extraire un tableau, construire une chronologie ou résumer un long document. Chaque transformation a un coût d’information. Elle doit donc conserver la version originale, enregistrer sa méthode et permettre une comparaison ponctuelle avec le document source.

Pour une question étroite, la récupération d’extraits peut être préférable à un résumé global. Pour une question de chronologie, une structure datée peut être plus utile qu’une sélection de paragraphes isolés. Il n’existe pas un format de contexte unique : le format découle de la décision à préparer.

Scénario assurance : trois questions, trois contextes

Scénario pédagogique, sans dossier client réel. Une équipe souhaite aider un gestionnaire à parcourir un dossier corporel volumineux. L’archive comprend des pièces médicales, des courriers, des rapports, des échanges et des versions successives de documents. Le système ne prend aucune décision d’indemnisation ; il prépare des vues vérifiables pour un professionnel habilité.

Question 1 : « Quels événements structurent la chronologie ? »

Le contexte privilégie les dates explicites, le type de pièce, l’auteur, les événements et les liens vers les pages sources. Les doublons sont signalés. Une date mentionnée dans un courrier ultérieur n’est pas automatiquement traitée comme équivalente à la pièce originale. La sortie attendue est une chronologie avec niveaux de confiance et points à confirmer.

Question 2 : « Quelle pièce soutient cette affirmation ? »

Le contexte se resserre autour de l’affirmation, de ses variantes lexicales et des passages susceptibles de la confirmer ou de la contredire. Il inclut davantage de texte autour de chaque occurrence pour éviter une citation sortie de son contexte. La sortie attendue distingue soutien direct, soutien partiel, contradiction et absence de preuve.

Question 3 : « Que manque-t-il pour poursuivre la revue ? »

Le contexte combine une liste déterministe des pièces attendues selon le processus concerné et les métadonnées des documents présents. Le modèle peut reformuler l’écart, mais il ne doit pas inventer une exigence. La sortie attendue renvoie à la règle qui justifie chaque pièce demandée et permet au gestionnaire de retirer une demande inadaptée.

Ces trois requêtes portent sur le même dossier, mais elles n’ont ni la même preuve ni le même format de sortie. Envoyer l’archive entière à chaque fois gaspille le budget et rend le diagnostic difficile. Composer trois paquets permet au contraire de tester précisément sélection, structure et attribution.

Quatre tests de robustesse propres au contexte long

1. Déplacer la preuve sans changer son contenu

Placer le même passage au début, au milieu puis à la fin, en conservant tous les autres éléments. Comparer conclusion, citation et formulation d’incertitude. Le but n’est pas d’imiter un benchmark académique, mais de vérifier la sensibilité du système sur les documents et modèles réellement envisagés.

2. Ajouter des distracteurs plausibles

Ajouter des passages proches par vocabulaire mais concernant un autre produit, une autre personne ou une autre étape du processus. La réponse doit rester fondée sur la bonne pièce. Ce test révèle si le paquet de contexte dépend trop du modèle et pas assez des métadonnées et filtres déterministes.

3. Introduire une version contradictoire

Présenter deux versions explicitement identifiées, dont l’une contredit l’autre. Le système doit signaler le conflit et utiliser les règles de version disponibles ; il ne doit ni fusionner les textes ni choisir silencieusement celui qui apparaît en dernier. Si la règle d’applicabilité manque, l’abstention est correcte.

4. Dépasser volontairement le budget

Ajouter des pièces jusqu’à atteindre la limite fixée pour le service, puis observer ce qui est retiré. La politique de réduction doit être déterministe et traçable : supprimer les doublons, préserver les preuves indispensables, réserver la place de sortie et refuser la requête si le noyau utile ne tient plus. Une troncature invisible en fin de chaîne est un échec.

Le benchmark LongBench Pro, publié en 2026, distingue notamment longueur, difficulté et dépendance partielle ou complète au contexte. Sans transposer ses résultats à un dossier assurance, cette taxonomie rappelle qu’un test de contexte long doit qualifier ce que la tâche exige réellement, pas seulement compter des unités d’entrée.

Quand transmettre davantage de dossier peut être justifié

Réduire systématiquement le contexte serait aussi simpliste que le remplir. Une tâche de synthèse globale, de détection de contradictions ou de construction chronologique peut dépendre d’une grande partie du dossier. La décision repose sur la structure de la question :

• si une preuve localisée suffit, sélectionner des extraits avec leur voisinage ;
• si plusieurs pièces doivent être croisées, composer un ensemble couvrant explicitement chaque sous-question ;
• si l’ensemble du dossier est nécessaire, segmenter la tâche, produire des résultats intermédiaires attribués puis effectuer une synthèse contrôlée ;
• si le système ne peut pas démontrer ce qu’il a omis, garder la sortie en assistance à la lecture et non en réponse autonome.

La récupération augmentée, formalisée notamment dans le travail fondateur sur le Retrieval-Augmented Generation, sépare récupération et génération. Cette séparation reste utile même avec une grande fenêtre : elle donne un point d’observation pour savoir quelles preuves ont été choisies et pourquoi. Le reranking et l’attribution des citations deviennent alors un sujet distinct de la capacité maximale du modèle.

Ne pas confondre contexte, historique et mémoire

La fenêtre de contexte existe pendant une requête. Un historique de conversation est une sélection de tours précédents réinjectée dans cette fenêtre. Une mémoire persistante ajoute encore une politique : quelles informations conserver, pour quelle finalité, combien de temps, avec quels droits, comment les corriger et comment les supprimer.

Dans l’assurance, réinjecter automatiquement une synthèse ancienne peut propager une erreur ou exposer une donnée qui n’est plus pertinente pour la nouvelle tâche. Chaque élément rappelé doit donc être traité comme une entrée versionnée, avec une provenance et une règle de validité. « Le modèle s’en souvient » n’est ni une exigence fonctionnelle ni une preuve de conformité.

Cette distinction aide aussi à tester : un défaut de réponse peut venir de la composition actuelle du contexte, d’un historique conversationnel ambigu ou d’une mémoire persistante incorrecte. Les trois mécanismes exigent des journaux et des voies de correction différents.

Mesurer qualité, coût et abstention

La recette compare le paquet composé à deux références : le traitement humain actuel et, lorsque c’est sûr, une variante contenant davantage de documents. Elle mesure au minimum :

• la présence des preuves attendues et des contradictions connues ;
• la stabilité de la réponse lorsque l’ordre change ;
• le taux d’affirmations sans soutien ou avec un mauvais document ;
• la pertinence des abstentions et des demandes de pièces ;
• les corrections humaines, ventilées par gravité et type de dossier ;
• la latence, le volume d’entrée et le coût complet par requête ;
• les incidents de droit d’accès, de version ou de troncature.

Le profil NIST AI 600-1 situe la mesure, la provenance et la gestion des risques sur tout le cycle de vie d’un système génératif. Pour ce cas d’usage, cela signifie conserver la version du modèle, la politique de sélection, les identifiants des pièces incluses, celles exclues pour cause de budget, les paramètres et l’issue humaine — dans le respect des règles de minimisation et de conservation applicables.

Le déploiement commence sur un périmètre où l’erreur est détectable et réversible. Le système peut fonctionner en parallèle de la revue sans influencer le dossier, puis en assistance avec validation obligatoire. L’extension dépend des erreurs réellement observées, pas de la seule capacité annoncée par le fournisseur.

Pour compléter la recette, les huit tests d’un RAG en assurance couvrent la chaîne de bout en bout, tandis que l’article sur le mécanisme d’attention aide à ne pas confondre signal interne du modèle et justification métier.

Sources et références

Sources primaires consultées le 12 août 2026. Les performances rapportées par les articles scientifiques dépendent de leurs modèles, jeux de données et protocoles ; elles ne sont pas extrapolées ici à un portefeuille assurance.

• Lost in the Middle: How Language Models Use Long Contexts — Liu et al., 2023.
• LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding — ACL 2024.
• LongBench Pro: A More Realistic and Comprehensive Bilingual Long-Context Evaluation Benchmark — Chen et al., 2026.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al., 2020.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST AI 600-1, publié en 2024 et page mise à jour en 2026.