AI搜索 实战案例分享｜生产环境实测

引言：为什么要在生产环境里重新审视“AI搜索”？

过去几年，搜索系统经历了明显的技术迁移：从传统关键词匹配，到语义向量检索，再到结合大语言模型的智能问答式搜索。很多团队在评估 AI 搜索时，往往会先做一个 Demo：上传几份文档，接入 Embedding 模型，使用向量数据库检索，再调用大模型生成答案。Demo 的效果通常不错，但真正进入生产环境后，问题会迅速暴露出来。

例如：

• 用户的问题并不总是标准表达；
• 企业知识库文档结构复杂，质量参差不齐；
• 同一问题可能需要跨多个文档、多个系统查询；
• 模型生成结果可能存在幻觉；
• 检索召回不稳定，答案可追溯性不足；
• 成本、延迟、权限、安全等问题会被放大。

因此，AI 搜索并不是简单地“向量数据库 + 大模型问答”，而是一套完整的工程系统。本文将结合一个生产环境中的实测案例，分享从业务背景、技术方案、数据处理、召回策略、排序优化、答案生成、效果评估到上线运维的完整实践经验。

一、项目背景：从传统搜索到 AI 搜索升级

本次案例来自一个企业内部知识检索平台。该平台主要服务于研发、售前、客服和运营团队，知识来源包括：

1. 产品说明文档；
2. 研发设计文档；
3. API 接口文档；
4. 常见问题 FAQ；
5. 工单历史记录；
6. 会议纪要；
7. 内部制度文档；
8. 运维故障复盘报告。

在升级前，系统使用的是传统搜索引擎方案，核心能力包括关键词检索、标题匹配、标签过滤和简单的权限控制。该方案在早期能够满足大部分检索需求，但随着文档数量增长，用户反馈逐渐变差。

主要问题体现在以下几个方面。

1. 关键词搜索对表达方式过于敏感

例如用户搜索：

“如何配置单点登录？”

如果文档里写的是：

“SSO 接入配置流程”

传统关键词搜索可能无法准确召回。即使通过同义词词典维护，也很难覆盖业务中的所有表达方式。

2. 搜索结果需要用户自行阅读和总结

用户通常希望直接获得答案，而不是打开十几个文档逐个查找。尤其是客服和售前场景，响应速度非常重要。如果一个问题需要花五分钟查资料，实际业务效率会受到明显影响。

3. 文档分散，知识复用效率低

很多关键知识存在于工单、会议纪要或复盘报告中，并没有被整理成标准文档。传统搜索更擅长检索结构化或半结构化内容，对于零散知识的理解能力不足。

4. 权限与准确性要求高

企业内部知识并非全部公开，不同角色能访问的内容不同。AI 搜索如果忽略权限控制，可能会造成信息泄露。如果检索或生成答案不准确，也可能影响业务决策。

基于这些问题，团队决定建设一套面向生产环境的 AI 搜索系统，目标不是替代原有搜索，而是在原有搜索基础上增强语义理解、问答生成和知识聚合能力。

二、目标定义：AI搜索到底要解决什么问题？

在项目启动时，我们没有直接讨论模型选型，而是先定义业务目标。因为 AI 搜索的成败，并不只取决于模型能力，更取决于是否解决了真实业务问题。

最终确定了四个核心目标。

1. 提升搜索召回质量

用户使用自然语言提问时，系统能够召回语义相关的内容，而不仅仅依赖关键词重合。

例如用户问：

“客户忘记管理员密码怎么办？”

系统应能够召回：

“管理员账号重置流程”

“企业后台密码恢复说明”

“账号权限异常处理 SOP”

2. 提供可直接使用的答案

系统不仅展示文档列表，还要基于检索结果生成结构化答案，例如步骤说明、注意事项、相关链接、适用范围等。

3. 保证答案可追溯

每个 AI 生成答案都必须附带引用来源，用户可以点击查看原文。对于企业场景来说，“答案从哪里来”与“答案是什么”同样重要。

4. 满足生产环境要求

包括：

• 响应速度可接受；
• 支持权限控制；
• 支持增量更新；
• 成本可控；
• 可观测、可回滚；
• 对错误答案有反馈闭环。

三、整体架构设计

生产环境中的 AI 搜索系统可以拆分为五层：

1. 数据接入层；
2. 文档处理层；
3. 索引与检索层；
4. 大模型生成层；
5. 评估与运营层。

