閱讀筆記 — 為什麼你的 RAG 需要一個會反省的大腦：Agentic RAG 完整解析

原文：How Agentic RAG Works（ByteByteGo）

你有沒有遇過這種情況：RAG 系統看起來運作正常，向量搜尋在搜、LLM 在回答——但給出的答案就是不對，或是答非所問？這篇文章正是在拆解這個問題的根源，以及為什麼在查詢和回答之間加一層「會思考、評估、重試的代理人」，可以從根本解決這件事。

標準 RAG 的問題：沒有人在反省

標準 RAG 是個單向流水線，流程很乾淨：使用者問問題 → 嵌入成向量 → 從向量庫撈前幾個 chunk → 丟給 LLM 生成回答。聽起來很合理，但它在以下三種情境會直接失靈：

1. 問題含糊：像「How do I handle taxes?」，到底是個人稅、公司稅還是非營利組織稅？標準 RAG 不會問你、不會猜你，只會照字面去搜，搜到什麼算什麼。

2. 答案散落在多份文件：例如「遠端工作承攬商政策」同時涉及 remote policy 和 contractor agreement 兩份文件，但普通 RAG 通常只從最相似的一個來源拿資料，拼圖只有一半。

3. 撈到看起來相關但其實錯的東西：相似度高不等於正確，可能是過期資訊，可能是沒真正回答問題的段落——但系統還是會很有自信地把它包進回答裡。

根本原因是：整個流程中間沒有一個節點在問「我剛才拿到的東西夠好嗎？」😮‍💨

Agentic RAG 的核心概念：把流水線變成控制迴圈

Agentic RAG 的核心概念是：把線性管線改成帶有決策點的控制迴圈。

1

檢索 → 評估 → 夠好？ → 是：回答 / 否：重試（換查詢、換來源）

文章把「agent」定義為一個不只是生成文字、還能做決策與呼叫工具的 LLM。這個 agent 可以改寫查詢、切換資料源、再次搜尋、查新版文件——在「一次射門就結束」之前，多一層判斷。

相比標準 RAG，Agentic RAG 多了三個關鍵能力：

🗺️ 工具使用與路由（Routing）

問題可以被導向不同知識源（SQL 資料庫、文件庫、產品 DB……），或者一次查多個來源再整合答案。問題屬於哪個 domain，就路由到哪個「專家來源」。

✏️ 查詢精煉（Query Refinement）

在檢索之前先把模糊的問題改寫成更具體的版本；如果第一次搜尋結果很弱，就再重寫查詢、重新搜。這相當於把「問問題的方式」也納入自動優化的範圍。

🔍 自我評估（Self-Evaluation）

取回結果後，agent 會檢查：相關嗎？完整嗎？有沒有矛盾？是不是過期版本？如果不夠好，就換查詢或換來源，而不是直接吐出去。

文章也強調這是一個光譜：從最簡單的「只負責路由到不同知識庫」，到 ReAct 那種 Reasoning + Acting 反覆交替，再到多 agent、由 orchestrator 協調的複雜系統。你不一定需要最複雜的版本。

三種失敗，三種修正

作者把標準 RAG 的三個失敗場景，直接對應到 Agentic RAG 的解法：

另外還可以加上記憶（memory）和 semantic cache，跨多輪對話保留脈絡，讓整個系統更像在做對話，而不是每次重新開始。

代價與風險：這不是免費升級 ⚠️

這段是我覺得文章最有價值的部分——作者非常誠實地列出 Agentic RAG 的代價，並強調要把它當作工程決策，而不是預設選項：

⏱ 延遲放大：每一圈 loop 都是多一次 LLM + 檢索。1–2 秒的標準 RAG，可能變成 10 秒。即時聊天場景常無法接受這個代價。

💸 成本膨脹：多出來的推理 token，可能讓成本放大 3–10 倍。如果 80% 的問題其實是簡單 FAQ，這個成本根本不值得。

