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, les schémas de base de données ni les formules de calcul de votre domaine. Sans ce contexte, le modèle devine, ce qui entraîne des erreurs SQL et des analyses incorrectes.

L'agent RMI ADK résout cette limitation grâce aux compétences. Prenons l'exemple d'un utilisateur qui demande "How congested was Storrow Drive yesterday?" (Quel était le niveau de trafic 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 la duration_in_seconds en temps réel et la static_duration_in_seconds en circulation fluide dans la historical_travel_time table. Un agent sans compétences pourrait inventer une colonne average_speed (RMI ne signale que la vitesse catégorielle, jamais en km/h) ou appliquer la mauvaise formule, ce qui donnerait une réponse assurée, mais incorrecte.

Bien que l'agent ait besoin de ces connaissances du domaine, il est inefficace de placer chaque définition de métrique, schéma de table et avertissement SQL dans un seul prompt système.

Limites des grands prompts système

Placer toutes les règles et tous les schémas de domaine dans un seul prompt système pose plusieurs problèmes :

  • Coûts plus élevés et réponses plus lentes : l'envoi d'un prompt volumineux à chaque tour gaspille des jetons et augmente la latence, même pour les questions qui n'ont pas besoin de ces règles.
  • Suivi des instructions moins efficace : à mesure qu'un prompt 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 un seul prompt 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 que lorsque cela est nécessaire. 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 la courte description de chaque compétence dans son prompt de base. Lorsqu'un utilisateur pose une question concernant une compétence, l'agent charge les instructions complètes pour ce tour. Cela permet de réduire la taille des prompts et d'économiser de l'espace de contexte pour l'historique réel 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 involontaires 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 la description pour décider de charger ou non 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ù elle doit être déclenchée.

2. Corps Markdown

Le corps fournit les conseils spécifiques au domaine que le modèle suit une fois chargé. Le corps de la compétence des 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 de déclenchement qui associent l'intention utilisateur à la bonne métrique. Fournir des instructions structurées et validées permet de maintenir le modèle ancré et de l'empêcher 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, le fait de 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 assure le déterminisme : le code gère les calculs stricts, les validations et les interactions avec l'API, tandis que la compétence indique au modèle quand et comment les utiliser.

Le regroupement d'outils évite également 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 leur 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 garantit 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 la taille du jeu d'outils de base.

Exemple : Ancrer une requête de congestion

  1. L'utilisateur demande "How congested is Storrow Drive during evening rush?" (Quel est le niveau de trafic sur Storrow Drive pendant l'heure de pointe du soir ?).
  2. Le prompt système de base n'annonce 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 extraire 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 rapport 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 réduire la taille du prompt système de base.

Points à retenir

  • Ancrer avec des conseils de domaine : fournissez des instructions, des contraintes, et une logique métier explicites plutôt que de vous appuyer sur des hypothèses générales du modèle.
  • Utiliser des compétences modulaires : divisez les connaissances en compétences ciblées au lieu d'un seul prompt système géant pour économiser des jetons, réduire la latence et améliorer la précision.
  • Rédiger des descriptions claires : incluez des expressions de déclenchement et des mots clés spécifiques dans la description de chaque compétence afin que l'agent la charge de manière fiable.
  • Inclure des exemples concrets : ajoutez des exemples validés et des workflows de référence aux corps de compétences pour garantir la cohérence et la précision des résultats.
  • Regrouper des 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 maintenant la taille du jeu d'outils de base.

Étapes suivantes

Contributeurs

Nathaniel Thomas | Stagiaire en génie logiciel, Google Maps Platform