Cette page a été traduite par l'API Cloud Translation.

Présentation des agents de données

Les agents de données vous permettent d'interagir avec les données de votre base de données en langage conversationnel. Vous pouvez créer des agents de données en définissant le contexte d'un ensemble de tables dans votre base de données. Cela permet aux agents de données de traduire les questions en langage naturel en requêtes précises pour vos cas d'utilisation cibles.

Le contexte est constitué d'informations spécifiques à la base de données qui permettent au LLM de générer des requêtes très précises. Le contexte inclut des modèles et des facettes (fragments) qui aident l'agent à comprendre le schéma de votre base de données et la logique métier de vos applications.

Les bases de données suivantes sont acceptées :

AlloyDB pour PostgreSQL
Cloud SQL pour MySQL
Cloud SQL pour PostgreSQL
Spanner

Quand utiliser les agents de données ?

Vous pouvez utiliser les agents de données pour créer des applications de données conversationnelles idéales pour des cas d'utilisation tels que :

Automatisation du service client : gérez les demandes à fort volume telles que "Où est ma commande ?" ou "Quel est mon solde actuel ?".
Assistants d'achat pour l'e-commerce : aidez les utilisateurs à parcourir de vastes catalogues de produits à l'aide de requêtes en langage naturel, comme "Montre-moi les chaussures de course à moins de 100 €".
Systèmes de réservation : permettent aux utilisateurs de vérifier la disponibilité et de réserver des rendez-vous, des vols ou des services de restauration via des interfaces de chat.
Outils pour les opérations sur le terrain : permettent aux employés mobiles d'interroger les niveaux d'inventaire, la disponibilité des pièces ou les détails des demandes d'intervention en temps réel.

Fonctionnement des agents de données

Pour créer des applications agentiques efficaces, l'agent doit comprendre l'organisation de vos données et votre logique métier. Vous fournissez ces informations sous la forme d'un contexte d'agent.

Vous définissez le contexte de l'agent dans des fichiers contenant des objets JSON pour les modèles et les facettes. Vous créez ces fichiers de contexte à l'aide de la CLI Gemini. Vous importez ensuite le fichier de contexte dans un agent de données que vous créez dans la console Google Cloud. Ce processus permet à l'agent d'apprendre le schéma spécifique de la base de données et la logique métier de l'application.

Le fichier de contexte de l'agent ressemble à ce qui suit :

{
  "templates": [
    {
      "nl_query": "Count prague loan accounts",
      "sql": "SELECT COUNT(T1.account_id) FROM bird_dev_financial.account AS T1 INNER JOIN bird_dev_financial.loan AS T2 ON T1.account_id = T2.account_id INNER JOIN bird_dev_financial.district AS T3 ON T1.district_id = T3.district_id WHERE T3.\"A3\" = \"Prague\"",
      "intent": "How many accounts associated with loans are located in the Prague region?",
      "manifest": "How many accounts associated with loans are located in a given city?",
      "parameterized": {
        "parameterized_intent": "How many accounts associated with loans are located in $1",
        "parameterized_sql": "SELECT COUNT(T1.account_id) FROM bird_dev_financial.account AS T1 INNER JOIN bird_dev_financial.loan AS T2 ON T1.account_id = T2.account_id INNER JOIN bird_dev_financial.district AS T3 ON T1.district_id = T3.district_id WHERE T3.\"A3\" = $1"
      }
    }
  ],
  "fragments": [
    {
      "fragment": "T.\"A11\" BETWEEN 6000 AND 10000",
      "intent": "Average salary between 6000 and 10000",
      "manifest": "Average salary between a given number and a given number",
      "parameterized": {
         "parameterized_intent": "Average salary between $1 and $2",
         "parameterized_fragment": "T.\"A11\" BETWEEN $1 AND $2"
      }
    }
  ]
}

Lorsqu'un utilisateur final pose une question en langage naturel, l'agent s'efforce en priorité de faire correspondre la question aux modèles et aux facettes qui ont été vérifiés par le développeur qui organise le contexte. Une fois que l'agent a identifié une correspondance, il utilise le modèle de requête et les facettes sélectionnés pour synthétiser une requête de base de données. L'agent exécute ensuite cette requête sur la base de données pour renvoyer des résultats précis.