整体流程如下：

用户问题
  ↓
问题预处理与意图识别
  ↓
混合检索：关键词检索 + 向量检索 + 结构化过滤
  ↓
结果重排序
  ↓
上下文构造
  ↓
大模型生成答案
  ↓
引用溯源与安全校验
  ↓
返回答案与相关文档

其中，最关键的不是单点模型能力，而是各个环节之间的配合。很多 AI 搜索效果不佳，并不是因为大模型不够强，而是因为文档切分不合理、索引质量差、召回结果噪声高，导致模型拿到的上下文本身就有问题。

四、数据处理：AI搜索效果的基础

生产环境中，数据质量通常比模型选择更重要。我们在项目中投入最多时间的部分，不是写 Prompt，而是清洗和组织数据。

1. 文档来源接入

系统需要接入多类数据源：

不同数据源的处理策略不同。比如 FAQ 适合以问答对作为基本单元，API 文档则需要保留接口名称、请求参数、返回字段等结构信息。工单记录不能直接入库，因为其中可能存在敏感信息和大量无效对话，需要先做脱敏和摘要。

2. 文档清洗

清洗规则主要包括：

• 去除页眉、页脚、版权声明等无意义内容；
• 处理重复段落；
• 删除无效空行和乱码；
• 统一 Markdown、HTML、PDF 的格式；
• 对敏感信息进行脱敏；
• 提取标题层级、标签、更新时间、作者、部门、权限范围等元数据。

在实测中发现，如果不做清洗，向量检索会受到明显干扰。例如文档系统中的导航栏、版权说明、历史版本信息，如果被一起向量化，会导致检索结果出现大量无关内容。

3. 文档切分

文档切分是 AI 搜索系统中的关键环节。切得太大，会导致召回内容不精确；切得太小，又会丢失上下文。

我们最终采用了“结构优先 + 语义补充”的切分策略：

• 优先按照标题层级切分；
• 保留段落上下文；
• 对表格和代码块进行特殊处理；
• 每个文本块控制在 300～800 中文字左右；
• 相邻块之间保留一定 overlap；
• 每个 chunk 绑定原文标题、路径、URL、权限、更新时间等元数据。

例如一篇产品配置文档会被切分为：

文档标题：企业认证配置指南
一级标题：单点登录配置
二级标题：SAML 配置步骤
正文内容：……
元数据：产品线、版本号、更新时间、适用角色、文档链接

这种方式可以让模型在回答时既拿到精确内容，也能保留足够上下文。

五、检索策略：不要只依赖向量搜索

很多团队做 AI 搜索时，会默认使用向量检索作为核心方案。但在生产环境中，单独依赖向量检索并不稳定。

我们采用的是混合检索方案：

关键词检索 + 向量检索 + 元数据过滤 + 重排序

1. 关键词检索的价值

关键词检索在以下场景中仍然非常重要：

• 搜索错误码；
• 搜索接口名称；
• 搜索产品型号；
• 搜索专有名词；
• 搜索人名、系统名、配置项。

例如用户搜索：

“ERR_AUTH_403”

这类问题如果只用向量检索，效果可能不如关键词精确匹配。因此，我们保留了传统搜索引擎，用于处理高精度匹配场景。

2. 向量检索的价值

向量检索更适合处理自然语言表达，例如：

“为什么客户登录后看不到菜单？”

它可以召回：

• 权限配置异常；
• 角色未绑定菜单；
• 组织架构同步失败；
• 租户配置错误。

这些内容未必包含用户问题中的每个关键词，但语义相关。

3. 元数据过滤

生产环境中必须考虑权限和业务范围。检索时我们会先根据用户身份进行过滤，例如：

• 用户所属部门；
• 用户角色；
• 可访问产品线；
• 文档密级；
• 区域限制；
• 数据源类型。

这一步非常重要。AI 搜索不能先召回所有内容再让模型判断权限，因为那样已经存在泄露风险。正确做法是在检索阶段就完成权限约束。

4. 重排序

初步召回后，我们会使用 rerank 模型或规则排序进行二次筛选。重排序考虑的因素包括：

• 语义相关度；
• 关键词匹配度；
• 文档权威等级；
• 更新时间；
• 点击率；
• 用户反馈；
• 文档来源可信度。

实测发现，加入重排序后，Top 5 结果的相关性提升明显。尤其是在多个文档都语义相近时，重排序可以优先选择官方文档、最新文档和高质量 FAQ。

