RAG 技術入門：讓 AI 不再胡說八道的記憶術

AI 的兩大硬傷

你有沒有跟 AI 聊天時遇過這些情況？

硬傷 1：知識有保質期

你：2026 年的 iPhone 用什麼晶片？
AI：截至我的訓練數據（2024 年 4 月），我無法回答 2026 年的問題…

AI 的知識在訓練完成那天就凍結了。之後發生的事，它一概不知。

硬傷 2：不會就亂編

你：OpenClaw 的 QMD 記憶格式有哪些欄位？
AI：QMD 格式包含 title、content、tags、timestamp…

（你去翻文件，發現它說的一半是對的，一半是自己編的）

AI 不確定答案時，不會說「我不知道」——它會非常自信地胡說八道。學術界叫這個現象 Hallucination（幻覺）。

幻覺有多嚴重？研究顯示，就算是最強的模型，在沒有參考資料時，複雜事實性問題的幻覺率可以高達 15-25%。

RAG 是什麼？先查再答

RAG = Retrieval-Augmented Generation（檢索增強生成）

核心概念只有一句話：

讓 AI 先從你的資料庫查到相關內容，再基於這些內容回答。

就像一個認真的研究員：

❌ 不 RAG：憑記憶回答（可能記錯或胡扯）
✅ 用 RAG：先翻書查資料，引用來源回答

RAG 的完整流程

┌─────────┐    ┌──────────────┐    ┌──────────────┐    ┌─────────┐
│ 你的問題 │ →  │ 向量化搜尋    │ →  │ 找到相關文件  │ →  │ AI 回答  │
│         │    │ (Embedding)  │    │ 塞進 Prompt  │    │ 有根據的 │
└─────────┘    └──────────────┘    └──────────────┘    └─────────┘

用一個具體例子：

你問：「我上次跟客戶王先生聊了什麼？」

步驟 1 - 搜尋：在你的筆記/會議紀錄中搜尋「王先生」相關內容
步驟 2 - 找到：3 篇會議紀錄提到王先生
步驟 3 - 組合：把這 3 篇內容塞進 Prompt
步驟 4 - 回答：AI 基於這 3 篇真實紀錄回答你

→ 不再是幻覺，而是根據你的實際資料回答

關鍵技術 1：Embedding（向量嵌入）

文字怎麼變成可搜尋的？

傳統搜尋用「關鍵字比對」——你搜「蘋果」，只會找到包含「蘋果」這兩個字的文件。

但如果你的筆記寫的是「今天買了 iPhone」？關鍵字搜尋找不到，因為沒有「蘋果」這兩個字。

Embedding 解決了這個問題。 它把文字轉成一串數字（向量），讓意思相近的文字在數學空間中彼此靠近。

「蘋果」→ [0.23, 0.87, 0.12, ...]
「Apple」→ [0.25, 0.85, 0.14, ...]  ← 很接近！
「iPhone」→ [0.28, 0.82, 0.18, ...]  ← 也很接近！
「椅子」→ [0.91, 0.03, 0.76, ...]  ← 很遠

比喻：Embedding 就像把所有文字放到一張超大地圖上。意思相近的詞會靠在一起——「狗」和「寵物」很近，「狗」和「微積分」很遠。搜尋時，只要找地圖上附近的點就好。

搜尋方式對比

搜尋方式	查詢「蘋果手機」	能找到的內容
關鍵字搜尋	比對「蘋果」+「手機」	只有包含這些字的文件
向量搜尋	比對語義向量	包含 iPhone、Apple、iOS 的文件都能找到

關鍵技術 2：Vector Database（向量資料庫）

Embedding 產生的向量需要存在某個地方——這就是 Vector Database。

跟一般資料庫的差別

比較	一般資料庫 (MySQL/PostgreSQL)	向量資料庫 (Pinecone/Chroma)
存什麼	結構化資料（姓名、日期、金額）	向量（一串數字）
怎麼查	SQL 關鍵字查詢	相似度搜尋（ANN）
強項	精確匹配	語義理解
弱點	不理解「意思」	不擅長精確匹配

