Práticas recomendadas para implantar o Conversational Analytics com o Looker

Com a análise de conversação, os usuários podem consultar dados modelados em LookML fazendo perguntas em linguagem natural em uma instância do Looker.

Este guia oferece estratégias e práticas recomendadas para ajudar administradores do Looker e desenvolvedores do LookML a configurar, implantar e otimizar a análise de conversas. Neste guia, abordamos os seguintes tópicos:

Ao preparar seu modelo LookML e a Análise de conversação, você pode aumentar a adoção pelos usuários e garantir que eles recebam respostas precisas e úteis para as perguntas.

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

Práticas recomendadas de LookML para o Conversational Analytics

A análise de dados de conversação interpreta perguntas em linguagem natural usando duas entradas principais:

  1. O modelo LookML: a Análise de dados de conversação analisa a estrutura, os campos (dimensões, medidas), os rótulos e as descrições definidos nas Análises detalhadas do Looker.

  2. Valores de campo distintos: a análise de conversas examina os valores de dados nos campos (especificamente, dimensões de string) para identificar as categorias e entidades disponíveis que os usuários podem consultar. A cardinalidade (o número de valores únicos) pode influenciar a forma como esses valores são usados.

Embora seja poderosa, a capacidade da análise de conversas de ser eficaz está diretamente relacionada à qualidade e à clareza dessas duas entradas. A tabela a seguir contém maneiras comuns de uma LookML pouco clara ou ambígua afetar negativamente a análise de conversas, além de soluções para melhorar a saída e a experiência do usuário.

Problema comum de qualidade da LookML Solução para análises de conversação mais claras
Falta de clareza:campos sem rótulos ou descrições claras são ambíguos para a análise de conversas e para os usuários. Use rótulos claros:use o parâmetro label para dar aos campos nomes intuitivos e adequados para empresas que os usuários provavelmente usarão nas perguntas.
Excesso de campos:expor muitos campos, especialmente IDs internos (chaves primárias), campos duplicados herdados de junções ou campos de cálculo intermediário, pode prejudicar as opções disponíveis para a análise de conversas. Ocultar campos irrelevantes:verifique se todas as chaves primárias, chaves estrangeiras, campos redundantes de junções e campos puramente técnicos permanecem ocultos.

(Opcional) Ampliar análises detalhadas:se a análise detalhada tiver muitos campos, crie uma que amplie uma já existente. Assim, é possível personalizar uma versão dedicada de conteúdo popular para a Análise de conversas sem modificar as análises detalhadas que outros conteúdos podem usar.
Conflitos de nomenclatura:vários campos com nomes ou rótulos semelhantes ou idênticos em diferentes visualizações na análise detalhada podem levar à seleção incorreta de campos. Escreva descrições detalhadas:elas fornecem contexto essencial para a análise de conversas. Use o parâmetro description para as seguintes tarefas:
  • Descreva o campo com clareza usando linguagem natural.
  • Inclua terminologia ou sinônimos específicos da empresa ou do setor.
  • Explique cálculos ou contexto. A análise de conversas usa descrições para identificar melhor os significados dos campos e mapear os termos dos usuários.

Por exemplo, um campo com o rótulo user_count pode ter a descrição "O número total de usuários únicos que visitaram o site".

Padronizar a nomenclatura:revise os nomes dos campos e os rótulos para garantir consistência e clareza.
Complexidade oculta:depender muito de campos personalizados ou cálculos de tabela no nível do painel significa que uma lógica de negócios potencialmente crítica não estará acessível à Análise de conversação. Incorpore lógica personalizada:identifique campos personalizados ou cálculos de tabela importantes e usados com frequência. Converta a lógica desses campos em dimensões e métricas do LookML para que a Análise de conversas possa usá-las.
Dados desorganizados:os seguintes tipos de dados inconsistentes ou mal estruturados dificultam a interpretação precisa das consultas pela Análise de conversas.
  • Variações de valor:o uso inconsistente de maiúsculas ou convenções de nomenclatura (por exemplo, uma mistura dos valores complete, Complete e COMPLETE) pode levar à duplicação de dados ou a relações de dados incorretas na análise de conversas.
  • Tipos de dados inconsistentes:colunas que devem ser numéricas e que contêm valores de string ocasionais forçam o tipo de campo a ser string, o que impede operações numéricas.
  • Ambiguidade de fuso horário:a falta de fusos horários padronizados nos campos de carimbo de data/hora pode levar a filtragem ou agregação incorretas.
Resolva problemas de qualidade de dados:sempre que possível, sinalize problemas de qualidade de dados (valores, tipos, fusos horários inconsistentes) identificados durante a curadoria. Trabalhe com equipes de engenharia de dados para limpar os dados de origem ou aplique transformações na camada de ETL/modelagem de dados.

Para mais práticas recomendadas de como escrever LookML limpa e eficiente, consulte a seguinte documentação:

