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

在大模型应用快速落地的过程中，“AI搜索”几乎成为企业知识库、智能客服、内部问答、内容检索、研发助手等场景的标配能力。相比传统关键词搜索，AI搜索能够理解语义、整合多源信息，并通过大模型生成自然语言答案，显著提升用户体验。

但与此同时，很多团队在上线AI搜索后很快会遇到一个现实问题：成本增长过快。

尤其当业务访问量上来以后，向量化、向量数据库、重排序模型、LLM推理、上下文拼接、日志存储、链路监控等环节都会持续产生费用。如果没有良好的架构设计和参数控制，AI搜索的成本可能会随着用户量线性甚至指数级增长。

本文将系统梳理AI搜索的成本来源，并给出一套可落地的降本方案，最后附上一份可参考的配置文件，帮助你在保证效果的前提下降低整体成本。

一、AI搜索的典型架构

在讨论成本之前，我们先看一下常见的AI搜索流程。

一个典型的AI搜索系统通常包含以下几个步骤：

1. 数据采集

   • 文档、网页、PDF、Markdown、数据库记录、工单、FAQ等。

2. 文本清洗

   • 去除HTML标签、重复内容、无效字符、广告信息、页眉页脚等。

3. 文本切分

   • 将长文档切分为适合向量化和召回的小片段。

4. Embedding向量化

   • 调用Embedding模型，把文本转换成向量。

5. 向量存储

   • 将文本片段和向量写入向量数据库。

6. 用户查询处理

   • 对用户问题进行改写、补全、意图识别或多轮上下文处理。

7. 查询向量化

   • 将用户问题转换成向量。

8. 向量召回

   • 从向量数据库中检索相关片段。

9. 重排序

   • 使用Rerank模型对候选结果进行精排。

10. 上下文拼接

    • 将相关文档片段拼接成Prompt上下文。

11. 大模型生成答案

    • 调用LLM生成最终回答。

12. 结果返回与日志记录

    • 返回答案，并记录请求、消耗、命中情况、用户反馈等。

从链路上看，AI搜索并不是“只调用一次大模型”这么简单，而是由多个模型、多种存储、多类计算资源组合而成。因此，降本也不能只盯着LLM单价，而应该从全链路优化。

二、AI搜索的主要成本来源

1. Embedding成本

Embedding成本主要发生在两个阶段：

• 文档入库时的批量向量化；
• 用户查询时的实时向量化。

如果知识库规模很大，例如数百万个文本片段，那么首次入库的Embedding成本会比较明显。但通常这属于一次性或低频成本。

相比之下，用户查询Embedding虽然单次成本低，但它属于高频实时调用。如果访问量较大，也会形成持续支出。

常见优化思路包括：

• 文档去重后再向量化；
• 增量更新，而不是全量重建；
• 对相同问题做查询缓存；
• 选择性价比更高的Embedding模型；
• 控制文本切片数量，避免无效片段过多。

2. 向量数据库成本

向量数据库成本主要来自：

• 存储成本；
• 内存成本；
• 索引构建成本；
• 查询计算成本；
• 高可用部署成本。

如果选择托管向量数据库，费用通常与向量数量、维度、索引类型、查询量有关。向量维度越高，存储和计算开销越大。

例如，同样存储1000万个片段，768维向量和1536维向量的资源消耗差异明显。如果业务不需要极高精度，使用较低维度的Embedding模型往往可以显著节省成本。

优化建议：

• 降低无效文档和重复文档；
• 合理选择向量维度；
• 对冷数据做归档；
• 将高频知识和低频知识分库；
• 使用混合检索减少纯向量检索压力；
• 根据业务规模选择本地部署或云托管。

3. Rerank重排序成本

Rerank模型通常用于提升搜索相关性。它会对召回结果逐条评分，然后重新排序。

例如，向量检索先返回Top 50，再用Rerank选出Top 5。这样效果可能会更好，但成本也会上升。因为Rerank的调用成本通常与“问题 × 候选文档数量”相关。

如果每次都对50个甚至100个候选片段做重排序，访问量大时成本非常可观。

