reset: 每日清空用戶測試檔 RAG 課程知識庫
This commit is contained in:
@@ -1,385 +0,0 @@
|
||||
---
|
||||
title: RAG 課程知識庫
|
||||
|
||||
---
|
||||
|
||||
# RAG 課程知識庫
|
||||
# 來源：虎智科技（TIGER AI）基本 RAG 教學投影片
|
||||
# 共 16 頁，以下依頁碼整理
|
||||
|
||||
---
|
||||
|
||||
## 第 1 頁：小 G 的秘密，大 L
|
||||
|
||||
本課程的核心比喻是「小 G」與「大 L」的關係。
|
||||
|
||||
- **小 G（LLM）**：代表大型語言模型（Large Language Model），例如 GPT、Gemini、Claude 等。小 G 擁有強大的語言理解與生成能力，可以進行對話、摘要、推理，但他本身的知識有截止日期，也不知道你公司內部的事情。
|
||||
- **大 L（世界級大知識庫）**：代表 LLM 訓練時所吸收的龐大世界級知識，例如維基百科、網路文章、學術論文等。這是 LLM 在訓練階段就學到的知識，儲存在模型的參數裡。
|
||||
|
||||
小 G 和大 L 之間的雙向箭頭，表示 LLM 是從世界級知識庫訓練而來的，也可以透過知識庫來強化回答能力。
|
||||
|
||||
---
|
||||
|
||||
## 第 2 頁：家用小 G，加上我家小 L
|
||||
|
||||
在企業應用中，光靠世界級知識庫（大 L）是不夠的。企業需要讓 LLM 也能掌握公司內部的知識，因此引入了「小 L（本公司小知識庫）」。
|
||||
|
||||
- **小 G（LLM）**：語言模型，負責理解問題、產生回應。
|
||||
- **大 L（世界級大知識庫）**：LLM 訓練時的龐大知識背景。
|
||||
- **小 L（本公司小知識庫）**：企業自己建立的私有知識庫，包含內部文件、SOP、產品說明書、會議紀錄等，是 LLM 原本不知道的資訊。
|
||||
|
||||
RAG（Retrieval-Augmented Generation，檢索增強生成）的核心概念就是：讓小 G 在回答問題時，可以先去查詢「小 L（本公司小知識庫）」，然後再結合自身的語言能力生成精確的答案。
|
||||
|
||||
---
|
||||
|
||||
## 第 3 頁：最簡單提供內部資料給 AI 的方法
|
||||
|
||||
這一頁展示了用 n8n 工作流程工具快速建立一個 RAG 問答機器人的實際範例。
|
||||
|
||||
**架構說明：**
|
||||
- 使用者透過問答工具（例如聊天介面）輸入問題。
|
||||
- n8n 工作流程中有一個「RAG 機器人」節點，接收問題後：
|
||||
- 連接 **Chat Model**（語言模型，這裡使用 Google Gemini Chat Model）來理解問題。
|
||||
- 連接 **Memory**（記憶）來保留對話歷史。
|
||||
- 連接 **Tool**（工具）來查詢知識庫，這裡使用 `get_ppt_tool`，可以讀取 PowerPoint 簡報內容。
|
||||
|
||||
**實際展示效果：**
|
||||
右側手機截圖顯示一個聊天介面（類似官網客服機器人），使用者問「簡單介紹虎智科技」，AI 助教「Leo」就能根據內部資料，精確回答公司介紹，包含講師背景、服務項目、曾獲獎項等詳細資訊。
|
||||
|
||||
這個範例說明：只要把公司資料（例如一份 PPT）接進去，AI 就能成為一個懂公司的客服機器人，完全不需要重新訓練模型。
|
||||
|
||||
這是最簡單的 RAG，你提供一份文件，AI 就可以去讀。如果你的文件這麼少，就沒有 RAG 的必要了，但是企業文件不可能這麼少，要怎麼從大量知識中找到正確的文件呢？所以就發明了 RAG。
|
||||
|
||||
---
|
||||
|
||||
## 第 4 頁：把文件存入 RAG 知識庫
|
||||
|
||||
這一頁說明 RAG 知識庫的「寫入流程」（Indexing Pipeline），也就是把企業文件存入知識庫的步驟。
|
||||
|
||||
**n8n 工作流程說明（由左至右）：**
|
||||
|
||||
1. **上傳知識文件**：觸發點，使用者上傳一份文字文件（例如 Word、TXT、PDF）。
|
||||
2. **取出文件內容（Extract From Text File）**：將文件解析，提取出純文字內容。
|
||||
3. **向量儲存庫（Vector Store）**：將文字內容存入向量資料庫，這個節點需要兩個子模組：
|
||||
- **Embeddings（向量模型）**：使用 Google Gemini Embeddings 將文字轉換成向量數字。
|
||||
- **Document（文件載入器）**：使用 Default Data Loader 格式化文件結構，再存入向量資料庫。
|
||||
|
||||
**核心概念：**
|
||||
文件不是直接以原文儲存，而是先透過 Embedding 模型轉換成高維度的數字向量，然後存入向量資料庫（Vector Database）。這樣之後查詢時，系統才能用語意相似度來找到最相關的片段，而不只是用關鍵字比對。
|
||||
|
||||
既然都有了全文搜尋，幹嘛還需要 Embedding 呢？那是因為，如果只有全文搜索，你就只能找到相同字詞，例如「捷運」如果打成「地鐵」就搜不到了，打成「列車」也搜不到，因為字不同。
|
||||
|
||||
Embedding 後就擁有「語義」搜尋的能力，捷運、地鐵、列車的「意思」類似，都可以搜到。這種方式讓你用模糊的記憶也能找到正確內容。
|
||||
|
||||
---
|
||||
|
||||
## 第 5 頁：取出 RAG 知識庫的資料
|
||||
|
||||
這一頁說明 RAG 知識庫的「查詢流程」（Retrieval Pipeline），也就是使用者提問時，系統如何從知識庫找到答案。
|
||||
|
||||
**n8n 工作流程說明：**
|
||||
|
||||
1. **有聊天就啟動**：當使用者傳入訊息時，工作流程開始執行。
|
||||
2. **回覆機器人**：核心 AI 節點，整合以下三個部分：
|
||||
- **Chat Model**：使用 Google Gemini Chat Model（設定了 2 個模型選項），負責理解問題並生成最終回答。
|
||||
- **Memory（記憶）**：使用 `chat_memory`（設定了 2 個記憶選項），讓對話有上下文記憶。
|
||||
- **Tool（工具）**：使用 `my_km`（我的知識庫），這是連接向量資料庫的工具，負責根據問題查詢最相關的文件片段。
|
||||
3. **my_km 工具**：連接 Embedding 模型（Google Gemini Embeddings），將使用者的問題也轉換成向量，然後在向量資料庫中找到語意最相近的資料，回傳給語言模型參考。
|
||||
|
||||
**流程邏輯：**
|
||||
使用者問問題 → 問題向量化 → 向量資料庫語意搜尋 → 找到相關文件片段 → 語言模型閱讀片段後生成回答 → 回傳給使用者。
|
||||
|
||||
---
|
||||
|
||||
## 第 6 頁：AI 用上千維度管理圖書館
|
||||
|
||||
這一頁說明 Embedding（向量嵌入）的概念，以及目前主流的 Embedding 模型。
|
||||
|
||||
**什麼是 Embedding？**
|
||||
Embedding 是一種將文字轉換成高維度數字向量的技術。文件、句子、詞語都可以被表示成一串數字（例如 [0.6, 0.3, 0.1, ...]），這些數字在高維度空間中的位置，代表了這段文字的「語意意義」。語意相近的文字，在向量空間中的距離也會比較近，這就是語意搜尋的基礎。
|
||||
|
||||
它實際在做的事，是 AI 閱讀你的文字後，理解意義，就把它用數學方法描述成空間中的一個點。
|
||||
|
||||
那空間可以容納多少點呢？每個內容都轉成上千維度，每個維度用一個浮點數就是小數點來說明，小數點後10位還有正負數，所以每一個維度可以存20億個位置，有1000個以上的「格子」，用來存全世界的知識是沒問題了！
|
||||
|
||||
**流程圖說明：**
|
||||
多份 Text/Doc 文件 → 輸入 Embedding Model → 輸出各自的向量數列 → 存入向量空間資料庫（圖中以 3D 散點圖示意，不同顏色代表不同類別的文件）
|
||||
|
||||
**主流 Embedding 模型列表：**
|
||||
|
||||
| 模型名稱 | 廠商 | 維度數 | 用途 |
|
||||
|---|---|---|---|
|
||||
| text-embedding-3-small | OpenAI | 1536 維 | 文字專用 |
|
||||
| text-embedding-3-large | OpenAI | 3072 維 | 文字專用 |
|
||||
| gemini-embedding-001 | Google | 3072 維 | 文字專用 |
|
||||
| multimodalembedding | Google Vertex AI | 1408 維 | 多模態（文字+圖片） |
|
||||
|
||||
**說明：** 維度越高，代表能表達的語意細節越豐富，但計算成本也越高。多模態 Embedding 可以同時處理文字和圖片，適合需要圖文混搜的場景。
|
||||
|
||||
---
|
||||
|
||||
## 第 7 頁：如何管理知識 / 記憶
|
||||
|
||||
這一頁對比人類與 AI 管理知識的方式，說明 AI 的向量化管理機制。
|
||||
|
||||
**人類管理知識的方式：**
|
||||
- 分資料夾（按主題分類）
|
||||
- 取一個很長的檔名（用命名來描述內容）
|
||||
- 加上關鍵字（便於搜尋）
|
||||
- 打標籤（多維度分類）
|
||||
- 加上目錄（建立索引）
|
||||
- 背誦（記在腦子裡）
|
||||
|
||||
**AI 管理知識的方式：**
|
||||
AI 不使用上述人類的分類方式，而是採用數學上的「群聚演算法」（如 K-Means Clustering）。每一筆資料都被轉換成向量，然後在高維空間中，根據語意相似度自動聚集成群。查詢時，AI 找的不是「同一個資料夾」或「相同標籤」，而是「向量距離最近的資料」。
|
||||
|
||||
這意味著即使文件沒有打標籤、沒有分資料夾，只要語意相近，AI 就能找到相關資料。這也是向量資料庫比傳統關鍵字搜尋更強大的地方。
|
||||
|
||||
---
|
||||
|
||||
## 第 8 頁：基本款 Naive RAG
|
||||
|
||||
這一頁介紹最基礎的 RAG 架構，稱為 Naive RAG，並與 Multimodal RAG（多模態 RAG）做比較。
|
||||
|
||||
**Naive RAG 流程：**
|
||||
1. 使用者輸入 User Query（問題）
|
||||
2. 問題透過 Embedding 向量化
|
||||
3. 向量資料庫（Vector DB）搜尋語意最相近的文件片段
|
||||
4. 找到的片段 + 問題 → 組合成 Prompt Template（提示詞模板）
|
||||
5. LLM 根據提示詞模板生成 Output（回答）
|
||||
|
||||
**Multimodal RAG（多模態）：**
|
||||
流程與 Naive RAG 相同，但資料來源（Data Sources）除了文字文件，還包含圖片、影片、音訊等多模態資料。
|
||||
|
||||
**Naive RAG 的適用場景：**
|
||||
- 內部使用，環境單純，數據量不大
|
||||
- 幫你找到所需資料
|
||||
- 幫你總結找到的資料
|
||||
|
||||
**說明：** Naive RAG 是最入門的 RAG 方案，適合小規模企業內部使用，例如公司 SOP 查詢、產品說明書問答等。缺點是對複雜問題、模糊問題、或需要最新資訊的場景處理能力有限。
|
||||
|
||||
---
|
||||
|
||||
## 第 9 頁：如果查詢者話說不清 — HyDE
|
||||
|
||||
這一頁介紹 HyDE（Hypothetical Document Embedding，假設文件嵌入）技術，用來解決使用者問題描述不清楚的問題。
|
||||
|
||||
**HyDE 的核心思路：**
|
||||
先讓 LLM 根據使用者模糊的問題，「假設性地」生成一份可能的回答文件（Hypothetical Response），然後再用這份假設文件去向量資料庫中搜尋，而不是直接用原始問題去搜尋。
|
||||
|
||||
**HyDE 流程：**
|
||||
1. User Query → LLM 生成 Hypothetical Response（假設答案）
|
||||
2. 假設答案 → Embedding 向量化
|
||||
3. 向量資料庫搜尋
|
||||
4. 找到的片段 → Prompt Template
|
||||
5. LLM 生成最終 Output
|
||||
|
||||
**適用場景：**
|
||||
- 用戶範圍廣，組成複雜（老人家、小朋友、非專業人士等）
|
||||
- 問題說不清楚：例如說「那個、這個、怎麼辦」這種模糊敘述
|
||||
|
||||
**說明：** HyDE 的優點是能把「模糊問題」轉化為「清楚的語意向量」，大幅提升搜尋準確率。缺點是多了一次 LLM 呼叫，增加延遲與成本。
|
||||
|
||||
---
|
||||
|
||||
## 第 10 頁：如果很需要最新資訊 — Corrective RAG
|
||||
|
||||
這一頁介紹 Corrective RAG（糾正型 RAG），用來解決知識庫資料過時、或需要即時資訊的問題。
|
||||
|
||||
**Corrective RAG 流程：**
|
||||
1. User Query → Embedding 向量化
|
||||
2. 向量資料庫搜尋，找到候選文件片段
|
||||
3. **Query Analyzer（查詢分析器）** 評估找到的資料品質（Grade 評分）：
|
||||
- 如果資料夠好 → 直接使用
|
||||
- 如果資料不夠好（過時、不相關）→ 自動進行 **Search Web（網路搜尋）** 補充最新資訊
|
||||
4. 修正後的資料（Correct Info）存回向量資料庫，同時進入 Prompt Template
|
||||
5. LLM 生成最終 Output
|
||||
|
||||
**適用場景：**
|
||||
- 知識庫的資料是不是太老了？
|
||||
- 我的行業要查詢最新數據（例如股市、法規、競品動態）
|
||||
- 流行業？輿情分析？（需要即時資訊的場景）
|
||||
|
||||
**說明：** Corrective RAG 讓知識庫不再是靜態的，而是能動態補充最新資訊。適合資訊更新頻繁的產業，如金融、法律、電商、新聞媒體等。
|
||||
|
||||
---
|
||||
|
||||
## 第 11 頁：如果要它理解 — Graph RAG
|
||||
|
||||
這一頁介紹 Graph RAG 與 Hybrid RAG，讓 AI 不只是「找資料」，而是真正「理解資料之間的關係」。
|
||||
|
||||
**Graph RAG 流程：**
|
||||
1. User Query → Embedding 向量化
|
||||
2. 向量資料庫搜尋
|
||||
3. **Graph Generator（知識圖譜生成器）** 同步從資料中抽取實體與關係，建立 **Graph DB（圖資料庫）**
|
||||
4. LLM 同時參考向量搜尋結果和圖資料庫的關係結構，生成更深入的 Output
|
||||
|
||||
**Hybrid RAG（混合型）：**
|
||||
同時使用 Vector DB（語意搜尋）和 Graph DB（關係結構）兩種上下文（Context 1 + Context 2），提供更完整的資訊給 LLM。
|
||||
|
||||
**Knowledge Graph 的核心概念：**
|
||||
- 不只是索引，AI 會發現知識之間的關係，知道數據的意義
|
||||
- 建立詞與詞、段落與段落、文件與文件之間的關聯
|
||||
- **特別說明：Knowledge Graph 不是圖片索引**，是語意關係的網絡圖
|
||||
|
||||
**適用場景：**
|
||||
需要深度理解文件脈絡的場景，例如法律條文解析、醫療知識問答、企業知識管理等，這些場景中「關係」比「文字」更重要。
|
||||
|
||||
---
|
||||
|
||||
## 第 12 頁：要它做計劃再工作 — Adaptive RAG
|
||||
|
||||
這一頁介紹 Adaptive RAG（自適應型 RAG），讓 AI 先制定計劃，再按計劃執行查詢與回答。
|
||||
|
||||
**Adaptive RAG 流程：**
|
||||
1. User Query → **Query Analyzer（查詢分析器）** 分析問題複雜度
|
||||
2. 依據複雜度決定路徑：
|
||||
- **Direct（直接回答）**：簡單問題直接查 Vector DB
|
||||
- **Multi-Step + Reasoning Chain（多步驟 + 推理鏈）**：複雜問題先制定多步驟計劃，透過 Reasoning Chain 逐步推理
|
||||
3. 查詢 Vector DB 取得相關資料
|
||||
4. LLM 根據計劃與資料生成最終 Output
|
||||
|
||||
**適用場景：**
|
||||
- 需要 AI 先制定複雜計劃，再依照計劃執行
|
||||
- 例如 Claude Code 這類 Agent 工具，都會先列出 Todo 計劃，再一步一步執行
|
||||
|
||||
**說明：** Adaptive RAG 能根據問題的難易度自動調整處理策略，對簡單問題快速回答，對複雜問題進行多步驟推理。這是目前主流 AI Agent 的基本能力之一。
|
||||
|
||||
---
|
||||
|
||||
## 第 13 頁：如果要它聰明 — Agentic RAG
|
||||
|
||||
這一頁介紹最高階的 Agentic RAG，讓 AI 具備真正的自主規劃與多 Agent 協作能力。
|
||||
|
||||
**Agentic RAG 架構：**
|
||||
- **Memory（記憶）**：分為 Short Term（短期記憶，當前對話）和 Long Term（長期記憶，跨對話知識）
|
||||
- **Planning（規劃）**：支援 ReAct（推理+行動）和 CoT（Chain of Thought，思維鏈）兩種推理模式
|
||||
- **多個 Agent（代理）**：Agent 1、Agent 2、Agent 3 並行工作，各自處理不同子任務
|
||||
- **工具整合（MCP Servers）**：
|
||||
- Local Data Servers（本地資料來源）
|
||||
- Search Servers（搜尋引擎，例如 kagi）
|
||||
- Cloud Servers（雲端服務，例如 AWS、Azure）
|
||||
- **LLM**：統整所有 Agent 的結果，輸出最終答案
|
||||
|
||||
**實際案例（Claude Flow SPARC）：**
|
||||
右側截圖展示 Claude Code 執行 Agentic RAG 的真實過程：
|
||||
- `specification`：分析專案需求
|
||||
- `system-architect`：設計系統架構
|
||||
- `sparc-coord`：協調 SPARC 方法論
|
||||
- `task-orchestrator`：統籌專案執行
|
||||
- 整個流程消耗約 62.8k tokens，執行時間約 1 分 30 秒
|
||||
|
||||
**適用場景：**
|
||||
- 需要多個 AI Agent 同時工作的複雜任務
|
||||
- 需要規劃、執行、反思、修正的完整 AI 工作流程
|
||||
- 例如：軟體開發自動化、複雜研究報告生成
|
||||
|
||||
---
|
||||
|
||||
## 第 14 頁：RAG 簡單流程（總覽架構圖）
|
||||
|
||||
這一頁用一張完整的架構圖，總結 RAG 系統的全貌，分為幕前（使用者看得到的部分）和幕後（系統後台處理的部分）。
|
||||
|
||||
**幕前（Frontend）：**
|
||||
- **聊天介面**：使用者與 AI 互動的介面
|
||||
- **語言模型**：接收問題，查詢知識庫後，生成回答，回傳給使用者
|
||||
|
||||
**幕後（Backend）：**
|
||||
|
||||
*文件處理流程（一次性建立）：*
|
||||
1. **企業文件** → 輸入系統
|
||||
2. **AI 預處理**：切塊（Chunking）、清理、格式化
|
||||
3. **向量模型**：將文字片段轉換成向量
|
||||
4. **向量資料庫**：儲存向量，供語意搜尋使用
|
||||
5. **知識結構**：同步從文件中抽取實體與關係
|
||||
6. **知識圖譜資料庫**：儲存知識關係，供深度理解使用
|
||||
|
||||
*查詢流程（每次問答觸發）：*
|
||||
- 語言模型 → 呼叫向量模型將問題向量化 → 向量資料庫搜尋 → 找到相關片段 → 語言模型生成回答
|
||||
|
||||
**核心說明：** 向量資料庫和知識圖譜資料庫是 RAG 系統的兩大資料儲存核心，前者負責語意搜尋，後者負責關係推理。
|
||||
|
||||
---
|
||||
|
||||
## 第 15 頁：RAG 應用案例，輸入優化
|
||||
|
||||
這一頁展示一個完整的企業級 RAG 應用架構，包含從原始資料到最終使用者介面的完整工程流程。
|
||||
|
||||
**三大工程層次：**
|
||||
|
||||
**⓿ 知識資料集提供：**
|
||||
- 企業的產業知識資料庫（Knowledge System DB）每日批次匯出
|
||||
- 透過 n8n 工作流程將資料轉換成 Excel 格式輸出
|
||||
- 這些資料成為 AI QA 的知識內容基礎
|
||||
|
||||
**❶ ETL 資料工程（n8n 自動化）：**
|
||||
- 資料清理 ETL 自動化：去除噪音、格式統一
|
||||
- 資料標示 ETL 自動化：自動為資料加上標籤與分類
|
||||
- 工具：n8n 工作流程自動化平台
|
||||
|
||||
**❷ RAG 工程：**
|
||||
- **Fine Tune Embedding 模型**：針對特定領域對嵌入模型進行微調，提升搜尋精準度（使用 unsloth 工具）
|
||||
- **Advance RAG 切塊與向量資料**：對文件進行智慧切塊、向量編碼、存入向量資料庫（使用 drant 向量資料庫）
|
||||
- 流程：從 ETL 資料集 → 文件切塊 → Embedding 向量編碼 → 存入向量資料庫 → 提供搜尋查詢
|
||||
|
||||
**❸ UI/UX 工程：**
|
||||
- **Chat Bot 使用者介面**：使用 OpenWebUI 建立對話介面
|
||||
- **Prompt Engineering（提示詞工程）**：設計預設提示詞庫，引導使用者說明需求
|
||||
- 使用者透過 WebUI 輸入需求，AI 比對 RAG 資料後提供建議
|
||||
|
||||
**❾ LLM 服務：**
|
||||
- Base Model 基礎模型
|
||||
- Fine Tune 微調模型
|
||||
- 使用 Ollama 在本地部署運行
|
||||
|
||||
---
|
||||
|
||||
## 第 16 頁：如何處理連續輸入的數據？
|
||||
|
||||
這一頁說明如何將 Graph RAG 應用於連續串流數據的即時分析場景。
|
||||
|
||||
**連續數據源的三大類型：**
|
||||
1. **網路**：網路流量、用戶行為數據、社群媒體數據
|
||||
2. **機器**：IoT 設備感測器數據、工廠機台狀態數據
|
||||
3. **投資**：股市行情數據、交易數據、財務指標
|
||||
|
||||
**處理流程：**
|
||||
1. **連續數據源** → 持續輸入資料
|
||||
2. **Data Analytics（數據分析）**：對連續數據進行統計歸納，找出規律與趨勢
|
||||
3. **Graph RAG（模式匹配）**：使用圖譜 RAG 進行模式匹配，將數據特徵與知識庫中的歷史模式對比
|
||||
4. **行動建議（Output）**：輸出具體的行動建議
|
||||
|
||||
**典型應用問題：**
|
||||
- 「他要下單了？」（使用者行為預測）
|
||||
- 「設備快壞了？」（預測性維護，Predictive Maintenance）
|
||||
- 「可以進場了？」（投資時機判斷）
|
||||
|
||||
**說明：** 這是 RAG 最進階的應用方向之一，將知識庫不再只是靜態的文件，而是結合即時串流數據，讓 AI 能夠在動態環境中做出即時的智慧決策。適合工業 IoT、量化交易、輿情監控等領域。
|
||||
|
||||
---
|
||||
|
||||
## 附錄：核心術語對照表
|
||||
|
||||
| 術語 | 說明 |
|
||||
|---|---|
|
||||
| RAG | Retrieval-Augmented Generation，檢索增強生成。讓 LLM 在回答時能先查詢外部知識庫。 |
|
||||
| LLM | Large Language Model，大型語言模型，例如 GPT、Gemini、Claude。 |
|
||||
| Embedding | 向量嵌入。將文字轉換成高維度數字向量，用於語意搜尋。 |
|
||||
| Vector DB | 向量資料庫。儲存文字的向量表示，支援語意相似度搜尋。 |
|
||||
| Chunking | 文件切塊。將長文件切割成適當大小的片段，再進行向量化。 |
|
||||
| Knowledge Graph | 知識圖譜。記錄實體與實體之間語意關係的網絡結構，不是圖片索引。 |
|
||||
| Naive RAG | 基礎款 RAG，適合簡單內部知識庫查詢。 |
|
||||
| HyDE | Hypothetical Document Embedding。先生成假設答案再搜尋，解決問題模糊的問題。 |
|
||||
| Corrective RAG | 糾正型 RAG，能自動判斷知識庫資料是否過時，並補充網路最新資訊。 |
|
||||
| Graph RAG | 圖譜型 RAG，讓 AI 理解知識之間的關係，而不只是找到相關文字。 |
|
||||
| Adaptive RAG | 自適應型 RAG，根據問題複雜度自動選擇查詢策略。 |
|
||||
| Agentic RAG | 代理型 RAG，支援多 Agent 協作、規劃、執行的最高階 RAG 架構。 |
|
||||
| ETL | Extract, Transform, Load。資料抽取、轉換、載入的工程流程。 |
|
||||
| Fine Tuning | 微調。針對特定領域對模型進行額外訓練，提升特定任務的表現。 |
|
||||
| n8n | 開源工作流程自動化工具，用來串接各種 API 和服務。 |
|
||||
| MCP Server | Model Context Protocol Server，讓 AI Agent 能呼叫外部工具和服務的協定。 |
|
||||
| SPARC | Claude Flow 的 Agent 協作方法論，代表 Specification、Pseudocode、Architecture、Refinement、Completion。 |
|
||||
| Ollama | 本地部署 LLM 的工具，可在自己的機器上運行開源模型。 |
|
||||
| OpenWebUI | 開源的 LLM 對話介面，類似 ChatGPT 的網頁 UI。 |
|
||||
| CoT | Chain of Thought，思維鏈。讓 AI 一步一步推理，提升複雜問題的準確率。 |
|
||||
| ReAct | Reasoning + Acting。讓 AI 交替進行推理和行動的 Agent 框架。 |
|
||||
Reference in New Issue
Block a user