做搜索 2 年，我对召回策略的 3 个认知升级

做搜索相关开发 2 年了，从最初只懂 BM25，到后来引入向量召回、混合召回，认知上有过几次比较大的升级。把这些升级过程记录下来，希望对刚入行做搜索的同学有帮助。
第一次升级：从"召回 = 关键词匹配"到"召回 = 相关性预测"
刚入行时以为搜索召回就是"关键词匹配"——用户搜什么词，文档里有什么词就匹配上。
直到接手一个真实项目，搜索质量被业务方反复吐槽，才发现召回远不止关键词匹配那么简单。
用户搜"苹果手机"——文档里有"iPhone"、"苹果公司"、"Apple Inc."、"水果苹果"——这些都是潜在相关但关键词不直接匹配的。
召回的本质不是"匹配"，是"预测相关性"——预测这个文档和用户查询之间是否存在有用的关联。关键词匹配只是其中一种预测方式，向量匹配、协同过滤、知识图谱也都是预测方式。
这个认知升级之后，看任何召回策略都会先问一句：它在预测什么相关性？预测得准不准？和其他召回方式互补还是冲突？
第二次升级：从"召回效果优先"到"召回效果 + 性能"平衡
第二个升级是在做大规模搜索系统时被逼出来的。
最初版本召回层用了 5 路召回（BM25 + 4 路向量），效果确实好，P99 准确率比单路高了 12 个百分点。
但上线后 P99 延迟从 80ms 飙到了 350ms——业务方反馈"搜索太慢"。
排查后才发现：5 路召回每路都要查一次向量库，总延迟是叠加的。线上流量高峰时 5 路同时跑，QPS 顶不住。
最后砍到了 2 路召回：BM25（必选）+ 主向量召回（按业务定制）。效果掉了 3 个百分点，但 P99 延迟降到了 120ms，业务方也满意了。
这次升级让我意识到：召回层设计不是"召回越多越好"，而是"在效果和性能之间找平衡"。工业级搜索系统里，性能不达标，效果再也没用。
第三次升级：从"召回是个黑盒"到"召回是个数据流"
第三个升级是在做 AB 实验平台时想通的。
最初做召回策略优化都是凭经验：调调权重、改改阈值、看效果好不好。但每次优化都像开盲盒——这次好了下次可能就差了。
后来做了一套 AB 实验平台，把召回的每个环节都拆成可观测的数据流：
每路召回分别返回多少条
各路召回的重叠率是多少
排序层最终挑出来多少条来自各路
用户最终点击了哪几条
把这些数据可视化后，召回策略优化就从"凭感觉"变成了"看数据"。比如发现"BM25 召回贡献了 70% 的点击但只占 20% 的召回量"——说明 BM25 在这个场景下权重应该加大；反之"向量召回贡献了 20% 的点击但占 60% 的召回量"——说明向量召回的权重可以降低。
这个升级让我认识到：召回层不是"装好就跑"的静态系统，而是"持续观测、持续调优"的数据流工程。
搜索召回这个领域，入门容易、精通难。新人最容易踩的坑就是"只看效果数字，忽略工程现实"。建议做搜索的同学：
先把基础原理（BM25、向量召回、混合召回）吃透
再学性能优化（索引、缓存、降级）
最后学 AB 实验和数据驱动优化
每一步都要有真实的项目练手，光看文档永远学不会。