書摘筆記|Learning LangChain(Oshin & Campos)
來源：Mayo Oshin & Nuno Campos,《Learning LangChain》(O'Reilly)
這是一篇整理筆記，記錄這本書關於 LLM 應用組裝、RAG 兩部曲、認知架構光譜與上線工程的核心觀點。重點是可複習的概念與線索，不是完整教學。
核心主題
做 LLM 應用的真正功夫，不在呼叫模型，而在「組裝」：把提示、檢索、記憶、工具呼叫組成適合你目的的認知架構，再用工程方法讓它可靠地上線——LangChain 與 LangGraph 就是這套組裝的工具箱。
核心觀點
- LLM 應用的核心挑戰只有一件事：如何有效建構送進模型的提示，並處理模型回傳的預測。框架的價值在於把常見解法做成可替換的積木（模型、提示模板、輸出解析器都遵守同一套介面，供應商可隨時抽換）
- RAG（檢索增強生成）解決兩個模型天生的缺口：私有資料與知識截止日之後的時事。流程固定三段：索引（切塊、嵌入、存向量資料庫）→ 檢索 → 生成
- LLM 是無狀態的，「記憶」是工程出來的：把對話歷史存起來、修剪、塞回提示；LangGraph 用 checkpoint（檢查點）把狀態持久化，才能中斷、續跑、重試
- 認知架構是一條「自主程度光譜」:0 純程式碼 → 1 單次 LLM 呼叫 → 2 鏈（固定步驟）→ 3 路由器（LLM 選步驟）→ 4 代理（LLM 自己決定迴圈何時停）。愈自主愈強，也愈不可靠
- 自主與可靠是一組取捨，但工程模式可以把這條邊界往外推：串流輸出、結構化輸出、人在迴路、反思（生成與評論互相迭代）、多代理分工
詳細內容
一、基礎建材：模型、RAG 與記憶（第 1-4 章）
- 核心概念：LangChain 把「聊天模型、提示模板、輸出解析器、嵌入、向量資料庫」做成共用規格的元件，用管線符號串起來；同一份程式可在 OpenAI、Anthropic、開源模型之間切換
- RAG 第一部（索引）：載入文件 → 切塊(chunk)→ 嵌入成向量 → 存入向量資料庫。嵌入是把文字變成可運算的數字序列，語意相近的文字向量也相近
- RAG 第二部（檢索）：進階策略都圍繞「使用者的問題不一定是最好的查詢」——改寫查詢(Rewrite-Retrieve-Read)、多查詢檢索、RAG-Fusion（多查詢加排名融合）、HyDE（先生成假想答案再拿去檢索）、查詢路由與 Text-to-SQL
- 記憶系統的兩個設計決策：狀態怎麼存、怎麼查。基本款是把訊息列表附回提示；上線後要面對原子性更新、耐久儲存、訊息修剪與過濾，這正是 LangGraph 出場的理由
二、認知架構與代理（第 5-7 章）
- 核心概念：先寫下應用的目的與「限制條件」，再選架構。書中以 email 助理為例：希望少打擾你、又不能代你寄出失禮的信——這就是自主(agency)與可靠(reliability)的取捨
- 代理架構 = 工具呼叫 + 思維鏈 + LLM 控制的「計畫-執行」迴圈；停止條件由 LLM 決定，這是它和鏈、路由器的本質差異
- 延伸一：反思(self-critique)——生成節點與評論節點來回迭代，模擬人類 System 2 的慢思考
- 延伸二：多代理——子圖(subgraph)與監督者(supervisor)架構，像團隊分工一樣拆任務
三、上線工程：模式、部署與測試（第 8-10 章）
- 把邊界外推的四個模式：結構化輸出（提示、工具呼叫或 JSON 模式，框架統一成一個介面）、逐 token 串流、人在迴路（中斷、核可、分叉、回復）、double texting（使用者連發訊息的處理）
- 部署範例的組合：向量資料庫(Supabase/pgvector)+ 監控(LangSmith)+ 後端（LangGraph Platform，支援排程、webhook、串流）
- 測試貫穿三階段：設計期（執行時自我修正，如自我修正 RAG——先評分檢索結果、再檢查答案是否幻覺）、上線前（資料集回歸測試）、上線後（監控與回饋迴圈）
四、LLM 該長什麼樣子給人用（第 11 章）
- 三種使用者體驗模式：互動聊天機器人（最容易加進既有產品）、協作編輯（LLM 當共同作者，需要共享狀態）、環境運算（ambient,LLM 在背景持續工作，需要觸發器、長期記憶、反思與摘要）
- 協作與環境的差別在「並行」：前者是你和 AI 同時工作互相餵料，後者是 AI 在背景做事、只在值得注意時浮出來
金句摘錄
- 打造 LLM 應用的真正挑戰，在於如何有效建構送進模型的提示，並處理模型的預測以回傳準確的輸出。（第 1 章）
- 游泳池和平房用的是同樣的建材；讓它們適合不同用途的，是組裝建材的那份計畫——架構。（第 5 章）
- 代理架構的關鍵，是把迴圈的停止條件交給 LLM——讓它自己決定何時停。（第 6 章）
- 應用愈能自主行動就愈有用，但放任過頭，它終究會做出你希望它沒做的事。（第 8 章）
- 串流聊天可能會成為 LLM 時代的命令列：最接近直接操作模型的介面，但終將變成小眾。（第 11 章）
實踐方法
- 從光譜最低處開始：先試單次 LLM 呼叫，不夠再升級成鏈、路由器，最後才是代理——每升一級都付出可靠度
- 動手前先寫兩份清單：應用的目的、行為的限制條件；限制條件會直接指向適合的架構
- 資料量小就直接塞提示，大到塞不下才需要 RAG；檢索品質不好時，先改查詢（改寫、多查詢）再動索引
- 需要下游程式處理的輸出，一律用結構化輸出並為每個欄位寫清楚描述
- 上線前先建評測資料集，讓每次改提示都有回歸測試可跑，而不是憑感覺判斷有沒有變好
這篇筆記後來長成了方法論文章：〈想做自己的 AI 應用，需要學 LangChain 嗎？一張地圖看懂 AI 應用開發〉