Construisez un système de questions-réponses sur votre base de connaissances avec le RAG
Les LLM ne connaissent pas votre matériel privé et à jour, et ont tendance à halluciner. Le RAG (génération augmentée par récupération) fait répondre le modèle à partir d’une base de connaissances fiable selon la logique « récupérer d’abord, générer ensuite » — l’une des approches de production les plus pratiques aujourd’hui.
ParAI Resource Hub
Pourquoi le RAG est nécessaire
Injecter des connaissances en affinant directement le modèle coûte cher et se met à jour lentement. Le RAG garde les connaissances dans une base externe et récupère à la demande les fragments pertinents pour les fournir au modèle : économique et toujours à jour.
Vue d’ensemble du pipeline
Un système RAG typique comporte deux phases : une « phase d’indexation » hors ligne qui transforme les documents en vecteurs récupérables, et une « phase de requête » en ligne qui récupère et génère une réponse à partir de la question de l’utilisateur.
Découpage des documents et embeddings
Découpez d’abord les documents en fragments de taille adaptée. Trop grands, la récupération perd en précision ; trop petits, le contexte se perd. Une approche courante : quelques centaines de tokens avec un léger chevauchement.
Utilisez ensuite un modèle d’embeddings pour convertir chaque fragment en vecteur et le stocker dans une base vectorielle (pgvector, Milvus ou Qdrant, par exemple).
Récupération vectorielle et Top-K
Quand un utilisateur pose une question, convertissez-la aussi en vecteur, lancez une recherche par similarité dans la base et récupérez les fragments les plus pertinents (Top-K).
Vous pouvez combiner la recherche par mots-clés pour une « récupération hybride » et appliquer un reranking afin d’améliorer encore la qualité du rappel.
Assemblez le contexte et générez la réponse
Insérez les fragments récupérés dans le prompt et demandez au modèle de « répondre uniquement à partir du matériel fourni, et d’indiquer clairement si le matériel ne contient pas la réponse » : cela réduit fortement les hallucinations.
Parmi les optimisations avancées : la réécriture de la requête, la citation des sources, le contrôle de la longueur du contexte, ainsi que la déduplication et le filtrage des résultats de récupération.
Choisir une base de données vectorielle
La base de données vectorielle est au cœur du RAG. Pour le prototypage, Chroma tourne en mémoire sans configuration. Pour les charges de production, Qdrant (en Rust) et Pinecone (entièrement géré) sont conçus pour un déploiement en production ; vérifiez leurs limites et options de montée en charge actuelles dans leur documentation. Si vous utilisez déjà PostgreSQL, pgvector évite d’ajouter de l’infrastructure. Weaviate brille quand vous avez besoin de modules de vectorisation intégrés et d’une API GraphQL.
Évaluer la qualité du RAG
Un système RAG ne vaut que par sa récupération et sa génération. Mesurez la récupération avec Recall@K (le bon fragment apparaît-il dans les résultats Top-K ?) et la génération par la fidélité (la réponse reste-t-elle ancrée dans le contexte récupéré ?) et la pertinence (répond-elle vraiment à la question ?). Des frameworks comme RAGAS automatisent ces métriques pour suivre la qualité au fil des itérations sur les stratégies de découpage, les modèles d’embedding et les templates de prompts.
Avant de commencer : prérequis
Il vous faut un ensemble de documents petit mais représentatif, le droit de les utiliser et un analyseur capable d’en extraire un texte propre (les PDF et les scans nécessitent souvent de l’OCR). Choisissez un modèle d’embeddings et un stockage vectoriel que vous pouvez exécuter dans votre environnement, et vérifiez leur dimension et la prise en charge des langues. Préparez 20 à 50 questions réelles avec, pour chacune, le document ou le passage censé y répondre. Enfin, décidez comment les documents sont mis à jour et qui peut lire chaque collection, car les permissions doivent s’appliquer au moment de la récupération, pas seulement dans l’interface.
Pas besoin d’un corpus énorme pour démarrer. Quelques centaines de pages bien structurées suffisent à valider le pipeline avant de passer à l’échelle.
Vérification : contrôlez la récupération avant les réponses
Testez d’abord la récupération. Pour chaque question étiquetée, lancez la recherche et inspectez les meilleurs résultats : le passage attendu doit figurer dans le Top-K et les fragments hors sujet ne doivent pas dominer. Sinon, ajustez la taille des fragments, le chevauchement, les filtres de métadonnées ou le modèle d’embeddings avant de toucher au prompt de génération. Vérifiez ensuite les réponses : le modèle doit citer ou extraire le passage récupéré, et indiquer que le matériel ne contient pas la réponse quand c’est le cas. Gardez un jeu d’évaluation fixe et relancez-le après chaque changement pour repérer les régressions. Testez aussi une question sans réponse, une question avec deux documents similaires et une question dans chaque langue prise en charge.
Dépannage des échecs RAG courants
Procédez dans cet ordre. Si la récupération ne renvoie rien, vérifiez que les documents sont indexés, que la requête et les documents utilisent le même modèle et la même dimension d’embeddings, et que les filtres n’excluent pas la collection. Si le bon fragment existe mais ressort bas, inspectez les frontières des fragments et essayez une recherche hybride par mots-clés ou un reranking. Si la réponse ignore le contexte récupéré, confirmez que les fragments ont bien atteint le prompt et n’ont pas été tronqués, puis durcissez la consigne de répondre uniquement à partir du matériel fourni et de citer les sources. Si les réponses sont obsolètes, vérifiez que la réindexation a tourné après la mise à jour du document. Si les doublons saturent le Top-K, dédupliquez par ID de document ou empreinte du contenu avant l’insertion. Enfin, vérifiez que les filtres de contrôle d’accès s’appliquent pendant la récupération, pas après la génération.
Quand le RAG n’est pas le bon outil
Le RAG convient mal quand toute la base de connaissances tient confortablement dans la fenêtre de contexte et change rarement ; transmettre les documents directement est plus simple. Il est aussi faible quand les sources sont peu fiables, contradictoires ou surtout composées d’images sans texte exploitable. Si la tâche exige du calcul, des transactions ou un état en temps réel, appelez une base de données ou une API au lieu de récupérer des textes à ce sujet. Pour une question nécessitant une seule consultation faisant autorité, un index de recherche ou une requête structurée peut être plus précis. Et si personne ne peut maintenir l’index, le système de récupération se dégradera vite ; un document plus petit et bien tenu peut mieux servir les utilisateurs.
Une étape de découpage
Cette fonction résout l’étape d’indexation qui découpe le document avant l’embedding. C’est une esquisse de départ, pas un résultat mesuré. Échec : si overlap vaut 0, un fait posé sur la coupe n’entre dans aucun fragment, et la récupération ne peut pas le rendre.
def chunk_text(text, size=400, overlap=50):
chunks = []
start = 0
while start < len(text):
chunks.append(text[start:start + size])
if start + size >= len(text):
break
start += size - overlap
return chunks