Advanced Workflows: Webhooks, MCPs, Claude, GPTs, RAG & Chunking Strategies（下）

[sky]

本文由人工智慧撰寫，工人智慧編輯。

▌Cache-Augmented Generation (CAG)

83. Cache-Augmented Generation (CAG) instand of RAG

當 Context Window 越來越大，Prompt Caching 越來越便宜，讓大家覺得：

• 是不是不需要 RAG 了？

• 直接把整本書丟給 AI 就好？

講師點出了實務上最大的痛點：資料留存時間 (TTL)。

RAG 是「長期記憶資料庫」，而 CAG 像是「短期記憶工作區」。

1. CAG (Cache-Augmented Generation)？

• 定義：CAG 是指利用 LLM 的 Context Caching（上下文快取）功能，將大量資料直接預先載入到模型的 Context Window 中，而非像 RAG 那樣存入向量資料庫。

• 運作差異：

  • 傳統 RAG：提問 \rightarrow 搜尋向量資料庫 (Vector DB) \rightarrow 檢索片段 \rightarrow LLM 回答。
  • CAG：提問 \rightarrow 直接搜尋 LLM 已快取的 Context Window (Cache) \rightarrow LLM 回答。

• 實作方式：在 Flowise 中，可以連接 Cache 節點（如 Google Gemini Context Cache, In-memory Cache, Redis 等）來實現。

2. CAG 的優勢

• 速度快 (Low Latency)：因為省去了外部檢索的步驟，CAG 的反應速度更快。

• 架構簡單 (Simplified Design)：不需要建立複雜的 RAG Pipeline（如切分 Chunk、Embedding、向量儲存），只需將整份文件丟入 Context Window 即可。

• 相關性 (Relevance)：通常能找到相關的答案。

3. CAG 的致命缺點

講師強調 CAG 目前不適合用於需要長期記憶的生產環境，原因如下：

• 快取生命週期短 (Time/Persistence)：這是最大的問題。快取會隨時間被刪除。

  • Claude Models：快取僅保留約 5-10 分鐘。
  • Google Models：可保留 1-2 天，但需額外付費。
  • In-Memory Cache：應用程式重啟後即消失。
  • 你無法構建一個應用程式，其知識庫只能維持幾分鐘或幾天。

• 準確度問題 (Accuracy)：

  • 雖然有 “Needle in a Haystack” (大海撈針) 測試聲稱 100% 準確，但在實際應用中，當上下文極長（如數百萬 Token）時，模型的表現會下降，準確度其實不如精心設計的 RAG。
  • RAG 在精確檢索特定資訊上仍然比 CAG 可靠。

4. 成本與模型支援

• Context Window 趨勢：現代模型支援極大的 Context，如 GPT-4 (1M)、Gemini 1.5 Pro (1M~10M)、Llama (10M)。

• 快取成本 (Prompt Caching)：

  • 如果不使用快取，每次發送百萬 Token 會非常昂貴。
  • 使用快取後，Input Token 成本可大幅降低：
    • Anthropic (Claude)：成本降低約 90%。
    • OpenAI：成本降低約 50%~75%，但基礎費率仍偏貴。
    • Google (Gemini)：相對便宜，且支援極大窗口。

5. 總結與建議

• CAG 適用情境：

  • 一次性分析：例如在 ChatGPT 或 Claude 介面上傳一個 PDF，進行對話或摘要。這類任務使用 Prompt Caching 非常合適。
  • 快速測試／好玩：想要快速從文件中提取數據，而不想建立資料庫時。

• CAG 不適合情境：

  • 生產級應用 (Production Apps)：需要永久儲存知識的應用程式。因為快取會過期，知識會丟失。

• 最終結論：

  • CAG 概念很酷，但不需要花太多時間鑽研。
  • 若要建立可靠的應用，RAG 仍然是主流且更準確的選擇。

---

▌Microsoft GraphRAG 與知識圖譜

84. GraphRAG from Microsoft: More Accurate RAG Results with Knowledge Graphs

本節課介紹 GraphRAG (Graph Retrieval-Augmented Generation) 的概念，探討它如何透過知識圖譜（如 Neo4j ）來解決傳統 RAG 的限制，但同時也指出它目前在成本與實作上的巨大挑戰，並給出一個簡單的替代方案。

1. GraphRAG

• 概念：GraphRAG 利用「知識圖譜 (Knowledge Graphs)」技術，將向量資料庫中的數據點連接起來，讓 RAG 應用程式更準確。

