搜尋之前先修好查詢
使用者問的問題很雜亂：含糊、代名詞一堆，或仰賴對話前文（那第二個呢？）。拿這種原始文字去搜，檢索效果很差。查詢改寫（query rewriting）會先插入一個小小的 LLM 步驟，把問題改寫成乾淨、自足的搜尋查詢——把它、那個指代清楚、展開縮寫，或把一個糾結的問題拆成好幾個。
一個近親是查詢擴展（query expansion）：替問題生出幾個改寫版本，各自檢索，再把結果合在一起——當你很難猜到文件的用詞時特別有用。這兩招都只多花一次便宜的模型呼叫，但提升檢索的效果，往往勝過任何嵌入上的微調。
多跳檢索
有些問題沒辦法靠單次搜尋回答，因為答案得仰賴一個中間事實。帶領打造我們計費服務那個團隊的人是誰？需要兩跳：先找出哪個團隊負責計費，再找出那個團隊的主管。多跳 RAG（multi-hop RAG）會先檢索、閱讀，從學到的東西組出一個後續查詢，再檢索一次——把多次搜尋串起來，直到湊齊每一塊。
代理式 RAG
代理式 RAG（agentic RAG）把整個迴圈交給一個LLM 代理人（LLM agent），由它自行決定要做什麼。不再是固定的「先檢索再生成」流水線，模型可以選擇搜尋、判斷結果夠不夠好、用更好的查詢再搜一次、呼叫其他工具（計算機、資料庫、網路搜尋），直到滿意了才作答。檢索變成代理人視需要呼叫的眾多工具之一。
大语言模型智能体循环：模型对任务进行推理、执行如检索等行动、观察结果，反复迭代直到完成。
這份靈活性能處理固定流水線搞不定的問題——但代價是更多次呼叫、跑得更慢，也更難除錯，因為每次走的路徑都不一樣。當問題真的很開放時，才動用代理式 RAG；對常見、形狀規整的問題，就保留簡單的流水線。多數正式上線的系統都是兩者並用。
評估 RAG
你無法改善沒在量測的東西，而RAG 評估（RAG evaluation）剛好乾淨地分成兩半。檢索面的指標問：對的塊回來了嗎？建一個小題庫，每題配上真正能回答它的塊，再追蹤召回率（recall，黃金塊有沒有被檢索到）和精確率（precision，回來的東西裡有多少是相關的）。
相关文段与检索文段的文氏图，其交集定义了精确率与召回率。
生成面的指標問的是最終答案：它忠實嗎（每個論點都有檢索脈絡支撐、沒有捏造的事實）、切題嗎（真的回答了問題）、完整嗎？忠實度常用LLM 當評審（LLM-as-a-judge）來評分——讓第二個模型逐句對照引用的脈絡查核。兩半都要盯：檢索很好但生成器不接地、或生成器很忠實卻被餵了錯的塊，兩種都算失敗。
- 建一個小而真實的測試集——真正的使用者問題，每題附上黃金段落和一個理想答案。
- 分開評分檢索與生成，這樣一旦退步，就能精準指出是哪一階段壞了。
- 一次只改一個變因——塊大小、嵌入模型、重排器、提示——再重跑；只保留數字認可的改動。
Recall@k——在检索结果前 k 名中出现的相关文段占全部相关文段的比例，是要追踪的核心检索指标。