面向客服的 RAG：如何讓 AI 回覆真正準確

沒有檢索時，LLM 在回答"我該如何重設密碼？"時會給出一個看似合理、但很可能是 錯的答案——不同的按鈕、不同的流程、不同的 URL。RAG（檢索增強生成）透過在模型開口之前， 把你文件中正確的片段注入到提示詞裡，來解決這個問題。

流水線概覽

三個階段：擷取、檢索、生成。

1. 擷取

• 透過知識庫 UI 上傳 PDF、Markdown、Office 檔案
• Worker 擷取文字，按約 800 token 分塊，重疊 100 token
• 每個分塊用 text-embedding-3-small（1536 維）做嵌入
• 儲存在帶 pgvector 擴充功能的 Postgres 中

2. 檢索

當訪客傳送訊息時，我們對查詢做嵌入，並針對該租戶的分塊執行餘弦距離搜尋。Top-K （預設 5）會被取出，並搭配相似度閾值來剔除不相關的匹配。

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM knowledge_chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 5;

3. 生成

檢索到的分塊會被前置到系統提示詞中，並附上明確指令：引用來源、若上下文未涵蓋該問題 則拒絕回答、若信心度低則轉交人工。

削減 token 帳單

有三個技巧能在大型知識庫上省下真金白銀：

• 嵌入快取——相同的查詢文字 → 相同的嵌入。用 SHA1 雜湊作為鍵， 在 Redis 中設 24 小時 TTL。重複問題的重新嵌入成本降為零。
• 提示詞快取——Anthropic 的 cache_control 和 OpenAI 的自動快取意味著靜態系統提示詞在每個 5 分鐘視窗內只計費一次。
• 基於閾值的跳過——如果沒有任何分塊通過相似度閾值，就什麼都不注入。 讓模型說"我不知道。"

當 RAG 不夠用時

RAG 很擅長處理"我該如何做 X？"這類問題。它在個人化資料上會失敗 （"我的訂單在哪？"）——那需要函式呼叫，我們會在另一篇文章中介紹。 兩者結合，才能讓你以一小部分的成本獲得 Intercom 等級的 AI。