AI搜索 性能优化教程｜生产环境实测

在过去一年里，越来越多团队把传统站内搜索升级为“AI搜索”：用户不再只输入关键词，而是直接提出问题；系统也不再只返回一组链接，而是结合语义检索、重排、摘要生成和业务规则，给出更贴近意图的答案。

但真正把AI搜索上线到生产环境后，很多问题会集中爆发：延迟高、成本高、召回不稳定、答案幻觉、索引更新慢、并发一上来就抖动。本文结合生产环境中的常见实践，系统讲解AI搜索的性能优化方法，覆盖架构设计、向量检索、Embedding、Rerank、LLM生成、缓存、索引、监控和压测等环节。

本文适合：正在搭建RAG系统、企业知识库搜索、电商智能搜索、客服问答、文档检索、代码搜索等场景的工程师、架构师和技术负责人。

一、AI搜索的典型链路

一个生产级AI搜索系统，通常不是单一模型调用，而是一条完整链路：

用户Query
  ↓
Query理解与改写
  ↓
召回：关键词检索 + 向量检索 + 规则召回
  ↓
结果合并与去重
  ↓
Rerank重排
  ↓
上下文构造
  ↓
LLM生成答案
  ↓
引用来源与安全校验
  ↓
返回结果

如果是更复杂的业务，还会加入：

• 用户画像与权限过滤；
• 多轮对话上下文压缩；
• 实时数据查询；
• 工具调用；
• AB实验；
• 反馈学习；
• 内容安全审核。

因此，AI搜索的性能优化不能只盯着“大模型响应慢”这一点，而要把整条链路拆开分析。

二、生产环境中的核心性能指标

上线AI搜索前，首先要明确评估指标。否则优化很容易变成“感觉变快了”，但实际用户体验并没有提升。

1. 延迟指标

常见指标包括：

对于AI搜索而言，首Token时间比完整响应时间更影响用户体感。如果3秒内能看到内容输出，用户通常愿意等待；如果10秒没有任何反馈，即使最终答案很好，也会被认为系统很慢。

2. 质量指标

性能优化不能以牺牲质量为代价，需要同时监控：

• 召回率；
• 命中率；
• TopK准确率；
• 答案引用准确率；
• 幻觉率；
• 用户点击率；
• 用户追问率；
• 点赞/点踩比例；
• 人工质检评分。

3. 成本指标

AI搜索的成本主要来自：

• Embedding模型调用；
• 向量数据库存储；
• Rerank模型调用；
• LLM生成Token；
• GPU/CPU推理资源；
• 索引构建任务；
• 日志与监控存储。

生产环境中，优化目标通常不是“最快”，而是在质量、延迟、成本之间找到平衡。

三、先定位瓶颈：不要盲目优化

在生产环境里，很多AI搜索系统慢，并不是因为模型太慢，而是链路中存在隐藏瓶颈。例如：

• 权限过滤查询慢；
• ES查询没有命中索引；
• 向量数据库TopK设置过大；
• Rerank候选数量过多；
• Prompt拼接了大量无用上下文；
• LLM输出长度没有限制；
• 每次请求都重新计算Embedding；
• 缓存没有命中；
• 网络跨地域调用；
• 日志同步写入阻塞主链路。

建议对每个请求打点，记录各阶段耗时：

query_rewrite_ms
embedding_ms
keyword_search_ms
vector_search_ms
permission_filter_ms
merge_dedup_ms
rerank_ms
prompt_build_ms
llm_first_token_ms
llm_total_ms
post_check_ms
total_ms

只有明确知道慢在哪里，优化才有效。

四、Query理解与改写优化

Query改写的作用是提升召回质量，例如把用户输入的自然语言问题转换为更适合搜索的表达。

例如：

用户问题：怎么退货？
改写后：退货流程 退货政策 退款时间 售后申请

但Query改写如果每次都调用大模型，会显著增加延迟和成本。

优化建议

1. 短Query优先规则化

对于高频短问题，可以使用规则或轻量模型处理：

• “退款”
• “怎么开发票”
• “登录不了”
• “订单取消”
• “密码重置”

这些不一定需要LLM改写，可以通过词典、同义词库、意图分类器完成。

2. 改写结果缓存

用户问题存在明显长尾，但高频问题也非常集中。可以对标准化后的Query做缓存：

cache_key = normalize(query)

标准化包括：

