Prácticas recomendadas para configurar Conversational Analytics en Looker

Conversational Analytics usa Gemini para Google Cloud interpretar preguntas en lenguaje natural, utilizando tu modelo semántico de Looker (LookML), los valores de datos y las configuraciones de agentes de datos como fuente de información. La calidad de sus respuestas está relacionada con la eficacia con la que prepares estos datos de entrada.

En esta guía, se proporcionan estrategias y prácticas recomendadas para que los desarrolladores y administradores de LookML configuren y optimicen Conversational Analytics. Si sigues estas recomendaciones para tu modelo de LookML, las exploraciones y los agentes de datos, puedes aumentar la adopción por parte de los usuarios y asegurarte de que obtengan respuestas precisas, pertinentes y útiles a sus preguntas. En esta guía, se abarcan las prácticas recomendadas relacionadas con Conversational Analytics, siguiendo un flujo lógico que comienza con el desarrollo de una base sólida en el LookML de un modelo, la configuración de exploraciones basadas en este modelo y la creación de agentes de datos que usan estas exploraciones como fuentes de datos.

Prácticas recomendadas de LookML para Conversational Analytics

Conversational Analytics interpreta preguntas en lenguaje natural aprovechando estos datos de entrada principales:

  • El modelo de LookML: El agente recupera el esquema de las exploraciones que están conectadas a él. El esquema incluye campos (dimensiones, mediciones), campos de solo filtro (filtros, parámetros) y sus etiquetas, descripciones y sinónimos correspondientes que se definen en el modelo de LookML que subyace a la exploración de Looker. Para obtener la lista completa de parámetros de LookML que analiza Conversational Analytics, consulta la descripción general de Conversational Analytics.
  • Valores de campo distintos: El agente puede tomar muestras de valores de datos y realizar búsquedas parciales para verificar valores de campo específicos en la base de datos subyacente. Estos métodos permiten que el agente elija los campos correctos, aplique los valores de filtro correctos y determine las categorías y entidades disponibles sobre las que podrían preguntar los usuarios.

La eficacia de Conversational Analytics está directamente relacionada con la calidad y la claridad de estos datos de entrada. En la siguiente tabla, se incluyen formas comunes en las que LookML poco claro o ambiguo puede afectar negativamente a Conversational Analytics, junto con soluciones para reducir la latencia y mejorar el resultado y la experiencia del usuario.

Problema de calidad de LookML Solución para un Conversational Analytics más claro
Falta de claridad y conflictos de nombres: Los campos que no tienen etiquetas claras, tienen definiciones ambiguas o comparten nombres similares en diferentes vistas pueden generar una selección de campos incorrecta. Aplica etiquetas claras y descripciones detalladas:
  • Usa el parámetro label para asignar a los campos nombres intuitivos y aptos para la empresa.
  • Usa el parámetro description para proporcionar contexto fundamental, definiciones en lenguaje natural y terminología específica de la industria. Conversational Analytics usa descripciones para identificar mejor los significados de los campos y asignar términos de usuario.
Sobrecarga de campos: Exponer demasiados campos, como IDs internos, campos duplicados de uniones o cálculos intermedios, desordena las opciones disponibles para Conversational Analytics. Oculta los campos irrelevantes: Asegúrate de que todas las claves primarias, las claves externas y los campos técnicos permanezcan ocultos.

(Opcional) Extiende las exploraciones: Para las exploraciones con muchos campos, considera crear una versión dedicada para Conversational Analytics extendiendo una exploración existente.
Carga de la base de datos para el muestreo y la búsqueda: Recuperar valores de muestra y sugerencias de la base de datos puede ser lento o generar una carga innecesaria, en especial cuando los usuarios hacen referencia a valores de datos específicos en las consultas. Define sugerencias en LookML: Evita las consultas de la base de datos en tiempo real para las sugerencias de campos codificando valores o apuntando a dimensiones más eficientes:
  • Usa el suggestions parámetro para codificar una lista de valores posibles.
  • Usa los parámetros suggest_explore y suggest_dimension para consultar una dimensión alternativa y más eficiente para las sugerencias de filtros.
