Qu'est-ce que le RAG ?
RAG signifie génération augmentée par récupération. C'est la façon standard de faire répondre un modèle de langage sur des informations sur lesquelles il n'a jamais été entraîné, c'est-à-dire en pratique presque tout ce qui est propre à une entreprise : contrats, procédures, données produits, historique de support, documentation interne.
Le principe est simple. Au lieu d'espérer que le modèle sache quelque chose, vous trouvez vous-même les passages pertinents et vous les lui transmettez avec la question. Le modèle n'a alors plus qu'une seule tâche, rédiger une bonne réponse à partir de preuves qu'on lui donne, au lieu de deux, se souvenir puis rédiger.
Cette séparation constitue toute la valeur de l'approche. Elle explique aussi le malentendu le plus fréquent au sujet du RAG : la qualité de la réponse est décidée avant que le modèle ne soit même appelé.
Pourquoi le RAG compte
Quatre raisons expliquent qu'il soit devenu l'architecture par défaut en contexte professionnel.
- Il fonctionne sur des informations qui bougent. Mettez un document à jour et la réponse suivante change. Pas de réentraînement, pas d'attente, pas de coût par mise à jour.
- Il rend les réponses vérifiables. Comme les passages sont récupérés explicitement, le système peut citer le document utilisé, ce qui transforme un assistant en quelque chose qu'un auditeur accepte.
- Il limite l'exposition. Seuls les passages récupérés quittent vos systèmes pour une question donnée, pas l'ensemble documentaire.
- Il coûte bien moins cher que les alternatives. Récupérer cinq passages coûte une fraction de l'envoi d'un corpus entier à chaque question, et l'écart se creuse avec chaque utilisateur supplémentaire.
La conséquence est autant organisationnelle que technique. Un système RAG qui fonctionne oblige une entreprise à décider quel document fait référence, une question que la plupart des organisations ont discrètement évité de trancher.
Comment ça fonctionne
Quatre étapes, et chacune est un endroit où la qualité se gagne ou se perd.
Le découpage divise les documents en passages. Trop petit, un passage perd le contexte qui lui donne du sens. Trop grand, le modèle reçoit du bruit autour de la phrase utile. C'est la décision la plus sous-estimée du pipeline.
L'embedding convertit chaque passage en une représentation numérique qui capture son sens, afin que la similarité puisse être mesurée plutôt que devinée à partir de mots-clés. Ces représentations sont stockées dans un index conçu pour ce type de comparaison.
La récupération compare la question entrante à l'index et renvoie les passages les plus proches. Les bons systèmes filtrent autant qu'ils classent, en s'appuyant sur des métadonnées comme la date, le client, la langue ou la version du document, pour qu'une procédure obsolète ne concurrence jamais la version courante.
La génération injecte les passages récupérés dans le prompt à côté de la question, avec une consigne de ne répondre qu'à partir de ce qui a été fourni et de le dire quand la preuve manque.
Le mode de défaillance découle directement de cet ordre. Quand un système RAG donne une mauvaise réponse, la récupération est coupable bien plus souvent que le modèle. Si le bon passage n'atteint jamais les premiers résultats, aucun modèle ne peut rattraper la situation.
Mise en œuvre
L'ordre compte plus que l'outillage.
- Choisir un seul ensemble documentaire avec un propriétaire clair et un niveau d'autorité connu. Pas l'intranet entier.
- L'assainir avant l'indexation. Supprimer les doublons et les versions périmées. Un système de récupération renverra volontiers un document obsolète avec une assurance totale.
- Ajouter des métadonnées de date, version, langue et périmètre, car le filtrage est ce qui évite la majorité des mauvaises réponses.
- Régler le découpage sur de vraies questions, pas sur un paramètre générique copié d'un tutoriel. Mesurer si le bon passage apparaît dans les premiers résultats.
- Autoriser le modèle à s'abstenir. Une réponse du type je n'ai pas cette information est une fonctionnalité, pas un échec.
- Afficher les sources dans l'interface, pour qu'un utilisateur vérifie en un clic et que la confiance se construise au lieu de s'éroder.
Technologies et outils associés
- Stockage vectoriel : l'index qui conserve les représentations de passages et répond efficacement aux requêtes de similarité.
- Modèles d'embedding : le composant qui transforme le texte en la forme numérique comparée lors de la récupération.
- Rerankers : une seconde passe qui réordonne les passages récupérés selon leur pertinence, souvent l'amélioration de qualité la moins chère disponible.
- Recherche hybride : combiner correspondance de mots-clés et recherche par similarité, ce qui rattrape les références exactes comme des codes produits que la similarité seule manque.
- Jeux d'évaluation : un ensemble fixe de vraies questions avec leurs sources attendues, rejoué à chaque modification, pour que la qualité devienne mesurable plutôt qu'anecdotique.
Conclusion
Le RAG est un problème de recherche documentaire déguisé en sujet d'IA. Les équipes qui le traitent comme un problème de modèle passent des mois à changer de fournisseur et à régler des prompts, alors que la vraie faute se situe dans le découpage, les métadonnées ou un index que personne n'a rafraîchi.
Le chemin fiable est peu spectaculaire : un ensemble documentaire avec un propriétaire clair, assaini avant indexation, enrichi de métadonnées, découpé en fonction de vraies questions, avec les sources affichées dans l'interface et l'autorisation pour le système d'admettre qu'il ne sait pas. Cette version gagne la confiance en quelques semaines. La version astucieuse qui saute la préparation documentaire ne la gagne généralement jamais.