六、答案生成：让大模型“基于材料回答”

检索完成后，系统会将 Top N 的内容构造成上下文，再交给大模型生成答案。这里最重要的原则是：让模型基于检索材料回答，而不是自由发挥。

1. Prompt 设计原则

我们在 Prompt 中明确约束：

• 只能基于提供的上下文回答；
• 如果上下文不足，需要说明无法确定；
• 必须引用来源；
• 不允许编造不存在的流程、接口或配置项；
• 对步骤类问题要分点输出；
• 对风险类问题要提示注意事项；
• 对版本相关问题要说明适用版本。

示例 Prompt 结构如下：

你是企业知识库问答助手。
请基于以下检索到的资料回答用户问题。
要求：
1. 不要使用资料之外的信息进行推测；
2. 如果资料不足，请明确说明“当前资料无法确认”；
3. 回答中需要给出引用来源；
4. 优先使用最新、权威来源；
5. 输出结构清晰，适合业务人员直接使用。

用户问题：
{query}

参考资料：
{context}

2. 上下文构造

上下文不是简单把检索结果全部塞给模型。我们会做以下处理：

• 去除重复内容；
• 按相关性和权威性排序；
• 保留标题和来源；
• 控制 token 长度；
• 对长表格进行摘要；
• 对冲突内容标记版本和时间。

如果上下文过长，不仅成本上升，还可能影响模型判断。因此，我们一般只选择最相关的 5～8 个片段进入生成阶段。

3. 防止幻觉

为了降低幻觉，我们采用了多种机制：

• 检索结果置信度过低时，不生成确定答案；
• 答案必须绑定引用；
• 模型输出后进行来源校验；
• 对关键字段进行规则检查；
• 高风险问题引导用户查看原文或联系负责人。

例如用户问：

“生产数据库能不能直接执行清表操作？”

如果资料中没有明确授权，模型不能回答“可以”，而应该提示需要遵循变更流程和审批机制。

七、生产环境实测效果

上线前，我们构建了一套测试集，包含约 800 条真实用户问题，来源于历史搜索日志、客服问答和工单记录。问题类型包括：

• 操作流程类；
• 故障排查类；
• 配置说明类；
• 接口查询类；
• 权限问题类；
• 产品能力咨询类；
• 制度规范类。

1. 评估指标

我们主要关注以下指标：

2. 实测结果

在生产环境灰度期间，我们选择了部分团队试用。对比旧搜索系统，结果大致如下：

需要说明的是，AI 搜索并不是所有场景都优于传统搜索。例如错误码、接口名、精确标题查询，传统关键词搜索依然非常有效。因此最终方案是融合式，而不是替代式。

八、踩坑经验：Demo 到生产的差距在哪里？

1. 文档质量差会直接影响答案质量

最初测试时，我们发现部分 AI 答案看起来很流畅，但内容并不准确。追溯后发现，问题不在模型，而在原文档：有些文档已经过期，有些文档之间互相矛盾。

解决方式是建立文档治理机制：

• 标记文档有效期；
• 对过期文档降权；
• 为权威文档增加权重；
• 对冲突内容提示用户；
• 建立知识负责人机制。

2. Chunk 切分不合理会导致召回失败

如果把整篇文档作为一个向量，检索结果会过粗；如果按固定长度强行切分，又可能把一个完整步骤拆散。最终我们采用标题结构切分，并对特殊内容单独处理，效果才稳定下来。

3. 权限控制不能后置

AI 搜索涉及企业内部知识，权限必须在检索阶段完成。如果模型接触到了用户无权访问的内容，即使最终没有展示，也存在风险。因此权限过滤需要成为索引和检索设计的一部分。

4. 不要迷信单一模型

我们曾经尝试只更换更强的 Embedding 模型，但提升有限。后来发现，召回策略、重排序、数据清洗、Prompt 约束共同优化后，整体效果才有明显提升。

5. 用户反馈闭环非常关键

上线后，用户会不断提出“答案不准”“引用不对”“没有找到我想要的内容”等反馈。如果没有反馈闭环，系统很难持续优化。我们为每个答案增加了点赞、点踩、原因选择和补充说明，并定期分析低分问题。

九、成本与性能优化

AI 搜索进入生产环境后，成本和延迟是必须关注的问题。

1. 缓存机制

