Desduplicação de Dados em Escala de Trilhões: Como Resolver o Maior Gargalo do Treinamento de LLMs
A corrida de escalonamento dos LLMs — e seu custo invisível
Os LLMs transformaram praticamente todas as facetas da IA moderna, abrindo novas fronteiras em geração de conteúdo, desenvolvimento de software, raciocínio e uso autônomo de ferramentas. E suas capacidades não mostram sinais de desaceleração.
Veja os anúncios mais recentes: Grok 4 da X.ai e Kimi K2 da Moonshot introduzem capacidades de raciocínio mais fortes, melhor uso de ferramentas e geração mais coerente — tudo impulsionado por corpora de treinamento significativamente maiores e mais diversos.
A tendência é clara: a fronteira da capacidade está sendo impulsionada por treinamento em uma escala sem precedentes. Considere as pegadas de dados de modelos recentes:
| Modelo | Lançamento | Parâmetros | Dados de treinamento |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 trilhões de tokens |
| Grok 4 | 2025 | ~175B | 100x mais que o Grok 2, provavelmente em escala de trilhões |
| GPT-4 | 2023 | 1,8T (est.) | 13 trilhões de tokens |
| LLaMA 3.1 | 2024 | 405B | 15 trilhões de tokens |
O Kimi K2, por exemplo, triplicou o tamanho de seu conjunto de dados em apenas seis meses — uma taxa de crescimento que quase supera a expansão da internet. Com 15,5 trilhões de tokens, ele é maior que o conteúdo acumulado de todas as grandes bibliotecas globais, muitas vezes.
Mas, enterrada nesse crescimento, há uma suposição de que mais dados sempre equivalem a melhor desempenho. Na prática, os ganhos marginais de simplesmente adicionar mais tokens estão diminuindo e sendo cada vez mais limitados pela qualidade dos dados.
Isso nos leva ao primeiro — e talvez mais subestimado — gargalo no treinamento moderno de LLMs: duplicação de dados.
Deduplicação de dados: por que ela importa para o treinamento de LLMs
Os conjuntos de dados modernos de pré-treinamento de LLMs são obtidos principalmente de rastreamentos da web em larga escala, repositórios abertos, corpora públicos e documentos específicos de domínio extraídos da web. À medida que esses pipelines crescem, a redundância se torna não apenas comum, mas sistêmica.
Documentos com pequenas variações (por exemplo, mudanças de formatação, rodapés, cabeçalhos padronizados) reaparecem em diferentes domínios. Páginas populares são espelhadas, traduzidas ou republicadas em outros sites. Bases de código e artigos de conhecimento são duplicados em fóruns, wikis e snapshots arquivados. Até fontes estruturadas, como a Wikipedia, apresentam repetição em trilhas de links e espelhos.
Quando esse conteúdo duplicado flui sem controle para os conjuntos de treinamento, as consequências são significativas:
Ineficiência computacional: exemplos repetidos não fornecem nenhuma informação nova, mas consomem os mesmos recursos computacionais.
Risco de overfitting: LLMs expostos a frases, estruturas ou padrões de conteúdo repetidos podem se tornar excessivamente dependentes desses padrões, reduzindo assim suas capacidades de generalização.
Memorização literal: alta duplicação aumenta o risco de os modelos memorizarem sequências específicas, levantando preocupações de segurança, privacidade e PI.
Vazamento na avaliação: se existirem duplicatas entre os conjuntos de treinamento e validação/teste, as pontuações de benchmark podem ser infladas artificialmente, fornecendo uma impressão enganosa da qualidade do modelo.
Em resumo, a duplicação não é apenas um incômodo. É um problema existencial para execuções de treinamento em alta escala e alto custo.
Um de nossos clientes corporativos — um provedor de LLMs de primeira linha — encontrou exatamente esse problema. Eles precisavam deduplicar dezenas de bilhões de documentos antes de serem ingeridos. Ferramentas de correspondência por hash exato não capturavam quase-duplicatas. Modelos semânticos eram caros demais para executar em escala. E pilhas tradicionais de limpeza de dados simplesmente não conseguiam atender às suas restrições de tempo e recursos.
Este é o contexto em que a deduplicação se tornou infraestrutura de missão crítica, não uma reflexão posterior de pré-processamento.
Uma visão geral das técnicas de deduplicação
Existem três estratégias dominantes para deduplicação em escala, cada uma com compensações em termos de precisão, custo e viabilidade.
Correspondência Exata: Usa hashing criptográfico para encontrar documentos idênticos. Rápida e precisa, mas não detecta quase duplicatas com pequenas diferenças de formatação.
Correspondência Semântica: Aproveita modelos de embedding vetorial para encontrar conteúdo conceitualmente semelhante. Altamente precisa, mas computacionalmente cara em escala.
Correspondência Aproximada: Encontra quase duplicatas usando algoritmos probabilísticos como MinHash LSH e similaridade de Jaccard. Equilibra precisão com eficiência computacional—perfeita para conjuntos de dados de trilhões de tokens.
Com corpora de pré-treinamento atingindo terabytes ou até petabytes, métodos tradicionais de correspondência exata, como comparações par a par, são computacionalmente inviáveis. A deduplicação semântica adiciona uma sobrecarga significativa ao usar modelos de embedding para gerar vetores.
Precisamos de métodos aproximados mais inovadores—como MinHash LSH—que equilibrem recall e precisão enquanto mantêm os custos gerenciáveis, tornando a deduplicação em larga escala prática.
MinHash LSH: Detectando Quase Duplicatas em Conjuntos de Dados em Escala de Trilhões
No contexto do treinamento de LLMs em larga escala, a deduplicação eficiente requer um algoritmo de correspondência que não seja apenas preciso, mas computacionalmente viável na escala de dezenas de bilhões de documentos. MinHash LSH (Locality Sensitive Hashing) foi criado especificamente para exatamente esse tipo de cenário.
MinHash: Estimativa de Similaridade Escalável
MinHash é uma técnica probabilística projetada para estimar a similaridade de Jaccard entre conjuntos, sem calcular interseções explícitas par a par. No contexto da deduplicação de documentos, ele atua como um mecanismo de compressão com perdas que preserva a estrutura de similaridade em corpora massivos.
O processo funciona da seguinte forma:
Cada documento é decomposto em um conjunto de shingles, normalmente n-gramas de caracteres ou palavras de comprimento fixo.
Uma série de funções hash independentes é aplicada a esses conjuntos.
Para cada função hash, o menor valor resultante em todo o conjunto de shingles é retido.
Isso produz uma assinatura MinHash de comprimento fixo para cada documento. A propriedade crítica é esta: para quaisquer dois documentos, a probabilidade de que um determinado valor hash seja compartilhado na mesma posição de suas assinaturas aproxima sua similaridade de Jaccard.
Isso reduz drasticamente a carga computacional para detecção de similaridade em larga escala. Em vez de comparar documentos completos, comparamos vetores curtos de assinatura. Mas há um problema de escalonamento. Mesmo com essa otimização, comparar cada par de documentos continua computacionalmente inviável em escala web.
Locality Sensitive Hashing: Acelerando a Busca por Similaridade
Para tornar o MinHash prático para corpora em escala de bilhões, aplicamos Locality Sensitive Hashing (LSH) sobre os vetores de assinatura. A ideia central do LSH é aumentar a probabilidade de documentos semelhantes colidirem em pelo menos um bucket hash, sem exigir comparação exaustiva.
Veja como funciona:
Cada assinatura MinHash é dividida em várias bandas, cada uma contendo um subconjunto das dimensões da assinatura.
Cada banda é independentemente hasheada em um bucket.
Se dois documentos compartilham pelo menos uma banda que é hasheada para o mesmo bucket, eles são considerados candidatos a uma possível duplicação.
Essa estratégia de bandas garante que documentos com alta similaridade (ou seja, muitos valores MinHash compartilhados) tenham muito mais probabilidade de colidir. Ao ajustar o número de bandas e linhas por banda, podemos fazer compensações entre recall (o número de duplicatas precisas capturadas), precisão (o número de falsos positivos evitados) e desempenho.
O resultado é um sistema de deduplicação aproximada escalável que permanece tratável mesmo quando aplicado a corpora contendo dezenas de bilhões de documentos.
Integrando MinHash LSH com Milvus e Zilliz Cloud
Tradicionalmente, a deduplicação é tratada por pipelines de pré-processamento independentes, desconectados da infraestrutura principal de recuperação ou armazenamento. Isso introduz uma série de ineficiências:
Transferência de dados custosa entre os componentes de deduplicação e indexação vetorial.
Lógica duplicada para normalização de dados e shingling.
Dificuldade em escalar os pipelines de deduplicação e recuperação em conjunto.
Abordamos o problema de forma diferente. Reconhecendo a força do Milvus como um banco de dados vetorial de alta taxa de transferência, perguntamos: E se o MinHash LSH fosse um primitivo de indexação nativamente integrado e de primeira classe?
Isso levou à integração nativa do MinHash LSH no Milvus 2.6 e no Zilliz Cloud (Milvus gerenciado), transformando a deduplicação aproximada em uma parte central do fluxo de trabalho de indexação e recuperação vetorial.
O Que Esta Integração Possibilita
Fluxo de trabalho de ponta a ponta: Da ingestão e geração de assinaturas MinHash à detecção aproximada de duplicatas e recuperação semântica downstream — tudo dentro do Milvus.
Escala distribuída: Construída sobre a arquitetura cloud-native do Milvus, a indexação LSH escala horizontalmente por terabytes ou até petabytes de dados.
APIs unificadas: A mesma API usada para busca por embeddings semânticos agora também pode dar suporte a consultas de deduplicação baseadas em MinHash, tornando os fluxos de trabalho de MLOps mais limpos e mais fáceis de manter.
Em nossa implementação atual:
Os usuários geram assinaturas MinHash externamente (por exemplo, usando suas estratégias preferidas de shingling e hash).
Esses vetores de assinatura (normalmente arrays
uint32) são inseridos no Milvus.A indexação LSH reduz o espaço de candidatos para detecção aproximada de duplicatas usando a estratégia de bandas descrita acima.
Esse design permite que equipes dedupliquem corpora de treinamento em escala massiva sem introduzir camadas adicionais de armazenamento ou lógica de pré-processamento desconectada.
Também ampliamos a API subjacente para dar suporte a fluxos de trabalho como inserção híbrida (vetores semânticos e MinHash), construção dinâmica de índices e consultas de deduplicação em lote. Esses recursos ainda estão evoluindo, e agradecemos feedback de equipes que estão implantando isso em produção.
Os Desafios de Engenharia para Deduplicar Dezenas de Bilhões de Documentos com MinHash LSH
Fazer o MinHash LSH funcionar em produção tem sido a baleia branca da indústria há anos.
O desafio se resume a dois requisitos brutais:
Você precisa de profunda expertise tanto nos algoritmos MinHash quanto LSH, além das habilidades de engenharia para integrá-los perfeitamente.
Qualquer caso de uso real de MinHash LSH envolve deduplicar dezenas de bilhões, centenas de bilhões ou até trilhões de pontos de dados. Isso impõe demandas esmagadoras de desempenho e capacidades de engenharia que a maioria das equipes não consegue atender.
Aqui está um exemplo perfeito: cerca de um ano atrás, uma empresa líder de IA nos procurou com uma solicitação aparentemente simples. Eles precisavam deduplicar dezenas de bilhões de pontos de dados (em um formato int32 de 780 dimensões), com a capacidade de iniciar serviços rapidamente e processar dados com rapidez para deduplicação e inserção.
Imediatamente encontramos um obstáculo crítico: a maioria dos bancos de dados vetoriais usa por padrão formatos de dados float32, mas vetores MinHash são coleções de valores de hash uint32.
À primeira vista, isso parece não ser um problema — float32 pode representar valores uint32 na maioria dos casos, certo?
Errado.
Aqui está a pegadinha: float32 só consegue representar inteiros sem sinal no intervalo de 0 a 16.777.216, enquanto uint32 cobre de 0 a 4.294.967.295. Se qualquer valor de hash exceder 16.777.216, float32 começa a perder precisão nos bits menos significativos.
Felizmente, o suporte a vetores binários do Milvus e do Zilliz Cloud resolve esse problema de forma elegante.
Isso pode parecer um detalhe técnico menor, mas destaca um ponto crucial: você precisa de um banco de dados projetado desde o início para lidar com diversos formatos de dados, escalas massivas e requisitos empresariais variados. Se você não estiver criando para cenários de nível empresarial desde o começo, até pequenos problemas de compatibilidade como esse podem se transformar em desastres de experiência do cliente no futuro.
Mas o desafio do formato dos dados foi apenas o começo—nossos clientes também exigiam desempenho extremo. Durante o processo de integração, o cliente foi direto: "Preciso iniciar rapidamente serviços do Zilliz Cloud que possam realizar imediatamente deduplicação vetorial de alta precisão. Cada importação envolve arquivos de 30GB com dados de assinatura int32 de 780 dimensões, e todo o processo de importação deve ser concluído em menos de 15 minutos."
À primeira vista, isso parece missão impossível, mas entregamos rapidamente nossa resposta: esqueça 15 minutos—vamos concluir em 4.
Esse avanço de desempenho veio de duas otimizações-chave do Milvus:
Primeiro, implementamos processamento paralelo de múltiplos arquivos, que rompeu o gargalo tradicional de importação serial. O sistema agora pode lidar simultaneamente com vários arquivos de dados, aumentando drasticamente a vazão geral e as velocidades de importação.
Segundo, integramos alocação dinâmica de recursos, que agenda de forma inteligente os recursos computacionais com base na complexidade e no volume das tarefas. Isso elimina desperdício e contenção de recursos, ao mesmo tempo em que maximiza a utilização. Combinadas, essas otimizações permitem que o Milvus aproveite plenamente os recursos do hardware moderno e as características de leitura-gravação concorrentes do armazenamento em nuvem, proporcionando experiências de importação de dados quase em tempo real.
Resolver o desafio da importação foi apenas o primeiro passo—como lidar com implantação rápida e computação em escala massiva?
Cenários de treinamento de grandes modelos de IA criam uma combinação perfeita de requisitos exigentes. Você está lidando com volumes enormes de dados de entrada, bancos de dados existentes massivos e cargas de pico que podem atingir 44.000 recuperações vetoriais por segundo—o tipo de concorrência extrema que sobrecarrega a maioria dos sistemas. À medida que os dados continuam a fluir e seu banco de dados cresce exponencialmente, as demandas computacionais aumentam na mesma proporção, exercendo pressão implacável sobre o desempenho do sistema.
A solução exige um poder sério de computação distribuída. A arquitetura nativa em nuvem do Zilliz Cloud foi projetada especificamente para enfrentar esses desafios por meio de distribuição inteligente de cargas de trabalho e escalonamento elástico.
A Arma Secreta: Integração com o Cardinal Engine
Olhando para o futuro, MinHash LSH representa apenas o começo. Estamos integrando esse recurso ao mecanismo proprietário Cardinal do Zilliz Cloud, o que acelerará ainda mais o processamento de dados não estruturados em todos os aspectos.
Cardinal é nosso mecanismo de busca vetorial de próxima geração com IA, criado do zero com C++ moderno e algoritmos de busca aproximada de vizinhos mais próximos (ANNS) de última geração. O objetivo é simples: atender a mais solicitações de usuários com os mesmos recursos de hardware.
Otimizações em Nível de Algoritmo: O Cardinal oferece amplo ajuste de desempenho para algoritmos centrais como IVF e indexação por grafos, alcançando o equilíbrio ideal entre velocidade e eficiência de memória.
Inovações em Nível de Engenharia: O mecanismo apresenta alocadores de memória personalizados e pooling de memória inteligente, juntamente com uma arquitetura modular de componentes que permite a composição flexível do pipeline de busca. Cada pipeline pode ser ajustado com precisão para casos de uso específicos e críticos para a missão.
Otimização Específica de Hardware: O Cardinal inclui vários kernels de computação especializados, cada um otimizado manualmente para plataformas de hardware e padrões de carga de trabalho específicos.
Essas otimizações abrangentes permitem que o Cardinal opere com eficiência máxima 24 horas por dia, entregando desempenho de busca vetorial líder do setor. Com o Cardinal impulsionando o Zilliz Cloud, alcançamos melhorias de desempenho de 10x em relação ao Milvus de código aberto, combinadas com velocidades de consulta ultrarrápidas e altas taxas de recall. Seja processando conjuntos de dados massivos ou criando aplicações que exigem tempos de resposta extremamente rápidos, o Cardinal fornece a base de desempenho para experiências de usuário superiores e aplicações de IA competitivas.
O Futuro É Não Estruturado—E Estamos Prontos para Ele
A deduplicação de dados de treinamento de LLM é apenas o ato de abertura em uma história de transformação muito maior. A IDC prevê que, até 2027, os dados não estruturados explodirão para quase 250 ZB globalmente—representando 86,8% de todos os dados existentes. Embora esses dados custem significativamente mais para processar e armazenar do que dados estruturados, o valor contido em textos, imagens, áudio, vídeo, logs de sensores, conteúdo de redes sociais, PDFs, páginas da web, repositórios de código, imagens médicas e fotos de satélite é impossível de ignorar.
Isso cria o desafio definidor da nossa era: como extraímos valor de forma eficiente de dados não estruturados que crescem exponencialmente sem estourar o orçamento?
Os recursos de deduplicação que criamos para o treinamento de IA representam apenas uma peça desse quebra-cabeça maior. À medida que os dados não estruturados continuam seu crescimento explosivo, os mesmos princípios—algoritmos inteligentes, engenharia em escala empresarial e desempenho nativo da nuvem—se tornarão infraestrutura essencial para toda organização orientada por dados.
O futuro pertence às empresas que conseguem transformar o caos dos dados não estruturados em uma vantagem competitiva estruturada. Estamos construindo esse futuro, um algoritmo de cada vez. Pronto para se juntar a nós?
Pronto para explorar a deduplicação em larga escala para seu pipeline de treinamento de IA? Saiba mais sobre os recursos de MinHash LSH do Milvus 2.6 em nossa documentação abrangente, experimente o Zilliz Cloud (Milvus gerenciado) para cargas de trabalho de produção, ou conecte-se com nossa equipe de engenharia no Discord para discutir seu caso de uso específico.
Continue lendo
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
8 Latest RAG Advancements Every Developer Should Know
Explore eight advanced RAG variants that can solve real problems you might be facing: slow retrieval, poor context understanding, multimodal data handling, and resource optimization.