Files
arcrun-rag-demo-knowledge/docs/RAG 課程知識庫.md
T

20 KiB
Raw Blame History

title
title
RAG 課程知識庫

RAG 課程知識庫

來源:虎智科技(TIGER AI)基本 RAG 教學投影片

共 16 頁,以下依頁碼整理


第 1 頁:小 G 的秘密,大 L

本課程的核心比喻是「小 G」與「大 L」的關係。

  • 小 GLLM:代表大型語言模型(Large Language Model),例如 GPT、Gemini、Claude 等。小 G 擁有強大的語言理解與生成能力,可以進行對話、摘要、推理,但他本身的知識有截止日期,也不知道你公司內部的事情。
  • 大 L(世界級大知識庫):代表 LLM 訓練時所吸收的龐大世界級知識,例如維基百科、網路文章、學術論文等。這是 LLM 在訓練階段就學到的知識,儲存在模型的參數裡。

小 G 和大 L 之間的雙向箭頭,表示 LLM 是從世界級知識庫訓練而來的,也可以透過知識庫來強化回答能力。


第 2 頁:家用小 G,加上我家小 L

在企業應用中,光靠世界級知識庫(大 L)是不夠的。企業需要讓 LLM 也能掌握公司內部的知識,因此引入了「小 L(本公司小知識庫)」。

  • 小 GLLM:語言模型,負責理解問題、產生回應。
  • 大 L(世界級大知識庫)LLM 訓練時的龐大知識背景。
  • 小 L(本公司小知識庫):企業自己建立的私有知識庫,包含內部文件、SOP、產品說明書、會議紀錄等,是 LLM 原本不知道的資訊。

RAGRetrieval-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

這一頁介紹 HyDEHypothetical 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(推理+行動)和 CoTChain 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 框架。