RAG
Définition
Retrieval-Augmented Generation. Technique qui donne au LLM accès à votre base documentaire au moment de répondre, plutôt que de lui apprendre vos données. Permet des réponses sourcées et à jour.
Comment ça marche
Le RAG (Retrieval-Augmented Generation) connecte un LLM à votre documentation sans le réentraîner. Au moment de l'indexation, on découpe vos documents en passages (chunks de quelques centaines de tokens), on calcule un embedding pour chacun, et on stocke ces vecteurs dans une base spécialisée. À la question de l'utilisateur, on calcule l'embedding de la requête, on cherche les passages dont les vecteurs sont les plus proches, et on les injecte dans le prompt avec une consigne : réponds en t'appuyant uniquement sur ces extraits. Le modèle compose alors une réponse ancrée dans vos sources.
À quoi ça sert
Le RAG résout deux problèmes du LLM brut : il ne connaît pas vos données propriétaires, et son savoir s'arrête à sa date d'entraînement. Cas typiques : assistant interne qui répond sur la documentation produit, support client qui s'appuie sur la base de connaissance, recherche sémantique dans une base de cas juridiques ou médicaux, agent commercial qui interroge le catalogue. Les réponses peuvent citer leurs sources, ce qui permet à l'utilisateur de vérifier et au métier de tracer. Mise à jour de la doc se traduit immédiatement par mise à jour des réponses, sans réentraîner quoi que ce soit.
Quand l'utiliser
Le RAG s'impose quand votre cas demande un savoir spécifique qui change régulièrement et qu'on doit pouvoir tracer. À l'inverse, pour des connaissances générales déjà bien couvertes par le modèle (français standard, programmation Python, droit français de base), le RAG ajoute de la complexité sans gain. Pour des cas où le ton compte plus que le contenu (génération marketing dans une voix de marque), un prompt système suffit. Pour transformer un modèle dans son comportement profond, c'est le fine-tuning qu'il faut, pas le RAG. La règle : RAG si la question est de l'ordre de la consultation, fine-tuning si elle est de l'ordre du style.
L'ingestion fait toute la qualité
La qualité d'un RAG dépend à 80% de l'ingestion, à 20% du modèle. Trois questions à trancher. Comment découper les documents : trop fin et on perd le contexte, trop large et on noie la pertinence ; on vise généralement 300 à 800 tokens par chunk, avec recouvrement. Quelles métadonnées attacher : titre, section, date, auteur, permissions, qui permettent de filtrer la recherche. Quel modèle d'embedding choisir : text-embedding-3-large d'OpenAI, voyage-3 de Voyage AI, ou des modèles open-source pour la souveraineté. Un corpus mal préparé renvoie des passages hors sujet et le LLM hallucine quand même.
Le stack technique
Pour un RAG modeste (jusqu'à quelques millions de chunks), pgvector dans PostgreSQL (via Supabase ou Neon) suffit largement, et garde l'avantage de cohabiter avec vos données métier. Pour des volumes plus gros ou des besoins de filtrage avancé, on regarde Qdrant, Weaviate ou Pinecone. Côté orchestration, LangChain et LlamaIndex proposent des abstractions complètes, mais on préfère souvent un code custom plus simple sur Next.js : une route d'indexation, une route de recherche, une route de génération. Moins de magie, plus de contrôle.
Le re-ranking et les techniques avancées
Une recherche par similarité simple suffit rarement pour atteindre une qualité production. On combine plusieurs techniques. Le hybrid search mélange recherche vectorielle et recherche par mots-clés (BM25) pour ne pas rater les requêtes très spécifiques. Le re-ranking utilise un second modèle plus précis (Cohere Rerank, Voyage Rerank) sur le top-50 récupéré pour ne garder que le top-5 vraiment pertinent. La query expansion reformule la question en plusieurs variantes avant la recherche. Ces couches ajoutent du coût et de la latence mais font passer un RAG de 60% à 90% de réponses correctes.
Les pièges à éviter
Quatre erreurs reviennent. Croire qu'un RAG remplace une bonne organisation de la documentation : un corpus mal structuré reste mal exploitable, IA ou pas. Indexer trop large : si on jette tout dans la base sans curation, on noie les passages pertinents dans le bruit. Oublier les permissions : un RAG mal cloisonné fuit des documents confidentiels à des utilisateurs qui n'y ont pas droit. Et négliger l'évaluation continue : on fixe un jeu de questions de référence avec les bonnes réponses attendues, et on mesure la qualité à chaque modification de prompt, de modèle ou d'ingestion.