BLOG | RAG et IA générative : stratégies avancées pour des réponses plus fiables

Lorsqu’on évoque l’IA générative, le terme RAG (Retrieval Augmented Generation) apparaît fréquemment. Cette technique permet à un LLM (Large Language Model) de répondre de manière précise à des questions basées sur des documents ou une base de connaissances spécifiques. Toutefois, le RAG présente certaines limites qui peuvent entraîner des déceptions. Pour exploiter pleinement cette méthode, il est crucial de comprendre son fonctionnement technique et d'appliquer diverses stratégies pour en améliorer les performances. Dans cet article, nous vous présenterons les approches les plus efficaces pour révéler le plein potentiel du RAG.

Le fonctionnement du RAG a des limites

La technique du RAG est de plus en plus courante grâce à sa simplicité de mise en œuvre, son faible coût et son accessibilité à divers profils techniques. Cependant, elle présente des limites, notamment lorsque les cas d'usage deviennent plus spécifiques et complexes. Pour maximiser son efficacité, il est essentiel de bien définir le projet en établissant des objectifs clairs et réalisables afin d'éviter le piège du « toujours plus ». Les stratégies mises en place doivent répondre à des besoins précis pour atteindre les performances attendues. Avec les LLMs, les possibilités sont vastes et il est facile de vouloir toujours plus. Il est donc primordial de réfléchir et de définir les choix dès le début du projet, en prenant en compte toutes les contraintes : temporelles, financières, écologiques, ainsi que celles liées à la performance.

Avant toute chose, il est indispensable de comprendre le fonctionnement technique du RAG dans son ensemble. Cette technique peut être représentée en quatre grandes étapes.

Étape 1 : Construction de la base de données vectorielle

Cette première étape, la plus longue, consiste à construire la base de données vectorielle. On commence par récupérer le contenu des documents pour créer la base de connaissances. Le contenu est ensuite découpé en "chunks", ou petits morceaux, afin de pouvoir être traité par des modèles qui transforment le texte en vecteurs qu’on appelle embeddings. La taille réduite des chunks permet de mieux segmenter l'information. Ces chunks, accompagnés de leurs embeddings et des métadonnées associées, sont ensuite insérés dans la base de données vectorielle, qui servira de base de connaissances. Les métadonnées permettent de mettre en place des filtres performants afin de ne requêter que les chunks correspondant au besoin (par exemple, une question sur une thématique précise, liée à un document spécifique, etc.).

Cette étape n'est réalisée qu'une seule fois par document ; une fois traité et intégré à la base vectorielle, le document n'a plus besoin de repasser par cette étape.

Étape 2 : Génération du vecteur de la question

Lorsque l'utilisateur pose une question, il est nécessaire de générer un vecteur correspondant à cette question en utilisant le même modèle d'embeddings que celui de l'étape 1. Ce vecteur joue un rôle crucial dans la recherche des chunks pertinents pour répondre à la question.

Étape 3 : Recherche de similarité

Grâce à l'embedding de la question, nous effectuons une recherche de similarité entre celle-ci et l'ensemble du corpus présent dans la base de données vectorielle. La similarité la plus couramment utilisée est la similarité cosinus, qui permet d'obtenir un score de similarité entre deux vecteurs en fonction de l'angle qu'ils forment. Cette similarité est ainsi calculée entre le vecteur de la question et chaque vecteur représentant un chunk.En utilisant les scores obtenus, nous pouvons facilement récupérer les chunks les plus proches (d'un point de vue vectoriel) de la question de l'utilisateur. Si les vecteurs sont proches, cela signifie qu'il y a de grandes chances que ces chunks abordent le même sujet que la question et contiennent donc l'information nécessaire pour y répondre.

Étape 4 : Génération de la réponse

Enfin, il ne reste plus qu'à fournir au LLM la question de l'utilisateur accompagnée des chunks récupérés, et de lui indiquer comment se comporter grâce à un prompt system bien conçu, afin de générer une réponse à la question de l'utilisateur.

La mise en place d'un tel processus est désormais relativement simple et ne demande pas un temps prohibitif, grâce aux nombreux outils et frameworks développés ces dernières années suite au boom de l'IA générative. Cependant, dans des cas d'utilisation spécifiques et plus complexes, le RAG peut rapidement devenir décevant et ne pas répondre aux attentes. Les réponses peuvent manquer de précision, ne pas répondre réellement à la question, ou contenir des informations qui ne correspondent pas totalement à celles de la base de connaissances. Bien que les étapes présentées soient théoriquement efficaces, elles peuvent atteindre des limites en pratique, rendant les résultats non optimaux.