优化建议：

• 限制Rerank候选数量；
• 只在低置信度场景启用Rerank；
• 对热门问题缓存Rerank结果；
• 先用轻量规则过滤，再进入Rerank；
• 根据业务重要程度分级使用Rerank。

4. 大模型生成成本

LLM成本通常是AI搜索系统中最显性的部分。它主要取决于：

• 输入Token数量；
• 输出Token数量；
• 模型单价；
• 请求次数；
• 是否使用高级推理模型；
• 是否开启长上下文。

AI搜索中最容易导致LLM成本上升的环节，是上下文拼接。

很多团队为了提高答案准确率，会把大量召回片段都塞进Prompt中。结果是输入Token暴涨，但有效信息并没有同步增加。更糟糕的是，过长的上下文可能引入干扰信息，反而降低回答质量。

优化建议：

• 控制Top K数量；
• 控制每个片段最大长度；
• 对片段进行摘要压缩；
• 使用小模型做初筛，大模型做最终回答；
• 根据问题复杂度动态选择模型；
• 限制最大输出长度；
• 对可直接回答的问题跳过LLM生成。

5. 缓存与日志成本

缓存本身是降本手段，但如果设计不当，也会产生额外成本。例如：

• 缓存粒度过细，命中率低；
• 缓存时间过长，结果过期；
• 存储大量无价值日志；
• 全量保存Prompt和上下文导致日志膨胀；
• 缺乏数据生命周期管理。

日志对于排查问题和优化效果非常重要，但并不意味着所有内容都要永久保存。

建议：

• 热门问题设置答案缓存；
• 查询Embedding缓存；
• 召回结果缓存；
• 对日志做分级存储；
• 敏感信息脱敏；
• 原始上下文保留短周期，聚合指标长期保存。

三、AI搜索降本的核心思路

AI搜索降本不是简单地“换便宜模型”，而是要做到：少算、算准、分层、缓存、监控。

四、少算：减少无效计算

1. 文档入库前去重

很多知识库成本高，问题不在模型，而在数据质量。

常见重复内容包括：

• 多个版本的相同文档；
• 网页中的导航栏、页脚、版权声明；
• FAQ中的重复问题；
• 自动生成的模板内容；
• 数据库中历史无效记录。

如果重复数据直接进入Embedding和向量库，不仅增加成本，还会影响召回质量。

建议在入库前做三层去重：

1. 精确去重

   • 对清洗后的文本计算Hash，相同Hash直接丢弃。

2. 近似去重

   • 使用SimHash、MinHash或文本相似度判断近似重复内容。

3. 业务去重

   • 按文档ID、版本号、发布时间等规则保留最新有效内容。

2. 合理切分文本

文本切片过小，会导致片段数量暴增，向量库成本上升；文本切片过大，又会导致召回不精准，Prompt成本增加。

通常建议：

• 普通知识库：每片300～800中文字符；
• 技术文档：每片500～1000中文字符；
• FAQ类内容：按问答对切分；
• 法律、合同、制度类文档：按条款或章节切分。

同时，切片重叠不宜过大。很多系统默认设置20%～30%的overlap，但对于结构化文档，可能10%以内就足够。

3. 查询预处理与拦截

不是所有用户输入都需要走完整AI搜索链路。

可以提前拦截以下情况：

• 空问题；
• 过短问题；
• 闲聊问题；
• 与业务无关的问题；
• 敏感或违规问题；
• 简单导航类问题，例如“怎么登录”“客服电话多少”。

对于高频简单问题，可以直接返回固定答案或FAQ结果，无需调用LLM。

这类策略看起来简单，但在真实业务中往往能节省大量成本。

五、算准：提高召回质量，减少上下文浪费

1. 使用混合检索

纯向量检索适合理解语义，但对专有名词、编号、错误码、产品型号等关键词并不总是稳定。

混合检索通常结合：

• BM25关键词检索；
• 向量语义检索；
• 元数据过滤；
• 业务规则排序。

例如，用户搜索“E1027支付失败”，关键词检索可能比向量检索更准确。将BM25和向量召回结合，可以减少无关片段进入后续Rerank和LLM环节。

