Práticas recomendadas para configurar a análise de conversação no Looker

A Análise conversacional usa o Gemini para Google Cloud (em inglês) para interpretar perguntas em linguagem natural, usando seu modelo semântico do Looker (LookML), valores de dados e configurações do agente de dados como fonte de verdade. A qualidade das respostas está relacionada à eficácia com que você prepara essas entradas.

Este guia oferece estratégias e práticas recomendadas para desenvolvedores e administradores da LookML configurarem e otimizarem a Análise de conversas. Ao seguir estas recomendações para seu modelo LookML, "explores" e agentes de dados, você pode aumentar a adoção pelos usuários e garantir que eles recebam respostas precisas, relevantes e úteis para as perguntas. Este guia aborda as práticas recomendadas relacionadas à análise de conversas, seguindo um fluxo lógico que começa com o desenvolvimento de uma base sólida na LookML de um modelo, a configuração de Análises baseadas nesse modelo e a criação de agentes de dados que usam essas Análises como fontes de dados.

Práticas recomendadas de LookML para a Análise Conversacional

A Análise de conversação interpreta perguntas em linguagem natural usando estas entradas principais:

  • O modelo do LookML: o agente busca o esquema das análises conectadas a ele. O esquema inclui campos (dimensões, métricas), campos somente para filtro (filtros, parâmetros) e os respectivos rótulos, descrições e sinônimos definidos no modelo LookML que embasa a Análise do Looker. Para conferir a lista completa de parâmetros da LookML analisados pela Análise Conversacional, consulte a visão geral da Análise Conversacional.
  • Valores de campo distintos: o agente pode fazer amostragem de valores de dados e realizar pesquisas difusas para verificar valores de campo específicos no banco de dados subjacente. Esses métodos permitem que o agente escolha os campos corretos, aplique os valores de filtro adequados e identifique as categorias e entidades disponíveis sobre as quais os usuários podem perguntar.

A eficácia da análise de dados de conversação está diretamente ligada à qualidade e à clareza dessas entradas. A tabela a seguir contém maneiras comuns de como o LookML pouco claro ou ambíguo pode afetar negativamente a Análise de conversas, além de soluções para reduzir a latência e melhorar a saída e a experiência do usuário.

Problema de qualidade do LookML Solução para uma análise conversacional mais clara
Falta de clareza e conflitos de nomenclatura:campos sem rótulos claros, com definições ambíguas ou que compartilham nomes semelhantes em diferentes visualizações podem levar à seleção incorreta de campos. Use rótulos claros e descrições detalhadas:
  • Use o parâmetro label para dar aos campos nomes intuitivos e adequados para empresas.
  • Use o parâmetro description para fornecer contexto essencial, definições em linguagem natural e terminologia específica do setor. A análise de conversas usa descrições para identificar melhor os significados dos campos e mapear os termos dos usuários.
Excesso de campos:expor muitos campos, como IDs internos, campos duplicados de junções ou cálculos intermediários, dificulta as opções disponíveis para a Análise Conversacional. Ocultar campos irrelevantes:verifique se todas as chaves primárias, chaves externas e campos técnicos permanecem ocultos.

(Opcional) Ampliar as análises detalhadas:para análises detalhadas com muitos campos, crie uma versão dedicada para a Análise Conversacional ampliando uma análise detalhada atual.
Carga do banco de dados para amostragem e pesquisa:a recuperação de valores de amostra e sugestões do banco de dados pode ser lenta ou gerar uma carga desnecessária, especialmente quando os usuários referenciam valores de dados específicos em consultas. Defina sugestões em LookML:evite consultas de banco de dados em tempo real para sugestões de campo codificando valores ou apontando para dimensões mais eficientes:
  • Use o parâmetro suggestions para codificar uma lista de valores possíveis.
  • Use os parâmetros suggest_explore e suggest_dimension para consultar uma dimensão alternativa e mais eficiente para sugestões de filtro.
Carga do banco de dados para consultas de dados:consultas grandes ou ineficientes podem aumentar a latência e a carga do banco de dados. Otimize consultas de dados:siga as práticas recomendadas gerais para otimizar o desempenho das consultas, como usar consciência agregada e lógica de junção eficiente.
Definições incompletas do LookML:confiar em campos personalizados ou cálculos de tabela no nível do painel torna a lógica de negócios essencial inacessível à Análise Conversacional. Incorpore lógica personalizada:converta campos personalizados ou cálculos de tabela importantes e usados com frequência em dimensões e medidas do LookML.
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:capitalização ou convenções de nomenclatura inconsistentes (por exemplo, uma mistura dos valores complete, Complete e COMPLETE) podem 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.
 Melhore a qualidade dos dados de endereço:sempre que possível, sinalize problemas de qualidade de dados (valores, tipos e fusos horários inconsistentes) identificados durante a curadoria. Trabalhe com equipes de engenharia de dados para limpar os dados de origem ou aplicar transformações na camada de ETL/modelagem de dados.

