检索系统七次演进：从BM25到生成式检索的完整技术脉络

引言：检索系统的思维框架

信息检索（Retrieval）与排序（Ranking）系统是搜索引擎、推荐系统乃至当今RAG（检索增强生成）架构的技术基石。然而，在实际工程实践中，很多开发者容易陷入一个误区：认为新技术总是对旧技术的替代。

近期，一位技术博主在Reddit上分享了一张关于检索系统演进的思维导图，并配以详细的文章说明。他提出了一个清晰的演进脉络，将检索技术的发展划分为七个阶段（或称为「浪潮」）。这个框架的价值不仅在于梳理历史，更在于揭示了一个关键洞察：这些方法并非相互取代，而是层层叠加、协同工作的。

七次演进浪潮的全景

作者提出的演进路径如下：

词法检索 → 协同/行为检索 → 学习稀疏检索 → 稠密/双塔 → 混合检索 → 多向量/多模态 → 生成式/智能体检索

下面逐一拆解每个阶段的技术内涵与产生背景。

第一波：词法检索（Lexical）——BM25与TF-IDF

最经典的代表是 BM25 和 TF-IDF。这类方法基于关键词的字面匹配与词频统计，核心思想是「查询中出现的词，在文档中出现得越多、越稀有，相关性越高」。

词法检索的优势在于可解释性强、计算高效、无需训练，至今仍是许多生产系统的默认基线。它的短板也很明显：无法理解语义。「汽车」和「轿车」在字面上不匹配，就会被判为不相关，这就是所谓的「词汇鸿沟」（vocabulary gap）问题。

第二波：协同/行为检索（Collaborative/Behavioral）

这一阶段引入了用户行为信号——点击、购买、停留时长等。协同过滤是推荐系统的核心思想：「喜欢A的人也喜欢B」。

行为信号的价值在于它捕捉了内容本身文本无法表达的「群体智慧」。但它同样存在冷启动问题：新物品、新用户缺乏交互数据时表现不佳。

第三波：学习稀疏检索（Learned Sparse）——SPLADE与DeepImpact

以 SPLADE、DeepImpact 为代表的学习稀疏检索，试图融合词法检索的效率与神经网络的语义理解能力。它依然产生稀疏向量（便于用倒排索引加速），但每个词的权重由神经网络学习得出，并且能够做「词项扩展」——为文档补充语义相关但字面未出现的词。

这一阶段可以看作是传统检索与深度学习之间的桥梁。

从稠密表示到混合融合

第四波：稠密/双塔检索（Dense/Two-Tower）

随着 BERT 等预训练语言模型的成熟，稠密检索成为主流。双塔（Two-Tower）架构分别用两个编码器将查询和文档映射到同一低维向量空间，通过向量相似度（如余弦相似度）衡量相关性。

配合 ANN（近似最近邻） 索引技术（如 HNSW、FAISS），稠密检索能在百万乃至十亿级向量中实现毫秒级召回。它真正解决了语义匹配问题，但代价是可解释性下降，且对训练数据质量高度敏感。

第五波：混合检索（Hybrid）——BM25与稠密检索的协同

实践很快证明：稠密检索并非万能。它在处理专有名词、代码、数字等精确匹配场景时反而不如 BM25。于是混合检索应运而生——同时运行词法检索和稠密检索，再通过融合策略（如 RRF，倒数排名融合）合并结果。

这正是作者强调的核心观点：一个成熟的生产系统往往同时包含 BM25、稠密检索、ANN、混合融合、行为信号以及查询改写。它们不是替代关系，而是各司其职的组件。

走向多模态与生成式检索的前沿

第六波：多向量/多模态检索（Multi-Vector/Multimodal）

单个向量表示整篇文档会丢失细粒度信息。以 ColBERT 为代表的多向量检索，为文档中的每个 token 保留独立向量，通过「后期交互」（late interaction）机制实现更精细的匹配，在精度上显著优于单向量方案。

另一边，多模态检索打破了文本的边界——图像、音频、视频都可以被编码进统一的语义空间，实现「以文搜图」「以图搜图」等跨模态检索能力。

第七波：生成式/智能体检索（Generative/Agentic）

最新的浪潮将大语言模型直接融入检索流程。生成式检索让模型直接生成文档标识符或答案，而智能体检索（Agentic Retrieval）则赋予系统自主规划的能力：模型可以自行分解查询、多轮检索、评估结果质量、决定是否需要补充搜索。

这一阶段与当前火热的 RAG 和 AI Agent 架构深度融合，代表着检索系统从「被动响应」向「主动推理」的范式转变。

核心洞察：叠加而非替代

这张思维导图最有价值的地方，并非罗列了七个技术名词，而是传递了一个工程哲学：检索技术的演进是累积的。

新方法的出现从来不是为了让旧方法退役，而是为了填补旧方法无法覆盖的场景。当你构建一个真实的生产级检索系统时，很可能会看到 BM25 处理精确匹配、稠密向量处理语义泛化、行为信号引入个性化、查询改写优化召回、生成式模块提供最终推理——所有这些技术在同一条流水线上协同运转。

理解这一点，有助于工程师避免「盲目追新」的陷阱，转而根据业务场景的具体需求，选择恰当的技术组合。对于正在搭建 RAG 系统的团队而言，这份演进框架也是一份实用的技术选型地图。

注：本文基于 Reddit 社区分享的单一来源整理，作者的完整文章仍在撰写中，感兴趣的读者可关注其 Substack 后续更新。