Demandez à un assistant général en IA la politique de remboursement de votre entreprise, et il ne peut que deviner. Il n’a jamais vu vos documents. RAG, abréviation de génération augmentée par récupération, résout ce problème en recherchant les bonnes informations et en les transmettant au modèle avec la question.

Ce guide explique chaque étape en langage simple, puis crée une petite version en utilisant uniquement la bibliothèque standard de Python. Nous avons exécuté ce code sur Python 3.13 et les scores affichés proviennent de cette exécution. Il n’utilise aucun modèle de langage, il démontre donc la récupération et la création d’invites, et nous n’avons pas testé l’étape de réponse finale.

Qu’est-ce que le RAG ?

La génération augmentée par récupération est une technique qui combine une étape de recherche avec un modèle de langage. Lorsqu’une question arrive, le système recherche une source de connaissances, ajoute les meilleurs résultats à l’invite et demande au modèle de répondre en fonction de ce matériel.

Pensez à un examen à livre ouvert. Un étudiant à livre fermé s’appuie sur sa mémoire et peut se souvenir de manière erronée en toute confiance. Un étudiant à livre ouvert peut d’abord rechercher la bonne page. RAG donne au modèle ce livre et lui permet également d’indiquer la page qu’il a utilisée.

Le problème que RAG résout

Un modèle de langage à lui seul présente trois limites pour une utilisation professionnelle :

• Il ne connaît pas vos données privées. Vos politiques, tickets et contrats ne faisaient pas partie de sa formation.
• Sa connaissance a un seuil. Il ne peut pas connaître un prix que vous avez modifié ce matin.
• Il peut inventer des réponses. En cas de doute, il peut produire quelque chose de plausible mais de faux.

RAG répond à ces trois critères et vous n’avez rien à recycler. Mettez à jour un document, réindexez-le et la toute prochaine réponse pourra l’utiliser.

Comment fonctionne RAG, étape par étape

Un système RAG comporte deux canalisations. L’un prépare vos données à l’avance et l’autre répond à chaque question.

Indexation : préparer vos données

1. Charger : collectez le contenu de PDF, de wikis, de bases de données ou de tickets.
2. Nettoyer et fragmenter : supprimez les fichiers inutiles, puis divisez les documents en petits passages.
3. Intégrer : convertit chaque passage en une liste de nombres, appelée intégration, qui capture sa signification.
4. Store : enregistre les intégrations dans un index consultable, souvent une base de données vectorielle.

Interroger : répondre à une question

1. Récupérer : intégrez la question et trouvez les passages les plus proches en termes de sens.
2. Augment : insérez ces passages dans l’invite.
3. Générer : le modèle écrit une réponse en utilisant ce contexte.

La récupération ne nécessite pas l’utilisation de vecteurs. Il peut s’agir d’une recherche par mot clé ou même d’une requête SQL, selon celle qui trouve la bonne information pour vos données.

Un petit exemple fonctionnel

Pour voir clairement les pièces mobiles, voici un petit retriever sans bibliothèque. Il représente le texte en nombre de mots, un substitut beaucoup plus simple aux intégrations réelles, et il évalue la similarité en utilisant la mesure du cosinus.

import math, re
from collections import Counter

DOCS = {
    "refunds": "Refunds are paid within 7 days to the original payment method.",
    "shipping": "Standard shipping takes 3 to 5 working days across India.",
    "warranty": "All keyboards include a 2 year warranty against defects.",
}

def vectorize(text):
    return Counter(re.findall(r"[a-z0-9]+", text.lower()))

def similarity(a, b):
    dot = sum(a[word] * b[word] for word in a)
    size = math.sqrt(sum(v * v for v in a.values()))
    size *= math.sqrt(sum(v * v for v in b.values()))
    return dot / size if size else 0

def retrieve(question, k=1):
    q = vectorize(question)
    scored = [(similarity(q, vectorize(t)), name) for name, t in DOCS.items()]
    return sorted(scored, reverse=True)[:k]

def build_prompt(question):
    (score, name), = retrieve(question)
    return (
        "Answer using only the context. If it is not there, say you do not know.\n"
        f"Context: {DOCS[name]}\n"
        f"Question: {question}"
    )

Poser des questions sur les remboursements trouve le bon passage et génère cette invite :

print(retrieve("How many days until refunds are paid?"))
# [(0.4558..., 'refunds')]

print(build_prompt("How many days until refunds are paid?"))
# Answer using only the context. If it is not there, say you do not know.
# Context: Refunds are paid within 7 days to the original payment method.
# Question: How many days until refunds are paid?

Dans un système complet, vous enverriez désormais cette invite à un modèle de langage. Le détail important est l’instruction permettant d’admettre lorsque la réponse est manquante, sur laquelle vous pouvez en savoir plus dans notre guide de l’ingénierie des invites.

