Prácticas recomendadas para configurar Conversational Analytics en Looker

Conversational Analytics usa Gemini for Google Cloud para interpretar preguntas en lenguaje natural, y utiliza tu modelo semántico (LookML), los valores de datos y las configuraciones del agente de datos de Looker como fuente de verdad. La calidad de sus respuestas está vinculada a la eficacia con la que prepares estas entradas.

En esta guía, se proporcionan estrategias y prácticas recomendadas para que los administradores y desarrolladores de LookML configuren y optimicen Conversational Analytics. Si sigues estas recomendaciones para tu modelo de LookML, tus Explorar y tus 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 abordan 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 las preguntas en lenguaje natural aprovechando estas entradas 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 correspondientes etiquetas, descripciones y sinónimos que se definen en el modelo de LookML que subyace en el Explorar de Looker. Para obtener la lista completa de los 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 los valores de los datos y realizar búsquedas aproximadas 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 adecuados y determine las categorías y entidades disponibles sobre las que los usuarios podrían hacer preguntas.

La eficacia de las estadísticas conversacionales está directamente relacionada con la calidad y la claridad de estas entradas. En la siguiente tabla, se incluyen formas comunes en las que el LookML poco claro o ambiguo puede afectar negativamente las estadísticas conversacionales, 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 incorrecta de campos. Aplica etiquetas claras y descripciones detalladas:
  • Usa el parámetro label para asignarles a los campos nombres intuitivos y adecuados para la empresa.
  • Usa el parámetro description para proporcionar contexto importante, 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 los términos de los usuarios.
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 búsquedas. Define sugerencias en LookML: Evita las consultas de bases de datos en tiempo real para las sugerencias de campos codificando valores de forma rígida o apuntando a dimensiones más eficientes:
  • Usa el parámetro suggestions 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: Sigue las prácticas recomendadas generales para optimizar el rendimiento de las consultas, como usar la conciencia de agregación y una lógica de unión eficiente.
Definiciones de LookML incompletas: Si dependes de los campos personalizados o los cálculos de tablas a nivel del panel, la lógica empresarial crítica no estará disponible para Conversational Analytics. Incorpora lógica personalizada: Convierte los campos personalizados o los cálculos basados en tablas importantes y de uso frecuente en dimensiones y medidas de LookML.
Datos desordenados: Los siguientes tipos de datos incoherentes o mal estructurados dificultan que Conversational Analytics interprete las búsquedas con precisión.
  • Variaciones de valores: Las convenciones de nomenclatura o el uso de mayúsculas inconsistentes (por ejemplo, una combinación de los valores complete, Complete y COMPLETE) pueden generar duplicación de datos o relaciones de datos incorrectas en Analytics Conversacional.
  • Tipos de datos incoherentes: Las columnas que deben ser numéricas y que contienen valores de cadena ocasionales fuerzan 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 marcas de tiempo puede generar filtrado o agregación incorrectos.
 Calidad de los datos de la dirección: Cuando sea posible, marca los problemas de calidad de los datos (valores, tipos y zonas horarias incoherentes) que identifiques durante la selección de datos. Trabajar 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 estos puntos clave 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 los usuarios empresariales. Evita las abreviaturas técnicas, como "amt_usd_curr", y, en su lugar, usa "Amount (USD)".
  • Habilita la asignación fluida: 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 que se usan con frecuencia directamente como dimensiones o medidas de LookML para garantizar una sola fuente de verdad y reducir la latencia.
  • Simplifica 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 comerciales 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 búsquedas aproximadas: Define valores codificados de forma rígida en el parámetro suggestions o usa suggest_dimension y suggest_explore para realizar consultas de bases 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 una lógica de unión eficiente.

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

Prácticas recomendadas para configurar un Explorar para usarlo con Conversational Analytics

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

  • En el LookML subyacente de tu Explorar, 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 crear LookML existente y seleccionar los campos que necesita el agente. En 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 Pedidos cuando los usuarios se refieran a Ventas".

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 un máximo de cinco Exploraciones y usan instrucciones en lenguaje natural para proporcionar contexto, definir terminología y establecer pautas 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 del usuario 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 responder todas las preguntas comerciales, los agentes funcionan mejor cuando se especializan en un dominio específico, como las ventas, el marketing o el análisis de productos. Un agente que se enfoca en una o algunas Exploraciones estrechamente relacionadas puede recibir instrucciones más precisas, lo que reduce la ambigüedad y mejora la exactitud de la respuesta.