• 實作工具：在 Flowise 中，可以使用 Graph Cypher QA Chain 或 Neo4j Chain 來連接 Neo4j 資料庫與 LLM 進行實作。

• 核心差異：

  • 傳統 RAG：LLM 搜尋向量資料庫，回傳 Top-K (例如 4 個) 片段 (Chunks)。缺點是這些片段之間彼此沒有關聯 (Relation)，LLM 不知道 Chunk A 和 Chunk B 的關係。

  • GraphRAG：建立結構化的連接，將不同的實體 (Entities) 串聯起來，提供更整體的上下文。

2. 運作原理：洋甘菊 (Chamomile) 範例

講師以洋甘菊書籍的例子，來解釋 GraphRAG 的優勢：

• 情境：如果整本書都是關於洋甘菊，包含它的成分、用途、品種等。

• GraphRAG 的做法：它會提取「實體 (Entities)」並建立「關係 (Relationships)」。

  • 洋甘菊 ➔ 含有 (Contains) ➔ 紅沒藥醇 (Bisabolol)。

  • 洋甘菊 ➔ 用於 (Used for) ➔ 舒緩 (Soothing)。

  • 洋甘菊 ➔ 類似 (Similar to) ➔ 羅馬洋甘菊。

• 優勢：當你問一個複雜問題時，傳統 RAG 可能因為 Context Window 滿了，只回傳關於「醫療用途」的 4 個片段，而漏掉了其他面向。GraphRAG 則能透過關係鏈接，回傳具有關聯性的整體資訊。

3. GraphRAG 的致命缺點

儘管概念強大，講師目前不推薦在一般生產環境中優先使用，原因有二：

1. 成本極高：建立圖譜索引（訓練過程）非常昂貴。若資料量大，單次訓練可能花費 $10 到 $50 美元甚至更多，對於頻繁更新的知識庫來說成本太高。

2. 設定複雜：Neo4j 的設定與維護相對困難。

4. 窮人的 GraphRAG：簡單替代方案

如果不想花大錢建圖譜，又想提升 RAG 的涵蓋率與準確度，講師建議使用以下「快速修正法」：

• 增加 Top-K (Increase Top-K)：將檢索的片段數從預設的 4 提高到 8 或 20。這樣可以倍增獲得相關資訊的機率。

• 增加 Chunk Size：使用更大的切分單位，讓每個片段包含更多上下文。

• 結論：對於大多數應用來說，單純調高 Top-K 和 Chunk Size，就能達到類似的效果，且成本遠低於 GraphRAG。

5. 總結與建議

• GraphRAG 是透過理解「實體間的關係」來讓回答更精確、更具解釋性。

• 但由於目前 Training Cost (訓練成本) 太高且架構複雜，現階段不建議作為首選。

• 最佳實務：先嘗試調高 Top-K (例如設為 8~20) 和 Chunk Size，這通常是最具性價比的優化方式。

下一節課將介紹另一個類似但更便宜的概念。

---

▌LightRAG (輕量化 GraphRAG)

85. LightRAG: Fast & Cost‑Effective Alternative to GraphRAG

這一節介紹 LightRAG，一個 GraphRAG 成本過高問題的替代方案。

雖然 LightRAG 在數據上表現不錯，但講師對其實用性相對保留，並認為下一節課的概念（ 情境化檢索 Contextual Retrieval）才是真正的重點。

1. LightRAG

• 定位：它是 GraphRAG 的輕量化、低成本替代品。

• 架構：運作原理與 GraphRAG 非常相似（也是透過配對詞彙／實體來建立關聯），但架構設計上更高效。

• 核心優勢 (相比 GraphRAG)：

  • 成本更低：API 呼叫費用與訓練成本都大幅降低。

  • 適應性更快：對於新數據的變更適應速度更快，這對於需要頻繁更新資料的應用程式很關鍵。

2. 效能比較

講師分析了 LightRAG 的研究報告數據：

• LightRAG vs. Naive RAG (傳統 RAG)：

  • 勝率：LightRAG 勝率約 67%，傳統 RAG 勝率約 32%。

  • 解讀：雖然 LightRAG 贏面較大，但這也意味著在 1/3 的情況下，最簡單的傳統 RAG 表現反而更好。講師認為這顯示傳統 RAG 其實已經夠強了，LightRAG 並沒有帶來「天翻地覆」的改變。

• LightRAG vs. GraphRAG：

  • 勝率：兩者互有勝負，大致呈現 50/50 的拉鋸戰。在某些指標（如多樣性）LightRAG 稍好，但在整體綜合表現上 GraphRAG 可能仍略勝一籌。

