语义搜还是关键词搜：Semantic、BM25 与 Hybrid Search

前置：一次检索请求怎样被约束：Retriever、Metadata Filter 与 Query Rewrite
核心问题：查询错误码、符号名和自然语言问题时，什么时候 Semantic Search 更好、什么时候 BM25 更稳，Hybrid 应怎样组合两类信号？

“如何限制并发请求”和“Semaphore usage”可能语义接近，即使词面不同也能召回。搜索 RunState 、 HTTP 429 、 GS-00601 时 lexical 信号往往比纯语义向量更稳定。

Semantic Search

Semantic Search 用 embedding 相似度找语义接近内容，擅长同义改写和自然语言概念；对精确 ID、数字、错误码和稀有 token 往往不稳定。它的 score 只表示向量空间相似度，不等于事实相关性，更不能替代 ACL/metadata filter。

Keyword / BM25 Search

Keyword/BM25 直接利用词项匹配，对错误码、函数名、产品型号和稀有 token 很强且可解释；弱点是无法自然覆盖大量同义改写。它与向量检索是互补关系，而不是“旧检索被新检索替代”。

Hybrid Search

Hybrid Search 先合并 lexical 与 semantic 候选，再用加权、RRF 或 reranker 形成统一排序。真正需要调的是 candidate pool、融合方法和 rerank 深度；这些参数必须由 retrieval eval 决定，不能直接把不可比较的原始 score 相加。

为什么 Hybrid Search 往往比“只选一种”更稳

假设代码库里真实符号叫 RefreshTokenValidator，用户问的是“登录续期为什么偶尔失效”。

• BM25 很擅长命中 RefreshTokenValidator、错误码、配置键这类字面信号；
• Semantic Search 更容易找到“token renewal / session refresh / credential rotation”等语义接近但措辞不同的文档；
• 单独依赖任何一边，都可能在另一类查询上失手。

一个常见做法不是直接把两个原始分数相加——BM25 与向量相似度的数值尺度通常不可比——而是先分别排序，再做 rank fusion。例如 Reciprocal Rank Fusion 的直觉是：某结果只要在任一检索器里排名很靠前，就应该获得明显权重；同时在两边都靠前则进一步增强。

query
 ├─ BM25 --------┐
 │               ├─ rank fusion → rerank → top-k
 └─ vector ------┘

工程上真正要调的不是“hybrid 好不好”，而是：哪些 query 值得双路搜索、各取多少候选、fusion 后是否还需要 rerank，以及这些选择对 recall、latency 和 token cost 的影响。

Failure Modes

直接把不可比较的 Search Score 相加

症状： BM25 分数与向量相似度未经归一/校准就线性求和。

为什么危险： 某一路分数量纲会压倒另一条，所谓 hybrid 实际退化为单路检索。

处理： 使用 RRF、rank fusion 或基于 eval 校准的归一策略，并记录各路 rank/score。

如何验证

Case	断言
直接把不可比较的 Search Score 相加	构造 lexical-only 与 semantic-only 各自占优的 query，验证 hybrid 能稳定召回两类证据。

自测

1. 搜索 ERR_AUTH_4017 与搜索“为什么登录后立即过期”，哪一个更依赖 BM25，哪一个更适合 semantic signal？
2. 为什么不能直接把 BM25 score 和 cosine similarity 原样相加？Hybrid ranking 至少需要怎样处理两类不可比信号？

Sources

• OpenAI API — Vector stores
• LangChain — Retrieval
• LangGraph — Agentic RAG
• LangChain — Cross encoder reranker