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

**URL:** https://vip.studycamp.tw/t/advanced-workflows-webhooks-mcps-claude-gpts-rag-chunking-strategies%EF%BC%88%E4%B8%8B%EF%BC%89/8612
**Category:** 自然語言處理
**Tags:** 上課筆記
**Created:** [2026年一月28日 08:27 UTC](https://vip.studycamp.tw/t/advanced-workflows-webhooks-mcps-claude-gpts-rag-chunking-strategies%EF%BC%88%E4%B8%8B%EF%BC%89/8612 "2026-01-28T08:27:28Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![sky](https://vip.studycamp.tw/user_avatar/vip.studycamp.tw/sky/32/8098_2.png) [@sky](https://vip.studycamp.tw/u/sky)
#### Post date: [2026年一月28日 08:27 UTC](https://vip.studycamp.tw/t/advanced-workflows-webhooks-mcps-claude-gpts-rag-chunking-strategies%EF%BC%88%E4%B8%8B%EF%BC%89/8612/1 "2026-01-28T08:27:28Z")

</div>

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

## ▌Cache-Augmented Generation (CAG)

> 1. 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 那樣存入向量資料庫。

- 運作差異：

- 實作方式：在 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)：這是最大的問題。快取會隨時間被刪除。

- 準確度問題 (Accuracy)：

### 4. 成本與模型支援

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

- 快取成本 (Prompt Caching)：

### 5. 總結與建議

- CAG 適用情境：

- CAG 不適合情境：

- 最終結論：

* * *

## ▌Microsoft GraphRAG 與知識圖譜

> 1. 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 進行實作。

- 核心差異：

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

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

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

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

- 優勢：當你問一個複雜問題時，傳統 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)

> 1. LightRAG: Fast & Cost‑Effective Alternative to GraphRAG

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

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

### 1. LightRAG

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

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

- 核心優勢 (相比 GraphRAG)：

### 2. 效能比較

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

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

- LightRAG vs. GraphRAG：

### 3. 實作現況

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

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

### ４. 總結與建議

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

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

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

* * *

## ▌Contextual Retrieval (情境化檢索)

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

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

### 1. 為什麼需要 Contextual Retrieval？

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

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

- 成效數據：根據 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)：

- 參數設定：

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

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

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

- 輸出格式：`[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?)。

- 結果：

### 5. 總結與建議

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

- 實作重點：

* * *

## ▌如何選擇正確的 RAG

> 1. 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) 時。

- 核心優勢：

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

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

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

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

- 缺點：

### 33. CAG (Cache Augmented Generation)

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

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

- 適用場景：

- 實作建議：

### 4. GraphRAG & LightRAG

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

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

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

- 建議：如果非要嘗試，建議優先選擇 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。

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

### 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 才能處理的問題。

* * *

## ▌課程總結

> 1. 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

- 雙向溝通：

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

### 4. Prompt Caching (提示詞快取)

- 適用場景：

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

### 5. 進階 RAG 策略

- GraphRAG & LightRAG：

- Contextual Retrieval (情境化檢索)：

### 6. 學習的本質

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

- 行動呼籲：