La génération augmentée par récupération (RAG) sera-t-elle tuée par les LLM à long contexte ?
La quête d’innovation et de suprématie en IA ne montre aucun signe de ralentissement. Récemment, Google a dévoilé Gemini 1.5, seulement deux mois après le lancement de Gemini, son dernier grand modèle de langage (LLM) capable de gérer des contextes allant jusqu’à un impressionnant total de 10 millions de tokens. Simultanément, OpenAI est entré en scène avec Sora, un robuste modèle texte-vers-vidéo célébré pour ses effets visuels captivants. La confrontation de ces deux technologies de pointe a suscité des discussions sur l’avenir de l’IA, en particulier sur le rôle et la disparition potentielle de la génération augmentée par récupération (RAG).
Dans cet article de blog, nous explorerons les subtilités des capacités de Gemini en matière de contexte long, ses limites et son impact sur l’évolution des techniques de génération augmentée par récupération. Plus important encore, nous discuterons de la question de savoir si le RAG est au bord de la disparition et de la façon d’optimiser les systèmes RAG.
Comprendre la capacité de contexte long de Gemini
Alors que l’attrait des effets visuels de Sora retient davantage l’attention, je m’intéresse davantage à Gemini et à son rapport technique associé, qui s’étend sur plus de 50 pages et explore les tests des capacités de Gemini en matière de contexte long et de multimodalité. Selon ce rapport, Gemini 1.5 Pro prend en charge des contextes ultra-longs allant jusqu’à 10 millions de tokens et le traitement de données multimodales, permettant à Gemini d’interagir de manière fluide avec des données diverses, depuis un livre entier et d’immenses collections de documents jusqu’à de vastes bibliothèques de code et un film d’une heure.
Gemini 1.5 Pro prend en charge des contextes ultra-longs allant jusqu’à 10M de tokens. Source de l’image : https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Stabilité et précision de la récupération
Ce rapport introduit une méthode d’évaluation de type « aiguille dans une botte de foin » afin de tester et de comparer la capacité de récupération de Gemini 1.5 Pro et de GPT-4. Dans ce test, Google insère des segments de texte (les « aiguilles ») à différentes positions d’un long document (la « botte de foin »), et Gemini et GPT doivent trouver et nommer les documents pertinents afin de les récupérer.
Les résultats des tests montrent que Gemini 1.5 Pro atteint un rappel de 100 % jusqu’à 530 000 tokens et maintient un rappel supérieur à 99,7 % jusqu’à 1M de tokens. Même avec un document extrêmement long de 10M de tokens, le modèle conserve un taux de rappel impressionnant de 99,2 %. Alors que GPT-4 gère parfaitement moins de 128 000 tokens, Gemini est plus compétent dans la gestion de contextes plus étendus. Ces résultats soulignent l’excellente récupération d’informations, la stabilité et la précision de Gemini dans des contextes exceptionnellement longs allant jusqu’à 10M de tokens.
Source de l’image : https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Questions-réponses
En plus de tester la capacité de récupération de Gemini, Google évalue sa capacité de réponse aux questions avec un contexte fourni. Dans ce test, Google utilise le livre Les Misérables (710 000 tokens) comme contexte et demande à Gemini 1.5 Pro, Gemini 1.0 Pro et Claude 2.1 d’Anthropic de répondre à des questions sur le livre.
Parce que Gemini 1.0 Pro et Claude 2.1 prennent en charge une longueur de contexte inférieure à 710 000 tokens, ils doivent s’appuyer sur la technique de génération augmentée par récupération (RAG) pour accéder aux passages les plus pertinents du Top-K (jusqu’à 4 000 tokens) du livre comme contexte. Gemini dispose d’une fenêtre de contexte plus grande, il utilise donc l’ensemble du livre comme contexte. Ce test compare également les performances des trois modèles dans une configuration 0-shot sans aucun contexte fourni.
Les résultats des tests montrent que Gemini 1.5 Pro surpasse les autres LLM alimentés par RAG pour répondre aux questions, démontrant sa domination dans la compréhension et le traitement d’immenses collections de textes. Ce test révèle également que la technique de génération augmentée par récupération peine souvent à résoudre les expressions référentielles et le raisonnement entre sources de données avec des dépendances à longue distance.
Source de l’image : https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Les LLM à long contexte tueront-ils le RAG ?
Le cadre de génération augmentée par récupération, intégrant une base de données vectorielle, un LLM et le prompt-as-code, est une technologie de pointe qui intègre de manière transparente des sources de connaissances externes afin d’enrichir la base de connaissances d’un LLM pour fournir des documents et des réponses précis et pertinents. C’est une solution éprouvée qui répond efficacement aux défis fondamentaux des LLM, tels que les hallucinations et le manque de connaissances spécifiques à un domaine.
En constatant les performances impressionnantes de Gemini dans la gestion de longs contextes, certaines voix prédisent rapidement la disparition du RAG. Par exemple, dans une critique de Gemini 1.5 Pro sur Twitter, le Dr Yao Fu a déclaré avec audace : « Le contexte de 10M tue le RAG. »
Cette affirmation est-elle vraie ? De mon point de vue, la réponse est « NON ». Le développement de la technologie RAG ne fait que commencer et continuera d’évoluer. Bien que Gemini excelle dans la gestion de contextes étendus, il est confronté à des défis persistants résumés par les 4V : Vélocité, Valeur, Volume et Variété.
Les défis 4V des LLM
Vélocité : Gemini se heurte à des obstacles pour atteindre des temps de réponse inférieurs à la seconde avec des contextes étendus, comme en témoigne un délai de 30 secondes pour répondre à 360 000 contextes. Malgré l’optimisme concernant les avancées computationnelles des LLM, des réponses rapides au niveau inférieur à la seconde lors de la récupération de longs contextes restent difficiles pour les grands modèles basés sur les transformers.
Valeur : La proposition de valeur des LLM est compromise par les coûts d’inférence considérables associés à la génération de réponses de haute qualité dans de longs contextes. Par exemple, récupérer 1 million de tokens de jeux de données à un tarif de 0,0015 pour une seule requête. Ce facteur de coût rend de telles dépenses élevées peu pratiques pour une utilisation quotidienne, constituant un obstacle important à une adoption généralisée.
Volume : Malgré sa capacité à gérer une grande fenêtre de contexte pouvant atteindre dix millions de tokens, la capacité volumique de Gemini est éclipsée lorsqu’on la compare à l’immensité des données non structurées. Par exemple, aucun LLM, y compris Gemini, ne peut accueillir adéquatement l’échelle colossale des données présentes dans l’index de recherche Google. En outre, les données privées des entreprises devront rester dans les limites de leurs propriétaires, qui peuvent choisir d’utiliser le RAG, d’entraîner leurs propres modèles ou d’utiliser un LLM privé.
Variété : Les cas d’utilisation réels impliquent non seulement des données non structurées comme de longs textes, des images et des vidéos, mais aussi une gamme variée de données structurées qui peuvent ne pas être facilement capturées par un LLM à des fins d’entraînement, telles que les données de séries temporelles, les données de graphes et les modifications de code. Des structures de données et des algorithmes de récupération rationalisés sont essentiels pour traiter efficacement des données aussi variées.Tous ces défis soulignent l’importance d’une approche équilibrée dans le développement d’applications d’IA, rendant le RAG de plus en plus crucial dans le paysage en évolution de l’intelligence artificielle.
Stratégies pour optimiser l’efficacité du RAG
Bien que la génération augmentée par récupération se soit révélée bénéfique pour réduire les hallucinations des LLM, elle présente des limites. Dans cette section, nous explorerons des stratégies visant à optimiser l’efficacité de la génération augmentée par récupération afin de trouver un équilibre entre précision et performance, et de rendre les systèmes RAG plus adaptables à un éventail plus large d’applications.
Améliorer la compréhension des longs contextes
Les techniques conventionnelles de génération augmentée par récupération s’appuient souvent sur le découpage en blocs pour vectoriser les données non structurées, principalement en raison des limitations de taille des modèles d’embedding et de leurs fenêtres de contexte. Cependant, cette approche de découpage présente deux inconvénients notables.
- Premièrement, elle décompose la séquence d’entrée en blocs isolés, perturbant la continuité du contexte et affectant négativement la qualité des embeddings.
- Deuxièmement, il existe un risque de séparer des informations consécutives en blocs distincts, ce qui peut entraîner une récupération incomplète d’informations essentielles.
En réponse à ces défis, les stratégies d’embedding émergentes basées sur les LLM ont gagné en popularité en tant que solutions efficaces. Elles offrent une meilleure capacité d’embedding et prennent en charge des fenêtres de contexte élargies. Par exemple, SRF-Embedding-Mistral et GritLM7B, deux des modèles de langage d’embedding les plus performants du Huggingface MTEB LeaderBoard, prennent en charge des contextes de 32 000 tokens, démontrant une amélioration substantielle des capacités d’embedding. Cette amélioration de l’embedding des données non structurées renforce également la compréhension des longs contextes par le RAG.
Une autre approche efficace pour relever les défis ci-dessus est la stratégie BGE Landmark Embedding récemment publiée. Cette approche adopte une architecture sans découpage, dans laquelle les embeddings pour les unités d’entrée fines, par exemple les phrases, peuvent être générés à partir d’un long contexte cohérent. Elle s’appuie également sur une fonction sensible à la position afin de faciliter la récupération complète des informations utiles comprenant plusieurs phrases consécutives au sein du long contexte. Par conséquent, le landmark embedding est bénéfique pour améliorer la capacité des systèmes RAG à comprendre et à traiter de longs contextes.
L’architecture du landmark embedding. Des tokens Landmark (LMK) sont ajoutés à la fin de chaque phrase. Une fenêtre glissante est utilisée pour traiter les textes d’entrée plus longs que la fenêtre de contexte du LLM. Source de l’image : https://arxiv.org/pdf/2402.11573.pdf
Ce diagramme compare les méthodes Sentence Embedding et Landmark Embedding pour aider les applications RAG à répondre aux questions. La première fonctionne avec le contexte découpé en fragments, ce qui tend à sélectionner la phrase saillante. La seconde maintient un contexte cohérent, ce qui lui permet de sélectionner la bonne phrase. Les phrases surlignées en bleu et en violet sont les réponses récupérées par les deux méthodes d’embedding, respectivement. Le système RAG qui a exploité Sentence embedding a donné la mauvaise réponse, tandis que le RAG basé sur Landmark embedding a donné la bonne réponse. Cette image est adaptée de : https://arxiv.org/abs/2402.11573
Utiliser la recherche hybride pour améliorer la qualité de recherche
La qualité des réponses de la génération augmentée par récupération dépend de sa capacité à récupérer des informations pertinentes de haute qualité. Le nettoyage des données, l’extraction d’informations structurées et la recherche hybride sont tous des moyens efficaces d’améliorer la qualité de récupération. Des recherches récentes suggèrent que les modèles de vecteurs clairsemés comme Splade surpassent les modèles de vecteurs denses dans la récupération de connaissances hors domaine, la perception des mots-clés, la recherche sémantique et de nombreux autres domaines.
Le modèle d’embedding BGE_M3, récemment publié en open source, peut générer des vecteurs de tokens clairsemés, denses et de type Colbert au sein du même modèle. Cette innovation améliore considérablement la qualité de récupération de la base de données vectorielle en effectuant des récupérations hybrides sur différents types de vecteurs. Notamment, cette approche s’aligne sur le concept largement accepté de recherche hybride parmi les fournisseurs de bases de données vectorielles comme Zilliz. Par exemple, la prochaine version de Milvus 2.4 promet une recherche hybride plus complète de vecteurs denses et clairsemés.
Utiliser des technologies avancées pour améliorer les performances du RAG
Dans ce diagramme, Wenqi Glantz a répertorié 12 points de douleur dans le développement d’un pipeline RAG et a proposé 12 solutions correspondantes pour relever ces défis. Source de l’image :https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
Maximiser les capacités du RAG implique de relever de nombreux défis algorithmiques et de tirer parti de capacités et de technologies d’ingénierie sophistiquées. Comme le souligne Wenqi Glantz dans son blog, développer un pipeline RAG présente au moins 12 défis d’ingénierie complexes. Relever ces défis nécessite une compréhension approfondie des algorithmes de ML et l’utilisation de techniques complexes telles que la réécriture de requêtes, les données d’entraînement pour la reconnaissance d’intention,, et la détection d’entités.
Même les modèles avancés comme Gemini 1.5 rencontrent des obstacles substantiels. Ils nécessitent 32 appels pour atteindre un taux de précision de 90,0 % dans les tests de référence MMLU de Google. Cela souligne la nature de l’optimisation des performances dans les systèmes RAG.
Les bases de données vectorielles, l’une des technologies d’IA de pointe, constituent un composant central du pipeline RAG. Opter pour une base de données vectorielle plus mature et avancée, telle que Milvus, étend les capacités de votre pipeline RAG de la génération de réponses à des tâches telles que la classification, l’extraction de données structurées et le traitement de documents PDF complexes. De telles améliorations multiformes des bases de données vectorielles contribuent à l’adaptabilité des systèmes RAG dans un éventail plus large de cas d’utilisation applicatifs.
Conclusion : RAG reste un pilier de la réussite durable des applications d’IA.
Les grands modèles de langage remodèlent le monde, mais ils ne peuvent pas changer les principes fondamentaux de notre monde. La séparation du calcul, de la mémoire et du stockage externe des données existe depuis la création de l’architecture de von Neumann en 1945. Toutefois, même avec une mémoire sur machine unique atteignant aujourd’hui le niveau du téraoctet, les disques SATA et flash jouent encore des rôles cruciaux dans différents cas d’utilisation applicatifs. Cela démontre la résilience des paradigmes établis face à l’évolution technologique.
Le cadre RAG demeure un pilier de la réussite durable des applications d’IA. Sa fourniture d’une mémoire à long terme aux grands modèles de langage s’avère indispensable pour les développeurs recherchant un équilibre optimal entre la qualité des requêtes et la rentabilité. Dans le déploiement de l’IA générative par les grandes entreprises, RAG est un outil essentiel pour maîtriser les coûts sans compromettre la qualité des réponses.
Tout comme les avancées en matière de grande mémoire ne peuvent pas évincer les disques durs, le rôle de RAG, associé à ses technologies de soutien comme la base de données vectorielle, reste essentiel et adaptatif. Il est appelé à perdurer et à coexister dans le nouveau paysage des données, en constante évolution, des applications d’IA et de la recherche d’informations.
Continuer à lire
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.