Dados

O que “Dados” Significa em Sistemas de IA

Em inteligência artificial (AI) e aprendizado de máquina (machine learning), dados são as evidências que um algoritmo (algorithm) usa para aprender padrões, fazer previsões ou escolher ações. Na prática, “dados” não são apenas arquivos em um bucket — eles incluem:

  • Os sinais brutos que você coleta (texto, imagens, eventos, leituras de sensores, cliques, transações)
  • Os rótulos (labels) ou alvos (anotações humanas, desfechos, avaliações)
  • Os metadados (metadata) (esquema (schema), proveniência (provenance), carimbos de data/hora, consentimento, idioma, fonte, método de coleta)
  • As transformações (transformations) e características (features) usadas por modelos (models)
  • Os registros (logs) produzidos por sistemas implantados (incluindo trajetórias de agentes (agent trajectories) e rastros de uso de ferramentas (tool-use traces))

O desempenho da IA moderna muitas vezes é menos limitado pela arquitetura do modelo do que pela qualidade, cobertura (coverage), governança (governance) e acessibilidade do pipeline de dados (data pipeline) — especialmente em sistemas de longa duração, nos quais os dados mudam ao longo do tempo.

Este artigo cobre o ciclo de vida (lifecycle) de ponta a ponta: coletar, documentar, proteger e gerenciar dados para sistemas de IA, com exemplos práticos e as principais ideias teóricas que motivam boas práticas.

Por que Dados Importam: Fundamentos Teóricos (Breves, mas Úteis)

A distribuição dos dados e a suposição “i.i.d.”

Muitos métodos de aprendizado de máquina (ML) são mais fáceis de analisar quando os exemplos de treinamento são independentes e identicamente distribuídos (i.i.d., independent and identically distributed): cada amostra é extraída de forma independente da mesma distribuição que os dados futuros. Sistemas reais violam isso o tempo todo:

  • Usuários mudam de comportamento
  • Sensores sofrem deriva
  • Funcionalidades do produto mudam
  • Adversários se adaptam
  • Agentes exploram novos estados

Quando a distribuição de implantação (deployment distribution) difere da distribuição de treinamento (training distribution), ocorre mudança de conjunto de dados (dataset shift) (também chamada de mudança de distribuição (distribution shift)). Esse é um dos principais motivos pelos quais modelos degradam após o lançamento, mesmo que as métricas de treinamento parecessem excelentes.

Viés, variância e cobertura

Mesmo “big data” pode ser não representativo. Lacunas de cobertura criam erros sistemáticos para certas subpopulações ou cenários. Isso está intimamente ligado a Viés e Equidade e, muitas vezes, tem mais a ver com escolhas de dados do que com escolhas de algoritmo.

Rótulos são medições, não verdade

Rótulos frequentemente contêm ruído e subjetividade:

  • Anotadores humanos discordam
  • Resultados são atrasados ou censurados
  • Rótulos refletem decisões de política (por exemplo, definições de “fraude”) Trate rótulos como medições com incerteza, não como verdade fundamental. Essa mentalidade orienta diretrizes de anotação melhores, avaliação e monitoramento.

Ciclo de Vida dos Dados para IA: Da Fonte ao Modelo (e de Volta)

Uma visão prática de ciclo de vida:

  1. Definir a tarefa e o comportamento-alvo (o que o modelo deve otimizar)
  2. Coletar dados brutos e resultados
  3. Documentar fontes, significado, consentimento e limitações conhecidas
  4. Limpar/validar e transformar
  5. Rotular (se necessário) e gerenciar a qualidade da anotação
  6. Dividir em treino/validação/teste (e divisões baseadas em tempo quando apropriado)
  7. Armazenar e versionar conjuntos de dados e características
  8. Proteger o acesso e atender a requisitos de privacidade
  9. Treinar e avaliar modelos (veja Avaliação de Modelos)
  10. Implantar, monitorar deriva (drift) e atualizar dados/modelo conforme a realidade muda (veja MLOps)

O ponto-chave é o feedback: a implantação gera novos dados (incluindo casos de falha) que devem informar a próxima iteração.

Coletando Dados

Comece com um plano de dados, não com um scrape

