AI搜索 如何降低成本｜生产环境实测

在大模型应用逐步从 Demo 走向生产环境之后，很多团队都会遇到同一个问题：AI 搜索效果确实更好了，但成本也明显上来了。
尤其是基于 RAG（Retrieval-Augmented Generation，检索增强生成）的 AI 搜索系统，一旦用户量增长，向量检索、Embedding、重排序、长上下文调用、LLM 生成等环节都会成为成本来源。
本文结合一次生产环境中的 AI 搜索优化实践，系统拆解 AI 搜索的主要成本构成，并给出可落地的降本方案。

一、为什么 AI 搜索会越来越贵？

传统搜索的主要成本集中在：

• 文档索引构建；
• 倒排索引存储；
• 查询召回；
• 排序计算；
• 搜索集群资源。

而 AI 搜索引入大模型之后，成本结构发生了明显变化。

典型 AI 搜索链路如下：

用户问题
  ↓
问题改写 / 意图识别
  ↓
Embedding 向量化
  ↓
向量召回 / 混合检索
  ↓
结果重排序
  ↓
上下文拼接
  ↓
大模型生成答案
  ↓
返回结果

每增加一个智能化环节，就可能增加一次模型调用或一次计算资源消耗。

在生产环境中，AI 搜索的成本通常来自以下几个方面：

其中，LLM 生成和上下文 Token 消耗通常是最显性的成本；而Embedding、重排序、向量库资源则是容易被低估的隐性成本。

二、生产环境实测背景

本次优化对象是一个企业知识库 AI 搜索系统，主要用于内部员工查询制度、产品文档、技术方案、流程规范等内容。

1. 系统基本情况

优化前，系统采用较标准的 RAG 架构：

Query
  ↓
Embedding
  ↓
向量召回 Top 20
  ↓
Rerank Top 8
  ↓
拼接上下文
  ↓
调用大模型生成答案

2. 数据规模

生产环境大致情况如下：

3. 优化前成本问题

上线初期效果不错，但随着使用量增长，问题逐渐暴露：

1. 每次搜索都调用大模型，成本线性增长；
2. 召回文档过多，导致上下文 Token 偏大；
3. 大量重复问题未命中缓存；
4. 低价值问题也进入完整 RAG 链路；
5. Rerank 计算资源占用较高；
6. 日志记录过细，存储费用增长明显。

经过统计，优化前单次 AI 搜索的平均成本主要集中在：

LLM 生成成本：约 65%
Embedding 成本：约 8%
Rerank 成本：约 12%
向量库与计算资源：约 10%
日志与其他：约 5%

也就是说，如果只盯着模型单价，而不优化链路，很难真正把成本降下来。

三、降本核心思路：不是换便宜模型，而是减少不必要调用

很多团队做 AI 搜索降本，第一反应是：

“把大模型换成更便宜的模型。”

这当然是一种办法，但并不是最优先的办法。

在生产环境中，真正有效的降本思路应该是：

1. 能不调用模型，就不调用模型；
2. 能少传 Token，就少传 Token；
3. 能用小模型解决，就不用大模型；
4. 能缓存，就不要重复计算；
5. 能提前判断无效请求，就不要进入完整链路；
6. 能分层处理，就不要所有请求都走最高规格。

也就是说，AI 搜索降本不是单点优化，而是链路优化。

四、优化一：增加语义缓存，减少重复生成

1. 为什么普通缓存不够？

普通缓存通常按照 Query 字符串完全匹配，例如：

公司年假怎么申请？

如果用户换一种问法：

年假申请流程是什么？
我想休年假，要怎么提交？
年假在哪里申请？

字符串不同，普通缓存无法命中。

但从语义上看，这些问题指向的是同一个答案。

因此，我们增加了语义缓存。

2. 语义缓存方案

流程如下：

用户 Query
  ↓
Query Embedding
  ↓
查询缓存向量库
  ↓
