RAG 調校怎麼做：從進階檢索到 LLM 評測的實戰筆記

如果你還在糾結要不要用 RAG，那篇已經拆過——這篇不重講。這篇假設你已經選了 RAG，現在卡在另一個問題：東西能跑，但答案時好時壞，你不知道要調哪裡。

2023 年底，LlamaIndex 貼出一張「Advanced RAG Cheat Sheet」，把檢索增強生成拆成一張圖，兩年多來還在被轉貼、被當新人教材用。但兩年半過去，清單裡一半的「進階技巧」已經變成基本款，評測那一半的判斷標準也整套換掉了。這篇拆三件事：①當年那張圖在講什麼、②哪些東西變成了預設配置、③怎麼知道自己調得夠不夠好。

那張 Cheat Sheet 原本在講什麼

核心邏輯很簡單：RAG 好不好，看兩件事——檢索得準不準、生成得穩不穩。 檢索端要顧 chunk 大小、結構化知識、滑動視窗、知識圖譜、多路檢索；生成端靠壓縮和 reranking 撐住品質，讓模型真的用檢索到的內容回答，而不是查了資料還自己亂掰。

同一時間，@llama_index 還轉貼過一篇文章，把邏輯拆成 12 個調校點，分兩階段：資料處理（清理資料、chunking、embedding 模型選擇、metadata、多重索引）跟推論（查詢改寫、檢索參數、進階檢索策略、reranking、選對 LLM、prompt engineering）。骨架到今天沒變，但每一點底下「什麼叫做好」，兩年半內全部升級了一輪。

2026 年的基本款，是當年的進階技巧

這是這篇最想讓你記住的事：混合檢索加 reranker，兩年前算進階，現在是上線前就該做完的事。 查了一輪 2026 年的工程實務文章，多個獨立來源描述的順序很一致——先穩住基本檢索（好的 embedding、合理 chunking、乾淨 metadata），加 reranker 排好 top-k；再疊混合檢索，把 BM25 關鍵字比對跟向量語意檢索合併，抓住向量搜尋常漏掉的產品代號、單號這類精確字串；最後才是查詢改寫、HyDE 補上使用者打字模糊的落差。這一整套現在的定位是「先做完再談進階」，不是技術亮點。

真正被當「進階」的是下一層：Adaptive RAG（用小分類器判斷查詢要不要檢索、單步還是多步）、GraphRAG（知識圖譜處理跨文件關聯）、RAPTOR（超長文件的階層式摘要索引）。多篇 2026 年指南把 Adaptive RAG 稱為「新興最佳實踐」——簡單問題直接答，複雜問題才動用多步檢索，省下延遲跟成本。HKUDS 的 OpenSpace 就是把檢索從單純查向量資料庫換成技能圖譜加自進化引擎的例子，重複查詢的 token 消耗直接砍掉快一半。

一句話講完：混合檢索不是終點，是及格線。

長 context 有沒有把這些招式做廢

有，但只廢了一部分。多篇 2026 年分析給出的粗略分界是：知識庫在 10 萬 token 以內，直接塞進 prompt 通常比架檢索 pipeline 划算；超過 100 萬 token、或資料一直在變、需要多租戶隔離，檢索還是省不掉。這跟微調 vs Prompting那篇邏輯一樣——長 context 沒淘汰 RAG，只是把「要不要用」變成一道要算數字的題目。

真正變化的是 chunk 策略：以前 context 小要切得很細，現在更常見的做法是先檢索、再整份丟進去——用檢索從大量文件裡挑出真正相關的那幾份，選中之後不再切碎，直接送進長 context 做跨文件推理。要說清楚的是：視窗變大不代表模型整個視窗都用得一樣好，多篇分析提到的「context rot」現象，讓「該檢索多少內容給模型看」還是得測，不能因為視窗變大就無腦塞滿。

光有檢索不夠：你要怎麼知道自己調得夠好

這是原本那套 cheat sheet 沒提到、但 LlamaIndex 另一則 2023 年底的貼文有講到的部分。

