Tree RAG : quand découper un document détruit son sens

Il existe une façon standard de brancher un modèle de langage sur vos documents. Elle tient en trois étapes, elle est bien outillée, elle se met en place en une journée, et elle produit des résultats corrects sur la plupart des corpus. Sur une norme technique, elle produit des réponses fausses qui ont l’air justes.

Voici pourquoi, et ce que nous faisons à la place.

Comment marche un RAG classique

RAG signifie retrieval-augmented generation : au lieu de demander au modèle ce qu’il sait, on va d’abord chercher les passages pertinents dans vos documents, puis on les lui donne à lire avant qu’il réponde. Le procédé standard fonctionne ainsi.

On découpe. Chaque document est coupé en blocs d’une taille fixe, typiquement quelques centaines à quelques milliers de caractères, souvent avec un chevauchement entre blocs voisins pour ne pas couper une phrase en deux.

On encode. Chaque bloc est transformé en vecteur, une liste de nombres qui représente son sens. Deux textes qui parlent de la même chose ont des vecteurs proches, même s’ils n’emploient pas les mêmes mots.

On cherche. La question de l’utilisateur est encodée de la même façon, et le système renvoie les blocs dont le vecteur en est le plus proche. Ces blocs partent dans le prompt, le modèle rédige sa réponse à partir d’eux.

Le résultat est souvent bon, et il faut le dire clairement : pour une base de connaissances interne, des comptes rendus, des fiches produit ou des articles, cette méthode suffit largement et rien ne justifie de construire autre chose. C’est d’ailleurs l’un des cas d’usage que nous voyons le plus souvent produire un retour réel dans une PME.

Ce que le découpage jette

Le problème apparaît dès que le document a une structure qui porte du sens.

Prenez un article de norme. Il vit dans une section, elle-même dans un chapitre, lui-même dans un domaine d’application défini au début du document. Cet emboîtement n’est pas de la mise en page : il dit à quoi l’article s’applique, dans quelles conditions, et avec quelles exceptions. Un article de deux lignes peut dépendre d’une définition posée cent pages plus haut et d’une restriction posée dans le titre de son chapitre.

Le découpage en blocs de taille fixe ignore tout ça. Il produit un bloc contenant le texte de l’article, sans son chapitre, sans son domaine d’application, sans les renvois qui le nuancent. La recherche vectorielle retrouvera ce bloc parfaitement, parce qu’il ressemble beaucoup à la question posée. Et le modèle répondra avec assurance en s’appuyant sur un extrait amputé de ce qui permettait de l’interpréter.

Un passage juste sorti de son domaine d’application est un passage faux. C’est la phrase qui résume tout le problème, et c’est aussi ce qui distingue un corpus normatif d’un corpus documentaire ordinaire. Sur un article de blog, un extrait hors contexte est au pire imprécis. Sur une norme, il est susceptible d’engager la responsabilité de celui qui l’a suivi.

Le second effet : la question qui ne ressemble à rien

Il y a un piège de plus, moins discuté. La recherche vectorielle trouve ce qui ressemble à la question. Or dans un corpus normatif, la bonne réponse ne ressemble souvent pas du tout à la question.

Quelqu’un demande si une disposition s’applique à son cas. La réponse se trouve dans un article d’exclusion, situé dans un tout autre chapitre, rédigé dans une formulation négative qui n’a lexicalement rien de commun avec sa question. Une recherche par similarité passe à côté, et elle passe à côté silencieusement : elle renvoie quand même trois blocs, plausibles, et le modèle rédige avec.

Une absence de résultat serait un signal. Un mauvais résultat n’en est pas un.

Garder l’arbre

L’alternative consiste à ne pas aplatir le document. Nous conservons son arborescence telle qu’elle est, chapitre par section par article, et nous indexons chaque nœud avec le chemin complet qui y mène.

Ce que ça change, concrètement :

• Un article n’est jamais renvoyé seul. Il arrive avec les nœuds dont il dépend, ce qui rend son domaine d’application visible dans la réponse.
• La recherche peut descendre l’arbre au lieu de comparer des blocs isolés, en partant du domaine concerné pour arriver à la disposition précise.
• Les renvois entre articles sont des liens dans une structure, pas des chaînes de caractères que le découpage a laissées derrière lui.
• Une réponse peut citer sa position exacte dans le document, ce qui permet à un professionnel d’aller vérifier. C’est la seule forme de citation qui vaut quelque chose dans ce métier.

Cette approche est plus lente à construire. Elle demande d’ingérer correctement des documents dont la structure n’est pas toujours propre, et de décider à quel niveau de granularité on s’arrête. Ce n’est pas un choix de bibliothèque, c’est un travail de modélisation, au même titre que le schéma de données d’une application métier.

Le cas qui nous a menés là

Nous avons construit ça pour Stratta, qui voulait que ses ingénieurs interrogent leurs normes techniques en langage courant, depuis l’outil qu’ils utilisaient déjà.

La recherche vectorielle classique aurait été plus rapide à écrire. Nous avons indexé les normes en conservant leur arborescence, puis exposé le tout par un serveur MCP, ce qui permet à l’ingénieur de poser sa question dans son assistant habituel et de recevoir l’article avec le contexte dont il dépend.

Une contrainte s’est révélée aussi structurante que l’indexation : chaque bureau ne doit voir que les normes qu’il a licenciées. C’est la règle la plus testée du projet, et elle se vérifie par la négative. Demander la norme d’une autre organisation ne doit rien renvoyer, jamais, par aucun chemin détourné.

Comment savoir si vos documents sont concernés

Un test simple, qui ne demande aucun outil. Prenez un paragraphe au hasard dans votre corpus, recopiez-le seul sur une page blanche, et donnez-le à quelqu’un du métier sans lui dire d’où il vient.

S’il peut l’interpréter correctement, un RAG classique suffira. S’il vous répond « ça dépend de quel chapitre ça sort », vous avez un corpus hiérarchisé, et le découpage standard vous fera des réponses fausses.

Les corpus concernés sont plus nombreux qu’on ne croit : normes et directives techniques, règlements communaux et cantonaux, contrats-cadres avec leurs annexes, conventions collectives, référentiels qualité. Tout ce qui a été écrit pour être appliqué plutôt que pour être lu.

Quand ne pas le faire

Nous finissons par là parce que c’est ce qu’on nous demande le moins souvent et ce qui compte le plus.

Si votre corpus tient en quelques dizaines de pages, un modèle peut le lire en entier à chaque question et il n’y a aucune raison d’indexer quoi que ce soit. Si vos documents sont plats, un RAG standard fera l’affaire pour une fraction du coût. Et si personne n’a encore essayé de poser ses questions avec les outils du commerce, c’est par là qu’il faut commencer : nous l’avons écrit dans l’article sur la rédaction de rapports, une bonne partie des besoins se règle sans rien construire.

Le développement commence là où les outils du commerce butent. Pas avant. C’est aussi pour ça que notre accompagnement démarre par une demi-journée d’observation plutôt que par un devis : nous préférons découvrir sur place qu’il n’y a rien à construire. Si vous avez un corpus qui vous pose ce problème, parlons-en.