搜『手机没电了』，返回一堆『电池续航短』的帖子——这事在十年前属于奢望。那时候你少打一个字，搜索引擎就当你没说过话。
关键词检索的死板，其实很好理解
倒排索引干的事情很朴素：建一张词到文档的映射表。你输入哪个词，它就去找哪个词。改一个字，结果可能天差地别。
举个例子。电商后台搜『防水鞋』，商品标题写的是『雨天不湿脚』。传统方案给你零结果。用户骂骂咧咧走了，商家还不知道自己丢了单子。
这不是算法笨。是它压根没打算理解『意思』这回事。
向量空间里，『意思近』就是『距离近』
语义检索换了个思路。把句子丢进模型，吐出一串数字——几百到上千维的坐标。业内管它叫 embedding。
『我饿了』和『肚子咕噜叫』，在这堆坐标里挨得很近。怎么算近？余弦相似度，看两个向量的夹角。夹角小，分数高。
说实话，这玩意儿并不真的『懂』你在说什么。它只是在海量语料里见过太多次共现，统计上觉得这俩该放一起。
有意思的是，很多团队第一次看到相似度打分时会懵。0.83 到底算高还是低？
没有标准答案。得看你自己数据的分布。有的领域 0.7 就算强相关，有的领域 0.95 才算。
能搜到，和搜得准，是两码事
这是新人经常踩的坑。
坑一：精确查询被『泛化』掉。用户搜订单号 A12345，语义模型可能热情地推给你一堆 12345 开头的无关文档。这时候倒排索引反而稳。
坑二：领域词不认。医疗、法律、工业设备型号，通用 embedding 经常翻车。型号 KX-2080B 和 KX-2080C，在向量空间里可能几乎重合。
坑三：短 query 飘。三个字的搜索词信息量太少，向量指向模糊。长文档和短查询之间还横着一道天然的长度鸿沟。
坑四：成本。全量重建索引不便宜，做增量又得处理一致性问题。
所以现在比较常见的做法是混合检索：BM25 拉一路，向量拉一路，合并候选池，再上一个重排模型精排。
从实操角度看，召回阶段宁可多召一点，反正重排会砍掉。指望一步到位？不现实。
阈值别拍脑袋，评估别只靠感觉
改造完上线，大家第一反应往往是『好像准了』。这个不能当结论。
得看指标。召回率、MRR、NDCG@10。还要分层看——头部热门 query 和长尾 query 的表现经常是两个世界。
据一些用户反馈，语义检索上线后长尾查询的点击率改善明显，但头部高频词的提升有限。原因不难猜，高频词早就被同义词表和各种人工规则覆盖了。
相似度阈值也一样。先拿几百条标注数据画个分布曲线，再决定卡在哪儿。0.6 还是 0.8，是靠数据说出来的，不是开会拍出来的。
还有一点常被忽略：坏 case 要存下来。今天修好的坑，明天调个模型版本可能又塌回去。
语义匹配不止用来搜东西
它的用武之地比想象中杂。
客服 FAQ 匹配——『怎么退款』和『钱什么时候退回来』该命中同一条答案。工单去重——两句描述不同但说的是同一台设备故障。商品同款识别、内容推荐召回、评论情感聚类，都在用同一套底层逻辑。
但边界也得说清楚。语义检索解决的是『表达差异』，不是『意图理解』。用户真正想要什么，模型猜不出来，还得靠行为数据和业务规则去补。
如果语料规整、查询以编号和专有名词为主，比如日志检索、内部工单系统——关键词方案够用了，别硬上向量库。如果是电商、社区搜索、知识库问答、RAG 检索，用户爱用大白话，那这笔投入值得。
您在搭检索系统时遇到过哪些奇怪的分词或召回的坑？欢迎结合具体场景继续聊聊。
