做 RAG 或企業搜尋的人都遇過這種尷尬：系統明明撈到了一篇直接回答問題的文件，benchmark 卻給低分，原因是這篇文件從來沒被標註過。Cohere 在 2026 年 9 月 30 日發表的 RCP-nDCG@10，就是針對這個問題提出的評測方法。
舊指標的問題出在答案 key
nDCG 一直是檢索評測的主力，因為它同時考慮相關程度和排名位置。但它的分數是拿系統結果去比對一組既有的相關性判斷（qrels），而這些判斷來自早期系統撈出的文件池——完整標註所有 query-document 組合太貴，所以業界長期採用這種 pooling 折衷。
折衷的代價是一個越來越大的覆蓋缺口。Cohere 舉了 ViDoRe v3 的一個真實例子：查詢氮氣鋼瓶的顏色代碼，答案 key 只標了兩篇文件，其中一篇直接引述答案的文件排在第 3 名，卻因為從未被標註而不算相關。模型越強、探索的語料範圍越廣，這種「撈到了卻沒分」的情況就越常見，benchmark 於是漸漸只反映上一代系統找得到的東西。
一份 46 人的人類標註研究
Cohere 做了一項 46 人的盲測標註研究，結果直指 qrels 的可靠度有限：
- qrels 對盲測人類相關性判斷的預測力只比隨機好一點，AUC 僅 0.65。
- 被標為不相關的文件中，28% 其實對人有幫助；反向錯誤只有 15%。
- 基準只把 29% 的文件標為相關，人類評審則認為有 60%。
- 兩位評審獨立給分，在 0 到 4 分的量表上完全一致的比率只有 42%。
RCP-nDCG@10 怎麼運作
RCP-nDCG@10 的做法不是靠一份固定答案 key，而是用校準過的 AI 評審，依同一套明確的 relevance rubric 逐篇給每份撈回的文件打分。這樣即使文件不在原始標註池裡，只要真的相關就能得分。
它也不只是叫 LLM 給個分數而已。每個分數由兩個訊號組成：評審對每份文件回答五題固定的 yes/no 問題（對每個 query 都一樣），同時把文件兩兩分組互相比較、估計勝率；校準階段再用 Item Response Theory 把兩者結合——比較決定順序，rubric 把順序放到所有 query 共用的同一把尺上。Cohere 強調，這種跨 query 可比的分數，是單次 LLM 評分做不到的。
人類站在哪一邊
驗證方式是盲測：46 位具相關領域學士以上學歷的標註員，在 NanoBEIR、BRIGHT 和 ViDoRe v3 的查詢上給各系統的前五名結果評分，看不到系統名稱。在兩種指標判斷不同的比賽中，評審 70% 站在 RCP-nDCG 這邊；整體而言 RCP-nDCG 選中評審偏好的比率是 77%，傳統 nDCG 是 52%。而且 RCP-nDCG 報告的差距越大，評審同意率越高，最寬的區間達到 97%；傳統 nDCG 即使差距最大也只有 53%。
拆解優勢來源，「給答案 key 漏掉的文件記分」貢獻了 19 個百分點，逐篇評分再增加 6 個——兩者會互相加成，因為單靠評分只能在 key 已列出的文件裡重新加權。
MTEB 的主要維護者、Aarhus 大學助理教授 Kenneth Enevoldsen 也表態支持，認為 rubric 錨定的 LLM 判斷在嚴謹對照人類標註的前提下，能讓既有 benchmark 恢復區分頂尖模型的能力，MTEB 計劃採用。
對 builder 的實際影響
有兩件事值得注意。第一，Cohere 接下來的第五代 Embed 和 Rerank 是用 RCP-nDCG@10 優化的，這代表它們在傳統 nDCG 排行榜上不一定最好看。如果你用舊指標挑模型，可能會錯過實際體驗更好的選項——自己用真實資料做離線評測，比照搬 leaderboard 更可靠。
第二，這是檢索評測方法學的轉變訊號，不只是 Cohere 自家的指標。之前寫過 ATLAS 把 agent 評測重點拉回搜尋本身，和這次是同一個方向：模型能力上升後，評測基建跟不上，最吃虧的是認真做檢索品質的團隊。程式碼和資料已在 GitHub（cohere-ai/rcp-ndcg）公開，想驗證這套方法適不適合自己的評測流程，可以從那裡開始；Cohere 也會在 2026 年 10 月 8 日辦一場 X 上的深入討論。