3. 實作現況

• 僅限 Python：目前 LightRAG 主要透過 GitHub Repo 以 Python 安裝使用，尚未整合進 Flowise 或 n8n 等 No-Code 工具中。

• 體驗心得：講師親自測試後表示，相比於正常的 RAG 應用，並沒有感受到巨大的升級感。

４. 總結與建議

• 結論：LightRAG 是一個不錯的概念，解決了 GraphRAG 太貴的問題，但不需要特別花時間去鑽研它。

• 理由：它的提升幅度不足以證明值得花心力去架設（特別是如果你還不會寫 Code）。

• 預告：講師認為下一節課要介紹的概念，才是目前讓 RAG 應用程式變得可靠的「黃金標準 (Gold Standard)」。

---

▌Contextual Retrieval (情境化檢索)

86. [POWERFUL] Contextual Retrieva: Improving RAG via Anthropic’s Chunking Strategy

情境化檢索 (Contextual Retrieval) 是 Anthropic 提出的一種進階 RAG 策略，目的在解決傳統切塊（Chunking）導致的「上下文丟失」問題。

1. 為什麼需要 Contextual Retrieval？

• 傳統 RAG 的痛點：
  在標準 RAG 中，文檔被切分成獨立的區塊（Chunks）。如果一個區塊的內容是「公司營收比上一季增長了 3%」，但該區塊內沒有提到「哪家公司」或「哪一季」，這個區塊就失去了檢索價值。

  • 後果：當使用者問「ACME 公司 2023 Q2 的表現如何？」時，標準 RAG 找不到上述那個缺乏關鍵字的區塊，導致回答錯誤。

• Contextual Retrieval 的解決方案：
  在對區塊進行 Embedding 之前，先用 LLM 為每一個區塊生成一段簡短的「解釋性上下文」（Context），並將其加到原始區塊前。

  • 優化後的區塊範例：「這份區塊來自 ACME 公司 2023 Q2 的財報… 本季營收增長 3%」。

• 成效數據：根據 Anthropic 的研究，此方法可將檢索失敗率降低 49%（從 5.7% 降至 2.9%）。

2. n8n 實作分析

這是一個高度自動化的 ETL (Extract, Transform, Load) 流程，用於處理文件並建立增強型向量資料庫。

Step 1: 觸發與文件處理

• Trigger: 使用 Google Drive Trigger 監聽特定資料夾（如 Tesla Earnings），當有新文件上傳時觸發。
• Loop: 使用 Loop (Split In Batches) 節點，確保可以一次處理多個上傳的文件。
• 格式判斷: 透過 Switch 節點區分 PDF 或純文字檔。如果是 PDF，則先轉為 JSON 格式以利處理。

Step 2: 特殊切塊策略 (Chunking Strategy)

• 自定義切塊 (Code Node)：

  • 工作流中使用了一個 Code 節點（命名為 “Text Splitter”）來執行切塊，而非直接使用標準節點。
  • 邏輯：優先嘗試在「段落 “\n\n”」切分，其次是「句子 ". "」，最後才是強制切分，以保持語意完整性。

• 參數設定：

  • Chunk Size (區塊大小)：設定為 2000 Tokens（較大，為了包含完整表格或段落）。
  • Overlap (重疊)：設定極低，僅 20 甚至可以是 0。因為 Contextual Retrieval 會主動補足上下文，因此不再需要依賴傳統的 Overlap 來維持語意連貫。

Step 3: 生成上下文 (The Contextual Loop)

這是本流程的核心，對切分出來的每一個 Chunk 進行處理：

• Prompt 設計 (System Prompt)：
  在 Basic LLM Chain 節點中，Prompt 結構如下：

  1. 輸入：整份文檔 (<document>) + 當前區塊 (<chunk>)。
  2. 指令：請給這個區塊一段簡短的背景描述（Context），使其在整份文檔中定位清楚。
  3. 特殊要求：如果區塊包含表格，必須包含完整的表格數據以維持數據完整性 (Data Integrity)。

• 輸出格式：[succinct context] : [original chunk]。

Step 4: 儲存與嵌入

• 組合數據：將 LLM 生成的 Context 與原始 Chunk 合併。
• Vector Store: 使用 Pinecone 儲存向量數據，Namespace 設定為 Info。

3. 模型選擇

Cost & Speed Optimization

由於此策略 （情境化檢索）需要對每個區塊都調用一次 LLM 並輸入整份文檔，Token 消耗量極大，因此選什麼模型很重要。推薦模型：

