Boas Práticas para Tópicos Multi-Dataset no Amazon QuickSight com Chat por IA

O problema que os Tópicos Multi-Dataset resolvem

A maioria das perguntas de negócio reais envolve mais de uma tabela. Um varejista que quer entender a receita líquida por categoria de produto precisa cruzar uma tabela de vendas, uma de devoluções e uma de dimensão de produtos — cada uma em um dataset separado. Até pouco tempo atrás, unir esses dados exigia que um engenheiro de dados fizesse o pré-join e entregasse um único dataset ao Amazon QuickSight antes de qualquer analista poder fazer uma pergunta.

A AWS anunciou os Tópicos Multi-Dataset no Amazon QuickSight para mudar essa dinâmica. Agora, equipes de analytics podem reunir múltiplos datasets em um único Tópico de duas formas: definindo chaves de relacionamento explícitas ou equipando o motor de Inteligência Artificial (IA) generativa com contexto semântico suficiente para que ele escreva o SQL por conta própria.

Esse post foca no segundo caminho: SQL gerado por IA via Chat. Para entender as diferenças em relação à experiência legada de Tópicos, a AWS recomenda consultar o post Construindo uma camada semântica unificada com Tópicos Multi-Dataset no Amazon QuickSight.

Como o Chat difere dos relacionamentos definidos

Antes de entrar nas boas práticas, é importante entender a diferença arquitetural entre os dois modos de Tópicos Multi-Dataset no QuickSight:

Relacionamentos explícitos: O QuickSight constrói um grafo lógico de joins e executa inner joins em tempo de consulta. O grafo deve ser um Grafo Acíclico Dirigido (DAG — Directed Acyclic Graph), suporta até 12 datasets e produz resultados determinísticos. Ideal para cenários de relatórios governados.
SQL gerado por IA (Chat): A IA lê a camada semântica do Tópico — instruções, descrições e sinônimos — e gera o SQL para responder a pergunta. Não há grafo de joins pré-definido. A IA opera sobre intenção, não sobre estrutura. Isso permite outer joins, unions, subqueries, self-joins e comparações entre granularidades diferentes.

Os relacionamentos definidos funcionam como trilhos de segurança: impedem joins incorretos. A orientação semântica funciona como guia: direciona a IA para o SQL correto e contextualmente apropriado. As duas abordagens têm valor — e podem ser combinadas em um Tópico híbrido.

Para as boas práticas de relacionamentos definidos, a AWS disponibilizou dois posts complementares: Boas práticas de modelagem de dados para relacionamentos multi-dataset no Amazon QuickSight e Padrões de modelagem de dados para relacionamentos multi-dataset no Amazon QuickSight.

A Pilha de Orientação Semântica (Semantic Guidance Stack)

O motor de IA do QuickSight Chat utiliza sete camadas de metadados ao gerar SQL. Entender cada camada é a base para escrever metadados eficazes:

Instruções no nível do dataset: definem a granularidade, o propósito, as chaves e as regras de negócio de cada dataset individualmente.
Instruções no nível do Tópico: definem a lógica entre datasets, regras de desambiguação e comportamentos padrão de join.
Sinônimos de campos: mapeiam o vocabulário de negócio para os nomes técnicos dos campos.
Descrições de campos: explicam a semântica da coluna, unidades, nulabilidade e intervalos válidos.
Exclusões de colunas: removem ruído como chaves internas, timestamps de ETL (Extração, Transformação e Carga) e campos depreciados.
Campos calculados e filtros nomeados: pré-constroem métricas de negócio comuns que a IA pode referenciar diretamente.

Cada camada reduz a incerteza da IA sobre os dados. Quanto mais precisamente cada camada for preenchida, mais estreito fica o espaço de interpretações possíveis de SQL — e mais precisos ficam os resultados gerados.

As 8 Boas Práticas

1. Escreva instruções no nível do dataset como um dicionário de dados

As instruções de dataset são o primeiro ponto de contato da IA com cada tabela. Uma instrução eficaz deve incluir: propósito e granularidade da tabela, chave primária, dicas de chave estrangeira em linguagem natural, regras de negócio, casos extremos conhecidos e regras de agregação.

