---
title: "Por que podar dados bate modelos 10x maiores?"
author: "Ricardo Pupo Larguesa"
date: "2026-05-05 08:00:00-03"
category: "Papers & Pesquisa"
url: "http://scale.press/portal/aintuicao/post/2026/05/05/por-que-podar-dados-bate-modelos-10x-maiores/md"
---

Na prática do desenvolvimento de software com IA, é comum ver equipes montando pipelines absurdos de auto-correção. O raciocínio padrão virou este: se o modelo principal alucina ou esquece fatos específicos do domínio, colocamos um segundo modelo atuando como "juiz" para validar a saída, ou forçamos o sistema a rodar em um loop iterativo até acertar. O problema é que isso custa tokens, dobra ou triplica a latência e transforma a arquitetura em um castelo de cartas.

Um paper submetido no início deste mês levanta uma questão incômoda sobre essa abordagem. O estudo [Cram Less to Fit More: Training Data Pruning Improves Memorization of Facts](https://arxiv.org/abs/2604.08519), liderado por pesquisadores como Vitaly Feldman e Kunal Talwar, prova matematicamente e empiricamente que estamos simplesmente entupindo as redes neurais com excesso de informação inútil. Em vez de [apostar apenas no aumento irracional de parâmetros](https://scale.press/portal/aintuicao/post/2026/02/24/a-ilusao-da-escala-e-o-retorno-triunfal-da-logica-ia-neuro-simbolica-em-pauta) ou em gambiarras de inferência, os autores atacam o problema na origem: a dieta de dados.

Os pesquisadores formalizam a memorização de fatos e demonstram que existe um limite rígido de capacidade na precisão factual de um modelo. Se você tenta socar mais fatos do que a rede consegue absorver, a performance colapsa. A solução proposta por eles é um esquema de seleção chamado *LossH*, que poda os dados de treinamento com base na perda (loss), limitando o número de fatos expostos e achatando a distribuição de frequência. Você ensina menos coisas, mas garante que o modelo aprenda de verdade o que foi ensinado.

Os resultados são difíceis de ignorar. No experimento usando dados da Wikipedia, um modelo pequeno como o GPT2-Small (com cerca de 110 milhões de parâmetros) treinado via poda de dados igualou a precisão factual do GPT2-Large (1.3 bilhão de parâmetros) treinado da forma tradicional. Eles replicaram o sucesso fazendo fine-tuning via LoRA no Llama-3.2-1B, onde a poda de dados aumentou a precisão na retenção de fatos sem degradar o desempenho em tarefas de raciocínio geral, como o benchmark MMLU.

No meu livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt), exploro como reduzir a ambiguidade na entrada melhora a saída. Mas a mesma lógica de economia se aplica aos pesos internos do modelo. Não adianta desenhar o prompt mais limpo do mundo se a rede neural subjacente sofreu uma indigestão de dados redundantes durante o pré-treinamento ou fine-tuning.

É por isso que, quando assumimos projetos de arquitetura de IA na [T2S](http://t2s.com.br), a primeira briga que compro com o cliente costuma ser pela curadoria do dataset corporativo. A vontade instintiva do gestor é pegar todos os PDFs, históricos de chat e manuais da empresa da última década e jogar dentro de um processo de fine-tuning. Esse paper confirma o que observamos na dor do dia a dia: curadoria deliberada supera volume bruto. E o que constato na prática é que um bom RAG sempre vence o fine tunning.

Se você precisa de respostas precisas e consistentes em produção, gastar recursos filtrando rigorosamente os dados de treino entrega um retorno técnico muito maior do que pendurar agentes juízes no final do seu pipeline. Talvez a pergunta certa para a engenharia de ML atual não seja como fazer a IA pensar duas vezes sobre o que disse, mas sim por que insistimos em fazê-la decorar o que não importa.

Para discutir mais sobre arquitetura de sistemas com IA, MLOps e os bastidores do desenvolvimento, conecte-se comigo: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo).