Introduction au RAG

Qu’est-ce que le RAG ?

RAG (Retrieval-Augmented Generation) est une architecture qui combine un système de recherche d’information avec un modèle de langage (LLM). Au lieu de compter uniquement sur les connaissances internes du modèle, le RAG va d’abord chercher des informations pertinentes dans une base de données, puis injecter ces informations dans le prompt pour générer une réponse fondée sur des données réelles.

Pourquoi le RAG est-il devenu incontournable ? Parce que les LLMs ont trois limitations fondamentales, et qu’elles se manifestent toutes au même endroit : le moment où quelqu’un pose une question sur votre entreprise. Les connaissances figées viennent en premier — un modèle ne sait que ce qu’il a appris lors de son entraînement, donc rien de votre tarif révisé le mois dernier. Viennent ensuite les hallucinations : interrogé sur une procédure interne qu’il ne connaît pas, le modèle produit une réponse plausible et parfaitement fausse, avec une grande assurance. Enfin les données privées lui échappent par construction : il n’a pas accès à vos documents internes, et vous ne souhaitez d’ailleurs pas qu’ils se retrouvent dans un corpus d’entraînement.

Le RAG résout ces trois problèmes en ajoutant une étape de recherche avant la génération. Le modèle cesse d’être une mémoire à interroger pour devenir un moteur de rédaction appliqué à des documents que vous contrôlez.

Architecture RAG

Le pipeline RAG se décompose en deux phases principales : une indexation faite à l’avance, puis un cycle exécuté à chaque question. Les quatre étapes ci-dessous constituent la trame des leçons suivantes.

Seule la première étape se paie en temps de calcul important ; les trois suivantes s’enchaînent en moins d’une seconde. C’est ce qui rend l’architecture viable pour un service interrogé en continu : vous encodez votre documentation une fois, puis chaque question ne coûte qu’un embedding et un appel de génération.

RAG vs Fine-tuning

Le RAG et le fine-tuning résolvent des problèmes similaires mais de manières différentes. Le tableau suivant, écrit ici sous forme de structure Python, met les deux approches face à face sur cinq critères.

# Comparaison RAG vs Fine-tuning

comparaison = {
    "RAG": {
        "mise_a_jour": "Instantanée (ajouter/supprimer des documents)",
        "cout": "Faible (pas de réentraînement)",
        "tracabilite": "Excellente (on sait d'où vient l'info)",
        "hallucinations": "Réduites (réponses fondées sur des sources)",
        "cas_usage": "Documentation, FAQ, bases de connaissances",
    },
    "Fine-tuning": {
        "mise_a_jour": "Coûteuse (réentraînement nécessaire)",
        "cout": "Élevé (GPU, temps, données annotées)",
        "tracabilite": "Faible (connaissances intégrées au modèle)",
        "hallucinations": "Possibles (le modèle peut extrapoler)",
        "cas_usage": "Style d'écriture, format de sortie, tâches spécifiques",
    },
}

La ligne « mise à jour » suffit souvent à trancher. Corriger une erreur dans une procédure revient, en RAG, à remplacer un fichier et à réencoder quelques chunks — l’affaire de quelques minutes. En fine-tuning, la même correction impose de reconstituer un jeu de données et de relancer un entraînement, avec l’incertitude de ne pas savoir si l’ancienne version a bien été oubliée. En pratique, le RAG est donc souvent la meilleure solution pour intégrer des connaissances factuelles, tandis que le fine-tuning est préférable pour modifier le comportement ou le style du modèle. Les deux ne s’excluent pas : un modèle affiné pour répondre dans le format attendu par votre métier peut parfaitement être alimenté par un RAG.

Le stack technique

Pour construire un pipeline RAG avec Mistral, trois bibliothèques suffisent, et leur installation tient sur une ligne.

# Les dépendances essentielles
# pip install mistralai faiss-cpu numpy

from mistralai import Mistral  # LLM + Embeddings
import faiss                    # Vector store
import numpy as np              # Calculs vectoriels

Le SDK mistralai couvre à lui seul les deux appels au modèle : les embeddings avec mistral-embed et la génération avec mistral-large. faiss-cpu, la bibliothèque de Meta pour la recherche vectorielle rapide, prend le relais dès que la comparaison exhaustive devient trop lente — au-delà de quelques dizaines de milliers de vecteurs. numpy, enfin, assure la manipulation de matrices de vecteurs qui relie les deux. Dans les leçons suivantes, vous construirez chaque étape de ce pipeline pas à pas, de la préparation des données jusqu’à la génération de réponses.

Quand utiliser le RAG ?

Le RAG est particulièrement adapté quand vous disposez de documents internes — documentation technique, procédures, contrats — qu’aucun modèle public n’a jamais vus. Il s’impose aussi lorsque les informations changent fréquemment : prix, disponibilité, réglementations. Un service qui annonce un tarif périmé coûte plus cher qu’un service qui ne répond pas.

Trois autres situations le désignent naturellement. Le besoin de traçabilité d’abord, quand vous devez savoir d’où vient chaque information — obligation courante dès qu’un secteur est régulé, et de toute façon condition de la confiance des utilisateurs. La volonté de réduire les hallucinations ensuite, puisqu’un modèle qui dispose du bon extrait n’a plus de raison d’inventer. Le budget enfin : quand vous n’avez ni les moyens ni les données annotées pour du fine-tuning, le RAG offre une voie praticable avec une poignée de documents et quelques heures de travail.

Points clés à retenir

• Le RAG combine recherche d’information (retrieval) et génération par LLM
• L’architecture se décompose en : indexation, recherche, augmentation, génération
• Le RAG est préférable au fine-tuning pour les connaissances factuelles évolutives
• Mistral fournit les deux briques essentielles : embeddings et LLM
• FAISS est la bibliothèque de référence pour la recherche vectorielle