相似度超过阈值？
  ↓
命中：直接返回缓存答案
未命中：进入完整 RAG 链路

缓存内容包括：

• 原始问题；
• Query 向量；
• 最终答案；
• 命中文档 ID；
• 答案生成时间；
• 业务分类；
• 可用状态；
• 用户反馈分。

3. 阈值设置

我们没有一开始就把阈值设得很低，而是采用灰度策略。

最终线上稳定阈值为 0.88 左右。低于该阈值的问题仍走完整链路，避免答非所问。

4. 实测效果

上线语义缓存后，生产环境数据如下：

语义缓存是本次降本中最直接有效的一项措施。

它带来的价值不仅是减少模型调用，还包括：

• 响应速度更快；
• 高峰期系统更稳定；
• 热点问题答案一致性更高；
• 降低下游模型抖动影响。

不过，语义缓存也要注意失效机制。如果知识库文档更新了，关联缓存必须失效，否则可能返回旧答案。

五、优化二：减少上下文 Token，降低生成成本

LLM 成本通常与输入 Token 和输出 Token 有关。在 RAG 搜索中，输入 Token 往往比输出 Token 更容易失控。

优化前系统会召回 Top 20，然后 Rerank 取 Top 8 拼接到 Prompt 中。很多情况下，Top 8 中存在大量重复内容。

例如某个制度文档被切成多个片段，用户问一个流程问题时，可能召回同一篇文档里的连续 5 个片段，导致上下文冗余。

1. 上下文压缩策略

我们采用了三层压缩：

第一层：同文档片段合并

如果多个片段来自同一篇文档，优先合并为连续段落，而不是重复拼接标题、元信息和无关内容。

第二层：去除低相关句子

对于长片段，只保留与 Query 相关度较高的句子。

例如原片段包含：

适用范围、定义说明、申请入口、审批流程、异常处理、联系方式

如果用户只问“在哪里申请”，则优先保留申请入口相关句子。

第三层：限制每篇文档 Token 配额

每篇文档最多占用一定 Token，避免单篇文档挤占所有上下文空间。

2. Prompt 模板精简

优化前 Prompt 中存在大量固定说明，例如：

你是一个专业、严谨、友好、乐于助人的企业知识库助手……
请根据以下资料回答用户问题……
如果资料中没有答案，请不要编造……
请分步骤回答……
请保持语气自然……

这些说明并非没有价值，但每次都完整发送，会造成固定 Token 开销。

我们做了两件事：

1. 将冗余指令压缩成更短的系统提示；
2. 对不同类型问题使用不同 Prompt，而不是统一大模板。

例如，对于事实查询类问题，只保留：

仅依据资料回答；资料不足时说明无法确认；答案简洁。

对于流程类问题，再增加：

如资料包含步骤，请按步骤列出。

3. 实测效果

可以看到，输入 Token 减少近一半，但答案满意度基本保持稳定。

这说明一个关键事实：

对 AI 搜索来说，并不是上下文越多越好，而是相关上下文越准越好。

六、优化三：分级路由，让不同问题走不同链路

并不是所有搜索问题都需要完整 RAG + 大模型生成。

用户问题大致可以分为几类：

优化前，所有问题都走同一条完整链路，显然浪费。

1. Query 分类器

我们增加了一个轻量 Query 分类器，用于判断问题类型。

实现方式有三种：

1. 规则匹配；
2. 小模型分类；
3. Embedding + 分类标签相似度。

生产环境中采用的是“规则 + 小模型”的混合方式：

• 高频明确问题用规则；
• 不确定问题用小模型；
• 低置信度再进入标准链路。

2. 分级路由策略

Query
  ↓
规则判断
  ↓
轻量分类器
  ↓
选择链路：
  - 缓存直接返回
  - 关键词搜索返回
  - 短 RAG
  - 标准 RAG
  - 强模型 RAG

不同链路对应不同成本。

