Período, recorte, medida, um pedido por vez

Selo de estado: Preview (teto atual do produto) · Curso ACD-410 — Ingestia AI: perguntar aos dados com proveniência · Aula 4 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai reescrever perguntas ruins — aplicando os quatro elementos que o próprio produto pede (período, recorte, medida, um pedido por vez) e sabendo por que uma pergunta mal feita custa mais caro.

Vídeo#

Identificador no manifesto: acd-410-04-boas-perguntas · duração-alvo 6 min · tela do produto: /query.

Roteiro de gravação (5 capítulos):

Conteúdo#

Os quatro elementos que o produto pede

O assistente de /query traz um bloco recolhido chamado "Como escrever uma boa pergunta". Ele não é decoração: são as quatro peças que transformam uma frase em consulta útil.

1. Diga o período. "Nos últimos 6 meses", "no trimestre passado". Sem período, a consulta varre tudo e custa mais.
2. Diga o recorte. "Por canal", "por loja", "por produto" — é o que vira o agrupamento.
3. Diga a medida. "Faturamento", "quantidade vendida", "ticket médio". Se a sua empresa usa outro nome, use o nome de vocês.
4. Um pedido por vez. Duas perguntas na mesma frase costumam virar um SQL confuso. Faça a segunda depois.

A isso soma-se um quinto princípio, que é o mais difícil de internalizar: não peça causa. A IA descreve o que os dados mostram; ela não afirma que "X causou Y" e recusa quando tentam forçar.

Determinístico × LLM: por que a pergunta ruim sai mais caro

A lição: a recusa é o caminho barato. Perguntar mal não gera erro bonito — gera um SQL plausível que varre a tabela inteira.

Reescritas: text-to-SQL

Reescritas: Q&A do dashboard

O Q&A responde só sobre o snapshot já materializado, e cada afirmação vem com citação. Isso muda o que faz sentido pedir:

Nas telas

Em /query, logo abaixo da caixa de texto, estão as quatro dicas e uma fileira de chips de exemplo — marcados como exemplo, porque não foram gerados das suas tabelas. Use-os como molde e troque as palavras pelos nomes do seu modelo. O campo tem como sugestão de preenchimento algo como "faturamento por mês dos últimos 6 meses": já é período + recorte + medida numa frase.

No painel, a caixa "Pergunte aos seus dados…" do ✨ é o Q&A: pergunta curta, resposta com evidências listadas abaixo. O rodapé avisa que as respostas vêm dos dados já carregados.

Exemplo: a Aurora Varejo

Ana começa com "como estão as vendas?". A resposta esperada é fraca por construção: ou um pedido de precisão, ou um SQL amplo que soma tudo sem período — e um custo estimado desproporcional.

Ela reescreve para "receita por categoria nos últimos 30 dias, só na filial Campinas". A resposta esperada é um SQL agrupando por categoria, com o período como parâmetro nomeado e o filtro de filial presente, sobre aurora_gold.vendas, com custo na casa dos centavos — e a medida citada na proveniência. Quatro palavras-chave a mais trocaram uma varredura por uma consulta estreita.

Depois ela tenta "por que a filial Campinas caiu?" no ✨ do painel. A resposta esperada é uma recusa: o painel não sustenta uma afirmação de causa. A versão que funciona é "qual categoria mais caiu em Campinas vs o mês anterior neste painel?" — descreve, não explica.

Erros comuns

O que esta prática NÃO resolve

Perguntar bem melhora muito o resultado, mas não transforma a IA em fonte de verdade: o estado é Preview, a qualidade em produção é NOT_MEASURED e a avaliação humana é gate pendente. Pergunta boa também não inventa dado que você não tem — comparação com o mercado continua impossível — e não autoriza pular a conferência da proveniência.

Faça você mesmo#

No workspace de treino Aurora Varejo, como admin ou dona. Atenção: os passos 3 a 6 disparam chamadas a modelo e consomem o orçamento de IA do workspace. São cinco reescritas; confira o limite do mês na tela antes de começar e pare se ele estiver perto do teto.

1. Abra /query e expanda "Como escrever uma boa pergunta". Copie as quatro dicas para uma anotação sua.
2. Escreva cinco perguntas ruins de propósito, uma de cada tipo: sem período · sem medida · dois pedidos na mesma frase · pedindo causa · pedindo dado que a Aurora não tem.
3. Gere a proposta para a pior delas e anote o custo estimado por execução e os bytes.
4. Reescreva as cinco aplicando período + recorte + medida + um pedido por vez. Gere a proposta da versão boa correspondente à do passo 3.
5. Compare os dois SQL e os dois custos estimados lado a lado. Anote a diferença em bytes.
6. No ✨ de um painel, faça a pergunta de causa e registre o texto da recusa. Depois faça a versão descritiva e confirme que veio resposta com evidências.
7. Em /auditoria, confira quais das suas tentativas geraram custo e quais foram recusadas antes de gastar.

Você terminou quando tiver as cinco reescritas documentadas (ruim → por que → boa), a comparação de bytes entre a pior e a melhor versão, e uma recusa de causa registrada com o texto exato.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• ai/boas-praticas-de-prompt
• ai/text-to-sql
• ai/qa-dashboard

Capacidades ensinadas#

C13.1 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".