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

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

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

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

A Análise Conversacional interpreta perguntas em linguagem natural aproveitando estas entradas principais:

  • O modelo LookML: o agente busca o esquema das análises conectadas a ele. O esquema inclui campos (dimensões, medidas), campos somente para filtros (filtros, parâmetros) e os rótulos, descrições e sinônimos correspondentes definidos no modelo LookML que está na base da análise do Looker Explore. Para conferir a lista completa de parâmetros do LookML que a Análise Conversacional analisa, consulte a visão geral da Análise Conversacional.
  • Valores de campo distintos: o agente pode amostrar valores de dados e realizar pesquisas aproximadas 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 corretos e identifique as categorias e entidades disponíveis sobre as quais os usuários podem perguntar.

A eficácia da Análise Conversacional está diretamente vinculada à qualidade e clareza dessas entradas. A tabela a seguir contém maneiras comuns de o LookML pouco claro ou ambíguo afetar negativamente a Análise Conversacional, 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 que não têm rótulos claros, têm definições ambíguas ou compartilham nomes semelhantes em visualizações diferentes podem levar à seleção incorreta de campos. Aplique rótulos claros e descrições detalhadas:
  • Use o parâmetro label para dar aos campos nomes intuitivos e adequados para negócios.
  • Use o parâmetro description para fornecer contexto crítico, definições de linguagem natural e terminologia específica do setor. A Análise Conversacional usa descrições para identificar melhor os significados dos campos e mapear os termos do usuário.
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. Oculte campos irrelevantes: verifique se todas as chaves primárias, chaves estrangeiras e campos técnicos permanecem ocultos.

(Opcional) Estenda as análises: para análises com muitos campos, considere criar uma versão dedicada para a Análise Conversacional estendendo uma análise 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 carga desnecessária, especialmente quando os usuários referenciam valores de dados específicos em consultas. Defina sugestões no 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 as consultas de dados: siga as práticas recomendadas gerais para otimizar o desempenho da consulta, como usar o reconhecimento de agregados e a lógica de junção eficiente.
Definições incompletas do LookML:confiar em campos personalizados ou cálculos de tabelas no nível do painel torna a lógica de negócios crítica inacessível à Análise Conversacional. Incorpore lógica personalizada: converta campos personalizados ou cálculos de tabelas importantes e usados com frequência em dimensões e medidas do LookML.
Dados confusos:os tipos de dados inconsistentes ou mal estruturados a seguir dificultam a interpretação precisa das consultas pela Análise Conversacional.
  • Variações de valor:convenções de capitalização ou nomenclatura inconsistentes (por exemplo, uma combinação dos valores complete, Complete e COMPLETE) podem levar à duplicação de dados ou a relações de dados incorretas na Análise Conversacional.
  • 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 em campos de carimbo de data/hora pode levar a filtragem ou agregação incorreta.
 Aborde a qualidade dos dados:sempre que possível, sinalize problemas de qualidade de dados (valores, tipos, fusos horários inconsistentes) identificados durante a curadoria de dados. Trabalhe com equipes de engenharia de dados para limpar os dados de origem ou aplicar transformações na camada de modelagem de dados/ETL.

Principais conclusões do LookML

Tenha essas conclusões em mente ao definir o LookML para análises 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 empresariais realmente falam. Evite abreviações técnicas como "amt_usd_curr" e use "Amount (USD)".
  • Ative o mapeamento contínuo: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 somente internos no LookML (como chaves estrangeiras ou IDs brutos) para garantir que apenas os campos necessários para responder a perguntas comerciais sejam exibidos na Análise Conversacional. Concentrar-se apenas em campos relevantes reduz o ruído e melhora a precisão da seleção de campos.
  • Otimize os dados de amostra e as consultas de pesquisa aproximada: defina valores codificados no parâmetro suggestions ou use suggest_dimension e suggest_explore para consultas de banco de dados mais eficientes.
  • Otimize as consultas de dados: siga as práticas recomendadas gerais do Looker para otimizar o desempenho da consulta, como usar o reconhecimento de agregados e a lógica de junção eficiente.

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

Práticas recomendadas para configurar uma análise 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 para usar como fonte de dados para a Análise Conversacional:

  • No LookML subjacente da análise, defina apenas os campos úteis para análise pelos 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 a curadoria de análises específicas do agente de dados que reutilizam conteúdo.
    • Use extends para criar o LookML atual e organize 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 do LookML no nível do campo para criar descrições criadas especificamente para agentes: "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 análises bem configuradas, você pode criar agentes de dados para oferecer experiências de conversação personalizadas para casos de uso ou grupos de usuários específicos. Os agentes de dados se conectam a até cinco análises e usam instruções de 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 a criação de agentes especializados para domínios específicos e a escrita de instruções claras e eficazes.

Criar agentes especializados