3. 实测效果

分级路由上线后，请求分布如下：

也就是说，真正需要强模型处理的问题只有约 6%。

这项优化显著降低了大模型调用成本，也提升了响应速度。

七、优化四：调整召回与重排序策略

RAG 效果差，很多时候不是生成模型的问题，而是召回和排序的问题。

但召回和 Rerank 也会产生成本。

1. TopK 不是越大越好

优化前采用：

向量召回 Top 20
Rerank Top 20
最终取 Top 8

看似稳妥，但实际分析发现：

• 大多数有效答案出现在 Top 5；
• Top 10 之后的内容相关性明显下降；
• Rerank Top 20 的计算成本较高；
• Top 8 拼接上下文容易引入噪声。

因此我们调整为动态 TopK。

2. 动态 TopK 策略

根据 Query 类型和召回置信度决定 TopK。

3. 跳过 Rerank

如果向量召回第一名分数明显高于第二名，并且文档类型可靠，可以跳过 Rerank。

例如：

Top1 score = 0.89
Top2 score = 0.68
差值 = 0.21

这类情况往往说明用户问题非常明确，可以直接使用 Top1 或 Top3。

4. 实测效果

这说明召回策略的精细化不仅能降本，还能减少噪声，提高答案稳定性。

八、优化五：文档切片策略重构

文档切片是很多 AI 搜索系统早期最容易忽略的问题。

如果切片过短：

• 语义不完整；
• 召回片段数量增加；
• 上下文拼接成本升高；
• 模型容易断章取义。

如果切片过长：

• 召回不精准；
• 单片段 Token 过多；
• 无关内容混入上下文。

1. 优化前切片方式

原方案主要按照固定长度切片：

每 500 字切一段，重叠 100 字

这种方式简单，但对结构化文档不友好。

例如制度类文档通常包含：

一、适用范围
二、申请条件
三、申请流程
四、注意事项
五、附件

固定长度切片可能把“申请条件”和“申请流程”切在一起，或者把流程步骤拆断。

2. 优化后切片方式

我们改为结构化切片：

• 优先按标题层级切；
• 保留章节标题；
• 对表格单独处理；
• 对流程步骤保持完整；
• 对 FAQ 保持问答对完整；
• 对超长章节再做二级切分。

3. 元数据增强

每个切片增加元数据：

{
  "doc_id": "policy_001",
  "title": "年假管理制度",
  "section": "申请流程",
  "doc_type": "制度",
  "department": "人力资源部",
  "version": "2024-09",
  "effective_date": "2024-10-01"
}

这些元数据可用于：

• 过滤过期文档；
• 优先召回权威文档；
• 按部门或权限过滤；
• 提高重排序准确率；
• 控制缓存失效。

4. 实测效果

切片优化不是立刻降低模型单价，但它能提升召回质量，从而间接减少上下文数量和错误回答。

切片策略优化后，系统更容易用较少上下文回答问题。

九、优化六：控制输出长度，避免“话痨式回答”

很多 AI 搜索系统还有一个隐藏成本：答案太长。

用户只是问：

报销单在哪里提交？

模型却回答：

您可以按照以下步骤进行报销申请：
1. 登录公司统一门户……
2. 在首页找到财务系统……
3. 点击费用报销……
4. 填写报销单……
5. 上传附件……
6. 提交审批……
此外，您还需要注意……

如果用户只是要入口，过长回答不仅增加 Token 成本，还影响体验。

1. 按问题类型控制输出

我们按类型设置输出长度：

2. Prompt 中加入长度约束

例如：

请用不超过 120 字回答，优先给出直接结论。

或：

如涉及流程，请最多列出 5 个关键步骤。

3. 实测效果

输出变短并没有降低用户满意度，反而让简单问题更清晰。

十、优化七：日志降采样与可观测性分层

AI 搜索上线后，很多团队会记录完整链路日志：

