RAG : faire répondre un modèle à partir de vos documents

Un modèle de langage a lu beaucoup de texte pendant son entraînement, mais il n’a pas lu vos documents : votre documentation interne, vos contrats, vos articles de blog, la base de connaissances de votre support. Il ne sait pas non plus ce qui a changé la semaine dernière. Si vous lui posez une question sur ces sujets, il répondra quand même, avec l’assurance habituelle, et il inventera ce qu’il ne sait pas.

Le RAG, pour retrieval-augmented generation, est la réponse la plus courante à ce problème. Le principe tient en une phrase : avant de poser la question au modèle, on retrouve dans vos documents les passages les plus pertinents et on les place dans la consigne. Le modèle ne répond plus de mémoire, il répond en s’appuyant sur un texte qu’on lui montre.

Pourquoi pas simplement entraîner le modèle sur vos documents ?

On peut affiner un modèle sur des données propres, mais ce n’est pas le bon outil pour y injecter des faits. L’affinage change surtout le style et le comportement, il est coûteux à refaire à chaque mise à jour des documents, et il ne permet pas de dire d’où vient une information. Avec le RAG, mettre à jour une connaissance revient à mettre à jour un document, et chaque réponse peut pointer vers sa source.

Les quatre étapes d’un système RAG

Tout système RAG, du prototype à la plateforme, se décompose en quatre étapes.

1. Ingestion. On extrait le texte de chaque document (PDF, pages web, fichiers Office, tickets) et on le nettoie : suppression des en-têtes et pieds de page répétés, des menus, des artefacts de mise en page.
2. Découpage. On coupe le texte en passages, appelés chunks, de taille raisonnable.
3. Indexation. Chaque passage est converti en vecteur par un modèle d’embeddings, puis stocké avec son texte et ses métadonnées.
4. Interrogation. À la question, on retrouve les passages les plus proches, on les assemble dans le prompt, et le modèle rédige la réponse.

Le découpage, le réglage le plus sous-estimé

Un passage trop long dilue l’information : son vecteur représente un peu de tout et ne ressemble fortement à rien. Un passage trop court perd son contexte : une phrase isolée comme « elle est valable un an » ne dit pas de quoi elle parle. Il n’existe pas de taille universelle, mais quelques principes tiennent bien.

• Couper aux frontières naturelles : titres, paragraphes, éléments de liste, plutôt qu’au milieu d’une phrase tous les mille caractères.
• Garder un peu de chevauchement entre passages voisins pour ne pas séparer une idée de sa suite.
• Attacher le contexte au passage : titre du document, intitulé de la section, date. Ces métadonnées servent à la recherche et à la citation.
• Traiter à part les tableaux et les listes de valeurs, que le découpage naïf détruit.

Les embeddings, ce qu’ils savent et ce qu’ils ne savent pas

Un modèle d’embeddings transforme un texte en une longue suite de nombres, de façon que deux textes qui parlent de la même chose aient des vecteurs proches. On mesure la proximité avec une similarité, le plus souvent le cosinus. C’est ce qui permet de retrouver « résilier mon abonnement » quand le document dit « mettre fin au contrat ».

Mais la proximité sémantique est floue. Un embedding retrouve très bien les paraphrases, et beaucoup moins bien ce qui tient à un mot précis : un identifiant de commande, un code d’erreur, un nom propre rare, un numéro d’article de loi. Pour ces requêtes, un moteur de recherche classique est meilleur.

La recherche hybride

La solution est de combiner les deux. D’un côté, une recherche lexicale, par exemple l’algorithme BM25, qui classe les passages selon les mots de la requête qu’ils contiennent, pondérés par leur rareté. De l’autre, une recherche vectorielle. On obtient deux listes classées, qu’on fusionne.

Une méthode de fusion simple et robuste s’appelle reciprocal rank fusion : chaque passage reçoit un score qui dépend de son rang dans chaque liste, et on additionne. Elle évite de comparer des scores de natures différentes, qu’on ne sait pas mettre à l’échelle. Dans la pratique, la recherche hybride retrouve à la fois les paraphrases et les termes exacts, et c’est rarement un mauvais choix de départ.

On peut ensuite ajouter une étape de reranking : un second modèle relit les dix ou vingt meilleurs candidats avec la question et les reclasse plus finement. Elle coûte du temps de calcul, et elle ne vaut le coup qu’une fois les étapes précédentes bien réglées.

Faire répondre le modèle, et citer ses sources

Une fois les passages retrouvés, la consigne doit être sans ambiguïté : répondre uniquement à partir des extraits fournis, dire clairement quand ils ne suffisent pas, ne rien ajouter de mémoire. Un système qui sait répondre « je ne trouve pas cela dans les documents » est plus utile qu’un système qui répond toujours.

Les citations sont ce qui rend la réponse vérifiable. Une bonne pratique consiste à numéroter les passages dans le prompt et à demander au modèle de citer les numéros qu’il utilise. Mais il ne faut pas se fier à sa parole : c’est le code qui transforme ces numéros en liens, et qui écarte tout numéro ne correspondant pas à un passage réellement fourni. Une citation inventée ne mène alors nulle part, au lieu de mener à une fausse source d’apparence crédible.

Le modèle rédige, le code attribue les sources.

Les droits d’accès, à la requête et pas après

Si vos documents n’ont pas tous le même public, le filtrage par permissions doit se faire pendant la recherche, avant que quoi que ce soit n’arrive dans le prompt. Filtrer la réponse après coup est trop tard : le passage confidentiel a déjà été lu par le modèle, qui peut en reprendre un morceau en le reformulant. Chaque passage indexé doit donc porter l’information de qui a le droit de le lire.

Ce qui casse le plus souvent

• Des documents obsolètes, jamais retirés de l’index, que le système cite avec aplomb.
• Des questions qui demandent de croiser plusieurs documents ou de calculer sur des tableaux, ce que la simple récupération de passages gère mal.
• Des PDF scannés dont l’extraction renvoie du bruit ou rien du tout, et que personne n’a vérifiés.
• Un index jamais rafraîchi quand les documents changent.
• Un nombre de passages trop élevé dans le prompt : plus de contexte n’est pas toujours mieux, et la partie utile se perd au milieu.

Mesurer avant de régler

Sans mesure, on règle au hasard. Constituez un petit jeu de questions réelles, avec pour chacune le ou les passages qui contiennent la réponse. Mesurez d’abord la récupération seule : le bon passage est-il dans les cinq premiers résultats ? C’est l’étape qui décide de tout. Si la récupération est mauvaise, aucun prompt ne sauvera la réponse. Mesurez ensuite la qualité de la réponse, de préférence à la main sur quelques dizaines de cas avant d’automatiser.

Un RAG décevant est presque toujours un problème de récupération, pas de génération. Regardez les passages retrouvés avant de blâmer le modèle.