搜索这个领域平时看着挺简单真自己从零搭一套坑多到数不过来。我这边维护的内部搜索内核Sirchmunk最近终于跑到了稳定可用的状态想把这套设计思路拆出来聊聊。先说结论这个项目从一开始就没有用向量数据库全程走稀疏检索加在线反馈闭环靠一套叫做“自进化”的机制持续调优。它对标的问题是团队内部文档、工单、代码片段这些中长尾内容越来越多传统Lucene系检索在语义匹配上吃力但直接上一套向量方案又觉得成本高、运维重、结果不可解释。这篇文章不聊概念只讲架构和取舍适合正在设计搜索系统、或者想优化现有检索效果的同学参考。1. 设计拆解为什么把“向量数据库”排除在方案外很多搜索项目在立项时会惯性思维地认为效果不好就是没上向量。实际上在Sirchmunk的选型讨论中我们列过一版很现实的需求清单反而不太支持向量方案。这个决策过程值得先讲清楚因为后面所有结构设计都建立在这个取舍之上。1.1 搜索场景的真实约束先说数据形态。项目要搜的东西很广运维操作手册、会议纪要、代码注释、历史工单甚至偶尔有扫描件OCR出来的文本。这些数据的特点是长度不均、质量参差、主题分散。如果做向量索引首先要过embedding模型但内容里大量是缩写、内部代号、命令片段通用模型对这些粒度的语义理解其实并不稳定。再说延迟预算。内网搜索虽然并发不高但内部用户对等待非常敏感。习惯了主流搜索引擎的毫秒级反馈如果一次查询要几百毫秒甚至一秒以上基本就被判定为不好用。纯向量检索在粗排阶段还好说但一旦要加过滤条件、做聚合统计、按时间或部门范围圈定结果向量方案的过滤能力往往需要额外对齐流程变长。还有一个被经常忽略的点结果可解释性。搜索最终要面对用户推荐结果如果是个黑盒出了badcase几乎没法定位。向量检索给出“语义上相似”的结论但用户问“为什么搜到了它”我们无话可说倒排索引至少能告诉用户“这篇文章里出现了你输入的两个关键词”。在内部系统里这种解释能力比花哨的语义匹配更重要。1.2 稀疏检索并不是过时方案有一种倾向是把稀疏检索当成老古董。实际上在Sirchmunk的设计里核心召回完全靠倒排索引配合BM25打分只是在排序阶段叠加了更多上下文特征。对于精确词命中、FAQ问答、工单检索这类场景稀疏匹配不仅稳定而且计算简单可量化。稀疏检索最被低估的优势是可以精确定位。比如用户输入“Redis连接超时排查”倒排索引可以做到“Redis”、“连接”、“超时”、“排查”四个词全部命中的文档优先这是向量检索很难做到的。向量检索擅长的是“含义相近但用词不同”比如“缓存挂了”和“Redis不可用”之间的联想但现实是很多内部文档标题就会直接用用户可能输入的关键词精确匹配已经解决大部分问题。真正的病根从来不是“倒排索引能不能召回”而是“召回后排序能力弱不强”。过去只有TF-IDF或BM25时排序确实粗糙满足不了长尾需求。但现在可以在倒排召回的基础上叠加大量实时特征用轻量模型做重排这本质上已经不是传统意义的“关键词搜索”了。Sirchmunk走的就是这条路召回靠稀疏排序靠特征加模型兼顾准与快。1.3 对“自进化”的理解方式说到自进化网上容易渲染成玄学好像系统会自己长出能力。实际工程里的自进化在我看来是一套受控的闭环系统观察用户行为形成信号信号回流到词典、索引权重、排序参数新参数经过验证后生效整个过程自动迭代。核心不在某个神秘算法而在闭环管道设计得是否扎实。Sirchmunk的自进化主要作用在三个地方词关系扩充、排序特征调整、结果注入与置顶。这三个地方分别对应召回变宽、排序变准、干预变少。每一步都依赖日志反馈来驱动而不是拍脑袋。这点在后面章节会详细拆。2. 索引与检索无向量方案的核心工程既然不用向量库索引与检索模块就是整个系统的心脏。这里说几个关键工程点都是实践中真正踩过坑才确认下来的设计。2.1 索引结构词典加倒排列表加辅助元数据Sirchmunk的索引物理结构可以简单理解成三层词典层记录词项到倒排列表的映射倒排列表存docID、词频、位置信息辅助元数据存字段级权重和文档属性。词典层用双数组Trie加哈希表结合。Trie负责前缀查找和提示词补全哈希表负责精确词典查询。倒排列表没有用纯数组存储而是在内存里用跳表加差值编码千万级文档量下既能支持快速跳跃定位又能压内存占用。位置信息这个字段容易被人省略但Sirchmunk保留了它因为短语查询和邻近查询都依赖位置计算。比如用户搜“订单失败 重试”文档里“失败”和“重试”出现在同一段落才算强相关没有位置信息只能妥协成AND匹配效果差不少。文档元数据单独放在一套列式结构中方便排序阶段按需取用。比如我们需要按“最近更新时间”、“作者部门”、“文档热度”做过滤或特征计算列式存储可以快速读取指定字段不需要展开整篇文档。很多自研搜索引擎初期会忽略这层设计结果排序阶段要临时查数据库延迟一下子就上去了。2.2 召回策略从词匹配到短语与字段加权召回策略直接决定了“能不能找到”。单纯对用户输入的每个词做OR匹配长尾场景噪音会很大做成AND匹配漏召回又太严重。Sirchmunk的召回逻辑分三层。第一层是核心必达所有查询词必须命中的文档集合要求严格AND匹配这部分是精确答案的候选池。第二层是宽松层去掉其中一个低频词后命中的文档集合主要解决用户多打了一个词、或者词序颠倒的问题。第三层是扩展层通过同义词和近义词扩展后的词项参与匹配这块由自进化模块动态维护。字段加权在召回阶段就起作用。标题命中权重远高于正文标签字段命中权重高于摘要。这不是排序阶段再做的事因为权重会直接影响初筛时候选集的大小。比如标题命中的文档哪怕频次只有一次也比正文频次五次更有机会进候选集。所以索引构建时不同字段的词项会写入各自独立的倒排列表查询时按字段加权合并打分。短语召回在这套架构里是独立处理的。查询解析器会先识别短语片段比如带引号的内容、连续的英文词组或ID串。短语作为一个整体词项去匹配索引里预建的phrase倒排列表。预建短语索引是在文档入库时用N-Gram滑窗抽出来的代价是索引稍大但查询时短语精度非常高工单号、版本号这类检索尤其受益。2.3 排序模型特征设计加打分函数倒排召回之后Sirchmunk的排序分两个阶段。第一阶段是快速粗排用BM25加少量静态特征过滤目标是快速砍掉明显无关的文档把候选集压缩到几百个。第二阶段是精排用GBDT模型对几百个候选逐条打分。精排用到的特征分为三类。文本特征BM25分值、词项覆盖率、短语命中数、标题命中权重、核心词距离等。行为特征文档历史点击率、平均停留时长、收藏数、转发数这些来自反馈数据。时效特征文档新鲜度指数衰减函数处理。模型训练用LambdaMART损失函数直接优化NDCG对排序任务来说比普通回归准确得多。初期没有训练数据时先用规则打分函数做兜底等反馈日志攒够十万级会话再切模型。这是整套架构里为数不多必须等数据的地方急不来。2.4 中文场景的切词与过滤如果只处理英文分词简单许多。但Sirchmunk面对的中文内容必须做专门的切词。我们采用“词典分词加统计分词结合”的策略通用词典负责日常词领域词典负责产品名、系统名、内部代号。统计分词用条件随机场训练一个序列标注模型解决未登录词。有个细节是过滤词表的动态性。传统实现会把“的、了、吗、呀”这类停用词直接丢掉但内部文档里很多核心语义恰恰藏在短词里。比如“上云”里的“上”“下线”里的“下”。所以Sirchmunk没有用固定停用词表而是用“词频加文档频率”联合判定高频且区分度低的词自动降权但不会直接删除。这个策略比静态停用词表效果好不少。3. 自进化机制反馈闭环怎么做自进化是Sirchmunk区别于普通搜索框架的核心设计。很多人以为只要记录点击日志就算闭环实际差了很远。真正要跑通闭环需要把信号采集、归因、更新、验证四件事全部自动化。3.1 三类反馈信号第一类信号是显式反馈。用户点了“有用”或“没用”按钮这是最干净的信号但数量稀少通常占全部行为的不到2%。任何推荐系统都不能只靠它但也不能没有它。第二类信号是隐式反馈。点击、停留时长、二次搜索比例、翻页深度这些信号量大但噪音也大。点击不一定是满意可能是标题党停留时长长不一定是内容好可能是没看懂。处理隐式信号的关键是设置阈值和置信度比如点击位置在前三但停留不超过三秒标记为低置信度正反馈不参与模型更新。第三类信号是外部反馈。比如新文档被高频引用、代码片段被反复粘贴这类信号与具体搜索会话无关但对文档权重有天然加成。Sirchmunk会把外部信号折算成静态分直接进入精排特征。3.2 在线日志与归因模块日志采集不在业务代码里堆打点而是统一走搜索中间件。查询词、命中的文档ID列表、展示顺序、用户点击序列、后续行为全部汇聚到日志管道。这里的核心难点在归因用户点了结果B但B展示了三个到底是因为排在第一的A太差还是因为B标题写得好需要合理分割归因。Sirchmunk的归因模块没有用复杂的因果推断就是用“逆位置权重”法用户在位置一的点击权重高在位置五的点击权重低同时考虑展示时间序列。这样能得到一个“如果结果排序变化预期点击会怎样变化”的近似信号用于训练排序模型基本够用。3.3 词典与同义关系的自动演进搜索系统最常见的badcase是“用户搜的词文档里没有但文档内容明明相关”。Sirchmunk靠动态同义词来解决。初始词典是人工导入的几十组常见同义词比如“宕机”等于“挂掉”等于“不可用”。但真实世界的词汇变化快人工维护跟不上。自动演进采用“点击停靠分析”当两个不同查询词触发了同一条文档被点击且查询词本身又不相似时就会把这两个词的关系强度加一分。例如用户搜“证书过期”点了文档X另一个人搜“SSL失效”也点了文档X多次重复后系统自动建立起“证书过期”与“SSL失效”的相关关系。累积关系度超过阈值后写入同义词词典参与后续查询扩展。这个过程完全不需要人工参与运行三个月后词典自动膨胀了差不多三分之一。3.4 排序模型周期性重训练与A/B验证排序特征和模型权重不能每天变否则用户会感觉结果飘忽不定。Sirchmunk采用固定进化窗口每周日凌晨跑一次离线训练用上一周日志生成新的排序模型然后切到小流量验证。验证采用分层A/B方式5%流量的对照组用上一版模型5%实验组用新模型观察点击率、无结果率、二次搜索率、平均停留时长等指标。只有连续两周正向指标显著时才全量上线。这里最重要的一条经验是不要因为单周指标好看就急着全量噪音周期普遍存在。4. 实操实现模块划分与关键流程模块划分决定了后续迭代是舒服还是痛苦。Sirchmunk把整个检索链拆成六块每块职责单一中间通过接口通信边界非常清晰。4.1 六个核心模块与数据流向查询网关负责接受请求、鉴权、限流把原始查询转成内部查询对象。分析模块做分词、词性标注、意图识别、查询改写。检索模块做倒排召回、短语匹配、候选集合并。排序模块加载特征和模型完成粗排与精排。反馈采集器负责把搜索结果页面行为写入日志管道。进化引擎定期消费日志产出新词典、新权重、新模型。数据流向是单向的查询进入网关后一路向下结果返回前端同时用户行为回流到日志管道进化引擎处理后把产物推给索引与排序模块。这个结构好在哪里任意模块可以独立升级比如分析模块换一套分词器不影响检索和排序排序模型重训练不需要动索引。解耦带来的直接好处是每次改动都只需要在单模块内测试风险大幅降低。4.2 索引更新的实时通道索引不能是全量重建Sirchmunk采用“主索引加增量段”的模式。新文档进来先写入增量段内存里维护一个小时级的小索引查询时合并主索引和所有增量段。每隔一段时间增量段合并进主索引。这种架构与Lucene的段合并思路一致但自己实现时要注意合并策略和删除文档的清理。实时性上文档入库到可以被搜到默认延迟是三十秒以内。增量段写满一定阈值或达到时间上限就触发合并合并过程中不阻塞查询用的是写时复制加原子切换目录的方式。这个设计被验证得很稳线上很少因为索引合并导致查询抖动。4.3 自进化调度与版本管理进化引擎不是一直在跑而是有节奏地执行。调度器按天触发任务链拉取日志到离线表清洗数据归因分析产出候选同义词训练排序模型生成实验配置。版本管理容易被忽略。Sirchmunk要求每次进化的产物都有完整版本记录包括数据时间范围、模型参数、特征字典快照、同义词变更集。这样做的好处是一旦新版本效果不佳可以快速回滚到旧版本。回滚粒度要细化到单产物比如只回滚词典不动模型。4.4 最小可运行实现方案如果你不打算完整复刻Sirchmunk想先用最小方案跑通闭环可以参考这个顺序。第一步搭一个带BM25的倒排索引查询服务用现成的检索引擎库就能实现。第二步在结果页埋点记录查询词、结果顺序、点击事件落日志。第三步做离线的点击归因分析产出词对相关度信号。第四步将高置信度的词对写入同义词表重启加载。这四步做完你就已经拥有一个能自我进化的最小搜索系统。全程不需要运维向量数据库也不需要大规模GPU训练。5. 常见问题与排查实录这部分是排障经验很多情况是跑了一段时间之后才暴露出来的值得单独记录。5.1 明明有文档却搜不到最常见的原因是分词不一致。文档入库时“OCR”被切成一个词用户查询时“o c r”被拆成三个字母两边对不上。排查思路是先看分析模块的输出把查询词分词结果打出来确认词典里是否存在这个词。如果确实没有就会走未登录词策略下次入库时自动学习。另一个原因是过滤条件误伤。比如时间范围默认只查三个月但用户找的是一年前的历史方案。这种问题定位很快检查查询日志里的过滤参数即可。5.2 找到了结果但排名靠后典型的排序权重问题。Sirchmunk初期特征权重依赖人工调节经常出现标题含精确关键词的文档排不到前面。后来引入模型训练后这个问题大幅缓解。但有一个隐藏点精排阶段没有纳入“标题完整匹配”这一强特征导致模型学到的是碎片化信号。补充该特征后排序准确度明显提升。5.3 自进化改完词典效果反而变差这是自进化系统典型的过拟合风险。某段时间大量用户搜“登录失败”第一次搜“登录失败”没结果第二次搜“验证失败”点了文档系统就建立了强关联。但两周后该问题修复用户不再搜“登录失败”这个关联却仍然是高权重于是搜“登录失败”时总会返回过时文档。解决办法有两条一是同义词必须有时效衰减太久没有共同点击就不再强化二是新增词对先进入灰度词典只影响小流量观察一段时间再全量。5.4 索引文件膨胀磁盘告警增量段合并策略不当时会产生大量冗余段文件。常见治理办法是限制最大段数量并定期做全量重合并。同时把删除文档的清理从“标记删除”改成“合并时真正物理清除”可以显著降低存储占用。Sirchmunk演进过程中踩过的最深的一个坑是重排序模型上线后效果不如老版本但指标差异一天看不出来三天观察期内用户流失已经发生。所以自进化迭代必须要能快速回滚而且一定要设定最低实验周期不能只看短期波动。这套机制跑到现在最大的感受是搜索系统真正的好处来自稳定可控的演进节奏而不是某个时段的大改大动。下次拆排序模型特征时再单独聊细节。