• 用户问题；
• Prompt；
• 召回片段；
• Rerank 分数；
• 模型输出；
• Token 用量；
• 用户反馈；
• 延迟数据。

这些日志对调试非常有价值，但如果全量长期保存，存储成本和合规风险都会增加。

1. 分层日志策略

我们将日志分为三类：

2. 采样规则

• 错误请求：100% 保存；
• 用户差评：100% 保存；
• 高成本请求：100% 保存；
• 普通请求：按 3%～10% 采样；
• 命中缓存请求：只保留指标日志。

3. 实测效果

日志降采样不会直接影响模型调用费用，但对长期运营非常重要。

十一、综合优化结果

经过多轮灰度和生产验证，整体结果如下：

需要说明的是，成本下降不是由某一个优化点单独完成的，而是多项策略叠加的结果。

其中贡献较大的三项是：

1. 语义缓存；
2. 上下文 Token 压缩；
3. 分级路由。

十二、AI 搜索降本的推荐优先级

如果你的团队也在做 AI 搜索降本，可以按照以下优先级推进。

第一优先级：先做监控

没有监控，就不知道钱花在哪里。

至少要统计：

• 每次请求输入 Token；
• 每次请求输出 Token；
• 模型调用次数；
• 缓存命中率；
• 召回 TopK；
• Rerank 耗时；
• 单次请求成本；
• 各链路请求占比；
• 用户满意度反馈。

第二优先级：做缓存

缓存是最容易见效的方式，尤其适合企业知识库、客服问答、政策查询等高重复场景。

建议同时做：

• 精确缓存；
• 语义缓存；
• 热点问题预生成；
• 文档更新后的缓存失效机制。

第三优先级：压缩上下文

Token 是 RAG 成本的核心变量之一。

可以从以下方向优化：

• 减少召回片段数量；
• 去重相似片段；
• 合并同文档片段；
• 提取相关句子；
• 精简 Prompt；
• 按问题类型控制上下文长度。

第四优先级：分级路由

不要让所有问题都走最贵链路。

建议至少划分：

• 缓存命中；
• 直接答案；
• 简单 RAG；
• 标准 RAG；
• 强模型 RAG；
• 人工兜底。

第五优先级：优化文档切片

切片质量决定召回质量，召回质量决定上下文成本和答案质量。

建议避免纯固定长度切片，优先采用结构化切片。

十三、几个容易踩的坑

1. 只看模型单价，不看 Token

有些模型单价低，但需要更长 Prompt、更长输出或多轮调用，最终成本未必低。

2. 盲目降低 TopK

TopK 降得太狠，可能导致召回不足，答案质量下降。应该结合召回置信度动态调整。

3. 语义缓存阈值过低

阈值过低会导致错误命中，尤其是政策类、权限类、金额类问题，必须谨慎。

4. Prompt 过度压缩

Prompt 太短可能导致模型不遵守约束，比如编造答案、不引用资料、不说明不确定性。

5. 只降成本，不看体验

AI 搜索最终是给用户用的。成本下降如果伴随满意度明显下降，长期看并不划算。

十四、结论

AI 搜索降本的关键，不是简单换一个更便宜的大模型，而是对完整链路进行系统性优化。

从生产环境实测结果看，比较有效的路径是：

监控成本结构
  ↓
语义缓存减少重复调用
  ↓
压缩上下文降低 Token
  ↓
分级路由避免过度计算
  ↓
优化召回和 Rerank
  ↓
重构文档切片
  ↓
日志分层与长期治理

最终，在不明显牺牲答案质量的前提下，AI 搜索整体成本下降约 48%～57%，平均响应时间也有明显改善。

对企业来说，AI 搜索真正进入生产环境之后，拼的不只是模型能力，而是工程能力、数据治理能力和成本控制能力。

一句话总结：

AI 搜索降本的本质，是把昂贵的大模型能力用在真正需要它的地方。