Cas d'utilisation de l'IA agentique : activer le streaming multimodal bidirectionnel en direct

Last reviewed 2026-04-06 UTC

Ce document fournit une architecture générale pour un système d'IA multi-agents bidirectionnel en direct sur Google Cloud. Le système aide les utilisateurs à accomplir des tâches techniques, comme assembler des composants complexes, diagnostiquer des dysfonctionnements d'équipement ou suivre des procédures de réparation complexes. Le système d'IA agentique fournit des conseils techniques ancrés et une surveillance automatisée de la sécurité grâce à un flux continu et bidirectionnel de données multimodales.

Ce document s'adresse aux architectes, aux développeurs et aux administrateurs qui créent et gèrent des infrastructures et des applications d'IA dans le cloud. Dans ce document, nous partons du principe que vous possédez des connaissances de base sur les agents et les modèles d'IA. Ce document ne fournit pas de conseils spécifiques pour concevoir et coder des agents d'IA.

La section Déploiement de ce document liste des exemples de code que vous pouvez utiliser pour apprendre à créer et déployer des systèmes d'IA multi-agents.

Architecture

Le diagramme suivant montre une vue d'ensemble d'une architecture qui utilise un système d'IA multi-agents pour permettre le streaming de données multimodales bidirectionnel en direct :

Architecture de haut niveau d'un système d'IA multi-agents permettant le streaming bidirectionnel de données multimodales.

L'architecture du diagramme précédent comporte deux workflows : les conseils techniques et la surveillance de la sécurité.

  • Le workflow de conseils techniques permet aux utilisateurs de recevoir des solutions commentées en temps réel à des questions techniques complexes. Ce workflow utilise le modèle Gemini Live pour traiter les flux multimodaux et se coordonner avec un sous-agent afin de récupérer des informations produit ancrées dans la base de connaissances.
  • Le workflow de surveillance de la sécurité permet de détecter automatiquement les dangers pour assurer la sécurité des utilisateurs lors des procédures techniques. Ce workflow utilise Gemini pour analyser les segments vidéo en direct, identifier les risques potentiels et déclencher des avertissements immédiats dans le tableau de bord client.

Les onglets suivants fournissent des schémas d'architecture qui illustrent les workflows de conseils techniques et de surveillance de la sécurité :

Workflow de conseils techniques

Le diagramme suivant illustre une architecture détaillée pour un workflow de conseils techniques.

Architecture illustrant le workflow des conseils techniques.

Le schéma précédent montre le flux de données suivant :

  1. Un utilisateur lance une session en posant une question technique à l'oral via le tableau de bord client. Par exemple, un technicien peut pointer sa caméra sur un panneau de commande et demander : "À l'aide, que signifie ce voyant rouge clignotant ?"

  2. Le tableau de bord client établit une connexion WebSocket persistante entre le frontend et le serveur backend.

  3. Les messages WebSocket regroupent les données multimédias brutes dans des objets Blob. Le composant Agent Development Kit (ADK)LiveRequestQueue diffuse en continu les données d'entrée à l'agent répartiteur.

  4. L'agent répartiteur détecte les commandes audio ou visuelles nécessitant des conseils techniques et envoie le flux d'entrée au modèle Gemini Live.

  5. Le modèle Gemini Live recherche des événements dans les données brutes. Les événements sont des mots clés audio, tels que "assemble" ou "help", ou des signaux visuels, tels que des gestes de la main.

    Gemini évalue chaque événement pour déterminer s'il est pertinent pour la demande de l'utilisateur. Par exemple, un geste de la main ou des mots de remplissage peuvent ne pas être pertinents. Gemini ne traite donc pas ces événements.

  6. Pour chaque événement pertinent, Gemini active l'appel de fonction afin d'évaluer s'il a besoin de contexte supplémentaire. Selon que du contexte supplémentaire est nécessaire ou non, Gemini ou un agent architecte renvoie une réponse à l'agent répartiteur.

    1. Si Gemini a besoin de plus de contexte, il recherche la fiche de l'agent de l'architecte pour comprendre comment structurer sa requête.

    2. Gemini envoie une requête structurée à l'agent répartiteur. La requête contient des informations sur l'événement, telles que le type de produit, le numéro de modèle, le type d'événement et les attributs.

    3. L'agent répartiteur utilise le protocole Agent2Agent (A2A) pour envoyer la requête structurée à l'agent architecte.

    4. L'agent d'architecture envoie la requête via un connecteur d'accès au VPC sans serveur . Le connecteur permet à l'agent d'accéder de manière sécurisée aux ressources du réseau de cloud privé virtuel (VPC) utilisé pour les ressources de stockage de cette architecture.

    5. Le connecteur d'accès au VPC sans serveur interagit avec les données mises en cache stockées dans Memorystore pour Redis Cluster. Si les données ne sont pas disponibles dans le calque mis en cache, l'agent d'architecture interagit avec les instances Compute Engine qui hébergent la base de connaissances.

    6. L'agent architecte reçoit les informations produit à partir du cache de données ou de la base de connaissances. L'agent d'architecture envoie les informations produit à Gemini pour générer une réponse. Par exemple, "Code d'erreur 3B : dysfonctionnement du ventilateur. Action recommandée : Vérifiez qu'il n'y a pas d'obstruction."

    7. L'agent d'architecture renvoie les informations produit à l'agent répartiteur.

    Si Gemini n'a pas besoin de plus de contexte, il génère directement une réponse à la demande de l'utilisateur.

  7. L'agent répartiteur reçoit la réponse de Gemini ou de l'agent d'architecture, et génère une réponse multimodale :

    1. Utilise le modèle Gemini Live et la fonction ADK run_live pour générer une réponse multimodale contenant la solution technique.

    2. Stocke la réponse en tant qu'objet Blob.

    3. Envoie la solution technique via le tampon de streaming et la connexion WebSocket persistante pour la transmettre au tableau de bord client.

  8. Le tableau de bord client extrait les données Blob de la solution technique pour fournir des conseils immédiats et à l'oral, et il met à jour l'UI avec les transcriptions pertinentes. La boucle de requête est terminée, tandis que le flux bidirectionnel actif est maintenu.

