RAG LLM: brancher un modèle sur vos données sans le fine-tuner

RAG LLM: réponse ancrée, pas mémoire magique

Un RAG LLM (Retrieval-Augmented Generation) récupère des passages de tes documents au moment de la question, puis les injecte dans le contexte du modèle pour générer une réponse. Le modèle n'a pas « appris » ton PDF dans ses poids: il lit ce que le retriever lui donne.

Tu l'utilises quand la vérité métier vit en dehors du modèle, dans tes procédures, tes catalogues, tes contrats, tes tickets ou ton wiki. Sans retrieval, le LLM invente poliment. Avec un mauvais retrieval, il invente en citant le mauvais paragraphe.

Avant de parler d'embeddings, regarde le process: quelle question traites-tu, où vit la source de vérité, quel est le risque si la réponse est fausse, et qui valide le résultat.

Les briques d'un pipeline RAG

Un pipeline RAG complet s'assemble en sept briques, dans cet ordre:

1. Le corpus: des sources autorisées, avec leurs droits et leur fraîcheur
2. L'ingestion: le parsing, le nettoyage et les métadonnées (produit, date, langue, confidentialité)
3. Le chunking: des tailles et des chevauchements adaptés au type de document
4. L'index: des embeddings, éventuellement complétés par du full-text ou de l'hybride
5. Le retrieval: le top-k, les filtres et le re-ranking
6. La génération: un prompt qui impose de s'appuyer sur les passages fournis
7. Le post-traitement: les citations, les logs et la validation humaine (HITL)

La recherche hybride, qui combine sémantique et mot-clé, sauve souvent les cas exacts comme les SKU ou les références légales. Un index purement vectoriel rate les identifiants rares.

Versionne enfin le corpus et l'index comme du code, avec la date d'ingestion, le hash des sources et les paramètres de chunking. Sans ça, tu ne peux pas rejouer un incident.

Qualité: mesurer avant d'ajouter des features

Sans jeu d'éval, tu optimises au feeling. Constitue d'abord 30 à 100 questions réelles, avec la réponse attendue ou les passages gold, puis mesure:

• Le rappel du retrieval: le bon chunk arrive-t-il dans le top-k ?
• La fidélité de la réponse aux passages fournis
• Le taux de « je ne sais pas » corrects
• Le temps de réponse et les tokens consommés

Les échecs se rangent en quelques familles: un corpus incomplet, un chunk trop gros ou trop petit, une mauvaise requête, une hallucination malgré un bon contexte, ou un problème de droits d'accès. Chaque famille appelle un correctif différent, donc ne change pas tout d'un coup.

Les citations cliquables nourrissent la confiance et la revue. Si l'équipe ne clique jamais dessus, c'est que le HITL est mal conçu.

Sécurité et périmètre d'accès

Un RAG qui indexe tout le Drive sans ACL rejoue les fuites internes, en plus poli. Filtre donc par identité et par droits au moment du retrieval, pas seulement dans le prompt, et journalise qui a vu quoi.

Pour les données personnelles, minimise ce qui entre dans l'index, masque ce qui doit l'être et fixe une durée de rétention. Un chunk n'est pas anodin parce qu'il est « technique ».

Quand un agent combine des outils et du RAG, le modèle peut enchaîner une recherche puis une action. Borne les tools avec une allowlist et place la validation humaine sur l'action, pas seulement sur le texte.

Coût tokens et latence

Chaque chunk injecté coûte des tokens d'entrée. Un top-k trop large gonfle la facture et le bruit, un top-k trop petit fait rater des passages. Calibre-le sur ton éval, pas sur une valeur magique trouvée sur internet.

Cache les embeddings des documents stables. Pour les questions répétées, ajoute un cache de réponses que tu invalides à chaque ré-ingestion. Et mesure la latence p95 de bout en bout, retrieval et génération compris.

Si le coût explose, commence par chasser le bruit, comme les chunks inutiles ou un historique de chat trop long, avant de changer de modèle.

Mettre un RAG en prod en 30 jours

Un premier RAG tient en quatre semaines si le périmètre reste borné:

1. Semaine 1: un seul flux, un corpus borné et 30 questions gold
2. Semaine 2: le pipeline d'ingestion, le retrieval hybride et les citations
3. Semaine 3: l'éval et la validation humaine sur les cas à risque
4. Semaine 4: le monitoring (qualité, coût, feedback) et l'élargissement contrôlé du corpus

Avant le go-live, vérifie quatre critères: un rappel de retrieval acceptable, zéro incident d'accès, un owner nommé et un runbook de ré-ingestion. Sans ça, tu as une démo.

Pour aller plus loin, l'article fine-tuning vs RAG t'aide à choisir entre les poids et le retrieval, et le guide LLMOps couvre les évals et l'observabilité.

Si vous voulez cadrer un premier RAG LLM sur un corpus réel, on peut le faire en 20-40 minutes.