幻觉与应对

RAG 的代价与优化策略

每次 RAG 查询都要额外花钱。不优化，成本会随用量快速失控。

额外成本来源
文档向量化
低（一次性）
Embedding 入库时跑一次，之后复用
问题向量化
低
每次查询约 0.1 元/百万 Token
向量检索
中
大规模知识库时延迟显著
Prompt 增大
高
每次多注入 500–2000 Token，LLM 费用倍增 ⚠
最关键的优化：先做意图识别，判断是否需要 RAG。70% 的对话其实不需要检索文档，直接用 LLM 回答更快更便宜。
PM 应对策略
建立检索命中率评测：知道有多少问题被成功检索到正确文档
引用来源强制显示：让用户可核查，也倒逼知识库质量
定期清洗知识库：RAG 质量上限 = 知识库质量
四种优化策略（点击展开）
关键词触发（过滤）
节省成本：跳过 30–70% 查询
先判断问题是否需要检索。「今天几号？」不需要查文档，直接回答；「我们的退款政策」才触发 RAG。
实现：用意图分类器或简单规则预判断，跳过不必要的检索链路。
模型路由（分级处理）
整体 LLM 费用降低 60–80%
简单问题用小模型（便宜），复杂问题才上旗舰模型。避免用 GPT-4 回答「你好」。
实现：问题复杂度分级 + 模型梯队配置（小模型兜底，大模型按需调用）。
语义缓存
高频查询降低 50% 延迟和费用
相似的问题复用同一检索结果。「退款政策」和「怎么退款」结果几乎一样，无需重复查询。
实现：问题向量相似度 ≥ 0.95 时直接返回缓存，跳过整条 RAG 链路。
精准切块（Chunking 策略）
准确率提高 20–40%
文档切割粒度影响检索质量。太大注入冗余 Token；太小丢失上下文。
最佳实践：约 512–800 Token/块，以标题/段落为边界，保留语义完整性。
还有一条路：让模型自己去翻
RAG：先切好、先算好向量
检索是「找相似」，答案在片段里
  • 适合：语料海量且相对稳定——产品手册、法规、客服知识库、历年工单
  • 适合：问题是「这事怎么规定的」，答案散在几百份文档的某几段里
  • 代价：切块、入库、更新一整条流水线，文档一改就得重跑
  • 软肋：只按语义相似度捞，要「精确匹配某个编号」时经常捞不准
工具读取：grep / glob / read
模型自己决定翻哪个文件、翻几遍
  • 适合：语料本来就带结构又天天变——代码仓库、日志、当前这台机器上的文件
  • 适合：要精确匹配（函数名、错误码、订单号），grep 一把命中，向量检索反而绕
  • 代价：多轮工具调用，延迟和 Token 都比一次检索高，且要给模型开读取权限
  • 软肋：文件规模超过模型能翻的范围就会漏，得靠目录结构和命名帮它收敛
怎么选：先问一句「这份资料有没有天然的索引」。 代码有文件路径和函数名，日志有时间戳，这类直接给工具让模型自己翻； 一堆没结构的 PDF 和网页，才轮到 RAG 先切块建索引。两者也常常混着用—— 先 RAG 找到大致位置，再用工具把那个文件完整读一遍。
RAG ≠ 全量检索。生产级 RAG 系统的核心是「什么情况下不用 RAG」，做好过滤和路由才是关键。知识库质量 → 检索质量 → 回答质量，三层缺一不可。