2. 使用元数据过滤

很多知识库文档天然带有元数据，例如：

• 产品线；
• 地区；
• 语言；
• 时间；
• 权限；
• 文档类型；
• 用户角色；
• 部门；
• 标签。

如果不使用元数据过滤，系统可能在全库中召回，既慢又贵，还容易返回不相关内容。

例如，用户属于“华东销售部”，问题是“最新返利政策”，检索时就应该优先限制在：

region: east_china
department: sales
doc_type: policy
status: active

这样可以显著缩小搜索范围，提高准确性并降低后续成本。

3. 动态Top K

很多系统固定设置Top K，例如每次召回20条、Rerank后取5条。这个策略简单，但不够经济。

更好的方式是动态Top K：

• 查询非常明确时，召回少量片段；
• 查询模糊时，召回更多片段；
• 初始召回结果分数差距明显时，减少Rerank；
• 初始结果置信度低时，再扩大检索范围。

例如：

• 高置信度：Top 5召回，Top 3进入LLM；
• 中置信度：Top 20召回，Top 5进入LLM；
• 低置信度：Top 30召回，启用Rerank，Top 6进入LLM。

这样可以避免所有请求都走最高成本路径。

六、分层：不同问题使用不同模型

AI搜索系统中，并不是所有问题都需要最强大模型。

可以按照问题复杂度分层：

1. L0：规则直接回答

适用场景：

• 固定FAQ；
• 导航说明；
• 联系方式；
• 标准流程；
• 简单状态查询。

这类问题不需要LLM，直接返回模板答案。

2. L1：小模型回答

适用场景：

• 简单知识问答；
• 单文档摘要；
• 格式化信息抽取；
• 短文本改写。

小模型成本低、速度快，适合处理大部分轻量请求。

3. L2：中等模型回答

适用场景：

• 多文档综合；
• 一般业务解释；
• 简单推理；
• 用户意图不完全明确的问题。

这是AI搜索的主力层。

4. L3：高级模型回答

适用场景：

• 复杂推理；
• 高价值客户问题；
• 法律、金融、医疗等高风险场景；
• 需要严谨分析和多步骤判断的问题。

高级模型只应服务于少量高价值请求，而不是全量请求。

七、缓存：把重复问题的成本降到接近零

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

1. 查询归一化

用户可能用不同表达问同一个问题：

• “怎么重置密码？”
• “密码忘了怎么办？”
• “登录密码找不回来了”
• “如何找回账号密码？”

如果只按原始文本做缓存，命中率会很低。

可以做查询归一化：

• 去除标点；
• 繁简转换；
• 同义词替换；
• 意图识别；
• Embedding相似匹配；
• 生成标准问题。

这样可以把多个相似问题映射到同一个缓存键。

2. 分层缓存

建议至少设计四类缓存：

1. 查询Embedding缓存

   • 相同或相似问题不重复向量化。

2. 召回结果缓存

   • 热门问题直接复用检索结果。

3. Rerank结果缓存

   • 避免重复精排。

4. 最终答案缓存

   • 对稳定知识直接返回答案。

缓存时间需要结合知识更新频率设置。例如：

• 企业制度：缓存1～7天；
• 产品价格：缓存10分钟～1小时；
• 实时库存：不缓存或短缓存；
• 技术文档：缓存1～3天；
• FAQ：缓存7～30天。

八、Prompt优化：减少Token浪费

Prompt越长，成本越高。很多AI搜索项目中，Prompt存在大量冗余内容：

• 重复的角色设定；
• 过长的输出格式要求；
• 不必要的示例；
• 无关上下文；
• 重复文档片段；
• 没有压缩的历史对话。

优化Prompt可以从以下几方面入手：

1. 压缩系统提示词

系统提示词应该明确但不要臃肿。把长期规则沉淀到应用逻辑中，而不是每次都放进Prompt。

2. 控制历史对话

多轮对话中，不建议把完整历史全部传给模型。可以采用：

• 最近N轮对话；
• 对话摘要；
• 关键信息槽位；
• 用户当前意图。

