Antes de treinar um modelo, o corpus precisa ser parseado, limpo, deduplicado, pontuado, tokenizado e montado em amostras. Em escala de petabytes, os engenheiros de dados não enfrentam apenas contas de computação (que continua se concentrando nos gigantes da nuvem) — eles se afogam em centenas de tabelas, conjuntos de features em crescimento constante e algumas poucas linhas ruins que podem forçar o reprocessamento de um lote inteiro.
O OmniTable, da Ant Group — vencedor de melhor paper da trilha industrial no VLDB 2026 — ataca a etapa mais negligenciada do pipeline de LLM: a preparação de dados. Em produção, ele gerencia mais de 35 PB e 305 bilhões de linhas de dados de treinamento nos domínios de web, código, PDF e SFT (os dados de treinamento estão se tornando um ativo essencial de iteração para self-play). Em uma tarefa real de preparação de SFT, o ciclo ponta a ponta caiu de cerca de 14 dias para 2,5, e as etapas manuais caíram de 45 para 12.
O resultado não veio de uma máquina mais rápida. O OmniTable muda a forma como os engenheiros organizam dados e features: um domínio de dados aparece como uma única tabela larga lógica na camada superior, enquanto por baixo ele permanece dividido por escala, padrão de acesso e motor de computação. Features deixam de ser cálculos improvisados dentro de scripts e passam a ser ativos do sistema, com definições, versões, dependências e linhagem.
Por que uma única feature pode arrastar 106 tabelas
O processamento tradicional de dados para LLM é construído em torno de tabelas físicas. Os resultados do parsing vão para uma tabela, a limpeza para outra; pontuações de qualidade, rótulos de domínio, assinaturas de deduplicação e marcadores de segurança geram cada um novas tabelas ou intermediários. Web, código, PDF e SFT cada um roda seu próprio pipeline. Ao adicionar features, a superfície de manutenção explode: para incluir uma única feature de qualidade, os engenheiros precisavam mexer em 106 tabelas em um canvas de tarefas.
Pior: as tabelas armazenam apenas resultados, não como esses resultados foram calculados. As UDFs vivem espalhadas em vários codebases, com vínculos frágeis entre colunas de entrada, versões de operadores, lotes de execução e tarefas de treinamento downstream. Rastrear uma amostra anômala significa saltar entre tabelas e scripts; uma mudança de versão de uma feature força as equipes a decidir quais lotes históricos precisam ser recalculados.
O OmniTable enquadra isso como três custos de engenharia: dados difíceis de localizar, features difíceis de retroalimentar e resultados difíceis de rastrear. Sua jogada de design é direta — promover lotes de dados e colunas de features a objetos de primeira classe, e rebaixar as tabelas físicas a um detalhe de implementação da camada de armazenamento.
Unificação lógica, separação física
O princípio central é “logicamente unificado, fisicamente separado”. Na camada lógica, cada linha é uma entidade de dados rastreável e cada coluna carrega um estado de estágio de processamento ou uma feature derivada. RawData, ProcessedData e TrainableData mapeiam para as formas bruta, intermediária e pronta para treinamento, com colunas de qualidade, domínio, segurança e deduplicação adicionadas conforme necessário. Um domínio, uma visão lógica.
Essa é a mesma jogada que os sistemas de banco de dados fizeram décadas atrás: separar o schema sobre o qual se raciocina do armazenamento que o serve. A engenharia de dados para LLM está finalmente ganhando o equivalente — uma camada de schema sobre uma bagunça física caótica.
Por que isso importa além de uma empresa
A capacidade dos modelos está cada vez mais limitada não pela arquitetura, mas pela disciplina com os dados. Todo laboratório de fronteira hoje roda o mesmo loop de treinamento; o diferencial está em quão limpos, rastreáveis e reproduzíveis são os dados por trás dele — a mesma evolução guiada pela qualidade dos dados que transformou a IA de proteínas. O OmniTable é um sinal de que a camada de engenharia de dados da IA está amadurecendo em uma disciplina de engenharia de primeira classe, com ferramentas reais, abstrações reais e números de desempenho reais.
Se você opera qualquer pipeline sério de treinamento ou fine-tuning, a lição é transferível: trate as features como ativos versionados e com rastreamento de linhagem, em vez de detalhes improvisados em scripts; dê a cada linha uma identidade; e mantenha uma visão lógica limpa por cima de qualquer bagunça física que exista por baixo.
