RAG

Comprendre le rôle stratégique du RAG, ses conditions d’utilisation et les choix techniques pour passer du POC à la production, avec des retours concrets sur ChromaDB et Qdrant.

Les grands modèles de langage accomplissent des prouesses, mais leur connaissance est figée à la date de leur entraînement. Lorsqu’une réponse dépend d’informations internes et changeantes — documentation produit, procédures, contrats, tickets support — il faut relier le modèle à une mémoire externe fiable. C’est précisément ce que propose le Retrieval‑Augmented Generation (RAG) : récupérer à la volée les passages pertinents dans une base documentaire, les injecter dans le prompt, puis générer une réponse fondée et traçable. L’objectif n’est pas seulement d’être “plus juste”, mais d’opérer avec des sources gouvernées par l’entreprise, auditées et mises à jour en continu.

Comprendre le RAG

Un système RAG s’articule autour de trois temps qui se déroulent à chaque requête. D’abord la recherche : la question de l’utilisateur est convertie en représentation numérique et comparée à un index de documents pré‑vectorisés pour sélectionner des passages réellement proches par le sens. Vient ensuite l’augmentation : ces extraits sont injectés dans un prompt structuré avec des consignes précises (format de sortie, citation des sources, droit de dire “je ne sais pas”). Enfin, la génération : le modèle produit la réponse en s’appuyant sur ce contexte ciblé. Cette orchestration réduit les hallucinations, rend la réponse vérifiable et permet de travailler sur des connaissances privées sans réentraîner le modèle à chaque changement.

C’est quoi la vectorisation ?

La vectorisation consiste à transformer un texte en un vecteur (embedding), c’est‑à‑dire une suite de nombres qui capture des proximités de sens. Deux textes sémantiquement proches — même lorsqu’ils n’emploient pas les mêmes mots — se retrouvent proches dans l’espace vectoriel. À l’inverse, des sujets sans lien sont éloignés. Lors d’une requête, la question est vectorisée puis comparée à des millions de vecteurs de l’index pour retrouver les passages les plus proches, en général via une mesure comme la similarité cosinus.

Exemple concret : texte, vecteurs et similarité

Considérons trois phrases : « Le chien aboie. », « L’animal domestique jappe. » et « La voiture roule. ». Après vectorisation (exemple fictif en 5 dimensions), on obtient :

La similarité cosinus se calcule avec : sim(A,B) = (A·B) / (‖A‖ × ‖B‖). Ici, sim(« Le chien aboie », « L’animal domestique jappe ») ≈ 0,97 : les phrases portent la même idée et leurs vecteurs sont presque colinéaires. À l’inverse, sim(« Le chien aboie », « La voiture roule ») ≈ 0,12 : les sujets sont éloignés. En production, les embeddings comptent des centaines ou milliers de dimensions, mais le principe reste le même.

Quand recourir au RAG — et quand s’en abstenir

Le RAG apporte de la valeur lorsqu’un service dépend d’informations qui évoluent souvent, lorsque la traçabilité est décisive, ou lorsque le corpus est long et hétérogène (PDF, wikis, tickets, tableaux). Dans ces contextes, on préfère injecter à la demande des passages exacts plutôt que d’espérer qu’un modèle pré‑entraîné “se souvienne” de tout. À l’inverse, lorsque l’objectif est surtout comportemental (style d’écriture, respect strict d’un format, extraction structurée) ou lorsque la latence doit être extrêmement basse, d’autres approches — fine‑tuning ciblé, outils transactionnels, requêtes SQL/BI — peuvent être plus adaptées, isolément ou en complément du RAG.

Les briques techniques qui font la différence

