Curadoria de Datasets

A curadoria de conjuntos de dados (dataset curation) é a disciplina de transformar “dados brutos (raw data)” em um ativo confiável de treinamento/avaliação (reliable training/evaluation asset) para aprendizado de máquina (machine learning, ML). Ela fica entre a coleta e a modelagem: você decide o que incluir, o que excluir, como limpar e equilibrar, como documentar e como manter o conjunto seguro e legalmente utilizável ao longo do tempo. Uma boa curadoria melhora o desempenho e a robustez do modelo; uma curadoria ruim pode introduzir silenciosamente viés, vazamento, violações de privacidade e risco de licenciamento.

Este artigo foca em fluxos de trabalho práticos e nos trade-offs (tradeoffs) que curadores fazem — especialmente para sistemas modernos de aprendizado de máquina (ML systems) (incluindo modelos de linguagem grandes (large language models)) — em que a escala do conjunto de dados, a proveniência (provenance) e as restrições de segurança/importância de segurança (safety constraints) importam tanto quanto a acurácia.

O que “curadoria de conjuntos de dados” significa (e por que isso importa)

Um conjunto de dados curado é mais do que um arquivo de exemplos. Ele é uma coleção versionada, documentada e com controle de qualidade de registros com:

  • Escopo e uso pretendido definidos (quais tarefas e populações ele representa)
  • Clareza de proveniência e licenciamento (de onde veio, direitos de uso)
  • Controles de qualidade (redução de ruído, normalização (normalization), deduplicação (deduplication))
  • Cobertura e balanceamento (evitar sub-representação sistemática)
  • Tratamento de segurança e privacidade (PII, conteúdo sensível, dados restritos)
  • Reprodutibilidade (reproducibility) (builds determinísticos, versionamento, trilhas de auditoria)

As escolhas de curadoria afetam diretamente:

  • Generalização (generalization): dados mais limpos e melhor cobertura geralmente ajudam.
  • Viés e equidade (bias and fairness): fontes desbalanceadas codificam vieses sociais e de plataforma.
  • Sobreajuste e memorização (overfitting and memorization): duplicatas e quase-duplicatas aumentam o risco de memorização.
  • Integridade de avaliação (evaluation integrity): contaminação (contamination) (sobreposição treino/teste) infla métricas.
  • Exposição legal: licenças pouco claras, texto protegido por direitos autorais e violações de privacidade podem criar riscos sérios.

A curadoria se relaciona de perto com Coleta e Rotulagem de Dados, Qualidade de Dados e Deriva, Versionamento de Dados e Documentação de Conjuntos de Dados (Datasheets).

Um ciclo de vida prático de curadoria

Um processo robusto de curadoria geralmente é iterativo:

  1. Definir requisitos: tarefa, população, risco aceitável, métricas.
  2. Selecionar fontes: avaliar representatividade, qualidade e status legal.
  3. Ingerir e normalizar: analisar formatos, padronizar esquemas, desidentificar quando necessário.
  4. Limpar e deduplicar: remover registros corrompidos, normalizar texto, detectar duplicatas.
  5. Filtrar: aplicar políticas de qualidade e segurança; remover spam e conteúdo tóxico conforme necessário.
  6. Balancear cobertura: garantir que domínios, idiomas, classes e demografias não estejam enviesados.
  7. Rotulagem / rotulagem fraca (weak labeling) (se necessário): diretrizes, auditorias, arbitragem.
  8. Empacotar partições (splits): treino/validação/teste com prevenção de vazamento.
  9. Documentar e versionar: proveniência, receita de build, problemas conhecidos, registro de mudanças.
  10. Monitorar e manter: deriva, ciclos de realimentação, rebuilds periódicos, desativar dados inseguros.

Na prática, a curadoria frequentemente é implementada como um pipeline reprodutível (pipeline) (veja Pipelines de Dados (ETL/ELT para ML)) com etapas de revisão humana para decisões de alto risco.

Selecionando fontes de dados: qualidade, representatividade e direitos

