Amazon Bedrock : AWS étoffe ses fonctionnalités RAG
Outre la refonte de SageMaker, AWS a également présenté de nombreuses améliorations pour Amazon Bedrock. La majorité d’entre elles visent à améliorer la conception d’architecture RAG, plus performante et moins chère.
Pour rappel, Bedrock est la plateforme du fournisseur cloud consacrée à l’inférence de grands modèles de langage et au développement d’applications d’IA générative. Depuis la place de marché associée, elle accueille plus d’une centaine de grands modèles de langage, contre une vingtaine en 2023. Toutefois, un LLM ne suffit pas à faire un bon système d’IA.
Comme ses concurrents Microsoft et Google, la filiale du géant de l’e-commerce entend proposer davantage d’outils pour orienter les résultats des LLM, les contrôler, et atténuer les hallucinations.
En la matière, l’architecture RAG (Retrieval Augmented Generation) s’est imposée. Cette approche consiste à nourrir le LLM de données en provenance de sources primaires (de préférence vérifiées) – après les avoir vectorisées – puis d’y ajouter une couche de recherche sémantique. Elle doit permettre d’enrichir les réponses et de les limiter à ce contexte.
Au sein d’Amazon Bedrock, c’est le service managé Knowledge Bases qui doit faciliter le déploiement d’une telle architecture.
Si tous les éditeurs de bases de données et les fournisseurs de cloud ont lancé une offre intégrant les fondations d’une telle architecture, elle réclame de configurer plusieurs briques distinctes.
Mieux classer les résultats avant de générer du contenu
L’une d’entre elles n’est autre que l’algorithme ou le LLM chargé de classer les résultats trouvés par le module de recherche avant de les envoyer aux LLM. En effet, ce mécanisme dit de « reranking » doit assurer que les informations les plus pertinentes sont servies aux grands modèles de langage.
Jusqu’alors, AWS ne proposait pas cette fonctionnalité. Or, cela affecte les contenus générés par le LLM et il se peut qu’il ne source pas correctement la source des documents associés. En effet, la recherche sémantique a encore des limites lorsque les éléments de la base de connaissances et les questions de l’usager sont complexes.
Le fournisseur a annoncé lors de sa conférence annuelle la disponibilité de deux LLM de reranking : Amazon Rerank 1.0 et Cohere Rerank 3.5. Ceux-là sont accessibles via API et peuvent être invoqués depuis le fichier de configuration RAG de Knowledge Bases. Pour l’instant, ils prennent en charge uniquement les données textuelles.
En sus de cet instrument qui doit améliorer la qualité des réponses et – in fine – réduire les coûts selon AWS (moins de recherches infructueuses), le fournisseur propose l’injection directe de données dans Knowledge Bases. Des connecteurs spécifiques à travers un SDK AWS ou la console de Bedrock peuvent être utilisés pour y insérer des données en dehors d’un écosystème AWS. Cela inclut également les données de streaming, par exemple issues d’équipements IoT ou qui transitent depuis un flux de type Apache Kafka. Les documents sont stockés dans des buckets S3, puis indexés dans le vector store de la plateforme.
L’ingestion de données à partir de connecteurs spécifiques est en disponibilité générale, tandis que les modèles de reranking le sont depuis les régions cloud US West (Oregon), Canada (Central), Europe (Frankfurt), et Asie Pacifique (Tokyo).
Ces deux capacités n’auraient pas réellement de sens sans l’annonce d’une troisième en disponibilité générale : la prise en charge de la recherche de données structurées. Bedrock propose une solution RAG « sur étagère » pour générer une requête SQL à partir du prompt d’un utilisateur. Cette conversion est effectuée par un module NL2SQL (Natural Language to SQL), compatible actuellement avec Amazon Redshift et SageMaker Lakehouse.
RAG multimodal et GraphRAG
Les autres fonctionnalités de Bedrock présentées lors de Re:Invent 2024 sont en préversion. À commencer par Data Automation, un service pour automatiser l’extraction de données semi-structurées depuis des documents, des images, des vidéos ou des fichiers audio.
Par exemple, il est possible d’automatiser le traitement de factures, de production de résumé ou de transcripts.
Celui-ci fournit deux modes : le premier permet de concevoir des applications de type Intelligent Document Processing (IDP), tandis que le second ajoute une étape de conversion des données extraites en vecteurs afin d’alimenter une base de connaissances. Ainsi, AWS espère étendre la portée de son architecture RAG aux applications d’IA multimodale.
Pour ce second cas d’usage, il est également possible d’utiliser un LLM en tant que parser, mais il est limité par le prompt en entrée (par défaut ou personnalisé). Contrairement à Data Automation, l’usage d’un LLM comme parser est accessible depuis toutes les régions cloud d’AWS où Knowledge Bases est disponible.
Le fournisseur se penche également sur la prise en charge en préversion d’une architecture GraphRAG.
Cette approche vise à parfaire la contextualisation des données en s’appuyant sur les capacités d’une base de données orientée graphe. AWS promet des réponses plus pertinentes, de meilleurs résumés et des réponses plus explicables. Pour ce faire, le fournisseur s’appuie sur la DBaaS Amazon Neptune Analytics, intégré à Bedrock Knowledge Bases.
Ici, il convient de stocker au préalable les documents dans des buckets S3. Après avoir créé un vector store depuis la console de Bedrock, « la base de connaissances génère et stocke automatiquement les embeddings dans Amazon Neptune, ainsi qu’une représentation graphique des entités et de leurs relations, dérivée du corpus de documents ».
Des évaluations réalisées par un LLM
Encore faut-il pouvoir apprécier la performance de tels dispositifs. Bedrock disposait déjà de fonctionnalités pour évaluer les sorties des grands modèles de langage, mais rien de tel pour les systèmes RAG. Pour combler ce trou dans sa raquette, le fournisseur cloud propose en préversion « RAG evaluation ». Ici, il reprend l’ensemble des critères d’évaluation des réponses des LLM – la complétude, la véracité, la cohérence logique, la toxicité, le refus, l’utilité et la production de stéréotypes –, et l’applique aux bases de connaissances. Ce ne sont pas des modèles NLP qui sont exploités pour effectuer les examens, mais un LLM. Cette technique nommée LLM-as-judge s’appuie sur un grand modèle de langage dont une partie de l’entraînement a été consacré à la détection des biais évoqués plus haut. Dans ces démonstrations, AWS emploie Claude 3.5 Sonnet. Cette approche LLM-as-judge est également en préversion pour noter les contenus générés par les LLM.
En revanche, ces évaluations RAG ne portent pas sur les mécanismes de recherche ni sur la latence du système. Ce sont pourtant des critères essentiels influencés à la fois par les documents ingérés et par le LLM exploité. En effet, suivant la stratégie de chunking (la sélection des extraits de documents les plus pertinents à vectoriser) et de vectorisation, les performances du système peuvent fortement évoluer.
Si l’ensemble de ces fonctionnalités génèrent des coûts supplémentaires, le géant du cloud a le bon goût de s’aligner sur ses concurrents et les pratiques de fournisseurs de LLM. Ainsi, il livre la préversion d’une fonction de mise en cache des prompts les plus utilisés. « Ceci est particulièrement utile pour les applications qui recourent de manière répétée au même contexte, comme les systèmes de questions-réponses […] ou les assistants de programmation qui ont besoin de maintenir le contexte sur les fichiers de code », vante AWS.
Le contexte mis en cache est conservé en mémoire « pendant 5 minutes après chaque accès ». Selon le fournisseur, cette approche permettrait de réduire les coûts « jusqu’à 90 % » et la latence « jusqu’à 85 % » pour les LLM compatibles.
À cela s’ajoute un système de routage « intelligent » des prompts vers plusieurs LLM. Celui-ci s’appuierait sur des technologies de correspondances des prompts et une « connaissance avancée des modèles ». Il s’agit d’optimiser la réponse suivant la requête et le résultat exigé. Cela permettrait de réduire les coûts de 30 % « sans compromettre la précision » de l’application. L’idée est intéressante, mais elle est pour l’instant cantonnée par collection de modèles. Ainsi, deux routeurs sont accessibles : celui d’Anthropic (Claude 3 Haiku, Sonnet 3.5) et Meta (Llama 3.1-8B Instruct, Llama 3.1 70B instruct).
Un gain de temps, pas forcément d’argent
AWS semble mieux doté que Microsoft Azure pour prendre en charge les architectures RAG, mais n’a pas développé de manière aussi poussée un équivalent à Azure AI Foundry, un service de création d’agents IA.
La prévision des coûts semble encore complexe au vu des nombreux services invoqués. Toutefois, peu importe la plateforme choisie, selon Holger Mueller, analyste chez Constellation Research, les PaaS consacrées à l’IA générative feraient gagner beaucoup de temps aux entreprises. Selon son estimation, il suffirait de 9 à 11 heures pour bâtir une architecture RAG dans Amazon Bedrock quand une approche DIY réclamerait au moins 84 heures.
« Les résultats de ce rapport sont clairs pour les directeurs généraux : ne suivez pas la voie du bricolage, mais utilisez plutôt des outils PaaS tels qu’Amazon Bedrock pour obtenir les résultats dont votre entreprise a besoin pour être gagnante à l’ère de l’IA », conclut-il, dans un billet de blog.