对于高频问题，我们会缓存检索结果和生成答案。例如：

• “如何重置密码？”
• “如何申请生产权限？”
• “如何配置 SSO？”
• “如何查看 API 调用日志？”

缓存可以显著降低模型调用成本，并提升响应速度。

2. 分层调用模型

不是所有问题都需要调用最强模型。我们采用分层策略：

• 简单 FAQ：直接返回已有答案；
• 精确查询：优先返回搜索结果；
• 中等复杂问题：使用普通模型生成；
• 高风险或复杂问题：使用更强模型，并增加校验。

3. 控制上下文长度

上下文越长，成本越高，延迟越大。通过重排序、去重和摘要，我们将输入内容控制在合理范围内。

4. 异步索引更新

文档更新后，不一定需要立即全量重建索引。我们采用增量更新策略：

• 新增文档：增量切分并入库；
• 修改文档：更新相关 chunk；
• 删除文档：同步删除索引；
• 权限变更：更新元数据过滤规则。

十、典型业务场景案例

案例一：客服快速定位解决方案

用户问题：

“客户说开通企业微信同步后，组织架构没有更新，应该怎么排查？”

AI 搜索返回：

1. 检查企业微信回调配置是否成功；
2. 确认同步任务是否开启；
3. 查看最近一次同步日志；
4. 检查部门 ID 是否发生变化；
5. 如果接口返回权限错误，需要重新授权；
6. 附带相关文档链接和工单案例。

这个答案原本需要客服搜索多个文档和历史工单，现在可以在一分钟内得到结构化排查路径。

案例二：研发查询接口变更

用户问题：

“新版用户查询接口是否还返回 mobile 字段？”

系统通过关键词和向量混合检索，召回 API 变更记录和接口文档。AI 答案指出：

• 在 v2.3 版本之前返回 mobile 字段；
• v2.4 后默认不返回，需要申请敏感字段权限；
• 推荐使用 maskedMobile 字段；
• 引用对应 API 文档版本说明。

这个场景中，版本信息非常关键。如果没有元数据和引用机制，模型很容易给出过时答案。

案例三：售前查询产品能力边界

用户问题：

“系统支持按照部门维度做数据隔离吗？”

AI 搜索从产品白皮书、权限设计文档和 FAQ 中综合信息，回答：

• 支持按照组织、角色、数据范围进行权限控制；
• 部门维度的数据隔离需要开启高级权限模块；
• 不同产品版本支持范围不同；
• 如涉及跨租户隔离，需要单独评估；
• 附带产品版本对比文档。

这类问题的价值在于减少售前反复咨询产品和研发，提高响应效率。

十一、上线策略与风险控制

AI 搜索上线不能一刀切。我们采用了分阶段策略。

1. 内部试用

先开放给知识库维护人员和部分高频用户，收集问题和反馈。

2. 灰度发布

按部门逐步开放，观察检索质量、响应时间、成本和用户满意度。

3. 双轨运行

AI 搜索与传统搜索同时保留。用户可以查看 AI 答案，也可以继续浏览原始搜索结果。

4. 风险提示

对于不确定答案，系统会明确提示：

“当前资料不足，建议查看原文或联系相关负责人确认。”

这比强行生成一个看似完整但实际不可靠的答案更安全。

十二、总结：生产环境中的 AI 搜索不是模型项目，而是系统工程

通过这次生产环境实测，我们最大的体会是：AI 搜索的核心不只是大模型，而是“数据、检索、生成、评估、运营”的综合能力。

一个真正可用的 AI 搜索系统，至少需要具备以下能力：

1. 高质量的数据清洗和文档切分；
2. 关键词与向量融合的混合检索；
3. 严格的权限过滤；
4. 有效的重排序机制；
5. 基于上下文的答案生成；
6. 清晰可靠的引用溯源；
7. 可观测的效果评估；
8. 持续反馈和知识治理。

从结果来看，AI 搜索确实能够显著提升企业知识检索效率，尤其适合自然语言问题、跨文档总结、故障排查和业务咨询等场景。但它并不能完全替代传统搜索，更合理的方式是融合两者优势：关键词搜索负责精确匹配，向量检索负责语义召回，大模型负责阅读、总结和表达。

如果说传统搜索解决的是“帮用户找到文档”，那么 AI 搜索进一步解决的是“帮用户理解知识并形成答案”。这也是 AI 搜索在生产环境中真正的价值所在。