3 か月前、私たちは Papers with Code の再興 に着手しました（告知ツイートも参照）。その目的は、オープンな AI 研究を見つけやすく、理解しやすいものにすることです。論文に関連する成果物を簡単に見つけ、AI のさまざまな分野における最新の技術水準（state-of-the-art、SOTA）を把握し、興味深い研究を共有し、互いの成果を土台にさらに発展させられるようにします。言い換えれば、研究の波を前進させ、次の Transformer を生み出すことが目標です。
もちろん、AI 研究を見つけやすくするには、人間とエージェントがウェブサイトや pwc search CLI コマンドを使って、関連性の高い研究や類似した研究をすばやく見つけられる強力な検索エンジンが必要です。エージェントは、Skillを通じてこのコマンドを利用できます。
ただし、研究成果の検索は、一般的なテキスト検索とまったく同じではありません。優れた論文検索エンジンは、正確なタイトルや arXiv 識別子を見つけられるだけでなく、「コード生成のための小規模言語モデル」のようなクエリも理解できる必要があります。たとえ論文中で、これらの単語がそのような形で連続して登場しなくてもです。また、「最初の BERT 論文」のようなナビゲーション型のリクエストを認識し、不完全なタイトルやスペルミスにも対応する必要があります。さらに、モデルサービスがコールドスタート中であったり、一時的に利用できなかったりする場合でも、すばやく結果を返さなければなりません。
Papers with Code における「DINO」の検索結果。
Papers with Code では、**ハイブリッド検索（hybrid search）**システムとして構築しました。これは、以前 ML6 で培った経験に基づいています。そこで私たちは、顧客向けに RAG ベースのシステムを開発していました。ハイブリッド検索は、キーワード検索またはベクトル検索だけに基づくシステムを上回ることが多く、両者の長所を組み合わせられることが分かっています（詳しくはこちらのブログ記事も参照してください）。キーワード検索は正確に一致する言及を見つけるのに対し、ベクトル検索は、より曖昧で意味的に近い用語を見つけられます。なお、リランカー（reranker）（クロスエンコーダー、cross-encoder とも呼ばれます）を使えば結果をさらに改善できますが、追加のコストとレイテンシが発生します。
ベクトル検索またはキーワード検索だけの場合よりも優れたハイブリッド検索。グラフは Microsoft の Azure AI Search：ハイブリッド検索とリランキングでベクトル検索を上回る（2023 年）より。
Papers with Code は PostgreSQL データベースに依存しているため、その全文検索機能を高速な字句検索のベースラインとして利用できます。密ベクトル埋め込みには pgvector を使用してセマンティックな再現率を高め、両者を逆順位融合（reciprocal rank fusion、RRF）アルゴリズムで組み合わせています。密ベクトル埋め込みは、以下 3 つの Hugging Face サービスによって支えられています。
-
Hugging Face Jobs は、論文コーパスの埋め込み生成に、必要に応じて利用できる GPU コンピューティング能力を提供します。
-
Hugging Face Storage Buckets は、データベース、実験、Jobs の間で永続的なデータ受け渡しを提供します。
-
Hugging Face Inference Endpoints は、オンラインクエリと増分更新向けに、低レイテンシの埋め込みサービスを提供します。
現在、このシステムでは arXiv と Daily Papers に由来する 11 万件を超える既存論文の埋め込みを管理しています。本稿では、そのアーキテクチャ、設計上の判断、そして本番環境に導入する過程で得られた知見について説明します。
TL;DR
検索を、オフラインでのコーパス構築とオンライン検索サービスの 2 つに意図的に分離しました。
オフラインのコーパス構築とオンラインのハイブリッド検索パイプラインのアーキテクチャ。
コストが高く、スループット重視の処理は Jobs が実行します。永続化する成果物は Bucket に保存します。リクエストチェーン上にあるのはクエリ埋め込みという小さな処理だけであり、保護された Inference Endpoint がこれを担うことで、オンライン検索に対応します。エンドポイントがコールドスタート中、ビジー状態、または不健全な状態にある場合、検索はただちに全文検索へフォールバックします。この分離により、高機能でありながら高速なシステムを実現できます。
厳密な埋め込み契約から始める
埋め込みパイプラインは、気づきにくい形で失敗することがよくあります。モデルのバージョンが変わったり、クエリ用のプロンプトとドキュメント用のプロンプトが混在したり、ベクトルの切り詰め方が一致していなかったり、更新後の要約と保存済みのベクトルが一致しなくなったりするためです。
こうした問題を避けるため、埋め込みの形式をバージョン管理された API として扱っています。各論文は、次の形式でエンコードします。
normalized title + "\n\n" + normalized abstractベクトルを生成するたびに、以下の情報を記録します。
- モデルリポジトリとその正確なバージョン
- 出力次元数
- 入力形式のバージョン
- 入力がクエリかドキュメントか
- 正規化方式
- 元のタイトルと要約のコンテンツハッシュ
本番環境では Qwen/Qwen3-Embedding-0.6B を使用し、正確なバージョンを固定したうえで、256 次元の L2 正規化済みベクトルを生成しています。このモデルは MTEB ランキングをもとに選定しました。MTEB は、埋め込みモデルの比較に広く使われているベンチマークです。なお、Qwen3 などの新しい埋め込みモデルは、次の 2 つの新機能をサポートしています。
-
動的な埋め込みサイズを指定できるため、品質と速度、ストレージコストの間でトレードオフを調整できます。Qwen モデルではこれを「MRL」、つまり Matryoshka Representation Learning（Matryoshka 表現学習）と呼んでいます。詳しくはこちらをご覧ください。私たちは検索速度を高めるため、埋め込み次元数として 256 を選択しました。
-
命令プロンプトを指定できます。Qwen の埋め込みモデルは
documentプロンプトをサポートしており、論文の埋め込みに使用しています。一方、オンライン検索ではqueryプロンプトを使用してユーザーのクエリを埋め込みます。
この契約は、埋め込みのエクスポート、GPU 推論、PostgreSQL への書き込み、そして最終的なオンライン検索での利用に至るまで、埋め込み処理全体を貫いています。
Jobs でデータベースのスナップショットをベクトルコーパスに変換する
コーパス全体の埋め込み生成は、典型的なバッチ処理タスクです。比較的短時間だけ GPU を使用し、高いスループットの恩恵を受けられる一方、実行の合間にリソースを継続して占有すべきではありません。Hugging Face Jobs は、このようなタスクに適しています。1 つの Job は、コマンド、ハードウェア仕様、オプションの Docker イメージによって定義され、依存関係をインラインで宣言できる uv スクリプトを実行できます。
コーパス構築パイプラインではまず、再現可能な読み取り一貫性を持つ PostgreSQL スナップショットから、各論文の最新バージョンをエクスポートします。エクスポーターはカタログ全体をメモリに読み込むのではなく、データ行をストリーミングで読み取ります。そして、サイズを制限した JSONL シャードを書き出し、行数と SHA-256 チェックサムを含むマニフェストを作成します。
この不変の実行ディレクトリを、プライベートな Storage Bucket に同期します。