Web検索エンジンをゼロから2か月で3億件のニューラル埋め込みで構築する
(blog.wilsonl.in)- 検索エンジンの品質低下と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か月のうちに構築できるのかについて、システム・アルゴリズム・インフラ全般にわたる主要な設計／最適化事項を具体的に案内する。
1件のコメント
Hacker Newsのコメント
OpenAIの最新埋め込みモデルが、バッチ推論で100万トークンあたり$0.0001という非常に低コストを提供している点に驚いた。10億ページを各1,000トークンで埋め込んでも合計$100しかかからないことになる。自前でRunpodのスポットGPUを使って推論を回すと、これより100倍は高くつく。他のAPIコストはひとまず別の話だが、OpenAIがこうしてドメイン特化のソースデータを確保しようとする、一種のハニーポット戦略なのではないかと気になる。
記事の最後ではCommon Crawlデータを追加する考えに触れていた。私たちのチームのWebグラフベースのランキング情報は、どのページをクロールするか選ぶ際に大いに役立つと思う。大規模な実例を直接見せてもらえて興味深かったし、ベクターデータベースが予想外にコスト効率的なのにも驚いた。
心から感嘆した。記事も驚くほどよく整理されている。検索エンジンの核心はクレンジングされフィルタリングされたデータにあるという点に同意する（garbage in, garbage out）。LLMの訓練でも、結局は少量の高品質データのほうが重要だと改めて感じた。すべてのコンテンツをLLMに審査させて検索エンジンを作ったら、どんな性能になるのか気になる。
本当に敬意を覚える。これだけ多くの技術を集めて一つとして動かすのはすごいことだ。検索エンジンの決定的な価値は、実際のランキングアルゴリズムにあると思う。このプロジェクトでLLMがランキングにどう使われているのかはよく分からない。昔からあるランキング手法の一つに、実際のユーザーの検索→クリックデータを集めるものがある。これはまさに人間の検索語→クリックしたリンクという訓練データだ。数回クリックが集まるだけでもランキングは確実に改善する。このデータをニューラルネットに入れれば分類問題に変えてランキングを改善できるし、より多くの人がクリックするほど重みも大きくなる。
本当に驚くばかりだ。実際かなりうまく動いている。もし1万人が月$5ずつ購読してコストを賄えるなら、コミュニティ支援の検索エンジンもそれほど荒唐無稽ではない気がする。
encoder-only LLMを知っている人には、Googleは事実上もう終わっているのが明らかだ。Googleがまだ持ちこたえているのは、世界中のWebをクロールしてインデックスを常に最新に保つのに時間がかかるからだ。Common Crawlのようなオープンな組織や有料サービスがリアルタイムのWebクロール問題を解決すれば、Googleの25年の防壁は崩れ、検索そのものがコモディティ化するだろう。
さらに言えば、大企業ITのあらゆる機能別代替がリアルタイムで進んでいる様子を私たちは目の当たりにしている。モデルによって、企業の技術的 barriers も今や大きく下がっている。
一人でここまで作り上げたというのは、これまで想像もできなかった。商用検索エンジンともそこまで遠くないように見える。もしかするとGoogleにも追いつける距離かもしれない。年間$50,000で済むなんて信じられないほど安く、今すぐシードマネーを送りたいくらいだ。
本当に素晴らしいプロジェクトだ。有名検索エンジンではうまく出てこなかった質問（高解像度のウルトラワイドモニターのおすすめ候補）について、ここでも試してみたが、依然として大規模ランキングだけを専門に扱うメタページが、専門的な情報を持つページより上に出る現象がある。ランキングへの執着が強すぎるように見える。自分で答えを探すなら、ハードウェアフォーラムやいくつかのブログを選んで、スペックや長所短所を丁寧に比較するだろう。こうした分析を実際にそのサイトがやっているのか確認しにくいので、特殊なケースでは具体的なデータを引用しているサイトをより高く評価するほうが合理的だ。ユーザーとしては、分析に使われた元の資料を見たい。しかし現実の検索エンジンは、そのようにボトムアップでソースの根拠を持ち上げてはくれない。
本当に素晴らしいと思う。全部これに置き換えられるか試してみようと思った。多少時間の無駄になるかもしれないが、それでもぜひいろいろ検索して感想を残したい。全体としてはほぼ正しい方向へ導いてくれるが、100%ではなかった。たとえばlemmyでfediverseを探そうとしたら、liberapayのページが結果に出た。ぜひCommon Crawl連携の約束を守ってほしいし、archive.orgのような他のサイトも参照してほしい。AI業界には何十億ドルも投じられているのだから、こういう実験こそコミュニティファンディングや作業の分担によってうまく回り、成功してほしい。正直、今の検索エンジンのほぼ独占状態には多くの人がうんざりしている。Ecosiaも独自検索エンジンを準備中だと聞くので、ぜひこのプロジェクトと協業するか支援を受けてほしい。私は分散型（Decentralized）検索エンジンを心から望んでいる。持続可能性の観点からオープンソース化をためらう気持ちは理解できる。だが、膨大な資金がさほど意味もなく浪費されているのはもどかしいし、このプロジェクトには途方もない可能性があるので、どうかオープンソース化してほしい。コミュニティは最終的にクラウドファンディングなどで持続可能な方法を見つけ出せると信じている。まだ投稿を全部読み終えていないが、期待が大きすぎてまず使ってみた。記事自体も非常に掘り下げられていて、このやり方は他の人にも十分参考になると思う。正直、魔法のようで、久しぶりにこういうプロジェクトに最初から最後までわくわくした。オープンソース化が難しいことも、第三国という背景も分かるが、本当に自分の金から$50でも寄付したい気持ちだ。オンライン決済を一度もしたことがない自分が、これほど喜んで支援したいと思うほどだ。だからこそ、ぜひCommon Crawlなどを活用してコミュニティと一緒に進めてほしい。心からこのプロジェクトとキャリアの両方を応援している。
最近読んだ記事の中で最も洞察に富んでいた。コストを下げるために選んだ要素と、実際の削減ポイントを詳しく説明していたのが特によかった。ニューラル検索に焦点を当てていたが、BM-25 + 埋め込みを組み合わせたハイブリッド検索も試したのか気になる。それから、どのリランキングモデルが最も有用で効率的だったのかも聞いてみたい。
本当に面白い体験談だった。私もビジネス検索向けに似たものを開発していて、似たような課題に数多く直面している。クロール・処理・インデックス化は簡単だと思う人が多いが、大規模かつコスト効率よくやるのはまったく別問題だ。wilsonzlinに拍手を送りたいし、ぜひこの件について話してみたい。こういうものをe2eで自分で作る人は本当に少ない。