這項研究由獨立研究者田野雄一（Yuichi Tateno）完成，以預印本形式發表於2026年6月，論文編號為arXiv:2606.22778，感興趣的讀者可通過該編號查詢完整論文。
**研究概要：當"找東西"這件事變得越來越複雜**
每天你都在用各種"找東西"的工具——搜尋引擎、智能客服、AI問答助手。這些工具之所以能準確找到你想要的內容，背後都依賴一種叫做"文本檢索模型"的技術大腦。這個大腦的工作原理，有點像圖書館裡一位經驗豐富的管理員：你說出你的需求，它迅速從數百萬本書中找出最相關的那幾本。
但隨著AI技術的飛速發展，這樣的"圖書館管理員"越來越多，種類也越來越複雜。有的擅長處理英文，有的精通多種語言；有的專注於代碼搜索，有的善於處理醫學文獻。面對這麼多候選者，我們怎麼公平地評估它們誰更厲害？過去的做法是給它們做一套龐大的考試——每次考試動輒包含數百萬道題，耗時極長，成本極高，普通開發者根本無法頻繁使用。
更棘手的問題是，在實際部署這些"管理員"時，我們經常需要做出取捨：是用原始的完整版本，還是把它壓縮一下節省空間？是保持全精度運算，還是降低精度換取速度？這些"節能模式"下的性能表現，幾乎沒有人在同一套標準下系統地比較過。
正是為了解決這些問題，田野雄一構建了一套名為HAKARI-Bench的輕量級評測基礎設施。"HAKARI"來自日語中"秤"（はかり）這個詞，寓意公平稱量、精準比較。這套系統把現有的各類大型評測題庫精心壓縮成小型"納米題集"（Nano-sets），覆蓋35個基準測試集、551個檢索任務、43種語言，並能在同一條件下同時評估五大類檢索技術方案，還能統一比較各種"節能壓縮"配置下的性能變化。最令人印象深刻的是，這套輕量化工具產出的模型排名，與原始大型評測的相關性高達Spearman 0.97以上——換句話說，用這把"小秤"稱出來的結果，和用"巨型工業天平"稱出來的幾乎一樣可靠。
---
**一、為什麼我們需要給"圖書館管理員"評分？**
回到那個圖書館的比喻。現代AI系統里有各種各樣的"管理員"，它們的工作方式大相徑庭。有的管理員靠關鍵詞匹配（這就是傳統的BM25方法，類似於按書名索引查書）；有的管理員把每本書提煉成一段"語義摘要"，通過比較摘要的相似度來找書（這是稠密檢索，也叫dense retrieval）；有的管理員則維護著一張超大的關鍵詞權重表，對稀疏出現的專業詞彙特別敏感（這是稀疏檢索，SPLADE系列模型）；還有一種高級管理員不滿足於整體摘要，會逐詞逐句仔細比對查詢和每本書（這是後期交互，ColBERT系列）。此外還有一類專門的"覆審官"——它們不負責從海量書庫中初步篩選，而是拿到初步候選名單之後再仔細精讀、重新排序（這就是重排序器reranker）。
這五種角色在真實的搜索系統里各有分工，有時候單獨使用其中一種，有時候組合使用。但過去大多數評測體系要麼只關注某一類，要麼雖然都覆蓋了，卻用不同的規則來評判它們，就像用不同標準的卷子同時考不同的學生，結果根本無法橫向比較。
BEIR這個由德國達姆施塔特工業大學等機構聯合提出的評測基準，是第一個嘗試用同一套規則來同台比較這五類檢索方案的框架，成為了業內的重要參考。之後MTEB（大規模文本嵌入基準）和MMTEB（大規模多語言版本）進一步擴展了評測的廣度，覆蓋了數百種語言和500多個任務。然而，這些系統都有一個共同的痛點：太重了。跑一次完整評測需要消耗大量計算資源和時間，開發者在日常調試模型時根本不可能頻繁使用。而且，當你想測試"如果把這個模型的向量維度從1024壓縮到256，性能會損失多少"這類問題時，現有框架幾乎沒有統一的答案——每個模型團隊各自測各自的，結果無法直接比較。
NanoBEIR是一個方向正確的先驅——它把BEIR的每個數據集壓縮成約50個查詢和最多一萬篇文檔的小規模版本，大大降低了評測成本。但NanoBEIR僅限於英文領域，也沒有系統性地覆蓋維度壓縮和量化等效率配置的評測。HAKARI-Bench的核心野心，正是在繼承這些前輩優點的基礎上，把這把"秤"做得更大、更全面、更公平。
**二、這把"秤"是怎麼造出來的？**
造一把好秤，首先需要設計好刻度盤，其次需要確保每次稱量的條件完全一致，最後需要驗證這把秤的讀數和"標準秤"有多大偏差。HAKARI-Bench的設計思路完全遵循這三個原則。
刻度盤的設計，體現在納米題集（Nano-sets）的構建方式上。研究者從現有的大型評測數據集中抽樣，每個任務保留約50到200個查詢、約1000到1萬篇文檔。這個壓縮比例頗為激進，相比原始數據集動輒數十萬篇的文檔規模，縮減了幾個數量級。具體的抽樣方法是：先從原始數據集裡挑選最多200個不重複的查詢，每個查詢至少有一個已知相關文檔；然後把所有被選中查詢的相關文檔全部保留；剩餘的文檔配額，優先填入"已知不相關"的困難負樣本，最後按原始順序填滿。這樣構建出來的小題集，保留了原始數據集裡最有區分度的部分，同時把無關的"背景噪音"儘量剔除。
確保稱量條件一致，體現在候選集的設計上。這是HAKARI-Bench最精妙的設計之一，也是它能同台比較"初步篩選型管理員"和"精讀覆審型覆審官"的關鍵所在。對於每個任務，系統預先用兩種方式各自檢索出前500篇候選文檔——一種是傳統的關鍵詞匹配方法（BM25），另一種是用一個固定的通用稠密檢索模型——然後把兩個候選列表用一種叫做"互惠排名融合"（RRF）的方法合併，取前100篇作為最終的固定候選集。這個候選集一旦確定，就保存下來供所有模型使用。
為什麼這樣設計很重要？因為這意味著不同的模型在"精讀覆審"階段面對的是完全相同的100篇文章，任何性能差異都純粹來自模型自身對相關性的判斷能力，而非因為候選集不同導致的基礎條件差異。此外，系統還設置了一個"保障規則"：如果某個查詢對應的100篇候選文檔里碰巧沒有任何相關文檔，就強制把一篇相關文檔添加到第101位。這確保了每個查詢至少有一篇相關文檔可以被排序，讓覆審型模型的評測具有實際意義。
整套系統的架構是一條清晰的五段流水線。第一段是任務規格說明，把每個數據集的來源、版本（精確到代碼倉庫的提交哈希值）、語言和領域類別寫成聲明式配置文件。第二段是統一任務格式，確保所有任務都遵循"文檔庫+查詢+相關性標註+固定候選集"這個四元組結構。第三段是評測執行，對五大類模型以及各種效率變體統一運行。第四段是結果儲存，所有運行結果以統一的模式存入資料庫，包括每個查詢的前100名排序、各類指標分數、數據集版本記錄等。第五段是聚合與展示，結果匯總到DuckDB數據倉庫，並以多維度過濾的排行榜形式對外呈現。
在這套體系中，數據集版本的精確記錄是一個容易被忽視但極為重要的細節。每次評測運行都會記錄使用的數據集版本（具體到Git提交哈希），這意味著即使將來數據集內容有所更新，歷史結果和新結果也可以被精確區分，確保了縱向的可比性。
**三、這把秤能稱什麼？——五大檢索家族與效率變體**
HAKARI-Bench能夠評測五大類檢索方案，每一類都扮演著不同的角色，就像圖書館裡的不同工作崗位各司其職。
關鍵詞匹配方法（BM25）是最古老也最可靠的方案，它像一個精通索引目錄的老派圖書館員，只認書面文字，不理解語義，但在某些場合出奇地有效。稠密檢索（dense retrieval）是目前最主流的神經網路方案，它把每個文檔和查詢都壓縮成一個數百維的"語義摘要向量"，通過計算兩個向量的相似度來判斷相關性——類似於圖書館員記住了每本書的"內容精髓"，用感性理解來匹配讀者需求。稀疏檢索（sparse retrieval）以SPLADE系列為代表，它生成的是一個非常稀疏的權重向量，只有少數幾個維度有非零值，這些維度對應著與文檔內容高度相關的詞彙——類似於圖書館員給每本書整理了一份精簡的關鍵詞權重清單。後期交互（late interaction）以ColBERT系列為代表，它不把整個文檔壓縮成一個向量，而是保留每個詞的獨立表示，匹配時計算查詢中每個詞與文檔中最相關詞之間的最大相似度之和——類似於圖書館員逐句對比讀者問題和書中內容。重排序器（reranker）則是在初步候選集上工作的精讀專家，它直接讀取查詢和文檔的完整文本，輸出一個精確的相關性分數，用於重新排列候選文檔的順序。
在評測具體操作上，稠密檢索有一個細節值得關註：對於每個模型和每個任務，系統會同時計算餘弦相似度和內積相似度，然後取兩者中更高的那個分數作為該模型在該任務上的得分。這相當於給每個模型選擇最適合它的"度量方式"，是一種對所有稠密模型統一適用的"上界"計算方法，能更公平地反映模型的真實能力上限。
對於效率變體的評測，HAKARI-Bench提供了一套系統化的衍生方案。維度壓縮方面，系統支持對向量的前若干維進行截斷，這背後的理念來自"麥特里約什卡表示學習"（Matryoshka representation learning）——就像俄羅斯套娃一樣，外層包含完整資訊，裡層的子集也能獨立工作。通過截斷到256維或更少，可以在保留大部分語義資訊的同時大幅減少儲存和計算開銷。
量化壓縮方面，系統支持int8量化和二值量化兩種形式。int8量化把每個維度從原來的4字節浮點數壓縮成1字節整數，儲存空間縮減到原來的四分之一；具體做法是對語料庫側的向量做每維度的最小值/最大值標定，然後把每個浮點數映射到0到255之間的256個整數桶中，標定時刻意不使用查詢側的數據，避免對評測查詢過擬合。二值量化更為激進，只保留每個維度的正負符號（1比特），把儲存壓縮到極致。
"浮點重評分"（rescore）則是一種兩階段策略：先用量化後的向量快速檢索出前100篇候選文檔，然後用原始的浮點向量對這100篇文檔重新精確評分、重新排序。這種策略在生產環境中非常實用，因為儲存在伺服器上的通常是量化後的廉價版本用於快速初篩，而少量候選文檔的精確重評分計算代價很小。
對於稀疏檢索模型，系統支持對查詢側和文檔側分別獨立設置"最大活躍維度數"，也就是最多保留多少個非零權重維度。查詢側的維度數直接影響搜索時的計算速度；文檔側的維度數影響倒排索引的儲存大小和內存占用。通過對這兩個參數的獨立調節，可以精細地分析在給定延遲預算和儲存預算下，最優的壓縮配置是什麼。
**四、551個任務的江湖——任務集的版圖與分布**
HAKARI-Bench覆蓋的551個任務，構成了一張極其豐富的多語言多領域地圖。從語言分布來看，排名前十的語言按任務數量依次是英語（201個任務）、越南語（40個）、德語（30個）、法語（29個）、荷蘭語（28個）、日語（27個）、西班牙語（26個）、泰語（24個）、韓語（20個）、阿拉伯語和波斯語（各19個），非英語任務總數超過450個。這意味著在這套評測體系里，單純擅長英文的模型是無法獲得高分的——多語言能力是衡量一個模型綜合實力的重要維度。
從領域分布來看，526個任務屬於自然語言類，覆蓋了約6萬9千條查詢和超過300萬篇文檔；25個任務屬於代碼類，包含約4400條查詢和超過15萬篇文檔。代碼任務分布在5個基準測試集中，其中NanoCoIR和NanoCodeRAG是純代碼任務集，而NanoBRIGHT、NanoRTEB和NanoRARb則是自然語言與代碼混合的任務集。
35個基準測試集可以大致分為五個家族。第一個家族是BEIR家族，以MNanoBEIR為代表，把BEIR的13個經典英文數據集擴展到了14種語言，總共182個任務——這是任務數量最多的單個基準，在聚合計算時為了避免它主導總排名，系統會先在每個BEIR數據集內部對14種語言求平均，再對13個數據集求平均，最終作為一個整體參與宏觀平均計算。
第二個家族是官方MTEB/MMTEB家族，包括NanoMTEB-v2（10個任務，英文為主）、NanoMMTEB-v2（18個任務，多語言）以及針對各語言的專項集，如NanoMTEB-Dutch（荷蘭語，27個任務）、NanoMTEB-Polish（波蘭語，14個任務）、NanoJMTEB-v2（日語，11個任務）、NanoVNMTEB（越南語，26個任務）等。
第三個家族是多語言通用檢索集，包括NanoMIRACL（覆蓋18種語言的單語檢索任務）、NanoMLDR（13種語言的長文檔檢索）、NanoIndicQA（11種印度次大陸語言）和NanoMuPLeR（14種語言的歐盟法律文件並行語料）。
第四個家族是長文檔、指令跟隨、專家領域和推理型任務，這是最具挑戰性的集合，包括NanoLongEmbed（文檔長度從數千到超過三十萬字符）、NanoIFIR（需要理解複雜指令的檢索任務）、NanoChemTEB（化學領域）、NanoR2MED（需要推理的醫療文獻檢索）、NanoBIRCO（複雜目標檢索）、NanoBRIGHT（高難度推理型檢索）、NanoRARb（把推理過程本身作為檢索目標）以及法律（NanoLaw）和醫療（NanoMedical）綜合任務集。
第五個家族是代碼檢索集，包括NanoCoIR（代碼資訊檢索綜合集，10個任務）和NanoCodeRAG（代碼增強生成檢索，4個任務）。
值得一提的是，不同任務集之間存在一些來自同一原始數據集的重複任務——比如scidocs、treccovid等數據集在不同的任務家族裡各有一個版本，但由於兩個版本的抽樣方法不同，構成了不同的評測表面，因此系統選擇保留而非合併這些重複任務。這種做法在等權重微觀平均時可能會輕微放大這些任務的權重，但在宏觀平均（每個基準測試集等權重）時影響會被有效抵消。
**五、稱量結果——55個模型的全面評測**
這次評測共涉及55個模型，其中稠密檢索模型33個、稀疏檢索模型4個、後期交互模型6個、重排序器11個（10個傳統交叉編碼器型、1個大語言模型風格），以及1個BM25詞彙基線。所有神經網路模型的參數規模都在10億以下，覆蓋了當前主流的中小型檢索模型範圍。
從總體表現來看，稠密檢索模型的每基準宏觀平均（乘以100後的分數，滿分100）差異顯著。排名靠前的基準有代碼檢索（NanoCodeRAG平均77.94分）、俄語（NanoRuMTEB平均74.04分）、化學領域（NanoChemTEB平均72.61分）和代碼資訊檢索（NanoCoIR平均72.31分）；排名靠後的則是推理檢索（NanoRARb平均僅22.00分）、醫療推理（NanoR2MED平均23.98分）、跨領域專利檢索（NanoDAPFAM平均26.67分）和複雜目標檢索（NanoBIRCO平均26.73分）。最高和最低之間相差超過50分，這個巨大的差距說明：現有的嵌入模型對於專家領域、指令跟隨和複雜推理類任務仍然存在明顯的短板，而這些短板只有通過多領域評測才能被暴露出來。
在稠密模型的整體排名中，按宏觀平均分數排列，前五名依次是jina-embeddings-v5-text-small（64.93分）、jina-embeddings-v5-text-nano（63.80分）、harrier-oss-v1-0.6b（63.68分）、pplx-embed-v1-0.6b（63.64分）和embeddinggemma-300m（62.58分）。BM25作為詞彙基線得分為50.24（宏觀平均），雖然低於頂級稠密模型群，但它在所有任務上都能提供一個公平的基線參照。
**六、量化和壓縮到底會損失多少性能？**
這是整個研究中最具實用價值的發現之一。研究者對所有33個稠密檢索模型統一應用了int8量化、二值量化以及對應的"浮點重評分"變體，計算每種設置相對於原始浮點基準的平均性能變化。
結論相當明確。二值量化單獨使用時平均損失6.50分，這是最大的性能損耗；int8量化單獨使用時只損失1.95分，非常溫和；二值量化加浮點重評分後平均只損失0.93分；而int8量化加浮點重評分後幾乎沒有損耗，僅0.09分。換句話說，int8量化配合重評分，幾乎是完全無損的——儲存空間縮減到四分之一，性能損失幾乎可以忽略不計。
更有趣的發現是模型之間的差異性。二值量化的性能損耗在模型之間差異極大，從最小的損失2.01分到最大的損失35.79分。損耗最嚴重的是多語言E5系列：mE5-small損失35.8分，mE5-base損失20.7分，mE5-large損失17.9分。同樣基於E5系列的bilingual-embedding-small也損失了16.2分。五個E5及其衍生模型的平均損耗約為19分，遠遠高於其他模型（大多數模型在2到10分之間）。
相比之下，專門針對量化魯棒性進行訓練的模型（jina-embeddings-v5系列、embeddinggemma-300m、snowflake-arctic-embed-l-v2.0、Qwen3-Embedding-0.6B）在二值量化後的損耗僅在2到4分之間。
這種差異與模型的維度大小無關，也與參數數量無關——相同維度下，mE5-small（384維）損耗35.8分，而all-MiniLM-L6-v2（同樣384維）僅損耗4.4分；相同1024維度下，mE5-large損耗17.9分，而jina-embeddings-v5-text-small僅損耗2.0分。這個發現告訴我們：二值量化的魯棒性是模型訓練策略決定的，而非規模決定的。
對於維度壓縮，分析結果同樣令人安心。按照本地維度的比例來對齊各模型（比較截斷到50%維度時的性能保留率），大多數模型在截斷到50%本地維度時能保留約99%的基準性能，截斷到25%時能保留約95%。最為出色的jina-embeddings-v3（本地維度1024）甚至在截斷到12.5%（僅128維）時仍能保留96%的性能。
從跨模型排名的角度來看，int8量化幾乎不影響排名（與浮點排名的Spearman相關係數高達0.995），int8加重評分更是完美保持排名（相關係數1.000）。二值量化單獨使用時會相當大地打亂排名（相關係數降到0.937），但加上浮點重評分後又恢復到接近浮點排名的狀態（0.988）。這意味著：如果你想用int8方案，直接參考浮點排行榜選模型就行；如果你想用二值方案，必須同時啟用浮點重評分，才能讓"好模型"依然是"好模型"。
**七、稀疏檢索的壓縮空間在哪裡？**
對於4個稀疏檢索模型，研究者專門測試了查詢側和文檔側分別獨立剪枝的影響。以naver/splade-v3為例，研究者嘗試了4×4=16種組合：查詢側最大活躍維度q取{8, 16, 24, 32}，文檔側最大活躍維度d取{64, 128, 256, 512}。
結果呈現出一個清晰的不對稱格局。文檔側可以激進壓縮：從512維減少到256維幾乎沒有任何損耗（保留100.6%的基準性能），減少到128維仍然保留99.1%，只有減少到64維才會造成約5.5%的損耗。而查詢側則相當敏感：從32維減少到24維能保留99.5%，從32維減少到16維就會損失約3%，減少到8維會損失約10%。
這個發現有很強的實踐指導價值：你可以大膽壓縮文檔側的維度來減少儲存索引的大小（這是離線構建的，成本相對低廉），但在查詢側必須保守一些，因為這直接影響每次實時搜索的延遲。使99%性能保留率的"安全操作範圍"是：查詢側q≥24，文檔側d≥128。選擇d=256、q=24這個組合時，在幾乎不損失質量的同時，既大幅壓縮了索引體積，又將查詢時的計算量控制在合理範圍內。
**八、重排序器在什麼情況下真的有用？**
重排序器的評測結果呈現出一幅複雜而有趣的圖景。總體來看，在全部551個任務的宏觀平均下，能夠超越最佳稠密模型（jina-embeddings-v5-text-small作為重排序器在候選集上得分65.51）的只有一個：大語言模型風格的重排序器Qwen3-Reranker-0.6B，得分68.03。傳統的多語言交叉編碼器型重排序器（如BAAI/bge-reranker-v2-m3得分63.07、mGTE重排序器得分62.97）全部低於最佳稠密模型。
但"總體落後"並不意味著"處處落後"。當把範圍限定在查詢和文檔都較短（查詢不超過70個字符，文檔不超過1000個字符）的多語言任務上時，多語言交叉編碼器bge-reranker-v2-m3以宏觀平均67.41分超越了最佳稠密模型（65.91分）；在同樣限定條件的英文任務上，英文專用交叉編碼器ettin-reranker-400m-v1以70.23分顯著超越了最佳稠密模型（68.59分）。
這說明，重排序器的優勢高度依賴於任務的特徵。傳統交叉編碼器是在短查詢/段落數據（如MS MARCO）上訓練的，在完全匹配這種使用場景時效果出色，一旦遇到長文檔、代碼、複雜推理或多語言混合任務，就會大幅退步。Qwen3-Reranker-0.6B作為一個基於大語言模型的重排序器，本質上繼承了大語言模型的指令理解能力，因此在長文本（長任務的z-score高達+1.62）和複雜推理場景中保持穩健，不受查詢長度影響。
從每個基準測試集的角度來看，重排序器優勢最大的領域在多語言任務（NanoMLDR上重排序器最佳與稠密最佳的差距高達+13.33分）。即便在重排序器整體落後的基準上，劣勢通常也很小。
研究者還分析了"稠密檢索模型重新評估自己候選集"的情況：當一個稠密模型對自己生成的混合候選集重新評分時，平均只能提升1.9分（不含保障規則時為1.5分）。這個提升非常微小，因為混合候選集本身已經包含了該稠密模型的檢索top候選，幾乎和完整語料庫檢索的結果相同。這也說明：混合候選集相比於純BM25候選集，能夠更公平地評估重排序效果，不會因為候選集和某種方法的"天然兼容性"而製造虛假的大幅提升。
**九、最關鍵的驗證：這把"小秤"和"大秤"差多少？**
所有上述分析都建立在一個核心前提之上：納米題集確實能代表原始大型評測的結論。研究者進行了三組獨立的對比驗證。
第一組，把NanoMMTEB-v2的結果與官方MMTEB v2多語言檢索評測對比，找出兩者都有完整結果的24個模型、18個共同任務。結論：Spearman秩相關係數0.975，平均秩差1.208，最大秩差僅4；基於Borda分數的Pearson相關係數0.969。
第二組，把NanoMTEB-v2的結果與官方MTEB檢索v2評測對比，共同模型18個、共同任務10個。結論：Spearman秩相關係數0.983，平均秩差0.722，最大秩差僅2；Pearson相關係數0.981。
第三組，把NanoBEIR-en的結果與英文BEIR原始完整版對比，共同模型19個、共同任務13個。結論：Spearman秩相關係數0.973，最大秩差3；Pearson相關係數0.974。
三次獨立對比都達到了0.97以上的Spearman相關係數，這是一個極高的數字。為了量化置信度，研究者對共同模型集進行了1萬次自助重抽樣，得到的95%置信區間下限分別為0.915（MMTEB）、0.912（MTEB-v2）和0.882（BEIR-en），即便是在最保守的估計下，相關係數仍然保持很高。特別值得關注的是，在MMTEB和MTEB-v2的對比中，排名第一的模型在官方評測和納米題集評測中都是第一，秩差為零，體現了頂端排名的高度穩定性。
當然，納米題集並非完美複製了原始評測的所有特性。從絕對分數來看，納米題集側的平均nDCG分數與MMTEB相比約低7分，而與MTEB-v2相比約高7分——連偏差的方向都不一致，說明絕對分數是不能跨基準比較的，納米題集只能作為相對排名的代理，絕不能當作絕對性能的直接參照。
在典型的偏差案例中，fever_hard_negatives任務（判斷一個陳述是否真實，是典型的難負樣本任務）在官方版本中模型得分範圍是27.5到92.9分，而在納米版本中卻是74.1到99.1分——不是因為變容易了，而是因為候選池的設計和語料庫規模的變化使得區分度被壓縮到了高分段。這是納米題集設計的一個已知局限，研究者在論文中坦率地指出了這一點。
**十、實際場景下，如何用這把秤做決策？**
HAKARI-Bench最終的價值，不是告訴你"哪個模型最厲害"，而是幫助你回答"對於我的具體需求，哪個模型最合適"。研究者通過幾個具體場景展示了這套體系的實用價值。
在多語言語義搜索場景下（以NanoMIRACL為代表，短查詢配短段落，18種語言），整體排名第10的BAAI/bge-m3在這個場景里是38個第一階段檢索系統里的第一名，整體排名第15的multilingual-e5-large排第3名。這些模型正是為多語言語義搜索場景特別優化的，而且在這個場景里表現出了與頂級通用模型同等甚至更好的效果。
在長文檔檢索場景下（NanoMLDR平均文檔長度5000到28000字，NanoLongEmbed文檔長度高達30萬字以上），整體排名第24的BM25在兩個場景中都是第1名。原因清晰：許多稠密檢索模型有最大輸入長度限制，當文檔過長時相關段落就被截斷了，而BM25沒有這個限制，能完整匹配全文。在稠密模型中，專門針對長上下文訓練的Qwen3-Embedding-0.6B在NanoLongEmbed上排第2，在NanoMLDR上排第4，是這個場景下最優秀的稠密方案。
在日語專項場景下（NanoJMTEB-v2），整體排名第28的日語專用模型cl-nagoya/ruri-v3-310m是第1名，遠超整體排名靠前的通用多語言模型。這再次說明：當目標語言有成熟的專用模型時，通用模型的全面領先並不能延伸到該特定語言場景。
在英文BEIR場景下（限定為MNanoBEIR里的13個英文任務），後期交互方案（ColBERT系列）的表現令人矚目：lightonai/ColBERT-Zero以67.97分位列第1，lightonai/GTE-ModernColBERT-v1以67.47分位列第2，均超過最佳稠密模型的66.97分。前12名中有5個後期交互模型，稀疏檢索模型naver/splade-v3也排在第13位，躋身前四分之一。這些都是在英文精確匹配任務上的專長體現，在多語言全任務集上則因為語言範圍限制而排名靠後。
**十一、這把秤的局限性——研究者自己怎麼說？**
研究者對這套體系的局限性相當坦誠。
納米題集壓縮了檢索空間（約1萬篇文檔 vs 原始的數十萬至數百萬篇），這使得一些碰巧相似但不相關的文檔不太可能出現在候選集裡，從而讓任務整體變得比原來容易。因此，二值量化等設置的性能損耗在納米題集上可能比在真實大規模語料庫上偏樂觀——量化的影響在小語料庫里更容易被彌補。
由於每個任務的查詢數量只有50到200個，單個任務的統計誤差較大。研究者通過2000次自助重抽樣計算了宏觀平均的95%置信區間，半寬平均為±2.1分，最大±2.3分。具體到排名穩定性：排名第1的模型從未在2000次重抽樣中跌至第2，說明前幾名的差距足夠大；但排名2到4的模型彼此之間差距約0.1分，排名交換概率高達31%到45%。結論是：宏觀平均分差低於1分的排名差距，不應該被認真對待。
固定候選集的設計，雖然確保了公平比較，但也帶來了一個問題：重排序器的評測建立在"每個查詢至少有一篇相關文檔在候選集裡"這個保障規則上，這不等於真實雙階段檢索中的情況——在生產環境裡，第一階段檢索可能完全漏掉所有相關文檔，導致重排序器根本無法挽回。候選集裡相關文檔的覆蓋率（約87%）和查詢覆蓋率（因保障規則達到100%）是兩個需要分開理解的指標。
在量化評測方面，HAKARI-Bench使用的是簡單的事後標量量化（int8）和符號二值量化，與生產級別的近似最近鄰搜索（ANN）系統中使用的更高級量化方法（如乘積量化、優化標量量化、帶理論誤差界的RaBitQ等）相比，存在較大差距。真實生產系統的最終量化魯棒性可能與這裡的測量值有所不同，更精確的生產級評測屬於ANN-Benchmarks等專項基準的範疇。
評測範圍方面，目前覆蓋的是參數規模約10億以下的開源模型，不包含OpenAI、Cohere、Voyage等商業API模型。在數據污染方面，部分模型（如multilingual-E5明確報告使用了MS MARCO和MIRACL訓練數據）在對應的納米題集上可能存在間接的領域適應優勢；更廣泛的是，隨著預訓練語料庫越來越大，測試集中的查詢和文檔被納入訓練數據的可能性越來越難以排除，這是整個領域面臨的共同挑戰，HAKARI-Bench也不例外。
最後，推理速度不在評測範圍之內。研究者詳細解釋了原因：速度高度依賴硬體、批次大小、序列長度、並行策略以及各模型是否支持優化注意力機制等實現細節，在同一條件下公平測量所有模型的"最優速度"極為困難，不恰當的測量反而會誤導選型決策。系統記錄了每個模型的活躍參數數量（作為推理計算量的粗略代理）和總參數數量（作為內存占用的代理），但不提供實際延遲數字。
**十二、未來的路——這把秤還能怎麼升級？**
研究者提出了三個方向的未來工作。第一是擴展評測模型範圍，納入超過10億參數的大型公開模型和商業API模型，使排行榜更有參考價值。第二是把實驗室場景延伸到大規模語料庫驗證，檢驗納米題集上的性能差異是否能在完整語料庫規模下重現。第三是改進納米題集的構建方法，特別是針對原始數據集沒有困難負樣本的情況——目前這類任務用原始語料庫順序填充剩餘文檔，導致檢索空間偏簡單。如果能夠引入通過第一階段檢索挖掘的困難負樣本，或者使用考慮難度和多樣性的文檔抽樣策略，納米題集的區分度和絕對分數代表性都會提升，從而在保持排名復現性的同時，讓分數分布更貼近原始評測。
---
**歸根結底，HAKARI-Bench做了一件聽起來簡單、做起來極難的事：把一套原本需要耗費大量資源的"工業大秤"，壓縮成了一把隨時可用的"口袋小秤"，同時確保讀數的可靠性。在這把小秤上，英文好手、多語言通才、代碼專家、長文檔能手都能找到屬於自己的舞台，各種"節能模式"的性能代價也一目了然。對於每一個需要在複雜需求和有限預算之間做權衡的工程師來說，這套工具的實際價值遠超過一張簡單的總排名榜單。**
如果你希望深入了解這套體系的技術細節，包括完整的模型列表、所有任務的數據來源以及詳細的實驗結果，可以通過論文編號arXiv:2606.22778查閱原文，相關代碼和數據集也已在GitHub和Hugging Face上以MIT協議公開發布。
---
Q&A
Q1：HAKARI-Bench的納米題集評測結果和原始大規模評測相差多少？
A：三次獨立驗證的Spearman秩相關係數均超過0.97，平均秩差約1，最大秩差不超過4，說明納米題集能高保真地復現模型排名。但絕對分數與原始評測不可比——同一套納米題集相對MMTEB偏低約7分，相對MTEB-v2偏高約7分，連偏差方向都不一致，因此只能用於排名參考，不能直接對比分數數值。
Q2：int8量化和二值量化對檢索性能的影響有多大？
A：int8量化平均僅損失約1.95分，加上浮點重評分後幾乎無損（僅0.09分），可視為"幾乎免費"的儲存節省手段。二值量化單獨使用平均損失6.50分，但模型差異極大，multilingual-E5系列損失高達17到35分，而專為量化魯棒性訓練的模型僅損失2到4分。加上浮點重評分後大多數模型都能恢復到接近浮點性能的水平。
Q3：重排序器（reranker）在什麼情況下比稠密檢索模型表現更好？
A：在短查詢配短文檔的多語言語義搜索場景下，多語言交叉編碼器型重排序器（如bge-reranker-v2-m3）明顯優於最佳稠密模型；在短英文任務上，英文專用交叉編碼器ettin-reranker也有明顯優勢。但在覆蓋代碼、長文檔、複雜推理等多樣化任務的全任務集上，傳統交叉編碼器普遍低於最佳稠密模型，只有基於大語言模型的Qwen3-Reranker-0.6B因其指令跟隨能力而超越。
