Mejores prácticas para mejorar la generación de consultas de agentes de datos

Un agente de datos genera mejores consultas cuando tiene un contexto enfocado y preciso sobre los datos que puede utilizar. Los nombres de objetos y los metadatos de esquemas proporcionan un punto de partida, pero pueden no explicar el significado empresarial, los valores esperados, las relaciones o la lógica de consulta necesaria para responder a una pregunta.

Utiliza la configuración que mejor se ajuste al contexto que necesitas proporcionar:

Objetivo Configuración
Limita qué datos puede consultar el agente Selección de esquemas
Explica qué significa una tabla, columna u otro elemento de esquema individual Descripciones de objetos de esquema
Define reglas de negocio, relaciones y directrices que se apliquen a todos los objetos Instrucciones del origen de datos
Demuestra el patrón de consulta para una pregunta Consultas de ejemplo

Para una visión general de estos ajustes, véase Configuraciones de agentes de datos.

Utiliza nombres claros de esquemas

Utiliza nombres descriptivos para fuentes de datos, tablas y columnas cuando controles el esquema. Nombres como , , y product_unit_price dan al agente señales más útiles que nombres como Table1, date1, y value. order_submission_dateCustomerOrders

No te fíes solo del nombre. Incluso un nombre técnico claro puede no comunicar el significado comercial del objeto, su nivel de detalle, las unidades o los valores válidos. Utiliza descripciones e instrucciones de fuentes de datos para proporcionar ese contexto.

Limitar el esquema seleccionado

Selecciona solo las tablas, columnas, vistas y funciones necesarias para las preguntas que el agente de datos debe responder. Los objetos irrelevantes aumentan la ambigüedad y proporcionan a la herramienta de generación de consultas más caminos posibles para considerar.

Por ejemplo, si los usuarios preguntan sobre los pedidos actuales de los clientes, no incluyan tablas de preparación archivadas ni tablas de finanzas no relacionadas. Cuando dos objetos seleccionados contienen datos similares, explica cuál es autoritativo y cuándo usar cada uno.

Describe objetos de esquema (Vista previa)

Para esquemas SQL grandes o ambiguos, utiliza descripciones de objetos de esquema para explicar qué representan tablas, columnas y otros elementos del esquema individuales. Las descripciones de objetos de esquema solo están disponibles cuando el agente de datos utiliza el tiempo de ejecución de previsualización.

Las descripciones son útiles cuando:

  • Los nombres de los objetos son abreviados, genéricos o similares entre sí.
  • El grano o la función comercial de una mesa no se refleja en su nombre.
  • Una columna contiene códigos, banderas, unidades o valores de categoría que requieren interpretación.
  • Una columna de fecha representa un evento empresarial específico, como la presentación de un pedido en lugar de su cumplimiento.
  • El esquema es demasiado grande para explicar claramente cada objeto en las instrucciones de la fuente de datos.

Describe tanto el significado como los valores esperados cuando esa información afecta a la generación de consultas. Por ejemplo:

Objeto de esquema Descripción efectiva
AdoptionEvents Contiene una fila por cada adopción completada de mascota. Úsalo AdoptionDate para la fecha de finalización.
StatusCode Estado del ciclo de vida de la adopción. Los valores esperados son AP (aprobado), PD (pendiente) y CN (cancelado).
Weight Peso actual del animal en kilogramos. Nulo significa que no hay medición disponible.

Prioriza las descripciones de objetos que sean difíciles de inferir. Evita repetir un nombre obvio sin añadir contexto empresarial.

Usar instrucciones de fuente de datos para reglas entre objetos

Las instrucciones de fuente de datos proporcionan orientación para generar consultas para una fuente de datos específica. Úsalos para obtener contexto que abarque múltiples objetos de esquema o defina cómo debe construirse una consulta, incluyendo:

  • Tablas de referencia sobre un tema.
  • Claves de combinación y rutas de combinación necesarias.
  • Reglas de granularidad de la tabla y eliminación de duplicados.
  • Filtros por defecto, como usar solo registros actuales o activos.
  • Lógica de fechas, calendarios fiscales y supuestos de zonas horarias.
  • Cálculos requeridos o columnas de salida.

