Práticas recomendadas para configurar as Estatísticas de conversas no Looker

A análise conversacional permite que os utilizadores consultem dados modelados em LookML fazendo perguntas em linguagem natural numa instância do Looker. Os utilizadores podem consultar os dados das seguintes formas:

Este guia fornece estratégias e práticas recomendadas para ajudar os programadores de LookML a configurar e otimizar com êxito a análise conversacional. Este guia aborda os seguintes tópicos:

Ao preparar o modelo LookML e a análise conversacional, pode aumentar a adoção por parte dos utilizadores e garantir que estes recebem respostas precisas e úteis às suas perguntas.

Saiba como e quando o Gemini para Google Cloud usa os seus dados.

Práticas recomendadas do LookML para as Estatísticas de conversas

As estatísticas de conversas interpretam perguntas em linguagem natural tirando partido de duas entradas principais:

  1. O modelo LookML: a análise conversacional analisa a estrutura, os campos (dimensões, medidas), as etiquetas, as descrições e os sinónimos definidos no modelo LookML subjacente à exploração do Looker.

  2. Valores de campos distintos: a análise conversacional examina os valores de dados nos campos (especificamente, dimensões de strings e sinónimos) para identificar as categorias e as entidades disponíveis sobre as quais os utilizadores podem fazer perguntas. A cardinalidade (o número de valores únicos) pode influenciar a forma como estes valores são usados.

A eficácia da análise conversacional está diretamente relacionada com a qualidade e a clareza destas duas entradas. A tabela seguinte contém formas comuns em que o LookML pouco claro ou ambíguo pode afetar negativamente as análises conversacionais, juntamente com soluções para melhorar o resultado e a experiência do utilizador.

Problema de qualidade do LookML comum Solução para Estatísticas de conversas mais claras
Falta de clareza: os campos que não têm etiquetas ou descrições claras são ambíguos para a estatística de conversação e para os respetivos utilizadores. Aplique etiquetas claras: use o parâmetro label para dar aos campos nomes intuitivos e adequados para empresas que os utilizadores provavelmente usarão nas suas perguntas.
Excesso de campos: expor demasiados campos, especialmente IDs internos (chaves primárias), campos duplicados herdados de junções ou campos de cálculo intermédios, pode desorganizar as opções disponíveis para a análise conversacional. Oculte campos irrelevantes: certifique-se de que todas as chaves primárias, chaves estrangeiras, campos redundantes de junções e campos puramente técnicos permanecem ocultos.

(Opcional) Estenda as explorações: se a sua exploração contiver um grande número de campos, considere criar uma nova exploração que estenda uma existente. Isto permite-lhe personalizar uma versão dedicada de conteúdo popular para a análise conversacional sem modificar as explorações de que outro conteúdo possa depender.
Conflitos de nomenclatura: vários campos com nomes ou etiquetas semelhantes ou idênticos em diferentes vistas na funcionalidade Explorar podem levar a uma seleção de campos incorreta. Escreva descrições detalhadas: as descrições fornecem contexto essencial para a análise conversacional. Use o parâmetro description para as seguintes tarefas:
  • Descreva o campo de forma clara usando linguagem natural.
  • Inclua terminologia ou sinónimos específicos da empresa ou do setor.
  • Explicar cálculos ou contexto. A análise conversacional usa descrições para identificar melhor os significados dos campos e mapear os termos do utilizador.

Por exemplo, um campo com a etiqueta user_count pode ter a descrição "O número total de utilizadores únicos que visitaram o Website".

Padronize a nomenclatura: reveja os nomes dos campos e as etiquetas para garantir consistência e clareza.
Complexidade oculta: depender fortemente de campos personalizados ou cálculos de tabelas ao nível do painel de controlo significa que a lógica de negócio potencialmente crítica não vai estar acessível ao Conversational Analytics. Incorporar lógica personalizada: identifique campos personalizados ou cálculos de tabelas importantes e usados com frequência. Converta a lógica destes campos em dimensões e medidas do LookML para que o Conversational Analytics os possa usar.
Dados desorganizados: os seguintes tipos de dados inconsistentes ou mal estruturados dificultam a interpretação precisa das consultas por parte da análise conversacional.
  • Variações de valores: a utilização inconsistente de maiúsculas e minúsculas ou convenções de nomenclatura (por exemplo, uma combinação dos valores complete, Complete e COMPLETE) pode originar duplicação de dados ou relações de dados incorretas no Conversational Analytics.
  • Tipos de dados inconsistentes: as colunas que se destinam a ser numéricas e que contêm valores de string ocasionais forçam o tipo de campo a ser string, o que impede as operações numéricas.
  • Ambiguidade do fuso horário: a falta de fusos horários padronizados nos campos de data/hora pode levar a uma filtragem ou agregação incorreta.
Resolva problemas de qualidade de dados: sempre que possível, sinalize problemas de qualidade de dados (valores, tipos e fusos horários inconsistentes) que identificar durante a organização dos dados. Trabalhe com equipas de engenharia de dados para limpar os dados de origem ou aplicar transformações na camada de modelagem de dados/ETL.

Para ver mais práticas recomendadas para escrever LookML limpo e eficiente, consulte a seguinte documentação:

Quando adicionar contexto ao LookML em comparação com as Estatísticas de conversas

Na análise conversacional, pode adicionar entradas de contexto, como sinónimos de campos e descrições, tanto ao LookML como às instruções do agente. Quando estiver a decidir onde adicionar contexto, aplique as seguintes orientações: o contexto que é sempre verdadeiro deve ser adicionado diretamente ao seu modelo LookML. Os Explorar do Looker podem ser usados em vários locais, incluindo em painéis de controlo e na análise conversacional, pelo que o contexto aplicado no LookML tem de ser válido para todos os utilizadores possíveis que vão interagir com os dados.

O contexto do agente deve ser qualitativo e focado no utilizador, e pode haver muitos agentes a servir diferentes utilizadores a partir de uma única página Explorar. Seguem-se exemplos de contexto que devem ser incluídos nas instruções do agente, mas não no LookML:

  • Quem é o utilizador que está a interagir com o agente? Qual é a respetiva função? São internos ou externos à empresa? Qual é a experiência anterior em estatísticas?
  • Qual é o objetivo do utilizador? Que tipo de decisão querem tomar no final da conversa?
  • Quais são alguns tipos de perguntas que este utilizador vai fazer?
  • Quais são os principais campos específicos deste utilizador? Quais são os campos que este utilizador nunca vai precisar de usar?

Práticas recomendadas para configurar a ferramenta Explorar para utilização com a análise conversacional

Para ajudar as Estatísticas de conversas a fornecer as respostas mais úteis, considere seguir estas práticas recomendadas quando definir as suas explorações para usar como origem de dados para as Estatísticas de conversas:

  • No LookML subjacente da sua exploração, defina apenas os campos úteis para a análise por parte dos utilizadores finais.
  • Atribua a cada campo um nome claro e conciso.
  • Dê a cada campo uma descrição clara, incluindo valores de exemplo quando for relevante. Estas descrições dos campos estão incluídas no comando enviado para o Conversational Analytics e podem ser úteis para fornecer contexto. Os valores de exemplo são especialmente úteis para campos de string.