• 去除多余空格；
• 大小写归一；
• 简繁转换；
• 标点规整；
• 同义词归一。

3. 控制改写数量

有些系统会把一个Query扩展成5到10个检索Query，这会让召回阶段的耗时成倍上升。生产中建议：

• 普通问题：1到2个改写；
• 复杂问题：最多3个改写；
• 高价值场景再使用更多改写。

五、Embedding性能优化

Embedding是AI搜索的基础，但也是常见性能消耗点之一。

1. Query Embedding缓存

对于重复问题，直接复用Embedding结果。尤其在客服、帮助中心、企业知识库中，高频问题非常多。

缓存策略：

key: model_name + model_version + normalized_query
value: embedding_vector
ttl: 7天或30天

注意：如果Embedding模型升级，必须更新版本号，否则新旧向量空间不一致，会导致检索效果异常。

2. 批量Embedding

索引构建时，不要逐条调用Embedding接口，而应使用批量处理：

batch_size = 32 / 64 / 128

具体大小取决于模型服务的吞吐能力和显存限制。生产环境实测中，批处理通常能显著提升吞吐，降低单位文本的平均处理耗时。

3. 文档切片要适中

文档切片过大，会导致语义不精确；切片过小，会导致索引量暴涨，召回结果碎片化。

常见建议：

中文知识库：300～800字一个chunk
技术文档：500～1200字一个chunk
客服FAQ：一问一答作为一个chunk
代码搜索：按函数、类或模块切分

同时建议保留元信息：

• 文档ID；
• 标题；
• 章节；
• 更新时间；
• 权限标签；
• 业务分类；
• 来源URL。

4. 避免重复入库

生产环境中，经常会因为定时任务、重试机制、数据同步异常导致重复chunk入库。重复数据会增加索引体积，影响检索速度和结果质量。

建议对文档内容计算Hash：

content_hash = sha256(title + content + metadata)

如果Hash未变化，则跳过Embedding和索引更新。

六、向量检索优化

向量数据库是AI搜索的核心组件。常见选择包括Milvus、Qdrant、Weaviate、Elasticsearch Vector、OpenSearch、pgvector等。

1. 合理设置TopK

很多系统为了“保证召回”，会把TopK设置得很大，比如100、200甚至500。这样不仅增加向量检索耗时，也会拖慢后续Rerank。

生产中常见配置：

向量召回TopK：20～80
关键词召回TopK：20～80
最终Rerank候选：30～100
最终给LLM上下文：3～8个chunk

如果知识库规模不大，TopK可以适当小一点；如果文档质量参差不齐，TopK可以适当增大，但必须配合重排和过滤。

2. 使用ANN索引

大规模向量检索不能使用暴力搜索，应使用近似最近邻索引，例如：

• HNSW；
• IVF_FLAT；
• IVF_PQ；
• DiskANN；
• ScaNN。

HNSW通常适合低延迟、高召回场景，但内存占用较高；IVF类索引适合数据量较大、资源受限的场景。

3. 调整索引参数

以HNSW为例，常见参数包括：

M：图中每个节点的连接数
efConstruction：构建索引时的搜索宽度
efSearch：查询时的搜索宽度

一般规律：

• M越大，召回越好，内存越高；
• efConstruction越大，构建越慢，质量越好；
• efSearch越大，召回越好，查询越慢。

生产环境需要通过压测找到平衡点，而不是直接使用默认值。

4. 先过滤还是后过滤

很多业务都有权限、租户、分类、时间范围等过滤条件。

例如：

tenant_id = 当前租户
permission_group in 用户权限组
status = published

如果先做全库向量检索，再做权限过滤，可能会出现TopK结果大部分被过滤掉，导致最终无结果。更糟糕的是，还浪费了大量计算。

更推荐：

• 能前置过滤的条件尽量前置；
• 建立分区或分片；
• 按租户、业务线、语言等维度拆分索引；
• 对权限复杂场景使用混合召回策略。

七、关键词检索与向量检索混合优化

单纯向量检索并不能解决所有问题。比如：

• 型号；
• 编号；
• 人名；
• 专有名词；
• 错误码；
• 订单号；
• API名称；
• 法律条文编号。

这些场景关键词检索往往更可靠。

推荐使用Hybrid Search

常见做法是：

结果 = BM25关键词检索 + 向量语义检索

然后进行归一化合并：

score = α * vector_score + β * bm25_score + γ * business_score

其中business_score可以包含：

