延續昨天用電商 AI 客服的案例，從最小 Baseline 開始拆 System Design。

如果使用者問「跑步鞋和休閒鞋有什麼差別？」
這是一個通用知識問題，User → Application → LLM → Response 就可能已經足夠。

但當問題變成

「你們這雙鞋可以機洗嗎？」
「這個商品的保固多久？」
「你們現在的退貨規則是什麼？」

答案就不再只是模型本身的通用知識，而是來自企業自己的商品資料、政策與文件。

昨天我們先把這類需求歸到 Knowledge Requirement。
今天就來繼續往下一層拆：Baseline 確定缺少外部資訊之後，到底應該怎麼把正確的 Context 補進模型？

缺 Knowledge，不代表第一步就是 RAG

假設公司的退貨政策只有三條，加起來不到幾百個字。
最簡單的方法可能只是直接把規則放進 Context，和 User Question 一起交給 LLM。
這時候不需要 Vector Database，也不需要額外建立 Retrieval Pipeline。

真正需要 Retrieval，是當企業 Knowledge 的規模逐漸增加，而每一次 Request 又只需要其中的一小部分。大型電商可能同時有商品說明、退換貨政策、配送規範、會員制度、產品手冊與 FAQ，全部塞進 Prompt 已經不合理，問題才逐漸變成：這一次推論，到底應該讓模型看到哪些外部資訊？

從 System Design 的角度看，我會把這件事理解成一個 Context Selection Problem。

例如使用者問「這雙鞋洗過之後還能退嗎？」，真正需要的資訊可能同時包含商品類別、清潔方式、已使用商品的退貨政策，以及特殊品項是否存在例外。

如果 Retrieval 只找到很多「鞋子相關文件」，卻沒有取回真正影響退貨資格的規則，最後仍然可能回答錯。Retrieval 的目的不是找到最多相似文字，而是取得足以支撐這一次任務的 Context。

先找 Source of Truth，再決定 Context 怎麼取得

表面上都是「商品問題」，真正的 Source of Truth 卻可能完全不同。

所以「模型不知道」並不代表「把資料做 Embedding」。

比較合理的順序是

1. 先確認資訊真正存在哪裡
2. 再決定要透過 Search / Retrieval、Structured Query，還是 Tool / API 取得
3. 這幾種方式最後都能把資訊補進 LLM Context，但解的是不同的資料存取問題

例如退貨政策、FAQ、產品手冊這類內容，本質上是從大量文字中找到相關資訊；Product Catalog 已經具有品牌、尺寸、材質、品類等 Schema，通常應該保留這些結構；而價格、庫存、訂單等持續變動的狀態，則更適合直接向真正的 Business System 查詢。

換句話說，是否使用 RAG 不是單純由「資料是結構化還是非結構化」決定，而是由 Source of Truth 與 Access Pattern 共同決定。

資料型態決定的是怎麼把 Context 取得得更準

決定 Access Pattern 之後，資料本身的結構才開始影響 Retrieval Pipeline 怎麼設計。

最典型的非結構化文件，例如退貨政策、FAQ、使用手冊，重點通常是把長內容整理成可搜尋的單位，再找到真正相關的段落。商品 Catalog、JSON、HTML、表格或帶有明確章節結構的文件則不同。這些資料本來就包含品牌、分類、Field、Section、Metadata、Parent-Child Relationship 等有價值的結構，如果全部攤平成純文字後只做 Vector Search，反而可能把原本有用的訊號丟掉。

例如一份商品資料可能天然存在：

商品 → 品類 → 規格 → 材質 → 清潔方式 → 注意事項

當使用者詢問「這雙鞋能不能機洗？」時，系統可以先利用商品 ID、分類或「清潔方式」等 Metadata 縮小範圍，再進一步使用 Semantic Retrieval。

這類設計可以理解成 Metadata-enriched / Structure-aware Retrieval：
資料原本的結構並不是 Retrieval 的障礙，反而應該成為搜尋的一部分。

因此結構化、半結構化和非結構化資料的差異，真正影響的是「怎麼 Index、Filter、Query、Retrieve」，而不是簡單決定「這個能不能叫 RAG」。

另一個維度是問題本身需要走幾步

資料怎麼被組織是一個維度，但一個問題要取得多少證據才能回答，又是另一個維度。有些問題是 Single-hop，例如「這雙鞋的清潔方式是什麼？」只要找到對應的商品說明就可以回答。

但如果使用者問：「我買的這雙限量聯名鞋已經穿過一次，如果鞋底出現製造瑕疵，還能退嗎？」這個答案可能需要先確認商品屬於哪種特殊品類，再找到聯名商品規範、已使用商品限制，以及瑕疵品是否存在例外條款。資訊可能分散在不同 Section、文件，甚至不同 Knowledge Source。這時候 Retrieval 就從：

Query → Retrieve → Answer

進一步變成：

Query → 找到第一個證據 → 根據結果決定下一個 Retrieval → 組合多個 Evidence → Answer

也就是 Multi-hop Retrieval。

所以這裡可以把幾個層次拆得更清楚：

Source 決定去哪裡找；Data Structure 決定怎麼找；Question Complexity 決定找幾步。

這三個維度不要混在一起，後面的 Retrieval Design 會清楚很多。