Carga de la base de datos para las consultas de datos: Las consultas grandes o ineficientes pueden aumentar la latencia y la carga de la base de datos. Optimiza las consultas de datos: Cumple con las prácticas recomendadas generales para optimizar el rendimiento de las consultas, como usar el reconocimiento de agregaciones y la lógica de unión eficiente.
Definiciones de LookML incompletas: Confiar en los campos personalizados o los cálculos basados en tablas a nivel del panel hace que la lógica empresarial fundamental sea inaccesible para Conversational Analytics. Incorpore lógica personalizada: Convierta los campos personalizados o los cálculos basados en tablas importantes y de uso frecuente en dimensiones y mediciones de LookML.
Datos desordenados: Los siguientes tipos de datos incoherentes o mal estructurados dificultan que Conversational Analytics interprete las consultas con precisión.
  • Variaciones de valores: Las convenciones de nomenclatura o el uso de mayúsculas y minúsculas incoherentes (por ejemplo, una combinación de los valores complete, Complete y COMPLETE) pueden generar duplicación de datos o relaciones de datos incorrectas en Conversational Analytics.
  • Tipos de datos incoherentes: Las columnas que deben ser numéricas y que contienen valores de cadena ocasionales obligan a que el tipo de campo sea string, lo que impide las operaciones numéricas.
  • Ambigüedad de la zona horaria: La falta de zonas horarias estandarizadas en los campos de marca de tiempo puede generar un filtrado o una agregación incorrectos.
 Aborda la calidad de los datos: Cuando sea posible, marca los problemas de calidad de los datos (valores, tipos, zonas horarias incoherentes) que identifiques durante la selección de datos. Trabaja con los equipos de ingeniería de datos para limpiar los datos de origen o aplicar transformaciones en la capa de ETL o modelado de datos.

Conclusiones clave de LookML

Ten en cuenta estas conclusiones cuando definas LookML para las exploraciones que se usarán como fuentes de datos para Conversational Analytics:

  • Usa etiquetas claras y precisas: Elige etiquetas para tus datos que reflejen cómo hablan realmente tus usuarios empresariales. Evita las abreviaturas técnicas como "amt_usd_curr" y, en su lugar, usa "Amount (USD)".
  • Habilita la asignación sin problemas: Usa sinónimos y descripciones para ayudar al agente a asignar las preguntas de los usuarios a los campos correctos.
  • Centraliza los cálculos: Define los cálculos de uso frecuente directamente como dimensiones o mediciones de LookML para garantizar una única fuente de información y reducir la latencia.
  • Optimiza el contexto: Oculta los campos técnicos o solo internos en LookML (como las claves externas o los IDs sin procesar) para garantizar que solo los campos necesarios para responder preguntas empresariales se muestren en Conversational Analytics. Enfocarse solo en los campos pertinentes reduce el ruido y mejora la precisión de la selección de campos.
  • Optimiza los datos de muestra y las consultas de búsqueda parcial: Define valores codificados en el parámetro suggestions o usa suggest_dimension y suggest_explore para realizar consultas de la base de datos más eficientes.
  • Optimiza las consultas de datos: Cumple con las prácticas recomendadas generales de Looker para optimizar el rendimiento de las consultas, como usar el reconocimiento de agregaciones y la lógica de unión eficiente.

Para obtener más prácticas recomendadas para escribir LookML limpio y eficiente, consulta la siguiente documentación:

Prácticas recomendadas para configurar una exploración para usarla con Conversational Analytics

