摘要：前一阵子，我们的剪辑师跟播客编辑天天抱怨这事儿。用语义检索去找“约会的搞笑时刻”还凑合，但一旦用户敲下“第281集”，结果就很让人抓狂：跑出第280、第282，甚至第218。有人搜“她说了什么”，系统把“他说了什么”也拉进来。对做短视频和二次创作的人来说，这等

现在的搜索能直接把“第281集”的片段准确找出来。

前一阵子，我们的剪辑师跟播客编辑天天抱怨这事儿。用语义检索去找“约会的搞笑时刻”还凑合，但一旦用户敲下“第281集”，结果就很让人抓狂：跑出第280、第282，甚至第218。有人搜“她说了什么”，系统把“他说了什么”也拉进来。对做短视频和二次创作的人来说，这等于把本该几分钟的活儿拉成几个小时：帧要一帧帧翻，思路被打断，时间成本直线上去了，内容复用和变现效率也跟着掉链子。

我们先把问题摸清楚，再去改。团队从2025年1月开始做技术和业务调研，用私有数据集跑了一轮又一轮的测试，对比了可选方案的利弊。到5月敲定了整体方案，6月把功能做出来、测过、上线。中间没偷懒，既做了端到端的跑测，也把替代方案的坑挨了个遍。

有个备选方案是再扛起一套传统关键词引擎，像 Elasticsearch 或 MongoDB，跟现有的 Milvus 并行跑。表面上看这是捷径，关键词精确匹配一来就有效果；但引入另一套系统的代价也够硬：运维入口翻倍，系统复杂度上天。而且更关键的一点，简单先按关键词筛一遍再用图索引，会把图结构给断掉。图索引靠大量候选节点保证召回，一旦筛得太狠，图就不连通，检索反而退化成暴力搜，慢又不稳。

最后决定继续把活儿放在 Milvus 里做功能增强。几个原因挺实在：社区活跃、迭代稳，养一套总比养两套省心。Milvus 新出的全文搜索模块在默认状态下对部分匹配已经有明显改进，能把像“喝酒场景”被误判为“用餐场景”这种错检率降下来。更重要的是，我们通过一系列内部策略，把关键词检索和向量检索融合在同一个生态里，既解决精确匹配问题，又没把原来的图检索搞垮。

技术上，架构是双核心的玩法：先用 Milvus 的 TEXT_MATCH 做关键词过滤，基于 BM25 做相关性排序，然后把这个精确匹配模块的结果和原来的语义模块融合。流程挺直观——先把包含用户关键词的文档筛出来，用 BM25 评估相关度，再根据用户选择（关键词模式或语义模式）走不同路径。还有更智能的一条路子：系统能识别混合类查询，比如“找到第281集的搞笑片段”，自动把“第281集”交给精确匹配，把“搞笑片段”交给语义检索，最后把两类结果合并排序。

实现里有些细节不能马虎。停用词这档子事儿不能随手删：业务里“THE Office”和“Office”不是一回事儿，任何词都得留着。要把词形变换处理好，比如 running 和 run 要还原，保证召回稳定。BM25 参数也经过调优：bm25_k1 设成 1.2，稍微多看词频；bm25_b 设成 0.75，对长文本有合适惩罚。为了让排序快点，文本字段先被转成稀疏向量，用 SPARSE_INVERTED_INDEX 类型做索引。还有 Alpha 策略、ACORN（近似聚类加随机邻居过连接）、动态邻居选择和元数据感知索引这些技术点，让引入关键词检索后，图结构不至于塌陷，检索成本也没被炸开。

开发过程中，团队在几处设计权衡上磨了很久。第一，先过滤再排序能保证精确度，但过滤不能太狠，否则会把有用的候选点一并扔掉。第二，坚持用单一数据库是好，但得确保语义图在过滤后还能保持连通性。第三，产品要给用户选项，但也不能把普通用户逼成工程师——于是既提供手动切换，也做了自动识别，让系统自己判断走哪条检索路径。

上线后，编辑们的痛点基本被命中：能准确找到“哪一集”“哪句台词”或特定场景，同时保留了语义检索在发现相关片段上的能力。工程上虽避免了再拉一套系统，但在 Milvus 里做了更深的索引、参数调优和大量边界场景验证，投入的精力并不少。要把语义和精确检索放在同一张图里听起来省事儿，实际上要把索引、过滤、排序三块的界线划清楚，尤其得防止图检索在低召回时崩盘，这一点我们一直盯着。

现在的体验是，普通用户可以什么都不管，直接输一句话让系统判断；进阶用户可以手动选关键词模式或语义模式；做剪辑的同事也能直接搜“第281集 第12分钟 有趣对白”，系统会把精确词先锁定到那集，再把语义部分拉开来匹配相关片段，最后把结果按相关性摆好。系统里还有开关控制 TEXT_MATCH，便于在特殊业务下关闭或调参，防止一刀切带来副作用。

来源：小杨科技观