Ce qui manque à notre exemple

Essayez maintenant une question qui signifie la même chose mais utilise des mots différents :

print(retrieve("When can I get my money back?", k=3))
# [(0.0, 'warranty'), (0.0, 'shipping'), (0.0, 'refunds')]

Chaque score est nul, car la question ne partage aucun mot avec aucun document. « Remboursé » signifie le remboursement à un être humain, mais le nombre de mots ne peut pas le dire. Ce résultat unique explique pourquoi les systèmes réels utilisent des intégrations, qui sont conçues de telle sorte qu’un texte ayant une signification similaire se retrouve avec des nombres similaires, même sans mots en commun.

Mais ne présumez pas que les intégrations résolvent tout. Ils peuvent avoir du mal avec des termes exacts tels que les codes de produits et les numéros d’erreur, que la recherche par mot clé gère très bien. C’est pourquoi de nombreux systèmes de production utilisent la recherche hybride, combinant les deux approches.

Chunking : l’étape que les gens sous-estiment

Les documents sont divisés en morceaux car des fichiers entiers sont trop longs et imprécis à récupérer. Le choix de la taille implique un véritable compromis :

Quelques centaines de mots avec un certain chevauchement entre les morceaux sont un point de départ courant, mais considérez cela comme une première hypothèse à tester. Divisez-vous le long des limites naturelles, telles que les titres, lorsque vous le pouvez. Et joignez des métadonnées, comme le titre du document, la date et le département, afin de pouvoir filtrer les résultats et citer les sources.

Améliorer la récupération

Lorsque les réponses sont mauvaises, voici les améliorations qui valent le plus la peine d’être essayées, à peu près dans cet ordre :

• Nettoyez les données. Supprimez d’abord les documents obsolètes et en double. Aucun algorithme ne corrige les sources contradictoires.
• Utilisez la recherche hybride. Combinez les résultats basés sur la signification et les mots clés.
• Ajoutez un reclassement. Récupérez plus de candidats, puis utilisez un modèle spécialisé pour les réorganiser par pertinence.
• Filtrer par métadonnées. Restreindre les résultats par produit, région ou date avant de lancer la recherche.
• Réécrivez la requête. Transformez une vague suite du type « Et la deuxième ? » en une question complète.

RAG vs réglage fin

Ils ne s’excluent pas mutuellement. Notre comparaison entre RAG, réglage fin et ingénierie rapide explique comment choisir de manière plus approfondie.

Comment tester un système RAG

RAG est un logiciel et nécessite des tests comme tout autre logiciel. Créez un ensemble de vraies questions ainsi que les passages et les réponses que vous attendez, puis mesurez les deux étapes séparément :

Incluez également les cas délicats : les questions sans réponse dans vos données, les questions qui utilisent une formulation différente et les questions dont les sources sont contradictoires. Réexécutez cet ensemble chaque fois que vous modifiez le regroupement, les modèles ou les invites, tout comme une suite de régression. Notre tutoriel pytest montre comment exécuter de nombreuses entrées via un seul test.

Pourquoi les systèmes RAG échouent

• La réponse ne se trouve pas dans les données. Le modèle peut encore en tenter une, alors dites-lui comment refuser.
• Le bon morceau n’a pas été récupéré. Il s’agit souvent d’un problème de regroupement ou de recherche.
• Trop de contexte. Des passages non pertinents peuvent distraire le modèle et augmenter les coûts.
• Documents obsolètes. Une ancienne politique peut être récupérée avec autant de confiance que la politique actuelle.
• Tableaux et fichiers PDF mal analysés. Si l’extraction brouille le texte, la récupération ne récupère jamais.
• Tests uniquement avec des questions de démonstration. Les vrais utilisateurs formulent les choses très différemment.

Sécurité et autorisations

RAG comporte deux risques faciles à ignorer. Tout d’abord, le contrôle d’accès : si l’index contient des fichiers RH, la question d’un junior ne doit pas les récupérer. Appliquez les autorisations de chaque utilisateur lors de la récupération, car demander au modèle de conserver des secrets ne constitue pas une protection fiable.

Deuxièmement, injection rapide. Une page Web ou un document récupéré peut contenir un texte tel que « ignorez vos instructions ». Traitez le contenu récupéré comme des données non fiables, limitez les actions que le modèle peut entreprendre et exigez qu’un humain approuve les actions sensibles.

Pour conclure

RAG est une idée simple avec de nombreux détails pratiques : trouvez la bonne information, puis demandez au modèle de l’utiliser. Commencez par un petit ensemble de documents clairs et une vingtaine de vraies questions. Faites en sorte que la récupération fonctionne bien avant d’ajouter de la complexité, car un pipeline modeste avec de bonnes données bat généralement un pipeline sophistiqué avec de mauvaises données.

Questions fréquentes

Continuez à apprendre