3. 上下文去重

多个召回片段可能来自同一文档或相邻段落，应在进入Prompt前合并去重。

4. 限制输出长度

如果用户只需要简短答案，就不要允许模型输出长篇内容。可以根据场景设置：

• 简短问答：200～400字；
• 操作指南：500～800字；
• 报告总结：1000～2000字；
• 复杂分析：按需放宽。

九、监控：没有指标就没有降本

想要持续降低AI搜索成本，必须建立监控体系。

核心指标包括：

1. 成本指标

• 每次请求平均成本；
• 每日总成本；
• 每个用户平均成本；
• 每个业务线成本；
• Embedding成本；
• Rerank成本；
• LLM输入Token成本；
• LLM输出Token成本。

2. 效果指标

• 召回命中率；
• 用户点击率；
• 答案采纳率；
• 用户满意度；
• 无答案率；
• 人工转接率；
• 投诉率。

3. 性能指标

• 平均响应时间；
• P95响应时间；
• P99响应时间；
• 向量检索耗时；
• Rerank耗时；
• LLM生成耗时。

4. 缓存指标

• Embedding缓存命中率；
• 检索缓存命中率；
• 答案缓存命中率；
• 缓存过期率；
• 缓存污染率。

降本不能牺牲核心体验，因此需要同时观察成本和效果。如果成本下降了30%，但用户满意度下降了50%，那不是优化，而是业务损伤。

十、推荐的降本策略组合

如果你正在从零构建AI搜索，可以采用以下默认策略：

1. 文档入库前做清洗、去重、结构化解析；
2. 文本切片控制在500～800中文字符；
3. overlap控制在50～100字符；
4. 使用中低维Embedding模型；
5. 启用BM25 + 向量混合检索；
6. 默认召回Top 10～20；
7. 仅在必要时启用Rerank；
8. LLM上下文控制在3～6个片段；
9. 对简单FAQ走规则或缓存；
10. 对复杂问题使用更强模型；
11. 设置最大输出Token；
12. 对热门查询做答案缓存；
13. 每日统计Token与成本；
14. 每周分析低命中问题并优化知识库；
15. 每月清理无效向量和过期文档。

十一、AI搜索降本配置文件示例

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

app:
  name: ai-search-cost-optimized
  env: production
  language: zh-CN
  timezone: Asia/Shanghai

cost_control:
  enabled: true
  daily_budget_usd: 100
  monthly_budget_usd: 2500
  alert_thresholds:
    daily_usage_percent: 80
    monthly_usage_percent: 85
  fallback_when_budget_exceeded:
    enable_cache_only_mode: true
    disable_rerank: true
    use_small_model: true
    max_context_chunks: 3

document_ingestion:
  enabled: true
  source_types:
    - markdown
    - pdf
    - html
    - database
  cleaning:
    remove_html_tags: true
    remove_navigation: true
    remove_footer: true
    remove_empty_lines: true
    normalize_whitespace: true
  deduplication:
    exact_hash: true
    simhash: true
    similarity_threshold: 0.92
  chunking:
    strategy: semantic
    chunk_size_chars: 700
    chunk_overlap_chars: 80
    min_chunk_size_chars: 200
    max_chunk_size_chars: 1000
  incremental_update:
    enabled: true
    compare_by:
      - document_id
      - updated_at
      - content_hash

embedding:
  provider: openai_compatible
  model: text-embedding-3-small
  dimensions: 768
  batch_size: 64
  timeout_seconds: 30
  cache:
    enabled: true
    ttl_hours: 168
    key_strategy: normalized_text_hash
  retry:
    max_attempts: 3
    backoff_seconds: 2

vector_store:
  provider: qdrant
  collection: knowledge_base
  distance: cosine
  index:
    type: hnsw
    m: 16
    ef_construct: 100
  search:
    default_top_k: 15
    max_top_k: 30
    score_threshold: 0.45
    ef_search: 64
  metadata_filter:
    enabled: true
    fields:
      - department
      - product
      - region
      - doc_type
      - permission_level
      - status
  cold_data:
    archive_enabled: true
    archive_after_days: 180

