AI搜索 如何降低成本｜附配置文件

在过去一年里，AI 搜索逐渐从“尝鲜功能”变成了很多产品的标配能力：企业知识库问答、文档检索、客服机器人、投研助手、代码搜索、内容推荐、销售线索分析等场景，都开始采用“搜索 + 大模型”的方案来提升信息获取效率。

但很多团队在落地 AI 搜索时，很快会遇到一个现实问题：效果确实不错，成本也确实不低。

尤其是在使用大模型 API、向量数据库、Embedding 模型、Rerank 模型、长上下文模型以及多轮对话能力之后，请求链路越来越长，调用组件越来越多，单次查询成本也随之上升。如果没有合理设计，AI 搜索很容易从“提升效率的工具”变成“持续烧钱的系统”。

本文将围绕 AI 搜索的典型架构，系统拆解成本来源，并给出一套可落地的降本方案。文末附一份示例配置文件，便于直接参考和改造。

一、AI 搜索为什么容易成本高？

传统搜索的成本主要集中在索引构建、存储和查询计算上，通常可以通过倒排索引、缓存、分片、副本等方式控制成本。

而 AI 搜索的成本结构更复杂，常见链路如下：

用户问题
  ↓
问题改写 / 意图识别
  ↓
Embedding 向量化
  ↓
向量召回 / 关键词召回 / 混合召回
  ↓
Rerank 精排
  ↓
上下文拼接
  ↓
大模型生成答案
  ↓
引用来源 / 追问推荐 / 结果校验

这个链路中，几乎每一步都可能产生成本。

常见成本包括：

1. Embedding 成本
   文档入库时需要生成向量，用户查询时也需要生成向量。如果文档量大、更新频繁，Embedding 成本会持续增加。

2. 向量数据库成本
   向量索引需要存储和计算资源。高维向量、大规模数据、多副本、高并发查询都会推高成本。

3. Rerank 成本
   Rerank 模型通常按请求或 token 收费。如果每次都对几十甚至上百条候选文档精排，成本会明显上升。

4. 大模型生成成本
   这是最容易失控的部分。上下文越长、模型越大、输出越多，费用越高。

5. 多轮对话成本
   如果每轮对话都携带完整历史记录和大量文档上下文，token 消耗会迅速累积。

6. 低质量请求成本
   很多用户问题其实不需要 AI 搜索，例如简单导航、闲聊、无效输入、重复提问。如果全部进入完整链路，会浪费大量预算。

因此，AI 搜索降本的核心不是简单地“换便宜模型”，而是要重新设计请求链路，让不同复杂度的问题走不同的处理路径。

二、AI 搜索降本的基本原则

要有效降低 AI 搜索成本，可以遵循以下几个原则。

1. 能不用大模型，就不用大模型

大模型是能力最强的一环，也是最昂贵的一环。很多请求并不需要生成式回答。

例如：

• 用户搜索一个明确的文档标题；
• 用户输入产品名称，希望找到对应说明书；
• 用户只是查询某个固定字段；
• 用户问题可以由 FAQ 直接命中；
• 用户输入无意义内容或非常短的关键词。

这些场景可以优先使用传统搜索、规则匹配、FAQ 命中、缓存命中等方式解决。只有当结果不确定、需要总结、需要跨文档综合时，再调用大模型。

2. 先召回，再判断是否需要生成

很多 AI 搜索系统会默认在每次查询后调用大模型生成答案。但事实上，有些搜索结果已经足够清楚。

例如用户搜索“报销流程 PDF”，系统直接返回相关文档即可，不一定需要生成一段解释。

可以在召回之后增加一个判断：

• 如果命中文档标题高度相关，直接返回搜索结果；
• 如果 FAQ 置信度很高，直接返回标准答案；
• 如果召回内容不足，再提示用户补充问题；
• 如果需要综合多个来源，再进入大模型生成。

3. 控制上下文长度

大模型生成答案时，最昂贵的部分往往不是输出，而是输入上下文。很多系统为了“保险”，会把大量检索结果全部塞进 prompt，导致 token 成本暴涨。

更合理的做法是：

• 控制候选文档数量；
• 控制每段文档长度；
• 对文档切片进行去重；
• 只保留与问题强相关的段落；
• 对长文档先做摘要；
• 使用结构化上下文，而不是原样堆砌全文。

4. 分层使用模型

不是所有任务都需要最强模型。

可以按任务复杂度分层：

这种分层策略通常比“一把梭调用最强模型”节省大量成本。

