昨天列了 Context Engineering（這系列的 L2）的工作清單，第一項是「模型缺的知識怎麼找進來」，這就是 RAG（Retrieval-Augmented Generation，檢索增強生成）。這個詞你大概聽過一百次了，今天想用窗口經濟學的角度重新看它：檢索做的事，是在每一次呼叫之前，替窗口動態決定「這次該放什麼知識」。看清這一點，很多 RAG 的設計問題會變得好判斷。

教科書版的 RAG，和它的三個裂縫

標準做法你可能已經熟：文件切成小塊（chunking）、每塊算成 embedding（Day 4 講過，把文字壓成向量、意思近的距離近）、存進向量資料庫；查詢時把問題也算成 embedding，撈出最相似的幾塊塞進窗口。

這條管線在很多場景可以用，但有一個團隊把它的裂縫暴露得特別清楚：LangChain。他們營運自家的文件問答 chatbot，某天發現一個尷尬的事實：自家工程師不用它。工程師遇到問題時走的是手動三步驟：查官方文件、查知識庫、直接搜程式碼。慢，但有效。

對照 chatbot 的向量檢索，他們找到三個結構性的問題：

• Chunking 破壞結構：文件本來有標題階層、步驟順序，切塊之後全沒了。使用者拿到的是碎片，缺的是脈絡
• Reindex 是持續的維護負擔：文件每天更新，每次都要重新切塊、重新 embedding、重新上傳，答案永遠慢半拍
• 引用模糊：答案說「來源：文件片段 #127」，使用者無從驗證，也點不回原文

用 Day 8（窗口經濟學）的語言講：這條管線塞進窗口的東西，同時得了「分心」和「污染」的病 — 碎片稀釋注意力，過時的 chunk 直接餵錯資訊。

他們的解法：讓 agent 直接用既有的結構

LangChain 重建 chatbot 時的關鍵發現是：文件本來就有結構、知識庫本來就有分類、程式碼本來就可以搜尋。與其把內容打碎再拼回來，他們把工程師的手動三步驟直接做成三個工具：文件 API 回完整頁面、知識庫 API 回分類文章、程式碼用 ripgrep（工程師慣用的高速文字搜尋工具）搜。檢索單位從「相似的碎片」變成「完整的頁面」。

更重要的變化在檢索的方式。向量檢索是一次性的：算相似度、拿 top-K、結束。新做法讓 agent 迭代地搜：使用者問「怎麼幫 agent 加 memory」，agent 先搜「memory」，發現這個詞有歧義（thread 內的對話歷史，還是跨 thread 的長期記憶？），分別搜「checkpointing」和「store API」，交叉驗證後合成一個涵蓋兩種場景的答案。這跟你自己查文件的過程一模一樣：搜、評估、換關鍵字、再搜。

效果有數字：token 用量降了四成，答案附可點擊的精確引用，reindex 成本歸零。內部工程師開始用自家產品了。

誠實版適用範圍：向量檢索沒有死

看到這裡先別急著把向量資料庫刪掉。這個案例的前提是內容本來就有結構：產品文件、知識庫、程式碼。結構化檢索是在利用這個前提，內容沒有這個前提時它就不成立。

• 適合向量檢索：非結構化內容（論文、書、PDF 堆）、需要語意層面的模糊匹配、內容不常更新
• 適合結構化檢索：文件、知識庫、程式碼這類本來就有組織的內容，尤其是更新頻繁、需要精確引用的
• 混合：兩邊都有就分層，結構化的走 API，非結構化的走向量

判斷方法比記規則簡單：觀察你的領域專家怎麼手動找答案。他們用關鍵字搜完整頁面，你就給 agent 一樣的工具；他們靠模糊的語意聯想翻資料，向量檢索才是對的形狀。LangChain 的整個重建，本質上就是把自家工程師的手動流程自動化而已。

檢索解決一半，另一半在明天

回到窗口經濟學：RAG 回答的是「模型缺的外部知識怎麼進窗口」。但 agent 跑起來之後，還有另一種資訊在不斷產生 — 對話裡使用者說過的偏好、任務做到一半的進度、上次踩過的坑。這些東西不在任何文件裡，沒人幫你 reindex，它們只存在於稍縱即逝的對話中。

誰決定哪些值得留下來？留下來的長什麼樣？這是記憶系統的問題，也是 L2 最深的一個坑。明天開始拆：記憶的寫入，誰決定什麼值得記。