布吉岛 Agent

Appearance

第 5 章 Embedding、BM25 与混合检索 ​

这一章开始正式进入 RAG 的检索层。

前面几章已经回答了这些问题：

  • 数据从哪里来
  • 数据怎么清洗
  • 为什么要切块
  • metadata 应该怎么设计
  • 索引怎样组织和维护

接下来就要继续往前走一步：当用户提问时，系统到底靠什么把相关内容找回来。

这一章讨论的核心不是某个具体框架 API，而是四个更底层的问题：

  • Embedding 到底在表示什么
  • 向量检索为什么能做语义召回
  • BM25 这类关键词检索为什么并没有过时
  • 为什么很多生产系统最后会走向混合检索和多路召回

学这一章时，最值得先建立的判断 ​

  • Embedding 解决的是语义相近问题，不是所有检索问题
  • BM25 这类稀疏检索仍然对术语、编号、专有名词很重要
  • 向量检索和关键词检索通常不是替代关系，而是互补关系
  • 很多“检索不准”问题，本质上是召回信号选错了，而不是单纯模型不够强

这一章会解决什么问题 ​

这一章主要回答四类问题：

  1. Embedding 到底是什么，它为什么能作为语义检索的基础
  2. 向量检索是怎样工作的，top_k、相似度、向量空间到底意味着什么
  3. BM25 为什么到今天仍然重要，它擅长解决哪些向量检索不擅长的问题
  4. 为什么真实系统常常要把向量检索、BM25、metadata 过滤和多路召回一起组织

换句话说，这一章真正想帮你建立的，不是“我知道几个检索名词”，而是：

  • 什么时候更该相信语义信号
  • 什么时候更该依赖精确匹配
  • 什么时候必须把多种召回方式组合起来

建议阅读顺序 ​

  1. 5.1 Embedding 的作用与原理
  2. 5.2 向量检索的工作方式
  3. 5.3 稀疏检索与 BM25
  4. 5.4 混合检索与多路召回

主题模块 ​

读这一章时，建议一直带着的 4 个问题 ​

  1. 当前问题更像语义相近问题，还是精确术语匹配问题
  2. 当前系统的主要盲点，是召回不到，还是召回进来太多不相关内容
  3. 当前数据类型更适合用向量检索、BM25，还是混合检索
  4. 如果召回效果差，问题更像出在 chunk、metadata、索引组织，还是检索信号本身

关联章节 ​