La préparation des données est déterminante. Un bon découpage en segments cohérents, avec un léger chevauchement, préserve le contexte et évite la perte d’information au milieu des documents. Des métadonnées soignées — langue, version, auteur, droits — permettent de filtrer finement et de diriger la recherche vers les sous‑corpus pertinents. Le choix du modèle d’embedding influence directement la pertinence sémantique ; il doit être adapté à la langue et au domaine. Côté recherche, la combinaison dense + sparse (hybride) donne d’excellents résultats : la composante dense capture le sens, la composante sparse sécurise les mots précis (acronymes, références). Un reranking par modèle léger reclassera ensuite les candidats pour fournir au LLM quelques passages réellement utiles. Enfin, l’orchestration de prompt doit rappeler les règles du jeu (citations, refus si hors périmètre, format d’output) et ordonner les extraits par pertinence pour limiter l’effet “lost‑in‑the‑middle”.

Mesurer la qualité d’un système RAG

Mettre en ligne un RAG n’est qu’un début ; la valeur vient de l’évaluation continue. La première dimension est la pertinence de la récupération : ramener, parmi les premiers résultats, les bons passages pour la question posée. On suit des indicateurs comme le Recall@k et le Mean Reciprocal Rank (MRR), en visant des passages pertinents présents systématiquement dans les tous premiers rangs. Vient ensuite la fidélité de la réponse : le modèle s’appuie‑t‑il effectivement sur le contexte fourni, sans inventer ? Des frameworks spécialisés (par exemple RAGAS, TruLens) proposent des scores de “faithfulness” qui comparent la sortie aux extraits injectés. Une réponse infidèle avec un bon contexte indique souvent un problème d’instructions ou de format d’output.

La qualité finale se juge sur l’utilité, la complétude et la clarté ; on peut mesurer l’“answer relevancy”, recourir à des juges LLM ou à des évaluations humaines par échantillonnage. La latence et le coût complètent le tableau : un RAG efficace répond vite — idéalement en quelques secondes — et maîtrise la taille du prompt. Le reranking aide justement à réduire le nombre de passages envoyés, donc les tokens, sans sacrifier la pertinence. En pratique, il est crucial de constituer un jeu de tests représentatif (questions typiques, réponses attendues ou passages de référence) et d’automatiser l’évaluation à chaque changement de la chaîne RAG (chunking, embeddings, stratégie de recherche, prompt). Cette démarche rend l’itération objective et évite les régressions.

Retours d’expérience : ChromaDB et Qdrant

Sur nos projets, nous avons constaté un schéma récurrent. ChromaDB excelle pour démarrer vite. Sa simplicité, ses SDK Python/JS et son mode persistant local (basé sur SQLite) en font un excellent terrain de jeu : idéal pour valider une pipeline d’ingestion, tester différentes tailles de segments, comparer des embeddings et mettre sur pied une démo. Les limites apparaissent surtout lorsque l’application doit servir plusieurs équipes, encaisser de la concurrence ou appliquer des filtres complexes : on commence à buter sur la persistance et l’exploitation multi‑processus si l’on ne passe pas en mode client‑serveur.

Qdrant a, de son côté, mieux tenu la charge en production. Son filtrage riche sur métadonnées, son support des approches hybrides dense/sparse et ses capacités de clustering (sharding, réplication, snapshots) apportent de la stabilité sous contrainte de volume et de disponibilité. Autre atout apprécié : la possibilité de composer la requête (dense + sparse) et de déléguer une partie du reranking côté serveur avant de ne transmettre au modèle que l’essentiel. Sur des corpus multilingues et versionnés, la combinaison “filtres stricts + hybride + rerank” a nettement réduit les hallucinations et les coûts de tokens.

Du POC à la production

Un enchaînement pragmatique consiste à démarrer avec une ingestion propre, un index local ChromaDB et un premier flux RAG sans reranking, simplement pour valider la chaîne et collecter des journaux. L’étape suivante introduit la recherche hybride et un reranking léger afin d’améliorer la précision tout en diminuant le contexte envoyé. Lorsque l’usage se stabilise et que les besoins d’isolation, d’observabilité et de scalabilité se confirment, le passage à Qdrant devient naturel : filtres riches, collections multiples, réplication, gouvernance des accès et supervision sérieuse.