Workflow de surveillance de la sécurité

Le diagramme suivant présente une architecture détaillée pour un workflow de surveillance de la sécurité.

Architecture illustrant le workflow de surveillance de la sécurité.

Le schéma précédent montre le flux de données suivant :

  1. Le tableau de bord client établit une connexion WebSocket persistante entre le frontend et le serveur de backend pour observer le flux vidéo en direct. Le message WebSocket regroupe ces données multimédias brutes dans des objets Blob et les envoie en continu au tampon de flux, à l'aide du composant ADK LiveRequestQueue.
  2. Le tampon de streaming dirige le flux d'entrée vers un outil de streaming qui s'exécute dans une boucle d'arrière-plan continue pour détecter les dangers dans le frame vidéo.
  3. L'outil de streaming envoie la dernière image vidéo du tampon de streaming à Gemini.
  4. Gemini observe les images vidéo pour détecter les dangers, comme une lumière vive ou de la vapeur.
    • Si aucun danger n'est détecté, rien ne se passe.
    • Si un danger est détecté, Gemini génère une réponse multimodale contenant le type de danger, ses attributs et son emplacement, et la stocke sous la forme d'un objet Blob. Gemini renvoie la réponse d'avertissement de danger à l'outil de streaming.
  5. L'outil de streaming transmet la réponse d'avertissement de danger au tampon de streaming.
  6. Le tampon de flux utilise la connexion WebSocket persistante pour fournir la solution technique au tableau de bord client.
  7. Le tableau de bord client extrait les données Blob de la solution technique pour fournir des conseils immédiats et met à jour l'UI avec les transcriptions pertinentes. Cela termine la boucle de requête tout en conservant le flux bidirectionnel actif.

Produits utilisés

Cette architecture de référence utilise les produits et outils suivants : Google Cloud

  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Gemini: famille de modèles d'IA multimodaux développés par Google.
  • Vertex AI : plate-forme de ML qui vous permet d'entraîner et de déployer des modèles de ML et des applications d'IA, et de personnaliser les LLM à utiliser dans des applications basées sur l'IA.
  • Agent Development Kit (ADK) : ensemble d'outils et de bibliothèques permettant de développer, de tester et de déployer des agents d'IA.
  • Protocole Agent2Agent (A2A) : protocole ouvert qui permet la communication et l'interopérabilité entre les agents, quels que soient leur langage de programmation et leur environnement d'exécution.
  • Accès au VPC sans serveur : service qui permet à vos environnements sans serveur de se connecter aux ressources d'un réseau de cloud privé virtuel.
  • Cloud privé virtuel (VPC) : système virtuel qui fournit des fonctionnalités de mise en réseau mondiales et évolutives pour vos charges de travail Google Cloud . Le VPC inclut l'appairage de réseaux VPC, Private Service Connect, l'accès aux services privés et le VPC partagé.
  • Memorystore pour Redis Cluster : service de data store en mémoire entièrement géré pour Redis.
  • Compute Engine : service de calcul sécurisé et personnalisable qui vous permet de créer et d'exécuter des machines virtuelles au sein de l'infrastructure de Google.

Pour savoir comment sélectionner d'autres composants pour votre système d'IA agentive, y compris le framework, l'environnement d'exécution de l'agent, les outils, la mémoire et les modèles de conception, consultez Choisir les composants de votre architecture d'IA agentive.

Cas d'utilisation