keyword_search:
  enabled: true
  provider: elasticsearch
  bm25:
    k1: 1.2
    b: 0.75
  top_k: 20

hybrid_search:
  enabled: true
  strategy: weighted_sum
  weights:
    vector: 0.65
    keyword: 0.35
  merge_top_k: 20
  deduplicate_by: chunk_id

query_processing:
  normalize:
    enabled: true
    lowercase: true
    trim_space: true
    remove_punctuation: true
    synonym_replace: true
  intent_detection:
    enabled: true
    route_simple_faq: true
    route_chitchat: true
    route_sensitive: true
  query_rewrite:
    enabled: false
    use_model: small
    max_tokens: 128
  cache:
    enabled: true
    semantic_cache: true
    similarity_threshold: 0.88
    ttl_minutes: 1440

routing:
  levels:
    l0_rule:
      enabled: true
      scenarios:
        - faq
        - navigation
        - contact
        - simple_process
    l1_small_model:
      enabled: true
      max_context_chunks: 3
      max_input_tokens: 4000
      max_output_tokens: 512
    l2_standard_model:
      enabled: true
      max_context_chunks: 5
      max_input_tokens: 8000
      max_output_tokens: 1024
    l3_advanced_model:
      enabled: true
      require_conditions:
        - high_value_user
        - complex_reasoning
        - low_confidence
      max_context_chunks: 8
      max_input_tokens: 16000
      max_output_tokens: 2048

rerank:
  enabled: true
  provider: cohere_compatible
  model: rerank-multilingual-v3
  trigger:
    only_when_vector_score_below: 0.72
    only_when_query_length_above_chars: 8
  candidates_top_k: 20
  return_top_k: 5
  cache:
    enabled: true
    ttl_hours: 24

context_builder:
  max_chunks: 5
  max_chars_per_chunk: 900
  max_total_context_chars: 4000
  remove_duplicate_chunks: true
  merge_adjacent_chunks: true
  include_metadata:
    - title
    - source
    - updated_at
  compression:
    enabled: true
    trigger_when_context_chars_above: 3500
    strategy: extractive_summary

llm:
  provider: openai_compatible
  default_model: gpt-4o-mini
  models:
    small:
      name: gpt-4o-mini
      temperature: 0.2
      max_output_tokens: 512
    standard:
      name: gpt-4o
      temperature: 0.2
      max_output_tokens: 1024
    advanced:
      name: gpt-4.1
      temperature: 0.1
      max_output_tokens: 2048
  prompt:
    system_template: |
      你是企业知识库助手。请严格基于给定资料回答。
      如果资料不足，请明确说明“根据当前资料无法确认”，不要编造。
      回答应简洁、准确，并在必要时列出依据来源。
    answer_style:
      concise: true
      use_bullets: true
      cite_sources: true
  safety:
    refuse_when_no_context: true
    hallucination_guard: true

cache:
  answer_cache:
    enabled: true
    ttl_minutes: 1440
    semantic_match: true
    similarity_threshold: 0.9
    exclude_doc_types:
      - price
      - inventory
      - realtime_status
  retrieval_cache:
    enabled: true
    ttl_minutes: 720
  rerank_cache:
    enabled: true
    ttl_minutes: 1440

logging:
  enabled: true
  level: info
  store_prompt: false
  store_context: false
  store_answer: true
  anonymize_user: true
  retention_days:
    raw_request: 7
    aggregated_metrics: 365
  metrics:
    token_usage: true
    model_latency: true
    cache_hit_rate: true
    retrieval_score: true
    user_feedback: true

monitoring:
  enabled: true
  dashboards:
    - cost
    - latency
    - quality
    - cache
  alerts:
    high_cost_per_query:
      enabled: true
      threshold_usd: 0.05
    low_cache_hit_rate:
      enabled: true
      threshold_percent: 20
    high_no_answer_rate:
      enabled: true
      threshold_percent: 15
    p95_latency:
      enabled: true
      threshold_ms: 5000