Retrieval Strategy 才是在這之後決定

到了這一步，才真正需要看 Query 特性。

• 像「Air Zoom Pegasus 43」這種明確型號，Lexical / Exact Match 很重要；
• 「適合扁平足、每週跑三次的鞋」則更依賴 Semantic Signal；
• 品牌、尺寸、商品分類等條件又很適合 Metadata Filter。

所以實務上的 Retrieval 很容易從單純 Vector Search 演進成：

Lexical + Metadata + Semantic Retrieval

也就是常見的 Hybrid Retrieval。

第一次 Retrieval 往往希望不要漏掉可能相關的內容，但真正送進 LLM 的 Context 又需要足夠精準，因此後面才會逐漸出現 Filtering、Reranking 等能力，把 Candidate 收斂成值得送給模型的 Context。

今天預計先整理這些能力為什麼出現就夠了。
更細的 Chunking、Embedding、Hybrid Search、Reranking 的常用手法細節，後面有機會再展開。

最後還有一個限制：Context Budget

Retrieval 並不是找到越多越好。

一次帶進 2,000 Tokens 和 20,000 Tokens，對成本、Latency 與 Capacity 的影響完全不同；過多不相關資訊，也可能讓真正重要的證據被 Noise 淹沒。

這裡就重新接回 Day 3 的 Sizing：Retrieval 本身也在放大 AI Workload，因此 Context Selection 不只是 Quality 問題，同時也是成本與容量問題。

Retrieval 的目標不是最大化資料量，而是在有限 Context Budget 裡，取得足以完成任務的資訊。

到了 Agent，Retrieval 從固定 Pipeline 變成 Dynamic Capability

Day 1 提過，一般 Workflow 的 Execution Path 通常由系統預先定義，而 Agent 的差異在於執行路徑開始變得 Dynamic。

這件事放到 Retrieval 裡也是一樣。一般 RAG 通常是固定的：

Query → Retrieve → Context → Generate

但當使用者只說「我的鞋子有問題，幫我看看怎麼處理比較好」，Agent 可能先查退換貨政策，接著發現需要訂單 State，因此改去呼叫 Order API；如果資訊仍然不足，再詢問使用者，甚至把一個複雜問題拆成多個 Retrieval Query。

此時 Retrieval 已經不只是 Pipeline 裡固定的一個 Step，而是 Agent 可以根據目前 State 動態選擇的能力。

所以 Agentic Retrieval 的差異不是「多跑幾次 RAG」，而是 Retrieval 本身開始進入 Dynamic Execution Path。

Memory 會成為 Agent 的另一種 Context Source

到了 Agent 場景，除了企業 Knowledge 和 Business State，還會多出另一種重要的 Context Source：過去的互動與經驗。

例如使用者曾經提過自己習慣穿寬楦鞋、上一次退貨流程做到哪裡，或某個任務先前已經查過哪些資訊。這些內容有些只需要在目前 Session 內保留，有些則可能需要跨 Session 保存。

這就是 Memory 開始出現的原因。
Memory 本身不等於 RAG。它除了「取回」之外，還包含哪些資訊值得保存、如何摘要或整理、保存多久，以及什麼時候更新或忘記。

但如果只看 Long-term Memory 的 Read Path，它和 Retrieval 的模式確實非常接近：
Current Task → Retrieve Relevant Memory → Add to Current Context → Agent

因此更精準的理解是：
Memory 是另一種 Context Source，而 Retrieval 是 Agent 在需要時重新取得 Memory 的方法之一。

• Short-term Memory 甚至可能完全不需要 Retrieval，可以直接存在目前的 Working State。
• Long-term Memory 則更常需要先保存重要資訊，再在未來任務中取回相關部分。

所以如果把 Context Source 放在一起看，Agent 實際上可能同時使用：

• External Knowledge
• Structured Data
• Business State
• Current Working State
• Long-term Memory

差別只是這些 Context 從哪裡來，以及用什麼方式取得。

從 Baseline 往下看，Knowledge Architecture 就清楚很多

延續前面的邏輯，再解決模型之是的問題，本質上建立的是一條 Context Acquisition 的判斷順序：

Knowledge Requirement
→ Source of Truth
→ Access Pattern
→ Data Structure / Query Complexity
→ Retrieval Strategy
→ Context Selection
→ Context Budget

Source of Truth 先決定去哪裡取得資訊，資料型態決定怎麼更有效率地 Index、Filter 或 Query，問題複雜度則決定一次 Retrieval 是否足夠。到了 Agent 場景，這些能力不會消失，而是從固定 Pipeline 的一部分，進一步成為 Agent 可以動態選擇的 Context Acquisition 能力；Memory 則再多提供一種可以被保存與重新取回的 Context Source。

所以今天整理真正想留下的不是某一套標準 RAG Architecture，而是一個比較基本的判斷方式：

先確認模型現在缺什麼資訊，再找到 Source of Truth；接著決定要 Search、Query 還是呼叫 Tool，最後才依資料結構與問題複雜度設計 Retrieval。

這些問題先回答對，後面的 Chunking、Embedding、Hybrid Search、Reranking，才是在優化正確的 Pipeline。

AI 你怎麼看?

(os: 今天居然是小企鵝嗎XD)