---

title: "你的 RAG 看起來很強，但其實跟亂猜差不多：ICLR 2026 新指標 Bits over Random" date: 2026-03-26 author: meow.coder source: https://www.threads.com/@meow.coder/post/DWWNBwCkgOX category: threads tags:

• RAG
• 檢索
• LLM
• Agent
• 論文
• ICLR created: 2026-03-27 updated: 2026-03-27

---

你的 RAG 看起來很強，但其實跟亂猜差不多：ICLR 2026 新指標 Bits over Random

原文摘要

一篇 ICLR 2026 論文提出新指標 Bits over Random（BoR），直接打臉一個常見迷思：檢索召回率很高，不等於你的 AI 真的「找到」了東西。

傳統 RAG 評估的盲點

傳統評估 RAG 都在問：

• 有沒有檢索到相關內容？
• 召回率多少？
• 排名好嗎？

盲點： 這些指標假設「消費者」能自己篩掉垃圾。人類確實很會這件事，但 LLM 不行。模型會把整包檢索結果當作 prompt 全部讀進去，不相關的內容會稀釋注意力、汙染推理。

BoR 的核心問題

你的檢索結果比隨機亂選好多少？

如果答案是「沒好多少」，你不是在找東西，你是在塞東西。

這在 Agent 系統特別致命——當你有 20、50、100 個工具可選，把全部丟進 context 看起來很周到，實際上是把選擇題變成開卷考，但參考資料裡一半是干擾項。

三個 Regime

1. 健康區：短名單、真正有篩選力
2. 灰色地帶：K 夠大讓 recall 上升，但隨機基線也跟著漲
3. 崩潰區：K 大到成功只是因為你把選項全秀出來了

實務上更好的問題不是「K 要多大召回率才好看」，而是「K 能多小還能維持表現」。少即是多。

實務建議

1. 分階段路由：先粗分領域再精選工具
2. 壓縮工具描述：讓差異更明顯
3. 主動排除不相關工具：不是選什麼進來，是選什麼踢掉

本質上是把工具選擇當成檢索問題，不是靜態 prompt 裝飾。

BoR 的局限

能測「選擇力」，但測不了「認知負荷」。短名單比隨機好，不代表模型不會被 200 個工具描述淹死。

核心觀點

1. 和 agent-browser Token 比較那篇直接呼應

之前整理過三大瀏覽器工具的 Token 差 4.5 倍——Playwright 回傳 16,000 tokens 的完整 DOM，agent-browser 只回 3,500。這篇用學術語言說了同一件事：