Principais conclusões sobre o LookML

Tenha em mente estas dicas ao definir a LookML para análises detalhadas que serão usadas como fontes de dados para a Análise Conversacional:

  • Use rótulos claros e precisos:escolha rótulos para seus dados que reflitam como os usuários da sua empresa realmente falam. Evite abreviações técnicas como "amt_usd_curr" e use "Amount (USD)".
  • Ativar o mapeamento integrado:use sinônimos e descrições para ajudar o agente a mapear as perguntas do usuário para os campos corretos.
  • Centralize os cálculos:defina cálculos usados com frequência diretamente como dimensões ou medidas do LookML para garantir uma única fonte de verdade e reduzir a latência.
  • Simplifique o contexto: oculte campos técnicos ou apenas internos na LookML (como chaves estrangeiras ou IDs brutos) para garantir que apenas os campos necessários para responder a perguntas de negócios sejam mostrados à Análise Conversacional. Ao focar apenas nos campos relevantes, você reduz o ruído e melhora a precisão da seleção.
  • Otimizar dados de amostra e consultas de pesquisa difusa: defina valores codificados no parâmetro suggestions ou use suggest_dimension e suggest_explore para consultas de banco de dados mais eficientes.
  • Otimize consultas de dados:siga as práticas recomendadas gerais do Looker para otimizar o desempenho das consultas, como usar o reconhecimento de agregados e uma lógica de junção eficiente.

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

Práticas recomendadas para configurar uma análise detalhada para uso com a Análise Conversacional

Para ajudar a Análise Conversacional a fornecer as respostas mais úteis, siga estas práticas recomendadas ao definir suas análises detalhadas para usar como fonte de dados da Análise Conversacional:

  • Na LookML da análise detalhada, defina apenas os campos úteis para a análise dos usuários finais.
    • Dê a cada campo um nome e uma descrição claros e concisos.
    • Inclua valores de amostra quando relevante. Os valores de amostra são especialmente úteis para campos do tipo string.
  • Considere selecionar "Explores" específicos do agente de dados que reutilizam conteúdo.
    • Use extends para criar com base no LookML atual e organizar os campos de que o agente precisa. Na atividade do sistema, os usuários podem ver quais campos são usados em consultas geradas por agentes e decidir quais campos excluir.
    • Use refinamentos da LookML no nível do campo para criar descrições feitas sob medida para agentes, como "Use o campo "Pedidos" quando os usuários se referirem a "Vendas"".

Práticas recomendadas para criar agentes de dados

Depois de estabelecer uma base sólida com as práticas recomendadas do LookML e as Análises bem configuradas, você pode criar agentes de dados para oferecer experiências de conversa personalizadas para casos de uso ou grupos de usuários específicos. Os agentes de dados se conectam a até cinco análises detalhadas e usam instruções em linguagem natural para fornecer contexto, definir terminologia e definir diretrizes comportamentais.

Seguir as práticas recomendadas ao criar agentes e escrever instruções é fundamental para adaptar as respostas do agente às necessidades específicas do usuário e melhorar a precisão geral. Essas práticas recomendadas incluem projetar agentes especializados para domínios específicos e escrever instruções claras e eficazes.

Criar agentes especializados

Embora seja tentador criar um agente de dados global para lidar com todas as questões comerciais, os agentes têm melhor desempenho quando são especializados em um domínio específico, como vendas, marketing ou análise de produtos. Um agente focado em uma ou algumas análises detalhadas relacionadas pode receber instruções mais precisas, o que reduz a ambiguidade e melhora a acurácia da resposta.

Ao projetar seus agentes, evite criar um único agente para processar todos os modelos de dados não relacionados. Em vez disso, crie agentes focados para diferentes áreas de negócios, conectando apenas as Análises relacionadas. Por exemplo, em vez de um agente para todos os dados da empresa, crie um "Agente de receita" focado especificamente nas análises detalhadas de Orders e Transactions.

Escrever instruções eficazes para o agente