Cette architecture de référence est conçue pour les cas d'utilisation qui nécessitent la synthèse en temps réel de flux de données multimodaux continus et bidirectionnels. Voici quelques exemples de cas d'utilisation de l'architecture décrite dans ce document :

  • Fabrication industrielle et maintenance sur le terrain : permettez aux techniciens de réparer des machines complexes en gardant les mains libres grâce à un assistant IA qui traite les flux audio et vidéo en direct des lunettes connectées. Le technicien discute avec l'assistant IA pour obtenir les schémas de la machine. L'assistant IA utilise un agent de base de données interne qui accède à la documentation produit pour fournir des instructions de réparation et d'assemblage ancrées. Un outil de vision en arrière-plan simultané surveille le flux bidirectionnel pour avertir de manière proactive le technicien des risques mécaniques ou des étapes d'assemblage incorrectes.
  • Assistance technique à distance : améliorez les résultats du dépannage pour les clients en leur permettant de partager le flux de la caméra de leur téléphone en direct avec un système d'IA agentique multimodale. L'architecture de streaming bidirectionnel permet une conversation dynamique où le système observe le matériel en temps réel. Si un processus de vision en arrière-plan identifie une connexion défectueuse, par exemple un câble branché sur le mauvais port, le système utilise le flux à faible latence pour interrompre immédiatement l'utilisateur et lui fournir des conseils de correction.

Considérations de conception

Les sections suivantes fournissent des recommandations générales pour concevoir les agents d'IA et implémenter cette architecture pour la production.

Conception d'agents IA

Pour améliorer le coût et les performances de vos agents, tenez compte des recommandations suivantes :

  • Scripts de boucle de contrôle : rédigez des invites système pour les agents en direct bidirectionnels sous forme de boucles de comportement strictes de machine à états plutôt que de simples consignes de personnalité. L'invite système doit explicitement demander à l'agent de rester silencieux jusqu'à ce qu'il soit déclenché. Il doit appliquer des réponses brèves et axées sur l'action pour que l'interaction vocale soit concise et naturelle.
  • Séparation des préoccupations : utilisez un outil de streaming en arrière-plan dédié pour surveiller les flux vidéo indépendamment de l'agent principal. L'agent racine de l'architecture est bidirectionnel et peut interrompre instantanément sa propre parole pour diffuser ces avertissements de sécurité critiques à l'utilisateur. De plus, si vous demandez à un seul agent de surveiller constamment un flux vidéo, cela peut entraîner une surcharge cognitive et des hallucinations.
  • Requêtes économiques : la longueur de vos requêtes (entrée) et des réponses générées (sortie) affecte directement les performances et les coûts. Rédigez des requêtes courtes et directes, qui fournissent suffisamment de contexte. Concevez vos requêtes pour obtenir des réponses concises du modèle. Par exemple, incluez des expressions telles que "résume en deux phrases" ou "liste trois points clés". Pour en savoir plus, consultez les bonnes pratiques pour la conception des requêtes.

Conception de la production

Pour implémenter cette architecture en production, tenez compte des recommandations suivantes :

  • Sécurité de l'entrée : pour contrôler l'accès à l'application, désactivez l'URL run.app par défaut du service Cloud Run de frontend et configurez un équilibreur de charge d'application externe régional. En plus d'équilibrer la charge du trafic entrant vers l'application, l'équilibreur de charge gère les certificats SSL. Pour une protection renforcée, vous pouvez utiliser les stratégies de sécurité Google Cloud Armor afin de filtrer les requêtes, de protéger le service contre les attaques DDoS et de limitation du débit.
  • Contrôle des accès : lorsque vous configurez les autorisations pour les ressources de votre topologie, respectez le principe du moindre privilège.
  • Mise en mémoire tampon asynchrone : pour dissocier les paquets audio et vidéo entrants du moteur d'inférence du modèle, utilisez une mémoire tampon First-In-First-Out (FIFO) asynchrone et thread-safe. Ce tampon agit comme un multiplexeur qui garantit que le système reste réactif aux interruptions de l'utilisateur sans bloquer l'interface utilisateur lors de calculs intensifs.
  • Coûts d'ingestion de données : pour réduire les coûts liés aux jetons et éviter l'épuisement de la fenêtre de contexte, utilisez un échantillonnage de frames à basse fréquence (par exemple, deux frames par seconde) et compressez toutes les données en fichiers JPEG Base64.
  • Mise en cache en mémoire : pour obtenir des vitesses de lecture inférieures à une milliseconde, utilisez une base de données Memorystore pour Redis Cluster en mémoire pour le coffre-fort des schémas de l'agent d'architecture. Cette implémentation minimise la latence, évite les silences lors des interactions vocales en temps réel et fournit une source de référence unique et évolutive.
  • Sécurité WebSocket : protégez les données multimodales sensibles, telles que les empreintes vocales et les vidéos, en appliquant le chiffrement TLS pour toutes les connexions WebSocket bidirectionnelles.
  • Communication A2A sécurisée :
  • Allocation des ressources : en fonction de vos exigences en termes de performances, configurez les limites de mémoire et les limites de processeur à allouer au service Cloud Run.

Pour en savoir plus sur les facteurs de conception, les bonnes pratiques et les recommandations pour créer et déployer un système d'IA multi-agents, consultez Système d'IA multi-agents dans Google Cloud.

Déploiement

Pour déployer un exemple d'implémentation de cette architecture, essayez Codelabs suivants :

Étapes suivantes

Contributeurs

Auteurs :

  • Christina Lin | Responsable de l'équipe d'ingénieurs en relations avec les développeurs
  • Samantha He | Rédactrice technique

Autres contributeurs :