Antes de coletar, anote:

  • Variável-alvo: o que você está prevendo ou otimizando?
  • Unidade de análise: usuário, sessão, documento, imagem, janela de tempo, passo de trajetória
  • População: quais usuários/dispositivos/regiões/períodos de tempo importam?
  • Estratégia de amostragem: aleatória, estratificada, baseada em tempo, aprendizado ativo (active learning)
  • Restrições: privacidade, consentimento, retenção, latência, custo

Um plano forte evita “conjuntos de dados acidentais”, nos quais o modelo aprende atalhos (por exemplo, identificadores vazados, vazamento temporal (time leakage) ou proxies de rótulo).

Fontes de dados e padrões comuns

  • Logs de eventos de produto: cliques, buscas, tempo de permanência (bom para recomendação, ranqueamento)
  • Registros de negócio: transações, tickets, reclamações (muitas vezes bagunçados, mas de alto valor)
  • Sensores/IoT: série temporal (time series) (exige cuidado com timestamps e calibração)
  • Conteúdo gerado por humanos: texto, imagens (exige gestão de direitos e revisão de segurança)
  • Conjuntos de dados de terceiros: início rápido, mas licenciamento e incompatibilidade de distribuição são riscos comuns

Exemplo prático: coletando dados para um classificador de tickets de suporte

Objetivo: encaminhar tickets para a fila correta.

  • Entradas brutas: título/corpo do ticket, metadados do cliente (plano, localidade), timestamp
  • Rótulos: fila/equipe que resolveu (mas cuidado: o encaminhamento pode refletir a estrutura organizacional histórica, não a “correção”)
  • Logging: capture o conteúdo inicial do ticket, não o conteúdo após os agentes editarem (evita vazamento)

Um erro comum é usar campos preenchidos depois do encaminhamento (vazamento temporal). Por exemplo, “assigned_team” pode ser definido pelo próprio fluxo de trabalho que você está tentando prever.

Dados para sistemas agênticos

Em configurações agênticas (agentic) (veja Agentes na área “Agentes e Planejamento”), dados importantes incluem:

  • Trajetórias: estados, ações, recompensas, chamadas de ferramentas, observações
  • Prompts e respostas de cada etapa
  • Saídas de ferramentas e erros (respostas HTTP, resultados de banco de dados)
  • Intervenções humanas (aprovações, correções, escalonamentos)

Esses dados dão suporte a depuração, avaliação e treinamento (por exemplo, aprendizado por imitação (imitation learning) ou ajuste por preferências (preference tuning)).

Rotulagem e Anotação (Quando Supervisão é Necessária)

Aprendizado supervisionado (supervised learning) (veja Aprendizado Supervisionado) depende de rótulos. Acertar os rótulos costuma ser a parte mais cara de um projeto de aprendizado de máquina.

Diretrizes de anotação e consistência

Uma boa anotação exige:

  • Definições claras com casos-limite
  • Exemplos de casos “difíceis” e como decidir
  • Uma forma de registrar rótulos “incertos” ou “informação insuficiente”

Meça o acordo:

  • Acordo entre anotadores (inter-annotator agreement) (percentual simples de concordância ou medidas mais robustas)
  • Fluxos de trabalho de arbitragem (adjudication) para discordâncias
  • Verificações pontuais e tarefas padrão-ouro

Supervisão fraca e rótulos implícitos

Às vezes, os rótulos vêm indiretamente:

  • Cliques como sinais de preferência
  • Compras como sinais de relevância
  • Fraude reportada como um proxy para fraude

Isso é útil, mas tendencioso. Por exemplo, “reportado” depende do comportamento do usuário e de políticas de detecção.

Exemplo prático: dados de preferência para um assistente

Para melhorar um assistente conversacional, você pode coletar:

  • Preferências pareadas (pairwise preferences) entre duas respostas candidatas
  • Motivos (opcional) para diagnosticar modos de falha
  • Contexto sobre a intenção do usuário e restrições

Isso é comum em pipelines modernos de modelos de linguagem grande (LLM) (frequentemente discutidos em Aprendizado por Reforço e otimização por preferências (preference optimization)).

Qualidade dos Dados: O que Medir e Por Quê

A qualidade dos dados é multidimensional:

  • Acurácia (accuracy): valores correspondem à realidade (difícil de garantir)
  • Completude (completeness): padrões de ausência (missingness) (MCAR/MAR/MNAR) podem enviesar modelos
  • Consistência (consistency): a mesma entidade tem campos consistentes entre fontes
  • Atualidade (timeliness): está fresco o suficiente para a tarefa?
  • Validade (validity): está em conformidade com restrições de esquema/faixa
  • Unicidade (uniqueness): entidades ou eventos duplicados distorcem o aprendizado
  • Qualidade dos rótulos: ruído, ambiguidade, deriva nas definições

