Conteúdo didático sobre data engineering como fundação para projetos…
INEMA
ibuição 6. Separar dados discretos e contínuos 7. Definir o grain 8. Normalizar dados 9. Criar tabelas-resumo 10. Colocar em DuckDB, SQLite ou PostgreSQL 11. Testar perguntas reais 12. Decidir se vira sistema 13. Criar skills/regras apenas se necessário 14. Revisar e melhorar continuamente ```
Modelo simples de entrega⌗
Ao final da prática, você deve ter algo assim:
```text /projeto /raw stripe_payments.csv hubspot_contacts.csv time_tracker.xlsx
/snippets stripe_payments_sample.csv hubspot_contacts_sample.csv
/audits stripe_payments_audit.md hubspot_contacts_audit.md
/processed payments_clean.csv contacts_clean.csv
/summaries receita_por_cliente_mes.csv utilizacao_por_consultor_semana.csv
/docs data_dictionary.md grain_definitions.md business_questions.md
engagement.duckdb```
Conclusão prática⌗
A prática é simples:
não comece pelo agente.
Comece pela pergunta, depois audite os dados, normalize, resuma, teste e só então transforme em sistema.
A ordem correta é:
pergunta → fonte → auditoria → limpeza → resumo → consulta → sistema
Essa é a diferença entre uma IA que “parece legal” e uma IA que realmente entrega valor.
os
São medidas:
receita
horas
valor_pago
utilização
dias_desde_último_contato
custo
Use para:
soma
média
mediana
mínimo
máximo
dispersão
Essa separação ajuda a saber que tipo de resumo criar.
7. Defina o grain da análise⌗
Agora defina o nível de detalhe.
Pergunte:
A pergunta precisa ser respondida por dia, semana, mês ou trimestre?
Por cliente, consultor, produto ou região?
Exemplos de grain:
cliente + mês
consultor + semana
produto + mês
região + trimestre
empresa + ano
O grain é uma das decisões mais importantes.
Exemplo:
Se a pergunta é:
Qual cliente gerou mais receita por mês?
O grain será:
cliente + mês
Se a pergunta é:
Qual consultor teve melhor utilização semanal?
O grain será:
consultor + semana
8. Normalize os dados⌗
Agora limpe e padronize.
Exemplos de normalização:
Datas em formato ISO
Moedas convertidas para uma moeda padrão
Nomes de colunas em snake_case
Status padronizados
Campos vazios tratados
Duplicatas removidas
JSONs importantes extraídos em colunas
Colunas obsoletas removidas
Exemplo:
Antes:
Client Name
client-name
CLIENTE
Nome do Cliente
Depois:
cliente
Antes:
Paid
paid
PAID
pago
Depois:
paid
9. Crie tabelas-resumo⌗
Agora transforme dados limpos em tabelas fáceis de consultar.
Exemplos:
receita_por_cliente_mes
utilizacao_por_consultor_semana
pnl_mensal
clientes
funil_por_origem_mes
Uma boa tabela-resumo deve ter:
dimensões
fatos
stamp de geração
grain claro
fonte rastreável
Exemplo:
| mes | cliente | receita_usd | custos | gerado_em |
|---|---|---|---|---|
| 2026-01 | Acme Corp | 15000 | 1200 | 2026-05-14 |
| 2026-01 | Globex | 8500 | 750 | 2026-05-14 |
10. Coloque as tabelas em um banco simples⌗
Para começar, use algo leve.
Opções:
DuckDB
SQLite
PostgreSQL
Supabase
Para muitos projetos, DuckDB já resolve muito bem.
A lógica é:
dados brutos → dados limpos → tabelas-resumo → banco consultável
Assim, o agente não precisa ler milhares de linhas. Ele pode fazer uma consulta SQL e receber só o resultado.
11. Teste com perguntas reais⌗
Agora rode perguntas reais contra as tabelas.
Exemplos:
```Quais foram os 10 clientes com maior receita no último mês?
Qual consultor teve menor utilização nas últimas 4 semanas?
A receita cresceu ou caiu em relação ao mês anterior?
Quais clientes ativos não tiveram contato nos últimos 30 dias?```
Se as respostas não saírem bem, provavelmente o problema está em uma dessas partes:
grain errado
campo ausente
dados mal normalizados
tabela-resumo incompleta
pergunta mal definida
12. Só depois crie skills, regras ou agentes⌗
Depois que a base estiver organizada, você decide o que vira sistema.
Use esta regra:
Vira sistema quando:⌗
a pergunta será feita várias vezes
a resposta muda com o tempo
mais de uma pessoa ou agente vai usar
tem valor recorrente para o negócio
Não vira sistema quando:⌗
é pergunta pontual
é análise única
não muda com frequência
ninguém vai reutilizar
Se virar sistema, escolha o melhor formato:
skill
regra
script
dashboard
tabela-resumo
notebook
automação
13. Enxugue as skills⌗
Evite criar uma skill para cada pequena tarefa.
Ruim:
audit_csv
audit_excel
audit_source
build_revenue_summary
build_customer_summary
build_utilization_summary
Melhor:
audit_source
build_summary
refresh_data
business_brief
pnl_brief
E use regras separadas para padrões gerais:
raw_is_sacred
pii_redaction
summary_conventions
Menos skills, mais claras e mais fortes.
Processo prático completo⌗
Você pode usar este fluxo como checklist:
```text 1. Definir pergunta de negócio 2. Listar fontes de dados 3. Guardar fontes brutas em /raw 4. Criar snippets de 100 linhas 5. Auditar volume, schema, snippet e distr
contínu
Uma prática boa é transformar isso em um processo padrão de diagnóstico e preparação de dados antes de criar qualquer agente, skill ou automação.
Prática passo a passo⌗
1. Comece pela pergunta de negócio⌗
Antes de olhar os dados, defina o que o sistema precisa responder.
Exemplos:
Pergunta fraca: “Quero usar IA nos meus dados.”
Pergunta boa: “Quero saber quais clientes geraram mais receita por mês.”
Pergunta boa: “Quero identificar consultores com baixa utilização semanal.”
Pergunta boa: “Quero gerar um briefing mensal de performance para a diretoria.”
Nesta etapa, anote:
- Qual pergunta será respondida.
- Quem vai usar a resposta.
- Com que frequência essa pergunta será feita.
- Qual decisão será tomada com base nela.
Se a pergunta não for recorrente, talvez não precise virar sistema.
2. Liste todas as fontes de dados⌗
Depois, faça um inventário simples das fontes existentes.
Exemplo:
| Fonte | Tipo | Observação |
|---|---|---|
| Stripe | CSV | pagamentos |
| HubSpot | CSV/API | contatos e funil |
| QuickBooks | pasta/export | financeiro |
| Time tracker | XLSX | horas por consultor |
| Planilha interna | Excel | controle manual |
O objetivo é saber de onde os dados vêm antes de tentar organizá-los.
3. Proteja a pasta raw⌗
Crie uma pasta chamada:
/raw
Tudo que vier do cliente ou dos sistemas entra ali sem alteração.
Regra importante:
raw é sagrado
Ou seja: nunca edite o arquivo original. Se precisar limpar, transformar ou corrigir, faça isso em outra pasta.
Estrutura simples:
/projeto
/raw
/snippets
/audits
/processed
/summaries
/docs
4. Crie snippets de 100 linhas⌗
Para cada fonte, gere uma amostra pequena.
A amostra ideal pode ter:
- primeiras linhas do arquivo;
- linhas aleatórias do meio;
- linhas estranhas ou incompletas;
- dados com campos nulos;
- possíveis duplicatas.
Exemplo de saída:
/snippets/stripe_payments_sample.csv
/snippets/hubspot_contacts_sample.csv
/snippets/time_tracker_sample.csv
A ideia é ter uma amostra pequena o bastante para entender, mas representativa o bastante para detectar problemas.
5. Faça a auditoria de 4 eixos⌗
Para cada fonte, audite quatro coisas.
Eixo 1: Volume⌗
Pergunte:
- Quantas linhas existem?
- Quantas colunas?
- Qual o tamanho do arquivo?
- Existem muitas abas?
- O volume cabe em planilha, banco leve ou precisa de algo maior?
Exemplo:
stripe_payments.csv
18.000 linhas
12 colunas
8 MB
Eixo 2: Schema⌗
Analise:
- nomes das colunas;
- tipos de dados;
- campos obrigatórios;
- porcentagem de nulos;
- colunas duplicadas;
- colunas obsoletas;
- chaves de conexão com outras tabelas.
Exemplo:
customer_id: texto, 0% nulo
amount: número, 0% nulo
currency: texto, 2% nulo
created_at: data, 0% nulo
metadata: JSON, 40% nulo
Eixo 3: Snippet⌗
Olhe manualmente a amostra.
Pergunte:
- Os dados fazem sentido?
- As datas estão no mesmo formato?
- Existem textos em campos numéricos?
- Existem linhas vazias?
- Existem valores estranhos?
- A amostra parece representar o todo?
Aqui você começa a entender a “personalidade” da base.
Eixo 4: Distribuição⌗
Para dados numéricos, veja:
- mínimo;
- máximo;
- média;
- mediana;
- valores negativos;
- outliers.
Para dados categóricos, veja:
- principais categorias;
- categorias raras;
- valores escritos de formas diferentes;
- campos vazios.
Exemplo:
status:
- paid: 12.000
- failed: 3.000
- refunded: 900
- blank: 200
- PAID: 50
Aqui já aparece um problema: talvez paid e PAID precisem ser normalizados.
6. Separe dados discretos e contínuos⌗
Classifique as colunas.
Dados discretos⌗
São categorias:
status
cliente
origem
etapa_do_funil
região
tipo_de_conta
consultor
Use para:
contagens
agrupamentos
top-N
segmentações
filtros
Dados⌗
diminui valor.
10. Skills também precisam ser enxutas⌗
Mais skills não significa melhor sistema.
Muitas skills parecidas criam sobreposição, confusão e risco de acionamento errado. O ideal é reduzir várias skills bagunçadas para poucas skills bem desenhadas, acompanhadas de regras claras.
A lógica é:
menos skills, melhores skills.
11. A parte invisível decide o sucesso⌗
A parte que o cliente vê são agentes, briefs, decisões, skills e automações.
Mas a parte que decide se o projeto vence ou não é a que quase ninguém vê:
- auditorias;
- snippets;
- pipelines;
- convenções;
- tabelas-resumo;
- bancos organizados;
- documentação;
- regras de qualidade.
Essa é a camada que sustenta tudo.
Conclusão final⌗
O grande aprendizado é que projetos de IA não falham principalmente por falta de modelo, prompt ou interface bonita. Eles falham porque os dados por trás estão crus, espalhados, mal auditados e mal modelados.
Para construir IA confiável, primeiro é preciso criar uma fundação confiável.
A fórmula é:
dados limpos + estrutura clara + tabelas-resumo + skills enxutas + regras bem definidas = agentes mais precisos, baratos e úteis.
Podemos concluir que a mensagem central é:
IA boa depende de base boa⌗
A camada de agentes, skills, automações e dashboards é só a parte visível. O que realmente sustenta o resultado é a engenharia de dados por baixo: fontes organizadas, auditoria, limpeza, normalização, tabelas-resumo e regras bem definidas.
Se a base de dados balança, todo o sistema balança.
Principais conclusões⌗
1. O “agentic OS” não começa nos agentes⌗
Antes de pensar em agentes inteligentes, prompts, skills ou automações, é preciso entender os dados.
O stack correto é mais ou menos assim:
fontes brutas → engenharia de dados → resumos/banco → skills/regras → agentes/decisões
Ou seja: o agente só parece inteligente quando a base já está preparada para ele consultar.
2. Dados crus não são bons para IA⌗
Planilhas, CSVs, PDFs, exports, bancos antigos e arquivos soltos geralmente vêm com problemas:
- campos vazios;
- formatos diferentes;
- duplicatas;
- colunas obsoletas;
- datas inconsistentes;
- moedas misturadas;
- JSONs dentro de colunas;
- dados que não respondem às perguntas do negócio.
A IA não deveria “se virar” com isso. Primeiro esses dados precisam ser auditados e tratados.
3. A auditoria vem antes do resumo⌗
Antes de criar tabelas-resumo ou alimentar agentes, é necessário auditar quatro pontos:
Volume: quantas linhas, colunas e arquivos existem.
Schema: nomes de colunas, tipos de dados, chaves e porcentagem de nulos.
Snippet: uma amostra representativa, normalmente 100 linhas.
Distribuição: mínimos, máximos, mediana, categorias principais e valores estranhos.
Se você não consegue responder esses quatro pontos, ainda não entende a fonte de dados.
4. A regra das 100 linhas ajuda a enxergar o problema⌗
Uma amostra de 100 linhas bem escolhida permite entender rapidamente a qualidade dos dados.
Ela deve incluir topo do arquivo, meio aleatório e casos estranhos. A ideia não é analisar tudo de uma vez, mas pegar uma amostra pequena o suficiente para raciocinar e grande o suficiente para revelar padrões.
5. Dados discretos e contínuos exigem análises diferentes⌗
Dados discretos são categorias, como status, origem, ciclo de vida, cliente e etapa do funil. Eles servem para contagens, agrupamentos e top-N.
Dados contínuos são medidas, como receita, horas, utilização e dias desde o último contato. Eles servem para mínimo, máximo, mediana, dispersão e cálculos.
Cada tipo pede uma forma diferente de auditoria e resumo.
6. Tabelas-resumo são o ponto de virada⌗
A tabela-resumo transforma dados grandes e bagunçados em informações prontas para consulta.
Ela combina:
dimensões, como mês e cliente;
fatos, como receita e custos;
stamp, como data de geração;
grain, que define o nível de detalhe, por exemplo cliente + mês.
Essa tabela funciona como um pequeno warehouse reconstruível, simples e confiável.
7. O grain precisa estar claro⌗
O nível de detalhe da tabela define o que o sistema consegue responder.
Exemplos:
- cliente + mês;
- consultor + semana;
- produto + trimestre;
- região + mês.
Se o grain estiver errado, a IA pode responder no nível errado ou não conseguir responder certas perguntas.
8. O ideal é sair do disperso para o unificado⌗
O fluxo recomendado é pegar várias fontes bagunçadas e passar por um funil:
auditar → normalizar → resumir
Depois disso, os dados podem virar um banco leve, como DuckDB, e gerar tabelas úteis como:
- receita por cliente por mês;
- utilização por consultor por semana;
- P&L mensal;
- clientes.
O objetivo é transformar várias fontes caóticas em um warehouse silencioso e confiável.
9. Nem tudo precisa virar sistema⌗
Antes de construir um sistema, é preciso perguntar:
Essa pergunta será respondida mais de uma vez?
A resposta muda conforme o negócio muda?
Mais de uma pessoa ou agente vai usar isso?
Se a resposta for “não”, talvez um script, cache ou notebook seja suficiente.
Construir sistema cedo demais aumenta complexidade, reduz velocidade e
diante.
Isso cria confusão e aumenta o risco de acionamento errado. O ideal é consolidar funções parecidas em skills mais amplas, bem desenhadas e com regras claras.
18. Progressive disclosure melhora o uso de skills⌗
A ideia de progressive disclosure é mostrar ao agente apenas a parte da skill que importa para aquela situação.
Em vez de carregar uma skill enorme com todas as instruções de uma vez, o sistema pode separar instruções por contexto: receita, clientes, utilização, auditoria, resumo etc.
Isso deixa o agente mais focado e reduz erros.
19. O trabalho invisível é o que sustenta o resultado final⌗
A mensagem final é que projetos sérios de IA não dependem apenas de prompts, interfaces ou modelos avançados.
Eles dependem de uma boa estrutura invisível: dados limpos, tabelas bem modeladas, documentação, auditoria, arquitetura e clareza sobre as perguntas de negócio.
A parte “chata” de data engineering é justamente o que permite que a parte “bonita” da IA funcione bem.
20. Conclusão geral⌗
O conteúdo defende que a vantagem real em projetos de IA está em saber organizar os bastidores.
Quem entende dados, schemas, anomalias, tabelas-resumo, tipos de dados, SQL e arquitetura consegue construir sistemas muito mais confiáveis.
A IA pode ajudar muito, mas ela precisa receber uma base preparada. Sem isso, qualquer agente sofisticado fica limitado, caro e pouco confiável.
somas, medianas e agregações.
Dados discretos ou categóricos são valores como status, nome do cliente, região, origem, etapa do funil ou tipo de conta. Eles servem mais para segmentação, filtro e agrupamento.
Saber a diferença ajuda a definir quais análises fazem sentido.
9. Problemas comuns em bases de dados reais⌗
O conteúdo mostra que bases reais geralmente vêm com muitos problemas.
Entre os mais comuns estão linhas vazias, colunas obsoletas, valores nulos, datas misturadas, moedas diferentes, textos em campos numéricos, dados duplicados, JSONs dentro de colunas, campos mal nomeados e estruturas herdadas de migrações antigas.
Esses problemas precisam ser identificados antes de conectar os dados a um agente de IA.
10. Dados ruins geram agentes ruins⌗
Um agente só é tão bom quanto os dados que recebe.
Se ele precisa navegar por dados confusos, incompletos ou contraditórios, vai acabar fazendo inferências frágeis. Mesmo que acerte em alguns casos, o custo em tokens e o risco de erro aumentam muito.
Por isso, preparar os dados antes é mais eficiente do que tentar fazer o agente “se virar” com dados brutos.
11. Summary tables simplificam o trabalho da IA⌗
Um dos conceitos centrais é o uso de tabelas-resumo.
Em vez de entregar todos os dados brutos para a IA, o ideal é criar tabelas já agregadas e organizadas. Por exemplo: receita por cliente por mês, utilização por consultor por semana, P&L mensal ou top clientes por receita.
Isso reduz complexidade, melhora a precisão e facilita a consulta.
12. O conceito de grain⌗
“Grain” é o nível de detalhe de uma tabela.
Uma tabela pode estar no nível diário, semanal, mensal, trimestral, por cliente, por produto ou por consultor.
A escolha depende das perguntas que o negócio quer fazer. Se as perguntas são mensais, faz sentido criar uma tabela mensal. Se são semanais, a tabela precisa preservar esse nível de detalhe.
Escolher o grain correto evita retrabalho e melhora a utilidade da base.
13. SQL é melhor do que jogar tudo no contexto da IA⌗
Para bases maiores, não faz sentido colocar todos os dados dentro da janela de contexto do modelo.
O melhor caminho é armazenar os dados em um banco ou mecanismo de consulta, como DuckDB, SQLite, PostgreSQL, Supabase ou Spark em casos maiores.
Assim, o agente pode escrever uma consulta SQL, buscar apenas o resultado necessário e trabalhar com uma resposta muito mais enxuta.
14. DuckDB e bancos leves são úteis para projetos menores e médios⌗
DuckDB aparece como uma boa opção para organizar dados localmente de forma simples e eficiente.
Ele pode carregar tabelas-resumo, permitir consultas SQL e servir como ponte entre dados organizados e agentes de IA.
Para muitos projetos, não é necessário começar com uma infraestrutura pesada. Um banco leve e bem organizado pode resolver bastante coisa.
15. Big data exige outro tipo de ferramenta⌗
Quando o volume é muito grande, como milhões ou bilhões de linhas, ferramentas simples não bastam.
Nesses casos, pode ser necessário usar soluções como Apache Spark ou pipelines mais robustos de dados.
Mas o conteúdo também alerta que, para quem está começando, esse tipo de ambiente é mais complexo e intimidador. A maioria dos projetos menores provavelmente lidará com milhares ou dezenas de milhares de linhas, não bilhões.
16. Nem toda pergunta merece virar sistema⌗
Antes de criar um sistema ou automação, é preciso perguntar se aquela análise realmente será usada de forma recorrente.
Uma pergunta só merece virar sistema se for feita mais de uma vez, se a resposta mudar com o tempo e se mais pessoas ou agentes precisarem acessá-la.
Perguntas pontuais podem ser resolvidas como análises únicas. Criar sistemas para tudo gera complexidade desnecessária.
17. Skills também precisam ser organizadas⌗
O conteúdo também critica o excesso de skills em sistemas agentic.
Muitas pessoas criam várias skills parecidas, como uma para auditar CSV, outra para Excel, outra para fonte de dados, outra para resumo de receita e assim por
Resumo dos tópicos principais⌗
1. Data engineering é a fundação dos projetos de IA⌗
O tema central é que sistemas com agentes, dashboards, automações e “agentic OS” dependem muito mais da estrutura dos dados do que da interface bonita ou da camada de IA.
A IA é apenas o meio. O que realmente determina se o sistema vai funcionar é o que existe por baixo: dados limpos, bem organizados, bem documentados e acessíveis de forma confiável.
Se os dados estiverem mal estruturados, o agente pode até parecer inteligente, mas vai gastar mais tokens, fazer suposições erradas e entregar respostas pouco confiáveis.
2. A camada agentic é a parte visível, mas não a mais importante⌗
Muita gente foca na parte mais chamativa: agentes, dashboards, automações, skills e interfaces.
Mas essa camada só funciona bem quando as camadas inferiores estão sólidas. O sistema pode ter vários agentes sofisticados, mas se eles estiverem consultando dados ruins, incompletos ou confusos, o resultado também será ruim.
A mensagem é: antes de pensar em agentes, é preciso olhar para os dados.
3. A pirâmide de dados⌗
O conteúdo organiza o raciocínio em uma espécie de pirâmide:
Na base estão as fontes brutas, como planilhas, CSVs, bancos de dados, sistemas antigos, HubSpot, Stripe, QuickBooks, SAP, Oracle e outros.
Depois vem a auditoria dos dados, onde se verifica volume, estrutura, tipos de dados, nulos, duplicatas e anomalias.
Em seguida entram os snippets, que são amostras dos dados usadas para entender rapidamente a qualidade da base.
No topo estão os documentos de apoio, como data dictionaries, briefs e perguntas de negócio.
A ideia é que, sem entender essas camadas, não dá para construir uma solução de IA confiável.
4. O cliente precisa saber quais perguntas quer responder⌗
Um ponto importante é que a empresa precisa ter clareza sobre o que deseja perguntar aos dados.
Se o cliente não sabe quais perguntas quer responder, isso é um sinal de alerta. A IA não resolve sozinha a falta de direção estratégica.
Antes de criar automações, agentes ou sistemas, é preciso entender quais decisões o negócio quer tomar e quais perguntas serão recorrentes.
5. O data dictionary é um documento essencial⌗
O data dictionary é apresentado como uma das peças mais importantes em projetos de dados.
Ele descreve o significado de cada campo, o tipo de dado, o formato, o tamanho, exemplos e observações. Isso ajuda a entender o que cada coluna representa e reduz ambiguidades.
Empresas mais maduras costumam ter esse tipo de documentação. Quando existe, é um bom sinal de organização e facilita muito o trabalho com IA e análise de dados.
6. A auditoria deve olhar para volume, schema, snippets e distribuição⌗
A auditoria dos dados pode ser feita olhando para quatro eixos principais.
O primeiro é o volume, ou seja, quantas linhas, colunas, tabelas e arquivos existem. Isso define quais ferramentas serão necessárias.
O segundo é o schema, que envolve nomes de colunas, tipos de dados, relações entre tabelas e chaves de conexão.
O terceiro são os snippets, pequenas amostras que ajudam a identificar problemas rapidamente.
O quarto é a distribuição, que analisa mínimos, máximos, medianas, categorias principais e valores fora do padrão.
7. Amostras pequenas revelam muitos problemas⌗
O autor recomenda pedir amostras dos dados antes de desenhar qualquer arquitetura.
Muitas vezes, 100 linhas por tabela já mostram boa parte dos problemas. Em bases maiores ou mais complexas, pode ser melhor analisar 1.000 ou 10.000 linhas.
Essas amostras ajudam a detectar duplicatas, campos vazios, valores inconsistentes, datas em formatos diferentes, colunas mal preenchidas e dados migrados incorretamente.
8. Dados contínuos e discretos precisam ser tratados de forma diferente⌗
O conteúdo diferencia dados contínuos e dados discretos.
Dados contínuos são valores que podem ser medidos e divididos, como receita, horas, consumo, tempo e valores financeiros. Eles são usados para cálculos, médias,
Engenharia de Dados na IA - Data engineering
1