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 de haut niveau pour un système d'IA multi-agent bidirectionnel en direct, sur Google Cloud. Le système aide les utilisateurs à effectuer des tâches techniques, telles que l'assemblage de composants complexes, le diagnostic de dysfonctionnements d'équipements ou le suivi de procédures de réparation complexes. Le système d'IA agentique fournit des conseils techniques fiables et une surveillance de sécurité automatisée 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 avez déjà acquis les connaissances de base sur les agents et les modèles d'IA. Ce document ne fournit pas de conseils spécifiques pour la conception et le codage d'agents d'IA.

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

Architecture

Le schéma suivant présente une vue de haut niveau d'une architecture qui utilise un système d'IA multi-agents pour activer 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 schéma précédent comporte deux workflows : conseils techniques et surveillance de la sécurité.

  • Le workflow de conseils techniques permet aux utilisateurs de recevoir des solutions commentées en temps réel à des requêtes 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 à partir de la base de connaissances.
  • Le workflow de surveillance de la sécurité fournit une détection automatisée des 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 via le tableau de bord client.

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

Workflow de conseils techniques

Le schéma suivant présente 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 effectuant une requête technique orale via le tableau de bord client. Par exemple, un technicien peut pointer sa caméra vers un panneau de commande et demander : "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 kit de développement d'agents (ADK) LiveRequestQueue composant 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 qui nécessitent des conseils techniques et envoie le flux d'entrée au modèle Gemini Live.

  5. Le modèle Gemini Live recherche les événements dans les données brutes. Les événements sont des mots clés audio, tels que "assembler" ou "aide", 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 requête 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 de déterminer s'il a besoin de contexte supplémentaire. Selon qu'un contexte supplémentaire est nécessaire ou non, Gemini ou un agent architecte renvoie une réponse à l'agent répartiteur.

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

    2. Gemini envoie une requête structurée à l'agent répartiteur. La requête contient des détails sur l'événement, tels 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 architecte envoie la requête via un connecteur 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 dans 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 la couche mise en cache, l'agent architecte 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 architecte 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 s'il y a des obstructions."

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

    S'il n'a pas besoin de plus de contexte, Gemini génère directement une réponse à la requête 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 run_live de l'ADK 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 fournir au tableau de bord client.

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

Workflow de surveillance de la sécurité

Le schéma 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 backend pour observer le flux vidéo en direct. Le message WebSocket regroupe ces données multimédias brutes dans des Blob objets et les envoie en continu au tampon de streaming à l’aide du composant LiveRequestQueue de l’ADK.
  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 l'image 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, tels qu'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 en tant qu'objet Blob. Gemini renvoie la réponse d'avertissement de danger à l'outil de streaming.
  5. L'outil de streaming transfère la réponse d'avertissement de danger au tampon de streaming.
  6. Le tampon de streaming utilise la connexion WebSocket persistante pour fournir la solution technique au tableau de bord client.
  7. Le tableau de bord client extrait les Blob données de la solution technique pour fournir des conseils commentés immédiats et met à jour l'interface utilisateur avec les transcriptions pertinentes. La boucle de requête est ainsi terminée tout en maintenant le flux bidirectionnel actif.

Produits utilisés

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

  • 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.
  • Gemini Enterprise Agent Platform : plate-forme complète qui vous permet de créer, de faire évoluer, de gérer et d'optimiser des agents IA professionnels.
  • Agent Development Kit (ADK) : ensemble d'outils et de bibliothèques permettant de développer, de tester et de déployer des agents 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 Google Cloud charges de travail. 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 VM au sein de l'infrastructure de Google.

Pour en savoir plus sur la sélection de composants alternatifs pour votre système d'IA agentique 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 agentique.

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 multimodales bidirectionnels continus. Voici quelques exemples de cas d'utilisation pour l'architecture décrite dans ce document :

  • Fabrication industrielle et maintenance sur le terrain : permettez la réparation sans les mains de machines complexes en fournissant aux techniciens un assistant IA qui traite l'audio et la vidéo en direct à partir de lunettes connectées. Le technicien converse avec l'assistant IA pour récupérer 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 garantir des instructions de réparation et d'assemblage fiables. Un outil de vision en arrière-plan simultané surveille le flux bidirectionnel pour avertir de manière proactive le technicien des dangers mécaniques ou des étapes d'assemblage incorrectes.
  • Assistance technique à distance : améliorez les résultats de dépannage des clients en permettant aux utilisateurs de partager un flux de caméra de téléphone en direct avec un système d'IA agentique multimodal. L'architecture de streaming bidirectionnel est compatible avec une conversation dynamique dans laquelle 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 dans le mauvais port, le système utilise le flux à faible latence pour interrompre immédiatement l'utilisateur avec des conseils correctifs.

Considérations de conception

Les sections suivantes fournissent des recommandations générales pour la conception des agents d'IA et la mise en œuvre de cette architecture pour la production.

Conception de l'agent IA

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

  • Scripts de boucle de contrôle : écrivez des invites système pour les agents en direct bidirectionnels sous forme de boucles de comportement de machine à états strictes 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 afin 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 son propre discours 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 rentables : la longueur de vos requêtes (entrée) et des réponses générées (sortie) affecte directement les performances et le coût. Rédigez des requêtes courtes, directes et fournissant un contexte suffisant. Concevez vos requêtes pour obtenir des réponses concises du modèle. Par exemple, incluez des expressions telles que "résumer en deux phrases" ou "lister trois points clés". Pour en savoir plus, consultez les bonnes pratiques pour la conception de requêtes.

Conception de la production

Pour mettre en œuvre cette architecture pour la production, tenez compte des recommandations suivantes :

  • Sécurité d'entrée : pour contrôler l'accès à l'application, désactivez l'URL run.app par défaut du service Cloud Run 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 la gestion des certificats SSL. Pour une protection accrue, vous pouvez utiliser les stratégies de sécurité Google Cloud Armor pour fournir un filtrage des requêtes, une protection contre les attaques DDoS et une limitation du débit pour le service.
  • Contrôle des accès : lorsque vous configurez les autorisations pour les ressources de votre topologie, suivez le principe du moindre privilège.
  • Mise en mémoire tampon asynchrone : pour dissocier les paquets audio et vidéo entrants de le moteur d'inférence du modèle, utilisez un tampon FIFO (First-In-First-Out) asynchrone et thread-safe. tampon FIFO (First-In-First-Out). 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 des données : pour réduire les coûts des jetons et éviter l'épuisement de la fenêtre de contexte, utilisez un échantillonnage d'images à basse fréquence, par exemple deux images par seconde , et compressez toutes les données dans des fichiers JPEG Base64.
  • Mise en cache en mémoire : pour atteindre des vitesses de lecture inférieures à la milliseconde, utilisez une base de données Memorystore pour Redis Cluster en mémoire pour le coffre-fort schématique de l'agent architecte. 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 lechiffrement 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 concernant la création et le déploiement d'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 :

Étape suivante

Contributeurs

Auteurs :

Autres contributeurs :