Prácticas recomendadas para configurar Conversational Analytics en Looker

Analíticas conversacionales permite a los usuarios consultar datos modelados en LookML haciendo preguntas en lenguaje natural en una instancia de Looker. Los usuarios pueden consultar los datos de las siguientes formas:

En esta guía se ofrecen estrategias y prácticas recomendadas para ayudar a los desarrolladores de LookML a configurar y optimizar Conversational Analytics. En esta guía se tratan los siguientes temas:

Si preparas tu modelo de LookML y Análisis conversacional, puedes aumentar la adopción por parte de los usuarios y asegurarte de que obtengan respuestas precisas y útiles a sus preguntas.

Consulta cómo y cuándo usa tus datos Gemini Google Cloud .

Prácticas recomendadas de LookML para Conversational Analytics

Analíticas conversacionales interpreta las preguntas formuladas en lenguaje natural mediante dos entradas principales:

  1. El modelo de LookML: Conversational Analytics analiza la estructura, los campos (dimensiones y medidas), las etiquetas, las descripciones y los sinónimos que se definen en el modelo de LookML subyacente de la Exploración de Looker.

  2. Valores de campo distintos: Conversational Analytics examina los valores de los datos de los campos (en concreto, las dimensiones de cadena y los sinónimos) para identificar las categorías y las entidades disponibles sobre las que pueden preguntar los usuarios. La cardinalidad (el número de valores únicos) puede influir en cómo se usan estos valores.

La eficacia de Estadísticas conversacionales está directamente relacionada con la calidad y la claridad de estas dos entradas. En la siguiente tabla se indican algunas formas habituales en las que un código LookML poco claro o ambiguo puede afectar negativamente a Conversational Analytics, así como soluciones para mejorar los resultados y la experiencia de usuario.

Problema habitual de calidad de LookML Solución para que Conversational Analytics sea más claro
Falta de claridad: los campos que no tienen etiquetas o descripciones claras son ambiguos tanto para Conversational Analytics como para sus usuarios. Aplica etiquetas claras: usa el parámetro label para asignar a los campos nombres intuitivos y fáciles de entender para los usuarios, que probablemente utilicen en sus preguntas.
Inflación de campos: si se exponen demasiados campos, sobre todo IDs internos (claves principales), campos duplicados que se heredan de las combinaciones o campos de cálculo intermedios, se pueden saturar las opciones disponibles en Analíticas conversacional. Ocultar campos irrelevantes: asegúrate de que todas las claves principales, las claves externas, los campos redundantes de las uniones y los campos puramente técnicos permanezcan ocultos.

(Opcional) Ampliar Exploraciones: si tu Exploración contiene un gran número de campos, puedes crear una Exploración que amplíe una ya creada. De esta forma, puede adaptar una versión específica del contenido popular para Analíticas conversacional sin modificar las exploraciones de las que dependa otro contenido.
Conflictos de nombres: si hay varios campos con nombres o etiquetas similares o idénticos en diferentes vistas de Explorar, se puede seleccionar un campo incorrecto. Escribe descripciones detalladas: las descripciones proporcionan un contexto fundamental para la analítica conversacional. Usa el parámetro description para las siguientes tareas:
  • Describe el campo con claridad usando lenguaje natural.
  • Incluir terminología o sinónimos específicos de la empresa o del sector.
  • Explica los cálculos o el contexto. Analíticas de Conversación usa descripciones para identificar mejor los significados de los campos y mapear los términos de los usuarios.

Por ejemplo, un campo con la etiqueta user_count podría tener la descripción "Número total de usuarios únicos que han visitado el sitio web".

Estandariza los nombres: revisa los nombres de los campos y las etiquetas para que sean coherentes y claros.
Complejidad oculta: si se usan en gran medida los campos personalizados o los cálculos de tablas a nivel de panel de control, la lógica empresarial, que puede ser crítica, no estará accesible para Analíticas conversacional. Incorporar lógica personalizada: identifica campos personalizados o cálculos de tabla importantes y de uso habitual. Convierte la lógica de estos campos en dimensiones y medidas de LookML para que Conversational Analytics pueda usarlos.
Datos desordenados: los siguientes tipos de datos incoherentes o mal estructurados dificultan que Analíticas conversacionales interprete las consultas con precisión.
  • Variaciones de valor: si no se usan las mismas mayúsculas y minúsculas o las mismas convenciones de nomenclatura (por ejemplo, si se mezclan los valores complete, Complete y COMPLETE), se pueden duplicar los datos o se pueden establecer relaciones incorrectas entre ellos en Analíticas de conversaciones.
  • Tipos de datos incoherentes: las columnas que deberían ser numéricas y que contienen valores de cadena ocasionales fuerzan el tipo de campo a 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 provocar que el filtrado o la agregación sean incorrectos.
Mejorar la calidad de los datos: cuando sea posible, marca los problemas de calidad de los datos (valores, tipos y zonas horarias incoherentes) que identifiques durante la conservación de los datos. Colabora con los equipos de ingeniería de datos para limpiar los datos de origen o aplicar transformaciones en la capa de modelado de datos o ETL.

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

Cuándo añadir contexto a LookML y cuándo a Conversational Analytics

En Conversational Analytics, puedes añadir entradas de contexto, como sinónimos de campos y descripciones, tanto a LookML como a las instrucciones del agente. Cuando decidas dónde añadir contexto, sigue estas directrices: el contexto que siempre sea verdadero debe añadirse directamente a tu modelo de LookML. Los Exploraciones de Looker se pueden usar en varios sitios, como en paneles de control y en analíticas conversacionales, por lo que el contexto que se aplique en LookML debe ser válido para todos los usuarios que interactúen con los datos.

El contexto del agente debe ser cualitativo y centrarse en el usuario. Además, puede haber muchos agentes que atiendan a diferentes usuarios desde una misma exploración. Estos son algunos 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é funciones tienen? ¿Son internos o externos a la empresa? ¿Qué experiencia tienen con Analytics?
  • ¿Cuál es el objetivo del usuario? ¿Qué tipo de decisión quieren tomar al final de la conversación?
  • ¿Qué tipo de preguntas hará este usuario?
  • ¿Cuáles son los campos principales específicos de este usuario? ¿Qué campos no necesitará usar este usuario?

Prácticas recomendadas para configurar un Explorar que se pueda usar con Analíticas conversacional

Para que Análisis conversacional te proporcione las respuestas más útiles, te recomendamos que sigas estas prácticas recomendadas al definir tus Exploraciones para usarlas como fuente de datos en Análisis conversacional:

  • En el lenguaje LookML subyacente de Explorar, defina solo los campos que sean útiles para el análisis de los usuarios finales.
  • Asigna un nombre claro y conciso a cada campo.
  • Asigna una descripción clara a cada campo, incluidos valores de ejemplo cuando sea pertinente. Estas descripciones de los campos se incluyen en la petición que se envía a Conversational Analytics y pueden ser útiles para proporcionar contexto. Los valores de muestra son especialmente útiles en los campos de cadena.