5. 尽可能复用计算结果

AI 搜索中有很多可缓存内容：

• 用户问题的 Embedding；
• 高频问题的检索结果；
• 高频问题的最终答案；
• 文档切片后的向量；
• 文档摘要；
• Rerank 结果；
• 权限过滤后的结果集合。

对于企业知识库、客服问答、政策查询等场景，重复问题非常多。缓存命中率一旦提升，成本会明显下降。

三、AI 搜索成本拆解

下面以一次典型 AI 搜索请求为例，拆解成本结构。

假设用户问题是：

“公司差旅报销需要哪些材料？流程是什么？”

系统可能执行以下步骤：

1. 对问题进行改写；
2. 生成查询向量；
3. 从向量库召回 30 个切片；
4. 从关键词索引召回 20 个切片；
5. 合并去重得到 40 个候选；
6. 使用 Rerank 对 40 个候选排序；
7. 取 Top 6 拼接上下文；
8. 调用大模型生成答案；
9. 生成引用来源；
10. 生成追问问题。

其中最主要的成本通常来自：

• 查询改写模型调用；
• Rerank 模型调用；
• 大模型输入 token；
• 大模型输出 token；
• 向量数据库查询资源。

如果每天有 10 万次查询，即使单次成本只有几分钱，月成本也可能达到数万元甚至更高。因此，降本必须从架构层面入手。

四、降本方案一：建立请求分流机制

AI 搜索的第一个降本点，是在入口处做请求分流。

可以将用户请求分为几类：

1. 无效请求
   如空输入、乱码、过短文本、明显无意义内容。
   处理方式：直接提示用户重新输入，不进入 AI 链路。

2. 导航型请求
   如“人事制度在哪里”“打开报销系统”。
   处理方式：返回链接或搜索结果，不调用生成模型。

3. 精确查询请求
   如“2024 年年假政策”“销售合同模板”。
   处理方式：传统搜索或混合搜索优先。

4. FAQ 请求
   如“试用期多久”“怎么重置密码”。
   处理方式：FAQ 高置信命中后直接返回标准答案。

5. 综合问答请求
   如“出差去北京三天，交通和住宿怎么报销？”
   处理方式：进入完整 RAG 链路。

6. 复杂推理请求
   如“对比新旧两版制度差异，并给出适用建议”。
   处理方式：使用更强模型和更长上下文，但需要限流。

一个简单的分流逻辑如下：

用户问题
  ↓
输入合法性检查
  ↓
缓存查询
  ↓
FAQ / 规则匹配
  ↓
传统搜索高置信命中？
  ↓
是否需要生成式回答？
  ↓
进入 RAG

通过这一步，很多请求可以在低成本路径中完成。

五、降本方案二：优化文档切片策略

文档切片会直接影响召回质量、上下文长度和生成成本。

如果切片过大：

• 每个切片包含太多无关内容；
• 拼接上下文时 token 消耗高；
• Rerank 成本增加；
• 回答容易引入噪声。

如果切片过小：

• 语义不完整；
• 召回结果碎片化；
• 需要拼接更多切片；
• 大模型难以理解上下文。

比较推荐的策略是：

• 普通知识库文档：每片 300～800 中文字；
• 制度类文档：按章节、条款切分；
• FAQ 文档：一问一答为一个切片；
• 技术文档：按标题层级和代码块切分；
• PDF 文档：清洗页眉页脚后再切片；
• 表格文档：尽量转为结构化记录。

同时要保留元数据，例如：

{
  "doc_id": "travel_policy_2024",
  "title": "2024年差旅报销制度",
  "section": "第三章 报销材料",
  "chunk_id": "travel_policy_2024_003",
  "source_url": "https://example.com/docs/travel-policy",
  "updated_at": "2024-05-12",
  "permission_group": "employee"
}

元数据有助于权限过滤、引用展示、增量更新和缓存管理，也能减少不必要的重复检索。

六、降本方案三：使用混合召回替代纯向量召回

纯向量召回擅长语义匹配，但并不总是最优。尤其是在以下场景中，关键词搜索可能更便宜、更准确：

• 产品型号；
• 合同编号；
• 文件标题；
• 人名；
• 地名；
• 日期；
• 法条编号；
• 错误码；
• 专有名词。

因此，推荐使用混合召回：

关键词召回 BM25
        ↓
      合并
        ↑
向量召回 Embedding

混合召回的好处是：

