De l'idée au déploiement : Créer un produit d'IA générative avec Bedrock

Qu’est-ce qu’on pourra faire avec ?

Une question qu’on se pose souvent dès qu’une nouvelle technologie débarque dans nos vies. Et c’est d’autant plus le cas avec l’IA Générative, dont le potentiel semble parfois dépasser notre propre imagination.

C'est en nous posant cette question que, ayant comme cas d'usage l’organisation de nos événements Hymaïa, nous nous sommes lancés le défi d'exploiter l'IA générative pour améliorer l'expérience des participants à nos conférences et meetups.

Quelques jours après nous avons donc sorti le POC pour un nouveau service : un service de RAG (Retrieval Augmented Generation) capable de fournir, en temps (quasi) réel :

1. le résumé de la présentation en cours par le conférencier
2. répondre à des questions sur l’ensemble des présentations d’une journée de conférence.

Nous ne le nierons pas : cet outil est aussi une excuse pour nous mettre à l'épreuve, construire des convictions solides sur la mise en place d'un service complet, englobant front-end, back-end, storage et, bien sûr, l'intégration d'un Large Language Model.

Dans cet article nous présenterons la solution, les choix technologiques ainsi que les résultats.

1. Solution

Comme présenté plus haut, notre solution consiste en un RAG se reposant sur un base documentaire créée en temps réel à partir de la transcription des présentations d’une conférence.

Nous avons donc conçu 2 produits :

1. Un outil de résumé de la présentation en cours sous forme de 5 points essentiels, avec un niveau de détail ajusté pour permettre une lecture rapide en quelques secondes.
2. Un outil de Q&A permettant aux participants de poser des questions telles que "Qu'est-ce qu'un Produit Data ?" et d'obtenir une réponse élaborée, citant également les sources.

Pour le choix des briques technologiques nous nous sommes basé sur 4 critères d’acceptance principaux :

• Temps de réalisation contenu : nous devions mettre en place une solution opérationnelle en un temps très court, avec seulement 5 jours avant notre prochain événement.
• Coûts limités : nous souhaitions des coûts de fonctionnement réduits, avec une possible tarification à l'usage pour l'ensemble du système.
• Temps réel : la capacité à utiliser le service pendant la présentation, avec une latence minimale ; les utilisateurs ne devant pas attendre plusieurs minutes après la fin de la présentation pour consulter le résumé.
• Scalabilité : les services devaient pouvoir être utilisés par un nombre d'utilisateurs concurrents allant de 1 à quelques dizaines. Rien de particulièrement ambitieux, mais suffisant pour imposer certaines contraintes.

2. Fonctionnement

Voici une représentation graphique des composants de la plateforme. Pour plus de détails, nous vous invitions à vous référer à la Partie 3 : “Choix Techniques”.

Comme présenté dans le schéma, le produit utilise un front-end d’enregistrement sous forme de page Web, actionné par un opérateur humain, qui devra lancer l’enregistrement en occasion de chaque talk d’une conférence en fournissant également un titre et, possiblement, une courte phrase de contexte, utilisée pour améliorer la qualité du speech-to-text. Ce front-end enregistre donc l’audio en segments de 30 secondes pour ensuite les transferrer dans un bucket S3, configuré pour déclencher l’exécution de la lambda de Speech-to-Text basée sur Whisper.

Comme présenté dans le schéma, le produit utilise un front-end d’enregistrement sous forme de page Web, actionné par un opérateur humain, qui devra lancer l’enregistrement en occasion de chaque talk d’une conférence en fournissant également un titre et, possiblement, une courte phrase de contexte, utilisée pour améliorer la qualité du speech-to-text. Ce front-end enregistre donc l’audio en segments de 30 secondes pour ensuite les transferrer dans un bucket S3, configuré pour déclencher l’exécution de la lambda de Speech-to-Text basée sur Whisper.

Les segments de texte en output sont ensuite fusionnés en continu dans un seul document pour chaque talk, qui est ensuite converti sous forme de vecteurs d’embedding par Amazon Bedrock Knowledge Base.

Deux autres front-ends se servent de l’API Bedrock pour demander :

1. le résumé du dernier talk, à l’aide d’un prompt simple à base d’une approche one-shot learning
2. les query de l’utilisateur pour l’interface question/réponse

3. Choix techniques

Aux critères fonctionnels décrits en introduction de l’article, nous en avons ajouté un 5e, plus technique : celui de ne dépendre que d'un seul fournisseur de services et de ne pas utiliser les API "haut-niveau" d'OpenAI. Ce choix découle de la volonté de nous conformer à l’approche privilégiée par les entreprises, qui consiste à rationaliser les fournisseurs pour simplifier la facturation et la gestion des ressources.

À plus d’un an de distance de la présentation de ChatGPT, vrai “Game changer” dans le domaine, les plateformes pour le développement de services basés sur l’IA Générative sont désormais nombreuses. Cependant, dans le but, purement technique, de monter et renforcer nos compétences sur l’offre Générative AI de AWS, nous avons choisi de nous servir de ce dernier.

De manière particulière, nous avons opté pour l'utilisation d'AWS Bedrock Knowledge Base, qui permet d’enrichir un LLM par une base documentaire pour la création de RAGs serverless.

Il est donc temps de définir l’architecture. Le service repose sur 4 briques principales:

1. Le Speech-to-Text : permet de convertir la voix du présentateur en un texte qui servira de base documentaire.
2. Le stockage des documents textuels : ceux-ci sont répertoriés dans une base de données vectorielle où nous enregistrons la représentation numérique (embeddings) des textes.
3. Le LLM permettant de fournir une réponse “augmentée” (c'est-à-dire, enrichie et contextualisée) à partir du prompt en entrée et des documents.
4. Les front-ends auxquels les utilisateurs accèdent pour utiliser les services.

3.1 Speech-to-Text

Bien que AWS propose des services sur étagère de Speech-to-Text, pour ce projet nous avons fait le choix d’utiliser OpenAI Whisper, que nous avions utilisé par le passé dans d’autres contextes et qui nous avait pleinement satisfait.

Un aspect plutôt intéressant de Whisper est en particulier sa frugalité en termes de ressources. Les versions “small” et “medium” de ce modèles permettent notamment d’être exécutées en CPU. Après quelques itérations, et des tests de performance sur AWS Fargate, nous avons pris le choix d’exécuter l’inférence (c-a-d la transcription de la parole en texte) sur une instance Whisper exécutée à l’intérieur d’une Lambda AWS, via un layer custom.

En particulier, cette solution remplit parfaitement nos critères de maitrise des coûts mais aussi de performance : le speech-to-text d’un segment audio de 30 secondes via Whisper sur une AWS Lambda ne demande pas plus que 10-12 secondes pour la version “small” du modèle, et 20-24 secondes pour la version “medium”.

Nous aurions bien évidemment pu opter pour la version basée sur API proposée par OpenAI, mais cela aurait été relativement plus cher,  en plus d’être en contradiction avec notre choix d'intégrer l'ensemble du système sur AWS.

3.2 Stockage des documents

Une fois les segments audio transcrits, ils sont stockés dans des répertoires S3 avant d'être convertis en vecteurs et stockés via le service Amazon Bedrock Knowledge Base. Ce dernier simplifie grandement la mise en place d'un RAG en se chargeant des étapes de création et de mise à jour de la base de données. Un détail technique intéressant est que les données sont stockées dans une instance OpenSearch Serverless, accessible séparément en cas de besoin. Bien que Amazon Bedrock Knowledge Base permette l'utilisation d'autres bases vectorielles comme Pinecone, nous avons choisi de ne pas explorer cette possibilité dans le cadre de ce projet. Quant au modèle d'embedding, nous avons choisi le seul disponible au moment du développement du projet : AWS Titan G1.

3.3 LLM

Pour notre couche de génération, Bedrock permet de choisir parmi nombreux modèles LLM, tels que Llama 2, Claude, Amazon Titan et d’autres. Dans le cadre de notre projet nous avons choisi l’excellent Claude Instant 1.2, plus rapide que Claude 2, et possédant une context window de 100.000 tokens. Par ailleurs, à différence de la plupart des modèles, Claude Instant 1.2 est également compatible avec les services de RAG serverless de Bedrock Knowledge Base ce qui simplifie ultérieurement notre choix.

3.4 Front-Ends

La couche front-end se compose de trois applications Web distinctes :

1. La première application fournit l'affichage du résumé de la présentation en cours.
2. La deuxième offre une interface de questions-réponses, comprenant un champ de texte permettant à l'utilisateur de poser des questions.
3. La troisième application fournit l'interface d'enregistrement destinée à l'opérateur du service.

Ces trois applications présentent une architecture simple, basée sur du HTML et du Vanilla JS, qui interagit avec des fonctions AWS Lambda exposées via un API Gateway.

Pour ce qui est des deux premières applications, leur simplicité est en partie due au niveau d'abstraction offert par l'API de Bedrock, qui, bien que sa documentation soit actuellement assez sommaire, reste très accessible.

Quant à l'application fournissant l'interface d'enregistrement, elle utilise les API d'enregistrement audio du navigateur et est responsable du découpage en segments de 30 secondes. Cette approche peut sembler sub-optimale car le découpage est réalisé de manière basique, entraînant parfois la coupure de certains mots en deux, alors que le serveur aurait pu effectuer un découpage plus intelligent. Néanmoins, cette méthode nous évite de maintenir un serveur de streaming, ce qui se traduit par des économies significatives.

4. Résultats

Après une première itération, les résultats nous ont semblé rapidement prometteurs. Comme évoqué plus haut, pour le processing Speech-to-Text nous avions expérimenté des tasks AWS Fargate avant d’opter pour une AWS Lambda qui, lors d’un démarrage à chaud, offre des performances d'inférence très intéressantes. De plus, le temps de calcul et de stockage des embeddings sur AWS est de 5 secondes environ, ce qui est négligeable dans notre cas d’utilisation.

Concrètement, de bout en bout, le système est capable de produire un résumé d'une portion d'une présentation en 15 à 17 secondes après la fin de l'enregistrement du premier segment.

4.1. Optimisations

Pour réduire ultérieurement le délai de disponibilité du résumé, nous avons mis en place un petit contournement. En effet, grâce à la taille de la fenêtre de contexte de Claude Instant 1.2, le service de résumé n’a pas besoin de récupérer l’information depuis la base de données vectorielles, mais reçoit le verbatim du texte de la présentation en cours directement dans le prompt. Dans le cadre du service de résumé, cela nous permet donc d'économiser facilement les 5 secondes nécessaires à la vectorisation du document.

4.2. Limitations

Bien que globalement personnellement satisfaits par le résultat technologique (et du temps de développement du service) certaines limitations se sont manifestées à l’usage et demandent une réflexion approfondie.

En particulier, le modèle de Speech-to-Text ne prend pas en charge la diarization, c'est-à-dire la reconnaissance des intervenants lorsqu'il y a plusieurs voix. Cet aspect est particulièrement limitant lors d’interviews ou de tables rondes car dans ces cas le système ne pourra pas attribuer correctement les propos à chaque orateur. Par exemple, lors d’un podcast impliquant 2 intervenants X et Y, il sera impossible de répondre de manière précise à une question du type “Quel est l’avis de X ?” car le document issu du Speech-to-Text ne dispose pas de la metadonnée associant une phrase à une personne en particulier.

Il est également important de souligner que, lors de certains talks présentant un vocabulaire technique très spécifique, le speech-text, notamment dans sa version “small” peut présenter des lacunes de compréhension des termes et donc poser des difficultés de compréhension au RAG. Un modèle “large”, dans ces cas, pourrait améliorer la qualité du service mais ne pourra pas vraiment remplacer une première phase d’apprentissage des termes techniques utilisés. Cela est relativement facile car prévu par l’API du modèle Whisper mais demandra de la saisie manuelle d’information de la part de l’opérateur.

D'un point de vue produit, il est pertinent de noter que la génération en temps réel d'un résumé complet d'une présentation ne répond pas toujours aux besoins spécifiques de l'utilisateur final. Il pourrait être plus judicieux de lui offrir la possibilité de choisir la durée du résumé : soit l'intégralité de la présentation, soit les 5 à 10 dernières minutes, au cas où il aurait besoin de se remettre rapidement dans le fil du discours ou de comprendre les derniers concepts abordés par l'orateur.

5. Coûts

En ce qui concerne les coûts associés à ces services, les principales dépenses comprennent la base vectorielle OpenSearch, l'inférence "pay-per-use" du modèle linguistique Claude Instant, la fonction lambda hébergeant Whisper, ainsi que le stockage S3.

Parmi ces éléments, OpenSearch représente le poste de dépenses le plus élevé, avec un coût d’environ 6$ par jour.

Quant au Speech-to-Text sur Lambda, bonne surprise : son usage reste dans notre free tier et elle nous coute 0 après quelques centaines d’invocations. La vectorisation des documents a également un coût négligeable dans notre cas (0.01$), en vertu de son prix unitaire de $0.0001 chaque 1000 tokens d’input.

En ce qui concerne LLM, dans notre cas, la dépense, compte tenu de la faible volumétrie, est plutôt limitée, mais pas négligeable puisque, compte tenu du prix de 0.8$ par millions de token en input et 2.4$ par millions de token en output, la facture journalière après 3000 requêtes environ s’élève à 10$.

Au total, pour chaque jour d’exploitation, nous avons constaté une facture d’environ 15-16$.

Conclusion et évolutions futures

Bien que les premiers résultats soient encourageants, le projet ne s'arrête pas là. De la diarization à l’accélération du temps de traitement ou, encore, à la réduction des coûts le projet offre de nombreuses directions pour approfondir l’usage et la création de produits basés sur l’IA Générative.  Nous souhaitons améliorer la qualité de l'expérience de nos utilisateurs, si vous avez des idées, n'hésitez pas à commenter l'article Linkedin associé à cette page.