1兆規模でのデータ重複排除：LLMトレーニング最大のボトルネックを解決する方法
LLMスケーリング競争——そしてその見えないコスト
LLMは現代AIのほぼあらゆる側面を変革し、コンテンツ生成、ソフトウェア開発、推論、自律的なツール利用における新たなフロンティアを切り開いてきました。そして、その能力は減速する兆しを見せていません。
直近の発表を見てみましょう。X.aiのGrok 4とMoonshotのKimi K2は、より強力な推論能力、より優れたツール利用、より一貫性のある生成を導入しています。これらはすべて、はるかに大規模で多様な訓練コーパスによって支えられています。
傾向は明らかです。能力のフロンティアは、前例のない規模での訓練によって押し広げられています。最近のモデルのデータ規模を見てみましょう。
| Model | Release | Parameters | Training Data |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15.5兆トークン |
| Grok 4 | 2025 | ~175B | Grok 2の100倍以上、おそらく兆規模 |
| GPT-4 | 2023 | 1.8T（推定） | 13兆トークン |
| LLaMA 3.1 | 2024 | 405B | 15兆トークン |
たとえばKimi K2は、わずか6か月でデータセットサイズを3倍にしました。これは、インターネットの拡大速度すらほぼ上回る成長率です。15.5兆トークンという規模は、世界中の主要な図書館すべての累積コンテンツを何倍も上回ります。
しかし、この成長の内側には、データが多ければ常に性能が向上するという前提が埋め込まれています。実際には、単にトークンを追加することによる限界的な利得は低下しており、データ品質によってますます制約されています。
ここで、現代のLLM訓練における最初の——そしておそらく最も過小評価されている——ボトルネックに行き着きます: データ重複です。
データ重複排除: LLM訓練において重要な理由
現代のLLM事前訓練データセットは、主に大規模なWebクロール、オープンリポジトリ、公開コーパス、そしてWebからスクレイピングされたドメイン固有文書から収集されています。こうしたパイプラインが拡大するにつれて、冗長性は単に一般的になるだけでなく、構造的なものになります。
軽微な違い（例: フォーマット変更、フッター、定型的なヘッダー）を持つ文書が、異なるドメインに再出現します。人気のあるページは、他のWebサイトでミラー化、翻訳、または再投稿されます。コードベースやナレッジ記事は、フォーラム、Wiki、アーカイブされたスナップショット間で重複します。Wikipediaのような構造化されたソースでさえ、リンク経路やミラーに反復が見られます。
この重複コンテンツがチェックされないまま訓練セットに流入すると、その影響は重大です。
計算効率の低下: 繰り返しの例は新しい情報を提供しないにもかかわらず、同じ計算資源を消費します。
過学習リスク: 繰り返される表現、構造、またはコンテンツパターンにさらされたLLMは、これらのパターンに過度に依存するようになり、その結果、汎化能力が低下する可能性があります。
逐語的な記憶: 高い重複率は、モデルが特定のシーケンスを記憶するリスクを高め、安全性、プライバシー、IPに関する懸念を引き起こします。
評価リーク: 訓練セットと検証/テストセットの間に重複が存在する場合、ベンチマークスコアが人為的に膨らみ、モデル品質について誤解を招く印象を与える可能性があります。
要するに、重複は単なる厄介事ではありません。大規模で高コストな訓練実行にとって、存在に関わる問題です。
当社のエンタープライズ顧客の1社——トップクラスのLLMプロバイダー——は、まさにこの問題に直面しました。同社は、取り込む前に数百億件の文書を重複排除する必要がありました。完全一致のハッシュ照合ツールでは近似重複を見逃しました。セマンティックモデルは大規模に実行するにはコストが高すぎました。そして従来のデータクリーニングスタックでは、時間とリソースの制約をまったく満たせませんでした。
このような背景のもと、重複排除は前処理の後付けではなく、ミッションクリティカルなインフラストラクチャとなっています。
重複排除手法の概要
大規模な重複排除には主に3つの戦略があり、それぞれ精度、コスト、実現可能性の面でトレードオフがあります。
完全一致: 暗号学的ハッシュを使用して同一のドキュメントを見つけます。高速で精密ですが、軽微なフォーマットの違いがある近似重複は見逃します。
セマンティックマッチング: ベクトル埋め込みモデルを活用して、概念的に類似したコンテンツを見つけます。非常に高精度ですが、大規模では計算コストが高くなります。
近似マッチング: MinHash LSH や Jaccard 類似度のような確率的アルゴリズムを使用して近似重複を見つけます。精度と計算効率のバランスを取り、兆単位のトークンを含むデータセットに最適です。
事前学習コーパスがテラバイト、あるいはペタバイト規模に達する中で、ペアワイズ比較のような従来の完全一致手法は計算上実現不可能です。セマンティック重複排除は、埋め込みモデルを使用してベクトルを生成するため、大きなオーバーヘッドを追加します。
コストを管理可能な範囲に抑えながら再現率と適合率のバランスを取る、MinHash LSH のようなより革新的な近似手法が必要です。これにより、大規模な重複排除が実用的になります。
MinHash LSH: 兆規模データセットにおける近似重複の検出
大規模 LLM トレーニングの文脈では、効率的な重複排除には、精度が高いだけでなく、数百億件のドキュメント規模でも計算上実現可能なマッチングアルゴリズムが必要です。MinHash LSH (Locality Sensitive Hashing) は、まさにこのようなシナリオのために設計されています。
MinHash: スケーラブルな類似度推定
MinHash は、明示的なペアワイズ交差を計算することなく、集合間の Jaccard 類似度 を推定するために設計された確率的手法です。ドキュメント重複排除の文脈では、大規模コーパス全体の類似性構造を保持する非可逆圧縮メカニズムとして機能します。
プロセスは次のように機能します。
各ドキュメントはシングルの集合に分解されます。通常は固定長の文字または単語 n-gram です。
一連の独立したハッシュ関数がこれらの集合に適用されます。
各ハッシュ関数について、シングル集合全体で得られた最小値が保持されます。
これにより、各ドキュメントに対して固定長の MinHash シグネチャ が生成されます。重要な特性は次のとおりです。任意の2つのドキュメントについて、特定のハッシュ値がそれらのシグネチャの同じ位置で共有される確率は、それらの Jaccard 類似度を近似します。
これにより、大規模な類似度検出における計算負荷が劇的に軽減されます。完全なドキュメントを比較する代わりに、短いシグネチャベクトルを比較します。しかし、スケーリング上の問題があります。この最適化を行っても、すべてのドキュメントペアを比較することは Web スケールでは計算上実現不可能です。
Locality Sensitive Hashing: 類似度検索の高速化
MinHash を十億規模のコーパスで実用的にするために、シグネチャベクトルの上に Locality Sensitive Hashing (LSH) を適用します。LSH の中核的な考え方は、網羅的な比較を必要とせずに、類似したドキュメントが少なくとも1つのハッシュバケットで衝突する可能性を高めることです。
仕組みは次のとおりです。
各 MinHash シグネチャは複数のバンドに分割され、それぞれにシグネチャ次元の一部が含まれます。
各バンドは独立してバケットにハッシュされます。
2つのドキュメントが、同じバケットにハッシュされる少なくとも1つのバンドを共有している場合、それらは潜在的な重複候補と見なされます。
このバンディング戦略により、高い類似度を持つドキュメント（つまり、多くの MinHash 値を共有するドキュメント）は、はるかに衝突しやすくなります。バンド数とバンドあたりの行数を調整することで、再現率（検出された正確な重複の数）、適合率（回避された偽陽性の数）、およびパフォーマンスの間でトレードオフを調整できます。
その結果、数百億件のドキュメントを含むコーパスに適用しても扱いやすい、スケーラブルな近似重複排除システムが実現します。
MinHash LSH と Milvus および Zilliz Cloud の統合
従来、重複排除は、主要な検索またはストレージインフラストラクチャから切り離されたスタンドアロンの前処理パイプラインによって処理されてきました。これにより、さまざまな非効率が生じます。
重複排除コンポーネントとベクトルインデックスコンポーネント間のコストの高いデータ転送。
データ正規化とシングリングのロジックの重複。
重複排除パイプラインと検索パイプラインを一緒にスケールさせることの難しさ。
私たちはこの問題に別のアプローチを取りました。Milvusの強みが高スループットのベクトルデータベースであることを認識し、次のように問いかけました。もしMinHash LSHがファーストクラスの、ネイティブに統合されたインデックスプリミティブだったらどうなるか？
これにより、MinHash LSHがMilvus 2.6およびZilliz Cloud（マネージドMilvus）にネイティブ統合され、近似重複排除がベクトルインデックス化と検索ワークフローの中核部分となりました。
この統合が可能にすること
エンドツーエンドのワークフロー: 取り込みとMinHashシグネチャ生成から、近似重複検出、下流のセマンティック検索まで、すべてをMilvus内で実行できます。
分散スケール: Milvusのクラウドネイティブアーキテクチャ上に構築されており、LSHインデックス化はテラバイト、さらにはペタバイト規模のデータに対して水平スケールします。
統一されたAPI: セマンティック埋め込み検索に使用される同じAPIが、MinHashベースの重複排除クエリもサポートできるようになり、MLOpsワークフローがよりクリーンで保守しやすくなります。
現在の実装では：
ユーザーはMinHashシグネチャを外部で生成します（例：任意のシングリングおよびハッシュ戦略を使用）。
これらのシグネチャベクトル（通常は
uint32配列）がMilvusに挿入されます。LSHインデックス化は、上記のバンディング戦略を使用して、近似重複検出の候補空間を絞り込みます。
この設計により、チームは追加のストレージ層や切り離された前処理ロジックを導入することなく、トレーニングコーパスを大規模に重複排除できます。
また、基盤となるAPIを拡張し、ハイブリッド挿入（セマンティックベクトルとMinHashベクトル）、動的インデックス構築、バッチ重複排除クエリなどのワークフローをサポートしました。これらの機能はまだ進化中であり、本番環境でこれを導入しているチームからのフィードバックを歓迎します。
MinHash LSHで数百億のドキュメントを重複排除する際のエンジニアリング上の課題
MinHash LSHを本番環境で機能させることは、何年もの間、業界にとっての悲願でした。
課題は、2つの過酷な要件に集約されます。
MinHashとLSHアルゴリズムの両方に関する深い専門知識に加え、それらをシームレスに統合するエンジニアリングスキルが必要です。
MinHash LSHの実際のユースケースでは、数百億、数千億、さらには数兆のデータポイントを重複排除する必要があります。これは、ほとんどのチームが満たせないほど、パフォーマンスとエンジニアリング能力に過酷な要求を突きつけます。
完璧な例があります。約1年前、ある大手AI企業が、一見すると単純な依頼を私たちに持ちかけました。彼らは、数百億のデータポイント（780次元のint32形式）を重複排除し、サービスを素早く立ち上げて、重複排除と挿入のためにデータを迅速に処理できるようにする必要がありました。
私たちはすぐに重大な障害にぶつかりました。ほとんどのベクトルデータベースはデフォルトでfloat32データ形式を使用しますが、MinHashベクトルはuint32ハッシュ値の集合です。
一見すると、これは問題ではないように思えます。float32はほとんどの場合uint32値を表現できますよね？
違います。
落とし穴は次のとおりです。float32が表現できる符号なし整数は0から16,777,216の範囲に限られる一方、uint32は0から4,294,967,295までをカバーします。いずれかのハッシュ値が16,777,216を超えると、float32は最下位ビットの精度を失い始めます。
幸いなことに、Milvus と Zilliz Cloud のバイナリベクトル対応が、この問題をエレガントに解決します。
これは些細な技術的詳細に見えるかもしれませんが、重要な点を浮き彫りにしています。多様なデータ形式、巨大なスケール、そしてさまざまなエンタープライズ要件に対応できるよう、最初から設計されたデータベースが必要だということです。最初からエンタープライズグレードのシナリオを想定して構築していなければ、このような小さな互換性の問題でさえ、将来的に顧客体験の大惨事へと発展しかねません。
しかし、データ形式の課題は始まりにすぎませんでした。お客様は極限のパフォーマンスも求めていました。 統合プロセスの中で、クライアントは率直にこう言いました。「高精度なベクトル重複排除を即座に実行できる Zilliz Cloud サービスを、迅速に立ち上げる必要があります。インポートのたびに、780 次元の int32 署名データを含む 30GB のファイルを扱い、インポート処理全体を 15 分未満で完了しなければなりません。」
一見するとミッション・インポッシブルのように見えますが、私たちはすぐに答えを出しました。15 分どころか、4 分で完了させます。
このパフォーマンス上のブレークスルーは、Milvus の 2 つの主要な最適化によって実現しました。
第一に、従来のシリアルインポートのボトルネックを打ち破る、複数ファイルの並列処理を実装しました。これにより、システムは複数のデータファイルを同時に処理できるようになり、全体のスループットとインポート速度が大幅に向上しました。
第二に、タスクの複雑さと量に基づいて計算リソースをインテリジェントにスケジューリングする、動的リソース割り当てを統合しました。これにより、リソースの無駄や競合を排除しつつ、使用率を最大化できます。これらの最適化を組み合わせることで、Milvus は最新ハードウェアの能力とクラウドストレージの同時読み書き特性を最大限に活用し、ほぼリアルタイムのデータインポート体験を提供できます。
インポートの課題解決は第一歩にすぎません。大規模環境での迅速なデプロイと計算をどう処理するのでしょうか？
大規模 AI モデルのトレーニングシナリオでは、厳しい要件が重なり合う完璧な嵐が生まれます。膨大な流入データ量、巨大な既存データベース、そしてピーク時には毎秒 44,000 件のベクトル検索に達する負荷に対処しなければなりません。これは、ほとんどのシステムを押しつぶすような極端な同時実行性です。データが流入し続け、データベースが指数関数的に成長するにつれて、計算需要もそれに応じて増大し、システム性能に容赦ないプレッシャーをかけます。
この解決策には、本格的な分散コンピューティングの力が必要です。Zilliz Cloud のクラウドネイティブアーキテクチャは、インテリジェントなワークロード分散とエラスティックスケーリングを通じて、こうした課題に対処するために特別に設計されています。
秘密兵器：Cardinal Engine の統合
今後を見据えると、MinHash LSH は始まりにすぎません。私たちはこの機能を Zilliz Cloud 独自の Cardinal エンジンに統合しており、これにより非構造化データ処理が全体的にさらに高速化されます。
Cardinal は、最新の C++ と最先端の近似最近傍探索（ANNS）アルゴリズムを用いてゼロから構築された、次世代の AI 搭載ベクトル検索エンジンです。目標はシンプルです。同じハードウェアリソースで、より多くのユーザーリクエストを処理すること。
アルゴリズムレベルの最適化：Cardinal は、IVF やグラフインデックスなどのコアアルゴリズムに対して広範なパフォーマンスチューニングを提供し、速度とメモリ効率の最適なバランスを実現します。
エンジニアリングレベルのイノベーション：このエンジンは、カスタムメモリアロケータとインテリジェントなメモリプーリングを備え、検索パイプラインを柔軟に構成できるモジュール型コンポーネントアーキテクチャも採用しています。各パイプラインは、特定のミッションクリティカルなユースケース向けに細かく調整できます。
ハードウェア固有の最適化：Cardinal には複数の専用計算カーネルが含まれており、それぞれが特定のハードウェアプラットフォームとワークロードパターン向けに手作業で最適化されています。
これらの包括的な最適化により、Cardinal は24時間体制で最高効率で稼働し、業界をリードするベクトル検索性能を提供できます。Cardinal が Zilliz Cloud を支えることで、オープンソースの Milvus と比べて10倍の性能向上を達成し、超高速なクエリ速度と高いリコール率を両立しました。大規模なデータセットを処理する場合でも、電光石火の応答時間を求めるアプリケーションを構築する場合でも、Cardinal は優れたユーザー体験と競争力のある AI アプリケーションのための性能基盤を提供します。
未来は非構造化へ——そして私たちはその準備ができています
LLM トレーニングデータの重複排除は、はるかに大きな変革ストーリーの序章にすぎません。IDC は、2027年までに非構造化データが世界全体で約250ZBにまで爆発的に増加し、存在する全データの86.8%を占めるようになると予測しています。このデータは構造化データよりも処理と保存に大幅に高いコストがかかりますが、テキスト、画像、音声、動画、センサーログ、ソーシャルメディアコンテンツ、PDF、Webページ、コードリポジトリ、医用画像、衛星写真の中に閉じ込められた価値は無視できません。
これは、私たちの時代を決定づける課題を生み出します。指数関数的に増大する非構造化データから、コストを破綻させることなく、どのように効率的に価値を引き出すのか？
AI トレーニング向けに構築した重複排除機能は、このより大きなパズルの一片にすぎません。非構造化データが爆発的に増え続ける中で、同じ原則——インテリジェントなアルゴリズム、エンタープライズ規模のエンジニアリング、そしてクラウドネイティブの性能——は、あらゆるデータ駆動型組織にとって不可欠なインフラストラクチャになるでしょう。
未来は、非構造化データの混沌を構造化された競争優位へと変えられる企業のものです。私たちはその未来を、アルゴリズムを一つずつ積み上げながら築いています。私たちに参加する準備はできていますか？
AI トレーニングパイプライン向けの大規模重複排除を検討する準備はできていますか？Milvus 2.6 の MinHash LSH 機能について詳しくは 包括的なドキュメントをご覧ください。本番ワークロードには Zilliz Cloud （マネージド Milvus）をお試しいただくか、具体的なユースケースについて Discord で私たちのエンジニアリングチームにご相談ください。
読み続けて
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
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.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.