Il est temps de regarder la vérité en face à propos de la génération augmentée par récupération, ou RAG : c’est une solution qui a besoin de sa propre solution.
La RAG avait pour objectif d’améliorer les performances des grands modèles de langage (LLM) et de réduire les hallucinations en permettant à ces derniers d’aller au-delà de leurs données d’entraînement grâce à l’accès à des bases de connaissances externes. Cependant, les limites réelles des systèmes RAG traditionnels sont devenues douloureusement évidentes.
« Dans une large mesure, la RAG est imparfaite, déclare Dinesh Nirmal, vice-président senior d’IBM Software. La RAG pure ne donne pas vraiment les résultats optimaux escomptés. »
Les défis auxquels les utilisateurs sont régulièrement confrontés avec la RAG comprennent les limites des fenêtres contextuelles et des opérations d’agrégation, l’incapacité à comprendre les relations complexes et la mauvaise qualité des résultats associés à un découpage en morceaux sous-optimal. En outre, la mise en œuvre de la RAG peut également présenter des problèmes de sécurité tels que la fuite de données.
La bonne nouvelle, c’est que les progrès réalisés dans le domaine des outils et des stratégies d’intelligence artificielle contribuent à compenser les défauts de la RAG traditionnelle, ce qui se traduit par des réponses plus précises aux requêtes des utilisateurs. Examinons de plus près comment améliorer les performances de la RAG.
Souvent, demander à une application LLM alimentée par la RAG traditionnelle d’effectuer des opérations d’agrégation (telles que trouver une somme) pour un énorme jeu de données n’est pas difficile, mais littéralement impossible. L’un des facteurs qui entravent les performances du système est la taille des fenêtres contextuelles : les fenêtres contextuelles des LLM ne sont généralement pas suffisamment évolutives pour traiter, par exemple, une collection de 100 000 factures. De plus, le pipeline de RAG traditionnelle s’appuie sur des bases de données vectorielles, qui sont conçues pour les recherches par similarité, et non pour les opérations d’agrégation.
« Concrètement, cela signifie qu’une base de données vectorielle n’est pas suffisante pour traiter ces cas, explique Sudheesh Kairali, ingénieur émérite chez IBM. La fenêtre contextuelle pose problème. L’autre problème est l’incapacité à traiter les opérations mathématiques. »
C’est là qu’intervient la RAG SQL.
Lorsque les utilisateurs de LLM recherchent des réponses dans de jeux ensembles de données, la combinaison d’une génération augmentée de récupération avec un SQL peut fournir des résultats précis, explique M. Kairali.
SQL comprend des fonctions d’agrégation intégrées, et les bases de données SQL ont une capacité supérieure à celle des fenêtres contextuelles de LLM. Si une entreprise ingère ses données de facturation dans une base de données SQL, elle peut employer un LLM pour convertir des requêtes telles que « Quelle est la somme de toutes les factures de l’année dernière ? » en SQL, interroger la base de données SQL via la RAG et obtenir la réponse.
« Vous pouvez effectuer de nombreuses agrégations si vous savez les créer », explique M. Kairali. Une fois que la base de données SQL a effectué une agrégation, « il ne s’agit plus alors que d’un exercice de traitement automatique du langage naturel (NLP) pour le LLM ».
Discerner les liens entre les différentes informations ou entités récupérées est un autre point faible de la RAG traditionnelle. Prenons l’exemple d’un patient ayant des antécédents médicaux complexes. Grâce au processus de récupération de la RAG traditionnelle, un LLM pourrait fournir des informations pertinentes. Ces données pourraient inclure des détails tels que le nombre de médecins que le patient a consultés au cours d’une année, mais pourraient avoir du mal à préciser les traitements prescrits par chacun d’eux.
Introduit en 2024 par Microsoft Research, GraphRAG relève ce défi en traitant et en identifiant les relations à l’aide de graphes de connaissances. GraphRAG organise les informations sous la forme d’un réseau de nœuds et d’arêtes représentant des entités et leurs relations entre elles.
« Si un patient s’est rendu à l’hôpital et que la question est de montrer toutes les visites précédentes qu’il a effectuées, cela peut être présenté non seulement sous forme de texte, mais aussi sous forme de représentation des connaissances via un graphe, explique M. Nirmal. Vous pouvez examiner divers angles et voir les différents médecins qu’il a consultés, les médicaments qu’il a pris, les traitements suivis, le tout dans une seule représentation graphique. »
Selon M. Nirmal, GraphRAG a toutefois ses limites, car le rendu d’un graphique se complexifie à mesure que le volume de données augmente. Il est par exemple plus difficile de cartographier des centaines de milliers de nœuds que quelques dizaines seulement. « Tout a ses limites, dit M. Nirmal, mais si GraphRAG connaît un tel succès, c’est précisément à cause des limitations de la RAG pure. »
Le découpage est essentiel pour les applications RAG. Dans le découpage traditionnel par modèles d’embedding, les documents pertinents sont divisés en morceaux plus petits à des points fixes, chacun étant représenté dans une base de données vectorielle. Cependant, cette méthode peut amener une application LLM à fournir des réponses incomplètes ou inexactes, même lorsqu’elle emploie un algorithme de machine learning de recherche sémantique sur une base de connaissances spécifique à un domaine.
« Ce processus entraîne souvent une perte de précision car vous ne savez pas où vous fragmentez les données, explique M. Nirmal. Imaginons que vous ayez fragmenté ou découpé un tableau en deux. Lorsque vous récupérez le tableau, vous n’en récupérez que la moitié. Vous avez donc perdu en précision. »
Heureusement, de meilleures stratégies de découpage par des méthodes agentiques peuvent améliorer la récupération d’informations. Ce découpage agentique comprend des stratégies telles que la création de fragments qui se chevauchent et la modification dynamique de la taille des fragments en fonction du contexte dans les documents récupérés. Les cadres d’orchestration LLM peuvent être utiles à cette fin. Ainsi, les outils TextSplitters de LangChain peuvent diviser le texte en petits morceaux sémantiquement significatifs. De telles stratégies permettent d’éviter la perte d’informations pertinentes lors de la décomposition d’un document.
L’IA agentique est utile pour le découpage et peut également améliorer la précision de la récupération d’autres manières. Prenons l’exemple de la RAG agentique : il s’agit d’un cadre d’IA avancé qui peut intégrer des pipelines RAG pour interroger à la fois les données structurées dans les bases de données SQL et les données non structurées dans les référentiels de documents, en exploitant les bases de données vectorielles pour la recherche de similitudes.
La RAG agentique enrichit également chaque fragment avec des métadonnées. Ce processus met en corrélation les données structurées (les métadonnées stockées dans une base de données transactionnelle) avec les données non structurées afin d’optimiser la précision de la récupération.
« Si nous parvenons réellement à exploiter le potentiel d’une base de données vectorielle tout en tirant parti de son volet transactionnel ou SQL, et à réunir ces deux dimensions, nous pourrons améliorer de manière significative la précision et les performances », a déclaré M. Nirmal.
Découvrez comment surmonter les trois principaux défis liés aux données non structurées.
La fuite de données est un problème connu des systèmes d’IA en général, et les LLM qui s’appuient sur la RAG ne font pas exception. Sans les mesures adéquates, un LLM peut fournir à des utilisateurs de bas niveau des informations auxquelles ils ne sont pas autorisés à accéder, qu’il s’agisse d’informations personnelles (PII) ou de données financières sensibles.
« C’est une réalité avec la RAG, explique M. Kairali. Lorsque vous commencez par une preuve de concept, tout le monde est content. Mais lorsque vous souhaitez passer à la production et vous assurer que le système y est prêt, vous commencez à comprendre qu’il existe un problème de protection des données. »
Pour résoudre ce problème, il faut préserver les listes de contrôle d’accès (ACL) et autres politiques de gouvernance lorsque des données non structurées sont intégrées à diverses bases de données. « Lorsque la requête arrive et que les données sont récupérées, il est important de s’assurer que les ACL et les politiques de gouvernance sont respectées, explique M. Kairali. Il s’agit essentiellement d’un problème d’ingénierie. »
La résolution de ce problème d’ingénierie peut être facilitée par des plateformes de données adaptées, telles que des data lakehouses gouvernés et open source. Ainsi, watsonx.data d’IBM, un data lakehouse hybride et ouvert, garantit que les contrôles d’accès sont hérités des systèmes sources des documents lorsque les données sont récupérées. Il fournit également des annotations pour les données personnelles afin d’empêcher le partage d’informations sensibles.
À mesure que les LLM et autres IA génératives s’intègrent de plus en plus profondément dans les workflows quotidiens, l’amélioration de la RAG aide les entreprises à tirer davantage de valeur de leurs données. Les outils et stratégies adaptés à l’entreprise « permettent d’améliorer les performances et la précision afin que les données deviennent gérables et précieuses », explique M. Nirmal. « C’est ce que recherchent tous les clients. »
Entraînez, validez, réglez et déployez une IA générative, des modèles de fondation et des capacités de machine learning avec IBM watsonx.ai, un studio d’entreprise nouvelle génération pour les générateurs d’IA. Créez des applications d’IA en peu de temps et avec moins de données.
Mettez l’IA au service de votre entreprise en vous appuyant sur l’expertise de pointe d’IBM dans le domaine de l’IA et sur son portefeuille de solutions.
Réinventez les workflows et les opérations critiques en ajoutant l’IA pour optimiser les expériences, la prise de décision et la valeur métier en temps réel.