Git costuma ser o primeiro lugar onde um projeto de inteligência artificial guarda tudo. Código, configuração, uma planilha de exemplos e, quando alguém percebe, vários gigabytes de imagens ou textos. O problema não aparece no primeiro commit. Ele aparece quando o dataset muda toda semana, precisa de versões e começa a deixar cada operação lenta e cara.
O guia publicado no Hugging Face Blog parte de uma distinção simples: código e dados obedecem a ritmos diferentes. Um arquivo de código geralmente é pequeno, pode ser comparado linha a linha e precisa acompanhar cada alteração feita pela equipe. Um dataset pode crescer muito, conter arquivos binários e exigir cópias completas ou quase completas a cada versão. Tratar os dois como se fossem a mesma coisa cria um repositório difícil de clonar e difícil de manter.
Por que o Git começa a sofrer com datasets
O Git guarda o histórico das mudanças. Isso é ótimo quando a mudança é uma linha de código ou um arquivo de configuração. Em imagens, áudios, vídeos e grandes arquivos tabulares, a comparação deixa de ser útil e o repositório passa a carregar versões antigas que quase ninguém consulta. Mesmo depois de apagar um arquivo da pasta atual, ele pode continuar ocupando espaço no histórico.
Há outro efeito prático: cada pessoa nova na equipe precisa baixar uma quantidade de dados que talvez nem use. O clone inicial demora mais, os pulls ficam pesados e os ambientes de CI gastam tempo e armazenamento. Para quem está estudando, esse atrito aparece antes mesmo do primeiro experimento. Para a equipe, ele vira uma cobrança recorrente de infraestrutura.
O Git LFS resolve parte do problema ao manter ponteiros no repositório e arquivos grandes fora dele. Ainda assim, ele não transforma o Git em um catálogo completo de datasets. É preciso pensar em permissões, custos, retenção, nomes de versões e no local onde os arquivos serão armazenados. Um ponteiro quebrado também pode interromper a reprodução de um treinamento.
Uma divisão mais saudável para o projeto
Uma estrutura pequena pode separar quatro coisas: código de preparação, metadados, dados brutos e versões prontas para treino. O código fica no Git. Os metadados registram a origem, o formato, a data de coleta, a licença e o hash do arquivo. Os dados grandes ficam em um armazenamento próprio, com controle de versão ou snapshots identificados.
O conjunto usado por um experimento precisa ser recuperável. Em vez de escrever apenas “treinamento de agosto”, registre um identificador, a versão do dataset e os filtros aplicados. O resultado pode ser um arquivo de manifesto no repositório, apontando para os objetos guardados fora dele. Assim, uma pessoa consegue entender qual código e quais dados formaram aquele resultado sem baixar tudo de uma vez.
Também vale separar dado bruto de dado tratado. O bruto deve permanecer preservado quando a licença permitir. O tratado pode ser recriado por um script versionado. Se uma regra de limpeza mudar, a equipe gera uma nova versão e mantém a anterior para comparação. Isso evita substituir silenciosamente o material usado em um modelo que já foi avaliado.
Como começar sem montar uma plataforma enorme
O primeiro passo é olhar o próximo dataset, não tentar reorganizar toda a empresa. Liste o tamanho dos arquivos, a frequência de alteração e quem precisa acessá-los. Se o conjunto ainda é pequeno e muda pouco, Git pode continuar adequado. Quando arquivos binários começam a dominar o repositório, migre o armazenamento e deixe no Git apenas o código e os manifestos.
Depois, crie uma convenção de nomes e um arquivo de descrição. Inclua a fonte, a licença, o período de coleta, o esquema das colunas, o hash e a versão. Não coloque tokens, senhas ou dados pessoais nesse manifesto. O objetivo é tornar o experimento repetível sem transformar o repositório em um depósito de cópias.
O guia do Hugging Face não oferece uma fórmula única, e esse é um ponto útil. Uma equipe pode usar Git LFS, armazenamento de objetos ou ferramentas próprias para datasets. A escolha depende do tamanho, do orçamento, da necessidade de trabalhar offline e das regras de acesso. O erro é deixar essa decisão para depois de o repositório já estar pesado.
Para revisar o projeto atual, procure arquivos grandes no histórico, confira se o dataset tem licença clara e tente reconstruir um experimento a partir do código e do manifesto. Se ninguém consegue dizer qual versão dos dados foi usada, o problema não é apenas de espaço: é de rastreabilidade. A separação entre código e dados resolve a parte mecânica, mas o registro das decisões é o que mantém o projeto compreensível.
Fonte: Hugging Face Blog, Stop Abusing Git.