A seleção de fontes é a decisão de maior alavancagem que você toma. Tipos comuns de fontes:

  • Dados primários (first-party data) (logs do seu produto, tickets de suporte, fluxos de sensores)
    • Prós: alinhados ao seu caso de uso, permissões mais claras
    • Contras: podem ser enviesados para usuários atuais; podem conter informações sensíveis
  • Conjuntos de dados públicos (public datasets) (corpora acadêmicos, conjuntos de benchmark)
    • Prós: documentados e amplamente usados
    • Contras: podem estar desatualizados; o licenciamento ainda pode ser restritivo
  • Dados da web (web data) (páginas raspadas, fóruns, redes sociais)
    • Prós: escala enorme, cobertura ampla
    • Contras: spam, toxicidade, ambiguidade de direitos autorais/licenciamento, problemas de representatividade
      Veja Dados da Web e Raspagem.
  • Dados de parceiros/fornecedores
    • Prós: curados para certos domínios (por exemplo, médico, jurídico)
    • Contras: restrições contratuais, requisitos de auditoria, dependência do fornecedor

Checklist prático para avaliação de fontes

Antes de ingerir uma fonte, registre:

  • Licença e termos: o treinamento é permitido? a redistribuição é permitida? derivados são permitidos?
  • Consentimento e privacidade: os dados contêm informações pessoalmente identificáveis (PII, personally identifiable information) / informações de saúde protegidas (PHI, protected health information)? foram coletados com consentimento?
  • Representatividade: quais populações ou tópicos dominam? quais estão ausentes?
  • Estabilidade: a fonte vai desaparecer ou mudar de formato com frequência?
  • Rastreabilidade: você consegue armazenar URLs/IDs de origem e timestamps para auditorias?
  • Perfil de risco: probabilidade de conteúdo tóxico, difamação ou material ilegal

Exemplo: Construindo um assistente de suporte ao cliente

  • Prefira tickets resolvidos primários e artigos de base de conhecimento (knowledge base) (permissão clara, domínio alinhado).
  • Use documentação técnica pública com licenças permissivas.
  • Evite raspagem ampla da web a menos que você tenha uma base legal sólida e um plano de filtragem.

Modelagem e normalização de dados (não pule as partes chatas)

A curadoria é mais fácil quando o conjunto de dados tem um esquema consistente e unidades consistentes.

Etapas típicas de normalização:

  • Padronizar codificações (por exemplo, UTF-8), quebras de linha e espaços.
  • Analisar campos estruturados (timestamps, idioma, códigos de país).
  • Normalizar texto (normalização unicode, transformar em minúsculas apenas quando apropriado).
  • Validar restrições (campos não vazios, faixas esperadas).
  • Anexar metadados (fonte, hora de coleta, tag de licença, versão do parser).

Para dados multimodais (multimodal) (texto+imagem+áudio), defina:

  • Um ID de registro estável
  • Referências para blobs (caminhos/URIs de armazenamento de objetos)
  • Metadados específicos por modalidade (duração, taxa de amostragem, resolução)
  • Formato de anotação e sistemas de coordenadas
    Veja Conjuntos de Dados Multimodais.

Limpeza: removendo corrupção e reduzindo ruído

A limpeza é sobre tornar o conjunto de dados mais aprendível sem deletar variabilidade legítima.

Operações comuns de limpeza:

  • Remover registros malformados (JSON quebrado, arquivos ilegíveis).
  • Remover boilerplate (banners de cookies, menus de navegação) em texto da web.
  • Identificação de idioma e filtragem de escrita/script (manter o que você suporta).
  • Remover caracteres de controle, caracteres repetidos ou spam óbvio de templates.
  • Normalizar espaços duplicados e quebras de linha.

Trade-off: limpeza agressiva vs. perda de sinal

Limpar demais pode prejudicar o desempenho quando o “ruído” na verdade faz parte da distribuição-alvo (por exemplo, erros de digitação em chat, artefatos de OCR em documentos digitalizados). Uma abordagem prática é:

  • Manter dados brutos em armazenamento frio (cold storage),
  • Produzir um conjunto de dados derivado limpo para treinamento,
  • Manter uma receita de build (build recipe) para que as decisões sejam reprodutíveis.

Deduplicação: exata, quase-duplicata e vazamento entre partições

Duplicatas inflacionam o tamanho do conjunto de dados sem adicionar informação e podem aumentar o risco de memorização. Elas também causam contaminação treino/teste (train/test contamination) quando as mesmas amostras ou amostras quase idênticas aparecem em múltiplas partições.

Tipos de duplicatas

  • Duplicatas exatas: strings/arquivos idênticos após normalização.
  • Quase-duplicatas: pequenas edições, mudanças de formatação ou sobreposições parciais.
  • Duplicatas semânticas: paráfrases; mais difíceis de detectar e às vezes desejáveis de manter.

