aws-genai-llm-chatbot : déployer un chatbot RAG multi-modèles sur AWS avec CDK

Le problème concret : recoller soi-même Bedrock, un vector store et une authentification

Monter un chatbot RAG sur AWS demande d'assembler au minimum un accès à un modèle, un stockage vectoriel, une couche d'authentification, une API et une interface web. Chaque brique a ses propres rôles IAM, ses limites de débit et son format de configuration. Le projet aws-samples/aws-genai-llm-chatbot part de ce constat et fournit un ensemble de constructs AWS CDK qui déploie l'ensemble d'un coup. Le public visé est une équipe plateforme ou un architecte cloud qui connaît déjà CDK et qui veut éviter de réécrire la plomberie d'authentification et d'indexation avant de pouvoir tester un cas d'usage métier. Ce n'est pas un produit hébergé : le README précise que le blueprint déploie la solution complète dans votre propre compte AWS. Vous héritez donc de la facturation et de l'exploitation des ressources créées.

Ce que le dépôt expose comme modèles et comme bases vectorielles

La liste des topics du dépôt donne l'inventaire le plus fiable des intégrations annoncées : amazon-bedrock, sagemaker, huggingface, openai, meta, ai21, cohere, mistral côté modèles, et opensearch, opensearch-serverless, aurora, pgvector, kendra côté recherche. Le README confirme trois voies d'accès aux modèles : Amazon Bedrock (Claude, Llama 2), SageMaker, et des endpoints de modèle personnalisés. Il mentionne aussi une intégration GenAIEH Gateway pour un accès à des modèles supplémentaires. Cette largeur de choix est le principal argument du projet. Elle a un revers : chaque combinaison modèle plus base vectorielle est un chemin de configuration distinct, et la matrice de tests réellement couverte n'est pas exposée dans les éléments dont je dispose. Les topics signalent une intention, pas une validation.

Architecture : où passent les documents et les requêtes

Le README décrit une architecture à sept composants : Amazon Bedrock pour l'accès aux LLM, Amazon OpenSearch pour le stockage vectoriel, Amazon S3 pour les documents, Amazon Cognito pour l'authentification, AWS Lambda pour le traitement serverless, Amazon API Gateway pour l'exposition des API, et une interface web React. Le flux se lit ainsi : un document déposé dans S3 est traité par une fonction Lambda qui produit des embeddings et les écrit dans l'index OpenSearch. Côté utilisateur, le navigateur s'authentifie via Cognito, appelle l'API Gateway, qui déclenche une Lambda chargée de récupérer les passages pertinents dans OpenSearch puis d'appeler le modèle via Bedrock ou SageMaker. Le README mentionne une mémoire de conversation avec stockage persistant et un suivi de la consommation de tokens. Ces deux éléments impliquent des écritures supplémentaires en base, mais le schéma précis n'est pas détaillé dans la documentation fournie.

Mise en route : prérequis et commandes de déploiement

Les prérequis listés sont un compte AWS avec les permissions adéquates, une CLI AWS configurée avec des identifiants, Node.js 18 ou plus récent avec npm, Python 3.8 ou plus récent, et une CLI AWS CDK compatible avec aws-cdk-lib 2.206.0 ou ultérieur. Le README donne deux commandes pour installer et vérifier la CLI : npm install -g aws-cdk@latest puis cdk --version. Il signale un point de friction précis : si vous voyez une erreur « Cloud assembly schema version mismatch » pendant le déploiement, c'est que votre CLI CDK est trop ancienne par rapport à aws-cdk-lib. La mise à jour de la CLI globale est la correction indiquée. Le README affirme que le déploiement est entièrement automatisé via AWS CDK et SeedFarmer, sans fournir la commande exacte du pipeline dans l'extrait disponible. Il faut donc se référer au dépôt pour la séquence précise. Aucun exemple de fichier de configuration, de clé de contexte CDK ou de paramètre d'environnement n'apparaît dans le matériel fourni, ce qui est une lacune notable pour un projet de cette taille.