1. 提升召回率；
2. 降低对大规模向量查询的依赖；
3. 减少需要 Rerank 的候选数量；
4. 对精确匹配问题更友好；
5. 可在关键词高置信时直接返回结果。

例如，当用户输入“ERR_5023 怎么处理”时，关键词搜索可能比向量搜索更有效。系统可以先检查是否存在精确命中，如果有，就不必进入完整 RAG 链路。

七、降本方案四：控制 Rerank 的使用范围

Rerank 能显著提升检索质量，但也会增加成本。很多团队会默认对所有候选结果进行 Rerank，例如召回 100 条，全部精排。这种方式非常昂贵。

建议采用以下策略：

1. 限制 Rerank 候选数量

通常可以只对 Top 20～40 个候选进行 Rerank，而不是对所有召回结果排序。

2. 根据问题类型决定是否 Rerank

对于精确标题匹配、FAQ 高置信匹配、关键词完全命中等场景，可以跳过 Rerank。

3. 使用轻量级 Rerank

可以先使用规则分数、BM25 分数、向量相似度做第一层排序，只有分数接近或问题复杂时，再调用 Rerank 模型。

4. 设置 Rerank 阈值

如果最高相关度分数低于阈值，说明知识库可能没有答案。这时不应强行生成，而是提示用户：

“当前知识库中没有找到足够可靠的信息，请补充问题或联系管理员更新资料。”

这样不仅降低成本，也能减少幻觉。

八、降本方案五：减少大模型输入 token

大模型输入 token 是 AI 搜索的主要成本来源之一。要降低输入 token，可以从 prompt 和上下文两方面优化。

1. 精简系统提示词

很多 prompt 写得很长，包含大量重复说明。可以将通用规则固化在服务端逻辑中，而不是每次都塞给模型。

例如，不建议每次都输入几百字的冗长规则：

你是一个非常专业、非常严谨、非常善于总结的企业知识库助手……

可以改为更短的指令：

请仅根据给定资料回答；若资料不足，说明无法确认；回答需列出引用来源。

2. 控制上下文数量

不要默认塞入 Top 10 或 Top 20。很多情况下 Top 3～6 已经足够。

可根据 Rerank 分数动态选择：

• 分数很高：使用 Top 3；
• 分数一般：使用 Top 5；
• 分数分散：使用 Top 8；
• 分数过低：不生成答案。

3. 对上下文做压缩

对于长文档，可以在入库阶段预生成摘要。查询时先使用摘要，如果摘要不足，再读取原文片段。

也可以对召回片段做简单清洗：

• 删除页眉页脚；
• 删除目录；
• 删除重复标题；
• 删除无意义空行；
• 删除版权声明；
• 删除导航文本。

这些操作看似简单，但能显著减少 token 浪费。

九、降本方案六：优化输出长度

很多 AI 搜索回答默认输出很长，导致输出 token 成本增加，也影响用户阅读。

可以根据问题类型控制输出长度：

同时可以设置最大输出 token，例如：

generation:
  max_output_tokens:
    simple: 300
    normal: 700
    complex: 1200

另外，追问推荐、摘要扩展、格式美化等功能并非每次都需要开启。可以按需生成，而不是默认调用。

十、降本方案七：缓存高频请求

缓存是 AI 搜索降本最直接有效的手段之一。

可以设置多级缓存：

1. Query Cache

缓存用户原始问题或标准化问题对应的答案。

例如：

• “怎么报销差旅费”
• “差旅报销流程”
• “出差回来怎么报销”

这些问题可以通过问题归一化后命中同一个缓存。

2. Embedding Cache

同一个问题不需要重复生成 Embedding。可以对标准化后的 query 做哈希：

cache_key = sha256(normalized_query)

3. Retrieval Cache

对于高频问题，可以缓存召回结果和 Rerank 结果。

4. Answer Cache

对于稳定知识库，可以缓存最终答案。但要注意文档更新后需要失效。

缓存失效策略可以基于：

• 文档版本号；
• 更新时间；
• 权限范围；
• 用户角色；
• 业务线；
• 语言；
• 模型版本。

缓存命中时，可以直接返回结果，成本几乎可以忽略。

十一、降本方案八：文档增量更新，而不是全量重建

很多团队在更新知识库时，会重新处理全部文档，包括切片、Embedding、索引构建。这会造成大量浪费。

更合理的方式是增量更新：

1. 计算文档内容哈希；
2. 判断文档是否变化；
3. 只处理新增或变更文档；
4. 删除过期切片；
5. 更新对应向量；
6. 保留未变化文档的原有向量。

