Papers with Code の検索:0.9955は何本で測った値か
Hugging Face が公開した Papers with Code の検索基盤の数値を、条件つきで読み分けられます。Recall@20 0.9955・p50 1.31ms・毎秒約75本が、それぞれどのコーパス規模・どの次元・どのハードで測られた値なのかを、原典(2026年8月21日)から整理しました。
答え 5,000本パイロット・256次元 0.9955 再現率 Recall@20・厳密探索比
この記事は海外の一次情報をAIエージェントが調査・検証して整理したもので、実際に試した体験談ではありません。
結論:0.9955 は5,000本での値で、11万本での値ではない
Hugging Face が2026年8月21日に公開した公式ブログ『How Hugging Face Inference Endpoints, Jobs, and Buckets Power Search on Papers with Code』(著者 Niels Rogge ほか)によると、Recall@20 0.9955 と p50 1.31ミリ秒・p95 2.21ミリ秒は、5,000本の論文によるパイロットにおける256次元インデックスの値です。
同じ記事は、本番システムが arXiv と Daily Papers 由来の11万本超(more than 110,000)の現行論文の埋め込みを保持していると述べていますが、その規模での Recall@20 と HNSW レイテンシは記載していません。
以下の数値はすべて Hugging Face 自身の発表によるもので、第三者による追試は2026年8月26日時点で確認できていません。
数値ごとの測定条件
性能とスループット
| 原典の数値 | 指標 | 測定条件 |
|---|---|---|
| Recall@20 | 0.9955 | 5,000本パイロット・256次元・厳密探索を正解としたANN再現率 |
| p50レイテンシ | 1.31 ms | 5,000本パイロット・256次元・HNSWルックアップ |
| p95レイテンシ | 2.21 ms | 5,000本パイロット・256次元・HNSWルックアップ |
| 符号化スループット | 約75本/秒 | 5,000本パイロット・1024次元・NVIDIA L4 GPU(l4x1、VRAM 24GB) |
| ストレージ | 約27% | 1024次元版に対する256次元版の使用量(同テスト内) |
ここで混ざりやすいのが、GPU がどの数値に紐づくかです。原典が L4 GPU を挙げているのは埋め込み生成 Job の実行環境としてであり、紐づくのはスループットだけです。HNSW ルックアップは PostgreSQL と pgvector 側の処理で、原典はその実行環境(インスタンス種別・メモリ・PostgreSQL の設定)を書いていません。
構成と運用のパラメータ
| 項目 | 原典の記載 |
|---|---|
| 埋め込みモデル | Qwen/Qwen3-Embedding-0.6B(厳密なリビジョン固定) |
| ベクトル | 256次元・L2正規化(Matryoshka 表現を切り詰めてから正規化) |
| 語彙ブランチ | 重み付き PostgreSQL 全文検索・最大50件 |
| セマンティックブランチ | pgvector・最大50件 |
| 統合 | 重み付き Reciprocal Rank Fusion、現時点は重み等分・k=60 |
| クエリ側タイムアウト | 1秒(本番) |
| エンドポイント | 最大1レプリカ・アイドル時にゼロへスケール |
| 増分処理 | 1時間ごと・1回あたり最大500本・バッチサイズ16 |
Qwen チーム(Alibaba)のモデルカードによると、このモデルのネイティブな埋め込み次元は1024で、MRL(Matryoshka Representation Learning)に対応し32から1024の範囲で出力次元を指定できるとされています(2026年4月時点のモデルカードの記載)。原典は256次元を選んだ理由を「検索を速くするため」と説明しています。
原典の数値を自分の見積もりに読み替える手順
- その数値が書かれている文の条件節を先に読む。 性能値については、原典で条件が示されているのは「5,000本パイロット・256次元」の1文だけです
- コーパス規模・出力次元・ハードウェアの3つを必ず添えて引用する。 3つのうち1つでも自社と違えば、そのまま持ち込める値ではありません
- 自社の規模での値が原典にあるかを確かめる。 本記事の題材では、11万本超での Recall@20 とレイテンシは原典に存在しません
- 無い値を外挿で作らない。 たとえば「毎秒約75本」から本番コーパスの処理時間を割り算で出しても、それは原典の主張ではありません(原典はフルコーパスの生成に要した実時間を書いていません)
誤読しやすい3点
「約27%」はストレージ削減率ではない
原典は、256次元版のテーブルとインデックスが1024次元版のストレージの約27%を使ったと述べています。27%は残った割合であり、削減幅に直すと約73%減にあたります。「27%削減」と訳すと効果を大幅に小さく伝えることになります。さらにこの比較には「そのテストにおいては ANN 再現率をほぼ同じに保ったまま」という限定が付いており、次元削減が本番の検索品質に与えた影響の実測値は原典にありません。
Recall@20 は「検索精度」ではない
0.9955 は厳密探索(総当たり)の上位結果を近似最近傍探索がどれだけ再現できたかを示す値です。検索結果が利用者にとって適切かどうかの精度とは別の指標であり、「検索精度99.55%」と読み替えると原典の主張が変わります。
1秒のタイムアウトはクライアント側の挙動
原典によると、1秒の本番タイムアウトはクエリを送るクライアントに実装された挙動です。エンドポイント側の設定として原典が明記しているのは、最大1レプリカとアイドル時のゼロスケールだけです。エンドポイントが起動中・タイムアウト・不正なベクトルを返す・同時実行の空きが無いときはセマンティックブランチを即座に飛ばし、利用者には語彙検索の結果を返すと説明されています。増分処理でも、書き込み前にソース行をロックして内容ハッシュを再確認し、推論中に変更された論文のベクトルは破棄して次回に回すとされています。
関連記事
インデックスのサイズが比較相手によって何倍にも見える問題はマルチベクトル検索の「約42倍」の比較相手を整理した記事で、公開ベンチマークの数値をそのまま自社の判断に使えるかという論点は日本語ラベルを学習に使っていない多言語検索モデルの記事で扱っています。本記事の数値は2026年8月26日に原典で照合しました。最新の状況は公式サイトでご確認ください。
参考にした情報源
全2件のうち0件 が公的機関の公開資料です。