Le coût réel et la surface d'exploitation, angle mort de la documentation

Le README présente la maîtrise des coûts comme une fonctionnalité, via le suivi de la consommation de tokens. C'est un outil de mesure, pas une réduction de facture. Le déploiement crée un domaine OpenSearch, un pool Cognito, une API Gateway, des fonctions Lambda, des buckets S3 et des appels à Bedrock ou à des endpoints SageMaker. Chacun de ces services a sa propre grille tarifaire, et OpenSearch en particulier se facture à l'heure tant que le domaine tourne. Rien dans le matériel fourni ne chiffre ce coût, ne décrit une option de mise à l'échelle à zéro, ni ne documente une procédure de démontage propre. C'est la principale zone d'ombre pour une équipe qui veut évaluer le projet sur un compte de test. Un deuxième point mérite attention : la solution est intrinsèquement liée à AWS. Si votre besoin est un prototype RAG sur un poste local ou sur un autre cloud, ce dépôt est le mauvais outil, quelle que soit la qualité de son code.

Alternatives : LangChain seul, ou une plateforme RAG managée

L'alternative la plus proche en esprit est d'utiliser LangChain directement, sans le blueprint. Le dépôt liste d'ailleurs langchain parmi ses topics, ce qui suggère qu'il s'appuie dessus en interne. La différence d'approche est nette : LangChain fournit des abstractions de chaînes et de récupérateurs que vous câblez vous-même, tandis que ce projet fournit des constructs CDK qui créent les ressources AWS et les relient. Avec LangChain seul, vous gardez le contrôle du cycle de vie de chaque composant et vous pouvez exécuter le tout hors AWS. Avec le blueprint, vous gagnez le provisionnement automatisé et l'intégration Cognito, au prix d'un couplage fort à l'écosystème AWS et d'une pile plus lourde à modifier. Une plateforme RAG entièrement managée constitue l'autre extrémité : moins de code à maintenir, mais aucune maîtrise des données ni des modèles. Le choix se joue donc entre contrôle et vitesse de mise en route, pas entre qualité et médiocrité.

Maintenance, versionnement et licence MIT-0

Le dépôt n'est pas archivé et la dernière poussée enregistrée date du 30 juin 2026. La version majeure la plus récente listée est v5.0.0, publiée le 23 janvier 2025, après une série de versions 4.0.x étalées sur 2024. Le passage de la branche 4 à la 5 signale une rupture d'API ou de structure, ce qui implique un travail de migration si vous partez d'une version antérieure. La licence MIT-0 est permissive : elle autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, sans obligation d'attribution. Elle s'accompagne d'une absence de garantie. Concrètement, personne ne prend en charge les correctifs de sécurité ni la compatibilité avec les évolutions des services AWS. Ce point compte pour un déploiement en production : la maintenance du blueprint dépend de la communauté et des mainteneurs du dépôt aws-samples. Je ne peux pas évaluer la fréquence réelle des mises à jour au-delà des versions listées, ni le nombre de contributeurs actifs, faute de données dans le matériel fourni.

Conclusion éditoriale

À adopter si vous voulez un point de départ CDK complet pour un chatbot RAG sur Bedrock et que vous acceptez de lire le code TypeScript pour combler les zones d'ombre de la documentation. À éviter si vous cherchez une brique RAG légère et portable hors AWS, ou si vous ne pouvez pas absorber la surface de services facturés (OpenSearch, Cognito, API Gateway, Lambda, S3) qu'implique ce déploiement. Avant tout engagement, vérifiez la compatibilité entre votre CLI CDK et aws-cdk-lib 2.206.0, puis inspectez les constructs CDK du dossier du projet pour identifier les ressources réellement provisionnées dans votre compte.

Sources officielles

1. aws-samples/aws-genai-llm-chatbot on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases