Un chatbot capable de répondre à vos questions tout en vous fournissant un lien cliquable vers la bonne vidéo YouTube, et au bon endroit dans la vidéo. C'est ce que permet cette architecture conçue sur Google Cloud, mêlant IA générative et approche serverless.
Dans cet article, nous explorerons comment mettre en place un chatbot RAG (Retrieval-Augmented Generation) qui utilise un corpus de vidéos pour fournir des réponses enrichies et pertinentes. Ce système repose sur une architecture event-driven pilotée par EventArc et des microservices déployés avec Cloud Run.
Une telle solution peut être appliquée dans divers contextes :
- Formation : Accès rapide à des segments vidéo éducatifs pertinents.
- Entreprise : Recherche d'informations dans des vidéos internes comme des réunions ou des formations.
- Médias et divertissement : Exploration d'archives vidéo ou de contenus créatifs selon des requêtes contextuelles.
- Parlement : Exploration de contenus vidéos longs : séances, commissions, etc
L'application proposée ici est l'exploration d'une playlist Youtube de formation sur les services Google Cloud.
Qu'est ce que le RAG ?
Le RAG veut dire Retrieval-Augmented Generation, et est la plupart du temps appliqué sur des documents textuels. Plutôt que de poser une question à un LLM, on va effectuer les étapes suivantes :
Ingestion
- On prend des documents pertinents pour l'application souhaitée.
- On découpe ces documents en morçeaux, appelés chunks.
- On construit une représentation de ces chunks appelée embedding, lisible par un algorithme de recherche par similarité.
- On stocke ces embeddings dans une base de données.
Récupération
- L'utilisateur pose une question qui est transformée en embedding.
- L'embedding est comparé à ceux de la base de données afin de retrouver du contexte pertinent.
- Un construit un prompt augmenté qui comporte la question de l'utilisateur ainsi que les éléments de contexte appropriés.
- Le LLM peut alors fournir une réponse pertinente sur ce prompt grâce au contexte.
Le RAG sur du contenu vidéo
Pour effectuer du RAG sur du contenu vidéo, l'idée principale est d'effectuer une transcription du contenu, afin de se ramener à un système RAG classique avec des documents.
Vue d’ensemble de l’architecture
Le système se divise en deux parties :
- Ingestion des vidéos : Un pipeline de traitement divise les vidéos en segments et génère des données prêtes pour la recherche.
- Retrieval et Chatbot : Le chatbot trouve les segments pertinents, fournit une réponse augmentée et un lien vers la vidéo correspondante.
Partie 1 : Ingestion des Vidéos
L’ingestion repose sur cinq microservices Cloud Run. Ces services traitent les vidéos, segmentent leur contenu, et transforment les données en embeddings vectoriels stockés dans Firestore pour la recherche. Chaque microservice produit un résultat dans un bucket spécifique, ce qui déclenche le traitement suivant via un déclencheur EventArc.
Étape 1 : Téléchargement des vidéos avec le service Downloader
L'utilisateur fournit une playlist YouTube via une API, et déclenche son téléchargement via un appel API sur ce service.
Les métadonnées de la playlist (titres, descriptions, ID des vidéos) sont enregistrées dans une collection Firestore nommée metadata.
Étape 2 : Segmentation des vidéos avec le service Splitter
Chaque vidéo est découpée en segments de 2 minutes avec un recouvrement de 30 secondes. Ce recouvrement permet d'éviter la perte de contexte lorsqu'une phrase est coupée en deux. La piste audio est extraite pour chaque segment et stockée dans le bucket dédié.
La collection metadata dans Firestore est mise à jour. On associe à chaque vidéo ses segments avec leurs informations, notamment les timestamps de début et de fin.
Le choix de la durée des segments (2 minutes) et de la taille de recouvrement peuvent être modifiés selon les besoins et le cas traité.
Étape 3 : Transcription des segments audio avec le service Transcriber
Les pistes audio des segments sont converties en texte grâce à l’API Speech-to-Text de Google Cloud (modèle Chirp). On obtient des transcriptions brutes dans un bucket.
Chirp est un modèle de transcription speech-to-text de pointe, conçu pour fournir des services de transcription extrêmement précis et rapides. Il prend en charge une large gamme de langues et de dialectes, ce qui en fait un choix polyvalent pour répondre à divers besoins de transcription. Il est disponible via l'API Speech-to-Text.
Étape 4 : Formatage des transcriptions avec le service Formatter
Les transcriptions brutes sont corrigées pour améliorer la grammaire et la clarté grâce à Gemini 1.5 Flash. On obtient ainsi des documents textuels dans un bucket, ce qui permet d'implémenter une logique RAG classique par la suite.
Étape 5 : Générer des embeddings avec le service Feeder
Les transcriptions finales sont transformées en embeddings vectoriels à l’aide de LangChain.
Le service Firestore sert de base de données pour les embeddings, avec une collection dédiée nommée embeddings.
Chaque embedding est stocké avec l'identifiant du segment audio auquel il appartient, ce qui permettra de retrouver les métadonnées dans la collection metadata.
Partie 2 : Retrieval et Chatbot
Une fois le corpus indexé, le chatbot répond aux questions des utilisateurs en recherchant les segments pertinents dans les embeddings et en fournissant un lien précis vers la vidéo source. Le timestamp correspondra au point de départ du segment audio le plus pertinent.
Étapes du chatbot :
Requête utilisateur : L'utilisateur pose une question via Google Chat.
-
Recherche par similarité :
- Les embeddings correspondant à la question sont récupérés dans Firestore.
- Les métadonnées associées (ID vidéo, segment, timestamps) sont extraites.
Reranking : La recherche par similarité permet d'obtenir les N chunks les plus pertinents (N=5 dans notre cas). L'étape de reranking consiste à utiliser un LLM pour réordonner ces chunks par ordre de pertinence, et n'en sélectionner qu'un.
-
Génération de réponse :
- Un prompt enrichi par le contexte du segment (le chunk retrouvé après reranking) est envoyé au LLM.
- Une URL est reconstruite avec le bon ID vidéo et le timestamp exact.
Validation finale avec Gemini 1.5 Flash :
On ne veut pas que l'URL de la vidéo soit fournie pour chaque réponse, sinon une question qui n'a rien à voir avec le contexte aboutirait quand même vers le contenu le moins éloigné en termes de similarité.
Le prompt augmenté est le suivant :
"""
You are a chatbot working for Stack Labs company. Your job is to retrieve information from videos.
You have to answer users' questions using the context given below, taken from video transcripts.
Don't invent anything, just use the context.
If you don't have a context, answer that you can't find one.
You must answer in english.
Context:
{context}
Question:
{query}
"""
Par conséquent la réponse du LLM peut comporter trois types de réponses :
- Le chatbot dit qui il est et à quoi il sert
- Le chatbot fournit un discours technique sur la base du contexte retrouvé dans Firestore
- Le chatbot dit qu'il n'a pas de contexte
On ne veut fournir un lien cliquable à l'utilisateur que s'il s'agit d'un discours technique. On va donc faire un appel supplémentaire à Gemini 1.5 Flash, en le forçant à fournir l'un des trois flags suivants :
- who_am_i : Le chatbot se présente.
- technical_speech : Réponse technique.
- no_context : Aucune information trouvée.
Il est possible de configurer Gemini pour qu'il retourne une réponse au format JSON en respectant un schéma :
classification_schema = {
"type": "object",
"properties": {
"response_type": {
"type": "string",
"enum": [
"who_am_i",
"technical_speech",
"no_context"
],
"description": "Message type based on context."
}
}
}
Le prompt donné à Gemini pour la classification est le suivant :
"""
Message : {message}
Classify this message by categorizing it into one of the following categories:
- who_am_i: the message is someone presenting himself
- technical_speech: Contains technical jargon, code-related keywords, or specific terminologies.
- no_context: the message says that no context is found
"""
Si la réponse appartient à la catégorie technical_speech, l’URL est ajoutée à la réponse.
Voici un aperçu du résultat :
Avantages de cette architecture
1. Liens contextuels précis
Le chatbot fournit des réponses enrichies avec des liens vidéo cliquables, garantissant une navigation rapide vers l’information.
2. Scalabilité et efficacité
L’utilisation de Cloud Run et EventArc permet une exécution à la demande et une scalabilité horizontale, tout en garantissant des coûts contenus.
3. Modularité
Chaque microservice est indépendant, ce qui facilite les mises à jour et l’ajout de nouvelles fonctionnalités. Chaque microservice Cloud Run peut être géré de façon indépendante : gestion de la capacité mémoire et CPU, montage d'un volume, etc.
4. Personnalisation
Cette solution peut être facilement personnalisée pour différents contextes, notamment le choix de la taille et du recouvrement des différents segments audios.
Conclusion
Cette architecture montre comment Google Cloud peut permettre une recherche d'informations efficace dans un corpus de vidéos. Le choix d’une approche serverless et event-driven garantit un système flexible, scalable, facile à maintenir et peu coûteux.
Merci d'avoir lu ! Nous sommes Victor et Maximilien, développeur et data engineer chez Stack Labs. Si vous souhaitez découvrir la Stack Labs Data Platform ou rejoindre une équipe tech motivée, n'hésitez pas à nous contacter.
Top comments (0)