Validação de dados na prática

Automatize verificações cedo no pipeline. Uma abordagem leve:

import pandas as pd

def validate_events(df: pd.DataFrame) -> None:
    required_cols = {"user_id", "event_time", "event_type"}
    missing = required_cols - set(df.columns)
    if missing:
        raise ValueError(f"Missing columns: {missing}")

    # Basic validity checks
    if df["user_id"].isna().mean() > 0.001:
        raise ValueError("Too many missing user_id values")

    allowed = {"search", "click", "purchase"}
    bad = (~df["event_type"].isin(allowed)).mean()
    if bad > 0:
        raise ValueError(f"Unexpected event_type rate: {bad:.3%}")

    # Time sanity checks (example)
    df["event_time"] = pd.to_datetime(df["event_time"], errors="coerce")
    if df["event_time"].isna().any():
        raise ValueError("Invalid timestamps found")

À medida que os sistemas amadurecem, as equipes frequentemente adotam ferramentas dedicadas para validação e observabilidade de dados (data observability), mas mesmo verificações simples capturam muitos problemas de produção.

Documentação: Tornando Dados Usáveis e Auditáveis

A documentação de dados é como você transforma um conjunto de dados de “um blob de arquivos” em um ativo que outras pessoas podem reutilizar com segurança.

O que documentar

Um mínimo prático:

  • Finalidade: uso pretendido e uso não pretendido
  • Fonte e proveniência: de onde veio, quem coletou, sob quais direitos/consentimento
  • Intervalo de tempo: janela de coleta e cadência de atualização
  • População: o que está incluído/excluído
  • Esquema e semântica: significados, unidades, codificação, valores ausentes
  • Processo de rotulagem: diretrizes, configuração de anotadores, acordo, ambiguidades conhecidas
  • Problemas conhecidos: riscos de viés, riscos de vazamento, artefatos, outliers
  • Segurança e privacidade: campos sensíveis, regras de manuseio, retenção

Formatos comuns incluem “fichas técnicas para conjuntos de dados (datasheets for datasets)” e “cartões de dados (data cards)” internos, análogos a Cartões de Modelo para modelos.

Exemplo prático: um trecho curto de “cartão de dados”

  • Conjunto de dados: tickets_v3
  • Tarefa: encaminhar tickets recebidos para a fila de nível superior
  • Coletado: 2024-01 a 2025-12, atualização semanal
  • Entradas: title, body, locale, plan_tier
  • Excluído: tickets de equipe interna, tickets marcados como spam
  • Rótulos: fila resolvida historicamente (não necessariamente a “melhor” fila)
  • Problemas conhecidos:
    • Reestruturação organizacional em 2025-06 causa mudança de rótulos
    • Alta ausência em plan_tier para clientes legados

Esse tipo de nota evita falhas silenciosas e ajuda a interpretar métricas de avaliação.

Protegendo Dados: Privacidade, Controle de Acesso e Modelos de Ameaça

Dados para IA frequentemente incluem informações sensíveis ou reguladas. Segurança não é opcional.

Riscos comuns

  • Acesso não autorizado a conjuntos de dados brutos
  • Vazamento de informações de identificação pessoal (PII) nos dados de treinamento levando à memorização ou exposição
  • Envenenamento de dados de treinamento (training data poisoning) (entradas maliciosas projetadas para manipular o modelo)
  • Logs inseguros (prompts, saídas de ferramentas, mensagens de usuários armazenadas sem controles)
  • Compartilhamento excessivo entre equipes ou fornecedores

Controles essenciais

  • Controle de acesso: menor privilégio via funções/grupos de gerenciamento de identidades e acessos (IAM), permissões separadas para produção/desenvolvimento
  • Criptografia (encryption): em trânsito (TLS) e em repouso (chaves gerenciadas por KMS)
  • Logs de auditoria: quem acessou o quê, quando
  • Minimização de dados (data minimization): colete apenas o necessário; remova campos não exigidos para modelagem
  • Políticas de retenção (retention policies): excluir ou arquivar conforme necessidades legais e de negócio
  • Segmentação (segmentation): isolar dados especialmente sensíveis (saúde, crianças, finanças)

