Ancrer les agents RMI ADK dans l'expertise du domaine grâce aux compétences

Présentation

Les grands modèles de langage disposent de connaissances générales étendues, mais ils ne connaissent pas les métriques spécifiques à votre domaine, les schémas de base de données ni les formules de calcul. Sans ce contexte, le modèle devine, ce qui entraîne un code SQL incorrect et une analyse erronée.

L'agent ADK RMI répond à cette limitation grâce aux compétences. Prenons l'exemple d'un utilisateur qui demande "comment était la circulation sur Storrow Drive hier ?". Pour répondre, l'agent doit savoir que RMI exprime la congestion sous la forme de l'indice de temps de trajet (TTI), qui correspond au rapport entre le duration_in_seconds en temps réel et le static_duration_in_seconds en temps normal dans le tableau historical_travel_time. Un agent sans compétences peut inventer une colonne average_speed (les rapports RMI n'indiquent que la vitesse catégorielle, jamais en km/h) ou appliquer la mauvaise formule, ce qui produit une réponse confiante, mais incorrecte.

Bien que l'agent ait besoin de ces connaissances sur le domaine, il est inefficace de placer chaque définition de métrique, schéma de tableau et mise en garde SQL dans un seul prompt système.

Limites des grands prompts système

Le fait de placer toutes les règles et tous les schémas de domaine dans une seule invite système pose plusieurs problèmes :

  • Coûts plus élevés et réponses plus lentes : envoyer une requête énorme à chaque tour gaspille des jetons et augmente la latence, même pour les questions qui n'ont pas besoin de ces règles.
  • Moins bonne compréhension des instructions : à mesure qu'une requête s'allonge avec des cas extrêmes, le modèle est plus susceptible d'ignorer ou d'oublier des règles spécifiques.
  • Maintenance plus difficile : combiner tous les éléments dans une seule requête rend difficile la mise à jour ou le test de règles individuelles sans en enfreindre d'autres.

Compétences

Les compétences de l'agent organisent les connaissances du domaine dans des dossiers modulaires que l'agent ne charge qu'en cas de besoin. Chaque compétence est un répertoire contenant un fichier SKILL.md avec des instructions Markdown et un en-tête YAML.

Au lieu de tout charger à l'avance, l'agent ne conserve que le description court de chaque compétence dans son prompt de base. Lorsqu'un utilisateur pose une question en rapport avec une compétence, l'agent charge les instructions complètes pour ce tour. Cela permet de limiter la taille des requêtes et de réserver de l'espace pour l'historique des conversations.

Les compétences permettent également de séparer clairement les préoccupations : vous pouvez écrire, tester et mettre à jour des fonctionnalités individuelles de manière isolée, sans risquer d'effets secondaires indésirables dans des domaines non liés. Un agent de production utilise généralement plusieurs compétences ciblées plutôt qu'un seul prompt géant.

Anatomie d'une compétence

Un fichier SKILL.md comporte deux parties : un en-tête YAML pour le routage et un corps Markdown pour les instructions.

1. En-tête YAML

---
name: rmi-traffic-metrics-grounding
description: >
  Standard traffic performance metrics computable from RMI BigQuery
  tables. Covers congestion severity (TTI), delay, travel time
  reliability (LOTTR, BTI, PTI, CoV), congestion frequency, speed
  breakdowns, and network-wide congestion rates. Use when the user asks
  about traffic conditions, congestion, reliability, delay, or network
  health.
---

Le modèle utilise description pour déterminer s'il doit charger la compétence. Étant donné que le modèle ne voit cette description qu'avant de décider de charger la compétence, assurez-vous qu'elle indique clairement les sujets abordés, les expressions typiques des utilisateurs et le moment où la compétence doit être déclenchée.

2. Corps Markdown