示例流程：

上传文档
  ↓
内容清洗
  ↓
计算 hash
  ↓
hash 是否变化？
  ├─ 否：跳过
  └─ 是：重新切片并更新索引

对于大规模企业知识库，这种方式可以显著降低 Embedding 成本和索引构建成本。

十二、降本方案九：设置预算、限流与降级

AI 搜索系统必须具备预算意识。

建议设置以下控制项：

1. 单用户每日调用上限
   防止异常用户或脚本刷接口。

2. 单租户预算上限
   多租户系统中尤其重要。

3. 复杂问题限流
   对需要强模型、长上下文、多轮推理的问题设置频率限制。

4. 低优先级请求降级
   高峰期可以从强模型降级到便宜模型。

5. 超过预算后切换搜索模式
   当预算耗尽时，保留传统搜索能力，关闭生成式回答。

降级并不代表不可用，而是让系统在成本压力下保持基本服务能力。

十三、降本方案十：做好可观测性

如果没有监控，降本只能靠猜。

AI 搜索应至少记录以下指标：

特别建议按“问题类型”统计成本。例如导航型、FAQ 型、综合问答型、复杂分析型分别消耗多少。这样才能精准定位成本黑洞。

十四、推荐的低成本 AI 搜索架构

一个相对稳妥的低成本架构如下：

用户请求
  ↓
输入清洗与问题标准化
  ↓
缓存查询
  ↓
意图识别 / 请求分流
  ↓
FAQ 与规则命中
  ↓
关键词搜索 + 向量搜索
  ↓
候选合并与去重
  ↓
条件触发 Rerank
  ↓
相关性阈值判断
  ↓
上下文压缩与拼接
  ↓
按复杂度选择模型
  ↓
生成答案 / 返回搜索结果
  ↓
记录成本与反馈

这套架构的核心思想是：

让简单问题走简单链路，让复杂问题才消耗复杂资源。

十五、附：AI 搜索降本配置文件示例

下面是一份可参考的 YAML 配置文件。实际使用时可以根据模型供应商、数据库、业务场景进行调整。

# ai_search_cost_optimization.yaml

app:
  name: ai-search
  environment: production
  default_language: zh-CN
  enable_cost_tracking: true

request:
  max_query_length: 500
  min_query_length: 2
  normalize:
    trim_space: true
    lowercase: true
    remove_extra_symbols: true
  invalid_query:
    enabled: true
    block_empty: true
    block_random_chars: true

budget:
  enabled: true
  currency: CNY
  monthly_limit: 30000
  daily_limit: 1500
  per_user_daily_limit: 100
  per_tenant_daily_limit: 5000
  alert_thresholds:
    - 0.5
    - 0.8
    - 0.95
  on_exceeded:
    mode: search_only
    disable_generation: true
    disable_rerank: true

cache:
  enabled: true
  query_cache:
    enabled: true
    ttl_seconds: 86400
    similarity_threshold: 0.92
  embedding_cache:
    enabled: true
    ttl_seconds: 2592000
  retrieval_cache:
    enabled: true
    ttl_seconds: 3600
  answer_cache:
    enabled: true
    ttl_seconds: 86400
    invalidate_on_document_update: true
  cache_key:
    include_user_role: true
    include_permission_group: true
    include_language: true
    include_doc_version: true

intent_routing:
  enabled: true
  model: small-classifier
  fallback: rag
  routes:
    invalid:
      action: reject
    navigation:
      action: return_links
      use_llm: false
    exact_search:
      action: search_only
      use_llm: false
    faq:
      action: return_faq_answer
      use_llm: false
      confidence_threshold: 0.88
    normal_qa:
      action: rag
      model_level: standard
    complex_analysis:
      action: rag
      model_level: advanced
      rate_limit_per_user_per_day: 10

document_processing:
  incremental_update: true
  content_hash: sha256
  skip_unchanged_documents: true
  chunking:
    strategy: semantic
    default_chunk_size_chars: 600
    chunk_overlap_chars: 80
    max_chunk_size_chars: 1000
    split_by_heading: true
    preserve_table_structure: true
    remove_header_footer: true
    remove_duplicate_lines: true
  metadata:
    required_fields:
      - doc_id
      - title
      - source_url
      - updated_at
      - permission_group
      - version

embedding:
  provider: example-provider
  model: text-embedding-economy
  dimension: 1024
  batch_size: 64
  cache_enabled: true
  normalize_vectors: true
  update_mode: incremental