Fluxo de trabalho prático de deduplicação

  1. Canonicalizar o conteúdo (normalizar espaços, remover boilerplate).
  2. Deduplicação exata com hash (hashes) (rápida).
  3. Deduplicação aproximada com impressões digitais (fingerprinting):
    • Texto: SimHash, MinHash, shingles de n-gramas (n-gram shingles)
    • Imagens: hashes perceptuais (pHash/aHash), similaridade por embeddings
  4. Deduplicação entre partições: garantir que teste/validação não sejam duplicatas dos dados de treino.

Exemplo: detecção de texto quase-duplicado com MinHash (esboço)

from datasketch import MinHash, MinHashLSH

def shingles(text, k=5):
    tokens = text.split()
    return {" ".join(tokens[i:i+k]) for i in range(max(0, len(tokens)-k+1))}

def minhash_signature(text, num_perm=128):
    m = MinHash(num_perm=num_perm)
    for s in shingles(text):
        m.update(s.encode("utf-8"))
    return m

lsh = MinHashLSH(threshold=0.85, num_perm=128)

signatures = []
for idx, doc in enumerate(docs):
    sig = minhash_signature(doc)
    lsh.insert(str(idx), sig)
    signatures.append(sig)

clusters = []
seen = set()
for i, sig in enumerate(signatures):
    if i in seen: 
        continue
    near = [int(j) for j in lsh.query(sig)]
    for j in near:
        seen.add(j)
    clusters.append(near)

# Keep one representative per cluster (e.g., the longest or highest-quality)

Trade-off: Se você deduplicar agressivamente demais, pode remover repetições legítimas que refletem a frequência do mundo real (por exemplo, intenções comuns de usuários). Um compromisso comum é:

  • Deduplicar corpora em escala web de forma agressiva,
  • Deduplicar logs de usuários de modo mais conservador (preservar informação de frequência),
  • Sempre deduplicar entre partições de avaliação de forma estrita.

Filtragem: qualidade, segurança e restrições de domínio

A filtragem remove exemplos de baixa qualidade, fora do domínio, inseguros ou legalmente problemáticos. A maioria das equipes implementa filtragem como uma cascata — heurísticas baratas primeiro, modelos mais pesados depois.

Categorias comuns de filtros

Filtros de qualidade

  • Muito curto/muito longo (por exemplo, “ok” ou dumps com megabytes)
  • Repetição excessiva (“aaaaa…”, parágrafos repetidos)
  • Indicadores de spam (muitos links, keyword stuffing)
  • Score baixo de modelo de linguagem ou heurísticas de perplexidade (perplexity) (cuidado: pode remover dialetos)

Filtros de domínio

  • Manter apenas idiomas ou domínios-alvo (por exemplo, resumos médicos)
  • Rejeitar código se você estiver construindo um conjunto de dados apenas conversacional (ou vice-versa)

Filtros de segurança

  • Ódio/assédio, conteúdo sexual, conteúdo de autoagressão (dependente de política)
  • Instruções para atos ilícitos (por exemplo, fabricação de armas)
  • Difamação ou acusações pessoalmente identificáveis

Filtros legais/conformidade

  • Fontes sensíveis a direitos autorais (dependendo da sua política)
  • Conteúdo licenciado incompatível com seu uso pretendido
  • Dados pessoais que você não pode processar legalmente sem salvaguardas

Exemplo: uma cascata simples de filtros

def passes_filters(record):
    text = record["text"]

    # Fast heuristics
    if len(text) < 50:
        return False
    if text.count("http://") + text.count("https://") > 10:
        return False
    if is_gibberish(text):   # e.g., character entropy / repetition rules
        return False

    # Language filter
    if detect_language(text) not in {"en", "es"}:
        return False

    # Safety model (slower)
    scores = safety_classifier(text)
    if scores["sexual"] > 0.9 or scores["hate"] > 0.8:
        return False

    return True

Trade-off: Filtrar reduz risco, mas pode introduzir viés ao excluir desproporcionalmente certos dialetos, xingamentos ressignificados, discussões de grupos minoritários ou educação em saúde sexual. Mitigações incluem:

  • Calibrar limiares por subgrupo,
  • Revisão humana para categorias limítrofes,
  • Manter conjuntos de auditoria de filtros para medir impacto desigual.

Balanceando cobertura: representatividade e comportamento de cauda longa

Mesmo conjuntos de dados “limpos” podem ser enviesados. Desequilíbrios de cobertura fazem os modelos terem desempenho pior para classes minoritárias, intenções raras, idiomas menores ou demografias sub-representadas.

