RAG : comment l’IA interroge réellement votre documentation

#RAG #Knowledge Management #Product Management #IA

Dans un précédent article, j’évoquais l’idée qu’une documentation produit structurée était devenue indispensable, parce que les outils IA permettent désormais de l’interroger en langage naturel. La suite logique de ce raisonnement, c’est que nous devons comprendre comment ces outils s’y prennent réellement pour aller fouiller dans notre base documentaire.

Le mot qui revient partout est RAG > Retrieval-Augmented Generation. Derrière l’acronyme se cache un mécanisme assez simple, mais dont la compréhension change la manière dont une équipe produit aborde ses choix d’outils, de structuration documentaire, et finalement de gouvernance de la connaissance.

L’objectif de cet article : démystifier ce qu’est un RAG, et donner à une équipe product les bons repères pour dialoguer avec ses équipes tech sur le sujet.

Le problème que résout un RAG

Un LLM seul (ChatGPT, Claude, Gemini, Mistral…) a deux limites structurelles quand on veut l’utiliser sur sa documentation interne.

D’abord, il ne connaît pas vos documents. Son entraînement s’est arrêté à une date donnée et n’inclut évidemment pas votre documentation technique, votre code source ou vos comptes-rendus de discovery.

Ensuite, sa fenêtre de contexte est finie. Même avec les modèles récents qui acceptent 200 000 tokens, on ne peut pas charger 5 000 pages de documentation à chaque question et ce n’est plus efficace.

Le RAG cherche à résoudre ces deux problèmes d’un coup. À chaque question posée, il commence par aller chercher dans votre base documentaire (google, confluence, sharepoint…) les passages les plus pertinents, puis il les envoie au LLM avec la question. Le modèle répond uniquement sur la base de ce qu’on lui a fourni et pas sur ses souvenirs d’entraînement.

C’est en gros ce que ferait un humain qui prépare une réunion : il ne lit pas toute la documentation de l’entreprise, il va chercher les trois ou quatre documents pertinents et il en fait la synthèse mentale.

Comment ça marche, étape par étape

Un RAG repose sur quatre briques, qu’il faut comprendre dans l’ordre.

1. L’indexation de la base documentaire Tous vos documents sont découpés en petits morceaux (qu’on appelle chunks), généralement de quelques centaines de mots chacun. Chaque morceau est ensuite transformé en une représentation mathématique (un vecteur) qui capture son sens unitairement. Deux morceaux qui parlent de la même chose auront des vecteurs proches (c’est d’ailleurs la base du fonctionnement des LLM).
2. Le stockage dans une base vectorielle Ces vecteurs sont rangés dans une base spécialisée (Pinecone, Qdrant, Weaviate, ou des solutions plus légères) qui sait retrouver très rapidement les vecteurs proches d’une question donnée.
3. Le retrieval au moment de la question Quand l’utilisateur pose une question, celle-ci est elle aussi convertie en vecteur. Le système identifie les chunks documentaires dont le vecteur est le plus proche c’est-à-dire qu’il identifie les passages a priori les plus pertinents.
4. La génération de la réponse Ces passages sont envoyés au LLM avec la question, dans un prompt qui ressemble en substance à : « Voici une question utilisateur et les extraits de documentation pertinents. Réponds uniquement sur la base de ces extraits, et cite tes sources. »

Tout l’enjeu d’un RAG se joue dans la qualité de chacune de ces quatre étapes. Un mauvais découpage, un retrieval imprécis ou un prompt mal calibré, et l’utilisateur reçoit une réponse hallucinée, hors-sujet ou faisant une part trop importante à des « détails ».

Mieux qu’un simple chatbot

Trois différences importantes avec un assistant IA « classique » qu’on questionnerait sur sa documentation à la volée.