retrieval:
  mode: hybrid
  keyword:
    engine: bm25
    top_k: 20
    boost_exact_match: 2.0
    boost_title_match: 1.5
  vector:
    engine: hnsw
    top_k: 30
    similarity_threshold: 0.55
  merge:
    strategy: weighted_score
    keyword_weight: 0.45
    vector_weight: 0.55
    deduplicate_by: chunk_id
    max_candidates: 40
  permission_filter:
    enabled: true
    filter_before_rerank: true

rerank:
  enabled: true
  provider: example-provider
  model: rerank-economy
  trigger:
    only_for_routes:
      - normal_qa
      - complex_analysis
    skip_if_exact_match_score_above: 0.9
    skip_if_faq_confidence_above: 0.88
  max_candidates: 30
  top_n: 8
  min_score_to_answer: 0.45

context:
  max_chunks:
    simple: 3
    normal: 5
    complex: 8
  max_context_tokens:
    simple: 1500
    normal: 3500
    complex: 7000
  compression:
    enabled: true
    remove_boilerplate: true
    use_precomputed_summary: true
    summary_fallback_to_original: true
  citation:
    enabled: true
    include_title: true
    include_source_url: true
    include_section: true

generation:
  enabled: true
  provider: example-provider
  models:
    simple: llm-small
    normal: llm-standard
    complex: llm-advanced
  routing:
    default: normal
    use_simple_model_if_context_tokens_below: 1500
    use_advanced_model_only_for_complex: true
  prompt:
    system: "请仅根据给定资料回答；若资料不足，说明无法确认；回答需列出引用来源。"
    include_chat_history: true
    max_history_turns: 3
  output:
    temperature: 0.2
    max_tokens:
      simple: 300
      normal: 700
      complex: 1200
    enable_followup_questions: false
    enable_markdown: true
  hallucination_control:
    refuse_if_no_evidence: true
    require_citation: true

rate_limit:
  enabled: true
  per_user:
    qps: 1
    burst: 5
  per_tenant:
    qps: 20
    burst: 100
  complex_analysis:
    per_user_daily_limit: 10

fallback:
  no_relevant_context:
    action: ask_clarification
    message: "当前知识库中没有找到足够可靠的信息，请补充问题或联系管理员更新资料。"
  model_error:
    action: return_search_results
  budget_exceeded:
    action: search_only
  high_latency:
    action: disable_rerank

observability:
  logging:
    enabled: true
    mask_sensitive_data: true
  metrics:
    enabled: true
    collect:
      - request_count
      - cache_hit_rate
      - embedding_calls
      - rerank_calls
      - input_tokens
      - output_tokens
      - estimated_cost
      - latency
      - no_answer_rate
      - user_feedback
  cost_report:
    enabled: true
    group_by:
      - tenant
      - user_role
      - route
      - model
      - document_collection
    export_interval: daily

十六、落地建议：从三个阶段逐步降本

如果你的 AI 搜索系统已经上线，不建议一次性大改。可以分阶段推进。

第一阶段：先做可观测性

先把每次请求的成本记录下来，包括：

• 是否命中缓存；
• 是否调用 Embedding；
• 是否调用 Rerank；
• 使用了哪个模型；
• 输入输出 token；
• 最终成本；
• 用户反馈。

没有数据，就无法判断哪里最浪费。

第二阶段：做请求分流和缓存

优先处理最容易见效的部分：

• 高频问题缓存；
• FAQ 高置信直接返回；
• 精确搜索不调用大模型；
• 无效请求拦截；
• 导航型请求返回链接。

这一阶段通常能快速降低 20%～50% 的成本。

第三阶段：优化检索与生成链路

进一步优化：

• 文档切片；
• 混合召回；
• Rerank 触发条件；
• 上下文 token 控制；
• 模型分层路由；
• 增量索引更新。

这一阶段会同时提升质量和降低成本。

结语

AI 搜索降本不是单点优化，而是一套系统工程。

真正有效的做法，不是简单选择更便宜的大模型，也不是盲目减少上下文，而是要围绕完整链路进行设计：入口分流、缓存复用、混合召回、精排控制、上下文压缩、模型分层、预算限流和成本监控。

最终目标是：

在不明显牺牲用户体验的前提下，让每一次昂贵的大模型调用都变得“值得”。

对于大多数业务来说，只要把“简单问题简单处理、复杂问题精细处理”的原则落地，AI 搜索的成本通常都能显著下降，同时系统稳定性和答案质量也会更好。