As instruções do agente são sua principal ferramenta para personalizar o comportamento de um agente de dados e incorporar a lógica de negócios e a terminologia exclusivas da sua organização. Pense nas instruções como uma forma de treinar seu agente para interpretar perguntas dos usuários, lidar com ambiguidades e responder da maneira mais útil para eles. Instruções bem escritas são essenciais para gerar respostas precisas, relevantes e confiáveis.

Insira as instruções do agente no campo Instruções ao criar o agente de dados. Para mais informações sobre como criar agentes, consulte a página de documentação Criar e gerenciar agentes de dados de análise.

Para escrever instruções eficazes, siga estas práticas recomendadas:

  • Defina o contexto de negócios e o comportamento padrão: treine o agente com a lógica e a terminologia exclusivas da sua organização. Use instruções para definir acrônimos (por exemplo, "LY significa ano passado"), explicar a lógica de filtragem comum ou definir comportamentos padrão para ambiguidade (por exemplo, "Se nenhum date_created for fornecido, filtre os últimos seis meses").
  • Use a LookML e a sintaxe de filtro: ao se referir a campos ou aplicar filtros nas instruções, use a sintaxe da LookML (por exemplo, events.date_created) e a sintaxe de filtro (por exemplo, "last 6 months"). Isso garante que o agente entenda quais campos ou filtros aplicar. Por exemplo: "Quando um usuário perguntar sobre 'região', use o campo account_holder.geo_region".
  • Seja conciso: escreva com clareza e evite palavras desnecessárias ou repetições nas instruções.
  • Evite redundância: não duplique informações que pertencem à LookML, como descrições de campos ou sinônimos. Para saber quando definir o contexto em LookML ou nas instruções do agente, consulte Quando adicionar contexto à LookML ou à Análise conversacional. Evite também explicar conceitos básicos que o agente já entende, como a diferença entre uma dimensão e uma métrica ou como fazer uma filtragem básica de datas.

Limitações das instruções para o agente

Ao escrever as instruções do agente, observe as seguintes limitações do Conversational Analytics:

  • A Análise de conversas não é compatível com a geração de consultas que contêm o parâmetro pivots. Embora a Análise de conversas possa retornar dados de várias dimensões de uma só vez, ela não pode criar tabelas dinâmicas em colunas separadas como a interface de Análise do Looker. Em vez disso, ele retorna os dados em um formato "longo" ou "simplificado", para que os dados sejam agrupados horizontalmente em vez de verticalmente.
  • Ao contrário da LookML, que é controlada, as instruções geralmente são texto livre e podem ficar "desatualizadas" à medida que o modelo de dados subjacente evolui com o tempo. Para evitar instruções desatualizadas com os agentes do recurso "Analisar dados", use consultas verificadas para definir pares de perguntas em linguagem natural e as consultas correspondentes do recurso "Analisar dados".

Exemplo de instruções para o agente

Confira algumas instruções de exemplo para um agente de dados conectado às análises detalhadas do Looker chamadas Itens do pedido e Produtos:

# 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.

Quando adicionar contexto à LookML ou à Análise Conversacional

Na Análise de conversas, é possível adicionar contexto à LookML ou às instruções do agente. Ao decidir onde adicionar contexto, siga estas orientações:

  • O contexto que deve ser aplicado a todos os usuários de uma Análise precisa ser adicionado diretamente ao modelo do LookML, já que as Análises do Looker podem ser usadas em vários lugares, incluindo dashboards e a Análise de conversas. Se o contexto só se aplicar a determinados usuários, use recursos do LookML, como atributos do usuário, para criar experiências personalizadas.
  • Priorize o LookML para metadados específicos do campo e requisitos rígidos. Coloque metadados específicos do campo, incluindo sinônimos e descrições, diretamente no LookML em vez de instruções do agente. Os requisitos para itens como valores de filtro padrão ou campos ocultos precisam ser processados na LookML para garantir que sejam respeitados.
  • Não duplique informações que o agente já conhece, como como criar uma consulta do Looker, uma explicação de dimensões ou medidas, as análises detalhadas acessíveis ou como fazer a filtragem básica de datas. Da mesma forma, não defina o mesmo termo na LookML e nas instruções do agente.

O contexto do agente precisa ser qualitativo e focado no usuário. Além disso, pode haver vários agentes atendendo a diferentes usuários em uma Análise. A LookML é boa para definir o que um campo é, mas geralmente não consegue definir estratégias de negócios ou cálculos preditivos. 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 é o objetivo 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 campos são mais relevantes para esse usuário? Por exemplo, quais campos devem estar acessíveis a esse usuário, determinados filtros precisam ser aplicados sempre ou alguns campos precisam ser priorizados para ele?