O que “balanceamento” pode significar

  • Balanceamento de classes (rótulos representados de forma uniforme)
  • Balanceamento de domínio (notícias vs. fóruns vs. documentação)
  • Balanceamento geográfico/de idioma
  • Balanceamento temporal (evitar treinar apenas com distribuições desatualizadas)
  • Balanceamento por segmento de usuários (novos usuários vs. usuários avançados)

Técnicas para melhorar cobertura

  • Amostragem estratificada: impor cotas em dimensões-chave.
  • Reponderação: manter a frequência bruta, mas ajustar pesos de treinamento.
  • Coleta direcionada: preencher lacunas com fontes adicionais (frequentemente o melhor).
  • Aumento de dados (data augmentation): para algumas modalidades/tarefas, use Aumento de Dados.
  • Dados sintéticos (synthetic data): podem ajudar a preencher lacunas, mas adicionam seus próprios riscos; veja Dados Sintéticos.

Exemplo prático: balanceando um conjunto de dados de suporte de produto

Suponha que 70% dos tickets sejam “redefinição de senha”, e apenas 1% sejam “disputas de cobrança”, mas disputas de cobrança tenham alto impacto. Você poderia:

  • Manter a maior parte dos exemplos de redefinição de senha (ainda são importantes),
  • Superamostrar ou coletar mais exemplos de cobrança,
  • Garantir que a avaliação inclua casos de cobrança suficientes para medir melhorias.

Trade-off: Balancear demais pode reduzir o desempenho nos casos mais comuns. Alinhe o balanceamento com sua função objetivo (por exemplo, acurácia média vs. acurácia no pior caso vs. erro ponderado por custo).

Lidando com conteúdo sensível: privacidade, segurança e dados restritos

Conteúdo sensível aparece em muitos conjuntos de dados do mundo real — especialmente logs e texto gerado por usuários.

Categorias comuns de conteúdo sensível

  • PII: nomes, e-mails, números de telefone, endereços, IDs
  • PHI: detalhes médicos (dependente de jurisdição)
  • Dados financeiros: números de cartão, contas bancárias
  • Dados de menores
  • Conteúdo extremamente inseguro/ilegal: por exemplo, material de abuso sexual infantil (CSAM, child sexual abuse material) (requer procedimentos rigorosos)

Isso se sobrepõe fortemente a Privacidade e Segurança de Dados.

Salvaguardas práticas

  • Minimizar: você precisa mesmo dos campos sensíveis?
  • Armazenamento separado: manter dados restritos brutos em um enclave seguro; usar derivados desidentificados para treinamento.
  • Controles de acesso e logs: menor privilégio, trilhas de auditoria.
  • Redação/anonimização: remover ou mascarar PII (mas lembre: anonimização perfeita é difícil).
  • Políticas de retenção: deletar dados que você não precisa mais.
  • Protocolos de revisão humana: especialmente para conteúdo de alto risco.

Exemplo: redação leve de PII (ilustrativo)

import re

EMAIL = re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b")
PHONE = re.compile(r"\b(\+?\d{1,3}[-.\s]?)?(\(?\d{3}\)?[-.\s]?)\d{3}[-.\s]?\d{4}\b")

def redact(text):
    text = EMAIL.sub("[EMAIL]", text)
    text = PHONE.sub("[PHONE]", text)
    return text

Importante: Redação baseada em regex falha em muitos casos (nomes, IDs dependentes de contexto) e pode redigir demais números benignos. Em cenários de alto risco, frequentemente são necessários detectores dedicados, extração estruturada de PII e auditorias manuais.

Trade-off de conteúdo sensível

Remover todo conteúdo sensível pode reduzir memorização nociva e risco de conformidade, mas também pode piorar modelos em:

  • Recusar solicitações inseguras (se nunca as virem),
  • Lidar com cenários reais de suporte (“Perdi o número do meu cartão…”),
  • Entender contextos médicos/jurídicos.

Um padrão comum é:

  • Manter tópicos sensíveis, mas remover identificadores sensíveis,
  • Separar dados de “treinamento de política” dos dados de “capacidade”,
  • Usar controles mais estritos em conjuntos de dados usados para pré-treinamento de uso geral.

Qualidade de rotulagem (quando seu conjunto de dados inclui rótulos)

Se seu conjunto de dados for supervisionado (supervised), a qualidade dos rótulos faz parte da curadoria. Práticas-chave (expandidas em Coleta e Rotulagem de Dados):

  • Diretrizes claras de rotulagem com casos-limite e contraexemplos
  • Medição de concordância entre anotadores (inter-annotator agreement) (para detectar ambiguidade)
  • Arbitragem (adjudication) para discordâncias (especialmente em rótulos subjetivos)
  • Conjuntos ouro (gold sets) e verificações pontuais (QA contínuo)
  • Monitoramento de deriva de rótulos (label drift) quando definições evoluem

