讓 AI 學會查資料：RAG 與 Embedding 技術解析

什麼是 RAG？

Retrieval-Augmented Generation（檢索增強生成）是一種結合「資料檢索」與「AI 生成」的技術架構。它讓 AI 不再只依賴訓練時學到的知識，而是在回答問題的當下，即時從你的資料庫中找到最相關的內容，再據此生成回答。

簡單說：RAG 讓 AI 擁有「查資料再回答」的能力。

為什麼需要 RAG？

純粹的大型語言模型（LLM）有幾個根本性的限制：

• 知識截止日期： 模型只知道訓練資料中的內容，無法回答訓練後發生的事。
• 幻覺問題 (Hallucination)： 當模型不確定答案時，它會「自信地編造」看似合理的內容。
• 無法存取私有資料： 你的產品文件、內部知識庫、部落格文章，模型一概不知。

RAG 的出現就是為了解決這些問題——讓 AI 的回答有據可查，而不是憑空捏造。

RAG 的運作流程

一個完整的 RAG 系統通常包含三個階段：

1. 索引 (Indexing)： 將你的文件內容切割成小段落（Chunks），並透過 Embedding 模型轉換為向量，存入資料庫。
2. 檢索 (Retrieval)： 當使用者提出問題時，將問題同樣轉換為向量，然後透過相似度比對，從資料庫中找出最相關的段落。
3. 生成 (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 系統的注意事項

1. Chunking 品質比模型選擇更重要。 再好的 Embedding 模型也救不了切割混亂的文件。
2. Query 與 Document 的格式要一致。 某些模型（如 E5 系列）要求查詢加 "query: " 前綴、文件加 "passage: " 前綴，忽略這點會嚴重影響檢索品質。
3. 向量資料庫的選擇取決於規模。 幾千筆資料用 MongoDB 或 PostgreSQL + pgvector 就夠；百萬級以上才需要考慮 Pinecone、Milvus 等專用方案。
4. 定期重建索引。 當內容更新後，舊的向量不會自動失效，需要機制確保向量與原文同步。

總結

RAG 與 Embedding 的結合，解決了 AI 應用中最關鍵的問題：如何讓模型的回答基於事實而非猜測。Embedding 負責讓機器「理解」文字的語意，RAG 負責在對的時機把對的資料送到 AI 手中。

Embedding 讓文字有了座標，RAG 讓 AI 學會查資料。兩者結合，AI 才從「很會說話」進化成「說得有根據」。