Técnicas de privacidade em aprendizado de máquina

Dependendo dos requisitos, considere:

  • Anonimização/pseudonimização (anonymization/pseudonymization) (frequentemente frágil; reidentificação pode ser possível)
  • Privacidade diferencial (differential privacy) (garantias mais fortes; pode reduzir utilidade)
  • Aprendizado federado (federated learning) (dados permanecem no dispositivo; ainda exige segurança cuidadosa)
  • Enclaves seguros / computação confidencial (secure enclaves / confidential computing) para fluxos de treinamento sensíveis

Esses temas frequentemente se cruzam com Aprendizado de Máquina com Preservação de Privacidade, Privacidade Diferencial e Aprendizado Federado.

Exemplo prático: lidando com logs de chat para um assistente

Se você registra conversas de usuários para melhorar o modelo:

  • Oculte (redact) ou aplique hash a identificadores (e-mail, números de telefone) quando viável
  • Armazene logs brutos em um enclave restrito; forneça uma visão sanitizada para a maioria dos usuários
  • Separe “logs de depuração” de “corpora de treinamento”
  • Crie fluxos de exclusão para atender solicitações de usuários (e garanta que conjuntos de dados derivados sejam atualizados)

Gerenciando Dados: Armazenamento, Versionamento, Linhagem e Reprodutibilidade

Um bom gerenciamento de dados permite confiabilidade, colaboração e conformidade.

Padrões de armazenamento: lake, warehouse e híbrido

  • Lago de dados (data lake): armazenamento bruto flexível (por exemplo, armazenamento de objetos) para dados não estruturados e semiestruturados
  • Armazém de dados (data warehouse): camada analítica estruturada e otimizada para consultas
  • Lakehouse (lakehouse): mistura de ambos, com formatos de tabela e governança sobre armazenamento de objetos

A abordagem correta depende dos padrões de acesso (treinamento em lote vs características de baixa latência) e da governança.

Versionamento de conjuntos de dados

Modelos são artefatos de código + parâmetros + dados. Se você não consegue reproduzir o conjunto de dados usado para treinamento, não consegue reproduzir ou depurar o modelo de forma confiável.

Abordagens comuns de versionamento:

  • Tirar snapshots de conjuntos de dados por data e IDs imutáveis
  • Armazenamento endereçado por conteúdo (content-addressed storage) (baseado em hash)
  • Usar ferramentas de versionamento de conjuntos de dados (por exemplo, fluxos no estilo DVC) ou equivalentes internos

Um padrão simples para criar divisões estáveis de treino/validação/teste:

import hashlib

def stable_bucket(user_id: str, salt: str = "v1") -> float:
    h = hashlib.sha256(f"{salt}:{user_id}".encode()).hexdigest()
    return int(h[:8], 16) / 16**8  # in [0, 1)

def split(user_id: str) -> str:
    r = stable_bucket(user_id)
    if r < 0.80: return "train"
    if r < 0.90: return "val"
    return "test"

Isso evita vazamento entre divisões quando novos dados chegam e mantém estável a separação no nível do usuário.

Linhagem e proveniência

Linhagem responde:

  • Quais fontes brutas produziram este conjunto de dados?
  • Quais transformações foram aplicadas?
  • Qual versão de código executou o pipeline?
  • Quem aprovou o conjunto de dados para uso?

A linhagem importa para auditorias, investigações de bugs e conformidade.

Repositórios de características e consistência entre treinamento e serving

Muitas falhas de aprendizado de máquina em produção vêm de desalinhamento treinamento–serving (training-serving skew): características calculadas de forma diferente offline (treinamento) vs online (inferência). Um repositório de características (feature store) ou definições compartilhadas de características pode ajudar.

Isso se conecta fortemente a MLOps e boas práticas de implantação.

Preparação de Dados para Modelagem (Sem Transformar Isso em “Vazamento de Dados”)

Transformações comuns

  • Normalização/padronização (normalization/standardization) para características numéricas
  • Tokenização (tokenization) para texto (veja Tokenização)
  • Redimensionamento/aumentação de imagens (veja Aumentação de Dados)
  • Tratamento de valores ausentes (imputação (imputation) vs indicadores explícitos de ausência (missing indicators))

Armadilhas de vazamento

