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

过去一年，越来越多企业把“AI搜索”从概念验证推进到生产环境：客服知识库、企业内部文档检索、销售资料问答、投研报告分析、研发规范查询、工单辅助处理……这些场景看起来都很适合用大模型加持搜索，但真正上线后，团队很快会遇到一个现实问题：

AI搜索效果能不能稳定？响应能不能快？更关键的是：成本能不能降下来？

很多项目在 Demo 阶段成本并不明显，因为访问量小、文档量少、调用频率低。但一旦进入生产环境，成本会以非常直观的方式暴露出来：Embedding 成本、向量库成本、重排模型成本、大模型推理成本、缓存成本、日志与监控成本、人工标注与评测成本，都会成为长期支出。

本文结合一个典型生产环境中的 AI 搜索系统改造实践，系统拆解成本来源，并分享一套可落地的降本方案。重点不是“为了省钱牺牲效果”，而是在保证搜索质量和用户体验的前提下，把不必要的计算浪费砍掉。

一、AI搜索的成本到底花在哪里？

一个常见的 AI 搜索系统，大致包含以下链路：

1. 用户输入问题；
2. 对问题进行改写、意图识别或 Query 扩展；
3. 使用 Embedding 模型将问题向量化；
4. 从向量数据库中召回相关文档；
5. 结合关键词搜索、规则召回进行混合检索；
6. 使用重排模型对候选结果排序；
7. 将 Top K 文档拼接进 Prompt；
8. 调用大模型生成最终回答；
9. 返回答案，并附带引用来源；
10. 记录日志，用于后续评测和优化。

这套流程看起来很合理，但每一步都可能带来成本。

1. Embedding 成本

Embedding 是 AI 搜索的基础。无论是文档入库，还是用户提问，都需要把文本转换成向量。

成本主要来自两个部分：

• 离线文档向量化成本：文档越多、切片越细，成本越高；
• 在线 Query 向量化成本：用户每问一次，基本都要调用一次 Embedding。

如果系统采用多路召回，例如对原始问题、改写问题、扩展问题分别做向量召回，那么一次请求可能产生多次 Embedding 调用。

2. 向量数据库成本

向量库成本不仅是存储，还包括查询计算、索引维护、扩容和高可用。

当文档切片过细时，向量数量会迅速膨胀。比如 10 万篇文档，如果每篇切成 20 个 chunk，就是 200 万条向量；如果每条向量维度较高，存储和查询压力都会明显提升。

3. 重排模型成本

很多系统上线后会发现，单纯向量召回的效果不够稳定，于是引入 Rerank 模型。Rerank 对相关性提升很明显，但代价也不小。

假设每次从向量库召回 50 条候选，再送入重排模型进行打分，那么每次搜索都要处理 50 对 Query-Document。如果访问量增长，Rerank 会成为非常明显的成本中心。

4. 大模型生成成本

这是最容易被看到的成本，也是最容易失控的部分。

大模型调用成本与输入输出 Token 数高度相关。AI搜索为了提升回答准确性，往往会把多个文档片段塞进 Prompt。Top K 越大、chunk 越长，输入 Token 越多；如果回答风格要求“详细解释”，输出 Token 也会增多。

很多系统为了“稳”，默认把 8 到 10 个文档片段全部拼进去，结果是：模型并没有用完这些上下文，但成本已经实实在在产生了。

5. 评测与人工运营成本

AI搜索不是一次上线就结束的系统。生产环境中需要持续评测：

• 用户问题是否被正确理解；
• 召回文档是否准确；
• 回答是否引用了正确资料；
• 是否存在幻觉；
• 是否需要新增知识；
• 是否有热点问题可以缓存。

这些工作如果完全依赖人工，会产生持续运营成本。

二、生产环境基线：未优化前的成本结构

以下是一组脱敏后的生产环境数据，用于说明典型 AI 搜索系统的成本结构。

业务场景是企业内部知识库问答，包含产品手册、操作规范、售后文档、培训资料和历史工单。系统日均请求量约 8,000 次，工作日高峰可达 12,000 次。

优化前架构

• 文档总量：约 12 万篇；
• 文档切片数量：约 185 万个 chunk；
• Embedding 模型：通用向量模型；
• 向量维度：1536；
• 检索方式：纯向量召回；
• 召回数量：Top 80；
• Rerank 输入：Top 80 全量重排；
• 最终进入大模型上下文：Top 8；
• 平均 Prompt 输入：约 7,500 tokens；
• 平均输出：约 850 tokens；
• 缓存策略：仅缓存完全相同问题；
• 平均响应时间：5.8 秒；
• P95 响应时间：11.6 秒。

