面向客服的 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。