RAG 精準調校反而害檢索
Redis 研究指出，RAG embedding 若只追求 precision，檢索準確率可能掉 40%，還會拖累 agentic pipeline。
Redis 的研究指出，RAG embedding 若只追求 precision，檢索準確率可能掉到 40%。
說真的，這結果很刺耳。很多團隊都想把 RAG 調得更準，結果可能把自己調進坑裡。
這篇在講一件很實際的事。Redis 的研究筆記提醒，精準度拉高，不代表檢索就更好。對 LangChain 這類 agentic pipeline 來說，前面檢索一歪，後面整串都會歪。
先看數字。研究提到，檢索準確率最多會掉 40%。這不是小誤差，是會直接改變產品行為的那種。
| 指標 | 數值 | 意思 |
|---|---|---|
| 檢索準確率下滑 | 最高 40% | 代表調校後，實際找回正確資料的能力可能明顯變差 |
| 優化目標 | Precision | 會讓相似匹配更嚴，但也可能縮小可檢索範圍 |
| 風險區 | Agentic pipelines | 代理流程很吃前段檢索品質，前面錯了後面很難救 |
| 常見後果 | Recall 下降 | 真正能回答問題的文件，可能被排除在外 |
為什麼只追 precision 會出事
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
RAG 的核心，不是找最像的句子而已。它要找的是，對答案真的有用的資料。這兩件事常常不是同一件事。
你把 embedding 調得太偏 precision，模型會變得很挑。它可能更愛抓近似片段，也更容易把邊界案例、補充文件、背景脈絡排掉。對使用者來說，結果就是少了關鍵上下文。
講白了，檢索不是單一分數遊戲。你在 benchmark 上拿到漂亮數字，不代表真實工作流會更順。客服問答、內部知識庫、研究助理，最怕的就是「看起來像對的」，但真正答案沒被撈出來。
- Precision 高，不代表 Recall 也高。
- 候選文件變少，漏掉答案的機率就上升。
- Agent 先吃到爛上下文，後面工具全跟著失真。
- 企業查詢很雜，最有用的文件常常不像問題本身。
這也是我覺得最麻煩的地方。團隊常常先看一個數字，然後就覺得自己做對了。可是在真實場景，錯的不是模型分數，是整個產品體驗。
Redis 在提醒什麼
Redis 這幾年一直往 AI 基礎設施走。它做 vector search、cache、agent memory，都很貼近實戰。這次的提醒很直白：embedding 層的 precision 變好，不等於 production 裡的 retrieval 變好。
這句話對做 agent 的團隊特別重要。因為 agent 的第一步，通常就是先抓資料。前面抓到的 context 如果太窄，或太偏近似樣本，agent 就會帶著偏差做決策。
你可能會想問，那是不是把 precision 放掉就好？也不是。問題不是 precision 本身，而是你把它當成唯一目標。RAG 需要的是平衡，不是單點最優。
“There is no free lunch in machine learning,” said Andrej Karpathy.
這句老話放在這裡很貼。你在一邊拿到好看分數，通常要在另一邊付代價。RAG 裡常見的代價，就是 Recall、grounding，還有可用上下文的廣度。
如果你的產品是知識助理，這種代價會很痛。使用者不會在乎你的 embedding loss 怎麼降，他只會在乎「為什麼明明有文件，系統卻找不到」。
跟常見 RAG 做法比起來差在哪
多數團隊做 RAG，會先看 chunking、reranking、embedding model，再看 prompt。這個順序沒錯，但很多人會誤以為只要把檢索模型調更準，整體就會更好。
Redis 這份研究的重點，就是打臉這種直覺。你在實驗室裡把一個指標拉高，不代表線上體驗會一起上去。反過來說，還可能把整條鏈弄壞。
我整理成幾個常見路線，差異很明顯：
- Precision-first： 匹配更緊，候選更少，漏掉有用資料的風險更高。
- Recall-aware： 找回更多上下文，但後面 rerank 和 filter 要更認真。
- Production-first： 看真實 query、人工抽查、再搭配線上 A/B test。
- Agent-first： 先看檢索是否能支撐任務，不只看 similarity 分數。
這裡還有一個很現實的問題。很多團隊拿 synthetic benchmark 當真相，但真實使用者的問題很髒。有人會打半句話，有人會混中英，有人會問很冷門的例外情況。
所以，真正該比的不是誰的分數漂亮，而是誰比較少漏答案。這一點，Pinecone、Weaviate 這類向量資料庫幫得上忙，但它們救不了錯的優化方向。
這件事放到產業脈絡裡看
RAG 現在已經不是 demo 技術了。很多公司拿它做客服、法務搜尋、銷售知識庫，甚至內部 agent。這些場景共通點很簡單：資料多，問題雜，錯一次就很煩。
也因為這樣，檢索層的微小變動，會比一般人想的更敏感。你把模型調得太保守，系統就只會撈到最像的文件。你把模型調得太寬，又會把垃圾上下文塞進去。
這就是 RAG 的老問題。不是找不到模型，而是找不到剛剛好的平衡點。很多時候，chunk 策略、reranker、metadata filter，甚至資料清洗，影響都比單純換 embedding 還大。
再看 agentic pipeline，就更明顯了。Agent 不是只回答一句話而已。它可能要查資料、比對條件、再呼叫 API。前面檢索若偏掉，後面每一步都會跟著偏。
所以我會建議團隊把測試重點換掉。不要只問「precision 有沒有變高」，而是問「正確文件有沒有更常被找回」。這兩題差很多。
團隊接下來該怎麼做
第一步，別只看單一指標。Precision、Recall、MRR、nDCG，最好一起看。只盯一個數字，很容易把系統調歪。
第二步，拿真實 query 測。不要只用乾淨的測試集。要把使用者真的會丟的問題拿進來，包含模糊問法、短句、錯字、混合語言。
第三步，檢查下游任務。你的 RAG 是拿來回答問題，還是拿來餵 agent 做決策？如果是後者，檢索品質的容錯率更低。
第四步，別迷信 embedding。chunking、reranking、metadata、query rewrite，常常比你想像中更有用。很多時候，修資料比修模型便宜，也更快。
如果你現在在調 RAG，我會直接問一句：你要的是更像，還是更對？兩者不是同一件事。搞清楚這點，才不會把系統越調越窄。
我的預測很直接。接下來一年，更多團隊會發現，RAG 的瓶頸不在模型多大，而在檢索策略有沒有配對好任務。先把 Recall、真實任務成功率、agent 完成率一起納入，再談 precision，會比較實在。