成本占比

从数据可以看出，大模型生成成本和 Rerank 成本占了接近 80%。因此，降本的优先级不能只盯着向量库或 Embedding，而应该从整体链路看。

三、降本思路：不是少用模型，而是少做无效计算

很多团队一提到降本，第一反应是：

• 换便宜模型；
• 减少上下文；
• 降低召回数量；
• 缩短回答长度。

这些方法当然有效，但如果粗暴执行，搜索效果很容易下降。真正可持续的降本，核心是四个字：

精准计算。

也就是说，把计算资源花在真正需要的请求上，而不是每个请求都走最重的链路。

我们将 AI 搜索请求分成四类：

1. 简单事实查询：例如“XX系统登录地址是什么？”
   这类问题不需要复杂推理，也不需要长上下文。

2. 明确文档定位查询：例如“售后退货流程第几步需要审批？”
   这类问题重点是检索准确，不一定需要大模型长篇生成。

3. 综合总结类查询：例如“比较A方案和B方案适用场景”。
   这类问题需要多个文档支撑，适合使用较强模型。

4. 低价值或不可回答查询：例如闲聊、无权限问题、知识库不存在内容。
   这类请求不应该进入昂贵链路。

如果所有问题都走“向量召回 Top80 + Rerank Top80 + 大模型长上下文生成”，成本一定高，而且并不必要。

四、实测降本方案一：文档切片优化，减少向量膨胀

文档切片是很多 AI 搜索系统的隐性成本源头。

优化前，我们采用固定长度切片，每个 chunk 约 500 字，重叠 100 字。这种方式实现简单，但带来几个问题：

• 标题、表格、步骤说明被切断；
• 同一段内容重复出现在多个 chunk；
• 重叠部分造成向量数量增加；
• 检索结果中经常出现语义不完整片段。

改造方法

我们改用“结构化切片 + 语义边界切片”：

1. 优先按标题层级切分；
2. 保留文档路径，例如“产品手册 > 账号管理 > 权限配置”；
3. 表格单独处理，转成可检索的文本描述；
4. 对过长段落再进行二次切分；
5. 减少无意义重叠；
6. 对模板页、页眉页脚、免责声明进行清洗；
7. 对重复内容进行 SimHash 去重。

改造效果

切片优化并不是简单减少 chunk，而是提高每个 chunk 的信息密度。经过人工抽样评测，召回准确率没有下降，反而略有提升，因为检索结果更完整了。

五、实测降本方案二：混合检索替代纯向量召回

纯向量召回适合语义相近的问题，但对于包含产品型号、错误码、版本号、字段名、接口名的问题，关键词检索往往更可靠。

例如：

“E3027 报错怎么处理？”

如果纯向量召回，模型可能会召回语义相似的“系统报错处理流程”，但关键词搜索可以直接命中包含 E3027 的文档。

改造方法

我们引入混合检索：

• BM25 关键词召回 Top 30；
• 向量召回 Top 40；
• 规则召回 Top 10，例如错误码、产品型号、接口名；
• 合并去重后进入候选池；
• 根据 Query 类型动态调整各路权重。

对于包含明显关键词的问题，提高 BM25 权重；对于自然语言描述型问题，提高向量召回权重。

改造效果

混合检索带来的价值不仅是效果提升，更重要的是减少了后续重排和生成的压力。因为候选质量变高，系统不需要盲目召回大量向量结果。

六、实测降本方案三：动态 Rerank，而不是全量 Rerank

优化前，每次请求都会把 Top 80 候选全部送入 Rerank。这是非常典型的浪费。

事实上，有些查询在检索阶段已经很明确。例如关键词完全匹配错误码、文档标题高度相关、用户问题与某个 FAQ 高度一致，此时没有必要重排 80 条。

改造方法

我们设计了动态 Rerank 策略：

1. 如果关键词强匹配且候选分数明显领先，只 Rerank Top 10；
2. 如果向量召回结果分数集中，说明不确定性高，Rerank Top 50；
3. 如果 Query 被识别为 FAQ 类问题，优先匹配 FAQ 库，不走重排；
4. 如果候选结果质量低，直接返回“未找到可靠资料”，避免强行生成；
5. 对历史高频 Query 的 Rerank 结果进行缓存。

改造效果