La traçabilité : un RAG bien construit cite les documents sources de chaque affirmation. L’utilisateur peut vérifier, contester, approfondir. Sans cette traçabilité, le LLM va réaliser trop d’interprétations et on doit re-requêter le chatbot pour comprendre son raisonnement quand on repère des pondérations logiques anormales (souvent : un détail de la doc qui prend beaucoup trop de place dans les réponses).

La fraîcheur : à chaque mise à jour d’un document dans la base, il suffit de réindexer ce document. Le RAG répondra avec l’information à jour dès la requête suivante. Là où un modèle « fine-tuné » sur votre documentation aurait nécessité un réentraînement complet.

Le périmètre maîtrisé : le RAG ne répond que sur ce qu’il trouve. Si l’information n’est pas dans la base, il dira qu’il ne sait pas (à condition qu’on l’ait configuré pour ça, et c’est précisément le rôle du prompt système). Aussi, c’est plus économe en ressources/tokens, sujet promis à une belle actualité !

L’approche pragmatique pour démarrer pour les équipes product

La plupart des tutos sur le RAG vous embarquent immédiatement vers une infrastructure conséquente : vector database, pipeline d’embeddings, framework d’orchestration. C’est nécessaire à grande échelle, mais pour démarrer, l’approche minimale est aujourd’hui beaucoup plus simple (c’est celle que j’utilise sur mes projets).

Pour les corpus de quelques centaines de documents (à savoir le cas réel de la plupart des équipes produit) un assistant IA branché directement sur un dossier de fichiers markdown bien organisés suffit. Pas de base vectorielle, pas d’embeddings à maintenir : le LLM lit la structure du dossier, ouvre les bons fichiers en fonction de leur nom, et synthétise. C’est techniquement moins efficace et scalable qu’un vrai RAG, mais opérationnellement c’est beaucoup plus rapide à mettre en place, et la qualité des réponses est souvent supérieure parce que les documents sont lus en entier plutôt que découpés en chunks parfois maladroitement.

Le vrai investissement n’est pas dans l’outil. Il est, comme je le défendais dans l’article précédent, dans la qualité de la structuration documentaire en amont.

Quand passer à une vraie infrastructure RAG

Quelques signaux concrets indiquent qu’il faut passer à l’étage RAG.

1. Le volume documentaire dépasse plusieurs milliers de pages et la fenêtre de contexte du LLM commence à saturer
2. Les utilisateurs sont nombreux et il faut absorber un débit de questions parallèles
3. Le cas d’usage est exposé à des utilisateurs externes et le SLA, la latence, la confidentialité deviennent critiques (hallucinations ou sécurité des données des chatbot par exemple)
4. Le corpus est multimodal (PDF complexes, schémas, données structurées) et nécessite un pipeline d’ingestion sérieux.

Dans ces cas, il est préférable de basculer vers un des framework dédiés du marché et l’équipe tech reprend la main sur l’architecture de cette base documentaire comme elle le ferait pour du code source.

Ce qu’un PM doit retenir

Un RAG n’est pas une boîte noire. C’est une mécanique en quatre étapes : indexer, stocker, retrouver, générer… et chacune de ces étapes dépend intégralement de la qualité des données d’entrée comme souvent dans nos contextes data/product.

Le vrai sujet, pour une équipe product, est de garantir que la documentation est suffisamment structurée, à jour, et nommée correctement pour qu’un système (qu’il soit minimaliste et géré par le produit ou industriel) puisse en tirer parti.

L’IA est donc l’inverse d’un substitut à la rigueur documentaire, mais plutôt un levier qui rend l’investissement dans cette rigueur plus rentable.

Chez Kanbios, nous accompagnons des équipes produit qui veulent transformer leur capital documentaire en un véritable outil de delivery : structuration de la connaissance, mise en place d’assistants IA internes, montée en compétence des PM et des équipes tech sur ces nouvelles pratiques. Si vous explorez ces sujets, échangeons.

Thomas Perard, Senior Manager Retail & Services chez Kanbios