• 文档热度；
• 更新时间；
• 用户权限；
• 类目匹配；
• 点击反馈；
• 人工置顶；
• 业务优先级。

生产实测经验

在企业知识库和客服问答场景中，Hybrid Search通常比单纯向量检索更稳定。尤其对于“错误码”“产品型号”“政策编号”等精确查询，BM25能显著提升命中率。

八、Rerank重排优化

Rerank的作用是从召回候选中选出最相关的结果。它通常比Embedding检索更准确，但耗时也更高。

1. 控制候选数量

不要把几百条候选都送进Rerank。建议：

召回阶段：每路TopK 30～50
合并去重后：控制在50～100
Rerank后：取Top 5～10

如果Rerank模型较慢，可以进一步控制在30以内。

2. 两阶段重排

可以使用两阶段策略：

第一阶段：轻量特征排序
第二阶段：Cross Encoder Rerank

轻量特征包括：

• 标题匹配；
• 关键词覆盖；
• 文档新鲜度；
• 历史点击率；
• 向量相似度；
• 类目匹配。

这样可以减少进入重模型的候选数量。

3. Rerank缓存

对于高频Query和稳定文档库，Rerank结果可以缓存：

key = query_hash + candidate_doc_ids_hash + rerank_model_version

如果候选集合不变，可以直接复用重排结果。

4. 小模型优先

很多情况下，并不一定需要最大Rerank模型。中文场景可以先评估：

• bge-reranker-base；
• bge-reranker-large；
• m3-reranker；
• 自研蒸馏模型。

如果业务对延迟敏感，可以考虑量化、蒸馏或GPU批处理。

九、Prompt与上下文构造优化

LLM生成阶段往往是总耗时和成本的主要来源。优化Prompt是最直接有效的手段之一。

1. 减少无效上下文

很多系统会把Top10甚至Top20的chunk全部塞进Prompt，导致输入Token暴涨。实际中，LLM不一定能有效利用过多上下文，反而可能引入干扰。

建议：

最终上下文chunk数量：3～8个
单个chunk长度：300～800字
总上下文Token：控制在模型窗口的20%～40%

2. 结构化上下文

不要简单拼接文本，最好带上来源信息：

[资料1]
标题：退款规则
来源：帮助中心/售后政策
内容：……

[资料2]
标题：特殊商品退货说明
来源：帮助中心/商品政策
内容：……

这样有利于模型引用来源，减少幻觉。

3. 明确回答边界

Prompt中应明确告诉模型：

如果资料中没有答案，请回答“根据当前资料无法确认”，不要编造。
回答必须基于给定资料。
涉及金额、时间、政策条款时必须引用来源。

这类约束可以降低幻觉率。

4. 控制输出长度

如果不限制输出长度，LLM可能生成过长答案，导致成本和延迟上升。

可以设置：

max_tokens = 512 / 800 / 1024

对于搜索问答，大多数场景512到800个输出Token已经足够。

十、LLM生成性能优化

1. 使用流式输出

流式输出不能减少总生成时间，但能显著改善用户体验。用户看到首Token后，会感觉系统已经开始响应。

前端可以显示：

正在检索相关资料……
已找到3条相关内容……
正在生成答案……

这类状态提示能降低等待焦虑。

2. 模型分级路由

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

可以按问题复杂度路由：

生产中，模型分级路由通常能明显降低成本，同时保持整体体验。

3. 控制Temperature

搜索问答不是创意写作，建议：

temperature = 0～0.3

较低的随机性可以提高答案稳定性，减少幻觉。

4. 答案缓存

对于高频问题，可以缓存最终答案。

缓存Key可以包含：

query_hash
retrieved_doc_ids
doc_versions
prompt_version
model_version

注意不要只按Query缓存，因为文档内容更新后，旧答案可能过期。

5. 异步生成摘要

如果搜索结果页面需要展示每条文档的摘要，不建议在用户请求时逐条生成。可以：

• 文档入库时预生成摘要；
• 后台异步更新摘要；
• 用户点击后再生成深度解释；
• 列表页先展示原文片段。

十一、缓存体系设计

AI搜索中常见缓存层包括：

Query改写缓存
Query Embedding缓存
召回结果缓存
Rerank结果缓存
Prompt片段缓存
最终答案缓存
用户会话缓存
文档摘要缓存

缓存设计原则

1. 缓存必须带版本

例如：