🔀 可預測性變差：因為 agent 會依情況做不同決策，同一個問題在不同時刻可能走完全不同的路徑，難以重現、難以測試、難以向利害關係人解釋。

🤔 評估悖論（Evaluator Paradox）：你用 LLM 來評審另一個 LLM 的檢索好不好。如果評估模型自己不夠好，會錯殺好結果或放過爛結果，整個「自我修正」就從優勢變成新的 bug 來源。

🔄 過度修正（Overcorrection）：agent 可能「嫌東嫌西」，捨棄本來就夠好的資料，一直找「更好」但實際上反而更差的東西。

作者也提醒：很多時候，先把 chunking、索引、資料新鮮度等基礎檢索品質做好，比堆 agent 還有價值。別用複雜度來掩蓋基礎建設的問題。

什麼時候才值得用 Agentic RAG？

文章最後給了一個判斷準則，用三個問題自問：

1. 系統有沒有在正確的來源檢索？
2. 能不能評估檢索結果是不是夠好？
3. 不夠好時，有沒有能力重試或改變策略？

如果三個答案都是「沒有」，而且查詢本身又複雜、多來源、不那麼結構化，那就值得考慮 Agentic RAG。

如果查詢很簡單、知識庫乾淨單一——老實用標準 RAG，反而是最合理的選擇。

作為軟體工程師的反思

讀完這篇，我腦海裡冒出的第一個念頭是：這個架構，其實可以直接搬到日常的工程開發流程上。

其實這個「每個 agent 是某個領域的專家，搭配自己的知識來源，做完決策再傳給下一個節點」的概念，在我之前寫的那篇 AI 輔助工程閱讀筆記裡就有提到——把 AI 當作一個專家團隊來使用：TypeScript 問題找 TS 專家、架構問題找前端專家、Infra 問題找 DevOps 專家，生成與驗證由不同「專家」負責。而 Agentic RAG 就是把這個想法具體化了，給每個 agent 配上自己的知識庫，讓它在自己的 domain 裡做判斷，再把結果往下傳。

把這個概念帶到產品開發流程上，可以這樣想：

• 一個寫 Spec 的專家 agent：整理需求、補問關鍵問題、產出結構化 spec（user story、edge cases、non-functional requirements……）
• 一個流程架構設計的專家 agent：根據 spec 出 API 設計、資料流、boundary 切分，甚至建議 event 流或 schema
• 一個知識檢索 agent（公司內部的 RAG）：專門去查公司歷史 PRD、設計規範、過往類似功能，避免重複踩坑
• 一個風險 review agent：專門挑一致性問題、資安疑慮、隱性需求漏掉、跟現有系統的衝突

你站在最上層當 orchestrator，agents 先把「粗糙的版本」鋪好，你再用判斷力去取捨、改寫、合併——這就是把 Agentic RAG 的「decision points」放大到整個開發流程。

當然，文章的警告也完全適用到這個場景：延遲、可預測性、評估悖論——agent 的輸出品質取決於你給它的輸入品質，以及你怎麼定義「夠好」。幾個落地建議：

• 從最痛的兩個環節開始，不要一口氣把全部流程都 agent 化。先從「規格常漏東西」或「架構設計常回頭重改」下手，體感差異最大。
• 強制每個 agent 有固定的輸入和輸出格式，不然它會變成很會講廢話的聊天夥伴。spec agent 的輸出一定要有固定 sections；design agent 一定要有明確的 API 列表或資料表設計。格式穩定，才有辦法串起來用。
• 在人類審查最貴的地方讓 agent 先擋一輪：把 lead 或架構師的時間壓縮在真正的 trade-off 判斷，而不是 basic 漏洞。

從「AI 專家團隊」到「Agentic RAG」，其實是同一個概念在不斷具體化的過程——而這篇文章讓我更清楚地看到，這個控制迴圈的架構，可以延伸到遠比 RAG 更廣的地方。🚀