Vazamento de dados (data leakage) ocorre quando informações indisponíveis no momento da previsão são incluídas nas características de treinamento. Exemplos:

  • Usar “resolution_time” para prever prioridade do ticket
  • Usar “future purchases” para prever churn
  • Divisões aleatórias de treino/teste em séries temporais, nas quais dados futuros vazam para o treinamento

Mitigações:

  • Use divisões baseadas em tempo para tarefas temporais
  • Defina explicitamente conjuntos de características “disponíveis no tempo t”
  • Execute verificações de vazamento (correlações com o alvo, timestamps impossíveis)

Dados para Aplicações Modernas com Modelos de Linguagem Grande

Sistemas com modelos de linguagem grande dependem de vários tipos distintos de dados:

  • Dados de pré-treinamento (pretraining data): corpora massivos (geralmente não pertencem às equipes de aplicação)
  • Dados de ajuste fino (fine-tuning data): pares de instrução/resposta, demonstrações de uso de ferramentas
  • Dados de preferência (preference data): rankings pareados, pontuações por rubrica (rubric scores)
  • Corpora de recuperação (retrieval corpora) para RAG: documentos incorporados (embedded) e pesquisados em tempo de execução (veja Geração Aumentada por Recuperação)
  • Conjuntos de avaliação (evaluation sets): prompts curados e comportamentos esperados para testes de regressão (regression testing)

Considerações-chave de gerenciamento:

  • Mantenha conjuntos de avaliação separados e estáveis para evitar “ensinar para o teste” (teaching to the test)
  • Versione corpora de recuperação e incorporações (embeddings) (atualizações de documentos mudam as saídas do modelo)
  • Registre prompts/chamadas de ferramentas com cuidado, porque logs frequentemente contêm conteúdo sensível

Monitorando Dados em Produção: Deriva, Feedback e Gatilhos de Retreinamento

Após a implantação, os dados mudam. O monitoramento deve incluir:

  • Deriva de entrada (input drift): distribuições de características-chave mudam
  • Deriva de conceito (concept drift): a relação entre entradas e saídas muda
  • Deriva de rótulos (label drift): política de rotulagem ou comportamento de anotação muda
  • Regressões de qualidade de dados: picos em campos ausentes, valores inválidos, duplicatas

Gatilhos práticos para investigação ou retreinamento:

  • Queda significativa em indicadores-chave de desempenho (KPIs) de negócio
  • Mudança nas distribuições de características além de limiares
  • Novos lançamentos de produto ou mudanças de política
  • Aumento de taxas de erro para coortes (cohorts) específicas (monitoramento de equidade (fairness monitoring))

Isso faz parte de uma prática robusta de MLOps e deve estar ligado à resposta a incidentes (incident response).

Checklists: Um “Pronto é Pronto” Prático

Checklist de coleta de dados

  • Objetivo claro, variável-alvo e restrições no tempo de previsão
  • Plano de amostragem que corresponda à população de implantação
  • Consentimento/licenciamento confirmado para o uso pretendido
  • Logging estável, versionado e testado (esquemas não mudam silenciosamente)

Checklist de documentação

  • Proveniência, janela de tempo, esquema e limitações conhecidas documentados
  • Processo de rotulagem documentado (diretrizes, QA, acordo)
  • Usos pretendidos e não pretendidos declarados
  • Identificadores de versão e changelog mantidos

Checklist de segurança

  • Acesso de menor privilégio, criptografia em repouso/em trânsito
  • Logs de auditoria habilitados
  • Regras de tratamento de PII aplicadas e testadas
  • Fluxos de retenção/exclusão implementados

Checklist de gestão

  • Versionamento e linhagem do conjunto de dados registrados
  • Divisões reprodutíveis e conjuntos de dados de treinamento
  • Consistência de características entre treinamento e serving garantida
  • Monitoramento de deriva e qualidade de dados em produção

Resumo

“Dados” em IA é uma disciplina de ciclo de vida completo: coletar sinais representativos, documentar significado e limitações, proteger informações sensíveis e gerenciar versões e linhagem para que modelos sejam reprodutíveis e confiáveis. Práticas fortes de dados reduzem vazamento e viés, melhoram a confiabilidade sob mudança de distribuição, viabilizam colaboração mais segura e fornecem a base para sistemas de aprendizado de máquina e sistemas agênticos sustentáveis.

Para práticas relacionadas, veja MLOps, Avaliação de Modelos, Viés e Equidade e Aprendizado de Máquina com Preservação de Privacidade.