embedding_model_version
rerank_model_version
prompt_version
doc_version
index_version

只要版本变化，就应该自动失效。

2. 高频短Query优先缓存

长尾问题缓存收益有限。可以重点缓存：

• Top 1000高频问题；
• 热门业务问题；
• 固定政策问题；
• 标准FAQ；
• 首页搜索推荐词。

3. 注意权限隔离

如果系统存在用户权限，缓存Key必须包含权限相关信息，否则可能出现数据泄露。

例如：

cache_key = tenant_id + user_permission_hash + query_hash

这是生产环境必须重视的问题。

十二、索引更新优化

AI搜索不是一次性构建索引就结束。生产环境中，文档会不断新增、修改、删除。

1. 增量更新

不要每次全量重建索引。应通过CDC、消息队列或更新时间戳做增量同步：

新增：生成Embedding并写入索引
修改：删除旧chunk，写入新chunk
删除：软删除或从索引移除

2. 双索引切换

对于大规模重建，可以使用双索引：

index_v1：当前线上索引
index_v2：后台构建新索引

构建完成并验证后，再切换流量到新索引。这样可以避免索引构建期间影响线上查询。

3. 索引健康检查

需要定期检查：

• 文档数是否一致；
• chunk数量是否异常；
• 向量维度是否一致；
• 是否存在重复数据；
• 是否存在空内容；
• 删除数据是否仍被召回；
• 权限标签是否缺失。

十三、并发与服务稳定性优化

AI搜索链路长，任何一个组件抖动都会影响整体体验。

1. 超时控制

为每个阶段设置超时：

Embedding：300ms～1000ms
向量检索：100ms～500ms
关键词检索：100ms～500ms
Rerank：300ms～1500ms
LLM首Token：1s～5s
总请求：10s～30s

超时后要有降级策略。

2. 降级策略

例如：

• Rerank超时：使用召回分数排序；
• 向量库不可用：只使用关键词检索；
• LLM不可用：返回搜索结果列表；
• 改写失败：使用原Query检索；
• 摘要生成失败：返回原文片段。

好的AI搜索系统，一定不是“某个组件失败就全链路失败”。

3. 限流与排队

LLM和Rerank通常是昂贵资源，需要限流：

• 按用户限流；
• 按租户限流；
• 按接口限流；
• 按模型限流；
• 按Token预算限流。

高峰期可以对低优先级请求降级，优先保障核心业务。

十四、生产环境实测优化案例

下面给出一个典型企业知识库AI搜索的优化前后对比。

优化前链路

用户Query
  ↓
LLM改写Query
  ↓
向量检索TopK=200
  ↓
关键词检索TopK=100
  ↓
合并后约250条
  ↓
Rerank全部候选
  ↓
Top20全部进入Prompt
  ↓
LLM生成答案

存在问题

• 总延迟TP95超过12秒；
• Rerank耗时过高；
• Prompt输入Token过多；
• LLM生成成本高；
• 部分答案引用不准确；
• 高峰期模型服务排队严重。

优化措施

1. Query改写缓存与规则分流

高频短问题不再调用LLM，使用规则改写和意图识别。Query改写平均耗时明显下降。

2. 调整召回TopK

将向量召回从TopK=200降到TopK=60，关键词召回从TopK=100降到TopK=50。

3. 增加轻量预排序

合并去重后先使用标题匹配、关键词覆盖和相似度做初筛，只保留Top80进入Rerank。

4. Rerank只处理Top80

避免对几百条候选全部重排。

5. Prompt只保留Top6

最终只选择Rerank后的Top6 chunk进入Prompt，并对超长chunk做裁剪。

6. LLM流式输出

用户平均在2秒左右看到首Token，体验明显改善。

7. 增加答案缓存

对高频政策类问题缓存最终答案，并绑定文档版本。

优化后效果

可以看到，优化并不是单点完成的，而是通过链路拆解逐步压缩延迟和成本。

十五、压测方法

AI搜索压测不能只测QPS，还要测复杂链路下的稳定性。

1. 构造真实Query集

Query集应覆盖：

• 高频短问题；
• 长尾复杂问题；
• 无答案问题；
• 多轮上下文问题；
• 权限过滤问题；
• 精确编号查询；
• 模糊语义查询；
• 超长输入；
• 恶意输入。

2. 分阶段压测

建议分别压测：

• Embedding服务；
• 向量数据库；
• ES/OpenSearch；
• Rerank服务；
• LLM服务；
• 完整链路。

