Retrieval Augmented Generation (RAG) : tout savoir

Une fois que des LLM sont entraînés sur un très grand corpus, ce dernier se veut le plus généraliste possible pour capter énormément de situations et de contextes, pour apporter des réponses précises. Seulement, ces LLM ne sont pas en mesure d'avoir accès à une base de connaissances personnalisée, sur des documents de tous types dans une entreprise par exemple.

Aujourd'hui, avec l'avènement des LLM, il pourrait alors être intéressant de se baser sur leurs capacités de généralisation afin de pouvoir comprendre et exécuter automatiquement les requêtes formulées lorsqu'un utilisateur cherche une information précise dans une base de connaissances existante. Cette approche est le Retrieval Augmented Generation (ou RAG), qui consiste à combiner un algorithme de recherche d'information, avec un LLM qui sera en mesure de comprendre la requête et d'apporter une réponse détaillée à l'utilisateur.

Dans cet article, nous allons voir le fonctionnement du RAG, ses prérequis et comment il est possible de développer son propre RAG.

Qu'est-ce que le RAG ?

Il est possible d'ajouter un contexte lorsque l'on communique avec un LLM, notamment afin de lui fournir des informations supplémentaires, comme des définitions, des exemples ou des situations. Seulement, lorsque ce contexte est définie à l'aide de nombreux documents (PDF, Word, etc), il n'est plus possible d'encapsuler toutes ces informations dans un seul contexte.

De plus, il a été documenté que la pertinence des réponses apportées par un LLM décroit lorsque la taille du contexte augmente. Plus on fourni de mots en entrée à un LLM, mois il sera capable d’emmagasiner toute l'information disponible.

Introduit par les équipes de recherche en IA de Meta, le Retrieval Augmented Generation (RAG) est une approche qui consiste à intégrer un mécanisme de recherche d'informations plutôt que de se baser sur un contexte appris lors de la phase d'entraînement, ou lorsqu'il est défini par l'utilisateur lui-même.

À lire : découvrez notre formation LLM Engineering

En particulier, cela permet d'apporter une base de connaissances sous la forme de documents de tout types, afin d'enrichir le LLM avec l'apport d'informations supplémentaires qui en serait pas publiques, ou qui seraient trop spécialisés pour avoir été utilisées lors de la phase d'entraînement.

Comment fonctionne le RAG ?

De manière synthétique, les RAG sont constitués de deux étapes principales.

• Une étape de récupération (retrieval) qui a pour but d'extraire des informations pertinentes depuis la base de connaissances, que ce soit dans une base de données ou dans des documents. Bien que cette recherche puisse se faire sur des mots-clés, les techniques modernes utilisent plutôt des méthodes basées sur l'embedding que nous allons détailler.
• Une étape de génération où, une fois l'information recherché extraite, un LLM va générer une réponse en langage naturel. L'intérêt d'utiliser un LLM ici est de ne pas directement fournir l'information extraite en brut à un utilisateur, mais de l'embellir avec un texte en langage naturel. À cette étape, plusieurs LLM comme GPT, LLaMa ou encore Mistral peuvent être utilisés.

Concentrons-nous surtout sur l'étape de génération, qui nécessite le plus de personnalisation.

Loader et Splitter

La toute première étape pour construire un RAG est de référencer et centraliser tous les documents qui doivent être utilisés comme base de connaissances. Ces documents peuvent être de natures diverses : fichiers textes ou Word, présentations, PDF, pages Web ou même des transcriptions de vidéos YouTube. Certains frameworks comme LangChain disposent de nombreuses intégrations pour pouvoir charger facilement différents types de documents sans développer soi-même de nouvelles fonctionnalités.

Une fois que les documents sont chargés, il est ensuite nécessaire de les transformer intelligemment, notamment puisque l'on souhaite à minima découper un document de plusieurs pages en plusieurs blocs de texte. Cette étape est réalisée par l'intermédiaire d'un splitter, dont le rôle est de découper efficacement les documents en blocs de textes qui sont reliés sémantiquement.

Tout d'abord, le splitter commence par découper le texte en petits blocs, souvent de la taille d'une ou deux phrases. Ensuite, il va combiner ces blocs pour en former des plus grands sans dépasser une certaine taille. Enfin, il va répéter l'opération avec le l'overlapping, c'est-à-dire faire chevaucher une partie des blocs entre-eux pour conserver un minimum de contexte entre deux blocs successifs.

Par exemple, sur l'image suivante, on obtient différents blocs basés sur l'article Wikipédia du journal Le Monde.

Embedding

L'embedding est une méthode d'encodage qui vise à représenter des mots ou une partie d'un mot (comme une syllabe) par des vecteurs. En cherchant à construire des vecteurs dans un espace à grande dimension (200, 500 voir plus), cette représentation permet d'effectuer des calculs numériques sur des mots, comme de la recherche sémantique, car les vecteurs associés aux mots d'un même contexte seraient proches entre-eux (au sens de la similarité cosinus par exemple).