这一步对成本影响非常明显。很多系统的 Rerank 成本高，不是因为模型太贵，而是因为候选数量设置过于保守。

七、实测降本方案四：上下文压缩，减少大模型输入 Token

AI搜索中最贵的部分通常是大模型输入输出。要降低成本，必须控制 Prompt 长度。

但“少塞文档”并不等于“降低质量”。关键是只把真正有用的信息送给模型。

改造前问题

优化前，我们默认取 Rerank 后 Top 8 文档，每个 chunk 原样拼接。这会带来几个问题：

• 多个 chunk 内容重复；
• 有些 chunk 只部分相关；
• 文档中包含大量无关说明；
• Prompt 中引用格式占用较多 Token；
• 用户问题简单时也使用长上下文。

改造方法

我们采用四种压缩策略：

1. 动态 Top K

根据问题复杂度选择上下文数量：

• FAQ 类：Top 1-2；
• 单文档定位类：Top 2-3；
• 多文档综合类：Top 5-6；
• 高风险问题：宁可少答，也不塞无关文档。

2. Chunk 内句子级筛选

不是整个 chunk 都送入模型，而是先抽取与 Query 最相关的句子或段落。

3. 去重与合并

如果多个 chunk 来自同一文档相邻位置，就合并为一个上下文块，避免重复标题和元信息。

4. 引用信息简化

保留必要来源，例如文档标题、章节、链接，不再重复长路径。

改造效果

这里有一个关键点：输入 Token 降低后，答案可用率并没有下降，反而略有提升。原因是模型看到的信息更干净，干扰更少。

八、实测降本方案五：模型分层，不同问题用不同模型

不是所有问题都需要最强大模型。

生产环境中，我们将模型调用分成三层：

第一层：轻量模型

用于：

• Query 分类；
• 意图识别；
• 是否需要检索；
• 问题安全判断；
• 简单 FAQ 改写。

这类任务不需要复杂推理，可以使用小模型或本地模型完成。

第二层：中等模型

用于：

• 常规知识问答；
• 简单总结；
• 单文档答案生成；
• 标准客服回复。

这是系统中的主力模型，追求性价比。

第三层：强模型

用于：

• 多文档综合分析；
• 高价值客户问题；
• 需要复杂推理的问题；
• 低置信度情况下的兜底回答。

强模型只服务少量复杂请求，而不是全量流量。

分层策略效果

优化后，强模型调用量下降约 64%，整体回答质量保持稳定。对于企业知识库场景，用户大多数问题并不需要复杂创造性生成，而是需要准确、可靠、可引用。

九、实测降本方案六：缓存不是简单缓存问题，而是缓存链路结果

很多团队只做“问题完全一致缓存”，但实际命中率很低。因为用户表达稍有不同，缓存就失效。

例如：

• “怎么重置密码？”
• “密码忘了怎么办？”
• “账号密码如何找回？”
• “登录密码重置流程是什么？”

这些问题语义相近，如果只做字符串匹配，就无法命中同一个缓存。

改造方法

我们做了三层缓存：

1. Query 归一化缓存

对用户问题进行标准化，例如去除语气词、统一术语、识别同义表达。

2. 语义缓存

将 Query 向量化后，与历史问题向量比较。如果相似度高，并且答案仍在有效期内，直接返回缓存答案。

3. 中间结果缓存

不仅缓存最终答案，还缓存：

• Query 改写结果；
• Embedding 结果；
• 召回结果；
• Rerank 排序结果；
• Prompt 构造结果。

这样即使最终答案不能直接复用，也可以减少部分链路成本。

缓存效果

缓存对高频内部知识库非常有效，尤其是制度流程、操作手册、错误码处理等问题。需要注意的是，缓存必须考虑文档版本和权限，否则容易返回过期或越权答案。

十、实测降本方案七：先判断“能不能答”，再决定“怎么答”

AI搜索常见浪费之一，是对本来无法回答的问题也走完整链路。

例如：

• 用户问知识库中不存在的问题；
• 用户没有权限查看相关文档；
• 问题过于模糊；
• 用户在闲聊；
• 用户要求生成与知识库无关的内容。

优化前，系统会努力检索、重排、拼 Prompt，然后让大模型生成一个看似合理但不可靠的回答。这不仅浪费成本，还增加幻觉风险。

改造方法

我们加入了前置判断：

1. 是否为知识库相关问题；
2. 是否包含足够信息；
3. 是否命中用户权限范围；
4. 检索结果置信度是否达标；
5. 是否需要追问用户补充信息。

