Présentation de QueryData

QueryData vous permet d'interagir avec les données de votre base de données à l'aide d'un langage conversationnel et de créer des agents de données. QueryData écrit des requêtes pour votre base de données à l'aide d'ensembles de contexte, qui sont des collections de code contenant des informations uniques sur votre base de données. Ce contexte permet à QueryData de traduire des questions en langage naturel en requêtes précises pour vos cas d'utilisation cibles.

Quand utiliser QueryData

QueryData est idéal pour les applications telles que :

  • Automatisation du service client : gérez un volume élevé de demandes telles que "Où en est ma commande ?" ou "Quel est mon solde actuel ?".
  • Assistants d'achat pour le e-commerce : aidez les utilisateurs à parcourir de grands catalogues de produits avec des requêtes en langage naturel telles que « Montre-moi des chaussures de course à moins de 100 € ».
  • Outils d'opérations sur le terrain : permettez aux employés mobiles d'interroger en temps réel les niveaux de stock , la disponibilité des pièces ou les détails des tickets d'assistance.

Fonctionnement de QueryData

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

Vous définissez le contexte dans des fichiers contenant des objets JSON pour chaque type de contexte. Vous créez ces fichiers de contexte à l'aide de Gemini CLI. Vous importez ensuite le fichier de contexte dans un ensemble de contexte que vous créez dans la Google Cloud console. Ce processus permet à QueryData 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 se présente comme suit :

Le fichier de contexte de l'agent 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"
      }
    }
  ],
  "facets": [
    {
      "sql_snippet": "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_sql_snippet": "T.\"A11\" BETWEEN $1 AND $2"
      }
    }
  ]
}

Lorsqu'un utilisateur final pose une question en langage naturel, QueryData donne la priorité à la mise en correspondance de la question avec les modèles et les facettes qui ont été audités par le développeur qui gère le contexte. Une fois que QueryData 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. La logique de l'ensemble de contexte exécute ensuite cette requête sur la base de données pour renvoyer des résultats précis.

Il est recommandé de définir des recherches de valeurs dans votre contexte. Les recherches de valeurs permettent à l'agent de mapper des expressions de valeur à des valeurs spécifiques stockées dans les colonnes de votre base de données. Cela ancre le LLM dans vos données réelles, ce qui l'aide à résoudre les ambiguïtés, par exemple si un terme fait référence à un nom de District ou à une City.

Si l'agent ne parvient pas à trouver de modèle correspondant, il utilise des recherches de valeurs pour mapper des expressions en langage naturel à des valeurs spécifiques stockées dans les colonnes de votre base de données. Cela ancre le LLM dans vos données réelles, ce qui l'aide à résoudre les ambiguïtés, par exemple si un terme fait référence à un District, un Name ou une City.

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

Étape suivante