Para ayudar a Conversational Analytics a proporcionar las respuestas más útiles, considera seguir estas prácticas recomendadas cuando definas tus exploraciones para usarlas como fuente de datos para Conversational Analytics:

  • En el LookML subyacente de tu exploración, define solo los campos que sean útiles para el análisis de los usuarios finales.
    • Asigna a cada campo un nombre y una descripción claros y concisos.
    • Incluye valores de muestra cuando sea pertinente. Los valores de muestra son especialmente útiles para los campos de tipo cadena.
  • Considera seleccionar exploraciones específicas del agente de datos que reutilicen contenido.
    • Usa extends para aprovechar el LookML existente y seleccionar los campos que necesita el agente. En la actividad del sistema, los usuarios pueden ver qué campos se usan en las consultas generadas por los agentes y decidir qué campos excluir.
    • Usa refinamientos de LookML a nivel del campo para crear descripciones diseñadas específicamente para los agentes: "Usa el campo Orders cuando los usuarios hagan referencia a Sales".

Prácticas recomendadas para crear agentes de datos

Después de establecer una base sólida con las prácticas recomendadas de LookML y las exploraciones bien configuradas, puedes crear agentes de datos para proporcionar experiencias conversacionales personalizadas para casos de uso o grupos de usuarios específicos. Los agentes de datos se conectan a hasta cinco exploraciones y usan instrucciones en lenguaje natural para proporcionar contexto, definir terminología y establecer lineamientos de comportamiento.

Seguir las prácticas recomendadas cuando se crean agentes y se escriben instrucciones es fundamental para adaptar las respuestas del agente a las necesidades específicas de los usuarios y mejorar la precisión general. Estas prácticas recomendadas incluyen diseñar agentes especializados para dominios específicos y escribir instrucciones claras y eficaces.

Crea agentes especializados

Si bien puede ser tentador crear un agente de datos global para manejar todas las preguntas empresariales, los agentes funcionan mejor cuando están especializados en un dominio específico, como ventas, marketing o estadísticas de productos. Se pueden dar instrucciones más precisas a un agente que se enfoca en una o algunas exploraciones estrechamente relacionadas, lo que reduce la ambigüedad y mejora la precisión de la respuesta.

Cuando diseñes tus agentes, evita crear un solo agente para manejar todos los modelos de datos no relacionados. En su lugar, crea agentes enfocados para distintas áreas empresariales y conéctalos solo a exploraciones estrechamente relacionadas. Por ejemplo, en lugar de un agente para todos los datos de la empresa, crea un "Agente de ingresos" enfocado específicamente en las exploraciones Orders y Transactions.

Escribe instrucciones eficaces para el agente

Las instrucciones del agente son tu herramienta principal para personalizar el comportamiento de un agente de datos y agregarle la lógica empresarial y la terminología únicas de tu organización. Piensa en las instrucciones como una forma de capacitar a tu agente sobre cómo interpretar las preguntas de los usuarios, manejar la ambigüedad y responder de la manera más útil para ellos. Las instrucciones bien escritas son clave para generar respuestas precisas, pertinentes y confiables.

Ingresa las instrucciones del agente en el campo Instructions cuando crees tu agente de datos. Para obtener más información sobre la creación de agentes, consulta la página de documentación Crea y administra agentes de datos de exploración.

Para escribir instrucciones eficaces, sigue estas prácticas recomendadas:

  • Define el contexto empresarial y el comportamiento predeterminado: Capacita al agente sobre la lógica y la terminología únicas de tu organización. Usa instrucciones para definir acrónimos (por ejemplo, "LY significa año pasado"), explicar la lógica de filtrado común o establecer comportamientos predeterminados para la ambigüedad (por ejemplo, "Si no se proporciona date_created, filtra los últimos 6 meses").
  • Usa la sintaxis de LookML y de filtros: Cuando hagas referencia a campos o apliques filtros en las instrucciones, usa la sintaxis de LookML (por ejemplo, events.date_created) y la sintaxis de filtros (por ejemplo, "last 6 months"). Esto garantiza que el agente comprenda qué campos o filtros aplicar. Por ejemplo: "Cuando un usuario pregunte sobre la 'región', usa el campo account_holder.geo_region".
  • Sé conciso: Escribe con claridad y evita las palabras o repeticiones innecesarias en las instrucciones.
  • Evita la redundancia: No dupliques la información que pertenece a LookML, como las descripciones de campos o los sinónimos. Para obtener más información sobre cuándo definir el contexto en LookML en comparación con las instrucciones del agente, consulta Cuándo agregar contexto a LookML en comparación con Conversational Analytics. También evita explicar conceptos básicos que el agente ya comprende, como la diferencia entre una dimensión y una medición, o cómo realizar el filtrado de fechas básico.

