上一篇文章里我们讨论了多模态 RAG。一个重要结论是图片、截图、表格和流程图也可以进入 RAG 检索链路。但当 RAG 真的上线以后另一个更现实的问题会立刻出现成本。RAG 的成本不只来自大模型调用还来自Embedding 检索 Rerank 多轮对话 长上下文拼接 多模态解析 日志和审计如果不做成本控制系统越用越贵最后就会变成“能跑但不敢用”。所以这篇文章讨论一个企业 RAG 必须面对的问题RAG 如何降低成本缓存、摘要和分层检索能怎么用。RAG 的成本到底花在哪很多人一开始只盯着模型 token 成本。这当然重要但不是全部。一个完整的 RAG 请求通常会经过用户问题 ↓ Query 处理 ↓ Embedding ↓ 向量检索 ↓ 关键词检索 ↓ Rerank ↓ Prompt 拼接 ↓ 大模型生成每一步都可能花钱。尤其在高并发场景里成本会叠加得很快。比如检索一次很便宜但每天几万次就不便宜了。 Rerank 只多跑几毫秒但乘以高并发也会明显增加算力消耗。 长上下文最贵不少成本都花在把无效内容塞进 Prompt。 Embedding 重建索引时也会花不少钱。所以降成本不能只靠“换个便宜模型”。它需要从检索链路、缓存和上下文设计一起做。第一招Query Cache最直接的降成本方式之一是缓存用户问题和检索结果。比如同一个问题反复被问。 相似问题频繁出现。 固定 FAQ 被多人查询。这时可以做 Query Cache。如果历史上已经回答过类似问题就不必每次都重新走完整链路。可以缓存标准化后的 query 召回结果 最终答案 引用来源Query Cache 有两个关键点。第一不能只按原始字符串缓存。因为用户可能换个说法问同一个问题。所以通常要先做 query 归一化或相似度匹配。第二缓存必须有失效策略。比如文档更新了旧答案就不能一直用。所以缓存的 key 最好带上tenant_id space_id prompt_version knowledge_version这样才能避免拿旧结果回答新问题。第二招Embedding CacheEmbedding 也可以缓存。比如同一个问题、同一个文档片段、同一个标题经常重复计算向量就可以缓存向量结果。常见场景包括重复的用户查询 重复的文档段落 固定模板内容 高频 FAQEmbedding Cache 的核心原则是相同输入不要反复算向量。但要注意文档内容变了缓存要失效。 文档版本变了缓存要失效。 不同模型生成的 embedding 不能混用。所以缓存 key 至少要包括text_hash embedding_model_version tenant_id space_idEmbedding Cache 能省一部分成本但不是万能。它更适合高频重复输入而不是所有场景。第三招摘要缓存长文档和长对话最容易把成本拉高。因为上下文越长Prompt 就越贵。这时可以考虑摘要缓存。比如文档摘要 章节摘要 问题摘要 对话上下文摘要 检索结果摘要摘要的作用是把长内容压缩成更短、更有信息密度的版本。例如一份很长的制度文档可以先生成章节摘要第一章适用范围 第二章审批规则 第三章例外情况 第四章历史版本差异这样在做粗筛检索时先召回摘要再决定是否下钻到原文。摘要缓存特别适合两类场景第一文档很长但内容不常变。第二用户经常问的是概括性问题而不是细节问题。比如这份制度主要讲什么 这个项目有哪些关键风险 这个系统的整体架构是什么不过摘要有一个风险摘要会丢细节。所以摘要适合粗筛不适合替代原文。更好的做法是先用摘要快速定位 再回原文核实第四招分层检索分层检索是很实用的降成本手段。它的核心思想是不是所有问题都要一上来就查最贵的深层内容。可以先粗后细。比如第一层文档标题和摘要 第二层章节级内容 第三层正文 Chunk 第四层精确字段和表格这样能避免一开始就把大量正文全部拉进来。一个典型流程是用户问题 ↓ 先查摘要或标题 ↓ 如果命中不够再查章节 ↓ 如果还不够再查正文 Chunk ↓ 最后必要时查表格和细粒度内容这个思路的好处是减少无效召回 减少长上下文 减少 Rerank 候选 降低模型输入 token分层检索对大知识库尤其有用。因为不是每个问题都需要最细的粒度。第五招小模型和大模型协作不是所有环节都必须用最贵的大模型。可以把任务拆给不同模型。比如小模型做 query 改写 小模型做摘要 小模型做粗分类 大模型做最终回答这样可以把成本花在真正需要高质量推理的地方。比如用户问题先交给小模型判断类型 再决定走普通检索还是多步检索 最后只在需要时调用大模型生成最终答案这类分工能明显降低成本。但前提是你对每一步的质量边界有把握。否则为了省成本把链路做得太复杂反而会拉低效果。第六招Token 控制长上下文是 RAG 成本的大头之一。所以 token 控制非常关键。可以做的事包括限制 TopK 去重 压缩片段 过滤低相关结果 限制重复段落 优先保留高质量证据不要把“能召回多少”理解成“应该放多少”。很多时候召回太多反而不好。因为无效上下文变多 模型注意力被稀释 答案更容易混乱 成本更高所以 Prompt 里的上下文应该尽量短而精。这也是为什么 Rerank 很重要。Rerank 不只是提准度也是在帮你省 token。第七招冷热分层知识库内容通常不是均匀使用的。有些内容每天都在被问。有些内容很少被问。所以可以做冷热分层。比如热知识高频 FAQ、常见制度、核心接口说明 温知识普通业务文档 冷知识历史版本、归档材料、低频资料对于热知识可以做更强缓存 更快索引 更高优先级 更低延迟策略对于冷知识可以做更低频索引更新 更低优先级召回 更严格的历史版本过滤冷热分层能帮助你把资源用在高频问题上。一个可落地的低成本 RAG 流程一个比较实用的降成本方案可以这样设计用户问题 ↓ Query 归一化 ↓ 命中 Query Cache ? ↓ 是直接返回缓存答案 ↓ 否走检索链路 ↓ 先查摘要 / 标题 / 热知识 ↓ 不足再下钻正文 ↓ Rerank ↓ 控制上下文长度 ↓ 大模型生成 ↓ 写入缓存和统计这个流程的重点不是省掉所有步骤而是减少不必要的步骤。尤其是重复查询不要重复算 粗问题不要直接下钻细节 低相关内容不要进 Prompt 高频内容要更充分缓存降成本和降质量不是一回事这里要特别小心一个误区降成本不能把系统做坏。比如把 TopK 压得太小 把摘要压得太狠 把缓存失效策略做得太粗 把小模型用在不该用的地方这些都可能省钱但也可能让答案变差。所以成本优化必须配合评测。要看成本下降了多少 召回是否变差 答案是否更不稳定 引用是否更少 延迟是否更低成本优化是工程问题不是只看账单问题。落地建议第一先做 Query Cache 和 Embedding Cache这两个最容易见效。第二长文档和高频文档优先做摘要缓存。第三检索链路尽量做分层不要一上来全量深挖。第四控制上下文长度别把无效内容拼进 Prompt。第五把小模型用在改写、摘要和分类上把大模型留给最终回答。第六高频知识做热分层低频历史内容做冷处理。第七所有成本优化都要和质量评测一起看。第八缓存 key 要带版本和租户信息避免旧答案污染新问题。总结RAG 降成本的关键不是单纯换便宜模型而是减少重复计算、减少无效检索、减少无效上下文。缓存、摘要、分层检索、小模型协作和 token 控制都是很实用的工程手段。如果这些手段做得好RAG 可以在维持效果的同时把成本压到一个更合理的区间。下一篇文章可以继续讨论 RAG 上线后怎么排查问题。因为系统真正运行起来以后日志和可观测性会决定你能不能找到问题根因。