Qu'est-ce que la génération augmentée par la recherche (RAG) ?

Génération assistée par la recherche (RAG) Il s'agit d'une architecture d'IA qui récupère des documents externes pertinents au moment de la requête et qui entraîne un grand modèle linguistique (LLM) à partir de ces documents afin de produire des réponses fondées sur des informations actuelles et vérifiables. Contrairement à un LLM « pur » qui s'appuie uniquement sur ses paramètres d'entraînement, un système RAG sépare ce que le modèle sait d'après ce que lève les yeux, ce qui en fait un outil pratique pour les tâches où la précision et l'actualité sont toutes deux essentielles.

Comment fonctionne RAG ?

RAG associe deux composants : un « retriever » qui identifie les passages pertinents et un générateur (le LLM) qui lit ces passages et produit une réponse. Patrick Lewis et ses coauteurs ont présenté cette architecture lors de la conférence NeurIPS 2020, en associant un modèle seq2seq pré-entraîné (mémoire paramétrique) à un index vectoriel dense de Wikipédia accessible via un système de recherche neuronal (mémoire non paramétrique). Leur article indique que le RAG produit des résultats « plus précis, plus variés et plus factuels » qu’un modèle de référence exclusivement paramétrique (Lewis et al., « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks » (NeurIPS 2020), arXiv 2005.11401, 2020).

Lors de l'exécution, le pipeline fonctionne en trois étapes. Tout d'abord, la requête de l'utilisateur est encodée sous forme de vecteur et comparée à un ensemble de documents pré-indexés afin de faire ressortir les passages les plus pertinents. Ensuite, ces passages sont ajoutés à la fenêtre de contexte du modèle en tant qu'entrée supplémentaire. Enfin, le LLM génère une réponse qui combine ses connaissances paramétriques avec les éléments de preuve extraits.

Le magasin de documents est généralement une base de données vectorielle : un système qui stocke des représentations à haute dimension de segments de texte et permet d'effectuer rapidement des recherches par « voisin le plus proche » approximatif. Les bases de données vectorielles sous-jacentes aux applications RAG ont connu une croissance de 377 % d'une année sur l'autre, soit la croissance la plus rapide parmi toutes les catégories technologiques liées aux LLM suivies (Databricks, État des lieux des données et de l'IA (adoption en entreprise et tendances de croissance), 2024).

Pourquoi la méthode RAG est-elle devenue la norme en matière de mise à la terre ?

Les modèles de langage de grande envergure (LLM) figent leurs connaissances à la fin de la pré-formation. Tout élément susceptible d’évoluer après cette date butoir — qu’il s’agisse d’un prix, d’une réglementation ou des caractéristiques d’un produit — nécessite soit un nouveau cycle de formation, soit une couche de récupération. La technologie RAG permet de gérer cela à moindre coût. Au lieu de procéder à un réentraînement, il suffit de mettre à jour le référentiel de documents ; le modèle cite alors automatiquement les informations actualisées dès qu’une requête pertinente est formulée.

L'adoption par les entreprises témoigne de cet aspect pratique. L'approche RAG s'est imposée comme la méthode dominante pour ancrer les modèles de langage de grande envergure (LLM) dans des données propriétaires ou actuelles, son adoption passant de 31 % l'année précédente à 51 % des entreprises en 2024 (Menlo Ventures, 2024 : L'état des lieux de l'IA générative dans l'entreprise, 2024).

Un deuxième avantage réside dans la traçabilité. Les documents extraits faisant partie de la fenêtre de contexte, un développeur peut vérifier quels passages le modèle a utilisés et remonter jusqu'à la source des affirmations. Cela s'avère difficile, voire impossible, avec un modèle purement paramétrique.

Cas d'usage

Bases de connaissances d'entreprise. La documentation interne, les documents juridiques et les contenus d'assistance évoluent fréquemment. Un pipeline RAG indexe ces documents et permet aux collaborateurs ou aux clients d'effectuer des requêtes en langage naturel sans avoir à attendre le prochain ajustement du modèle.

Données Web en temps réel pour les agents d'IA. Les agents IA ont besoin d’informations actualisées, de pages produits, d’actualités et de résultats de recherche, qu’aucun corpus statique ne peut fournir. L’intégration de contenu Web en temps réel dans la couche de recherche permet à l’agent de disposer d’un contexte précis et à jour. L’Web Render API de Massive peut ici servir de couche source de données Web actualisées : le point de terminaison « Search » renvoie des résultats de recherche mis en forme (y compris des aperçus générés par l’IA via awaiting=ai), et le point de terminaison « Browsing » renvoie du code HTML ou Markdown « propre » à partir de n'importe quelle URL publique ; ces deux formats sont adaptés au découpage en segments et à l'intégration dans un pipeline RAG.

Code et documentation de l'API. Les API des bibliothèques évoluent à chaque nouvelle version. L'utilisation de RAG sur un corpus de documentation versionné permet à un assistant de programmation de citer la signature de méthode correcte pour la version en cours d'utilisation, plutôt que d'en fournir une obsolète.

Automatisation du service client. Les bots d'assistance s'appuyant sur un catalogue de produits en ligne, un document relatif à la politique de retour et un flux d'informations sur les problèmes connus fournissent des réponses précises et citent la politique applicable, ce qui permet de réduire le nombre de cas remontés à un niveau supérieur.

Bonnes pratiques

La taille des blocs a son importance. Les segments trop courts perdent leur contexte ; ceux qui sont trop longs affaiblissent le signal pertinent. La plupart des professionnels commencent par des segments de 256 à 512 tokens, avec un chevauchement de 10 à 20 %, afin d'éviter de couper une phrase en plein milieu.

Commencez par nettoyer vos documents sources. Les éléments standardisés, les textes de navigation et les publicités présents dans une page récupérée génèrent des représentations bruyantes et nuisent à la qualité des réponses. Si vous récupérez du contenu Web en temps réel, analysez-le pour le convertir en Markdown ou en texte brut avant de l'indexer.

Évaluez séparément la récupération et la génération. Une réponse de mauvaise qualité peut résulter d'une mauvaise récupération (le bon document n'a pas été renvoyé) ou d'une mauvaise génération (le modèle a ignoré un bon document). Le fait de distinguer les indicateurs de performance pour chaque étape vous aide à identifier et à corriger le composant concerné.

