Introduction

Les Large Language Models (LLMs) sont des outils formidables, capable de répondre de manière convaincante quelle que soit la question posée. Malheureusement, cette capacité à convaincre est une arme à double tranchant. En effet, sous couvert d’un raisonnement en apparence logique, les faits énoncés peuvent être totalement faux. Cela peut être causé par l’absence de documents dans le corpus d’apprentissage, à cause de leur nouveauté, de leur rareté ou bien encore de l’aspect confidentiel.

De plus, dans certain cas d’usage engageant la responsabilité de l’utilisateur du LLM, il est nécessaire de pouvoir donner les sources utilisées pour répondre à la question. C’est le cas sur des clauses contractuelles par exemple où la réponse est moins importante que la manière d’y parvenir.

Ces cas d’usage sont regroupés sous le terme d’« application à usage intensif de connaissance ». Dans ce cadre, on souhaite surtout accéder à de la connaissance par opposition à des applications de traduction ou de reformulation par exemple. On souhaite donc utiliser la puissance de compréhension et de synthèse de LLMs tout en garantissant l’exploitation d’une base de connaissance contrôlée, tout cela en citant ces sources. Ce meilleur des mondes existe, il est basé sur les RAG: “Retrieval Augmented Generators”

Un RAG est un système basé sur les LLM pour aller chercher de l’information dans un corpus contrôlé par l’utilisateur puis de synthétiser une réponse à partir d’éléments choisis.

Principaux composants

Un RAG est une architecture mettant en jeu plusieurs composants. Avant de présenter l’architecture complète, nous allons zoomer sur les principales parties.

Embedding

Le premier concept d’un RAG est l’embedding. En effet, un ordinateur ne peut pas manipuler directement les mots ou les phrases. Il est nécessaire de les transformer en valeurs numériques sur lesquelles il est possible de calculer. Il est important que cette transformation conserve la proximité sémantique, c'est-à-dire que deux concepts proches sémantiquement sont proches numériquement.

Il existe heureusement des modèles pré-entrainés adaptés à cette tâche, les “sentences embedding” dérivés de BERT. Cette opération peut demander pas mal de calcul, même si les modèles sont plus petits que les LLMs. Récemment a même été proposé des modèles spécifiquement pour améliorer les temps d’inférence.

Document Chunking

Le corpus contenant la connaissance à exploiter par le RAG n’est pas utilisable directement. Il doit être découpé en petits morceaux, les chunks (avec potentiellement un overlap). Comme nous l’avons vu, ces chunks ne sont pas utilisables directement et doivent être transformé via un embedding. De plus, il est important de garder la métadonnée autour des chunks, par exemple le fichier source d’où il est tiré, le chapitre à l’intérieur du document, la date de dernière mise à jour, etc.

La taille du corpus peut être grande et le stockage et la récupération de ces chunks pose de nouveaux problèmes, c’est là qu’interviennent les vector DB.

Système d'information spécialisé : Bases de données vectorielles

Pour répondre à une question donnée, un RAG calcule un embedding de la question et va chercher les chunks pertinent. Comme les embeddings préservent la notion de distance sémantique, trouver des documents pertinents revient en fait à trouver des documents proches, en termes de distance, dans l’espace des embedding. On peut donc formaliser le probleme de trouver les documents pertinent par “trouve les k chunks les plus proches dans l’espace d’embedding”. Cette opération doit être peu couteuse, même avec un corpus de grande taille. C’est là qu’interviennent les vectorDB.

Afin de résoudre ces problèmes, il n’est plus possible d’utiliser des bases de données relationnelles type mySQL, ou no-SQL type REDIS. La manière dont y est stocké l’information n’est pas adaptée aux types de requête faire dans un RAG.

