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.
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.
É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 :
ou rejoindre une équipe tech motivée, n'hésitez pas à nous contacter.
SOCIAL SHARE CARD GENERATOR