过去两年，很多团队搭 RAG 的第一反应是押模型：换更好的 embedding、上更大的 LLM、把 top_k 调大。但最近一周知乎上密集出现的几篇工程复盘，指向了同一个更朴素的事实：召回不行，先别急着换模型，问题往往出在"只有一路检索"上。
有工程师用 100 条混合了专有名词、报错代码和口语化转述的测试集实测，单路向量召回的 Top-5 命中率只有 40% 上下，换成 BM25+向量双路召回、RRF 融合、Cross-Encoder 精排之后，命中率提到 85% 以上。知乎同一周里，从检索栈演进分析到 RRF 融合细节，"混合检索"的讨论密度明显压过了模型选型——对已经在跑纯向量知识库的团队来说，这才是此刻真正要回答的问题：要不要跟？
混合检索为什么在 2026 年成了默认配置
把几个独立信源摆在一起看，证据链是完整的。独立基准方面，denser.ai 2026 年的对比基准显示，混合搜索相比纯向量搜索带来 NDCG 提升 7.4%、精度提升 0.229 倍。知乎行业综述给的口径更宽：关键词+语义混合相比单一检索方式，可为 RAG 带来约 10-30% 的精度提升——但注意，这是别人语料上的综述区间，不是你的 SLA，实际增益高度依赖查询分布。工程侧的旁证更直接：RRF 这种排名融合算法不需要训练、7 行代码就能实现，如今 Elasticsearch、OpenSearch、Weaviate、Qdrant、Azure AI Search 全都内置了它。知乎主流引擎集体把"双路召回+融合"做成默认能力，本身就是趋势的证据。
甚至硬件厂商都开始为检索负载做专用芯片：Dnotitia 在 FMS 2026 上展示了 VDPU 向量检索芯片并拿下 AI Application Award，官方口径是传统架构下向量检索会吃掉宿主 CPU 70-90% 的利用率，专用硬件能把它压到接近 0。知乎这条消息目前只有厂商单源、没有第三方基准，中小团队完全可以只看不动；但它透露的信号很清楚——检索层的计算负载，已经大到有人愿意为它做一颗芯片了。
纯向量检索撞的到底是什么墙
向量是对文本的有损压缩。向量检索擅长把"网页连接被重置怎么办"匹配到"TCP 连接被对端中断的排查方法"，但未必稳定保留 ERR_CONNECTION_RESET、0x80070005、补丁编号、显卡型号或内部表名。知乎而真实用户的查询恰好是两类信号的混合：自然语言描述，加上不能改写的实体。BM25 不理解语义，却会给稀有词更强的区分度，错误码、型号、内部缩写这类"不能换说法"的词，正是它的主场。所以生产 RAG 的稳健基线通常是稀疏与稠密两路并行，而不是押注单一路径。
升级后的典型管线长这样：一次 embedding 调用，BM25 与向量两路并行召回，RRF 按名次融合出 Top30，Cross-Encoder 精排出 Top5，再回表拉完整父块送进 LLM；embedding 服务异常时自动降级为纯 BM25，业务不被第三方接口绑架。两阶段的分工也很清楚：Retriever 要快、负责覆盖，Reranker 可以慢、只处理几十个候选。第一阶段漏掉的文档，第二阶段无法创造出来。知乎所以顺序永远是先保召回，再谈排序质量。
冷水：混合检索不是万能药
先看一个反例。有作者拿 DeepSeek App 的真实引用频次当"标准答案"做对比实验，结果融合反而把相关性的 0.653 拖到了 0.12。知乎原因不复杂：这组数据里 BM25 那路是纯噪声，融合时它贡献的不是证据，是干扰——等于让一个完全不懂行的人参与投票。
所以该不该融合，本身要先验证。混合检索要先用小样本验证两路各自的独立价值，再决定要不要融合。知乎RRF 解决的是"怎么融合"，"该不该融合"是另一个问题。增益的分布也要说清：错误码、型号、专有名词越多的语料，BM25 那路价值越大；纯语义改写的 FAQ 型语料，混合的收益就小得多。10-30% 是综述区间，你的增益只能自己测。
升级决策卡：先回答三个问题
第一，标准答案所在文档有没有进入候选集？这是两种完全不同的病：Recall@50 下降，多半是召回或过滤问题；Recall 不变、MRR 下降，多半是融合或精排问题。知乎前者要修索引、分词和切块，后者才轮到调融合和精排——先诊断，再开药，别一上来就重构。
第二，两路是不是各自都有独立价值？用几十条标注样本分别看两路的召回表现，任何一路是纯噪声，就别融合，上面的 0.653 到 0.12 就是教训。
第三，有没有一个哪怕只有 200 条的评测集？可以从线上日志抽取 200 条代表性查询，删除隐私信息，再由熟悉业务的人标注强相关、部分相关和不相关文档。知乎没有评测集就升级，等于凭手感拆管线，升完也不知道是赚是亏。
按这把尺子量，结论很分明：查询里混着大量错误码、型号、版本号和内部缩写的团队（运维知识库、产品手册、制度合规库），升级收益最直接；纯语义 FAQ、语料不大、且已经加了 rerank 的团队，可以先不动，把精力花在评测集上。
融合这步，RRF 是目前最稳的默认选择：它不比较原始分数，只看文档在每一路排第几，天然免疫 BM25 与余弦相似度的量纲差异。最常见的错误是直接把两路原始分数加权相加——直接写 0.5 * bm25 + 0.5 * cosine，权重看似均衡，实际可能完全由一方支配。知乎RRF 的代价也要认：它丢失分数的绝对判别力，差的检索器会带噪进场。简单、少假设，就是它活了十几年的原因。
真升级的话，这四笔成本绕不开
双索引维护。文档更新时，BM25 与向量索引可能短暂看到不同版本，候选集随时间抖动；chunk 需要带 document_version、indexed_at 这类版本字段，换索引走"建新索引、验证后切别名"，而不是原地改一半。
融合与精排的算力。双路召回、融合、重排每一步都吃 CPU；Cross-Encoder 把查询和候选一起读，能区分否定、版本和条件差异，但没法对全库逐一计算，只能处理召回后的几十个候选。先保 Recall，再在效果目标下控制精排规模，是成本与效果的平衡点。
模型锁定。如果升级的同时还想顺手换 embedding 模型，请记住：换模型等于重建索引。不同模型的向量空间不通用，切换模型必须把整个知识库重新向量化。知乎今年开源阵营卷得很快，Qwen3-Embedding、KaLM、Conan-v2 轮番登榜，但越是这样，越要上线前把模型定死，别图新鲜来回换。
还有一个视角值得借鉴：把检索看成分层工具箱，而不是单一管线——少量稳定上下文垫底，实时精确检索和语义混合检索各管一层，重大结论回到原始来源验证；先用便宜线索定位，证据不足再逐级升级。混合检索不是终点，它只是这个工具箱里的 L2 层。
两个容易被漏掉的新变化
一是检索层正在变成攻击面。2026 年的一篇 arXiv 论文提出 TabooRAG：攻击者只需向知识库注入一篇构造的"风险语境文档"，模型的安全对齐就会把良性查询一并判为需拒答内容，9 个主流 LLM 上的阻断攻击成功率达 59.1%-77.4%。知乎这是单篇论文的结论，防御仍是开放问题，但最低成本的防御现在就能做：在知识库写入管线里加语境异常检测，新文档与已有内容主题分布距离过远却能被高频召回，就触发人工审核。另外别忘了无答案门禁：混合检索会提高"找到某些东西"的概率，却不保证找到的内容足以回答。知乎精排分低于校准阈值时，让系统说"证据不足"，比强迫 LLM 拼结论体面得多。
二是检索的控制权在转移。这周知乎上"Agent 为什么重新用回 Grep"的讨论很热，高赞回答的结论并不是 Grep 战胜 RAG：真正发生的变化，是检索的控制权从固定流水线转移到了 Agent。知乎对你现有知识库的启示是：RAG 未必消失，但会越来越像 Agent 工具箱里可被调用的一层，而不是生成前的固定工序。今天为混合检索打的评测集、建的版本字段，将来同样是 Agent 检索的基础设施，不白花。
下一步
别急着拆管线。先花两天做 200 条评测集，把"正确文档进没进候选集"这个问题量化；再决定是加 BM25 那路、调融合，还是继续打磨单路。该等的等，该升的升。2026 年的 RAG 工程，最值得追的不是新名词，而是自己评测集上的证据。