evaluation:
  enabled: true
  test_set_path: ./eval/search_qa_set.jsonl
  schedule: weekly
  metrics:
    - recall_at_5
    - mrr
    - answer_correctness
    - citation_accuracy
    - user_satisfaction

十二、配置文件关键参数说明

1. chunk_size_chars

这是影响成本和效果的关键参数。切片过小会增加向量数量，切片过大又会增加Prompt长度。建议从700字符左右开始测试，再根据召回质量调整。

2. embedding.dimensions

向量维度越高，表示能力通常越强，但存储和检索成本也越高。对于大部分中文企业知识库，768维通常已经够用。

3. hybrid_search.weights

混合检索权重需要根据数据特点调整。如果文档中有大量专业术语、型号、编号，可以提高关键词检索权重；如果问题表达更口语化，可以提高向量检索权重。

4. rerank.trigger

不要默认所有请求都Rerank。建议只在召回分数不够高、问题较复杂或业务风险较高时启用。

5. context_builder.max_total_context_chars

该参数直接影响LLM输入成本。建议先限制在3000～5000中文字符范围内，再结合实际效果优化。

6. routing.levels

模型路由是降本重点。让简单问题走规则或小模型，让复杂问题走高级模型，可以在不明显损失体验的情况下降低成本。

7. cache.answer_cache

答案缓存适用于稳定知识。但对于价格、库存、实时状态等内容，需要谨慎缓存，避免返回过期信息。

十三、一个实际降本案例思路

假设某企业知识库每天有10万次搜索请求，初始方案如下：

• 每次请求都做Embedding；
• 向量检索Top 30；
• 每次都做Rerank；
• 拼接Top 8片段进入LLM；
• 所有请求都使用同一个大模型；
• 不使用缓存。

上线后成本很高，响应速度也不稳定。

经过优化后：

1. 对热门问题启用语义缓存；
2. 查询Embedding缓存命中率达到35%；
3. 简单FAQ约20%请求走规则回答；
4. Rerank只在40%请求中触发；
5. LLM上下文从8个片段降到5个片段；
6. 70%请求使用小模型；
7. 25%请求使用标准模型；
8. 5%请求使用高级模型；
9. 日志不再保存完整上下文；
10. 每周清理低质量文档和重复片段。

最终可能实现：

• 总Token消耗下降40%～60%；
• Rerank调用次数下降50%以上；
• 平均响应时间下降30%；
• 单次请求成本下降50%左右；
• 用户满意度基本保持稳定，甚至因召回质量提升而上升。

十四、常见误区

误区一：只看模型单价

模型单价很重要，但不是唯一因素。一个便宜模型如果需要更长Prompt、更频繁重试、更高人工兜底，综合成本未必低。

误区二：上下文越多越好

上下文过多不仅贵，还可能降低答案准确性。AI搜索追求的是“相关信息足够”，不是“信息越多越好”。

误区三：所有问题都用RAG

有些问题直接查数据库更准确，有些问题规则回答更稳定，有些问题适合传统搜索。RAG不是唯一方案。

误区四：不做评估就调参数

降本参数不能凭感觉改。每次调整Top K、chunk size、rerank策略，都应该用测试集验证召回率和答案质量。

误区五：忽略知识库质量

垃圾数据进入系统，只会产生垃圾答案。清洗、去重、结构化、权限管理，是AI搜索效果和成本的基础。

十五、总结

AI搜索的成本优化，本质上是一个系统工程。

真正有效的降本，不是简单换成更便宜的大模型，而是从数据、检索、排序、上下文、模型路由、缓存、监控等环节整体优化。

可以用一句话概括：

让简单问题不进模型，让明确问题少进上下文，让复杂问题才用强模型，让重复问题直接命中缓存。

如果你的AI搜索成本正在快速上升，可以优先从以下五件事开始：

1. 清理重复文档，减少无效向量；
2. 控制切片大小和上下文长度；
3. 启用查询缓存和答案缓存；
4. 按问题复杂度做模型路由；
5. 建立成本、效果、延迟三类监控。

当这些基础能力完善后，AI搜索不仅可以变得更便宜，也会变得更快、更准、更稳定。