Plan-and-Execute：先規劃再執行的 RAG 模式
對複雜問題，先讓 LLM 規劃出需要哪些資訊、分幾步取得，再按計畫執行，比邊搜邊想更系統化。
全部文章
第 127 頁，共 128 頁
Query Classification：讓 RAG 知道該怎麼回答這個問題
不是所有問題都需要 RAG。用 LLM 先分類查詢類型，再決定執行路徑，節省成本又提升準確度。
RAG A/B 測試：怎麼科學地比較兩個 Pipeline 配置
「加了 Cross-Encoder 之後感覺好多了」不是科學的評估。A/B 測試讓你知道改動是否真的有效，效果多大，在哪類查詢上有效。
RAG 冷啟動：沒有資料時怎麼讓系統能用
RAG 系統需要資料才能回答問題，但一開始就沒有資料。冷啟動策略決定了系統從空到可用的路徑。
RAG 成本優化：把每次查詢的花費壓到最低
RAG 系統的成本來自 LLM token、Embedding API、向量搜尋。每個環節都有可以壓成本的地方，但要確認優化沒有犧牲太多品質。
RAG 評估框架與工具選型：Promptfoo、RAGAS、DeepEval、TruLens
RAG 評估沒有指定工具的業界標準；先把 retrieval、generation、operation 分開量，再依技術棧選 Promptfoo、RAGAS、DeepEval 或 TruLens。
RAG 常見失敗模式：10 種問題和對應的解法
RAG 系統出問題，90% 的情況是這 10 種之一。先識別是哪種失敗模式，再找對應的解法，比盲目優化有效很多。
RAG Guardrails：在輸入和輸出加一道防線
RAG 系統面對的攻擊不只是技術層面的，Prompt Injection 和 Jailbreak 是真實威脅。輸入輸出都需要獨立的防護層。
RAG 可觀測性工具全景：2026 年的選擇
自己寫 trace 夠用，但開源工具讓你少做很多事。Langfuse、Phoenix、LangSmith 各有定位，選哪個取決於你對自架、開源、整合複雜度的取捨。
RAG Observability：讓黑盒子變透明的逐節點追蹤
RAG 系統最難的不是建起來，是搞清楚為什麼這次回答不好。Pipeline Tracing 把每個步驟的決策和數據記下來，讓除錯有跡可循。
RAG Prompt Engineering：System Prompt 和 Context 怎麼設計
搜尋找到了正確的文件，但 LLM 的回答還是不好——很多時候問題在 Prompt 設計。System prompt 結構、context 排版、指令語言都會影響輸出品質。
RAG Streaming：SSE 讓 LLM 回答邊生成邊顯示
LLM 生成需要 3-5 秒，等全部生成完再顯示體驗很差。SSE 讓 token 一邊生成一邊推送，首個字元出現時間從 5 秒縮到 1 秒以內。
RAG 配額系統：用雙重限制控制 LLM 成本
只限制請求次數不夠，一個超長的查詢可能消耗掉十個普通查詢的 token。雙重配額（請求數 + token 數）才能真正控制成本。
RAG vs Fine-tuning：不是非此即彼
RAG 和 Fine-tuning 解決的是不同問題。RAG 給模型新知識，Fine-tuning 改變模型的行為風格。大多數情況是兩者都用，而不是選一個。
RRF：RAG 系統裡多路結果怎麼合併
BM25、向量搜尋、HyDE、Multi-Query 各出一份結果，怎麼合理地合成一份？RRF 用名次而不用分數，規避了跨系統分數無法比較的根本問題。
Self-Reflection + LLM-as-Judge：讓 AI 評估自己的回答
用另一個 LLM 評估回答的準確度和品質，分數太低就重新生成，並自動加上適當的免責聲明。
Semantic Caching：語義相近的問題只跑一次 RAG
快取不只能比對完全一樣的查詢，語義相近的問題也能命中快取，省下整個 RAG pipeline 的執行。
SPLADE：比 BM25 更聰明的稀疏向量搜尋
BM25 只認識查詢裡出現的詞，SPLADE 能推斷相關詞彙並加入搜尋，在保持關鍵字搜尋精確性的同時獲得部分語義能力。
Text-to-SQL Router：精確查詢不走 RAG
「我今年完攀幾條」這種問題，RAG 語義搜尋永遠不如直接查資料庫。讓 LLM 識別意圖、提取參數，執行預定義 SQL 模板。
Vector Database 選型：Pinecone、Weaviate、Qdrant、Vectorize 怎麼選
向量資料庫的選型比 LLM 選型更受部署平台限制。先確認平台和規模需求，再看功能特性，不要只看 benchmark。