對應原題（Common ‧ RAG and Retrieval）
- What is HyDE (hypothetical document embeddings) and when does it outperform standard dense retrieval?
- How does agentic RAG differ from standard RAG, and when is the extra complexity justified?
🎯 什麼情境該想到我
當你「索引沒問題、reranker 也上了，但使用者就是搜不到」的時候。這時瓶頸往往不在索引端，在查詢端。
⚙️ 怎麼用
★ 根本問題：查詢與文件的不對稱
| 使用者查詢 | 答案文件 | |
|---|---|---|
| 長度 | 5–15 字 | 200–500 字 |
| 句型 | 疑問句、口語 | 陳述句、書面 |
| 用詞 | 日常說法（「連不上」） | 專業術語（「TLS 握手逾時」） |
| 脈絡 | 隱含（多輪對話裡是代詞） | 完整 |
embedding 模型要把這兩種東西映到同一個空間附近，天生就難。
→ 索引端的解法是加脈絡（見 切塊與文件解析）；查詢端的解法就是這一頁。
查詢改寫的階梯
| # | 手法 | 做什麼 | 成本 |
|---|---|---|---|
| 1 | 正規化 / 指代消解 | 「它支援嗎？」→「OAuth 2.0 支援 refresh token 嗎？」 | 1 次小模型呼叫 |
| 2 | 多查詢擴展 | 生成 3–5 個不同說法的變體，各自檢索，用 RRF 合併 | N 次檢索 |
| 3 | 查詢分解 | 「A 和 B 哪個便宜」→ 拆成「A 的價格」「B 的價格」 | N 次檢索 + 合成 |
| 4 | Step-back | 先問更抽象的問題（「這個錯誤怎麼修」→「這個模組的錯誤處理機制」），把背景一起撈回來 | 2 次檢索 |
| 5 | HyDE | 先讓 LLM 編一篇假答案，用假答案去檢索 | 1 次 LLM 生成 |
★ 第 1 項是多輪對話 RAG 的必做項，而且最常被忽略。
使用者第三輪說「那這個要怎麼設定？」——把這句原樣丟去檢索，等於什麼都沒查。
很多「多輪對話 RAG 很爛」的專案，真正的 bug 只是沒做指代消解。
★ HyDE：用假文件去搜真文件
Gao et al., 2022 — Precise Zero-Shot Dense Retrieval without Relevance Labels
使用者：「為什麼我的 Go 服務記憶體一直漲？」
│
▼ ① 叫 LLM 寫一篇假想的答案文件（不檢索，純編）
「Go 服務記憶體持續成長常見於 goroutine 洩漏。當 goroutine 阻塞在
未關閉的 channel 上⋯可用 pprof 的 goroutine profile 檢查⋯」
│
▼ ② 用這篇假文件的 embedding 去檢索（原查詢丟掉）
▼
真實文件：「Go 記憶體洩漏排查指南」✅
★ 為什麼「假的」反而有效：
它把「問題空間」映射到「答案空間」。
假文件就算事實全錯，它的形狀是對的——長度、句式、術語密度、領域詞彙都和真正的答案文件相似。
而 embedding 相似度捕捉的主要就是這種分布層面的相似，不是事實正確性。
換句話說：HyDE 是免訓練的 query→document 空間轉換器。 原本要靠標註資料微調 retriever 才能學到的對齊，它用一次 LLM 呼叫換到。
什麼時候勝過標準 dense：
- ✅ Zero-shot / 沒有標註資料可以微調 retriever（這是論文的主場）
- ✅ 使用者用語與文件用語落差大（口語 vs 專業、客服 vs 技術文件）
- ✅ 查詢很短、很模糊
- ✅ 模型對該領域有常識（能編出形狀正確的假文件）
什麼時候不要用：
- ❌ 查詢本身已經是關鍵字或識別碼 ——
ERR_4012不需要擴寫，直接 BM25（見 稀疏與密集檢索） - ❌ 模型對該領域一無所知 —— 編出來的假文件會把檢索帶向錯誤的方向，比原查詢更糟
- ❌ 延遲敏感 —— 多一次 LLM 生成，直接加在 TTFT 上
- ❌ 已經有足夠標註資料微調 retriever —— 微調過的 retriever 通常更好且更便宜
實務折衷：
- 生多篇假文件取平均 embedding，降低單篇的隨機偏差
- 把假文件的 embedding 和原查詢的 embedding 加權平均，保留原意不跑偏
- 只對「長的、模糊的、自然語言的」查詢啟用——用一個分類器路由
🤖 Agentic RAG
和標準 RAG 的差別
標準 RAG（固定管線）
查詢 → 檢索一次 → 生成一次 → 答案
★ 步數固定、延遲可預測、好評估
Agentic RAG（模型自己決定）
查詢 → ┌─ 要不要檢索？（有些問題不需要）
├─ 該查哪個來源？（文件庫 / SQL / 網路 / API）
├─ 查什麼？（自己構造查詢）
├─ 查回來的夠嗎？（自我評估）
└─ 不夠 → 換個查法再來一次 ──┐
└──▶ 答案
★ 步數不定、延遲不可預測、難評估
常見形態：
| 形態 | 做什麼 |
|---|---|
| 路由 | 依查詢意圖選資料源（產品文件 / 工單系統 / 網路搜尋） |
| Self-RAG | 模型自我評估「這段相關嗎」「我的答案有被支持嗎」，不合格就重來 |
| Corrective RAG (CRAG) | 檢索品質評分過低就 fallback（例如改用網路搜尋） |
| 多跳 / ReAct 式 | 用上一輪的結果構造下一輪的查詢（見 ReAct 與 Agent Loop） |
| 查詢規劃 | 先拆解出子問題與相依關係，再依序執行 |
★ 最小可行版：一個檢索工具 ＋ 一個「夠不夠」自檢環
（補充自 https://juejin.cn/post/7690218295266066441，查證 2026-09-28）
上表五種形態容易讓人以為 agentic 要「重裝備」。實務上八成收益來自最便宜的那一段：
檢索 → 問模型「這些夠不夠回答？」
├─ 夠 → 作答
└─ 不夠 → 改寫查詢，再查一次（設上限，通常 2–3 輪）
這就是 CRAG 的輕量版：一個檢索工具 + 一個自檢環，不需要多智能體、不需要路由器。
★ 工具堆多了反而亂。先加自檢環量一輪，再決定要不要往上加路由與規劃。
分類與訓練路線的完整整理 → Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG，arXiv 2501.09136（2025-01，已查證存在）。
★ 什麼時候值得付這個複雜度
先量清楚「單輪 RAG 在哪些查詢上失敗」，再決定。
| 失敗原因 | 該做什麼 |
|---|---|
| 沒撈到（recall 低） | ❌ 不是 agentic 的問題 → 修切塊、加 hybrid、加查詢改寫 |
| 撈到但排序爛 | ❌ → 加 Reranker 重排序 |
| 需要組合多份文件才能回答（多跳） | ✅ agentic 值得 |
| 不同查詢需要不同資料源 | ✅ 路由值得 |
| 有些查詢根本不該檢索（閒聊、算數） | ✅ 值得（而且省錢） |
| 答案需要驗證（高風險領域） | ✅ 值得 |
★ 最常見的錯誤是「檢索品質不好，就上 agentic RAG」。
讓模型查五次爛檢索，不會比查一次好檢索更準——只會慢五倍、貴五倍，而且更難除錯。面試答法：「我會先做失敗分析，把單輪 RAG 的錯誤分成『沒撈到／排錯／本質上需要多跳』三類。
只有第三類是 agentic 能解的。前兩類上 agentic 是用複雜度掩蓋基礎問題。」
代價（要能講出來）
- 延遲不可預測 —— 2 步或 8 步差很多，SLO 很難訂
- 成本不可預測 —— 必須設步數與 token 預算上限（見 ReAct 與 Agent Loop）
- 評估變難 —— 不再是「檢索對不對」，而是整條軌跡對不對
- 新的失敗模式 —— 無限重查、越查越偏、自我評估過度樂觀
- 除錯需要完整 trace —— 沒有可觀測性就等於瞎
⚠️ 注意 / 什麼時候不適用
- 查詢改寫會丟失資訊。改寫後一定要同時保留原查詢去檢索一次，用 RRF 合併——避免改寫本身變成新的失敗點。
- 改寫與 HyDE 都增加 TTFT。可以用小模型（Haiku 等級）做改寫，成本與延遲都低一個量級。
- 多查詢擴展會放大檢索成本（N 倍的向量搜尋）。要確認向量庫撐得住。
- HyDE 的假文件不可以進入最終答案。它只用來算 embedding，絕不能被模型當成證據——這是很危險的 bug。
- Agentic 的自我評估常常過度樂觀。「我覺得資料夠了」這個判斷本身需要被評估。
- 所有查詢端手法都要能關掉。加一個 feature flag，出事時能立刻退回單純檢索。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：多輪 RAG 先確認有沒有做指代消解。
🔗 相關
- 稀疏與密集檢索 —— 精確匹配型查詢不需要改寫
- 切塊與文件解析 —— 索引端的對稱解法（contextual retrieval）
- Reranker 重排序 —— 排序問題該用它，不是用 agentic
- ReAct 與 Agent Loop —— agentic RAG 的底層迴圈
- RAG 評估與營運 —— 失敗分析怎麼做
- 工具-RAG檢索增強生成 —— 決策層