幻觉与应对 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 」，做好过滤和路由才是关键。知识库质量 → 检索质量 → 回答质量，三层缺一不可。