Web検索エンジンをゼロから2か月で3億件のニューラル埋め込みで構築する

 (blog.wilsonl.in)
1 ポイント 投稿者 GN⁺ 2025-08-13 | まだコメントはありません。 | WhatsAppで共有
  • 検索エンジンの品質低下とTransformerベースの埋め込みモデルの進化を背景に、2か月間で3億件の埋め込みベースWeb検索エンジンを開発した経験を扱う
  • 合計200台のGPUクラスター、大規模分散クローラー、RocksDB、HNSWなどの高性能インフラとアルゴリズムにより、リアルタイム自然言語理解検索を実現
  • キーワード一致ではなく意図中心のクエリ応答を目標に、文書パースと文脈保持のための正規化、チャンキング、文連結など多様なNLP/ML手法を適用
  • パイプライン、ストレージ、サービスメッシュ、ベクトルインデックスなど各レイヤーごとの大規模分散システム設計とボトルネック／コスト最適化策を紹介
  • 最終的に超低遅延、大規模分散、高精度のパーソナライズ検索エンジンが誕生したことを述べる

概要と動機

  • 筆者は最近の検索エンジン品質低下、SEOスパム、無関係コンテンツ増加への問題意識と、Transformerベースの埋め込みモデルの自然言語理解力が高まった環境を受け、検索エンジンをゼロから構築することを決めた
  • 既存検索エンジンの限界は、人間レベルの質問理解力の不足とキーワードベースの単純な一致に由来する
  • 良質なコンテンツが常に上位表示され、長いテール部分まで偏りなく探索する意図中心ランキングが目標
  • Web検索エンジン構築の過程は、計算機科学、言語学、オントロジー、NLP、ML、分散システム、性能エンジニアリングなど多様な領域を包含する
  • 今回のプロジェクトは、2か月のあいだインフラや事前経験なしに純粋に一人で始め、完全に新しい検索エンジンを実装する挑戦

全体システム構成

  • 200台のGPUクラスターでSBERTベースのテキスト埋め込み3億件を生成
  • 同時に数百台のクローラーが毎秒50,000ページを収集し、合計2.8億件のインデックスを構築
  • RocksDBとHNSWを200コア、4TB RAM、82TB SSDにシャーディングして保存・インデックス化
  • クエリ応答の全体遅延時間は約500msに設定
  • 全体構造とフローは、クローラー、パイプライン、ストレージ、埋め込みベクトルインデックス、サービスメッシュ、フロント／バックエンド領域に分離される

埋め込みベース検索の実験と改善

Neural Embedding Playground

  • SBERTなどの埋め込みモデルを活用した検索は、従来のキーワード中心検索より自然なクエリ理解と精度が高いことが実験で確認された
  • 入力クエリの意図を文脈および文単位で把握し、実際に関連性の高い正答を抽出できる

従来検索 vs. ニューラル検索の例

  • 従来検索: ランダム性のある結果、キーワード一致中心
  • 埋め込み検索: 質問の文脈と意図を把握し、正確な中核文または概念中心の結果を提供
  • 複雑な概念の組み合わせ、暗黙的／複合的な質問、品質シグナルを含むクエリに対して意味ベースで正答を探索可能

Webページのパースと正規化

  • HTMLから意味的なテキスト要素のみを抽出し、レイアウト・制御要素などのノイズを除去する正規化が目標

  • WHATWG、MDNなどの標準に合わせて、p、table、pre、blockquote、ul、ol、dlなどテーブル構造を維持

  • メニュー、ナビゲーション、コメント、インターフェースなどのクローム要素を完全に除去

  • サイトごと（例: en.wikipedia.org）に特殊ルールを適用し、過剰抽出／不足抽出の問題を解決

  • 意味ベースの構造化データ（meta、OpenGraph、schema.orgなど）も活用し、知識グラフ構築とランキング改善が可能

チャンキングと文脈保持

文単位チャンキング

  • 埋め込みモデルの限界を克服するため、ページ全体ではなく文ベースの単位チャンキングを適用
  • チャンキング時には自然な文境界、文法、省略、URL、非公式表現など多様なケースをspaCy sentencizerで正確に区別

文脈保持と連結

  • 文同士の依存関係、見出し、段落、表などを把握し、文脈情報までまとめて埋め込み
  • 例えば表構造も各行の意味を失わないよう、上位見出し／条項などを連鎖的に連結して挿入

文連鎖（Statement Chaining）

  • DistilBERT分類器で1つの文と前の文を一緒に分析し、文脈依存性の確認とチェーン抽出を自動化
  • 埋め込み時には上位の従属文をすべて含め、文脈保持力を高める

