Génération augmentée de récupération sans serveur (RAG) sur AWS

Dans le paysage évolutif de l’IA générative, l’intégration d’informations externes actualisées dans de grands modèles de langage (LLM) représente une avancée significative. Dans cet article, nous allons développer une véritable solution de génération augmentée de récupération (RAG) sans serveur, facilitant la création d’applications qui produisent des réponses plus précises et plus pertinentes au contexte. Notre objectif est de vous aider à créer votre application basée sur GenAI le plus rapidement possible, en gardant un œil sur vos coûts et en vous assurant de ne pas payer pour une capacité de calcul que vous n’utilisez pas.

RAG sans serveur : un aperçu

La RAG sans serveur associe les capacités avancées de traitement du langage des modèles de fondation à l’agilité et à la rentabilité d’une architecture sans serveur. Cette intégration permet la récupération dynamique d’informations provenant de sources externes, qu’il s’agisse de bases de données, d’Internet ou de bases de connaissances personnalisées, ce qui permet de générer un contenu non seulement précis et riche en contexte, mais également à jour avec les informations les plus récentes.

Amazon Bedrock simplifie le déploiement des applications RAG sans serveur, en offrant aux développeurs les outils nécessaires pour créer, gérer et mettre à l’échelle leurs projets GenAI sans avoir besoin d’une gestion d’infrastructure étendue. En outre, les développeurs peuvent exploiter la puissance des services AWS tels que Lambda et S3, ainsi que des bases de données vectorielles open source innovantes comme LanceDB, pour créer des solutions pilotées par l’IA réactives et rentables.

Ingestion de documents

La transition vers votre solution RAG sans serveur implique plusieurs étapes clés, chacune étant conçue pour garantir l’intégration transparente des modèles de fondation avec les connaissances externes.

Le processus commence par l’ingestion de documents dans une architecture sans serveur, où des mécanismes pilotés par des événements déclenchent l’extraction et le traitement du contenu textuel pour générer des intégrations. Ces intégrations, créées à l’aide de modèles tels qu’Amazon Titan, transforment le contenu en vecteurs numériques faciles à comprendre et à traiter par les machines.

Le stockage de ces vecteurs dans LanceDB, une base de données vectorielles sans serveur soutenue par Amazon S3, facilite la récupération et la gestion efficaces, garantissant que seules les informations pertinentes sont utilisées pour augmenter les réponses du LLM. Cette approche améliore non seulement la précision et la pertinence du contenu généré, mais réduit également de manière significative les coûts opérationnels en tirant parti d’un modèle de paiement en fonction de votre utilisation.

Consultez le code ici.

Que sont les intégrations ?

Dans le domaine du traitement du langage naturel (NLP), les intégrations constituent un concept essentiel qui permet de traduire des informations textuelles sous forme numérique que les machines peuvent comprendre et traiter. C’est un moyen de traduire des relations sémantiques en relations géométriques, ce que les ordinateurs peuvent comprendre bien mieux que le langage humain. En substance, l’intégration permet de transformer le contenu d’un document en vecteurs dans un espace à haute dimension. Ainsi, la distance géométrique dans cet espace prend une signification sémantique. Dans cet espace, les vecteurs représentant différents concepts seront éloignés les uns des autres et des concepts similaires seront regroupés.

Ceci est réalisé grâce à des modèles tels qu’Amazon Titan Embedding, qui utilise des réseaux neuronaux entraînés sur des corpus de texte massifs pour calculer la probabilité que des groupes de mots apparaissent ensemble dans divers contextes.

Heureusement, vous n’avez pas à créer ce système à partir de zéro. Bedrock est là pour donner accès à des modèles d’intégration, ainsi qu’à d’autres modèles de fondation.

Ma base de connaissances est intégrée, que faire maintenant ?

Vous devez stocker ces données quelque part. Dans une base de données vectorielles, pour être précis. Et c’est là que la véritable magie sans serveur opère.

LanceDB est une base de données vectorielles open source conçue pour la recherche vectorielle avec stockage persistant, simplifiant la récupération, le filtrage et la gestion des intégrations. La fonctionnalité la plus remarquable pour nous est la possibilité de connecter LanceDB directement à S3. De cette façon, nous n’avons pas besoin d’informatique inactive. Nous n’utilisons la base de données que pendant l’exécution de la fonction Lambda. Nos tests de charge ont montré que nous pouvons ingérer des documents d’une taille maximale de 500 Mo sans que LanceDB, Bedrock ou Lambda ne soient mis à rude épreuve.

Les démarrages à froid Lambda constituent une limitation connue de ce système, mais nous avons constaté que le processus qui prend le plus de temps est en fait le calcul des intégrations, qui se déroule en dehors de Lambda. Nous avons mesuré que notre base d’utilisateurs n’est affectée par le démarrage à froid que dans 10 % des cas. Pour remédier à ce problème, vous pouvez envisager de créer des tâches par lots dans la prochaine phase d’un MVP et éventuellement utiliser d’autres services AWS sans serveur tels que Batch ou ECS Fargate, en profitant également de la tarification Spot pour réaliser encore plus d’économies.

Interrogation