Quando adicionar contexto à LookML ou ao Conversational Analytics

Na análise de dados de conversação, é possível adicionar entradas de contexto, como sinônimos de campo e descrições, tanto na LookML quanto nas instruções do agente. Ao decidir onde adicionar contexto, siga estas orientações: o contexto que é sempre verdadeiro deve ser adicionado diretamente ao seu modelo LookML. As análises detalhadas do Looker podem ser usadas em vários lugares, incluindo painéis e a Análise de conversas. Portanto, o contexto aplicado no LookML precisa ser válido para todos os usuários que vão interagir com os dados.

O contexto do agente precisa ser qualitativo e focado no usuário. Além disso, pode haver vários agentes atendendo a usuários diferentes em uma análise detalhada. Confira alguns exemplos de contexto que devem ser incluídos nas instruções do agente, mas não na LookML:

  • Quem é o usuário que está interagindo com o agente? Quais são as funções dessas pessoas? Eles são internos ou externos à empresa? Qual é a experiência anterior deles com análise de dados?
  • Qual é a meta do usuário? Que tipo de decisão eles querem tomar no final da conversa?
  • Quais são alguns tipos de perguntas que esse usuário vai fazer?
  • Quais são os principais campos específicos desse usuário? Quais campos esse usuário nunca vai precisar usar?

Este guia recomenda a seguinte abordagem gradual para implementar a análise de conversas no Looker:

Essa abordagem permite começar com um escopo pequeno e controlado, validar sua configuração e depois expandir para mais usuários e dados.

Fase 1: organizar os dados e definir o escopo inicial

Nesta fase, prepare seus dados para que os usuários possam consultar com a Análise de conversas e defina o escopo da implantação inicial. Siga estas recomendações para começar com um escopo pequeno e controlado:

  • Limite o acesso inicial dos usuários: para ativar testes e validações internas, use o sistema de permissões do Looker para conceder a função do Gemini a um pequeno grupo de usuários que conhecem os dados.
  • Limitar o acesso do Gemini aos modelos do Looker: ao conceder a função do Gemini, você também pode limitar os modelos que o Gemini pode acessar. Para começar, limite o acesso do Gemini a um ou dois modelos selecionados para a análise de conversas.
  • Selecione análises detalhadas selecionadas: comece com uma ou duas análises bem estruturadas, baseadas em dados relativamente limpos e que ofereçam um valor comercial claro. Otimize essas análises detalhadas para o Conversational Analytics no Looker seguindo as instruções detalhadas em Práticas recomendadas de LookML para o Conversational Analytics.

Fase 2: configurar agentes e validar internamente

Nesta fase, crie e refine seus agentes de análise de conversas e teste-os completamente com usuários internos para confirmar a precisão e a eficácia. Essa fase envolve as seguintes etapas:

  1. Criar agentes selecionados: crie agentes do Conversational Analytics com base apenas nas análises detalhadas selecionadas que você preparou durante a fase de seleção e configuração inicial.
  2. Refinar com instruções do agente: use instruções do agente para fornecer mais contexto e orientações. Exemplo:

    • Defina sinônimos para nomes ou valores de campos.
    • Forneça contexto ou regras específicas sobre como determinados campos devem ser usados.
  3. Validar internamente e iterar: teste os agentes com usuários que conhecem os dados. Faça várias perguntas, teste casos extremos e identifique pontos fracos. Faça as seguintes mudanças com base no feedback dos testes:

    1. Refine o LookML. Por exemplo, ajuste os valores dos parâmetros do LookML label, description ou hidden.
    2. Ajuste as instruções do agente.
    3. Continue sinalizando problemas com a qualidade dos dados.

Fase 3: aumentar a adoção da análise de conversas para mais usuários

Nesta fase, expanda a adoção da análise de conversas para mais usuários concedendo acesso, coletando feedback e fazendo iterações nos seus agentes. Essa fase envolve as seguintes etapas:

  1. Conceder acesso direcionado: conceda acesso à Análise de conversas a outros usuários que têm a função do Gemini e incentive essas pessoas a usar os agentes específicos e aprovados que você criou.
  2. Lançar e coletar feedback: peça feedback ativamente sobre os seguintes temas:

    • Acurácia das respostas
    • Facilidade de uso
    • Informações ausentes ou resultados confusos
  3. Itere continuamente: use o feedback para fazer mais refinamentos nas instruções do agente e na LookML e priorize os esforços de limpeza de dados.

  4. Ampliar o acesso: depois que os agentes se mostrarem estáveis e valiosos, amplie o acesso a outros grupos de usuários relevantes e apresente novos agentes selecionados concedendo a função do Gemini. Você também pode apresentar novos agentes selecionados e ampliar o acesso aos modelos disponíveis para a função do Gemini, seguindo os mesmos processos usados nas fases anteriores.