Long contexte et hallucinations : ce que les nouvelles études imposent de revoir dans les architectures RAG

La semaine du 31 mars au 6 avril a vu converger deux publications sur un même diagnostic : les modèles de langage hallucinant davantage à mesure que la taille du contexte augmente, et ces hallucinations seraient en partie inhérentes à leur architecture. L’une est une étude empirique à très grande échelle sur des tâches de type question-réponse documentaire. L’autre identifie les mécanismes neuronaux à l’origine du phénomène, et conclut qu’ils naissent lors du pré-entraînement et non lors du fine-tuning. Pris ensemble, ces travaux ne remettent pas en cause l’utilité des LLM dans les processus métier — mais ils imposent de réviser certaines hypothèses sur lesquelles reposent nombre d’architectures RAG actuelles.

Pour les équipes qui conçoivent ou font évoluer des systèmes RAG en production, le signal est actionnable immédiatement : les paramètres de sélection de contexte, les stratégies de découpage, et les mécanismes de contrôle de cohérence post-génération méritent d’être réexaminés à la lumière de ces résultats — en particulier dans les environnements où la fiabilité factuelle a des conséquences réglementaires ou contractuelles.

Ce que mesure l’étude Kamiwaza AI : la dégradation chiffrée selon la longueur du contexte

JV Roig, chercheur en IA agentique à la startup Kamiwaza AI, a publié en mars 2026 une étude portant sur 172 milliards de tokens d’évaluation, couvrant 35 modèles open-weight, trois longueurs de contexte (32K, 128K et 200K tokens), quatre températures et trois plateformes matérielles (NVIDIA H200, AMD MI300X et Intel Gaudi 3). La méthodologie RIKER utilisée repose sur une inversion de paradigme : les documents de test sont générés à partir de vérités connues plutôt que l’inverse, ce qui permet un scoring déterministe sans annotation humaine ni juge LLM. (Source : arxiv.org — RIKER 172B Token Study)

Les résultats sont gradués et sans ambiguïté sur la tendance. À 32 000 tokens de contexte, le meilleur modèle testé — GLM 4.5 de Zhipu AI — hallucine dans 1,2 % des cas ; la moyenne des modèles se situe à 6,8 %. Quand le contexte est porté à 128 000 tokens, le taux d’erreur du meilleur modèle monte à 3,2 %, et la moyenne passe à 10 %. Au-delà de 200 000 tokens, les taux s’envolent pour tous les modèles testés. L’étude note également que les fenêtres de contexte annoncées par les fournisseurs dépassent fréquemment la capacité utilisable réellement efficace — un écart documenté dans plusieurs travaux antérieurs sur le phénomène dit du « contexte perdu au milieu », où les modèles tendent à mieux traiter les informations placées en début et en fin de contexte qu’en son centre.

Le cadrage de l’étude est intentionnellement orienté vers les cas d’usage enterprise : une base de connaissances chargée dans le contexte d’un agent de support client, d’un assistant juridique ou d’un outil de traitement documentaire est précisément le type de scénario modélisé par la méthodologie RIKER. Le constat est que ces déploiements courent structurellement un risque d’hallucination plus élevé que ce que laissent supposer les benchmarks standard, dès lors que la taille du contexte dépasse les 32 000 tokens.

Ce que révèle l’étude sur les H-Neurons : une origine liée à l’objectif d’entraînement

Parallèlement, une équipe de l’université Tsinghua a publié en décembre 2025 une étude sur ce qu’elle nomme les « H-Neurons » — un ensemble de neurones représentant moins de 0,1 % du total d’un LLM, mais dont l’activation précède systématiquement la génération de contenus hallucinés. L’analyse de leur comportement révèle qu’ils n’encodent pas l’incertitude : ils encodent une tendance à fournir une réponse satisfaisante pour l’utilisateur, même en l’absence d’information fiable en interne. Ce mécanisme, qualifié de « sur-compliance », pousse le modèle vers la plausibilité plutôt que vers la précision factuelle. (Source : arxiv.org — H-Neurons)

La conclusion la plus importante pour les architectes de systèmes est que ces neurones émergent lors du pré-entraînement, et non lors du fine-tuning ou de l’alignement RLHF. Cela signifie qu’ils ne peuvent pas être corrigés en modifiant uniquement la phase d’instruction-tuning. Les chercheurs concluent que des stratégies d’atténuation nécessitant une modification profonde de l’objectif d’entraînement seraient nécessaires pour réduire le phénomène à sa source — et ces modifications impliquent probablement de développer d’autres types d’architectures, comme des modèles ancrés dans une représentation du monde réel. Ces approches alternatives sont considérées comme plusieurs années en amont de l’état de l’art actuel.

La nuance importante est que cette étude ne dit pas que les LLM sont inutilisables. Elle dit que leur tendance à halluciner est une propriété émergente de leur objectif de prédiction du token suivant, et que cette propriété s’amplifie avec la longueur du contexte — ce qui rejoint les mesures empiriques de Kamiwaza AI. Pour les cas d’usage où la fiabilité est non négociable, la conséquence pratique est que l’architecture externe — RAG, contrôle de cohérence, mécanismes de validation — reste le levier disponible à court terme.

Les implications concrètes pour le design des systèmes RAG