这样能定位具体瓶颈。

3. 观察关键指标

包括：

• QPS；
• 并发数；
• TP95/TP99；
• 错误率；
• 超时率；
• 缓存命中率；
• GPU利用率；
• CPU利用率；
• 内存占用；
• 队列长度；
• Token吞吐；
• 向量库查询耗时。

十六、监控与告警

上线后需要持续监控。推荐建立如下仪表盘：

1. 链路耗时看板

展示每个阶段耗时分布：

Query改写
Embedding
向量检索
关键词检索
Rerank
LLM首Token
LLM总耗时
总耗时

2. 质量看板

展示：

• 无答案率；
• 用户点踩率；
• 引用缺失率；
• 引用错误率；
• 搜索无结果率；
• Top1点击率；
• Top3点击率；
• 人工质检通过率。

3. 成本看板

展示：

• 每日Token消耗；
• 单用户平均成本；
• 单租户成本；
• Embedding调用量；
• Rerank调用量；
• 缓存节省成本；
• 模型调用失败率。

4. 告警规则

例如：

TP95 > 8s 持续5分钟告警
错误率 > 2% 持续3分钟告警
LLM首Token > 5s 持续5分钟告警
向量检索超时率 > 1% 告警
缓存命中率异常下降告警
Token消耗突增告警

十七、常见误区

误区一：只用向量检索就够了

向量检索擅长语义匹配，但对精确词、编号、专有名词并不总是可靠。生产环境建议使用Hybrid Search。

误区二：TopK越大越好

TopK越大，后续重排和生成成本越高。过多上下文还可能干扰LLM判断。

误区三：把所有内容都塞给大模型

LLM不是万能过滤器。检索阶段越精准，生成效果越稳定。

误区四：只关注答案，不关注引用

AI搜索的可信度来自可追溯来源。没有引用的答案很难在企业场景中被信任。

误区五：没有降级方案

生产环境中模型、数据库、网络都可能出问题。没有降级方案的AI搜索系统不可控。

十八、推荐的生产级架构

一个较稳妥的生产级AI搜索架构可以设计为：

API Gateway
  ↓
Search Orchestrator
  ↓
Query Processor
  ↓
Embedding Service
  ↓
Hybrid Retriever
  ├── Vector DB
  └── Search Engine
  ↓
Permission Filter
  ↓
Rerank Service
  ↓
Context Builder
  ↓
LLM Gateway
  ↓
Answer Validator
  ↓
Response

配套组件包括：

• Redis缓存；
• Kafka消息队列；
• MySQL/PostgreSQL元数据；
• 对象存储；
• Prometheus/Grafana监控；
• ELK日志；
• Feature Store；
• AB实验平台；
• 人工质检平台。

十九、上线前检查清单

上线AI搜索前，建议逐项检查：

• [ ] 是否支持流式输出；
• [ ] 是否有完整链路打点；
• [ ] 是否设置各阶段超时；
• [ ] 是否有降级策略；
• [ ] 是否有缓存版本控制；
• [ ] 是否支持权限隔离；
• [ ] 是否记录引用来源；
• [ ] 是否支持无答案返回；
• [ ] 是否有人工质检样本；
• [ ] 是否完成压测；
• [ ] 是否有Token成本监控；
• [ ] 是否支持索引增量更新；
• [ ] 是否能快速回滚模型和Prompt；
• [ ] 是否对高频问题做缓存；
• [ ] 是否配置错误率和延迟告警。

二十、总结

AI搜索性能优化的核心，不是简单地换一个更快的大模型，也不是盲目扩大向量数据库配置，而是对整条链路进行系统治理。

可以按照以下顺序推进：

1. 先打点：拆解每个阶段耗时；
2. 再压测：找到真实性能瓶颈；
3. 控TopK：减少无效候选；
4. 做混合召回：提升稳定性；
5. 优化Rerank：只重排必要结果；
6. 精简Prompt：减少Token浪费；
7. 使用缓存：优先覆盖高频请求；
8. 流式输出：改善用户体感；
9. 分级路由：降低成本；
10. 监控告警：保障生产稳定性。

生产环境中的AI搜索，真正考验的是工程能力：检索、模型、缓存、索引、权限、监控、降级缺一不可。只有把AI能力和传统搜索工程结合起来，才能构建一个既准确、又快速、还可控的智能搜索系统。