Le corps fournit les consignes spécifiques au domaine que le modèle suit une fois chargé. Le corps de la skill de métriques RMI inclut la formule exacte du TTI (duration_in_seconds / static_duration_in_seconds), un modèle SQL BigQuery validé pour chaque métrique et des expressions déclencheurs qui associent l'intention utilisateur à la métrique appropriée. En fournissant des instructions structurées et vérifiées, vous permettez au modèle de rester ancré dans la réalité et l'empêchez de deviner les détails du schéma ou de la formule.

Enregistrer des compétences avec ADK

Regroupez les compétences dans un SkillToolset et ajoutez-les à la liste d'outils de l'agent :

from google.adk import skills
from google.adk.tools import skill_toolset

rmi_skill_toolset = skill_toolset.SkillToolset(
    skills=[
        # TRAFFIC_METRICS_SKILL_DIR points to the skill's SKILL.md folder.
        skills.load_skill_from_dir(TRAFFIC_METRICS_SKILL_DIR),
    ],
)

# root_agent = llm_agent.Agent(..., tools=[*bq_tools, rmi_skill_toolset])

Ici, TRAFFIC_METRICS_SKILL_DIR pointe vers le répertoire contenant la compétence d'ancrage des métriques de trafic.

Regrouper des outils avec des compétences

Étant donné que les compétences sont des instructions textuelles, s'appuyer uniquement sur le modèle pour interpréter et exécuter une logique complexe peut entraîner des incohérences. L'association d'outils exécutables à une compétence permet d'obtenir un certain déterminisme : le code gère les calculs stricts, les validations et les interactions avec les API, tandis que la compétence indique au modèle quand et comment les utiliser.

Le regroupement d'outils permet également d'éviter le gonflement du contexte global. Au lieu d'exposer tous les outils spécialisés à l'avance, les outils sont limités pour ne se charger que lorsque la compétence de domaine correspondante est active.

Vous pouvez associer des outils spécifiques directement à une compétence dans son en-tête YAML :

metadata:
  adk_additional_tools:
    - calculate_custom_metric

Cela permet de s'assurer que le modèle reçoit à la fois le schéma de l'outil et ses instructions d'utilisation juste à temps, ce qui permet de maintenir un ensemble d'outils de base simple.

Exemple : Ancrer une requête sur la congestion

  1. L'utilisateur demande "Quelle est la circulation sur Storrow Drive pendant l'heure de pointe du soir ?"
  2. L'invite système de base n'indique que le nom et la description de chaque compétence. L'agent voit donc que rmi-traffic-metrics-grounding couvre la "congestion" et appelle load_skill pour obtenir ses instructions complètes pour cette requête.
  3. Une fois la compétence chargée, l'agent applique la définition du TTI et le modèle SQL validé qu'il fournit, en calculant le ratio par rapport à historical_travel_time au lieu de deviner une formule.

Étant donné que le corps d'une compétence n'est récupéré que lorsqu'une requête en a besoin, les compétences que l'agent n'utilise jamais n'entrent jamais dans le contexte, ce qui permet de maintenir la petite taille de l'invite système de base.

Points à retenir

  • Ancrer avec des conseils spécifiques au domaine : fournissez des instructions, des contraintes et une logique métier explicites au lieu de vous appuyer sur des hypothèses générales du modèle.
  • Utilisez des compétences modulaires : divisez les connaissances en compétences ciblées au lieu d'une seule invite système géante pour économiser des jetons, réduire la latence et améliorer la précision.
  • Rédigez des descriptions claires : incluez des expressions et des mots clés déclencheurs spécifiques dans la description de chaque compétence pour que l'agent la charge de manière fiable.
  • Incluez des exemples concrets : ajoutez des exemples validés et des flux de travail de référence aux corps de compétences pour que les résultats restent cohérents et précis.
  • Regroupez les outils pour le déterminisme : associez des outils exécutables à des compétences pour gérer la validation et l'exécution strictes tout en conservant un ensemble d'outils de base épuré.

Étapes suivantes

Contributeurs

Nathaniel Thomas | Stagiaire en ingénierie logicielle, Google Maps Platform