「我的 AI 客服一直答錯，是不是 AI 不夠強？」
大多數時候，答案是：不是 AI 的問題，是知識庫的問題。
純 LLM 的根本限制
GPT、DeepSeek、Claude 這些大型語言模型的訓練資料有個截止日期，而且它們根本不知道：
- 你的產品規格是什麼
- 你的定價方案怎麼算
- 你的退換貨政策有哪些條款
- 你的服務流程是哪幾個步驟
如果你直接把 LLM 接上 LINE Bot，沒有提供任何背景資料，它只能靠「猜」來回答——猜錯是必然的。
RAG（Retrieval-Augmented Generation） 就是解決這個問題的架構。
RAG vs 純 LLM：差在哪？
純 LLM：
用戶問題 → LLM（靠訓練記憶回答）→ 回覆
RAG：
用戶問題 → 向量搜尋知識庫 → 找到相關段落 → LLM（根據段落回答）→ 回覆| 比較項目 | 純 LLM | RAG |
|---|---|---|
| 知識來源 | 訓練資料（有截止日） | 你的文件庫（隨時更新） |
| 回答準確度 | 容易幻覺、捏造 | 有根據，可引用來源 |
| 客製化程度 | 低，只知道公開資訊 | 高，知道你的私有知識 |
| 維護方式 | 需要重新訓練模型 | 只需更新文件庫 |
| 成本 | Fine-tuning 極貴 | 向量索引成本低 |
對 90% 的企業 AI 客服場景來說，RAG 是正確答案——不需要自己訓練模型，只需要整理好文件。
RAG 的四個核心步驟
1. 文件準備（Chunking）
把你的知識來源（FAQ、產品文件、操作手冊）切成適當大小的段落。
關鍵原則：
- 每個 chunk 約 200–500 字，語意完整
- 不要切在句子中間
- 標題、URL 等 metadata 一起存
2. 向量化（Embedding）
把每個段落轉成向量（一串數字）。語意相近的段落，向量距離也近。
「退貨政策是 7 天鑑賞期」
↓ Embedding 模型
[0.12, -0.34, 0.87, 0.05, ...] ← 768 維向量3. 向量搜尋（Retrieval）
用戶的問題也向量化，然後在知識庫裡找「最相近」的幾個段落。
用戶問：「我買的東西可以退嗎？」
↓ 向量搜尋
找到：退貨政策段落（相似度 0.92）
退貨流程說明（相似度 0.87）
客服聯絡方式（相似度 0.71）4. 生成（Generation）
把找到的相關段落塞進 LLM 的 prompt，讓它根據這些資料回答：
[系統提示]
你是客服助理，根據以下知識回答用戶問題。
[知識片段]
退貨政策：購買後 7 天內可申請退貨，商品需保持原狀...
[用戶問題]
我買的東西可以退嗎？本站 LINE Bot 的實際架構
這個網站本身就是 LINE Bot 的知識庫。架構如下：
網站文章（Markdown）
↓ npm run reindex
文章切成 chunks（約 300 字/塊）
↓ Cloudflare Workers AI（bge-m3 模型）
向量化 → 存入 Cloudflare Vectorize
↓
用戶在 LINE 提問
↓ LINE Webhook → Cloudflare Worker
問題向量化 → Vectorize 搜尋（topK=5, minScore=0.4）
↓
相關文章段落 + 用戶問題 → DeepSeek Chat
↓
回覆 + 引用來源連結技術選型說明：
- Cloudflare Vectorize：無伺服器向量資料庫，按用量計費，適合中小型知識庫
- bge-m3：支援中英混合語言的 Embedding 模型，繁體中文效果好
- DeepSeek Chat：性價比高，繁體中文輸出品質穩定
- minScore=0.4：過濾掉相似度太低的結果，避免引用不相關段落
實際檢索程式碼
export async function retrieve(
query: string,
embedder: WorkersAIEmbedding,
index: VectorizeIndex,
options = { topK: 5, minScore: 0.4 },
) {
const [vector] = await embedder.embed([query]);
const results = await index.query(vector, {
topK: options.topK,
returnMetadata: 'all',
});
return results.matches
.filter((m) => m.score >= options.minScore)
.map((m) => ({
score: m.score,
text: m.metadata?.text as string,
title: m.metadata?.title as string,
url: m.metadata?.url as string,
}));
}知識庫怎麼維護？
建好知識庫不是一勞永逸，需要定期更新：
什麼時候要更新：
- 產品規格或定價變動
- 新增服務項目
- 客服發現 Bot 常答錯某類問題（代表知識庫缺這塊）
更新流程（以本站為例）：
- 修改或新增 Markdown 文章
- 執行
npm run reindex（重新向量化並上傳） - 部署新版網站
整個流程約 5 分鐘，不需要重新訓練任何模型。
監控指標：
- RAG 命中率：每次回覆是否找到相關段落
- 用戶滿意度：Bot 回答後是否繼續追問或直接離開
- 轉接真人比例：若比例過高，代表知識庫有缺口
你需要 RAG 嗎？
如果你的 AI 客服需要回答這些問題，答案幾乎都是「需要」：
- 你的產品/服務細節
- 你的定價與方案
- 你的流程與政策
- 你的成功案例
知識庫的品質決定 AI 客服的品質。整理 FAQ 文件、產品說明、服務流程，就是在幫你的 AI 客服「補腦」。
想建立自己的 RAG 知識庫？
從文件整理到向量化部署，每個專案的規模和需求都不同。
加入 LINE Bot 告訴我你想解決的問題，我可以幫你評估知識庫的規模、技術選型和維護成本。或者到聯絡頁面留下資訊，讓我們深入討論你的場景。