Article
讓 AI 學會查資料：RAG 與 Embedding 技術解析
當 AI 不再只靠訓練記憶回答問題，而是能即時從你的資料中檢索再生成，這就是 RAG（檢索增強生成）的核心概念。本文從 Embedding 向量化到 Cosine Similarity 相似度計算，完整拆解 RAG 的運作原理與實務要點。
本文目錄
什麼是 RAG？
Retrieval-Augmented Generation（檢索增強生成）是一種結合「資料檢索」與「AI 生成」的技術架構。它讓 AI 不再只依賴訓練時學到的知識，而是在回答問題的當下，即時從你的資料庫中找到最相關的內容，再據此生成回答。
簡單說：RAG 讓 AI 擁有「查資料再回答」的能力。
為什麼需要 RAG？
純粹的大型語言模型（LLM）有幾個根本性的限制：
- 知識截止日期： 模型只知道訓練資料中的內容，無法回答訓練後發生的事。
- 幻覺問題 (Hallucination)： 當模型不確定答案時，它會「自信地編造」看似合理的內容。
- 無法存取私有資料： 你的產品文件、內部知識庫、部落格文章，模型一概不知。
RAG 的出現就是為了解決這些問題——讓 AI 的回答有據可查，而不是憑空捏造。
RAG 的運作流程
一個完整的 RAG 系統通常包含三個階段：
- 索引 (Indexing)： 將你的文件內容切割成小段落（Chunks），並透過 Embedding 模型轉換為向量，存入資料庫。
- 檢索 (Retrieval)： 當使用者提出問題時，將問題同樣轉換為向量，然後透過相似度比對，從資料庫中找出最相關的段落。
- 生成 (Generation)： 將找到的相關段落作為上下文（Context），連同使用者的問題一起送給 LLM，讓它基於這些真實資料生成回答。
關鍵點：RAG 的品質取決於「檢索」的精準度。如果第 2 步找到的段落不相關，第 3 步的回答再流暢也沒有意義。
什麼是 Embedding？
Embedding（嵌入向量）是 RAG 的核心基礎設施。它的作用是將文字轉換成一組數字（向量），讓電腦能夠理解文字之間的「語意距離」。
舉例來說：
| 文字 | 向量（簡化示意） |
|---|---|
| 「JavaScript 的非同步處理」 | [0.82, -0.15, 0.43, ...] |
| 「JS async/await 錯誤處理」 | [0.79, -0.12, 0.41, ...] |
| 「今天晚餐吃什麼」 | [-0.31, 0.67, -0.22, ...] |
前兩句話語意相近，因此向量數值也接近；第三句話完全不相關，向量方向截然不同。這就是 Embedding 的威力——它捕捉的是語意，而非關鍵字。
Embedding 的技術細節
模型選擇
常見的 Embedding 模型各有特色：
| 模型 | 維度 | 多語言 | 適用場景 |
|---|---|---|---|
| text-embedding-3-small (OpenAI) | 1536 | 是 | 通用場景、商業應用 |
| intfloat/multilingual-e5-small | 384 | 是 | 輕量部署、中文支援佳 |
| BAAI/bge-m3 | 1024 | 是 | 高精度多語言檢索 |
| all-MiniLM-L6-v2 | 384 | 否 | 英文為主的輕量場景 |
維度越高，理論上能表達越細緻的語意差異，但也意味著更大的儲存空間與更高的運算成本。對大多數應用來說，384 維已經足夠。
Chunking 策略
在生成 Embedding 之前，必須先將長文切割成適當大小的 Chunks。這一步驟直接影響檢索品質：
- 太大的 Chunk： 包含過多不相關資訊，稀釋了語意焦點。
- 太小的 Chunk： 失去上下文，導致語意不完整。
- 最佳實踐： 以段落為自然切割點，每個 Chunk 控制在 200–500 tokens，確保語意完整且聚焦。
相似度計算
有了向量之後，如何判斷兩段文字有多「相似」？最常用的方法是 Cosine Similarity（餘弦相似度）：
similarity = (A · B) / (|A| × |B|)
- 結果範圍為
-1到1，越接近1表示越相似。 - 它衡量的是向量的「方向」而非「長度」，因此不受文字長短影響。
RAG vs. Fine-tuning：什麼時候該用哪個？
| 比較面向 | RAG | Fine-tuning |
|---|---|---|
| 適用情境 | 資料經常更新、需要引用來源 | 需要改變模型的語氣或行為模式 |
| 資料更新 | 即時，只需更新向量資料庫 | 需要重新訓練模型 |
| 成本 | 低，主要是儲存與檢索 | 高，需要 GPU 運算時間 |
| 幻覺控制 | 強，回答基於實際資料 | 弱，仍可能編造 |
| 可解釋性 | 高，可追溯引用來源 | 低，無法得知答案依據 |
如果你的需求是「讓 AI 知道你的資料」，選 RAG；如果需求是「讓 AI 變成你的語氣」，選 Fine-tuning。
實際應用場景
RAG + Embedding 的組合已經被廣泛應用：
- 知識庫問答： 企業內部文件搜尋，員工直接用自然語言提問。
- 智慧客服： 基於產品文件與 FAQ 自動生成精準回答。
- 相關內容推薦： 部落格、新聞網站透過語意相似度推薦相關文章。
- 程式碼搜尋： 在大型 codebase 中用自然語言找到相關的函式或模組。
- 個人化學習： 將教材向量化，根據學生提問推薦最相關的章節。
建構 RAG 系統的注意事項
- Chunking 品質比模型選擇更重要。 再好的 Embedding 模型也救不了切割混亂的文件。
- Query 與 Document 的格式要一致。 某些模型（如 E5 系列）要求查詢加
"query: "前綴、文件加"passage: "前綴，忽略這點會嚴重影響檢索品質。 - 向量資料庫的選擇取決於規模。 幾千筆資料用 MongoDB 或 PostgreSQL + pgvector 就夠；百萬級以上才需要考慮 Pinecone、Milvus 等專用方案。
- 定期重建索引。 當內容更新後，舊的向量不會自動失效，需要機制確保向量與原文同步。
總結
RAG 與 Embedding 的結合，解決了 AI 應用中最關鍵的問題：如何讓模型的回答基於事實而非猜測。Embedding 負責讓機器「理解」文字的語意，RAG 負責在對的時機把對的資料送到 AI 手中。
Embedding 讓文字有了座標，RAG 讓 AI 學會查資料。兩者結合，AI 才從「很會說話」進化成「說得有根據」。