Exemplo de instrução ruim: “Esta é a tabela de dados de vendas. Ela contém informações de vendas.”

Exemplo de instrução boa:

"SALES_FACT contém uma linha por item de pedido. Chave primária: order_line_id (inteiro, nunca nulo).
Granularidade: um item = um produto em um pedido.
Receita = quantity * unit_price - discount_amount. Sempre SUM receita.
Excluir linhas onde order_status = 'VOID' de todos os cálculos de receita."

2. Escreva instruções no nível do Tópico para lógica entre datasets

As instruções de Tópico dizem à IA como as tabelas se relacionam entre si, qual dataset tem precedência quando os termos são ambíguos e como tratar computações entre datasets. Devem incluir: relacionamentos conceituais, regras de desambiguação, comportamento padrão de join, resolução de múltiplos fatos e definições de negócio que abrangem datasets.

Importante: as instruções de Tópico devem adicionar contexto entre datasets, nunca redefinir semânticas já especificadas no nível do dataset.

3. Projete sinônimos para como os usuários realmente falam

Sinônimos fazem a ponte entre como os usuários expressam perguntas e o que o esquema técnico chama de cada coisa. A estratégia de cobertura deve organizar os sinônimos em quatro níveis: linguagem executiva (nomes de KPIs), linguagem de analistas (definições de métricas), jargão do domínio e abreviações e acrônimos.

A recomendação da AWS é ter entre 3 e 7 sinônimos por coluna consultada com frequência. Menos de 3 deixa lacunas de vocabulário; mais de 10 arrisca introduzir termos ambíguos.

4. Enriqueça descrições de campos e tipos semânticos

As descrições de campos dão à IA uma compreensão precisa do significado, unidade, restrições e uso pretendido de cada coluna. Cada descrição deve incluir: definição precisa, unidade ou formato, nulabilidade, valores válidos ou enumerados e comportamento de agregação.

5. Guie o comportamento de join sem definir relacionamentos

Tópicos orientados por Chat permitem especificar a semântica de join inteiramente por instruções em linguagem natural. A AWS descreve cinco técnicas:

Dicas implícitas de join: declare o tipo e a condição de join como regra em linguagem natural.
Instruções de alinhamento de granularidade: quando dois fatos têm granularidades diferentes, instrua a IA a fazer o rollup antes do join.
Instruções de union: quando duas tabelas têm o mesmo esquema e representam o mesmo tipo de entidade, instrua a IA a usar UNION ALL.
Instruções de subquery: para padrões de negação (“clientes que nunca compraram”), instrua a IA a usar NOT EXISTS ou LEFT JOIN / IS NULL.
Instruções de join condicional: alguns datasets só são relevantes para perguntas específicas — instrua a IA a incluí-los condicionalmente.

6. Trate padrões complexos via instruções semânticas

Tópicos orientados por Chat desbloqueiam padrões analíticos que os relacionamentos definidos não suportam:

Outer joins: instrua a IA a usar LEFT JOIN para preservar registros sem correspondência (ex: produtos sem vendas).
Relacionamentos muitos-para-muitos: instrua a IA a navegar pela tabela de bridge (ex: ENROLLMENTS entre STUDENTS e COURSES).
Hierarquias recursivas: instrua a IA a fazer self-join para representar hierarquias como funcionário/gestor.
Dimensões com múltiplos papéis (role-playing): instrua a IA sobre qual chave usar para cada papel (ex: DATE_DIM usada para data do pedido, data de envio e data de entrega).
Comparações entre granularidades: instrua a IA a fazer o rollup antes de comparar (ex: vendas diárias vs. metas mensais).
Relacionamentos circulares: diferente dos relacionamentos definidos, o Chat não rejeita grafos com ciclos — a IA navega pelo caminho mais apropriado para a pergunta.

7. Reduza ruído e melhore a precisão das respostas

