Agentic RAG for Dummies：用 LangGraph 把檢索流程拆成看得懂的模組
A modular Agentic RAG built with LangGraph — learn Retrieval-Augmented Generation Agents in minutes.
秒懂
- 它是什麼？
- 這是一個以 Jupyter Notebook 為主體、用 LangGraph 實作的 Agentic RAG 教學專案，涵蓋父子區塊索引、多代理 map-reduce 與人類介入澄清。它適合想理解代理式檢索架構的開發者，但作為正式產品基底仍有不少需要自行補齊的地方。
- 適合誰用？
- 想理解 Agentic RAG 各環節如何串接的開發者，尤其是已經會用 LangChain 但還沒碰過 LangGraph 的人，這個專案是很好的教材。它把查詢重寫、澄清、平行檢索、自我修正拆成清楚階段，搭配 notebook 逐步執行，學習曲線比直接讀 LangGraph 官方文件平緩。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 16 天前。
- 用什麼語言寫的？
- 主要是 Jupyter Notebook（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這專案解決的是教學斷層，不是檢索效能問題
市面上 RAG 教學大多停在「切塊、嵌入、檢索、生成」這條直線。這個專案的 README 直接點出問題：多數教學缺乏如何建構模組化、代理驅動系統的指引。它想補的洞是架構層面的，不是演算法層面的。目標讀者很明確，是已經懂基本 RAG、想進一步理解代理如何協調檢索的人。專案提供兩條路徑：一條是 Colab 上可直接跑的 notebook，適合邊看邊改；另一條是模組化專案，每個元件宣稱可以獨立抽換。這種雙軌設計在教學 repo 裡算貼心，因為同一份程式碼要同時服務「想懂概念」和「想動手改」兩種人，其實不容易。
父子區塊：用兩次切割換取精準度與上下文
文件準備階段採用階層式索引。文件先依照 Markdown 標題層級切成較大的 parent chunk，再由每個 parent 切成固定大小的 child chunk。搜尋時以 child chunk 比對，命中後回傳對應的 parent chunk 給生成階段。這個設計的邏輯是：小區塊語意聚焦，檢索精準度高；大區塊含括前後文，回答時不會斷章取義。做法本身不新，Parent Document Retriever 的概念在 LangChain 生態裡已存在一段時間。但這個專案把它跟 LangGraph 的工作流綁在一起，讓使用者能在同一個圖結構裡看到「哪個節點負責切塊、哪個節點負責檢索」。README 還提到 Chunky 這個外部工具，宣稱可以轉 PDF、清理文件、比較切塊策略，但那是另一個 repo，這裡沒有提供整合範例。
四階段查詢流程：記憶、澄清、平行檢索、聚合
查詢處理被拆成四個階段。第一階段維護滾動摘要與近期對話歷史，用意是讓多輪對話有連續性，又不讓 context 無限膨脹。第二階段做查詢澄清：解析代名詞指涉、把複合問題拆成子查詢、偵測模糊輸入，必要時暫停並詢問使用者。第三階段是核心，對每個子查詢產生一個平行執行的代理子圖，每個代理各自搜尋 child chunks、抓取 parent chunks、在結果不足時自我修正、壓縮 context、搜尋預算耗盡時優雅回退。第四階段把各代理的回應聚合為單一答案。README 給的例子是「什麼是 JavaScript？什麼是 Python？」會觸發兩個平行代理。這個設計的取捨在於：平行執行換來速度，但每個子代理的搜尋預算必須設限，否則複雜查詢會讓成本失控。
Ollama 優先但可換供應商，模型大小有硬性建議
可執行應用預設使用 Ollama，README 給的範例指令是 ollama pull granite4.1:8b，然後用 langchain_ollama 的 ChatOllama 初始化，參數包含 temperature=0 與 seed=42。專案宣稱可換成任何 LangChain 支援的 chat model 供應商，並附上 OpenAI、Anthropic、Google 的範例，但那些範例被收在摺疊區塊，實際內容在提供的材料裡沒有展開。比較重要的是這句警告：要可靠呼叫工具與遵循指令，建議使用 8B 以上的模型，較小的模型可能忽略檢索指令或產生幻覺。這等於承認這個架構對底層模型的工具呼叫能力有依賴，不是換個模型就能無痛轉移。seed=42 這個設定也透露專案重視可重現性，但溫度設為 0 不代表輸出永遠一致，模型實作與硬體都會影響結果。
啟動方式：notebook 是入口，模組化專案需要自行組裝
README 提供 Colab 一鍵開啟的連結，指向 notebooks/agentic_rag.ipynb，這是學習路徑的起點。模組化路徑的安裝指令與詳細設定在提供的材料中被截斷，無法確認完整的 pip 安裝清單或環境變數設定方式。可以確定的是 Python 版本要求 3.11 以上，LangGraph 需要 1.2 以上，向量資料庫用 Qdrant。對於想跑本地版本的人，材料裡能確認的步驟只有安裝 Ollama、拉取 granite4.1:8b 模型、然後在 notebook 裡逐步執行。模組化專案的目錄結構、設定檔格式、如何指向自己的 PDF 文件，這些訊息在現有材料中都看不到。想從 notebook 過渡到可部署應用的人，需要自己翻 repo 原始碼才能補齊這段落差。
可觀測性與評估：Langfuse 與 RAGAS 是後見之明
專案把可觀測性與評估列為功能，分別用 Langfuse 追蹤 LLM 呼叫、工具使用與圖執行過程，用 RAGAS 評估檢索與回答品質。這兩個工具選得合理：LangGraph 的圖結構如果沒有外部追蹤，除錯時很難看出是哪個節點出了問題；RAGAS 則提供量化指標，不是只靠人工看回答順不順。但 README 沒有說明這些整合是預設開啟還是需要額外設定，也沒有提供任何評估結果範例。換句話說，評估框架是接上了，但沒有示範「跑完之後會看到什麼數字、那些數字代表什麼」。對教學專案來說，少了這一步有點可惜，因為評估的價值在於解讀，不在於能產生報表。
真正的限制：教學架構與生產架構之間的距離
這個專案最明顯的界線在於預設模型與文件格式。Ollama 在地端跑，隱私有優勢，但 granite4.1:8b 這類模型在複雜工具呼叫上的表現，跟雲端旗艦模型還有差距。README 自己警告小模型可能忽略檢索指令，這在代理式 RAG 裡是致命傷，因為整個流程依賴模型正確決定何時檢索、何時澄清、何時回退。文件格式方面，parent chunk 以 Markdown 標題為邊界，代表輸入最好是結構良好的 Markdown。如果你的來源是掃描 PDF 或格式混亂的網頁，這個切塊策略的效益會大打折扣。另外，多代理 map-reduce 的搜尋預算機制在 README 只有一句話帶過，沒有說明預算怎麼設定、耗盡後的回退品質如何。對照組是 LlamaIndex 的 AgentWorkflow 或微軟的 GraphRAG，前者把代理工具封裝得更抽象，後者專注在知識圖譜建構而非對話澄清。這個專案的位置比較接近「看得懂每一步在做什麼」的教學工具，而不是「丟文件進去就得到最佳答案」的產品。
授權與維護：MIT 乾淨，但更新節奏需要自己觀察
授權是 MIT，對學習與商業使用都友善，沒有 copyleft 包袱。repo 沒有被封存，最近一次 push 是 2026 年 8 月，v2.3 在 2026 年 6 月釋出，v2.2 在同年 6 月，v2.1 在同年 4 月。從版本間隔看，專案在 2026 年上半年的更新頻率不算低，但這種節奏能否維持，從材料中無法判斷。升級成本方面，LangGraph 1.2 以上的版本要求意味著 API 可能還在不穩定階段，LangGraph 本身在 1.x 系列有過 breaking changes，如果你把這個專案的架構抄進自己的程式碼，之後要跟上 LangGraph 新版可能得改圖定義。RAGAS 與 Langfuse 的版本相容性也沒有在 README 中說明。以教學 repo 來說，這些都可以接受，但如果你想以它為基底開發，請把「追上游更新」這項工作算進維護成本。
編輯結論
想理解 Agentic RAG 各環節如何串接的開發者，尤其是已經會用 LangChain 但還沒碰過 LangGraph 的人，這個專案是很好的教材。它把查詢重寫、澄清、平行檢索、自我修正拆成清楚階段，搭配 notebook 逐步執行，學習曲線比直接讀 LangGraph 官方文件平緩。但如果你要的是可直接上線的產品，請先確認三件事：預設的 Ollama 模型是否真的能穩定呼叫工具，你的文件是否適合以 Markdown 標題作為 parent chunk 邊界，以及你能否接受 map-reduce 在搜尋預算耗盡時的回退品質。這些在 README 裡都有提到，但沒有給出量化評估，需要你自己拿真實文件測試。
社群筆記