Ces problématiques peuvent transformer le RAG d'une solution magique en une technique qui ne répond pas aux cas d'usage et que l'on laisse de côté. Cependant, il existe plusieurs stratégies qui peuvent être mises en place pour améliorer grandement les résultats. Ces stratégies nécessiteront plus de temps de développement (tout en restant raisonnable) et des analyses plus poussées de différentes métriques.

La mise en place de stratégies pour révéler le plein potentiel du RAG

Pour résoudre les problématiques liées au RAG, de nombreuses stratégies peuvent être mises en place. Les stratégies les plus efficaces dépendent du cas d'usage spécifique, il est donc crucial de définir rapidement des métriques pour analyser les résultats et les impacts de chacune d'elles sur les performances. La principale source de limitation du RAG provient de la partie Retrieval (récupération des chunks pertinents), c'est pourquoi les métriques essentielles se concentrent sur cet aspect. Un chunk est considéré pertinent s'il apporte des informations permettant de répondre à la question. Parmi les métriques les plus intéressantes, on trouve la précision (pourcentage de chunks pertinents récupérés parmi tous les chunks récupérés), le rappel (pourcentage de chunks pertinents récupérés parmi tous les chunks pertinents) et des métriques qui tiennent compte de l'importance de l'ordre de classement des chunks, comme la NDCG ou la MMR.

Une fois ces métriques en place, il est intéressant de développer différentes stratégies pour améliorer les performances. Voici une sélection de certaines des méthodes ayant le plus fort impact sur la partie Retrieval :