Le choix de l'embedding est très important, car c'est justement sur ce dernier qu'un RAG se base pour déterminer précisément le champ sémantique lié à une requête formulée par l'utilisateur : plus l'embedding est précis, plus le RAG saura de quoi parle l'utilisateur et sera plus à même d'apporter une réponse pertinente.

Vector Store

Comme nous venons de l'indiquer, les vecteurs sont au cœur des LLM et des RAG, car ils permettent de représenter les mots sous forme de vecteurs, en encapsulant un maximum d'informations par rapport aux contextes où ce mot a été identifié. Ainsi, il est donc important pour nos algorithmes de pouvoir facilement et rapidement accéder aux informations vectorielles de chaque mot.

Or, lorsque ces vecteurs sont enregistrés sur le disque dur, les temps de lecture et décodage de données peuvent freiner la vitesse de réponse apportée. Pour cela, des bases de données vectorielles ont été mises au point pour faciliter la lecture et l'écriture de vecteurs d'embedding, notamment en stockant intelligemment les vecteurs lorsque ceux-ci sont similaires.

Il existe plusieurs bases de données vectorielles qui peuvent être exécutées localement, comme Chroma ou FAISS, mais aussi des bases managées dans le Cloud comme Pinecone ou Weaviate.

Retrieval

La dernière étape du RAG, et qui est également l'une des plus critiques, est l'étape de recherche d'informations dans la base de connaissances. Tout l'intérêt des retrievers et de trouver la source d'une information demandée par un utilisateur.

Cela peut être par exemple une réponse précise (une date, un nom ou un identifiant) mais également un paragraphe si l'utilisateur demande un extrait ou si le contexte associé doit être fourni dans la réponse.

À noter qu'en théorie, rien n'oblige à ce que le retrieval utilise une base de données vectorielle pour rechercher la source d'une information, mais la plupart des retrievers utilisent tout de même ce type de base de données.

À découvrir : notre formation LLM Engineering

Il existe des frameworks qui peuvent déjà de proposer tout un ensemble de composants permettant de construire ses propres RAG. C'est le cas par exemple de LangChain, où toutes les briques de construction d'un RAG sont disponibles, de la partie chargement de données jusqu'au retrieval, et même avec les fonctionnalités supplémentaires comme l'indexation.

Avantages et risques d'utilisation d'un RAG

L'utilisation d'un RAG présente de nombreux avantages.

• Pour des entreprises notamment, cela permet d'apporter toute une documentation interne rapidement et facilement accessible pour les collaborateurs : la pertinence des réponses est donc beaucoup plus importante par rapport à un LLM sans RAG. Cette documentation interne peut être de nature diverse, comme l'ensemble des documents de fonctionnement interne (CE, règlement intérieur) ou sur des documents permettant de gagner en efficacité. Il s'agit d'ailleurs de l'un des premiers cas d'usage généralement développé en interne dans les entreprises, car il est plutôt rapide à mettre en place et moins sensible qu'un LLM exposé publiquement.
• L'autre principal intérêt du RAG et de pouvoir actualiser des informations qui proviennent de différentes sources (pages Web, documents, etc) sans devoir à chaque fois passer par une étape d'entraînement. Cela permet ainsi d’accélérer la mise à disposition d'information actualisées aux utilisateurs sans devoir attendre des mises à jours de la part des développeurs.

Néanmoins, il y a tout de même certains risques qu'il ne faut pas sous-estimer, d'autant plus lorsque les réponses d'un RAG peuvent être utilisées pour des sujets critiques, comme la médecine ou le juridique.

• Puisque la réponse reste générée par un LLM et que le RAG se base également sur des contextes, l'information obtenue n'est pas toujours vraie dans 100% des cas, elle peut être erronée. Pour pallier à ce sujet, il est recommandé de vérifier la source de l'information lorsque le RAG fournit une réponse, d'autant plus qu'il est capable de donner le document où l'information a été obtenue.
• Des informations sensibles peuvent être présents dans la base de connaissances, et donc un utilisateur pourrait avoir accès à une information dont il ne serait pas censé avoir accès. Cela pourrait survenir par exemple dans le cas d'un RAG de service client qui aurait accès à toutes les informations des utilisateurs, ce qui autoriserait un utilisateur de connaitre les commandes d'un autre utilisateur. Pour éviter cette situation, il est nécessaire de vérifier que la base de connaissances ne dispose pas d'informations sensibles, et de déterminer les autorisations d'un utilisateur avant de pouvoir effectuer une recherche spécifique.

Conclusion

Mis sur le devant de la scène avec les nouveaux modèles de LLM, le RAG est l'une des techniques les plus utilisés lorsque des entreprises souhaitent développeur leur propre LLM, que ce soit pour des besoins en interne, ou pour exposer directement un service à des clients (agent de service client par exemple).

L'étape la plus décisive pour un RAG consiste à déterminer quels seront les documents susceptibles d'apporter la réponse à la question ou la demande d'un utilisateur. Avec un couche de génération de texte alimentée par un LLM, le résultat est d'autant plus concis et agrégé pour l'utilisateur sans devoir effectuer des recherches qui peuvent s'avérer laborieuses.