Architecture de l'agent ADK RMI

**Important** : Avant de pouvoir interroger les données Roads Management Insights, vous devez d'abord vous abonner à l'ensemble de données de partage de démonstration Boston RMI (ou acheter un abonnement à l'ensemble de données RMI pour votre zone géographique) et avoir accès à l'API Gemini.

Objectif

L'agent ADK Roads Management Insights (RMI) fournit une interface en langage naturel pour interroger et analyser les données RMI stockées dans Google BigQuery. En tirant parti d'Agent Development Kit (ADK) de Google et des grands modèles de langage Gemini, il permet aux utilisateurs d'extraire des insights exploitables à partir d'ensembles de données à grande échelle sur le réseau routier et le trafic sans avoir à écrire manuellement des requêtes SQL complexes.

Architecture de référence

L'architecture se compose d'un système d'agents hiérarchique dans lequel un agent racine planifie et orchestre les interactions utilisateur, en déléguant des tâches spécifiques de récupération de données et de génération SQL à un sous-agent spécialisé.

Composants

1. Agent RMI (agent racine)

• Rôle : interface conversationnelle principale et orchestrateur de tâches.
• Responsabilités:
  • Maintient le contexte de conversation multitour.
  • Décompose les requêtes en langage naturel en tâches analytiques exploitables.
  • Délègue les tâches de récupération de données structurées à l'agent BigQuery.
  • Synthétise les données tabulaires brutes renvoyées par le sous-agent en insights concis et lisibles par l'humain.

2. Agent BigQuery (sous-agent)

• Rôle : agent spécialisé dans la traduction SQL et l'exécution de bases de données.
• Responsabilités:
  • Traduit les instructions en langage naturel de l'agent racine en requêtes SQL BigQuery optimisées.
  • Exécute les requêtes directement sur l'ensemble de données BigQuery configuré.
  • Renvoie les résultats de requête bruts et non modifiés à l'agent racine.

3. Ensemble de données BigQuery

• Rôle : entrepôt de données analytiques cloud natif.
• Contenu : tables Roads Management Insights (RMI), y compris historical_travel_time et recent_roads_data, structurées conformément au schéma RMI BigQuery.

4. Google GenAI

• Rôle : moteur de raisonnement et de génération de langage de base.
• Modèle : utilise les modèles Google Gemini (par exemple, gemini-3.5-flash) pour optimiser l'orchestration des agents, la compréhension du langage naturel et la génération SQL .

Flux d'exécution

1. Requête utilisateur : l'utilisateur envoie une question en langage naturel (par exemple, "Quel était le temps de trajet moyen sur la route 66 hier ?").
2. Planification et orchestration : l'agent RMI reçoit la requête, identifie que des données de trafic empiriques sont nécessaires et formule une instruction de récupération spécifique pour le sous-agent.
3. Délégation : l'agent RMI appelle l'agent BigQuery avec l' instruction structurée et les contraintes temporelles ou spatiales pertinentes.
4. Génération SQL : en s'appuyant sur sa compréhension du schéma RMI, l' agent BigQuery génère une requête SQL BigQuery optimisée.
5. Exécution et récupération des données : l'agent BigQuery exécute la requête sur l'ensemble de données BigQuery sous-jacent et récupère les enregistrements tabulaires résultants.
6. Synthèse de la réponse : l'agent BigQuery renvoie les données brutes non modifiées à l'agent RMI, qui interprète les résultats, résout les identifiants de route manquants et crée une réponse claire en langage naturel pour l'utilisateur.

Exemple de scénario

Le défi

Un urbaniste doit évaluer la congestion du trafic sur un réseau routier métropolitain pour déterminer si les temps de signalisation doivent être ajustés pendant les heures de pointe du soir.

Solution workflow

1. Requête utilisateur : l'urbaniste interagit avec l'agent à l'aide de la CLI ou de l'interface utilisateur Web, en posant la question suivante :

   "Identifiez les cinq routes les plus encombrées du centre-ville de Boston vendredi dernier à 17h."

2. Traitement de l'agent :

   • L'agent RMI analyse la requête. Il identifie l'emplacement cible ("centre-ville de Boston"), la fenêtre temporelle ("vendredi dernier à 17h") et l'objectif analytique ("cinq routes les plus encombrées"). Il détermine que "congestion" doit être mesurée comme le rapport entre la durée du trajet en temps réel et la durée statique (duration_in_seconds / static_duration_in_seconds).

   • Il délègue la récupération des données à l'agent BigQuery avec une instruction structurée :

     "Recherchez les tronçons de route du centre-ville de Boston et renvoyez les cinq premiers avec le taux de congestion le plus élevé pour le vendredi 9 janvier 2026 à 17h."

3. Récupération des données :

   • L'agent BigQuery traduit cette instruction en une requête SQL ciblant la table historical_travel_time, en calculant le taux de congestion et en triant les résultats pour identifier les cinq premiers segments.
   • Il exécute la requête sur BigQuery.
   • BigQuery renvoie des résultats tabulaires bruts, tels que (segment_id, display_name, duration_in_seconds, static_duration_in_seconds, congestion_ratio).

4. Génération d'insights :

   • L'agent BigQuery renvoie la liste brute des segments à l'agent RMI.
   • L'agent RMI analyse les enregistrements, gère les tronçons de route dont le nom d'affichage est manquant ou qui ne contiennent que des références d'identifiant, et synthétise les données dans un résumé.

   • L'agent crée la réponse finale :

     "Le vendredi 9 janvier 2026 à 17h, les routes les plus encombrées du centre-ville de Boston ont connu des temps de trajet nettement plus longs que leur durée statique habituelle. Voici les cinq tronçons les plus encombrés en fonction du rapport entre la durée en fonction du trafic et la durée statique : Route roads/CgkJZ-tTXuNcW4s : il s'agit du tronçon le plus encombré, avec un temps de trajet de 66 secondes contre une durée statique de seulement 6 secondes (un taux de congestion de 11,0x)..."

Conclusion

En dissociant l'interaction conversationnelle et la synthèse narrative de la génération SQL de bas niveau et de la récupération des données, l'architecture hiérarchique de l'agent ADK RMI comble le fossé entre les entrepôts de données géospatiales complexes et les utilisateurs finaux. L'isolation de l'exécution de la base de données dans un sous-agent spécialisé favorise la modularité, la facilité de maintenance et la sécurité opérationnelle, tout en permettant aux décideurs d'extraire rapidement des insights vérifiables en langage naturel.

Étapes suivantes

• Personnaliser pour votre cas d'utilisation : adaptez cette architecture multi-agent et cette conception de prompt à vos cas d'utilisation géospatiaux ou organisationnels spécifiques.
• Étendre avec des agents de planification spécialisés : intégrez un agent de planification dédié pour orchestrer des workflows analytiques complexes en plusieurs étapes.
• Intégrer des sources de données multimodales : enrichissez les insights sur la gestion du trafic et des routes en combinant les données RMI avec des couches spatiales supplémentaires, telles que les événements météorologiques, les calendriers de construction ou les flux d'incidents en direct.
• Déployer en production : faites passer votre agent du prototype à un environnement d'entreprise de production en suivant le guide pour enregistrer et gérer les agents ADK hébergés sur Gemini Enterprise Agent Platform.

Contributeurs

Kel Markert | Cloud Géographe