本文为工程实践复盘，客户信息已脱敏，文中数据均为项目复盘口径的脱敏示意值。

一、项目背景

某集团旗下有十几套业务系统，制度文件、合同模板、操作手册、历史工单散落在 OA、内部知识库和各业务系统的附件里，彼此之间没有任何检索关联。员工想找一份差旅报销流程，要在 OA、财务共享、知识库三个系统来回翻，关键词搜索常常返回一堆不相关的东西，翻到第三页就放弃了。我们刚接手时，各系统自带的搜索互不相通，甚至出现过搜报销跳出来食堂菜谱的尴尬。更麻烦的是权限，能搜到的内容点进去往往提示无权限，因为搜索引擎没和源系统的权限模型打通。

这件事的业务压力很实在。一个一万多人的集团，每天内部检索请求成千上万，光靠人工问群、问行政，效率低到影响业务流转。我们评估过，员工平均找一份制度要花六分钟，其中大半时间花在切换系统和翻页上，真正阅读的时间反而很少。管理层也头疼，制度发了没人看，真出事又查不到谁看过，责任界定困难。更隐蔽的是知识资产在流失，老员工手里的经验散落在聊天记录和本地文档里，人一走，那部分知识就断了，新人只能在错误里重新学一遍。

我们一开始以为这是个简单的爬虫加索引工程，真正进场才意识到难点不在技术堆叠，而在跨系统的权限治理和数据归一。权限模型不打通，搜索再快也是空欢喜，搜出来点不进去比搜不到还让人恼火。所以项目第一天我们就把权限和召回列为一等公民，而不是等召回做好了再补权限这个后患。

二、落地场景

我们搭了一套统一搜索入口，把 OA 文档、知识库文章、业务系统附件三类来源做归一接入。检索时先按用户身份透传权限，再走语义向量召回加关键词 BM25 召回的双路融合，最后做去重和权限内排序。运营侧能看搜索词分布和点击反馈，反过来优化召回策略。

落地时我们优先接了高频场景：制度查询、合同模板检索、故障处理手册。对一个省级国资集团来说，这种跨库搜索把原本要翻半天的制度查找压到了秒级。我们还做了搜索建议和错别字纠正，因为内部文档命名很不规范，员工搜的词和系统里的词经常对不上，比如有人搜报销有人搜差旅，其实是同一份东西。搜索框还接了热门词榜，新人不小心也能找到高频制度。

为了让运营能持续调优，我们给搜索词做了聚类，每周把高频未命中词拉出来人工补同义词和别名，相当于给搜索喂一份活字典。这一步看起来不起眼，却是召回率稳步上行的关键，因为内部术语的收敛是持续过程，不可能一次配齐。

三、关键技术挑战与解决思路

第一个难点是跨系统文档归一。不同系统的文档格式和权限模型不一样，有的按部门隔离，有的按角色隔离。我们先用适配器把元数据映射到统一 schema，权限采用源系统判定加网关二次过滤两层，宁可少召回也不越权。这里踩过一次坑，早期我们只在网关做过滤，结果某个源系统权限改了但没同步，漏放了一批本该可见的文档，被业务投诉看不见。后来改成以源系统判定为准、网关兜底，两边对账，问题才消失。

第二个难点是语义和关键词召回的融合排序。纯向量召回看着相关但排序乱，长尾 query 尤其差。我们叠了一层 BM25 作为基础相关性，再用向量召回补充语义，用学习排序模型做最终融合，权重可调。第三个是结果去重，同一份制度在多个系统有副本，我们按内容指纹聚类只留最新版，避免一屏出现三个同名文件。第四个是意图识别，口语化搜索占比不低，我们加了一层 query 改写，把差旅、报销这类同义归并，召回率又提了一截。

学习排序模型的上线也踩了坑。我们一开始直接用全量点击日志训练，结果被少数高频管理员的点选带偏，排出来的结果偏向管理类文档。后来我们按角色对训练样本做了重采样，让一线员工的查询样本有足够权重，排序才回归正常。这件事让我意识到，企业搜索的排序不能只信原始行为数据，得带着对组织结构的理解去清洗样本。

案例片段（已脱敏）：跨库检索的权限过滤与融合召回配置。

yaml sources:  - type: oa_doc    auth: source_judge  - type: kb_article    auth: gateway_filter recall:  vector_weight: 0.55  bm25_weight: 0.45  dedupe_by: content_simhash

还有一段线上日志，能看出融合排序对长尾 query 的提升：一条项目结项审计需要哪些材料的口语化搜索，纯 BM25 只召回两份不相关的通用制度，叠了向量召回后排到了一份结项审计清单，点击率从 0 变成 60% 以上。

四、效果数据

上线一个季度后，搜索首点命中率从约 38% 提升到 71%，员工平均找文档耗时从 6 分钟降到 40 秒左右。无效结果占比从 34% 降到 11%。跨系统可检索覆盖率达到 92%。日检索请求中，长尾口语化 query 的点击率提升最为明显，部分场景翻倍。权限误放或漏放事件从每周数起降到接近零。这些口径随文档治理进度波动，但趋势是稳的。

五、可复用经验总结

搜索这件事，最怕搜出来的东西用户点不进去。我们项目初期只做向量召回，结果排序飘忽，运营抱怨搜到了却排在第 8 页。后来把权限过滤前置、再叠 BM25 才稳下来。说到底，企业搜索不是比谁召回多，而是比谁能把对的文档放到搜索结果的最前屏。权限和召回得一起设计，割裂做必然翻车。

点击反馈闭环别省，它比任何调参都来得直接。我们后来把点击日志接回排序模型，冷启动期靠它把长尾 query 的排序拉了上来。文档治理是搜索的地基，源系统命名和权限不规整，再好的检索也救不回来，这活儿得和业务一起长期做，别指望技术单方面解决。还有一点，排序样本要带着组织视角去清洗，盲目信原始行为数据，模型会被少数高频角色带偏，这点我们交过学费。

结语

回过头看，统一搜索最划算的一笔投入是搜索词日志，它让我们第一次看清用户到底在搜什么、卡在哪。我们据此反过来推动源系统的文档命名规范，搜索质量才进入正向循环。如果重来一次，我会更早把权限模型统一掉，而不是先埋头做召回，权限这关绕不过去，晚做只会让历史债越积越多。另外，同义词和别名的运营机制要从第一天就排进节奏，内部术语的收敛没有终点，靠的就是持续补字典这件笨功夫。