如果置信度不足，系统不再强行回答，而是返回：

“当前知识库中没有找到可靠依据，建议补充产品名称、版本号或具体错误信息。”

改造效果

• 无效请求减少约 12%；
• 幻觉投诉下降约 31%；
• 大模型无效生成成本明显下降；
• 用户对“无法回答”的接受度反而提升。

在生产环境中，“不知道”比“编一个答案”更有价值。

十一、整体优化结果：成本、速度、质量三项对比

经过上述改造，系统运行两周后，我们对同等业务流量进行了对比。

核心指标对比

最终，整体成本下降约 61%，响应速度提升约 50%。更重要的是，搜索质量没有明显下降，部分指标还有提升。

质量评测结果

我们使用 1,200 条真实用户问题进行人工评测，评测维度包括：

• 召回是否命中正确文档；
• 回答是否正确；
• 是否引用可靠来源；
• 是否存在幻觉；
• 表达是否清晰；
• 是否解决用户问题。

这说明降本并不必然导致质量下降。恰当的链路优化，反而会让模型更聚焦、更稳定。

十二、AI搜索降本的优先级建议

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

第一优先级：控制大模型 Token

这是最直接、最有效的降本点。

建议：

• 动态 Top K；
• 压缩上下文；
• 删除无效元信息；
• 控制回答长度；
• 简单问题不用长 Prompt；
• 输出格式尽量简洁。

第二优先级：减少 Rerank 数量

Rerank 不要默认全量处理。

建议：

• 根据召回置信度动态决定候选数量；
• 高频问题缓存 Rerank 结果；
• FAQ 命中后跳过 Rerank；
• 对强关键词问题减少候选规模。

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

切片决定了召回质量和向量规模。

建议：

• 不要盲目固定长度切片；
• 保留标题和层级；
• 清洗重复内容；
• 对表格做结构化处理；
• 控制 chunk 数量；
• 定期分析低命中文档。

第四优先级：建立模型路由

不同请求使用不同模型。

建议：

• 小模型做分类；
• 中等模型处理主流问答；
• 强模型处理复杂任务；
• 无法回答时不要强行生成；
• 高价值用户或关键场景可使用更强模型。

第五优先级：做语义缓存

缓存不只是缓存最终答案。

建议：

• 建立语义相似问题缓存；
• 缓存 Embedding；
• 缓存召回与重排结果；
• 绑定文档版本；
• 严格处理权限变化。

十三、容易踩的坑

1. 只看成本，不看质量

如果降本后用户找不到答案，最终会产生更高的人工客服成本或业务损失。AI搜索降本必须配合评测体系，不能只看调用账单。

2. 只调模型，不改数据

很多搜索问题不是模型问题，而是文档问题。文档重复、过期、结构混乱、标题缺失，会直接导致检索不准。

3. Prompt 越长越安心

长 Prompt 不等于好答案。上下文过多会增加干扰，模型可能引用错误片段。真正有效的是“高相关、低噪声”的上下文。

4. 缓存忽略权限

企业知识库必须重视权限。如果缓存答案没有绑定用户权限、部门、文档版本，就可能产生严重的信息泄露风险。

5. 没有离线评测集

没有评测集，就无法判断优化是变好还是变坏。建议从真实搜索日志中抽样，构建覆盖高频、长尾、复杂、多轮、无答案等类型的问题集。

十四、结论：AI搜索降本的本质是系统工程

AI搜索的成本不是某一个模型决定的，而是由整个链路共同决定的。真正有效的降本，不是简单换便宜模型，也不是粗暴减少召回数量，而是围绕“请求是否值得计算、应该计算多少、用什么模型计算、计算结果能否复用”进行系统优化。

从生产环境实测结果看，以下策略最有效：

1. 优化文档切片，减少无效向量；
2. 使用混合检索，提高候选质量；
3. 动态 Rerank，避免全量重排；
4. 压缩上下文，降低输入 Token；
5. 模型分层路由，让强模型只处理复杂问题；
6. 语义缓存与中间结果缓存，提高复用率；
7. 前置置信度判断，避免无效生成。

最终目标不是“让 AI 搜索变得最便宜”，而是让它在生产环境中具备可持续性：成本可控、效果稳定、响应足够快、风险可管理。

对于企业来说，AI搜索真正进入生产阶段后，拼的不再是 Demo 有多惊艳，而是系统能否长期稳定运行。谁能把成本、质量和效率三者平衡好，谁才能真正把 AI 搜索做成业务基础设施。