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, 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 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, 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, 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.