1. Groq Cloud (Llama 模型)：利用 LPU 硬體加速，推理速度極快，適合大量批次處理。

2. Google Gemini 2.0 Flash (Experimental Free)：透過 OpenRouter 使用。

• 優點：目前免費、速度快、擁有 100 萬 Context Window，非常適合讀取整份長文檔。
• 注意：不要使用 Thinking Models (如 o1 或推理模型)，因為它們速度慢且會產生大量額外的推理 Token，對於這種單純的總結任務來說是浪費。

4. 實測

使用 Tesla 2024 Q3 財報實測結果如下：

• 測試場景：上傳一份格式混亂、包含跨頁表格的 Tesla 財報。

• 查詢：「2024 Q3 的現金與投資總額是多少？」(What was cash, cash equivalents… in Q3 2024?)。

• 結果：

  • 標準 RAG 可能會因為表格被切斷而抓取到錯誤數字。
  • Contextual Retrieval 成功抓取到包含完整表格數據的區塊，準確回答 33.6 Billion。
  • 這證明了即使是非結構化的 PDF，透過生成上下文並強制保留表格完整性，也能達到極高的檢索準確度。

5. 總結與建議

• 何時使用：當您的資料包含大量財務報表、法律合約或技術手冊，且標準 RAG 經常發生「抓不到重點」或「數據錯置」的情況時。

• 實作重點：

  • 使用 Custom Code 或邏輯確保切塊時盡量不切斷段落。
  • 務必使用 Fast & Free/Cheap 的模型（如 Gemini Flash, Groq）來生成 Context，否則成本會失控。
  • Prompt 中加入「保留表格完整性」的指令是處理財務數據的關鍵。

---

▌如何選擇正確的 RAG

87. Choosing the Right Strategy: GraphRAG, LightRAG, CAG, or Contextual Retrieval?

這節課是關於 RAG 選擇策略的總結指南，講師分析了在不同場景下應該使用哪種技術（Standard RAG, Contextual Retrieval, CAG, GraphRAG/LightRAG），以及如何優化現有的系統。

1. Standard RAG (標準 RAG)

99% 的首選。這是最基礎也最穩健的策略，將資料切塊後存入向量資料庫。

• 適用場景：絕大多數情況 (99%)，特別是有動態知識庫 (Dynamic Knowledge) 或 超大型資料集 (Very Large Datasets) 時。

• 核心優勢：

  • 管理靈活：可以輕鬆地新增、刪除或更新資料塊（Chunks）與 Metadata。
  • 維護容易：對於需要頻繁更新資料的應用程式來說，這是最標準且有效的解法。

2. Contextual Retrieval (情境化檢索) - 提升準確度

當標準 RAG 的準確度不足以滿足需求時，這是第一個建議採用的進階方案。

• 適用場景：標準 RAG 準確度不夠。

• 優點：顯著提升檢索的準確性。

• 缺點：

  • 設定繁瑣：需要建立額外的工作流來生成 Context。
  • 耗時：Embedding 過程較慢，且目前某些平台（如 n8n, Flowise）的原生節點可能還不夠穩定。

33. CAG (Cache Augmented Generation)

快取增強生成，速度快，適合短期任務（5分鐘）。

利用模型的 Prompt Caching 功能，將資料直接塞入 Context Window。

• 適用場景：

  • 資料量較小 (Smaller datasets)。
  • 需要極快的回應速度 (Fast response times)。
  • 不想建立完整的 RAG 系統，只想快速上傳一堆文件問問題。

• 實作建議：

  • 推薦使用標準介面（如 ChatGPT, Claude 網頁版），不推薦使用 API。
  • 原因：Cache 會在短時間內（5分鐘、10分鐘或幾天）自動過期刪除。若透過 API 頻繁重建 Cache，成本高且管理麻煩。

4. GraphRAG & LightRAG

實驗性質選項，基於知識圖譜的檢索技術，目前仍偏向實驗性質。

• 定位：可供實驗，但尚未成為主流。

• 缺點：昂貴、速度較慢、設定困難。

• 建議：如果非要嘗試，建議優先選擇 LightRAG。

  • 相比 GraphRAG，LightRAG 更便宜、更快，且穩定性與效果相當。

5. RAG 優化技巧

在決定更換架構之前，講師強烈建議先調整「標準 RAG」的參數，這通常能以最小的代價獲得顯著的改善。

A. 增加回傳區塊數量 (Top K)

• 標準設定：通常為 4。

• 優化建議：嘗試增加到 8 甚至 20。

• 效果：Anthropic 的研究指出 Top K = 20 有時能創造奇蹟，大幅提升可靠性。