Le point de terminaison QueryData de l'API Conversational Analytics est un outil agentique qui permet l'intégration programmatique à vos applications pour générer des requêtes SQL à partir de questions en langage naturel. Dans une application conversationnelle, le point de terminaison QueryData doit être utilisé dans un framework qui gère l'historique et le contexte de la conversation.

Contexte de l'agent

Le contexte de l'agent se compose d'un ensemble organisé de modèles et de facettes au format JSON qui guident l'agent dans la traduction des questions en langage naturel en requêtes pour une base de données spécifique. La définition du contexte permet de générer des requêtes SQL très précises pour les modèles de requêtes courants.

Pour maximiser la précision, assurez-vous que le contexte de l'agent est exact et couvre de manière exhaustive les requêtes d'application attendues.

Modèles de requêtes

Les modèles de requêtes sont un ensemble organisé de questions représentatives en langage naturel avec les requêtes SQL correspondantes. Elles incluent également des explications pour fournir une justification déclarative de la génération du langage naturel vers SQL.

Un objet de modèle de requête se présente comme suit :

{
  "templates": [
    {
      "nl_query": "Count prague loan accounts",
      "sql": "SELECT COUNT(T1.account_id) FROM bird_dev_financial.account AS T1 INNER JOIN bird_dev_financial.loan AS T2 ON T1.account_id = T2.account_id INNER JOIN bird_dev_financial.district AS T3 ON T1.district_id = T3.district_id WHERE T3.\"A3\" = \"Prague\"",
      "intent": "How many accounts associated with loans are located in the Prague region?",
      "manifest": "How many accounts associated with loans are located in a given city?",
      "parameterized": {
        "parameterized_intent": "How many accounts associated with loans are located in $1",
        "parameterized_sql": "SELECT COUNT(T1.account_id) FROM bird_dev_financial.account AS T1 INNER JOIN bird_dev_financial.loan AS T2 ON T1.account_id = T2.account_id INNER JOIN bird_dev_financial.district AS T3 ON T1.district_id = T3.district_id WHERE T3.\"A3\" = $1"
      }
    }
  ]
},
...

Voici les principaux composants de l'objet JSON du modèle de requête :

nl_query : exemple de requête en langage naturel que l'agent de données traite.
sql : requête SQL pour la requête en langage naturel.
intent : objectif ou but de la requête en langage naturel. Si elle n'est pas définie, cette valeur est définie par défaut sur la requête en langage naturel.
manifest : forme généralisée et générée automatiquement de l'intention.
parameterized_intent : formulaire de l'intention, généré automatiquement et basé sur un modèle, avec des valeurs d'entité remplacées par des paramètres.
parameterized_sql : formulaire de requête SQL basé sur un modèle et généré automatiquement, qui correspond à l'intention paramétrée.

Les facettes de requête sont un ensemble organisé de conditions représentatives en langage naturel avec les prédicats SQL correspondants. Les facettes gèrent le filtrage et les conditions, ce qui permet aux modèles de requête d'effectuer des recherches à facettes.

Un objet de facette de requête (fragment) se présente comme suit :

{
...
"fragments": [
    {
      "fragment": "T.\"A11\" BETWEEN 6000 AND 10000",
      "intent": "Average salary between 6000 and 10000",
      "manifest": "Average salary between a given number and a given number",
      "parameterized": {
         "parameterized_intent": "Average salary between $1 and $2",
         "parameterized_fragment": "T.\"A11\" BETWEEN $1 AND $2"
      }
    }
  ]
}

Voici les principaux composants de l'objet JSON du fragment :

fragment : prédicat SQL.
intent : explication du prédicat SQL.
manifest : forme généralisée et générée automatiquement de l'intention.
parameterized_intent : formulaire de l'intention, généré automatiquement et basé sur un modèle, avec des valeurs d'entité remplacées par des paramètres.
parameterized_fragment : formulaire de fragment généré automatiquement à partir du modèle qui correspond à l'intention paramétrée.

Limites

Les agents de données sont soumis aux limites suivantes :

Le contexte d'agent pour les bases de données n'est compatible qu'avec les modèles et les facettes.
Le contexte de l'agent pour les bases de données n'est utilisé que par le point de terminaison QueryData de l'API Conversational Analytics.

Étapes suivantes

Découvrez comment créer ou supprimer un agent de données dans AlloyDB Studio.

Présentation des agents de données Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.