Les utilisateurs peuvent transmettre leurs données à notre fonction d’inférence via une URL Lambda. Ceci est introduit dans le modèle Titan Embedding via Bedrock, qui calcule un vecteur. Nous utilisons ensuite ce vecteur pour trouver une poignée de documents similaires dans nos bases de données vectorielles, et nous les ajoutons à la dernière requête. Nous envoyons la requête finale au LLM choisi par l’utilisateur et, s’il prend en charge le streaming, la réponse est retransmise en temps réel à l’utilisateur. Ici encore, nous n’avons pas de calcul inactif de longue durée ici, et comme les entrées utilisateur sont généralement plus petites que les documents que nous ingérons, vous pouvez vous attendre à des temps plus courts pour le calcul de son intégration.

Une limitation connue de ce système d’inférence est le démarrage à froid de notre base de données vectorielles dans une nouvelle fonction Lambda. Puisque LanceDB fait référence à une base de données stockée dans S3, lorsqu’un nouvel environnement d’exécution Lambda est créé, nous devons charger la base de données pour pouvoir effectuer nos recherches vectorielles. Cela ne se produit que lorsque vous passez à l’échelle supérieure ou que personne ne vous a posé de question depuis longtemps, ce qui signifie qu’il s’agit d’un petit compromis par rapport aux économies réalisées grâce à une architecture entièrement sans serveur.

Consultez le code ici.

Découvrir les aspects économiques de la RAG sans serveur

Il est essentiel de comprendre les implications financières pour adopter la RAG sans serveur. Le modèle tarifaire d’Amazon Bedrock, basé sur l’utilisation de jetons et la consommation de ressources sans serveur, permet aux développeurs d’estimer les coûts avec précision. Qu’il s’agisse de traiter des documents à intégrer ou d’interroger le modèle pour obtenir des réponses, la tarification à l’usage garantit que les coûts sont directement liés à l’utilisation, de sorte que vous ne payez que pour ce que vous utilisez.

Aspects économiques de l’ingestion

Examinons de plus près les aspects économiques de l’utilisation d’architectures sans serveur pour le traitement de documents. Nous basons nos calculs sur deux hypothèses : le temps de traitement est estimé approximativement à 1 minute par mégaoctet de données, et un document de cette taille contient généralement un peu moins de 30 000 jetons. Bien que ces chiffres constituent une base de référence, la réalité est souvent plus favorable, de nombreux documents étant traités beaucoup plus rapidement.

Le traitement d’un seul document de 1 Mo entraîne des dépenses minimes, moins d’un demi-centime dans la plupart des cas. Lorsque vous augmentez jusqu’à un millier de documents, chacun d’une taille de 1 Mo, le coût total reste remarquablement bas, inférieur à 4 USD. Cet exemple démontre non seulement la rentabilité des architectures sans serveur pour le traitement des documents, mais met également en évidence l’efficacité du modèle de tarification basé sur des jetons utilisé sur des plateformes telles qu’Amazon Bedrock. Il s’agit également d’un processus ponctuel : une fois que vous avez traité vos documents, ils seront conservés dans votre base de données vectorielles jusqu’à ce que vous décidiez de les supprimer.

Aspects économiques de l’interrogation

Passons à la partie interactive de notre configuration et abordons ce qui se passe lorsque vous commencez à poser des questions à votre IA. Voici quelques-unes de nos hypothèses : nous pensons qu’il faudra environ 20 secondes à AWS Lambda pour intégrer notre requête de réponse, et nous partons du principe que chaque question et sa réponse contiennent environ 1 000 jetons chacune. Par rapport au coût d’inférence, les frais associés aux requêtes adressées à S3 sont négligeables.

Une fois les hypothèses posées, examinons les coûts. Le lancement d’une seule requête sur le modèle Claude V2 par Anthropic coûtera environ 3 cents. Si vous optez pour quelque chose d’un peu plus léger, comme Claude Instant, le coût chute considérablement à une fraction de cent par requête. Passez à 1 000 requêtes avec Claude V2, et vous obtenez une dépense globale d’environ 33 USD. Cela couvre l’ensemble du processus : envoi de votre question au LLM, extraction de documents similaires de votre base de données pour enrichir votre requête et la lier à des documents contextuels, et obtention d’une réponse sur mesure.

La véritable cerise sur le gâteau de toute cette configuration est la façon dont elle est conçue pour fonctionner sur demande, grâce à sa nature sans serveur. Cela signifie que vous ne payez que pour ce que vous utilisez.

Élargir les horizons grâce à la RAG sans serveur

À l’avenir, les applications potentielles de la RAG sans serveur vont bien au-delà des cas d’utilisation actuels. En incorporant des stratégies supplémentaires telles que le reclassement des modèles en fonction de leur pertinence, l’intégration d’adaptateurs pour une recherche sémantique améliorée et l’exploration de l’intégration multimodale des informations, les développeurs peuvent affiner et étendre leurs applications GenAI.

La prise en charge par Amazon Bedrock de la RAG sans serveur ouvre de nouvelles voies d’innovation dans le domaine de l’IA générative. En réduisant les obstacles à l’entrée et en proposant une plateforme évolutive et rentable, AWS permet aux développeurs d’explorer tout le potentiel des applications pilotées par l’IA. Alors que nous continuons à explorer et à étendre les capacités de la RAG sans serveur, les possibilités de créer des solutions d’IA plus intelligentes, réactives et pertinentes sont infinies. Rejoignez-nous dans cette aventure et découvrez comment la RAG sans serveur sur Amazon Bedrock peut transformer vos projets d’IA en réalité.

Ressources

• Référentiel de code du pipeline d’ingestion
• Inférence en streaming à l’aide du référentiel de code Amazon Bedrock
• Regardez la conférence sur AWS Innovate