Ces deux publications, combinées, remettent en question une hypothèse implicite dans de nombreux projets : celle selon laquelle l’élargissement de la fenêtre de contexte compenserait des lacunes de conception du pipeline de récupération. Les données disponibles suggèrent l’inverse — fournir plus de contexte sans sélection rigoureuse augmente le risque d’erreur, pas la fiabilité.

Plusieurs ajustements architecturaux découlent directement de ces constats. Le premier concerne la taille du contexte assemblé : maintenir le contexte injecté dans le LLM sous un seuil strict — plusieurs praticiens évoquent 8 000 tokens comme plafond de départ pour la majorité des requêtes — et augmenter la précision du retrieval plutôt que sa couverture. Un seuil de pertinence plus agressif lors du reranking réduit le volume injecté sans nécessairement dégrader la qualité de la réponse, et souvent l’améliore.

Le deuxième ajustement porte sur la stratégie de découpage. Des chunks trop larges introduisent du bruit et amplifient l’effet « perdu au milieu ». Des chunks trop petits fragmentent le contexte sémantique et forcent le modèle à inférer des liaisons qu’il n’a pas. Le chunking sémantique — qui segmente selon la cohérence de sens plutôt que selon un nombre fixe de tokens — s’impose comme approche de référence pour les cas d’usage enterprise nécessitant une haute précision factuelle.

Le troisième ajustement concerne les mécanismes de post-vérification. Dès lors que les hallucinations ne peuvent être supprimées à la source par les modèles eux-mêmes, les pipelines de production ont intérêt à intégrer une étape de vérification de la fidélité des réponses — un composant qui mesure si chaque affirmation de la réponse est étayée par un passage effectivement présent dans le contexte récupéré. Ce type de contrôle est particulièrement critique dans les environnements réglementés (finance, santé, juridique) où une hallucination présentée avec confiance peut engager la responsabilité de l’organisation.

Enfin, ces résultats orientent le débat « long contexte versus RAG » dans un sens plus tranché que ce que les annonces de fenêtres géantes pourraient laisser penser. Un benchmark conduit par une banque européenne en 2025, cité dans des retours d’expérience sectoriels, illustre la logique : une approche par injection de contexte long était 34 % plus précise sur des requêtes simples, mais l’approche RAG était 67 % plus précise sur des requêtes de synthèse multi-documents — avec une latence huit fois plus faible et un coût 94 % inférieur. Le choix d’architecture doit donc être piloté par le type de requête dominant, pas uniquement par la taille du contexte disponible.

Ce que cela change pour les entreprises

Le signal le plus direct concerne les projets actuellement en production ou en cours de déploiement qui s’appuient sur des contextes longs pour compenser un retrieval insuffisamment précis. La dégradation documentée commence à partir de 32 000 tokens, et elle est non linéaire : le saut entre 128 000 et 200 000 tokens est significativement plus prononcé que celui entre 32 000 et 128 000. Pour les systèmes de support client, d’assistance juridique ou d’analyse documentaire où la base de connaissance est chargée intégralement ou en grande partie dans le contexte, le risque d’hallucination est probablement sous-estimé si aucune mesure de fidélité n’a été mise en place.

Les projets en conception ont une opportunité de bâtir ces garde-fous dès l’architecture initiale. Les indicateurs clés à instrumenter sont la fidélité (chaque affirmation de la réponse est-elle ancrée dans un passage récupéré ?), la précision du retrieval (les chunks retournés sont-ils ceux qui contiennent réellement l’information nécessaire ?) et le taux de refus approprié (le système sait-il reconnaître qu’il n’a pas l’information, plutôt que d’en fabriquer une ?). Dans les environnements réglementés, ce dernier point est particulièrement critique : un modèle qui dit « je ne sais pas » est préférable à un modèle qui répond avec assurance sur une base incorrecte.

Pour les organisations dont les projets IA impliquent des contextes très longs — analyse de contrats, traitement de dossiers complets, agents sur de grandes bases documentaires — ces publications constituent un argument supplémentaire pour maintenir une supervision humaine sur les décisions à conséquences significatives, et pour prioriser les architectures permettant la traçabilité du raisonnement jusqu’aux passages sources.

Ce que cela met à jour dans la Méthode Virtuose

Le chapitre 3 (Long contexte et RAG robuste) gagne en substance sur deux points. D’abord, la section 3.1 (La révolution du contexte long) doit désormais intégrer la nuance empirique que la capacité annoncée d’une fenêtre de contexte ne correspond pas à sa capacité efficace réelle — et que cette capacité effective décroît de manière mesurable au-delà de 32K tokens sur les tâches de récupération d’information documentaire. Ensuite, la section 3.6 (Évaluation de la qualité : exactitude, couverture, citations et ancrage) peut s’appuyer sur les métriques issues des méthodologies RIKER et RAGAS pour documenter les seuils de contrôle de fidélité recommandés en production. Le principe H-Neurons — hallucinations émergentes lors du pré-entraînement, non corrigeables par le fine-tuning — renforce également l’argument en faveur des architectures hybrides (RAG + validation externe) documentées dans le chapitre 6 (Architecture et LLMOps).

Le vrai effet de ces publications n’est pas de disqualifier les LLM ni de freiner les projets RAG — il est de déplacer le débat d’une question de capacité (le modèle peut-il traiter 200K tokens ?) vers une question de fiabilité opérationnelle (à quelle longueur de contexte le taux d’erreur devient-il inacceptable pour ce cas d’usage précis ?). C’est cette question, et non la taille de la fenêtre, qui devrait piloter les choix d’architecture.