• Récupération des informations : Insérer les informations dans la base de données vectorielle est une étape cruciale. La récupération du texte des documents est souvent simple, mais devient complexe lorsque les documents contiennent des tableaux ou des images. Dans ces cas, il est essentiel d'utiliser des techniques avancées, comme les modèles d'IA (notamment l'OCR), pour extraire les informations de manière structurée. Les LLMs étant très performants avec le markdown (système de balisage simple), utiliser des modèles qui extraient le contenu des documents sous ce format peut améliorer la qualité des informations fournies au LLM. Avoir une base de données vectorielle bien structurée avec du contenu de qualité est essentiel pour maximiser les performances lors de la partie retrieval (mais également lors de la génération de la réponse).
• Paramétrage : Le bon fonctionnement du RAG dépend du paramétrage précis de ses différentes briques, ajusté grâce aux métriques. Parmi les paramètres importants, on trouve, entre autres, la taille des chunks, la taille de l'overlap des chunks (recouvrement), et le nombre de chunks récupérés lors d'une requête.
• Optimisation des vecteurs de question : Le RAG se base sur la similarité entre vecteurs, il est donc crucial que le vecteur de la question soit pertinent. Les formules de politesse comme "Bonjour", "Merci", "j’aimerais savoir", etc., n'apportent aucune information utile. Il peut être intéressant de reformuler la question de l'utilisateur avant de la vectoriser et d'effectuer la recherche. Un LLM peut être utilisé pour générer une reformulation optimisée.
• Utilisation des sparse embeddings : Les modèles d'embeddings capturent les informations sémantiques du texte, mais perdent les informations des mots présents. Pourtant, il est logique qu'un chunk contenant des mots similaires à la question soit considéré comme pertinent. En ajoutant des sparse embeddings (opposés aux dense embeddings), qui capturent ces données grâce à une autre méthode de vectorisation, on peut réaliser des requêtes hybrides dans la base vectorielle. Les modèles les plus couramment utilisés pour générer ces embeddings sont BM25 ou BGE-M3. Les vecteurs ainsi générés sont majoritairement vides (pleins de zéros) puisqu'ils représentent l'utilisation des mots. La requête utilise à la fois les dense embeddings pour l'information sémantique et les sparse embeddings pour les mots. Les résultats sont ensuite fusionnés (la méthode la plus courante étant la Reciprocal Rank Fusion (RRF)) pour obtenir les chunks pertinents finaux.
• Reclassement sémantique : Après avoir effectué la requête et récupéré les chunks pertinents, on peut utiliser un modèle d'IA spécialisé en reclassement sémantique (reranker). Ces modèles, conçus pour évaluer la similarité sémantique entre une question et un document, améliorent les résultats en mettant en avant les chunks les plus appropriés. Bien que ces modèles présentent des limites, telles qu'un temps de calcul long et des restrictions sur la taille des entrées, ils permettent d'affiner les résultats après une première requête hybride. Cette requête initiale reste nécessaire, car il n'est pas viable de traiter un très grand nombre de chunks avec ce type de modèle (à cause des limites citées précédemment).

Le RAG est composé de plusieurs briques techniques, chacune ayant ses propres paramètres et problématiques. Nous nous sommes concentrés principalement sur la partie retriever car c’est dans la majorité des cas celle-ci qui a l’impact le plus important sur les performances, cependant il peut être nécessaire de maîtriser et de mettre en œuvre certaines méthodologies pour les autres briques. Voici un schéma non exhaustif des différentes questions à se poser lors de la mise en place de chacune d’entre elles :

Beaucoup de stratégies permettent d'améliorer les résultats, mais leur efficacité dépend du cas d'usage et du cahier des charges du projet. Ce dernier doit être au cœur de la modélisation de la solution afin d'adapter au mieux le processus aux besoins réels. Cependant, il est important de noter que, malgré la mise en place de toutes ces techniques, si les documents initiaux ne contiennent pas les informations nécessaires pour répondre à une question, le RAG ne sera pas une solution magique et ne pourra pas fournir de réponse adéquate. Il pourrait même générer des informations erronées (hallucinations), d'où l'importance cruciale du travail de construction du corpus.

En réalité, il existe de très nombreuses « techniques » de RAG

Dans cet article, nous avons principalement abordé les stratégies d'amélioration de la partie Retrieval, car c'est cette brique qui a le plus grand impact sur les performances. Nous nous sommes également concentrés sur l'approche classique du RAG. Cependant, ces derniers mois, de nombreuses autres techniques basées sur le RAG ont émergé : self-RAG, CRAG, GraphRAG, FRAG, AirRAG, et bien d'autres encore.

Le but ici n'est pas de détailler chacune de ces techniques, ce qui serait bien trop long. Je vous encourage à aller les découvrir et les explorer si cela vous intéresse. Voici cependant une sélection de quelques papiers sur certaines des techniques les plus utilisées :

Self-RAG : 2310.11511

CRAG : 2401.15884

GraphRAG : 2404.16130

Le principe général de ces techniques est de complexifier le pipeline du RAG (présenté au début de cet article) en intégrant un LLM au cœur des différentes étapes. Cela permet d'apporter de l'intelligence à chacune d’entre elle pour améliorer les performances. Par exemple, on peut faire appel à un LLM pour évaluer les chunks en rapport avec une question, vérifier si la réponse est pertinente, utiliser plusieurs LLMs avec différents systèmes de prompting, puis un LLM pour synthétiser les différentes réponses, etc.

Les techniques sont nombreuses et variées, et avec les LLMs, de nombreuses solutions sont envisageables. Cependant, ces méthodes apportent de nouvelles problématiques structurelles et éthiques. Pour une simple question, de nombreux appels à un LLM peuvent être nécessaires, ce qui pose des problèmes de coûts, de disponibilité, de temps de réponse, et bien sûr, un enjeu écologique majeur, car ces technologies sont très énergivores (sans parler des ressources rares nécessaires à la création de l'infrastructure). Pour résoudre ces problèmes, il est envisageable de limiter le nombre d'appels, de privilégier des modèles plus légers et spécifiques au cas d'usage, etc.

Le RAG est une technique simple qui permet d'améliorer rapidement et efficacement les résultats produits par un LLM. Cependant, des limites peuvent rapidement apparaître, et des stratégies plus avancées, intégrant de nouvelles briques technologiques comme des modèles de vectorisation différents ou d'autres types de modèles d'IA, peuvent être utilisées pour y remédier. Les métriques jouent un rôle majeur dans l'amélioration du RAG et il est indispensable de les mettre en place pour évaluer et optimiser les performances. Le cas d'usage et le cahier des charges du projet restent les éléments moteurs de la réussite d'un projet basé sur l'IA générative, car ils permettent d'adapter le processus avec les stratégies et méthodologies les plus adéquates pour obtenir un projet performant répondant pleinement aux attentes.