這則講的是拿 LLM 當評審——用一個 LLM 打分另一個 LLM 的輸出，問題是裁判本身靠不靠譜。LlamaIndex 當時做了 benchmark，拿裁判分數對照人工標註，結論是 Gemini Pro 當裁判接近 GPT-4。放到 2026 年讀，這個結論本身就是反面教材——不是它錯，是這兩個模型早就不是現役選手，拿來當參照點已經沒意義。真正還成立的是背後那句話：裁判模型要比被評模型強，這件事兩年半沒變過。

現在的做法也不再是「拿哪個模型當裁判」的單點問題，是一整套框架在比。RAGAS、TruLens、DeepEval、Arize Phoenix 是 2026 年常用的開源評測工具，TruLens 提出的「RAG Triad」——context relevance（資料相不相關）、faithfulness（有沒有照資料講）、answer relevance（有沒有答到問題）——已經是業界拆解 RAG 品質的標準三分法，一份跨工具評測甚至直接拿 GPT-4o 當公版裁判去比較。LLM-as-judge 準不準？前提是裁判模型比被評模型強就夠可靠，風險是裁判可能有一樣的知識盲點、還有偏好長答案的囉嗦偏誤，所以日常迭代用 LLM 評分，重大版本上線前補一輪人工抽查。

你的 RAG 系統值不值得信任，不是看它聽起來對不對，是看 faithfulness 分數有沒有過門檻。

從 notebook 到正式上線，差的是那幾個月

Abacus AI 創辦人 Bindu Reddy 講的是另一個常被低估的事：RAG 看起來簡單，做好極其難。 一個向量資料庫加檢索通常不夠，你需要語意理解跟一整套搜尋引擎撐著「檢索」這件事。跟其他機器學習問題一樣，notebook 原型幾小時就能生出來，但通過完整評測、真正上生產，常常要花好幾個月。

這句話放到 2026 年一樣成立，而且有具體案例。Weaviate 的法律合約檢索系統用 Query Agent 加 Agent Skills，一個 prompt 12 分鐘內就 build 出處理 510 份合約的系統，成本約 0.3 美元——但背後動用了 ColQwen 多向量嵌入、FastAPI、Next.js 整條工程鏈，證明的不是「RAG 變簡單了」，是工具鏈進步讓搭起來變快，評測工程一件都沒少。如果知識庫本身帶著長影片、跨模態查詢，複雜度還要再疊一層——HKUDS 的 VideoRAG 用雙通道架構處理上百小時影片問答，說明的是同一件事：檢索端工程量跟資料形態成正比，沒有一套公式能套用到所有場景。

自己架這套 pipeline 到本地端跑，VRAM 通常是第一個卡住的地方——本地跑 embedding 模型、cross-encoder reranker，都需要吃記憶體。麗臺 RTX PRO 4000 Blackwell 這類 24GB 工作站顯卡，規格上足夠同時跑本地 reranker 跟中型 embedding 模型，不用每次測試都打 API 排隊。

利益揭露：文中麗臺 RTX PRO 4000 為蝦皮聯盟連結，點擊購買我會獲得回饋，不影響你的價格。這裡給的是規格面的判斷，不是我本人架過這套本地 pipeline 的使用心得。

給正在調 RAG 的工程師

• 先做完基本款，再想進階技巧。 混合檢索加 reranker 是 2026 年的及格線，不是拿來說嘴的成就。
• 檢索跟生成分開測。 context precision/recall 顧檢索，faithfulness 顧生成，混在一起看不出問題出在哪。
• 裁判模型要比被評模型強，而且定期換代。 兩年前的「Gemini Pro 接近 GPT-4」放到今天沒意義，是因為兩個模型都被取代了，不是結論本身錯。
• 長 context 不是免死金牌。 知識庫夠小可以直接塞，夠大或會變動還是得檢索。

LlamaIndex 自己也在說明同一件事——它 2026 年的官方定位已經從「一個 RAG 框架」改成「文件工作流的 agentic 基礎設施」，理由是 agent 推理跟寫程式工具進步太快，框架抽象層重要性下降，真正沒解決的問題永遠是「怎麼把一份亂七八糟的 PDF 讀對」。RAG 這個詞兩年前是一套簡單的檢索加拼接，現在是一整條從資料處理到評測的工程鏈——cheat sheet 教你怎麼開始，evaluator 才告訴你什麼時候算做完。