Réduire un contexte RAG sans perdre la preuve utile

Le coût des contextes longs

Un système RAG récupère des documents avant de demander au modèle de produire une réponse. Plus le contexte est long, plus la latence, la mémoire de cache clé-valeur et le coût en tokens peuvent augmenter. La compression post-retrieval semble une solution naturelle, mais elle ajoute parfois un modèle auxiliaire ou un traitement par requête suffisamment lourd pour annuler une partie du gain.

REVA, pour Reusable Evidence View Aggregation, propose de déplacer une partie de ce travail hors de la requête courante. Le système exploite les interactions historiques entre requêtes, documents et modèle générateur pour construire des vues de preuves réutilisables.

Comment REVA organise les preuves

Le cadre décrit dans le preprint collecte les traces d’attention du générateur lors des accès aux documents. Ces scores au niveau des tokens sont transformés en unités de mots lisibles, puis agrégés lors des consultations répétées d’un même document. Le résultat est un magasin de scores indexé par document.

Le budget final n’est pas fixé au moment de l’agrégation. Une vue adaptée à une contrainte de longueur peut être rendue ensuite, en conservant l’ordre du document et l’interface RAG habituelle. Cette propriété permet de produire plusieurs budgets à partir d’un même travail historique, au lieu de recalculer une compression pour chaque requête.

Avant de l’adopter

REVA suppose que l’historique contient de l’information utile. Un corpus consulté une seule fois offrira moins de possibilités de réutilisation. Un corpus fréquemment mis à jour pose une autre question : quand un document change, ses scores historiques doivent-ils être invalidés, recalculés ou versionnés ? Une vue compressée ne doit jamais mélanger silencieusement deux versions d’une preuve.

Il faut également distinguer importance et suffisance. Un token souvent regardé par le générateur n’est pas nécessairement le détail indispensable à une question rare. Le guide de déploiement doit conserver des tests qui demandent des éléments périphériques : une date, une exception, une condition ou un chiffre particulier.

Résultats rapportés

Les auteurs indiquent que les compresseurs modernes ont des gains instables par rapport à une troncature simple et peuvent introduire une latence en ligne. Sur quatre benchmarks et plusieurs LLM, REVA améliorerait la qualité de génération de 1,0 à 5,8 points. Le surcoût de compression serait réduit d’un facteur 5,3 à 15,6, avec moins de 40 millisecondes de latence ajoutée dans le protocole décrit.

Ces chiffres sont des résultats rapportés par le preprint. Ils doivent être reproduits sur le corpus, le générateur et le trafic de l’équipe avant de justifier une migration. Une moyenne de benchmark peut cacher une baisse sur les questions qui exigent une preuve inhabituelle.

Un protocole d’évaluation

Conservez d’abord une ligne de base sans compression et une ligne de base avec troncature simple. Mesurez la qualité de réponse, le rappel des preuves, la latence de bout en bout, le coût et le taux d’abstention. Ajoutez des requêtes répétées pour estimer le bénéfice de la réutilisation, puis des requêtes nouvelles pour tester la robustesse.

Pour chaque réponse, vérifiez si les passages utilisés sont encore présents dans la vue rendue. Une réponse correcte par hasard ne doit pas être confondue avec une preuve suffisante. Lorsque la compression omet un élément critique, conservez le cas dans un jeu de régression plutôt que de modifier uniquement la moyenne.

Choisir les bons cas

Un jeu d’évaluation utile ne contient pas seulement des questions dont la réponse se trouve dans le premier paragraphe. Ajoutez des documents longs, des sections répétitives, des tableaux, des exceptions et des passages qui se contredisent entre versions. Une compression doit conserver l’élément qui tranche la question, même s’il est peu fréquent dans l’historique.

Les requêtes peuvent être classées par répétition. Les requêtes récurrentes permettent de mesurer le bénéfice principal de la réutilisation. Les requêtes nouvelles testent la capacité de la vue à rester utile lorsqu’elle n’a pas été optimisée pour une formulation précise. Une stratégie qui gagne sur les premières mais perd sur les secondes peut être acceptable pour une FAQ stable, mais pas pour un corpus exploratoire.

Fraîcheur et versionnement

Une preuve compressée doit être liée à la version du document, à la date de calcul et au modèle qui a produit les scores. Lorsqu’une politique ou une documentation change, les vues héritées doivent être invalidées ou recalculées. Le risque principal n’est pas seulement de perdre un détail, mais de conserver un détail ancien qui semble encore autoritatif.

Le versionnement aide aussi à expliquer une réponse. Si un utilisateur conteste une synthèse, l’équipe doit pouvoir retrouver le document source, la vue rendue et le budget appliqué. Sans cette chaîne, une compression rapide réduit le coût de calcul mais augmente le coût d’audit.

Déployer progressivement

