Un système de RAG fonctionne bien sur des documents courts, des notices, des pages web. Il se complique dès que les documents sont longs : un manuel de plusieurs centaines de pages, un rapport annuel, une documentation technique complète. Découper simplement ces documents en segments de taille fixe produit des réponses partielles ou fausses.
Le problème de fond est qu’un long document contient une structure et des dépendances que le découpage naïf détruit : une définition donnée au début, un tableau repris plus loin, un chapitre qui s’appuie sur le précédent. Couper sans stratégie, c’est perdre ces liens.
Cet article décrit les techniques qui permettent de gérer les documents volumineux : l’indexation hiérarchique, le découpage parent-enfant, les résumés intermédiaires, et le traitement des contenus non textuels. Vous pourrez les appliquer à vos propres corpus.
Pourquoi un long document casse le découpage classique
Le découpage classique produit des segments de taille homogène, indépendants les uns des autres. Cela suppose que chaque segment contient une information autonome. Or dans un long document, l’information est répartie : une notion est définie au chapitre un et utilisée au chapitre cinq.
Quand on découpe ce document en segments uniformes, on obtient des fragments qui perdent leur contexte. Un segment du chapitre cinq, sans la définition du chapitre un, devient ambigu ou faux pour le modèle. La réponse du système en hérite : elle est plausible sur le fragment, mais fausse sur le document.
Le second problème est la taille : un long document génère des centaines de segments, et la récupération doit alors choisir parmi beaucoup de candidats. Plus le nombre de segments croît, plus le risque de ramener un mauvais passage augmente, surtout si les segments se ressemblent.
L’indexation hiérarchique
La première réponse consiste à conserver la structure du document au lieu de l’aplatir. On indexe le document à plusieurs niveaux : les sections, puis les sous-sections, puis les paragraphes. La requête navigue d’abord au niveau de la section, puis descend vers le passage précis.
Cette hiérarchie apporte deux bénéfices. Elle réduit le bruit, car la récupération ne compare la requête qu’aux segments du bon niveau ou de la bonne section. Elle conserve le contexte, car chaque segment est rattaché à sa section, et l’on peut remonter cette section au modèle en complément.
Concrètement, cela se traduit par une indexation qui garde, pour chaque segment, son chemin dans le document, et une récupération qui utilise ce chemin pour filtrer. Le surcoût est modeste, le gain de précision est réel sur les corpus longs.
Le découpage parent-enfant
Une technique proche consiste à découper le document à deux tailles : de grands segments parents, qui gardent le contexte, et de petits segments enfants, qui servent à la recherche. La requête retrouve un petit segment, et c’est le grand segment parent qui est envoyé au modèle.
L’intérêt est de séparer les deux exigences contradictoires du découpage : la recherche veut des segments petits et précis, la génération veut un contexte large et complet. Le parent-enfant donne à chaque étape ce dont elle a besoin.
Cette technique est particulièrement efficace sur les documents techniques, où la réponse dépend d’un passage précis mais aussi de ce qui l’entoure. Elle a un coût, une indexation plus lourde, mais c’est un des meilleurs compromis qualité sur les corpus longs.
Les résumés comme index intermédiaire
Une autre approche consiste à faire produire par un modèle un résumé de chaque section, et à indexer ces résumés plutôt que le texte brut. La requête retrouve le résumé pertinent, puis le système charge la section complète correspondante.
Le résumé agit comme un index sémantique : il condense ce que la section contient, ce qui améliore la correspondance avec une requête formulée en langage naturel. Un utilisateur qui demande « comment configurer les permissions » retrouve plus sûrement la section dont le résumé dit exactement cela.
Le coût est celui de la génération des résumés, qui se fait une fois à l’indexation, pas à chaque requête. Pour des corpus volumineux et stables, c’est un coût unique qui améliore durablement la récupération. Il se combine d’ailleurs bien avec les techniques précédentes.
Tableaux, images et contenus non textuels
Les documents volumineux ne contiennent pas que du texte. Ils contiennent des tableaux, des schémas, des captures, parfois des formules. Un découpage qui ne traite que le texte perd ces contenus, et avec eux une partie des réponses possibles.
Pour les tableaux, la bonne pratique est de les extraire dans un format structuré, qui conserve les lignes et les en-têtes, plutôt que de les écraser en texte brut. Un tableau structuré reste interprétable par le modèle, un tableau écrasé devient un amas de chiffres sans signification.
Pour les images et schémas, deux voies existent : les décrire par un modèle qui produit un texte d’indexation, ou les intégrer directement si le modèle est multimodal. La première est plus simple et suffit souvent ; la seconde est plus fidèle mais plus coûteuse. Le choix dépend du poids de ces contenus dans vos réponses.
Maîtriser le coût sur de gros volumes
Gérer des documents volumineux coûte plus cher, à tous les étages : l’indexation, les résumés, la récupération, la génération. Sans maîtrise, le coût par requête peut exploser en même temps que la qualité s’améliore, et annuler le bénéfice.
La maîtrise passe par trois leviers. Le premier est de ne générer les contenus coûteux, les résumés, les descriptions d’images, qu’une fois, à l’indexation, et de les réutiliser. Le second est de borner ce que l’on charge à chaque requête : un parent, une section, pas le document entier. Le troisième est de choisir le modèle en fonction de la tâche, un modèle léger pour la récupération, un modèle plus fort pour la réponse.
La règle reste la même que partout : mesurer le coût par requête et la qualité, et ajuster. Un RAG sur documents volumineux se pilote par ces deux chiffres, pas par une configuration figée.
L’accompagnement Agenticiel pour gérer vos documents volumineux
Mettre en place un RAG sur des documents volumineux demande de choisir et de combiner ces techniques, puis de valider chaque choix par la mesure. C’est un travail d’ingénierie que nous menons pour des équipes qui veulent interroger leur documentation complète sans sacrifier la qualité.
Agenticiel intervient comme sous-traitant de développement : analyse du corpus, choix de la stratégie d’indexation, mise en place du parent-enfant ou des résumés, validation sur un jeu d’évaluation. L’équipe est composée de développeurs offshore francophones basés à Madagascar, ce qui réduit le coût du chantier tout en conservant une communication directe, dans votre langue et sur votre fuseau.
Notre approche consiste à traiter le document volumineux comme un problème de structure et de coût : on préserve la hiérarchie, on sépare la recherche du contexte, et on maîtrise le coût pour que la qualité gagnée ne soit pas annulée par la facture.