Heureusement, il existe des bases de données designées spécifiquement à certaine tâche, comme les base TimescaleDB pour les time series, ou bien encore postGIS pour les données géographiques. Ici, ce sont donc les vector DB qui vont répondre à notre problème. Elles stockent de manière optimisée les embeddings de telle sorte qu’il est possible de trouver les L vecteur les plus proches d’un vecteur donné. On retrouve donc ici des acteurs comme ChromaDB, Qdrant, ou bien PGVector.

Donc à la fin de cette étape, le RAG a retrouvé dans la base de donnée, les k chunks les plus pertinents pour la question posée. Ils sont donc transférés au LLM pour fournir la réponse finale.

LLM

La question de l’utilisateur et les chunks sont assemblés afin de constituer un prompt qui est donc fourni en entrée à un LLM, type LLaMa 2, Falcon, etc. de manière classique. Il est à noter que la tâche de créer une réponse à partir d’éléments fournis au LLM est plus simple que de devoir tout générer. Ainsi, même avec un LLM de “petite” taille (7b) on obtient déjà des résultats très pertinents.

L’architecture RAG

Avec les éléments précédents, nous pouvons présenter l'architecture complète d'un RAG. Tout d'abord, la VectorDB est peuplée avec les embeddings et les métadonnées des chunks issus de la base de documents. La requête arrive et son embedding est calculé. Les K chunks les plus pertinents sont extraits de la VectorDB. La question et les chunks sont combinés pour créer un prompt. Ce prompt est transmis à un LLM, qui fournit la réponse.

Cette réponse peut également être augmentée avec les sources utilisées, grâce aux métadonnées associées aux chunks.

Techniquement, cette architecture générale est classique et on a pu identifier les différentes briques nécessaires à sa construction. En pratique, des librairies Python telles que Langchain ou LLamaIndex permettent, de façon efficace, de choisir le LLM, le modèle d’embedding, la Vector DB, ainsi que leurs paramètres, et de les combiner efficacement.

Conclusion

L’architecture RAG propose donc de très nombreux avantages par rapport à l’utilisation d’un LLM seul. On peut lister les éléments suivants :

• Fiabilité : par l’utilisation d’une base de connaissance contrôlée par l’utilisateur, la probabilité d’hallucination est fortement réduite.
• Confiance : Les sources utilisées pour la génération sont données. Si une forte responsabilité de l’utilisateur est engagé, il peut directement se référer aux sources.
• Efficacité : Le LLM utilisé pour générer la réponse peut être de taille largement plus petite qu’un GPT-4 pour des résultats. Cette architecture évite de finetuner un modèle sur son corpus. De plus, même avec peu de document, il est possible d’avoir un RAG pertinent.
• Souplesse : La modification de la base de connaissance se fait simplement via l’ajout de documents à la vectorDB.

Cette architecture est déjà très efficace avec des briques génériques. Il est possible d’améliorer encore leurs performances via le fine-tuning. On peut ré-entraîner le LLM sur une base de données questions-documents-réponse, qui peut par exemple être générée par un plus gros modèle (comme GPT-4) et ainsi améliorer la qualité de la réponse générée.

En outre, il est possible de modifier cette architecture afin d’incorporer la capacité à utiliser des outils. On parle alors d’« agents ». Dans ce cadre, avant de répondre directement à la question posée, un LLM peut choisir de faire appel à un outil, par exemple une recherche en ligne, une API, une calculatrice, etc. Ainsi, le LLM peut lui-même choisir la requête à effectuer dans la Vector DB, Il peut dans ce cadre combiner le RAG avec d’autres outils, comme la recherche en ligne.

Si les RAGs offrent de nombreux avantages, ils restent des systèmes de machine learning. Leurs performances doivent être bien mesurées et leurs utilisations monitorées en permanence, notamment à cause de la dynamicité de la base de connaissance. Les métriques à observer font l’objet d’étude approfondie, mais on y retrouvera par exemple des métriques de performance sur la qualité des résultats et aussi des métriques sur la sécurité comme celles autour de la toxicité.

Envie d’en savoir plus sur comment déployer un LLM domain specific, et faire un test de RAG avec vos propres données ? Prenez RDV ici.