Limpar dados de treino sem reescrevê-los: o framework que ensina um editor a só apontar o que mudar

Antes de um modelo de linguagem aprender qualquer coisa, alguém decidiu o que ele vai ler. Essa decisão — que trechos de um corpus bruto da internet entram no pré-treino e em que forma — é um dos elos menos discutidos e mais determinantes da cadeia. O UltraX, publicado pela OpenBMB (consórcio que reúne Universidade de Pequim, ModelBest, Tsinghua e Shanghai Jiao Tong), ataca esse elo com uma ideia simples: em vez de decidir manter ou descartar um documento inteiro, ou reescrevê-lo do zero com um LLM grande, treinar um modelo pequeno para apontar exatamente que linhas mudar — e como.

O dilema que já existia

Refinar dados de pré-treino em larga escala tinha, até aqui, duas famílias de solução, ambas com um problema estrutural. Filtros baseados em regras — descartar documentos com muito HTML residual, muita repetição, poucas palavras reais — são rápidos, mas rígidos: a mesma regra se aplica a milhões de documentos diferentes, ignorando variação caso a caso. Reescrita ponta a ponta com um LLM grande resolve esse problema de rigidez, mas troca por outro: custo computacional alto, risco de o modelo "alucinar" conteúdo que não estava no texto original, e fragmentação semântica quando documentos longos precisam ser cortados em pedaços para caber na janela de contexto do reescritor.

Como o UltraX evita as duas armadilhas

A solução tem duas etapas. Na primeira, um LLM especializado gera, para uma amostra de textos, pares de "antes e depois" de alta qualidade — um mapeamento cuidadoso entre o texto bruto e sua versão refinada, linha por linha (a técnica que os autores chamam de Line Alignment Mapping). Esses pares viram dados de treino para um modelo refinador leve, que aprende não a reescrever, mas a prever uma sequência de operações estruturadas: manter tudo, remover tudo, apagar linhas específicas, substituir uma string, ou inserir uma linha nova.

Na segunda etapa, esse modelo pequeno roda sobre o corpus inteiro — bilhões de tokens —, prevendo operações em janelas deslizantes, que são agregadas, validadas e aplicadas por um executor determinístico. O resultado é o melhor dos dois mundos: decisões sensíveis ao caso específico de cada documento, mas com o custo computacional de rodar um modelo pequeno em vez de um grande, e sem o risco de invenção que vem de deixar um LLM reescrever texto livremente.

Por que "menos tokens, mesmo resultado" importa mais que o número em si

O ganho de qualidade — cerca de 1 a 2 pontos percentuais em benchmarks padrão — não é, isoladamente, dramático. O que muda o cálculo é a eficiência: atingir com 16 bilhões de tokens o que dado bruto precisa de 20 bilhões para alcançar significa treinar modelos comparáveis com 20% menos dado processado, o que se traduz diretamente em menos tempo de GPU e menos energia gasta — um problema que cresce junto com o tamanho dos modelos, não diminui.

Há também um efeito qualitativo por corpus: em fontes já mais ruidosas, como RedPajama-v2 e AICC, o UltraX removeu proporcionalmente mais conteúdo problemático (redução de até 33% em AICC) que em fontes já mais limpas, como Ultra-FineWeb (redução de menos de 4%) — sinal de que o modelo está de fato discriminando qualidade caso a caso, não aplicando um corte uniforme.

Os limites do experimento

Os resultados foram validados com modelos de cerca de 1 bilhão de parâmetros treinados do zero — uma escala útil para testar a hipótese rapidamente, mas pequena diante dos modelos de produção que rodam em dezenas ou centenas de bilhões de parâmetros. Se os ganhos se sustentam nessa escala maior, onde cada ponto percentual de qualidade custa ordens de magnitude mais para conquistar por outros meios, ainda não foi demonstrado publicamente.

O que fica

O UltraX não promete um salto de capacidade — promete tirar mais proveito do dado que já existe, uma área que recebe muito menos atenção pública que arquitetura de modelo ou escala de parâmetros, mas que decide silenciosamente boa parte do que um modelo "sabe" antes mesmo do primeiro passo de treino. É um lembrete oportuno num momento em que a conversa sobre IA gira quase inteira em torno de parâmetros e benchmarks: parte do próximo ganho de eficiência pode estar em editar melhor o que já se tem, não em treinar em mais.

Perguntas Frequentes

O que é refinamento de dados de pré-treino?

É o processo de melhorar a qualidade dos textos brutos coletados da internet antes de usá-los para treinar um modelo de linguagem — removendo ruído, boilerplate (código HTML residual, menus repetidos) e conteúdo de baixa qualidade, sem descartar informação relevante junto.

Por que não simplesmente usar um LLM grande para reescrever tudo?

Porque reescrever bilhões de tokens com um LLM grande é caro computacionalmente, arrisca introduzir alucinações (conteúdo inventado que não estava no original) e força a fragmentação de documentos longos em pedaços menores para caber na janela de contexto do modelo, o que quebra coerência textual.

O modelo refinador do UltraX é o mesmo que faz o pré-treino final?

Não. O modelo refinador (0,6B de parâmetros na versão preview) só decide e aplica as edições no corpus de treino. O modelo final, que efetivamente aprende linguagem a partir desses dados já refinados, é treinado depois, separadamente — no experimento do paper, modelos de cerca de 1B de parâmetros.