Documentação de Conjuntos de Dados (Datasheets)

Visão geral

Documentação de conjunto de dados (dataset documentation) — frequentemente chamada de Fichas Técnicas para Conjuntos de Dados (Datasheets for Datasets) — é uma forma estruturada de registrar a proveniência (provenance) de um conjunto de dados (de onde veio e como foi criado), o uso pretendido (intended use) (para que deve e não deve ser usado) e as limitações conhecidas (known limitations) (vieses, lacunas, ruído de rótulo (label noise), restrições legais e modos de falha (failure modes)).

O termo, popularizado por Gebru et al. (“Datasheets for Datasets”, 2018), faz uma analogia com fichas técnicas de eletrônicos (electronics datasheets): se você entrega um componente (um conjunto de dados) que outras pessoas vão integrar a sistemas, você também deve entregar documentação descrevendo como ele se comporta e quais restrições se aplicam.

Na prática moderna de aprendizado de máquina (machine learning), a documentação de conjuntos de dados dá suporte a:

  • Reprodutibilidade (reproducibility): outras pessoas conseguem entender e recriar as entradas de treinamento, não apenas o código do modelo.
  • Gestão de riscos (risk management): trazer à tona riscos de viés, privacidade e licenciamento antes da implantação.
  • Clareza operacional (operational clarity): evitar uso indevido (por exemplo, usar um conjunto de dados construído para pesquisa acadêmica em um produto clínico regulado).
  • Governança e conformidade (governance and compliance): viabilizar revisão, auditorias e aprovações em linha com requisitos organizacionais e legais.

As fichas técnicas são fortemente relacionadas a (e complementares a) Governança de Dados (Data Governance), Versionamento de Dados (Data Versioning), Privacidade (Privacy) e Qualidade de Dados e Deriva (Data Quality & Drift).

Por que a documentação de conjuntos de dados importa

Conjuntos de dados são “infraestrutura” para sistemas de aprendizado de máquina

Muitas falhas em aprendizado de máquina são falhas de dados: exemplos rotulados incorretamente, artefatos de amostragem, vazamento oculto, subcobertura demográfica ou semântica de rótulos pouco clara. Sem documentação, usuários a jusante podem:

  • Assumir que os dados são representativos quando não são
  • Tratar rótulos como “verdade de referência (ground truth)” objetiva quando eles refletem diretrizes subjetivas
  • Ignorar restrições de licenciamento ou consentimento
  • Não perceber peculiaridades conhecidas (por exemplo, imagens com marcas-d’água (watermarks) correlacionadas com rótulos de classe)

Isso se torna especialmente importante para conjuntos de dados usados além de seu contexto original — algo comum em benchmarks abertos (open benchmarks) e plataformas internas de dados.

A documentação reduz “reuso silencioso (silent reuse)” e “acoplamento oculto (hidden coupling)”

Conjuntos de dados evoluem: fontes mudam, políticas de rotulagem se alteram, filtros são adicionados e a desduplicação melhora. Uma ficha técnica torna essas mudanças explícitas e dá suporte a interfaces estáveis entre equipes e ao longo do tempo — semelhante a um contrato de API (API contract).

Isso está fortemente ligado a Pipelines de Dados (ETL/ELT para AM): sem documentação, o comportamento do pipeline vira conhecimento tribal (tribal knowledge).

O que é uma “ficha técnica”?

Uma ficha técnica (datasheet) é um conjunto padronizado de perguntas e respostas que descreve um conjunto de dados ao longo de seu ciclo de vida. Em geral, ela cobre:

  • Motivação: por que existe, quem a criou, qual problema ela atende
  • Composição: quais instâncias estão incluídas, quais campos existem, quais populações/domínios são representados
  • Processo de coleta: fontes de dados, estratégia de amostragem, intervalo de tempo, instrumentos, consentimento
  • Rotulagem: definições de rótulos, instruções para anotadores, concordância entre anotadores (inter-annotator agreement), verificações de garantia de qualidade (QA)
  • Pré-processamento: filtragem, normalização, desduplicação, extração de atributos (feature extraction)
  • Usos recomendados: tarefas apropriadas, restrições, orientação de avaliação
  • Usos fora de escopo: cenários conhecidos de uso indevido
  • Distribuição: formato, método de acesso, licenciamento, política de retenção
  • Manutenção: como as atualizações acontecem, versionamento, pontos de contato
  • Riscos e limitações: viés, ausência de dados, preocupações com privacidade, correlações espúrias (spurious correlations), casos conhecidos de falha