Trade-off: Diretrizes rígidas melhoram consistência, mas podem simplificar demais a realidade. Quando a tarefa é inerentemente ambígua (toxicidade, sentimento), você pode precisar de rótulos probabilísticos ou distribuições multi-anotador.

Proveniência, linhagem e versionamento (reprodutibilidade e auditabilidade)

A curadoria moderna de conjuntos de dados trata conjuntos de dados como artefatos de software.

O que rastrear

No mínimo, rastreie metadados tanto no nível do conjunto de dados quanto no nível do registro:

  • Identificador de fonte (URL, nome do conjunto de dados, contrato com parceiro)
  • Timestamp de coleta e timestamp de ingestão
  • Tag de licença/termos
  • Etapas de processamento e versões de ferramentas (versão do parser, versão do modelo de filtro)
  • Hashes/impressões digitais (para deduplicação e integridade)
  • Proveniência de anotação (quem/o que rotulou, versão das diretrizes)

Isso permite:

  • Execuções de treinamento reprodutíveis,
  • Auditorias e solicitações de remoção (takedown),
  • Depurar falhas do modelo rastreando a origem dos dados.

Veja Versionamento de Dados e Documentação de Conjuntos de Dados (Datasheets).

Práticas de versionamento que funcionam

  • Camada bruta imutável: armazenar dados originais (quando legalmente permitido) com controles de acesso rígidos.
  • Builds determinísticos: uma versão do conjunto de dados é a saída de um pipeline conhecido + configuração.
  • Versionamento semântico (semantic versioning) para conjuntos de dados (por exemplo, v2.1.0):
    • Major: mudanças no significado do esquema/rótulos
    • Minor: novos dados adicionados
    • Patch: correção de bug no processamento sem mudança semântica intencional
  • Registros de mudanças (changelogs): o que mudou, por quê, impacto esperado.

Exemplo: conceito de “receita de build” do conjunto de dados

Armazene um arquivo de configuração descrevendo o build:

dataset_name: support-assistant-corpus
version: 2.1.0
sources:
  - type: internal_tickets
    date_range: [2025-01-01, 2025-12-31]
    consent: support_terms_v3
filters:
  language: ["en"]
  pii_redaction: true
  safety_filter:
    hate_threshold: 0.8
    sexual_threshold: 0.9
dedupe:
  method: minhash
  threshold: 0.85
splits:
  strategy: time_based
  test_start: 2025-11-01

O objetivo é que alguém consiga reconstruir 2.1.0 e obter o mesmo conjunto de dados (ou entender por que ele difere).

Prevenindo vazamento e contaminação de benchmarks

Vazamento (leakage) acontece quando informações da avaliação aparecem no treinamento, inflando métricas e reduzindo a confiança.

Modos comuns de vazamento:

  • Exemplos exatos/quase-duplicados entre treino/teste
  • Usuários ou sessões compartilhados entre partições (vazamento em nível de usuário)
  • Vazamento temporal (dados do futuro no treino, passado no teste)
  • Treinar em conjuntos de teste de benchmark (especialmente em corpora da web)

Mitigações práticas:

  • Deduplicar entre partições usando impressões digitais robustas.
  • Usar partições baseadas em tempo (time-based splits) para dados de produto.
  • Usar partições agrupadas (grouped splits) (por exemplo, por usuário/cliente/conta).
  • Manter listas de bloqueio (blocklists) de conteúdo de benchmark e conjuntos de avaliação conhecidos.
  • Executar periodicamente “varreduras de contaminação (contamination scans)” contra suas suítes de avaliação.

O controle de vazamento é parte central de uma avaliação confiável e se conecta a Qualidade de Dados e Deriva.

Mantendo conjuntos de dados curados ao longo do tempo

Conjuntos de dados são ativos vivos. Manutenção inclui:

  • Atualizações incrementais: adicionar novos dados sem quebrar a reprodutibilidade
  • Gestão de deriva: conforme comportamento do usuário e linguagem evoluem
  • Atualizações de política: novos requisitos de segurança podem exigir re-filtragem
  • Remoções e correções: remover registros por solicitações legais/de privacidade
  • Descontinuação: aposentar versões antigas usadas no treinamento em produção