Actualisez l'index selon une fréquence adaptée au rythme des modifications apportées à la source. Un catalogue de produits mis à jour quotidiennement nécessite une réindexation quotidienne. Un corpus juridique mis à jour chaque trimestre peut être réindexé moins souvent. Les documents obsolètes présents dans le magasin de recherche constituent une source fréquente d'erreurs RAG.

Surveillez les limites de la fenêtre de contexte. Chaque fragment extrait consomme des jetons. Si le nombre de passages est important, vous risquez de dépasser la fenêtre de contexte du modèle ou d'affaiblir le signal. Une solution pratique consiste à reclasser les fragments extraits par ordre de pertinence et à ne conserver que les trois à cinq premiers.

Conclusion

Le RAG s’attaque au mode de défaillance le plus courant des grands modèles de langage (LLM) : des réponses plausibles, mais obsolètes ou erronées, car le modèle ne peut pas accéder à des informations au-delà de la limite de son apprentissage. En séparant la récupération de la génération, cette architecture permet au modèle génératif de se concentrer sur le raisonnement, tandis que le composant de récupération se charge de connaître les faits actuels. Le taux d’adoption par les entreprises a franchi la barre des 51 % en 2024, et l’infrastructure associée — bases de données vectorielles, API de recherche et couches d’accès au Web en temps réel — est désormais suffisamment aboutie pour que la plupart des équipes puissent mettre en place un pipeline RAG opérationnel sans expertise spécialisée en apprentissage automatique. Le principal défi technique ne consiste plus à savoir s’il faut utiliser le RAG, mais à déterminer à partir de quelles sources de données extraire les informations et comment garantir que ces sources restent à jour et fiables.

Foire aux questions

Le « fine-tuning » intègre de nouvelles connaissances dans les poids du modèle grâce à un apprentissage supplémentaire. La méthode RAG laisse les poids inchangés et fournit des informations actualisées au moment de l'inférence en récupérant des documents. Le « fine-tuning » est plus adapté pour enseigner à un modèle un nouveau style ou une nouvelle tâche ; la méthode RAG est plus adaptée pour maintenir les réponses à jour à moindre coût.

La méthode RAG réduit les hallucinations en fournissant au modèle le texte source sur lequel fonder sa réponse, mais elle ne les élimine pas pour autant. Le modèle peut toujours ignorer un passage extrait, le mal interpréter ou combler les lacunes avec des détails inventés. La qualité de l'extraction, la conception de la consigne et la vérification après génération ont toutes une incidence sur la fréquence à laquelle les hallucinations se produisent.

RAG effectue des recherches dans tout type de texte pouvant être segmenté et intégré : fichiers PDF, pages HTML, enregistrements de bases de données, fichiers Markdown, code ou tableaux structurés. La qualité des résultats dépend de la qualité du nettoyage et de la segmentation des documents sources avant leur indexation.

Une base de données vectorielle stocke les représentations vectorielles de fragments de texte et permet d'effectuer rapidement des recherches par similarité. Lorsqu'une requête est reçue, la couche de recherche effectue une représentation vectorielle de celle-ci et interroge la base de données vectorielle afin de trouver les fragments les plus proches. Cette recherche par similarité constitue le cœur de l'étape de recherche dans tout système RAG.

Oui. Au lieu d'utiliser un index statique pré-construit, la couche de recherche peut récupérer des pages web en temps réel au moment de la requête et en extraire le texte pertinent avant de le transmettre au LLM. Cette approche privilégie la précision en temps réel au détriment de la prévisibilité offerte par un index stable, au prix d'une latence plus élevée par requête.