Na prática, muitas organizações implementam fichas técnicas como “cartões de conjunto de dados (dataset cards)” (por exemplo, em catálogos internos ou em ferramentas como Hugging Face). O essencial não é o formato exato, mas a completude e a manutenção.

Relação com outros artefatos de documentação

As fichas técnicas se encaixam em um ecossistema mais amplo de documentação:

  • Cartões de modelo (model cards) descrevem um modelo treinado (desempenho, uso pretendido, limitações). Fichas técnicas descrevem os dados que sustentam treinamento e avaliação. Se o seu wiki tiver, veja Cartões de Modelo (Model Cards).
  • Protocolos de coleta de dados e diretrizes de rotulagem alimentam a ficha técnica; veja Coleta e Rotulagem de Dados.
  • Avaliações de impacto à privacidade (privacy impact assessments) e revisões legais informam seções sobre consentimento e restrições; veja Privacidade e Segurança de Dados.
  • Artigos de benchmark (benchmark papers) frequentemente fornecem documentação parcial do conjunto de dados, mas fichas técnicas buscam um nível de detalhe sistemático e operacional.

Seções centrais de uma boa ficha técnica

1) Motivação e uso pretendido

Esta seção deve responder:

  • Por que o conjunto de dados foi criado?
  • Quem o criou e para quais usuários?
  • Para quais tarefas ele é destinado?
  • Quais são os não objetivos (non-goals)?

Seja explícito quanto ao escopo pretendido. Por exemplo:

  • “Este conjunto de dados é destinado a pesquisa sobre classificação de sentimento em avaliações de produtos em inglês.”
  • “Não é destinado a avaliação de desempenho de funcionários, decisões de crédito ou perfilamento automatizado de alto impacto (high-stakes).”

É aqui que você reduz dano a jusante: muitos casos de uso indevido acontecem porque “era conveniente”, não porque era apropriado.

2) Proveniência e linhagem de dados (data lineage)

A proveniência deve ser concreta o bastante para que alguém consiga verificar a fonte e entender as transformações. Inclua:

  • Sistemas de origem (bancos de dados, sensores, sites, fornecedores)
  • Período de coleta
  • Lógica de consulta / critérios de extração
  • Quaisquer junções entre tabelas ou enriquecimento externo
  • Se o conteúdo foi gerado por usuários, licenciado ou raspado (scraped) (veja Dados da Web e Raspagem (Web Data & Scraping))

Se você mantém versões do conjunto de dados, vincule a proveniência a identificadores de versão (por exemplo, hashes de commit do Git/DVC ou números de versão do catálogo); veja Versionamento de Dados.

3) Composição e esquema (schema)

Descreva o que o conjunto de dados contém:

  • Número de exemplos (total e por partição: treino/val/teste)
  • Definições de atributos/campos e unidades
  • Espaço de rótulos e definições
  • Padrões de ausência de dados
  • Duplicatas conhecidas ou quase duplicatas
  • Para conjuntos de dados multimodais (multimodal datasets): modalidades, estratégia de alinhamento e sincronização; veja Conjuntos de Dados Multimodais

Para conjuntos de dados tabulares, inclua a clareza de um “dicionário de dados (data dictionary)”:

  • Significado da coluna
  • Valores permitidos
  • Unidades de medida
  • Semântica de “desconhecido” vs “ausente”

4) Processo de coleta e amostragem

Documente como os itens foram selecionados:

  • Universo de amostragem (sampling frame) (o que poderia ter sido amostrado)
  • Critérios de inclusão/exclusão
  • Método de amostragem (aleatória, estratificada, amostra por conveniência)
  • Vieses conhecidos (por exemplo, geografia, tipo de dispositivo, variedade linguística)
  • Detalhes de instrumentação (especificações do sensor, versão do código de logging)

Um modo de falha comum é confundir populações registradas (logged) com populações alvo (por exemplo, “usuários que habilitaram telemetria” ≠ “todos os usuários”).

5) Detalhes de rotulagem e anotação

Para aprendizado de máquina supervisionado (supervised ML), a qualidade dos rótulos frequentemente é o fator limitante. Inclua:

  • Quem rotulou os dados (especialistas, trabalhadores de crowd, usuários, heurísticas automatizadas)
  • Diretrizes de anotação e treinamento
  • Se a rotulagem foi de uma passagem ou de múltiplas passagens
  • Concordância entre anotadores e resolução de divergências (por exemplo, κ de Cohen)
  • Processos de QA (perguntas ouro, auditorias, verificações por amostragem)
  • Ambiguidades conhecidas nos rótulos

Se os rótulos foram produzidos automaticamente (supervisão fraca (weak supervision)), documente as regras heurísticas e o perfil de ruído esperado.

6) Pré-processamento e extração de atributos

Liste transformações que afetam materialmente o significado:

  • Normalização de texto, decisões de tokenização (tokenization)
  • Redimensionamento/corte de imagens e conversões de espaço de cor
  • Reamostragem de áudio, recorte (clipping)
  • Regras de filtragem (por exemplo, remover textos curtos, filtro de palavrões)
  • Métodos de desduplicação (deduplication) (hash exato vs similaridade aproximada)
  • Aumento de dados (data augmentation) (se incorporado ao conjunto de dados em vez de feito no treinamento)

O pré-processamento pode incorporar viés (por exemplo, filtrar imagens de “baixa qualidade” que remove desproporcionalmente condições de iluminação mais escuras).

7) Limitações conhecidas, riscos e viés

Esta é a seção mais importante para uso responsável. Documente:

  • Grupos sub-representados, classes raras, comportamento de cauda
  • Viés de medição (rótulos refletem escolhas de política ou julgamentos subjetivos)
  • Viés histórico (dados espelham desigualdades passadas)
  • Correlações espúrias (por exemplo, cor de fundo correlaciona com a classe)
  • Riscos de privacidade (reidentificação (re-identification), atributos sensíveis)
  • Riscos de vazamento de dados (data leakage) (por exemplo, duplicatas entre partições, vazamento temporal)

Sempre que possível, quantifique limitações:

  • Métricas de desbalanceamento de classes (class imbalance)
  • Cobertura por recortes-chave
  • Taxas de erro em auditorias anotadas
  • Casos conhecidos de falha descobertos na avaliação

Essas limitações devem se conectar a Qualidade de Dados e Deriva: se o conjunto de dados será atualizado, registre qual deriva é esperada e qual monitoramento (monitoring) existe.

8) Distribuição, licenciamento e controles de acesso (access controls)

Inclua:

  • Termos de licença (por exemplo, CC-BY, CC-BY-NC, licença corporativa customizada)
  • Restrições (sem uso comercial, sem redistribuição, exigências de atribuição)
  • Processo de acesso (download público, solicitação interna, acesso com restrição)
  • Políticas de retenção e exclusão de dados
  • Controles de segurança, especialmente para dados sensíveis; veja Segurança de Dados

Restrições de licenciamento e consentimento devem estar explícitas em “uso pretendido” e “usos fora de escopo”.

9) Manutenção e ciclo de vida

Conjuntos de dados raramente estão “prontos”. Inclua:

  • Proprietário/curador (caixa de e-mail do time, caminho de escalonamento)
  • Frequência de atualização e gatilhos
  • Política de versionamento (versionamento semântico (semantic versioning) para conjuntos de dados é comum)
  • Política de descontinuação (deprecation) (por quanto tempo versões antigas permanecem disponíveis)
  • Expectativas de registro de mudanças (change log)

Isso se conecta diretamente a Governança de Dados: a documentação deve indicar quem pode aprovar mudanças e como decisões são registradas.

Exemplo prático: uma mini ficha técnica (classificação de texto)

Abaixo está uma ficha técnica condensada para um conjunto de dados interno de tickets de suporte ao cliente. Na prática, você expandiria as seções e anexaria links de apoio (consultas, guias de rotulagem, relatórios de auditoria).

dataset_name: "SupportTickets-Sentiment-v1.2"
created_by: "Customer Insights ML Team"
date_created: "2025-03-10"
contact: "ml-data-stewards@company.example"

motivation:
  purpose: "Train sentiment classifiers to route support tickets."
  intended_users: ["Internal ML engineers", "CX analytics"]
  intended_uses:
    - "Sentiment classification (negative/neutral/positive) for triage"
  out_of_scope_uses:
    - "Employee evaluation"
    - "Automated account sanctions"

