Déduplication des données à l’échelle du trillion : comment résoudre le plus grand goulot d’étranglement de l’entraînement des LLM
La course au passage à l’échelle des LLM — et son coût invisible
Les LLM ont transformé presque toutes les facettes de l’IA moderne, ouvrant de nouvelles frontières dans la génération de contenu, le développement logiciel, le raisonnement et l’utilisation autonome d’outils. Et leurs capacités ne montrent aucun signe de ralentissement.
Prenez les annonces les plus récentes : Grok 4 de X.ai et Kimi K2 de Moonshot introduisent des capacités de raisonnement plus solides, une meilleure utilisation des outils et une génération plus cohérente — le tout alimenté par des corpus d’entraînement nettement plus vastes et plus diversifiés.
La tendance est claire : la frontière des capacités est repoussée par un entraînement à une échelle sans précédent. Considérez l’empreinte de données des modèles récents :
| Modèle | Sortie | Paramètres | Données d’entraînement |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15,5 billions de tokens |
| Grok 4 | 2025 | ~175B | 100x plus que Grok 2, probablement à l’échelle du billion |
| GPT-4 | 2023 | 1,8T (est.) | 13 billions de tokens |
| LLaMA 3.1 | 2024 | 405B | 15 billions de tokens |
Kimi K2, par exemple, a triplé la taille de son jeu de données en seulement six mois — un taux de croissance qui dépasse presque l’expansion d’Internet. Avec 15,5 billions de tokens, il est plus vaste que le contenu cumulé de toutes les grandes bibliothèques mondiales, et de loin.
Mais enfouie dans cette croissance se trouve l’hypothèse selon laquelle davantage de données équivaut toujours à de meilleures performances. En pratique, les gains marginaux obtenus en ajoutant simplement plus de tokens diminuent et sont de plus en plus limités par la qualité des données.
Cela nous amène au premier goulot d’étranglement — et peut-être le plus sous-estimé — de l’entraînement moderne des LLM : la duplication des données.
Déduplication des données : pourquoi elle compte pour l’entraînement des LLM
Les jeux de données modernes de préentraînement des LLM proviennent principalement de crawls web à grande échelle, de dépôts ouverts, de corpus publics et de documents propres à certains domaines collectés sur le web. À mesure que ces pipelines se développent, la redondance devient non seulement courante, mais systémique.
Des documents avec de légères variations (par exemple, changements de mise en forme, pieds de page, en-têtes passe-partout) réapparaissent sur différents domaines. Des pages populaires sont mises en miroir, traduites ou republiées sur d’autres sites web. Des bases de code et des articles de connaissance sont dupliqués sur des forums, des wikis et des instantanés archivés. Même les sources structurées, comme Wikipédia, présentent des répétitions dans les parcours de liens et les miroirs.
Lorsque ce contenu dupliqué est intégré sans contrôle aux jeux d’entraînement, les conséquences sont importantes :
Inefficacité de calcul : Les exemples répétés n’apportent aucune information nouvelle, mais consomment les mêmes ressources de calcul.
Risque de surapprentissage : Les LLM exposés à des formulations, structures ou motifs de contenu répétés peuvent devenir trop dépendants de ces motifs, réduisant ainsi leurs capacités de généralisation.
Mémorisation verbatim : Une forte duplication augmente le risque que les modèles mémorisent des séquences spécifiques, soulevant des préoccupations en matière de sécurité, de confidentialité et de propriété intellectuelle.
Fuite d’évaluation : Si des doublons existent entre les ensembles d’entraînement et de validation/test, les scores de benchmark peuvent être artificiellement gonflés, donnant une impression trompeuse de la qualité du modèle.
En bref, la duplication n’est pas qu’une simple nuisance. C’est un problème existentiel pour les entraînements à grande échelle et à coût élevé.
L’un de nos clients entreprise — un fournisseur de LLM de premier plan — a rencontré exactement ce problème. Il devait dédupliquer des dizaines de milliards de documents avant leur ingestion. Les outils de correspondance par hachage exact passaient à côté des quasi-doublons. Les modèles sémantiques étaient trop coûteux pour être exécutés à grande échelle. Et les piles traditionnelles de nettoyage des données ne pouvaient tout simplement pas respecter leurs contraintes de temps et de ressources.
C’est dans ce contexte que la déduplication est devenue une infrastructure critique, et non une étape de prétraitement secondaire.
Aperçu des techniques de déduplication
Il existe trois stratégies dominantes pour la déduplication à grande échelle, chacune avec des compromis en matière de précision, de coût et de faisabilité.
Correspondance exacte : Utilise le hachage cryptographique pour trouver des documents identiques. Rapide et précise, mais ne détecte pas les quasi-doublons présentant de légères différences de mise en forme.
Correspondance sémantique : Exploite des modèles de vectorisation par embeddings pour trouver du contenu conceptuellement similaire. Très précise, mais coûteuse en calcul à grande échelle.
Correspondance approximative : Trouve des quasi-doublons à l’aide d’algorithmes probabilistes comme MinHash LSH et la similarité de Jaccard. Équilibre précision et efficacité computationnelle — parfait pour les jeux de données de plusieurs billions de tokens.
Avec des corpus de pré-entraînement atteignant des téraoctets, voire des pétaoctets, les méthodes traditionnelles de correspondance exacte, telles que les comparaisons par paires, sont computationnellement irréalisables. La déduplication sémantique ajoute une surcharge significative en utilisant des modèles d’embedding pour générer des vecteurs.
Nous avons besoin de méthodes approximatives plus innovantes — comme MinHash LSH — qui équilibrent rappel et précision tout en maintenant les coûts à un niveau gérable, rendant la déduplication à grande échelle pratique.
MinHash LSH : détecter les quasi-doublons dans des jeux de données à l’échelle du billion
Dans le contexte de l’entraînement de LLM à grande échelle, une déduplication efficace nécessite un algorithme de correspondance qui soit non seulement précis, mais aussi computationnellement faisable à l’échelle de dizaines de milliards de documents. MinHash LSH (Locality Sensitive Hashing) est conçu précisément pour ce type de scénario.
MinHash : estimation de similarité évolutive
MinHash est une technique probabiliste conçue pour estimer la similarité de Jaccard entre des ensembles, sans calculer explicitement les intersections par paires. Dans le contexte de la déduplication de documents, elle agit comme un mécanisme de compression avec perte qui préserve la structure de similarité à travers des corpus massifs.
Le processus fonctionne comme suit :
Chaque document est décomposé en un ensemble de shingles, généralement des n-grammes de caractères ou de mots de longueur fixe.
Une série de fonctions de hachage indépendantes est appliquée à ces ensembles.
Pour chaque fonction de hachage, la valeur minimale obtenue dans l’ensemble de shingles est conservée.
Cela produit une signature MinHash de longueur fixe pour chaque document. La propriété critique est la suivante : pour deux documents quelconques, la probabilité qu’une valeur de hachage particulière soit partagée à la même position de leurs signatures approxime leur similarité de Jaccard.
Cela réduit considérablement la charge computationnelle pour la détection de similarité à grande échelle. Au lieu de comparer des documents complets, nous comparons de courts vecteurs de signatures. Mais il existe un problème de passage à l’échelle. Même avec cette optimisation, comparer chaque paire de documents reste computationnellement irréalisable à l’échelle du Web.
Locality Sensitive Hashing : accélérer la recherche de similarité
Pour rendre MinHash pratique pour des corpus à l’échelle du milliard, nous appliquons Locality Sensitive Hashing (LSH) par-dessus les vecteurs de signatures. L’idée centrale de LSH est d’augmenter la probabilité que des documents similaires entrent en collision dans au moins un compartiment de hachage, sans nécessiter de comparaison exhaustive.
Voici comment cela fonctionne :
Chaque signature MinHash est divisée en plusieurs bandes, chacune contenant un sous-ensemble des dimensions de la signature.
Chaque bande est hachée indépendamment dans un compartiment.
Si deux documents partagent au moins une bande qui est hachée vers le même compartiment, ils sont considérés comme des candidats à une duplication potentielle.
Cette stratégie de bandes garantit que les documents présentant une forte similarité (c’est-à-dire de nombreuses valeurs MinHash partagées) sont beaucoup plus susceptibles d’entrer en collision. En ajustant le nombre de bandes et de lignes par bande, nous pouvons arbitrer entre le rappel (le nombre de doublons exacts détectés), la précision (le nombre de faux positifs évités) et les performances.
Le résultat est un système de déduplication approximative évolutif qui reste traitable même lorsqu’il est appliqué à des corpus contenant des dizaines de milliards de documents.
Intégrer MinHash LSH à Milvus et Zilliz Cloud
Traditionnellement, la déduplication est gérée par des pipelines de prétraitement autonomes, déconnectés de l’infrastructure principale de récupération ou de stockage. Cela introduit toute une série d’inefficacités :
Transfert de données coûteux entre les composants de déduplication et d’indexation vectorielle.
Logique dupliquée pour la normalisation des données et le shingling.
Difficulté à faire évoluer ensemble les pipelines de déduplication et de récupération.
Nous avons abordé le problème différemment. Reconnaissant la force de Milvus en tant que base de données vectorielle à haut débit, nous nous sommes demandé : Et si MinHash LSH était une primitive d’indexation native, intégrée de premier ordre ?
Cela a conduit à l’intégration native de MinHash LSH dans Milvus 2.6 et Zilliz Cloud (Milvus géré), faisant de la déduplication approximative un élément central du flux de travail d’indexation vectorielle et de récupération.
Ce que permet cette intégration
Flux de travail de bout en bout : De l’ingestion et de la génération de signatures MinHash à la détection approximative de doublons et à la récupération sémantique en aval, le tout au sein de Milvus.
Échelle distribuée : Construit sur l’architecture cloud-native de Milvus, l’indexation LSH évolue horizontalement sur des téraoctets, voire des pétaoctets de données.
API unifiées : La même API utilisée pour la recherche par embeddings sémantiques peut désormais également prendre en charge les requêtes de déduplication basées sur MinHash, rendant les flux de travail MLOps plus propres et plus maintenables.
Dans notre implémentation actuelle :
Les utilisateurs génèrent des signatures MinHash en externe (par exemple, en utilisant leurs stratégies de shingling et de hachage préférées).
Ces vecteurs de signature (généralement des tableaux
uint32) sont insérés dans Milvus.L’indexation LSH réduit l’espace des candidats pour la détection approximative de doublons en utilisant la stratégie de bandes décrite ci-dessus.
Cette conception permet aux équipes de dédupliquer des corpus d’entraînement à très grande échelle sans introduire de couches de stockage supplémentaires ni de logique de prétraitement déconnectée.
Nous avons également étendu l’API sous-jacente pour prendre en charge des flux de travail tels que l’insertion hybride (vecteurs sémantiques et MinHash), la construction dynamique d’index et les requêtes de déduplication par lots. Ces capacités continuent d’évoluer, et nous accueillons avec intérêt les retours des équipes qui les déploient en production.
Les défis d’ingénierie de la déduplication de dizaines de milliards de documents avec MinHash LSH
Faire fonctionner MinHash LSH en production est depuis des années la baleine blanche de l’industrie.
Le défi se résume à deux exigences brutales :
Il faut une expertise approfondie à la fois des algorithmes MinHash et LSH, ainsi que les compétences d’ingénierie nécessaires pour les intégrer de manière transparente.
Tout cas d’utilisation réel de MinHash LSH implique de dédupliquer des dizaines de milliards, des centaines de milliards, voire des milliers de milliards de points de données. Cela impose des exigences écrasantes en matière de performance et de capacités d’ingénierie auxquelles la plupart des équipes ne peuvent pas répondre.
Voici un exemple parfait : il y a environ un an, une entreprise d’IA de premier plan nous a approchés avec une demande apparemment simple. Elle devait dédupliquer des dizaines de milliards de points de données (dans un format int32 à 780 dimensions), avec la capacité de lancer rapidement des services et de traiter rapidement les données pour la déduplication et l’insertion.
Nous nous sommes immédiatement heurtés à un obstacle majeur : la plupart des bases de données vectorielles utilisent par défaut des formats de données float32, mais les vecteurs MinHash sont des collections de valeurs de hachage uint32.
À première vue, cela peut sembler sans importance—float32 peut représenter des valeurs uint32 dans la plupart des cas, n’est-ce pas ?
Faux.
Voici le piège : float32 ne peut représenter des entiers non signés que dans la plage de 0 à 16,777,216, tandis que uint32 couvre de 0 à 4,294,967,295. Si une valeur de hachage dépasse 16,777,216, float32 commence à perdre de la précision dans les bits les moins significatifs.
Heureusement, la prise en charge des vecteurs binaires par Milvus et Zilliz Cloud résout élégamment ce problème.
Cela peut sembler être un détail technique mineur, mais cela met en évidence un point crucial : vous avez besoin d’une base de données conçue dès le départ pour gérer des formats de données divers, des échelles massives et des exigences d’entreprise variées. Si vous ne construisez pas pour des scénarios de niveau entreprise dès le début, même de minuscules problèmes de compatibilité comme celui-ci peuvent se transformer en désastres pour l’expérience client par la suite.
Mais le défi du format des données n’était que le début : nos clients exigeaient également des performances extrêmes. Pendant le processus d’intégration, le client l’a formulé sans détour : « J’ai besoin de lancer rapidement des services Zilliz Cloud capables d’effectuer immédiatement une déduplication vectorielle de haute précision. Chaque importation implique des fichiers de 30 Go avec des données de signature int32 à 780 dimensions, et l’ensemble du processus d’importation doit être terminé en moins de 15 minutes. »
À première vue, cela ressemble à une mission impossible, mais nous avons rapidement apporté notre réponse : oubliez les 15 minutes — nous le ferons en 4.
Cette percée en matière de performances est venue de deux optimisations clés de Milvus :
Premièrement, nous avons mis en œuvre un traitement parallèle multi-fichiers qui a fait voler en éclats le goulot d’étranglement traditionnel de l’importation sérielle. Le système peut désormais traiter simultanément plusieurs fichiers de données, augmentant considérablement le débit global et les vitesses d’importation.
Deuxièmement, nous avons intégré une allocation dynamique des ressources qui planifie intelligemment les ressources de calcul en fonction de la complexité et du volume des tâches. Cela élimine le gaspillage et la contention des ressources tout en maximisant l’utilisation. Combinées, ces optimisations permettent à Milvus d’exploiter pleinement les capacités du matériel moderne et les caractéristiques de lecture-écriture concurrentes du stockage cloud, offrant des expériences d’importation de données quasi en temps réel.
Résoudre le défi de l’importation n’était que la première étape : comment gérer un déploiement rapide et le calcul à très grande échelle ?
Les scénarios d’entraînement de grands modèles d’IA créent une tempête parfaite d’exigences élevées. Vous faites face à d’énormes volumes de données entrantes, à d’immenses bases de données existantes et à des pics de charge pouvant atteindre 44 000 récupérations vectorielles par seconde — le type de concurrence extrême qui met à genoux la plupart des systèmes. À mesure que les données continuent d’affluer et que votre base de données croît de manière exponentielle, les besoins en calcul augmentent en conséquence, exerçant une pression constante sur les performances du système.
La solution exige une puissance de calcul distribué sérieuse. L’architecture cloud-native de Zilliz Cloud a été spécifiquement conçue pour relever ces défis grâce à une distribution intelligente des charges de travail et à une mise à l’échelle élastique.
L’arme secrète : l’intégration de Cardinal Engine
À l’avenir, MinHash LSH ne représente que le début. Nous intégrons cette capacité au moteur propriétaire Cardinal de Zilliz Cloud, ce qui accélérera encore le traitement des données non structurées dans tous les domaines.
Cardinal est notre moteur de recherche vectorielle de nouvelle génération alimenté par l’IA, construit de A à Z avec du C++ moderne et des algorithmes de recherche approximative des plus proches voisins (ANNS) de pointe. L’objectif est simple : traiter davantage de requêtes utilisateur avec les mêmes ressources matérielles.
Optimisations au niveau des algorithmes : Cardinal offre un réglage approfondi des performances pour les algorithmes de base comme IVF et l’indexation par graphe, en trouvant l’équilibre optimal entre vitesse et efficacité mémoire.
Innovations au niveau de l’ingénierie : le moteur dispose d’allocateurs de mémoire personnalisés et d’une mise en commun intelligente de la mémoire, ainsi que d’une architecture de composants modulaire qui permet une composition flexible du pipeline de recherche. Chaque pipeline peut être finement ajusté pour des cas d’utilisation spécifiques et critiques.
Optimisation spécifique au matériel : Cardinal inclut plusieurs noyaux de calcul spécialisés, chacun optimisé manuellement pour des plateformes matérielles et des modèles de charge de travail particuliers.
Ces optimisations complètes permettent à Cardinal de fonctionner à efficacité maximale 24 h/24 et 7 j/7, offrant des performances de recherche vectorielle à la pointe du secteur. Avec Cardinal au cœur de Zilliz Cloud, nous avons obtenu des améliorations de performances de 10x par rapport à Milvus open source, combinées à des vitesses de requête ultra-rapides et à des taux de rappel élevés. Que vous traitiez des jeux de données massifs ou que vous créiez des applications exigeant des temps de réponse fulgurants, Cardinal fournit la base de performance nécessaire à des expériences utilisateur supérieures et à des applications d’IA compétitives.
L’avenir est non structuré — et nous y sommes prêts
La déduplication des données d’entraînement des LLM n’est que le lever de rideau d’une histoire de transformation bien plus vaste. IDC prévoit que, d’ici 2027, les données non structurées exploseront pour atteindre près de 250 Zo à l’échelle mondiale, représentant 86,8 % de toutes les données existantes. Bien que ces données coûtent nettement plus cher à traiter et à stocker que les données structurées, la valeur enfermée dans le texte, les images, l’audio, la vidéo, les journaux de capteurs, le contenu des réseaux sociaux, les PDF, les pages web, les dépôts de code, l’imagerie médicale et les photos satellites est impossible à ignorer.
Cela crée le défi déterminant de notre époque : comment extraire efficacement de la valeur de données non structurées en croissance exponentielle sans se ruiner ?
Les capacités de déduplication que nous avons développées pour l’entraînement de l’IA ne représentent qu’une pièce de ce puzzle plus vaste. Alors que les données non structurées poursuivent leur croissance explosive, les mêmes principes — algorithmes intelligents, ingénierie à l’échelle de l’entreprise et performance cloud-native — deviendront une infrastructure essentielle pour chaque organisation pilotée par les données.
L’avenir appartient aux entreprises capables de transformer le chaos des données non structurées en avantage concurrentiel structuré. Nous construisons cet avenir, un algorithme à la fois. Prêt à nous rejoindre ?
Prêt à explorer la déduplication à grande échelle pour votre pipeline d’entraînement IA ? Découvrez les capacités MinHash LSH de Milvus 2.6 dans notre documentation complète, essayez Zilliz Cloud (Milvus géré) pour les charges de travail de production, ou échangez avec notre équipe d’ingénierie sur Discord pour discuter de votre cas d’utilisation spécifique.
Continuer à lire
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.