Descripción general de los conjuntos de contexto

Un conjunto de información contextual es una colección de información específica de la base de datos que permite que herramientas como QueryData generen consultas con alta precisión. Los conjuntos de contexto pueden incluir plantillas, facetas y búsquedas de valores que ayudan a QueryData a comprender el esquema de tu base de datos y la lógica empresarial de tus aplicaciones.

Se admiten las siguientes bases de datos:

  • AlloyDB para PostgreSQL
  • Cloud SQL para MySQL
  • Cloud SQL para PostgreSQL
  • Spanner
  • Firestore compatible con MongoDB
  • Bigtable

Qué son los conjuntos de información contextual

Para crear aplicaciones de agentes eficaces, las herramientas como QueryData deben comprender la organización de tus datos y la lógica empresarial. Esta información se proporciona en forma de un conjunto de contexto.

El contexto se define en archivos que contienen objetos JSON para cada tipo de contexto. Puedes crear estos archivos de contexto con la ayuda del agente de ingeniería de contexto. Luego, subes el archivo de contexto a un conjunto de contexto que creas en la consola de Google Cloud. Este proceso permite que herramientas como QueryData aprendan el esquema específico de la base de datos y la lógica empresarial de la aplicación.

El archivo de contexto es similar al siguiente:

{
  "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": "employee.\"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": "employee.\"A11\" BETWEEN $1 AND $2"
      }
    }
  ],
  "value_searches": [
    {
      "query": "SELECT $value as value, 'accounts.account_type' as columns, 'Account Type' as concept_type, 0 as distance, '{}'::text as context FROM \"accounts\" T WHERE T.\"account_type\" = $value",
      "concept_type": "Account Type",
      "description": "Exact match for account types"
    }
   ]
}

Formato de archivo del conjunto de información contextual

Un archivo de conjunto de información contextual consta de un conjunto seleccionado de plantillas, facetas y búsquedas de valores en formato JSON que guían a herramientas como QueryData en la traducción de preguntas en lenguaje natural a consultas para una base de datos específica. Definir el contexto garantiza la generación de SQL de alta precisión para los patrones de consulta comunes.

Para maximizar la precisión, asegúrate de que el conjunto de contexto sea preciso y completo en su cobertura de las consultas esperadas de la aplicación.

Los conjuntos de contexto se pueden crear en las regiones us-central1, us-east1, europe-west4 y asia-southeast1. Debes seleccionar una región cuando crees el primer conjunto de contexto en un proyecto. Los conjuntos de contexto posteriores usan la misma región.

Plantillas de consulta

Las plantillas de consultas son un conjunto seleccionado de preguntas representativas en lenguaje natural con consultas en SQL correspondientes. También incluyen explicaciones para proporcionar una justificación declarativa de la generación de lenguaje natural a SQL.

Un objeto de plantilla de consulta se ve de la siguiente manera:

{
  "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"
      }
    }
  ],
  ...
}

Los componentes principales del objeto JSON de la plantilla de consulta son los siguientes:

  • nl_query: Es un ejemplo de una consulta de lenguaje natural que controlan herramientas como QueryData.
  • sql: Es la consulta en SQL para la consulta en lenguaje natural.
  • intent: Es el objetivo o propósito de la consulta en lenguaje natural. Si no se establece, este valor se establece de forma predeterminada en la consulta de lenguaje natural.
  • manifest: Es una forma generalizada y generada automáticamente del intent.
  • parameterized_intent: Es una forma de intent generada de forma automática con plantillas, en la que los valores de las entidades se reemplazan por parámetros.
  • parameterized_sql: Es un formato de plantilla generado de forma automática de la consulta en SQL que corresponde al intent parametrizado.

Facetas de consulta

Las facetas de consulta son un conjunto seleccionado de condiciones de lenguaje natural representativas con predicados de SQL correspondientes. Las facetas administran el filtrado y las condiciones, lo que permite que las plantillas de consulta realicen búsquedas por facetas.

Un objeto de faceta de consulta es similar al siguiente:

{
...
"facets": [
    {
      "sql_snippet": "employee.\"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": "employee.\"A11\" BETWEEN $1 AND $2"
      }
    }
  ]
}