常見的向量資料庫

名稱	特點	適合場景
Chroma	開源、輕量、好上手	個人/小型專案
Pinecone	雲端服務、免維護	商業/生產環境
Weaviate	開源、功能豐富	中大型專案
Qdrant	高效能、Rust 實作	效能敏感場景

RAG 在 OpenClaw 中的實現：Memory 系統

OpenClaw 的 Memory 系統就是 RAG 的實際應用。

Memory 的運作方式

你跟 Agent 的對話
       ↓
重要內容被萃取出來 → 轉成向量 → 存入記憶庫
       ↓
下次相關話題出現時
       ↓
Memory 自動檢索相關記憶 → 塞進 Prompt → Agent 「記得」

三種記憶類型

類型	說明	比喻
Episodic（情節記憶）	具體事件：「2/15 跟王先生開會」	日記
Semantic（語義記憶）	摘要知識：「王先生偏好保守方案」	筆記
Procedural（程序記憶）	操作步驟：「報價流程是 A→B→C」	SOP

QMD 格式

OpenClaw 用 QMD（一種結構化記憶格式）儲存記憶，讓 RAG 檢索更精準：

# 一筆記憶的格式
type: episodic
content: "2/15 與王先生開會，他提到預算上限 50 萬，偏好分期付款"
tags: ["王先生", "會議", "預算"]
created: "2026-02-15"
importance: high

Memory 系統讓你的 Agent 真正「記住你」——不是把所有對話存起來（太浪費），而是萃取重點 → 向量化 → 需要時檢索。這就是 RAG 的實戰應用。

RAG vs 長 Context Window

你可能會想：Context Window 已經做到 100 萬 Token 了（Gemini 1.5），為什麼還需要 RAG？

比較	塞進 Context Window	用 RAG
資料量	有上限（再大也有限）	理論上無限
成本	窗口越大越貴	只檢索需要的部分，便宜
精準度	資料太多時注意力分散	只挑相關的，更精準
速度	資料越多越慢	檢索快，回答快
即時性	每次都要重新塞進去	資料庫隨時更新

比喻：Context Window 像桌面——桌子再大也有限。RAG 像圖書館的索引系統——書有幾百萬本沒關係，你只需要找到那本就好。

實務上，最好的做法是兩者結合：用 RAG 檢索最相關的內容，放進 Context Window 讓 AI 回答。OpenClaw 的 Memory 系統正是這麼做的。

RAG 的限制：不是萬靈丹

1. 檢索品質是關鍵

如果搜到的資料不對，AI 的回答也會不對（Garbage In, Garbage Out）。

2. 無法完全消除幻覺

AI 可能忽略你提供的資料，或者把多份資料混在一起產生新的錯誤。

3. 需要維護資料品質

你的記憶庫裡如果有過時或矛盾的資訊，RAG 可能會挖出來用。

OpenClaw 的 Soul 系統中的 Memory 衰減機制就是為了解決這個問題——讓舊的、不重要的記憶自動淡化。

一張圖看懂 RAG 在 OpenClaw 中的角色

┌─────────────────────────────────────────────────┐
│               你跟 Agent 對話                     │
└───────────────────────┬─────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────┐
│  Agent 分析你的意圖                               │
│  → 需要查歷史資料嗎？                             │
│     ├── 不需要 → 直接回答                         │
│     └── 需要 → 觸發 RAG                          │
└───────────────────────┬─────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────┐
│  RAG 流程                                        │
│  1. 把你的問題 Embedding（向量化）                 │
│  2. 在 Memory 資料庫中搜尋相似向量                 │
│  3. 取回最相關的 3-5 筆記憶                        │
│  4. 把記憶塞進 Prompt                             │
└───────────────────────┬─────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────┐
│  AI 基於真實資料回答你的問題                       │
│  「根據 2/15 的會議紀錄，王先生的預算上限是…」      │
└─────────────────────────────────────────────────┘