Um achado contraintuitivo: menos campos visíveis produzem respostas mais precisas. A IA processa cada coluna no escopo ao formular o SQL. Colunas técnicas, chaves substitutas, timestamps de ETL e campos depreciados adicionam ruído. A recomendação é excluir: chaves substitutas internas, metadados de ETL, campos depreciados e campos de alta cardinalidade com baixo valor analítico.

8. Teste, valide e itere o modelo semântico

Um modelo semântico nunca está pronto na primeira versão. A AWS recomenda criar um banco de perguntas com 15 a 25 questões por dataset principal, organizadas em cinco níveis de complexidade crescente:

Nível 1: dataset único, métrica única — testa agregação básica e filtro de data.
Nível 2: dataset único, múltiplas dimensões — testa GROUP BY com múltiplas dimensões.
Nível 3: entre datasets, granularidade compatível — testa join e cálculo de divisão.
Nível 4: entre datasets, granularidade incompatível — testa alinhamento de granularidade e lógica de rollup.
Nível 5: padrões complexos — testa LEFT JOIN e agregação segura com NULL.

Os pontos de validação incluem: tipo correto de join, granularidade correta de agregação, seleção correta do dataset, lógica de filtro e tratamento de valores NULL.

Framework de Decisão: qual abordagem escolher?

O Amazon QuickSight oferece três abordagens para Tópicos Multi-Dataset: relacionamentos definidos, orientação semântica (Chat) e um híbrido das duas. A escolha depende do caso de uso, perfil do usuário e requisitos de governança:

Esquema estrela estável, ambiente regulado: relacionamentos definidos — semântica de inner join aplicada, resultados determinísticos.
Analytics exploratório, perguntas ad-hoc: semântico apenas (Chat) — máxima flexibilidade.
Outer joins, unions ou subqueries necessários: semântico apenas (Chat) — relacionamentos definidos suportam apenas inner joins.
Hierarquias recursivas ou self-joins: semântico apenas (Chat).
Usuários não técnicos precisando de proteções: híbrido — grafo de join explícito mais metadados.
Power users, máxima flexibilidade: semântico apenas (Chat).

Considerações práticas adicionais

A AWS destaca alguns pontos importantes para quem for implementar essa abordagem:

Concisão nas instruções: prefira listas de regras em formato de tópicos a parágrafos em prosa. Cada regra deve ser uma afirmação independente e analisável.
Ordem de precedência: quando instruções de Tópico e de dataset conflitam, as de Tópico têm precedência. Use isso de forma previsível.
Performance: mantenha Tópicos focados em um domínio (analytics de varejo, RH, finanças). Evite criar um Tópico único para todo o data warehouse. Datasets com SPICE (in-memory) geralmente produzem respostas mais rápidas que fontes em Direct Query.
Segurança em nível de linha (RLS — Row-Level Security): é aplicada no nível do dataset, independentemente de como a IA faz joins ou unions. Um gestor regional restrito aos dados de sua região nunca verá dados de outras regiões, independentemente da pergunta feita no Chat.
Quando dividir em múltiplos Tópicos: considere dividir quando há comunidades de usuários diferentes com vocabulários distintos, datasets de domínios de negócio diferentes ou quando a complexidade das instruções do Tópico cresce além de 30 regras.

Conclusão

A transição de grafos de relacionamento explícitos para orientação semântica representa uma abordagem fundamentalmente diferente para analytics multi-dataset: em vez de definir cada caminho de join antecipadamente, você descreve a granularidade dos dados, o vocabulário, as regras de negócio e os casos extremos — e a IA traduz a intenção do usuário em SQL correto em tempo de consulta.

Isso desbloqueia capacidades que relacionamentos pré-definidos não suportam: outer joins que preservam registros sem correspondência, unions que combinam tabelas paralelas, self-joins que percorrem hierarquias recursivas e comparações entre granularidades que exigem rollups em tempo de execução. A restrição é semântica, não estrutural: quanto mais precisamente você descreve seus dados, mais confiavelmente a IA entrega resultados corretos.

Fonte

Multi-dataset Topic best practices for Amazon Quick Chat (https://aws.amazon.com/blogs/machine-learning/multi-dataset-topic-best-practices-for-amazon-quick-chat/)