Limitaciones de las instrucciones del agente

Ten en cuenta las siguientes limitaciones de Conversational Analytics cuando escribas las instrucciones del agente:

  • Conversational Analytics no admite la generación de consultas que contengan el pivots parámetro. Si bien Conversational Analytics puede mostrar datos para varias dimensiones a la vez, no puede convertirlos en columnas separadas de la misma manera que la IU de exploración de Looker. En cambio, muestra los datos en un formato "largo" o "aplanado", por lo que los datos se agrupan horizontalmente en lugar de verticalmente.
  • A diferencia de LookML, que está regulado, las instrucciones suelen ser texto de formato libre y pueden quedar "obsoletas" a medida que el modelo de datos subyacente evoluciona con el tiempo. Para evitar instrucciones obsoletas con los agentes de datos de exploración, usa consultas verificadas para definir pares de preguntas en lenguaje natural y sus consultas de exploración correspondientes.

Ejemplo de instrucciones del agente

Estas son algunas instrucciones de muestra para un agente de datos que está conectado a las exploraciones de Looker llamadas Order Items y Products:

# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.

# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
  EOP: End of Period. This is the last day of the period.
  LY: Last Year.
  Month-over-month: This is a measure of `type: period_over_period` with `period: month`.

# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
  Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
  Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.

# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.

Cuándo agregar contexto a LookML en comparación con Conversational Analytics

En Conversational Analytics, puedes agregar contexto a LookML o dentro de las instrucciones del agente. Cuando decidas dónde agregar contexto, aplica las siguientes indicaciones:

  • El contexto que se debe aplicar a todos los usuarios de una exploración se debe agregar directamente a tu modelo de LookML, ya que las exploraciones de Looker se pueden usar en varios lugares, incluidos los paneles y Conversational Analytics. Si el contexto solo se debe aplicar a ciertos usuarios, considera usar funciones de LookML, como los atributos de usuario, para crear experiencias personalizadas.
  • Prioriza LookML para los metadatos específicos del campo y los requisitos estrictos. Coloca los metadatos específicos del campo, incluidos los sinónimos y las descripciones, directamente en LookML en lugar de en las instrucciones del agente. Lo ideal es que los requisitos para elementos como los valores de filtro predeterminados o los campos ocultos se manejen en LookML para garantizar que se respeten.
  • No dupliques la información que el agente ya conoce, como cómo crear una consulta de Looker, una explicación de las dimensiones o mediciones, sus exploraciones accesibles o cómo realizar el filtrado de fechas básico. Del mismo modo, no definas el mismo término en LookML y en las instrucciones del agente.

El contexto del agente debe ser cualitativo y enfocarse en el usuario, y puede haber muchos agentes que atiendan a diferentes usuarios desde una exploración. LookML es útil para definir qué es un campo, pero, por lo general, no puede definir la estrategia empresarial ni los cálculos predictivos. Estos son ejemplos de contexto que se deben incluir en las instrucciones del agente, pero no en LookML:

  • ¿Quién es el usuario que interactúa con el agente? ¿Qué puestos tienen estas personas? ¿Son internas o externas a la empresa? ¿Cuál es su experiencia previa en estadísticas?
  • ¿Cuál es el objetivo del usuario? ¿Qué tipo de decisión busca tomar al final de la conversación?
  • ¿Qué tipos de preguntas hará este usuario?
  • ¿Qué campos son más relevantes para este usuario? Por ejemplo, ¿a qué campos debe acceder este usuario?, ¿se deben aplicar siempre ciertos filtros? o ¿se deben priorizar algunos campos para este usuario?