provenance:
  sources:
    - system: "Zendesk"
      extraction_query: "link-to-sql-or-notebook"
      time_range: "2024-01-01 to 2024-12-31"
  pii_handling:
    - "Names/emails removed via regex + entity recognition"
    - "Free-form text may still contain residual PII"

composition:
  num_examples: 480000
  language: ["en-US primarily"]
  fields:
    - name: "ticket_text"
      type: "string"
      description: "User-submitted ticket body after templated signatures removed"
    - name: "sentiment"
      type: "categorical"
      values: ["negative", "neutral", "positive"]
  splits:
    method: "time-based"
    train: "2024-01 to 2024-10"
    val: "2024-11"
    test: "2024-12"

labeling:
  method: "Crowd annotation + expert audit"
  guidelines: "link-to-guidelines"
  annotators_per_item: 3
  agreement:
    metric: "Cohen_kappa"
    value: 0.71
  known_ambiguities:
    - "Sarcasm often mislabeled as positive"

preprocessing:
  - "Removed templated greetings/signatures"
  - "Truncated to 2048 characters"
  - "Deduplicated exact matches by SHA256(ticket_text)"

known_limitations:
  - "Overrepresents paid subscribers; free tier under-sampled"
  - "Contains domain-specific jargon; general sentiment models may not transfer"
  - "Residual PII risk in text; not approved for open release"

distribution:
  access: "internal://data-catalog/supporttickets-sentiment"
  license: "Internal use only"
  retention: "18 months rolling"

maintenance:
  update_frequency: "quarterly"
  versioning: "minor version for new data; major for label schema changes"
  changelog: "internal://data-catalog/supporttickets-sentiment/changelog"

Mesmo esta versão curta esclarece partições baseadas em tempo (time-based splits) (evitando vazamento), risco residual de privacidade e restrições contra uso indevido.

Exemplo prático: documentando uma armadilha em um conjunto de dados de visão computacional

Imagine um conjunto de dados para “detecção de capacete” em canteiros de obras. Um problema oculto comum é o vazamento de contexto (context leakage):

  • Imagens “sem capacete” foram coletadas principalmente de câmeras antigas em um local.
  • Imagens “com capacete” foram coletadas em um local diferente, com iluminação e fundos diferentes.

Um modelo pode aprender pistas de fundo/local, em vez de capacetes.

Uma boa ficha técnica observaria explicitamente:

  • Locais/câmeras usados por classe
  • Datas de coleta e dispositivos
  • Quaisquer verificações de correlação realizadas (por exemplo, informação mútua (mutual information) entre local e rótulo)
  • Medidas de mitigação (rebalanceamento, coleta de contraexemplos (counterexamples), partições estratificadas por local (site-stratified splits))

Este é um exemplo clássico de como limitações conhecidas previnem alegações incorretas como “funciona em todos os locais”.

Como fichas técnicas apoiam fluxos de trabalho reais de aprendizado de máquina

Seleção e reuso de conjuntos de dados

Em organizações, equipes frequentemente escolhem conjuntos de dados a partir de um catálogo. Sem fichas técnicas, elas podem escolher apenas por conveniência ou pelo nome. Com fichas técnicas, conseguem responder rapidamente:

  • Este conjunto de dados é legalmente utilizável no meu produto?
  • Ele representa minha população-alvo?
  • Os rótulos são definidos da forma que eu preciso?
  • Quão antigos são os dados e como eles são atualizados?

Treinamento, avaliação e depuração

Quando um modelo tem desempenho abaixo do esperado em uma fatia (slice), fichas técnicas ajudam a diagnosticar se é um problema de modelagem ou uma limitação de dados:

  • A fatia pode estar sub-representada.
  • A definição de rótulo pode ser inconsistente para aquela fatia.
  • O pré-processamento pode remover sinais importantes (por exemplo, remover pontuação que codifica sentimento).

Isso complementa abordagens de monitoramento descritas em Qualidade de Dados e Deriva.

Conformidade e revisão

Em contextos regulados ou de alto impacto, fichas técnicas funcionam como evidência de que riscos de dados foram identificados e mitigados. Elas também simplificam a coordenação entre revisores jurídicos, de privacidade e de segurança (veja Privacidade e Segurança de Dados).

Padrões de implementação: como operacionalizar fichas técnicas

“Ficha técnica mínima viável (minimum viable datasheet)” vs. ficha técnica completa

Uma abordagem pragmática é exigir um conjunto mínimo de campos para todo conjunto de dados e expandir ao longo do tempo.