プロトタイプ活用結果

  • サンドボックス環境で多様な実戦クエリを試した結果、従来手法と比べてはるかに正確な（文脈適応型）クエリ応答を確認
  • キーワード不一致、省略／比喩／複合質問などでもアプリが意図を認識し、正しい文脈文を対応付け、隠れた知識や関係も効果的に発掘

大規模Webクローラー（ノードベース）

  • 作業分散のためのワークスティーリング、ドメイン別同時実行性／トラフィック制御、DNS／URL／ヘッダー検証など、さまざまな安定性・効率性を考慮
  • クローラーには非同期I/OベースのPromise、DDoSに強いメカニズム、リソース管理（メモリ、遅延、バックオフ）、ノイズドメイン検知などを適用
  • URL正規化、プロトコルおよびポート／ユーザー情報制限、Canonicalizationによって重複／異常URLフィルタリングを強化

パイプライン（分散タスクキュー）

  • 各ページ状態をPostgreSQLで管理し、初期には直接Polling／トランザクションを活用
  • 大規模分散環境（数千クローラー）ではスケール問題、待ち行列／ロックのボトルネックが発生し、Rustベースのインメモリコーディネーターでキュー状態を管理
  • タスク構造: ハッシュマップベースのインデックス、バイナリヒープ、ドメイングループ、ランダムPoll、入れ替え（swap_remove）など多様なインデックス化
  • タスクごとのメモリは100B水準で、128GBサーバーなら10億タスクも処理可能
  • その後、SQS代替用としてオープンソースのRocksDBベース待ち行列を開発し、1ノードで毎秒30万opsをサポート

ストレージ設計（Oracle → PostgreSQL → RocksDB）

  • 初期はOracle Cloud（低コストegress／保存）、その後PostgreSQL（TOAST）まで使用したが、書き込みスケール／性能の限界に直面
  • PostgreSQLのMVCC、Write Amplification、WALなどの特性上、大規模並列INSERTでボトルネックが生じ、最終的にKVストアのRocksDBへ移行
  • RocksDBのブロブ分離保存（BlobDB）、SSTファイル、マルチスレッド、ハッシュインデックス化などでNVMe SSDの最大性能を活用
  • 64個のRocksDBシャードへ拡張し、各シャードはxxHash(key)ベースのルーティング、Serde+MessagePackシリアライズを使用
  • 最終的に数千クライアント（クローラー／パーサー／ベクトライザー）から毎秒20万opsを処理し、メタデータとブロブを分離・圧縮保存

サービスメッシュとネットワーキング

  • インフラ拡張時のサービスインスタンス自動探索／通信セキュリティのため、mTLS+HTTP2ベースで設計
  • 各NodeにルートCAベースの証明書を適用し、MessagePackシリアライズを直接利用、内部DNSとCoreDNS、カスタムクライアントSDKなどを開発
  • 既存VPN（ZeroTier、Tailscale）利用経験はあったが、ネットワーク／性能／運用上の問題から独自のHTTP+mTLSを選択
  • システムサービス制御（systemd + cgroup + journald）で管理を一元化し、軽量化と標準化を実現

大規模GPU埋め込み生成パイプライン

  • 当初はOpenAI APIを活用したが、コスト問題からRunpodなどの高性能GPU環境へ移行
  • パイプラインは各ステージを非同期に分離し、GPU効率90%以上、250台のGPUで毎秒10万embeddingsを生成
  • Rustパイプライン、Python inference → named pipeによるIPC、構造化バックプレッシャーでリソースを自動調整

ベクトルインデクシング（HNSW/シャーディング）

  • HNSWアルゴリズムを用いたメモリベースのベクトル検索で、ANN（Approximate Nearest Neighbor）により超低遅延を実現
  • RAM限界到達時にはノードごとの均等シャーディング（64ノード）を行い、各シャードは個別のHNSWインデックスとして並列検索
  • HNSWの特性上、大量のRAMが必要でライブ更新にも限界があるため、最終的にCoreNNというディスクベースのオープンソースベクトルDBへ移行
  • CoreNNは128GB RAM、単一ノードでも30億件の埋め込みを高精度で検索可能

検索エンジンUXと遅延最適化

  • 検索エンジンUXでは即時応答が中核（ローディングインジケーターなし、伝統的なSSR）
  • Cloudflare ArgoなどでエッジPoPに近づけ、HTTP/3を採用して転送遅延を最小化
  • アプリサーバーレベルですべてのデータを用意し、個別APIラウンドトリップを最小化、ミニファイ・圧縮済みページを即時応答

この要約は、最新の自然言語処理・ML技術を適用した大規模Web検索エンジンが、どのようにエンドツーエンドで2か月のうちに構築できるのかについて、システム・アルゴリズム・インフラ全般にわたる主要な設計／最適化事項を具体的に案内する。

関連記事

まだコメントはありません。

まだコメントはありません。