Deduplicación de datos a escala de billones: cómo resolver el mayor cuello de botella del entrenamiento de LLM
La carrera por escalar los LLM, y su costo invisible
Los LLM han transformado casi todas las facetas de la IA moderna, abriendo nuevas fronteras en la generación de contenido, el desarrollo de software, el razonamiento y el uso autónomo de herramientas. Y sus capacidades no muestran señales de desaceleración.
Tomemos los anuncios más recientes: Grok 4 de X.ai y Kimi K2 de Moonshot introducen capacidades de razonamiento más sólidas, mejor uso de herramientas y una generación más coherente, todo impulsado por corpus de entrenamiento significativamente más grandes y diversos.
La tendencia es clara: la frontera de las capacidades está siendo impulsada por el entrenamiento a una escala sin precedentes. Considera las huellas de datos de modelos recientes:
| Modelo | Lanzamiento | Parámetros | Datos de entrenamiento |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 billones de tokens |
| Grok 4 | 2025 | ~175B | 100x más que Grok 2, probablemente a escala de billones |
| GPT-4 | 2023 | 1,8T (est.) | 13 billones de tokens |
| LLaMA 3.1 | 2024 | 405B | 15 billones de tokens |
Kimi K2, por ejemplo, triplicó el tamaño de su conjunto de datos en apenas seis meses, una tasa de crecimiento que casi supera la expansión de internet. Con 15,5 billones de tokens, es más grande que el contenido acumulado de todas las principales bibliotecas del mundo, muchas veces.
Pero oculta dentro de este crecimiento hay una suposición de que más datos siempre equivale a mejor rendimiento. En la práctica, las ganancias marginales de simplemente añadir más tokens están disminuyendo y se ven cada vez más limitadas por la calidad de los datos.
Eso nos lleva al primer cuello de botella —y quizá el más subestimado— en el entrenamiento moderno de LLM: la duplicación de datos.
Deduplicación de datos: por qué importa para el entrenamiento de LLM
Los conjuntos de datos modernos de preentrenamiento de LLM provienen principalmente de rastreos web a gran escala, repositorios abiertos, corpus públicos y documentos específicos de dominio extraídos de la web. A medida que estas canalizaciones crecen, la redundancia se vuelve no solo común, sino sistémica.
Documentos con pequeñas variaciones (por ejemplo, cambios de formato, pies de página, encabezados repetitivos) reaparecen en distintos dominios. Páginas populares se duplican en espejos, se traducen o se vuelven a publicar en otros sitios web. Bases de código y artículos de conocimiento se duplican en foros, wikis e instantáneas archivadas. Incluso fuentes estructuradas, como Wikipedia, presentan repetición en rutas de enlaces y espejos.
Cuando este contenido duplicado fluye sin control hacia los conjuntos de entrenamiento, las consecuencias son significativas:
Ineficiencia computacional: Los ejemplos repetidos no aportan información nueva, pero consumen los mismos recursos computacionales.
Riesgo de sobreajuste: Los LLM expuestos a formulaciones, estructuras o patrones de contenido repetidos pueden volverse excesivamente dependientes de estos patrones, reduciendo así sus capacidades de generalización.
Memorización textual: Una alta duplicación aumenta el riesgo de que los modelos memoricen secuencias específicas, lo que plantea preocupaciones de seguridad, privacidad y propiedad intelectual.
Filtración en la evaluación: Si existen duplicados entre los conjuntos de entrenamiento y validación/prueba, las puntuaciones de referencia pueden inflarse artificialmente, dando una impresión engañosa de la calidad del modelo.
En resumen, la duplicación no es solo una molestia. Es un problema existencial para ejecuciones de entrenamiento de alta escala y alto costo.
Uno de nuestros clientes empresariales —un proveedor de LLM de primer nivel— se encontró exactamente con este problema. Necesitaban deduplicar decenas de miles de millones de documentos antes de que fueran ingeridos. Las herramientas de coincidencia exacta por hash no detectaban casi duplicados. Los modelos semánticos eran demasiado costosos para ejecutarse a escala. Y las pilas tradicionales de limpieza de datos simplemente no podían cumplir con sus restricciones de tiempo y recursos.
Este es el contexto en el que la deduplicación se ha convertido en infraestructura crítica para la misión, no en una idea tardía de preprocesamiento.
Una visión general de las técnicas de deduplicación
Existen tres estrategias dominantes para la deduplicación a escala, cada una con compensaciones en términos de precisión, costo y viabilidad.
Coincidencia exacta: Usa hashing criptográfico para encontrar documentos idénticos. Rápida y precisa, pero no detecta casi duplicados con diferencias menores de formato.
Coincidencia semántica: Aprovecha modelos de embeddings vectoriales para encontrar contenido conceptualmente similar. Muy precisa, pero computacionalmente costosa a escala.
Coincidencia aproximada: Encuentra casi duplicados usando algoritmos probabilísticos como MinHash LSH y similitud de Jaccard. Equilibra la precisión con la eficiencia computacional: perfecto para conjuntos de datos de billones de tokens.
Con corpus de preentrenamiento que alcanzan terabytes o incluso petabytes, los métodos tradicionales de coincidencia exacta, como las comparaciones por pares, son computacionalmente inviables. La deduplicación semántica añade una sobrecarga significativa al usar modelos de embeddings para generar vectores.
Necesitamos métodos aproximados más innovadores —como MinHash LSH— que equilibren la exhaustividad y la precisión mientras mantienen los costos manejables, haciendo que la deduplicación a gran escala sea práctica.
MinHash LSH: Detección de casi duplicados en conjuntos de datos a escala de billones
En el contexto del entrenamiento de LLM a gran escala, la deduplicación eficiente requiere un algoritmo de coincidencia que no solo sea preciso, sino también computacionalmente viable a la escala de decenas de miles de millones de documentos. MinHash LSH (Locality Sensitive Hashing) está diseñado específicamente para este tipo de escenario.
MinHash: Estimación de similitud escalable
MinHash es una técnica probabilística diseñada para estimar la similitud de Jaccard entre conjuntos, sin calcular intersecciones explícitas por pares. En el contexto de la deduplicación de documentos, actúa como un mecanismo de compresión con pérdida que preserva la estructura de similitud en corpus masivos.
El proceso funciona de la siguiente manera:
Cada documento se descompone en un conjunto de shingles, normalmente n-gramas de caracteres o palabras de longitud fija.
Se aplica una serie de funciones hash independientes a estos conjuntos.
Para cada función hash, se conserva el valor mínimo resultante en todo el conjunto de shingles.
Esto produce una firma MinHash de longitud fija para cada documento. La propiedad crítica es esta: para cualquier par de documentos, la probabilidad de que un valor hash particular se comparta en la misma posición de sus firmas aproxima su similitud de Jaccard.
Esto reduce drásticamente la carga computacional para la detección de similitud a gran escala. En lugar de comparar documentos completos, comparamos vectores de firmas cortos. Pero hay un problema de escalabilidad. Incluso con esta optimización, comparar cada par de documentos sigue siendo computacionalmente inviable a escala web.
Locality Sensitive Hashing: Aceleración de la búsqueda de similitud
Para hacer que MinHash sea práctico para corpus a escala de miles de millones, aplicamos Locality Sensitive Hashing (LSH) sobre los vectores de firmas. La idea central de LSH es aumentar la probabilidad de que documentos similares colisionen en al menos un bucket hash, sin requerir una comparación exhaustiva.
Así es como funciona:
Cada firma MinHash se divide en múltiples bandas, cada una de las cuales contiene un subconjunto de las dimensiones de la firma.
Cada banda se hashea de forma independiente en un bucket.
Si dos documentos comparten al menos una banda que hashea al mismo bucket, se consideran candidatos a una posible duplicación.
Esta estrategia de bandas garantiza que los documentos con alta similitud (es decir, muchos valores MinHash compartidos) tengan muchas más probabilidades de colisionar. Al ajustar el número de bandas y filas por banda, podemos equilibrar la exhaustividad (el número de duplicados correctos detectados), la precisión (el número de falsos positivos evitados) y el rendimiento.
El resultado es un sistema de deduplicación aproximada y escalable que sigue siendo manejable incluso cuando se aplica a corpus que contienen decenas de miles de millones de documentos.
Integración de MinHash LSH con Milvus y Zilliz Cloud
Tradicionalmente, la deduplicación se gestiona mediante pipelines de preprocesamiento independientes desconectados de la infraestructura principal de recuperación o almacenamiento. Esto introduce una serie de ineficiencias:
Costosa transferencia de datos entre los componentes de deduplicación e indexación vectorial.
Lógica duplicada para la normalización de datos y el shingling.
Dificultad para escalar conjuntamente los pipelines de deduplicación y recuperación.
Abordamos el problema de manera diferente. Reconociendo la fortaleza de Milvus como base de datos vectorial de alto rendimiento, nos preguntamos: ¿Y si MinHash LSH fuera una primitiva de indexación de primera clase e integrada de forma nativa?
Esto condujo a la integración nativa de MinHash LSH en Milvus 2.6 y Zilliz Cloud (Milvus gestionado), convirtiendo la deduplicación aproximada en una parte central del flujo de trabajo de indexación y recuperación vectorial.
Qué permite esta integración
Flujo de trabajo de extremo a extremo: Desde la ingesta y la generación de firmas MinHash hasta la detección aproximada de duplicados y la recuperación semántica posterior, todo dentro de Milvus.
Escala distribuida: Construida sobre la arquitectura nativa de la nube de Milvus, la indexación LSH escala horizontalmente a través de terabytes o incluso petabytes de datos.
APIs unificadas: La misma API utilizada para la búsqueda de embeddings semánticos ahora también puede admitir consultas de deduplicación basadas en MinHash, lo que hace que los flujos de trabajo de MLOps sean más limpios y fáciles de mantener.
En nuestra implementación actual:
Los usuarios generan firmas MinHash externamente (por ejemplo, usando sus estrategias preferidas de shingling y hash).
Estos vectores de firma (normalmente arrays
uint32) se insertan en Milvus.La indexación LSH reduce el espacio de candidatos para la detección aproximada de duplicados mediante la estrategia de bandas descrita anteriormente.
Este diseño permite a los equipos deduplicar corpus de entrenamiento a una escala masiva sin introducir capas de almacenamiento adicionales ni lógica de preprocesamiento desconectada.
También hemos ampliado la API subyacente para admitir flujos de trabajo como la inserción híbrida (vectores semánticos y MinHash), la construcción dinámica de índices y consultas de deduplicación por lotes. Estas capacidades siguen evolucionando, y agradecemos los comentarios de los equipos que implementan esto en producción.
Los desafíos de ingeniería de deduplicar decenas de miles de millones de documentos con MinHash LSH
Lograr que MinHash LSH funcione en producción ha sido la ballena blanca de la industria durante años.
El desafío se reduce a dos requisitos brutales:
Se necesita una profunda experiencia tanto en los algoritmos MinHash y LSH como las habilidades de ingeniería para integrarlos sin problemas.
Cualquier caso de uso real de MinHash LSH implica deduplicar decenas de miles de millones, cientos de miles de millones o incluso billones de puntos de datos. Esto impone exigencias aplastantes de rendimiento y capacidades de ingeniería que la mayoría de los equipos no puede satisfacer.
Aquí tienes un ejemplo perfecto: Hace aproximadamente un año, una empresa líder de IA se acercó a nosotros con una solicitud aparentemente sencilla. Necesitaban deduplicar decenas de miles de millones de puntos de datos (en un formato int32 de 780 dimensiones), con la capacidad de poner en marcha servicios rápidamente y procesar datos con rapidez para su deduplicación e inserción.
Inmediatamente nos encontramos con un obstáculo insalvable: la mayoría de las bases de datos vectoriales usan por defecto formatos de datos float32, pero los vectores MinHash son colecciones de valores hash uint32.
A primera vista, esto parece no ser un problema: float32 puede representar valores uint32 en la mayoría de los casos, ¿verdad?
Incorrecto.
Aquí está la trampa: float32 solo puede representar enteros sin signo en el rango de 0 a 16,777,216, mientras que uint32 abarca de 0 a 4,294,967,295. Si algún valor hash supera 16,777,216, float32 empieza a perder precisión en los bits menos significativos.
Afortunadamente, el soporte de vectores binarios de Milvus y Zilliz Cloud resuelve este problema con elegancia.
Esto podría parecer un detalle técnico menor, pero destaca un punto crucial: necesitas una base de datos diseñada desde el principio para manejar diversos formatos de datos, escalas masivas y requisitos empresariales variados. Si no estás construyendo para escenarios de nivel empresarial desde el inicio, incluso pequeños problemas de compatibilidad como este pueden convertirse en desastres de experiencia del cliente más adelante.
Pero el desafío del formato de datos fue solo el comienzo: nuestros clientes también exigían un rendimiento extremo. Durante el proceso de integración, el cliente lo expresó sin rodeos: "Necesito poner en marcha rápidamente servicios de Zilliz Cloud que puedan realizar de inmediato deduplicación vectorial de alta precisión. Cada importación implica archivos de 30GB con datos de firma int32 de 780 dimensiones, y todo el proceso de importación debe completarse en menos de 15 minutos."
A primera vista, esto parece una misión imposible, pero rápidamente entregamos nuestra respuesta: olvida los 15 minutos; lo haremos en 4.
Este avance en rendimiento provino de dos optimizaciones clave de Milvus:
Primero, implementamos procesamiento paralelo de múltiples archivos que rompió el cuello de botella tradicional de la importación serial. El sistema ahora puede manejar simultáneamente múltiples archivos de datos, aumentando drásticamente el rendimiento general y las velocidades de importación.
Segundo, integramos asignación dinámica de recursos que programa inteligentemente los recursos computacionales según la complejidad y el volumen de la tarea. Esto elimina el desperdicio y la contención de recursos, al tiempo que maximiza la utilización. Combinadas, estas optimizaciones permiten que Milvus aproveche plenamente las capacidades del hardware moderno y las características de lectura-escritura concurrentes del almacenamiento en la nube, ofreciendo experiencias de importación de datos casi en tiempo real.
Resolver el desafío de la importación fue solo el primer paso: ¿cómo manejas el despliegue rápido y la computación a escala masiva?
Los escenarios de entrenamiento de grandes modelos de IA crean una tormenta perfecta de requisitos exigentes. Estás lidiando con enormes volúmenes de datos entrantes, bases de datos existentes masivas y cargas máximas que pueden alcanzar 44,000 recuperaciones vectoriales por segundo: el tipo de concurrencia extrema que aplasta a la mayoría de los sistemas. A medida que los datos siguen fluyendo y tu base de datos crece exponencialmente, las demandas computacionales aumentan en consecuencia, ejerciendo una presión implacable sobre el rendimiento del sistema.
La solución requiere una gran potencia de computación distribuida. La arquitectura nativa de la nube de Zilliz Cloud fue diseñada específicamente para abordar estos desafíos mediante distribución inteligente de cargas de trabajo y escalado elástico.
El arma secreta: integración del Cardinal Engine
De cara al futuro, MinHash LSH representa solo el comienzo. Estamos integrando esta capacidad en el motor propietario Cardinal de Zilliz Cloud, lo que acelerará aún más el procesamiento de datos no estructurados en todos los ámbitos.
Cardinal es nuestro motor de búsqueda vectorial impulsado por IA de próxima generación, construido desde cero con C++ moderno y algoritmos de búsqueda aproximada de vecinos más cercanos (ANNS) de última generación. El objetivo es simple: manejar más solicitudes de usuarios con los mismos recursos de hardware.
Optimizaciones a nivel de algoritmo: Cardinal ofrece un amplio ajuste de rendimiento para algoritmos centrales como IVF e indexación de grafos, logrando el equilibrio óptimo entre velocidad y eficiencia de memoria.
Innovaciones a nivel de ingeniería: El motor cuenta con asignadores de memoria personalizados y agrupación inteligente de memoria, junto con una arquitectura de componentes modular que permite una composición flexible del pipeline de búsqueda. Cada pipeline puede ajustarse con precisión para casos de uso específicos y críticos para la misión.
Optimización específica de hardware: Cardinal incluye múltiples kernels de cómputo especializados, cada uno optimizado manualmente para plataformas de hardware y patrones de carga de trabajo particulares.
Estas optimizaciones integrales permiten que Cardinal opere con la máxima eficiencia las 24 horas, ofreciendo un rendimiento de búsqueda vectorial líder en la industria. Con Cardinal impulsando Zilliz Cloud, hemos logrado mejoras de rendimiento de 10x frente a Milvus de código abierto, combinadas con velocidades de consulta ultrarrápidas y altas tasas de recall. Ya sea que estés procesando conjuntos de datos masivos o creando aplicaciones que exigen tiempos de respuesta vertiginosamente rápidos, Cardinal proporciona la base de rendimiento para experiencias de usuario superiores y aplicaciones de IA competitivas.
El futuro es no estructurado, y estamos listos para ello
La deduplicación de datos de entrenamiento de LLM es solo el acto inicial en una historia de transformación mucho más grande. IDC predice que para 2027, los datos no estructurados se dispararán hasta casi 250ZB a nivel mundial, lo que representa el 86,8% de todos los datos existentes. Si bien estos datos cuestan significativamente más de procesar y almacenar que los datos estructurados, el valor encerrado en texto, imágenes, audio, video, registros de sensores, contenido de redes sociales, PDFs, páginas web, repositorios de código, imágenes médicas y fotos satelitales es imposible de ignorar.
Esto crea el desafío definitorio de nuestra era: ¿cómo extraemos valor de manera eficiente de datos no estructurados que crecen exponencialmente sin arruinarnos?
Las capacidades de deduplicación que hemos creado para el entrenamiento de IA representan solo una pieza de este rompecabezas más grande. A medida que los datos no estructurados continúan su crecimiento explosivo, los mismos principios —algoritmos inteligentes, ingeniería a escala empresarial y rendimiento nativo de la nube— se convertirán en infraestructura esencial para toda organización impulsada por datos.
El futuro pertenece a las empresas que pueden convertir el caos de los datos no estructurados en una ventaja competitiva estructurada. Estamos construyendo ese futuro, un algoritmo a la vez. ¿Listo para unirte a nosotros?
¿Listo para explorar la deduplicación a gran escala para tu pipeline de entrenamiento de IA? Obtén más información sobre las capacidades MinHash LSH de Milvus 2.6 en nuestra documentación completa, prueba Zilliz Cloud (Milvus gestionado) para cargas de trabajo de producción, o conecta con nuestro equipo de ingeniería en Discord para hablar sobre tu caso de uso específico.
Sigue leyendo
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.