Los componentes principales del objeto JSON de faceta son los siguientes:

  • sql_snippet: Es un fragmento de SQL. Para evitar ambigüedades, califica los nombres de las columnas con los nombres de las tablas (por ejemplo, table_name.column_name).
  • intent: Es una explicación del predicado de SQL.
  • manifest: Es una forma generalizada y generada automáticamente del intent.
  • parameterized_intent: Es una forma de intent generada de forma automática con plantillas, en la que los valores de las entidades se reemplazan por parámetros.
  • parameterized_sql_snippet: Es una forma de plantilla generado de forma automática del sql_snippet que corresponde al intent parametrizado.

Búsquedas de valor

Las consultas de búsqueda de valores son consultas definidas por el desarrollador que usan funciones de coincidencia para encontrar valores y su contexto dentro de una base de datos. La vinculación de valores usa los resultados de estas consultas para identificar qué tablas y columnas contienen un valor coincidente, comprender el tipo de concepto del valor y corregir errores ortográficos.

La API de QueryData usa la vinculación de valores para convertir el lenguaje natural en SQL con mayor precisión. Con las consultas de búsqueda de valores, la API puede corregir errores ortográficos y resolver los tipos de valores según los valores de la base de datos, lo que mejora la precisión de las conversiones.

La vinculación de valores mejora la precisión de la conversión de lenguaje natural a SQL. Por ejemplo, si un usuario pregunta "¿Hay vuelos desde Heathrow?", la base de datos podría almacenar el nombre del aeropuerto como "London Heathrow". Sin la vinculación de valores, el SQL generado podría filtrar por WHERE name = 'Heathrow' y no mostrar resultados. Las consultas de búsqueda de valores guían al agente para que asigne "Heathrow" al valor correcto de la base de datos "London Heathrow" y su ubicación de esquema (airports.name), lo que garantiza que el SQL generado sea preciso.

A continuación, se muestra un ejemplo de consulta de búsqueda de valores:

{
  ...
  "value_searches": [
    {
      "query": "SELECT $value as value, 'airports.iata' as columns, 'Airport IATA Code' as concept_type, 0 as distance, '{}'::text as context FROM \"airports\" T WHERE T.\"iata\" = $value",
      "concept_type": "Airport IATA Code",
      "description": "Exact match (Standard SQL) for 3-letter airport codes"
    },
    {
      "query": "WITH TrigramMetrics AS ( SELECT T.\"name\" AS original_value, (T.\"name\" <-> $value::text) AS normalized_dist FROM \"airports\" T WHERE T.\"name\" % $value::text ) SELECT original_value AS value, 'airports.name' AS columns, 'Airport Name' AS concept_type, normalized_dist AS distance, '{}'::text AS context FROM TrigramMetrics",
      "concept_type": "Airport Name",
      "description": "Fuzzy match using standard trigram for partial airport names"
    },
    {
      "query": "WITH SemanticMetrics AS ( SELECT T.\"city\" AS original_value, ( (google_ml.embedding('gemini-embedding-001', $value)::vector <=> google_ml.embedding('gemini-embedding-001', T.\"city\")::vector) / 2.0 ) AS normalized_dist FROM \"airports\" T WHERE T.\"city\" IS NOT NULL ) SELECT original_value AS value, 'airports.city' AS columns, 'Airport City' AS concept_type, normalized_dist AS distance, '{}'::text AS context FROM SemanticMetrics",
      "concept_type": "Airport City",
      "description": "Semantic search on string values for airport city names"
    }
  ]
}

Los componentes principales del objeto JSON de búsqueda de valores son los siguientes:

  • query: Es una instrucción de SQL parametrizada que define la lógica para hacer coincidir una frase de valor con los valores almacenados en una base de datos. Por lo general, el conjunto de resultados proyecta el valor coincidente, la ubicación del esquema, el tipo de concepto y una métrica de distancia normalizada (entre 0 y 1).
  • concept_type: Es una etiqueta semántica asignada al valor, por ejemplo, district o loan_status. Esta etiqueta ayuda a vincular valores y, con el tiempo, a que las herramientas como la API de QueryData comprendan el rol de la frase de valor en el esquema. También ayuda a producir una instrucción de SQL que se orienta al concepto del valor, así como a la tabla y la columna en las que aparece la frase del valor.
  • description: Es una descripción de la lógica de búsqueda.

Limitaciones

Los conjuntos de contexto tienen las siguientes limitaciones:

  • Los conjuntos de contexto para bases de datos solo admiten plantillas, facetas y búsquedas de valores.
  • Los conjuntos de contexto para bases de datos solo los usa el extremo QueryData en la API de Conversational Analytics.

¿Qué sigue?