面向客服的 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 在撰写回复时就能调用它。一般问题靠你的知识来回答，个人问题靠你的系统来回答，其余的交给你的团队。