Embora possa ser tentador criar um agente de dados global para lidar com todas as perguntas 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 intimamente relacionadas pode receber instruções mais precisas, o que reduz a ambiguidade e melhora a precisão da resposta.

Ao criar seus agentes, evite criar um único agente para lidar com todos os modelos de dados não relacionados. Em vez disso, crie agentes focados em áreas de negócios distintas, conectando-se apenas a análises intimamente relacionadas. Por exemplo, em vez de um agente para todos os dados da empresa, crie um "Agente de receita" focado especificamente nas análises Orders e Transactions.

Escrever instruções eficazes do agente

As instruções do agente são sua principal ferramenta para personalizar o comportamento de um agente de dados e infundi-lo com a lógica de negócios e a terminologia exclusivas da sua organização. Pense nas instruções como uma maneira de treinar seu agente sobre como interpretar as perguntas do usuário, lidar com a ambiguidade e responder da maneira mais útil para seus usuários. Instruções bem escritas são fundamentais 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 na lógica e 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 sintaxe do LookML e do filtro: ao se referir a campos ou aplicar filtros em instruções, use a sintaxe do LookML (por exemplo, events.date_created) e a sintaxe do 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".
  • Use consultas de ouro para exemplos complexos: para perguntas ou consultas comuns que envolvem lógica de negócios complexa, forneça golden queries (consultas de ouro), que são pares de perguntas em linguagem natural e as consultas do Looker correspondentes e verificadas. As consultas de ouro podem ajudar o agente a aprender padrões específicos. Concentre-se em consultas que esclareçam terminologia complexa ou combinações de filtros comuns. As consultas de ouro precisam ser fornecidas em uma representação de consulta específica do LookML, em vez de SQL bruto ou URLs de análise padrão.
  • Seja conciso: escreva com clareza e evite palavras ou repetições desnecessárias nas instruções.
  • Evite redundância: não duplique informações que pertencem ao LookML, como descrições de campos ou sinônimos. Para saber mais sobre quando definir o contexto no LookML em vez de instruções do agente, consulte Quando adicionar contexto ao LookML em vez da 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 medida ou como realizar a filtragem básica de datas.

Limitações das instruções do agente

Observe as seguintes limitações da Análise Conversacional ao escrever as instruções do agente:

  • A Análise Conversacional não oferece suporte à geração de consultas que contenham o pivots parâmetro. Embora a Análise Conversacional possa retornar dados para várias dimensões de uma só vez, ela não pode transformá-los em colunas separadas da mesma forma que a interface da análise do Looker. Em vez disso, ela retorna os dados em um formato "longo" ou "aplanado", para que os dados sejam agrupados horizontalmente em vez de verticalmente.

  • A Análise Conversacional não pode reutilizar campos personalizados definidos no conteúdo do Looker atual (por exemplo, quando você usa o LookML gerado de uma análise que contém um campo personalizado para criar uma consulta de ouro) ou gerar novos campos personalizados em uma nova consulta. Em vez disso, ela usa campos do LookML atuais ou usa o Python para criar cálculos personalizados nos resultados dos dados.

  • Ao contrário do LookML, que é regido, as instruções geralmente são texto livre e podem ficar "desatualizadas" à medida que o modelo de dados subjacente evolui ao longo do tempo.

Exemplo de instruções do agente

Confira alguns exemplos de instruções para um agente de dados conectado às análises do Looker chamadas Itens de 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`.

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

Quando adicionar contexto ao LookML em vez da Análise Conversacional

Na Análise Conversacional, você pode adicionar contexto ao LookML ou dentro das instruções do agente. Ao decidir onde adicionar contexto, aplique as seguintes orientações:

  • O contexto que deve ser aplicado a todos os usuários de uma análise precisa ser adicionado diretamente ao modelo LookML, já que as análises do Looker podem ser usadas em vários lugares, incluindo painéis e a Análise Conversacional. Se o contexto só precisar ser aplicado a determinados usuários, considere usar 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 tratados no 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 acessíveis ou como fazer a filtragem básica de datas. Da mesma forma, não defina o mesmo termo no LookML e nas instruções do agente.

O contexto do agente precisa ser qualitativo e focado no usuário, e pode haver muitos agentes atendendo a usuários diferentes de uma análise. O LookML é bom para definir o que um campo é, mas geralmente não pode definir a estratégia de negócios ou cálculos preditivos. Confira exemplos de contexto que precisam ser incluídos nas instruções do agente, mas não no LookML:

  • Quem é o usuário que está interagindo com o agente? Qual é a função dele? Ele é interno ou externo à empresa? Qual é a experiência de análise anterior dele?
  • Qual é o objetivo do usuário? Que tipo de decisão ele quer 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 precisam estar acessíveis a esse usuário, determinados filtros precisam ser sempre aplicados ou alguns campos precisam ser priorizados para esse usuário?