Operacionalmente, equipes maduras implementam:

  • Rebuilds agendados (mensal/trimestral)
  • Monitoramento contínuo para regressões de qualidade de dados
  • Revisões de governança para mudanças de alto impacto (veja Governança de Dados)
  • Padrões seguros de retenção e acesso (veja Segurança de Dados)

Armadilhas comuns e como evitá-las

  • Otimizar apenas por tamanho: mais dados nem sempre é melhor; volume de baixa qualidade pode prejudicar modelos.
  • Curadoria “de uma vez só”: sem versionamento e registros de mudanças, você não consegue depurar regressões.
  • Colapso oculto de subgrupos: filtros treinados em idioma/dialetos majoritários podem apagar variedades minoritárias.
  • Deduplicação excessiva: remover sinais legítimos de frequência pode prejudicar ranking e predição de intenção.
  • Licenças não documentadas: misturar fontes com termos incompatíveis cria risco legal a jusante.
  • Ignorar ciclos de realimentação: saídas do modelo podem reentrar nos dados de treinamento e amplificar erros (especialmente em sistemas generativos).

Um fluxo de trabalho prático de curadoria ponta a ponta (exemplo)

Imagine que você quer um conjunto de dados para ajustar finamente (fine-tune) um chatbot de suporte para um produto SaaS.

  1. Definir escopo

    • Apenas inglês, últimos 12 meses
    • Tarefas: troubleshooting + FAQs de cobrança
    • Deve redigir PII; não deve incluir segredos internos

  2. Selecionar fontes

    • Tickets de suporte resolvidos (dados primários)
    • Artigos públicos da central de ajuda (conteúdo próprio)
    • Excluir posts de fórum da comunidade (alta toxicidade + consentimento pouco claro)

  3. Ingerir e normalizar

    • Converter tickets para um esquema consistente: {ticket_id, user_message, agent_reply, timestamp, product_area}
    • Normalizar HTML → texto para artigos de ajuda

  4. Limpar

    • Remover assinaturas e boilerplate (“Sent from my iPhone”)
    • Remover registros corrompidos

  5. Redigir informações sensíveis

    • Mascarar e-mails, números de telefone, IDs de conta
    • Armazenar tickets brutos em um bucket restrito; treinar apenas com texto redigido

  6. Deduplicar

    • Deduplicação exata por hash
    • Deduplicação aproximada para remover duplicatas de templates (macros de “reset password”)

  7. Filtrar

    • Remover tickets contendo segredos (chaves de API) via varredura por padrões
    • Remover conteúdo abusivo acima de um limiar (mas manter parte para treinamento de recusa, se a política exigir)

  8. Balancear

    • Garantir que problemas de cobrança estejam suficientemente representados em treino e teste
    • Manter uma distribuição realista em um conjunto de avaliação separado de “frequência natural”

  9. Particionar

    • Partição baseada em tempo: último mês como teste
    • Agrupar por cliente para evitar vazamento entre clientes

  10. Documentar + versionar

  • Criar um datasheet: uso pretendido, exclusões, método de redação, pontos cegos conhecidos
  • Publicar v1.0.0; atualizações posteriores viram v1.1.0, etc.

Checklist de curadoria (referência rápida)

  • Fontes
    • Licença/termos registrados por fonte
    • Representatividade avaliada; lacunas identificadas
  • Processamento
    • Normalização e esquema validados
    • Deduplicação (incluindo entre partições) implementada e medida
    • Filtros auditados quanto a impacto em subgrupos
  • Segurança e privacidade
    • Política de dados sensíveis definida; tratamento de PII testado
    • Controles de acesso, retenção e logging estabelecidos
  • Qualidade e avaliação
    • Verificações de vazamento executadas
    • Métricas de cobertura acompanhadas (domínio/idioma/classe)
  • Reprodutibilidade
    • Conjunto de dados versionado com uma receita de build + registro de mudanças
    • Documentação publicada (datasheet)

Resumo

A curadoria de conjuntos de dados é uma competência fundamental em aprendizado de máquina: ela transforma entradas brutas, bagunçadas e arriscadas em conjuntos de dados úteis, seguros e auditáveis. Os melhores curadores tratam conjuntos de dados como produtos em evolução — construídos com pipelines reprodutíveis, validados com métricas de qualidade e cobertura, filtrados com atenção cuidadosa a vieses e governados com controles fortes de privacidade e legais. Quando bem feita, a curadoria melhora o desempenho e a confiabilidade do modelo, ao mesmo tempo em que reduz risco operacional e legal.