Un déploiement prudent peut commencer en mode observation : générer la vue REVA en parallèle du contexte complet sans modifier la réponse affichée. Comparez les preuves conservées, la latence et les réponses. Ensuite, activez la compression sur un sous-ensemble de requêtes et conservez un mécanisme de retour au contexte complet lorsque le score de confiance ou la couverture de preuve est insuffisant.

Cette étape rend visible le vrai compromis. Une réduction de tokens n’est utile que si elle ne déplace pas le travail vers une revue humaine systématique. Mesurez donc le temps de correction et les demandes de reprise, pas seulement la durée de génération.

Questions de gouvernance

Une vue de preuve peut contenir des informations sensibles même si elle est plus courte que le document original. Les droits d’accès, la durée de conservation et la suppression doivent donc s’appliquer à la vue comme à la source. Les logs d’attention peuvent également révéler quelles parties d’un document ont été jugées importantes ; ils méritent la même prudence que les autres traces de traitement.

La provenance doit rester visible. Une réponse produite à partir d’une vue compressée devrait pouvoir pointer vers le document source et sa version. Si le système ne peut pas restituer cette relation, la compression a réduit la capacité d’audit. Dans un contexte juridique, médical ou financier, ce manque de traçabilité peut être plus coûteux que la latence économisée.

Quand revenir au contexte complet

Préparez un mécanisme de reprise. Il peut être déclenché par une question qui demande un élément absent, par une contradiction entre documents ou par une confiance insuffisante du générateur. Le système peut alors récupérer les passages complets, demander une reformulation ou signaler qu’il ne dispose pas d’une preuve suffisante.

Cette stratégie reconnaît qu’aucune compression ne peut être optimale pour toutes les requêtes. L’objectif réaliste est de réduire le coût des cas ordinaires tout en conservant une voie explicite vers les sources quand la question devient difficile.

Résumé opérationnel

REVA doit être lu comme une stratégie de réutilisation, pas comme une permission de supprimer les sources. Mesurez le bénéfice sur des requêtes répétées, vérifiez les cas rares, versionnez les documents et conservez une reprise vers le contexte complet. La compression est acceptable lorsque la preuve reste retrouvable et que le gain de latence ne déplace pas le coût vers une vérification humaine permanente.

Le résultat attendu doit être défini avant l’activation : moins de tokens, moins de latence, même qualité de preuve, ou un compromis explicite entre ces objectifs. Sans cette définition, une compression peut sembler réussie simplement parce qu’elle raccourcit le contexte, alors qu’elle augmente les omissions.

Critères de sortie

Une vue compressée est acceptable si sa provenance reste récupérable, si les cas de contrôle conservent les détails attendus et si le système sait revenir aux sources. Les seuils exacts dépendent du domaine, mais ils doivent être définis avant la comparaison. La décision ne doit pas reposer uniquement sur une baisse de coût.

Une revue humaine peut compléter cette décision sur un échantillon fixe. Elle doit vérifier les documents sources, les passages présents dans la vue et la réponse générée, sans connaître à l’avance quelle méthode a produit le contexte. Cette séparation réduit le risque de préférer une méthode simplement parce qu’elle paraît plus compacte ou plus élégante.

Le protocole devrait être répété après une mise à jour du générateur, de l’index ou de la politique de segmentation. Une vue calculée pour une version de modèle n’est pas nécessairement équivalente pour une autre. Documenter ces dépendances transforme une optimisation ponctuelle en composant gouvernable.

La règle finale est simple : compresser le contexte ne doit jamais supprimer la possibilité de revenir à la preuve.

Cette règle doit apparaître dans les critères de validation et dans la documentation du système, afin que la réduction de contexte reste une optimisation contrôlée plutôt qu’une perte silencieuse d’information.

La version du document source, le budget de contexte et le modèle générateur doivent rester associés à chaque vue compressée. Sans ce lien, une réponse ancienne peut sembler justifiée par une preuve qui a depuis changé.

Cette association facilite aussi l’audit des régressions. Lorsqu’une réponse évolue, l’équipe peut comparer le document original, la vue rendue et la sortie du générateur, puis déterminer si la cause vient de la source, de la compression ou du modèle. La latence gagnée ne doit jamais effacer cette chaîne de vérification.

Ce que l’étude ne prouve pas

Les résultats ne garantissent pas le même compromis sur un corpus sans répétition, des documents dynamiques ou un générateur différent. Une meilleure métrique de génération ne prouve pas l’absence d’omission de preuve critique. Le preprint ArXiv n’est pas nécessairement évalué par les pairs.

Sources

Tuan Nguyen, Qiran Hu, Banruo Liu, Khoa D. Doan, Kok-Seng Wong et coauteurs, « REVA: Reusable Evidence View Aggregation for Context-Efficient RAG Serving », ArXiv 2609.11209v1, consulté le 21 septembre 2026 : résumé et preprint, PDF.