Cuando diseñes tus agentes, evita crear uno solo para controlar todos los modelos de datos no relacionados. En su lugar, crea agentes enfocados en áreas comerciales distintas y conéctalos solo a las exploraciones estrechamente relacionadas. Por ejemplo, en lugar de tener un agente para todos los datos de la empresa, crea un "Agente de ingresos" que se enfoque específicamente en los Exploradores de 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 guiar 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 Instrucciones 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 Explorar datos.

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

  • Define el contexto comercial y el comportamiento predeterminado: Entrena al agente sobre la lógica y la terminología únicas de tu organización. Usa instrucciones para definir acrónimos (por ejemplo, "AA significa Año Anterior"), explicar la lógica de filtrado común o establecer comportamientos predeterminados para la ambigüedad (por ejemplo, "Si no se proporciona ningún date_created, filtra los últimos 6 meses").
  • Usa LookML y la sintaxis de filtros: Cuando te refieras 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 debe aplicar. Por ejemplo: "Cuando un usuario pregunte sobre la "región", usa el campo account_holder.geo_region".
  • Usa consultas de referencia para ejemplos complejos: Para las preguntas o consultas comunes que involucran una lógica empresarial compleja, proporciona golden queries, es decir, pares de preguntas en lenguaje natural y sus correspondientes consultas de Looker verificadas. Las preguntas de referencia pueden ayudar al agente a aprender patrones específicos. Enfócate en las preguntas que aclaran la terminología compleja o las combinaciones de filtros comunes. Las preguntas de referencia deben proporcionarse en una representación de consulta de LookML específica, en lugar de en SQL sin procesar o URLs de Explorar estándar.
  • Sé conciso: Escribe con claridad y evita las palabras innecesarias o la repetición en las instrucciones.
  • Evita la redundancia: No dupliques la información que pertenece a LookML, como las descripciones de los 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 métrica, o cómo realizar un filtrado básico por fecha.

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 parámetro pivots. Si bien Conversational Analytics puede devolver datos para varias dimensiones a la vez, no puede pivotarlos en columnas separadas como lo hace la IU de Explorar de Looker. En cambio, devuelve los datos en un formato "largo" o "aplanado", por lo que los datos se agrupan horizontalmente en lugar de verticalmente.

  • Conversational Analytics no puede reutilizar los campos personalizados que se definen en el contenido existente de Looker (por ejemplo, cuando usas el LookML generado a partir de una Exploración que contiene un campo personalizado para crear una consulta de referencia) ni generar campos personalizados completamente nuevos dentro de una consulta nueva. En cambio, usa los campos existentes de LookML o Python para crear cálculos personalizados en los resultados de los datos.

  • A diferencia de LookML, que está controlado, las instrucciones suelen ser texto de formato libre y pueden quedar "desactualizadas" a medida que el modelo de datos subyacente evoluciona con el tiempo.

Ejemplo de instrucciones del agente

Estas son algunas instrucciones de ejemplo para un agente de datos 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`.

# Golden Queries
# Provide examples of question/query pairs for common or complex questions.
Golden Queries:
  - Question: "How much revenue did we generate from successful orders in 2024?"
    Looker query:
      model: thelook_ecommerce
      explore: order_items
      fields: [order_items.total_sales]
      filters: [{field: order_items.status, value: "Complete"}, {field: order_items.created_year, value: "2024"}]

# 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 lugar de Conversational Analytics

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

  • 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 debe aplicarse a ciertos usuarios, considera usar funciones de LookML, como los atributos del 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. Los requisitos para aspectos como los valores de filtro predeterminados o los campos ocultos deberían controlarse de forma ideal 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 las medidas, sus Exploraciones accesibles o cómo realizar un filtrado básico por fecha. 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 centrarse en el usuario, y puede haber muchos agentes que atiendan a diferentes usuarios desde una sola exploración. LookML es útil para definir qué es un campo, pero, por lo general, no puede definir la estrategia comercial ni los cálculos predictivos. A continuación, se muestran 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 internos o externos a la empresa? ¿Cuál es su experiencia previa en análisis?
  • ¿Cuál es el objetivo del usuario? ¿Qué tipo de decisión quieren 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 debería tener acceso este usuario?, ¿se deberían aplicar siempre ciertos filtros?, ¿se deberían priorizar algunos campos para este usuario?