Campos mínimos viáveis:

  • Proprietário/contato
  • Objetivo e uso pretendido
  • Fonte(s) de dados + intervalo de tempo
  • Definições de esquema/rótulos
  • Principais limitações e riscos conhecidos
  • Restrições de licença/acesso
  • Identificador de versão e data da última atualização

Ficha técnica completa adiciona:

  • Metodologia detalhada de amostragem
  • Processo de anotação e QA
  • Análises quantitativas de viés/cobertura
  • Resultados de auditoria e casos conhecidos de falha
  • Plano de manutenção e política de descontinuação

Trate a documentação como um artefato vivo

Fichas técnicas devem ser atualizadas quando:

  • O conjunto de dados é atualizado
  • Definições de rótulo mudam
  • Novas limitações são descobertas (por exemplo, uma análise de viés revela uma lacuna)
  • Termos de acesso/licenciamento mudam
  • Ocorre um incidente grave (por exemplo, vazamento de privacidade ou uso indevido)

Isso se encaixa naturalmente com Versionamento de Dados: cada versão liberada do conjunto de dados deve referenciar uma versão da ficha técnica (ou incorporá-la nos metadados da liberação).

Integração de ferramentas (tooling integration)

Formas comuns de armazenar e impor fichas técnicas:

  • Em um catálogo de dados (portal interno)
  • Como DATASHEET.md no repositório do conjunto de dados
  • Como metadados estruturados (YAML/JSON) validados na integração contínua (CI)
  • Como parte das saídas do pipeline (estatísticas auto-geradas + narrativa escrita por humanos)

Um padrão útil é a documentação híbrida (hybrid documentation):

  • Auto-gerada: contagem de linhas, ausência de dados, estatísticas básicas por fatia, esquema
  • Escrito por humanos: intenção, considerações éticas, limitações, semântica de rotulagem

Armadilhas comuns e como evitá-las

Armadilha 1: Declarações vagas (“pode conter viés”)

Substitua avisos vagos por achados específicos e acionáveis:

  • Quais grupos estão sub-representados?
  • Como a representação foi medida?
  • Quais tarefas provavelmente vão falhar por causa disso?

Armadilha 2: Ausência de uma seção de “usos fora de escopo”

Equipes costumam pular isso, mas é uma das salvaguardas mais eficazes. Se um conjunto de dados não deve ser usado para certas decisões, diga isso explicitamente.

Armadilha 3: Documentação não vinculada a versões

Uma ficha técnica que não especifica a versão do conjunto de dados pode se tornar enganosa. Sempre inclua:

  • Versão do conjunto de dados
  • Data em que foi gerado/publicado
  • Link para o registro de mudanças

Armadilha 4: Ignorar pré-processamento e filtragem

Regras de filtragem podem ter efeitos grandes e ocultos. Registre-as, especialmente tudo que remove dados (não apenas transformações).

Armadilha 5: Sem propriedade ou plano de manutenção

Se ninguém for dono da ficha técnica, ela vai deteriorar. Designe um responsável e defina o gatilho de atualização.

Checklist recomendado para autores e revisores

Ao criar ou revisar uma ficha técnica, verifique se ela responde:

  • Consigo dizer de onde os dados vieram e como foram selecionados?
  • Consigo dizer o que cada campo e rótulo significa operacionalmente?
  • Consigo dizer para que deve e não deve ser usado?
  • Consigo identificar riscos-chave (viés, vazamento, privacidade, licenciamento)?
  • Consigo reproduzir a versão do conjunto de dados usada no treinamento?
  • Eu sei com quem falar e como atualizações acontecem?

Se alguma resposta for “não”, o conjunto de dados provavelmente será usado de forma indevida ou interpretado incorretamente.

Conexões com práticas adjacentes de dados

Fichas técnicas se tornam muito mais poderosas quando combinadas com:

Resumo

A documentação de conjuntos de dados (fichas técnicas) transforma conjuntos de dados de artefatos opacos em componentes bem especificados: é possível entender sua origem, uso pretendido e limitações antes de construir modelos sobre eles. Na prática, fichas técnicas reduzem uso indevido, melhoram a reprodutibilidade, aceleram a depuração e apoiam governança e conformidade. As fichas técnicas mais eficazes são específicas, versionadas e mantidas — um registro vivo que evolui junto com o conjunto de dados e com os sistemas construídos a partir dele.