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

問一個單純的 LLM「怎麼重設密碼？」，你會得到一個聽起來合理、但很可能是錯的答案：按鈕不對、流程不對、網址也不對。RAG（檢索增強生成）的解決辦法，是在模型回答之前，把你自己內容中合適的段落放進提示詞裡。

流程一覽

三個階段：匯入、檢索、生成。

1. 匯入

• 上傳 PDF、DOCX、TXT、Markdown、CSV 或 JSON 檔案、爬取你的網站，或在「訓練」裡新增問答配對。
• 背景處理程式擷取文字，切成約 2,000 個字元（大約 500 個 token）的段落，相鄰段落重疊 200 個字元。每個問答配對保持為一個段落。
• 每個段落用 text-embedding-3-small（1,536 維）產生嵌入向量。
• 段落存進裝有 pgvector 擴充功能的 PostgreSQL，並建立用於餘弦距離的 HNSW 索引。

2. 檢索

當訪客的訊息需要用到事實時，我們把他最近的幾則訊息轉成嵌入向量，在該工作區的段落上做餘弦距離搜尋。問候和閒聊會跳過這一步。查詢的簡化版如下：

-- Simplified. The real query also checks that the document is
-- ready, enabled, in date and visible on the visitor's platform.
SELECT c.id, c.content,
       1 - (c.embedding <=> $1::vector) AS similarity
FROM knowledge_chunks c
WHERE c.tenant_id = $2
ORDER BY c.embedding <=> $1::vector
LIMIT $3;  -- 3 × top-K candidates, re-ranked afterwards

我們取回所需數量三倍的候選段落，重新排序，捨棄相似度低於門檻（約 0.3）的段落，每份文件最多保留兩段，再把排名前五的段落（預設值）交給模型。

3. 生成

這些段落會附加到系統提示詞裡，放在一個有明確邊界的參考區塊中。模型被告知要把這個區塊當作資料而不是指示，只使用能回答問題的參考內容，並且不要編造其中沒有的產品事實。

如果訪客問到產品事實而找不到相關內容，就完全不會呼叫模型：系統會告訴訪客沒有這項資訊，並把對話轉給真人，除非關閉了自動轉真人。

壓低成本

有三件事讓大型知識庫的成本維持在負擔得起的範圍：

• 嵌入向量快取：相同的搜尋文字會得到相同的嵌入向量。快取鍵是模型名稱加上文字的 SHA-1 雜湊值，在 Redis 中保存 24 小時。
• 提示詞快取：對 Claude 模型，請求會要求 Anthropic 快取提示詞；OpenAI 則會自動快取較長的提示詞。參考區塊每次回覆都會改變，所以主要受惠的是提示詞中固定的部分。
• 依門檻略過：如果沒有任何段落達到門檻，就不會在提示詞裡加入任何內容。

RAG 不夠用的時候

RAG 很擅長回答「我該怎麼……？」這類問題。但它答不了「我的訂單在哪裡？」，因為這些資料不在你的文件裡。

為此，AskAIs 提供自訂工具：你描述自己系統裡的一個 HTTP 端點，例如訂單、預約或庫存，AI 在撰寫回覆時就能呼叫它。一般問題靠你的知識來回答，個人問題靠你的系統來回答，其餘的交給你的團隊。