強化你的 RAG：利用 Multi-Agent Self-RAG 導入人類推理邏輯

原始來源與檔名：20260512_2026-05-06T095748+0800-Supercharge your RAG with Multi-Agent Self-RAG.md

來源：[[Julian Yip]] / Medium — 2026-05-03 原始檔名：2026-05-06T095748+0800-Supercharge your RAG with Multi-Agent Self-RAG.md

NAPKIN | 餐巾紙

餐巾紙公式

Simple RAG = Retrieve -> Generate (Fails on deep/complex queries). Self-RAG = Retrieve -> Grade Docs -> Hypothesis -> Brainstorm Queries -> Retrieve Again -> Final Generate. Multi-Agent Paradigm: Break the reasoning loop into explicit node states managed by LangGraph.

這篇文章指出了單次檢索 (Single-turn RAG) 在面對真實世界複雜問題時的無力。以「德里飛慕尼黑被拒絕登機可獲多少賠償？」為例，RAG 可能只會檢索到「賠償金額依距離而定」的政策文件，但無法給出精確數字。解法是導入「Multi-Agent Self-RAG」框架 (基於 LangGraph)。Agent 會先對檢索到的文件進行「評分 (Grade)」，然後像人類一樣提出「假設 (Hypothesis)」(我需要先知道兩地距離)，接著大腦風暴出新的查詢問題 (New Queries)，再次進入向量庫檢索距離數據，最終結合兩份文件給出精確答案。這是一個讓 AI 學會「思考後再問一次」的強大架構。

一句話

傳統的 RAG 系統是「找資料 -> 回答」，但人類找資料是「找資料 -> 發現線索 -> 提出新問題 -> 再找一次資料 -> 統整回答」。透過 LangGraph 實作的多智能體 Self-RAG，我們讓 AI 學會這套邏輯：先檢索，評估文件是否有用，如果資料不夠，AI 會自己提出假說（例如：我需要先查出兩地距離才能算賠償金），然後發動第二次檢索，直到收集齊全所有拼圖，才產出最終答案，徹底解決 RAG 容易給出空泛答案的致命傷。

餐巾紙草圖

[ Multi-Agent Self-RAG Loop ]

(1) User Query: "Delhi to Munich denied boarding compensation?"
       │
       v
(2) Retrieve: General EU policy (distance based)
       │
       v
(3) Grade Docs: Keep EU policy, drop US policy.
       │
       v
(4) Generate Hypothesis: "I need the exact distance."
       │
       v
(5) Transform Query: "Distance between Delhi and Munich?"
       │
       v
(6) Retrieve (Again): Distance is 5,931 km.
       │
       v
(7) Generate Answer: Distance > 3500km, so compensation is 600 EUR.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

痛點: 真實世界的問題需要多步檢索與推理。單純 RAG 無法處理需要跨文件關聯、或依賴中介資訊（如：先查距離才能算賠款）的複雜查詢。
解決方案 (Self-RAG with LangGraph):
- 1st Iteration (Simple RAG): 最基礎的 Retrieve -> Generate。
- 2nd Iteration (Grade Documents): 代理人針對取回的文件評分，保留有用的 (useful_documents)，並基於這些文件產生下一步的 hypothesis (假設)。
- 3rd Iteration (Transform Query): 代理人判斷目前資訊不足以作答，於是基於假設大腦風暴出新問題清單 (new_queries)。
- Final Iteration: 使用新問題再次進行 Retrieve，獲取補足的資訊後，最終交給 Generate answer 節點。
實作細節:
- 使用 Python 建立 TypedDict 定義圖譜的狀態 (GraphState)。
- 利用 LangGraph 的 StateGraph 定義節點 (Nodes) 與條件邊界 (Conditional Edges)。
- 核心精神在於將原本的 RAG 打斷為狀態機，讓模型在產生幻覺或資訊不足時，能自主繞回 transform_query 重新檢索。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

RAG 的能力天花板在於「單次命中率」: Vector Search 的本質是文本相似度，但複雜問題的答案往往不是單一文本，而是邏輯推導。如果系統缺乏「意識到自己不知道，並主動尋找缺少的一角」的能力，RAG 就永遠只是個笨拙的維基百科搜尋器。
狀態機架構確保控制流: 使用 LangGraph 而非單純的 Prompt Chaining，好處在於能夠保留歷史狀態（useful_documents 採取 append 而非覆寫）。這樣 Agent 在進行多輪對話與檢索時，不會出現「查了 B 忘了 A」的失憶症。

關鍵證據

在作者展示的實際 Log 中，系統清楚印出了它的「假設」：“To answer this question accurately, I need to determine: 1. Is this flight operated by an EU airline? … 2. What is the flight distance…”。隨後它主動產生了新查詢 “What is the flight distance between Delhi and Munich?”。這種中介推理軌跡 (Trace) 直接證明了 Agent 具備了規劃 (Planning) 的能力。

邊界條件

成本與延遲代價: Self-RAG 的致命傷是「慢」與「燒錢」。原本只需要呼叫 1 次 LLM 和 1 次 DB，現在可能要呼叫 4-5 次 LLM 來評分、改寫、重構，以及多次 DB 檢索。這套架構不適合用在對延遲要求極高 (如秒級客服回應) 的場景。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 呼應了《ADLC 開發方式》一文中提到的「機率論與非線性路徑」。Self-RAG 正是這種非線性行為的體現——即使輸入相同，Agent 也可能因為某次檢索結果不同，而走上不同的 Query 改寫路線。這也就是為什麼 ADLC 呼籲我們必須用語義評測（LLM-as-a-Judge）來測試 RAG 的 Groundedness（真實性）。
深層洞見: **“The hypothesis is especially useful when no useful documents can be identified initially, as the agent can still form hypothesis from documents not immediately deemed as useful.” (當一開始找不到有用文件時，假設特別有用，因為代理人仍能從看似無用的文件中形成假設，以決定下一步該問什麼。) ** 這打破了我們對檢索系統的思維：有時候檢索回來的「錯誤資料」並非毫無價值，它能成為指引系統「換個方向問」的探路石。
行動呼籲: 如果你手邊有正在開發的 RAG 專案，請做一個壓力測試：問它一個需要「兩層邏輯關聯」的問題（例如：公司最新規定中，住在距離總部最遠的董事可以報帳多少交通費？）。如果它失敗了，請不要急著去調整 Embedding Model，試著引入一個簡單的 LLM Evaluator 節點，讓它學會判斷「資訊不足時，把問題拆解後再搜一次」。