2026-09-06 14 min read -- 次瀏覽

RAG 入門完全指南：讓 AI 讀懂你給的資料

從 Embedding、向量資料庫到檢索策略，手把手打造一套可上線的 RAG 知識庫。

大語言模型 RAGEmbedding知識庫 問小墨這篇的內容
RAG 檢索增強生成示意
RAG：讓 AI 從你的私人資料庫裡找答案，而不是亂猜。

📌 本篇文章重點

  • RAG（檢索增強生成）讓 LLM 能引用「真實資料」作答，解決亂編答案與知識過時的問題。
  • 核心流程 4 步：分段 → 向量化 → 檢索 → 合成回答。
  • 用 Chroma + Ollama 就能在筆電上跑整套 RAG，零雲端成本。
  • 最先該優化的不是模型，而是「分段與檢索」。

一、為什麼這篇值得看？

直接問 GPT「我們公司的請假規則」它一定亂答——因為它沒看過你的文件。微調重訓又貴又慢，對時常變動的資料完全不划算。

RAG 換了一條路：不教會 AI 你的資料，而是讓它每題先「去查」。資料更新 = 資料庫更新，AI 本身不用重訓。這是企業落地 AI 最常用的架構。

二、核心概念，3 分鐘搞懂

RAG 就是把人查書的過程搬進程式：

RAG 流程
文件 → 分段(chunk) → 向量化(embedding) → 存入向量庫
                                          ↓
問題 → 向量化 → 檢索最相關的片段 → 塞進提示詞 → LLM 回答

💡 一句話總結

RAG = 檢索到的正確段落 + 提示詞 + LLM。答案的精準度取決於「有沒有檢索到對的段落」。

三、動手實作：4 步建出你的第一個 RAG

Step 1

安裝工具

Bash
pip install chromadb
ollama pull nomic-embed-text   # 本機向量模型
ollama pull qwen2.5:7b         # 本機 LLM（可選）
Step 2

把文件分段並向量化

Python
import chromadb
from langchain_text_splitters import RecursiveCharacterTextSplitter
from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
emb_model = "nomic-embed-text"

with open("handbook.md") as f:
    text = f.read()

chunks = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50
).split_text(text)
Step 3

存入向量庫

Python
db = chromadb.PersistentClient(path="./rag_db")
col = db.get_or_create_collection("handbook")

def embed(t):
    r = client.embeddings.create(model=emb_model, input=t)
    return r.data[0].embedding

col.add(
    ids=[f"c{i}" for i in range(len(chunks))],
    embeddings=[embed(c) for c in chunks],
    documents=chunks,
)
Step 4

查詢：檢索 + 合成回答

Python
def ask(question):
    hits = col.query(query_embeddings=[embed(question)], n_results=3)
    ctx = "\n---\n".join(hits["documents"][0])

    prompt = f"""根據以下資料回答，若找不到就說不知道。
資料：
{ctx}

問題：{question}"""

    r = client.chat.completions.create(
        model="qwen2.5:7b",
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

print(ask("請假的流程是什麼？"))

⚠️ 重要防守

提示詞裡務必加一句「若資料中找不到答案就誠實說不知道」。這能阻止 RAG 繼續亂編，是最便宜的護欄。

四、影響品質的 3 個旋鈕

旋鈕調法影響
chunk 大小任務複雜用 700+，回答簡短用 200–500太大塞滿不相關內容，太小漏上下文
檢索數量 n_results2–5 個片段越多越全但越雜
embeddings 模型與檢索語義相關的專用模型決定「找得準不準」的天花板

五、常見問題（FAQ）

Q1檢索到的東西不對，怎麼救？

多半是 chunk 切太碎。改用「語義分段」（按標題、章節切）或加大 chunk，讓每個片段自帶上下文。

Q2一定要用雲端向量庫嗎？

個人專案用 Chroma 或本地 pgvector 就夠。資料量到百萬級、需要 HA 再考慮托管服務。

Q3RAG 和微調（Fine-tuning）選哪個？

先 RAG。資料量少、更新頻繁、要可追溯就選 RAG；要「學會某一種能力或語氣」才是微調的場。

總結

RAG 的四個字拆開就是：分段 → 向量化 → 檢索 → 合成。先把這條自己跑通，再去追進階的混合檢索、重排序（Rerank）——地基對了，高樓才蓋得穩。

問小墨 AI