Escribe instrucciones directas que indiquen qué debe hacer el agente. Por ejemplo, usa "Une EmployeeStatusFact con EmployeeDim en EmployeeID" en lugar de "Evita unir incorrectamente tablas de empleados".

Mantenga las instrucciones centradas. Poner definiciones específicas de objeto en las descripciones de objetos del esquema en lugar de usar el espacio limitado de instrucciones como glosario para cada tabla y columna.

Definir términos empresariales y valores esperados

Define terminología que los usuarios puedan incluir en sus preguntas pero que no se corresponda directamente con el esquema. Ejemplos incluyen siglas como "MAU", significados específicos de la organización de "cliente activo" y distinciones como año fiscal frente a año natural.

También documenta los valores que el agente necesita para construir correctamente los filtros:

  • Ya sea que una columna de estados use "CA" o "California".
  • Si un valor booleano se almacena como 1 y 0, Y y N, o texto.
  • Ya sea que los valores de la moneda se almacenen en dólares o en céntimos.
  • ¿Qué valores de estado representan registros completados, cancelados o activos?
  • Ya sea nulo, cero o una fecha centinela tiene un significado especial.

Coloca una definición en la descripción del objeto de esquema cuando se aplique a un objeto. Colócalo en instrucciones de fuente de datos cuando se aplique en toda la fuente de datos o afecte a la lógica de consultas multiobjeto.

Explica las relaciones y la granularidad de la tabla

Las uniones precisas requieren algo más que hacer coincidir los nombres de las columnas. Identifica el nivel de detalle de las tablas importantes, las rutas de relación válidas y las claves que no son evidentes en los metadatos.

Por ejemplo, explica si una tabla de ventas contiene una fila por pedido, línea de pedido o total diario del producto. Si unir dos tablas de hechos duplicaría filas, instruye al agente para que agregue cada tabla antes de unirse o que utilice la tabla de dimensiones correspondiente.

Incluye orientación sobre relaciones como:

- Join `OrderItems` to `Orders` on `OrderID`.
- Join `Orders` to `Customers` on `CustomerID`.
- Aggregate `OrderItems` to one row per `OrderID` before joining to order-level payment totals.

Utiliza consultas de ejemplo para lógica compleja

Utiliza consultas de ejemplo para mostrar que la consulta es más clara que describir la lógica en prosa. Un buen ejemplo empareja una pregunta representativa en lenguaje natural con una consulta válida que demuestra el patrón esperado.

Prioriza ejemplos que demuestren:

  • Uniones de varias tablas o preagregación obligatoria.
  • Cálculos específicos de negocio.
  • Fechas relativas, periodos fiscales o lógica de instantáneas.
  • Filtros que asignan la terminología del usuario a valores almacenados.
  • Clasificación, funciones ventana u otros patrones complejos de consulta.

Mantén cada ejemplo centrado en un patrón reutilizable. Evita ejemplos superpuestos o contradictorios y verifica que todos los ejemplos coincidan con el esquema actual.

Prueba y refina el contexto

Pruebe preguntas representativas, inspeccione la consulta generada e identifique qué contexto faltaba o se malinterpretó. Actualiza la configuración más cercana al problema:

  • Elimina objetos irrelevantes o añade los que faltan en la selección de esquemas.
  • Aclarar el significado o los valores esperados de un objeto en su descripción del esquema.
  • Añadir lógica de negocio entre distintos objetos o lógica de combinación a las instrucciones de la fuente de datos.
  • Añade una consulta de ejemplo cuando el agente necesite aprender un patrón de consulta específico.

Repite este proceso a medida que evolucionan el esquema y las preguntas de usuario. Para un flujo de trabajo de pruebas estructurado, véase Desarrollar un agente de datos utilizando un proceso iterativo.

Pasos siguientes