• 代價：應用程式會變慢且變貴（因為輸入的 Context Token 變多了）。

B. 調整區塊大小 (Chunk Size)

• 標準設定：通常在 400 到 2000 Tokens 之間。

• 優化建議 (針對純文字)：嘗試增大到 4000 - 6000 Tokens。

  • 原理：現代模型（如 Gemini 1.5, Claude 3）對長文本的處理能力極強。給予更多上下文（例如 Top K 10 × Chunk 5000 = 50,000 Tokens）通常效果更好。

• 例外情況 (針對數據／清單)：

  • 如果是數字密集或清單型資料（如人名列表），較小的 Chunk Size 反而比較精準，這時不應盲目加大。

6. 決策流程總結

講師提出的最終決策路徑如下：

1. Level 1: 先使用 Standard RAG（最快、最便宜、最簡單）。
2. Level 2: 準確度不夠？先增加 Top K 和 加大 Chunk Size（如果你是處理文本資料）。
3. Level 3: 還不夠？實作 Contextual Retrieval。
4. Level 4: 仍不滿意？嘗試疊加 LightRAG。
5. 最後手段 (The Final Option)：如果以上都失敗，且文件極其複雜，建議暫時放棄。等待 1-2 個月後的下一代模型（Next LLM），通常新模型的原生能力就能解決舊模型需要複雜 RAG 才能處理的問題。

---

▌課程總結

88. Recap: Special Workflows, Advanced Strategies & MCPs (Model Context Protocol)

特殊工作流、進階策略與模型上下文協議，這節課是對本堂（Advanced Workflows: Webhooks, MCPs, Claude, GPTs, RAG & Chunking Strategies）課程的快速回顧與重點總結。

1. MCP

Model Context Protocol：模型上下文協議。

• 定義：MCP 就像是 LLM 的 USB-C 接口。它類似於 Function Calling（函數調用），但更加標準化、強大且易於連接。
• 功能：允許 LLM 無縫連接各種外部 API 和工具，並且能自動列出 API 可執行的所有功能。
• 實作回顧：
  • Claude Desktop：透過修改設定檔（Developer Mode），將本地的 MCP Server 連接至 Claude 桌面版。
  • n8n：在 n8n 中建立 Client 和 Server 端，打造自己的 MCP 應用，這比單純的 AI Agent 更穩定且成本更低。

2. ChatGPT Actions & Webhooks

• 連接萬物：透過 Webhooks 將任何 API 連接到 ChatGPT。
• GPT Actions：利用 ChatGPT 編寫代碼並實作於 GPT Actions 中，讓 ChatGPT 變身為能執行外部動作的 AI Agent（類似 Claude 的 Agent 功能）。

3. 串接 Flowise 與 n8n

• 雙向溝通：

  • Flowise → n8n：使用 HTTP Request 節點，將 Flowise 的處理結果發送給 n8n 觸發後續流程。
  • n8n → Flowise：在 n8n 中透過 Curl 指令或 HTTP Request 調用 Flowise 的 API 接口。

• 價值：這種靈活的串接方式可以節省大量時間，讓不同工具發揮各自強項。

4. Prompt Caching (提示詞快取)

• 適用場景：

  • 短期、快速的資訊提取任務（因為 Cache 會自動過期）。
  • 重複發送相同 Prompt 的 API 調用。

• 自動化：OpenAI 和 OpenRouter 的 API 通常會自動處理 Caching，幫助開發者節省 Token 費用並加快回應速度。

5. 進階 RAG 策略

• GraphRAG & LightRAG：

  • 原理：利用知識圖譜（Knowledge Graph）連接向量資料庫中的不同實體（Entities），即使區塊（Chunks）之間在文本上不連續，也能透過概念關聯被檢索到。
  • 評價：雖然概念很酷，但目前成本較高且速度較慢，設定也較繁瑣。

• Contextual Retrieval (情境化檢索)：

  • 原理：Anthropic 提出的策略，為每個切塊補充上下文（Context）。
  • 評價：這是講師認為最實用且強大的概念，能將檢索失敗率降低近一半，顯著提升 RAG 的準確度。

6. 學習的本質

• 定義：真正的學習是「在相同的情況下，展現出不同的行為」（Same circumstances but different behavior）。

• 行動呼籲：

  • 如果您以前從未寫過 Webhook、沒架設過 MCP Server 或沒試過 Contextual Retrieval，現在應該去實際動手做。
  • 當別人談論 MCP 或 RAG 優化時，您現在應該具備參與討論並實作的能力。