HAKARI-Bench - 実運用視点での情報検索モデル評価ベンチマーク

Search Engineering Tech Talk 2026 Summer での登壇資料です

----

https://huggingface.co/spaces/hakari-bench/leaderboard
https://github.com/hakari-bench/hakari-bench
https://arxiv.org/abs/2606.22778 HAKARI-Bench: A Lightweight Benchmark for Comparing Retrieval Architectures and Efficiency Settings under Unified Conditions

Transcript

1. 実運用視点での情報検索モデル評価ベンチマーク HAKARI-Bench 舘野 祐一 / @hotchpotch / id:secondlife Search Engineering Tech Talk 2026 Summer - 2026/07/23
2. で、誰?
3. 自己紹介 舘野 祐一, Yuichi Tateno id:secondlife, セコン @hotchpotch https://secon.dev/ 小さな法人代表のソフトウェアエンジニア ご家庭用GPUでも学習できるモデル好き 情報検索関連 JQaRA: 検索拡張(RAG)評価のための日本 語 Q&A データセット JaCWIR: 日本語情報検索評価のための小 規模でカジュアルなWebタイトルと概要の データセット 🍷 FineWeb2 Edu Japanese - 高品質 な教育向け日本語データセット 日本語Reranker 日本語SPLADE 関連しない文削除モデル OpenProvence
4. 「セマンティック検索ができる検索システムを作る。 対象言語は英語・日本語。コード検索も行いたい。 検索サーバの費用はあまりかけられない。 性能と運用費を考え、調査・選定して」 🤔
5. 検索精度の評価 英語の汎用検索評価: BEIR 埋め込み全般: MTEB / MMTEB MTEB系は、検索(Retrieval)タスクは一部 MMTEB はよく利用されるが、131タスク中 Retrieval は 18 タスクのみ コード検索: CoIR, CodeRAG-Bench 長文検索: LongEmbed, MLDR 日本語(JMTEB)、多言語、法律など、様々なドメインのベンチマーク
6. 実運用では、精度だけでは選べない モデル推論速度 クエリ・文書の推論(エンコード)速度 Active Parameters (AP) が支配的 総パラメータ数はこれに token 参照テ ーブルの static embedding が追加 ただし実速度は、系列長・実装・ハードウ ェアにも左右される 検索エンジンの検索速度 👉 今回の主題はこちら (密ベクトル検索の場合) ベクトル次元数 小さいほど省メモリ、省ストレージ・推 論速度向上 量子化 int8 / binary
7. 全てを考慮して選定が必要 精度に加え、実際の検索エンジンでの速度など、考える項目は多い 比較対象のモデルで、必要なベンチマークがすべて揃っていることも、ほとんどない 👉 そこで、評価に必要な情報をまとめて計測・表示できる仕組みを制作
8. HAKARI-Bench 多言語・多領域の35ベンチマーク(551タスク)の検索タスクを横断評価 1 task あたり 200 query 10,000 docs に小型化 情報検索タスクのみを取り扱う dense / BM25 / sparse(SPLADE) / late-intraction(ColBERT) 主な検索方法にすべて対応 次元削減(マトリョーシカ埋め込み)・量子化(int8, binary)も計測 reranker も35ベンチマークすべてで評価可能 これらの評価基盤 + 評価ビュワーが HAKARI-Bench (なお、leaderboard では、ほぼ重複タスクを除いた538 tasksで表示)
9. HAKARI-Bench Leaderboard GitHub Paper: arXiv:2606.22778
10. 例: 日本語性能の切り口で見る 日本語タスクで絞る lang: JA でフィルター 大体 JMTEB-v2, BEIR-ja の検索タス ク JMTEB は日本語ドメイン NanoBEIR-ja は英語NanoBEIRの日本 語翻訳 JMTEB は日本製モデルが強いが、 BEIR-ja はマルチリンガルモデルが強い 再現URL 何を重要視する？ ベンチマークのタスクを理解する Task columns 表示、説明をクリック 例: MNanoBEIR / NanoBEIR-ja / NanoClimateFEVER タスクのサマリの確認 タスクによって強い・弱いが分かれる 本当に評価したいタスクを知る
11. 例: 他の切り口で見る lang: EN, Code でもフィルター RTEB, LongEmbed など特定ベンチマークで見る ActiveParams や次元数ででフィルターする などなど
12. 例: Reranking で見る Reranking 実際の検索システムをシミュレート まずドキュメント絞り込み -> 次に reranker でさらに rerank Dense + BM25のハイブリット検索結果 Top-100 に対しての reranking task Top-100 のソートタスクとなる 計算コストが大きい reranker でも計測 可能 結果があまりかわらない？ reranker は短いクエリ・ドキュメントで 学習 query len < 70, doc len < 1000 などに 絞る 短いクエリとドキュメントのみを対象に 👉 bge-reranker-v2-m3 がトップレベ ルの性能に 再現URL
13. 例: Chart ビューで見る 3次元プロット 標準では Borda Score, AP, Dims 俯瞰で見れる
14. 検索システム視点で見る
15. 次元削減 Gemini Embedding 2での例 Gemini Embedding 2 Matryoshka Representation Learning MRLなどで学習済みモデルの場合、次元 削減が可能 標準は 3,072 次元 1536, 768, 512, 256 次元削減も対応 次元を落とせば、ストレージ・メモリ・類似 度計算の高速化が可能 Dims variants に✅ 次元削減したら、精度にどれだけ影響がある のか？ 768次元までは「ほぼ影響なし」 512次元は若干落ちる 256次元からはぐっと落ちる 再現URL
16. 出力ベクトルの量子化 出力ベクトルの fp16 を int8(1/2), binary(1/16) などに量子化 量子化手法もいろいろあるが、シンプルな量子化でざっくり量子化耐性を見る 近似最近傍探索における新しいビット量子化手法、RaBitQとBBQ TurboQuant in Qdrant 検索モデル学習時に、量子化を考慮した学習を行うことで、量子化時に性能劣化を防ぐ Quantization-Aware Training of jina-embeddings-v4 ※なおモデル自体の重みの量子化ではなく、出力ベクトルの量子化であることに注意！
17. 量子化と検索精度 GeminiEmb2 の場合 Qurantization variants と Dims に✅ 3072次元では binary の方が若干性能が良い(!) 精度と削減を考えると、768d + int8 がバランスが良い。 768 + binary もfp16から見ると1/16に削減、精度劣化も3.6%と許容範囲な場合も (なお実際は1/16容量にはならず、ANNのindexデータも別途計上される) 再現URL mE5 の場合 multilingual-e5, e5 は量子化耐性が悪い int8 はまだしも binary が壊滅的に悪い(30-66%劣化) mE5 + binary 量子化で検索システムを作ると、かなり悪い結果に 再現URL
18. rescore - 再スコアリングで精度を上げる rescore とは？ 量子化すると検索精度が落ちる しかし、Top-N には正解がある可能性も 量子化前ベクトルで rescore (再スコア付) することで精度改善 検索エンジンは、量子化前ベクトルも保存 できる実装が多い Top-100 の結果を rescore で計測 再現URL 全モデルでの傾向 binary 単独: -6.9%精度劣化 binary + float rescore: -0.9% 精度劣化 int8 + float rescore: -0.1% 精度劣化 rescore すると、HakariのNano-set(対 象文章が少なめ)では、ほぼ結果を維持でき る
19. 他にもいろいろ dense だけでなく、sparse / late interaction / BM25 を比較 一覧にないモデルも Hakari の同一条件で評価 今回は「結果閲覧」の話が主だったが、もちろん別モデルも評価可能 というか、自作モデルを、多言語・多様な検索で評価したかったから作った
20. まとめ 実運用視点での情報検索モデル評価ベンチマーク 多様なドメインでのタスク評価 次元削減・量子化など、本番運用で知りたい切り口の結果 ご活用ください！
21. ご清聴ありがとうございました お気にいったら、Hugging Face Spaces / GitHub に star, like をもらえると励みになります！ Leaderboard · GitHub