W
AI-Wiki
CONCEPT

混合检索

定义

混合检索 是一种把多种检索信号并行组合的知识库查询策略。在本文语境中，它不是泛指任何“多路召回”，而是特指把 BM25 或 FTS5 的关键词检索、embedding 向量搜索、以及基于实体与关系的图遍历联合起来，再用 RRF（Reciprocal Rank Fusion） 做结果融合排序。

它解决的问题不是“检索功能从无到有”，而是 LLM Wiki 变大以后，原本依赖 index.md 的查找方式开始变慢、变脆弱、覆盖不全。

在本文档中的语境

在 Karpathy 的原版 LLM Wiki 设计里，index.md 在中等规模下是有效的，文档到了几百页时“仍然能撑一阵”。但 Rohit 的 V2 判断更激进：当 wiki 增长到 100 到 200 页，并继续扩张时，index.md 会逐渐成为检索瓶颈。

这里的瓶颈不只是“找得慢”，更是“找不全”。因为知识库变大后，用户提出的问题不再只是在目录里找主题，还会出现以下几类查询：

  • 精确术语：需要命中某个准确名词、函数名、组件名、决策名。
  • 语义同义：提问词和文档原词不一致，但实际在问同一件事。
  • 影响分析：需要追踪“改一个东西会波及什么”。
  • 历史决策：需要找出某个设计为什么形成、后来是否被替代。
  • 个人偏好：需要从过往记录里找出某人的习惯、约束、偏好。

单靠 index.md 更像是人工维护的导航入口，适合启动阶段或中等规模，不足以覆盖这些查询面。于是 V2 不是把索引页废掉，而是在其之上引入 混合检索 作为扩展检索层。

三路检索的分工

1. BM25 / FTS5：负责精确词和术语命中

BM25 或 SQLite FTS5 负责处理“此刻相关”中的字面相关部分。它最适合以下场景：

  • 组件名、库名、接口名、缩写词必须精确命中。
  • 用户知道原文里的关键词，只想迅速定位页面或段落。
  • 文档中存在专有术语，不能只靠语义近似猜测。

例如查询某个精确名词、某条 claim id、某个 ADR 名称时，关键词检索通常比向量搜索更稳定，也更容易解释。作者建议的最先落地方案，就是 先上本地 FTS5 或 BM25，因为它实现成本低、行为直观、评估也容易。

2. 向量搜索：负责语义相近材料召回

向量搜索同样服务于“此刻相关”，但它覆盖的是语义相关而不是字面重合。它适合：

  • 提问和文档用词不同，但表达的是同一问题。
  • 用户只记得含义，不记得原始术语。
  • 文档分散在多页中，需要先召回一批语义近邻材料。

例如文档里写“替代旧决策”“被新信息覆盖”，用户却搜索“后来是否推翻了原来的方案”，这种情况下关键词检索可能漏掉，而 embedding 检索更容易召回相关页面。

因此，BM25/FTS5 与向量搜索不是互斥关系，而是互补关系：前者强在精确命中，后者强在同义、近义、改写和概念相近。

3. 图遍历：负责结构上的相关影响链

图遍历处理的不是“此刻最像什么”，而是“在知识结构里和它有关的是什么”。这也是 Rohit 评论里最关键的观点：

  • BM25 和向量搜索找的是“此刻相关”。
  • 图遍历找的是“结构相关”。

所谓结构相关，指的是实体之间存在带语义的边，例如 uses、depends_on、contradicts、supersedes 等。它适合回答：

  • 升级某个组件会影响哪些服务？
  • 某个鉴权决策关联了哪些 bug、哪些负责人、哪些后续修改？
  • 一条旧结论后来被哪条新结论替代？
  • 某段历史设计是由哪些前置事件或约束形成的？

这类问题即使文本相似度不高，也可能在结构上高度相关。普通 双链 或页面互链只能表达“有关”，但无法稳定表达“依赖”“矛盾”“替代”“来源于”这些明确关系，因此图遍历通常要建立在类型化知识图谱或至少“显式实体—关系契约”之上。

融合方式：用 RRF 合并，而不是替换索引

本文强调的 混合检索 不是“把 index.md 换成 hybrid search 就结束了”，也不是让某一路检索独占排序。V2 的做法是：

  1. 让 BM25 / FTS5、向量搜索、图遍历各自返回候选结果。
  2. 用 RRF 对多路结果做统一融合排序。
  3. 把融合后的结果交给后续阅读、证据抽取或回答生成步骤。

这样做的重点在于：

  • 避免单一路径的盲区。
  • 保留不同检索器各自的优势。
  • 不要求所有查询都依赖图谱，也不要求所有问题都做 embedding。
  • index.md 仍然可以保留为人工入口、导航层和维护层，而不是被简单废除。

RRF 的价值在这里主要是工程上的稳健：它不要求三路分数必须天然可比，而是按各自排名进行融合，更适合多种异构检索结果一起工作。

为什么会提出混合检索

提出 混合检索 的直接原因，是 wiki 在小规模和中等规模时还能靠索引页维持可用，但继续增长后会明显暴露问题。

原文中的判断有两个层次：

  • 原版观点：index.md 在中等规模下很好用，几百页时仍能支撑一段时间。
  • V2 观点：当文档数来到 100 到 200 页并继续增长后，索引页会逐渐变成瓶颈，应引入 BM25、向量搜索、图遍历三路并行。

这说明 混合检索 不是启动期必选项，而是规模扩张后的系统化补强。它属于从“能跑起来”迈向“变大后还能找准”的那一步。

实施顺序：先轻后重

作者明确反对一开始就把完整 V2 全部做齐，因为那会让系统过重，也难以判断哪一层真正有收益。围绕 混合检索，建议顺序是：

  1. 先保留原有 wiki 结构：raw、wiki、index.md、log.md、规则文件继续存在。
  2. 先上本地 FTS5 或 BM25：优先解决精确词检索和术语命中问题。
  3. 再加 embedding：补足语义相近材料的召回。
  4. 再抽取图关系：可先从 Markdown frontmatter 或 sidecar JSON 中抽取实体和边。
  5. 图数据库后置：不必一开始就引入专门图库，先把实体类型和边的契约定义清楚。

这个顺序很重要，因为它表明 混合检索 不是“先上最复杂基础设施”，而是从最可验证、最便宜的增量开始。

关键细节与边界

它不是简单替代 index.md

index.md 在启动阶段和中等规模中仍有价值：

  • 它是人工可读的导航页。
  • 它能暴露知识库结构。
  • 它有助于 Agent 维护页面组织。

混合检索 的作用是补足索引在大规模场景中的检索能力，而不是否定索引页本身。

它依赖图关系质量，但图数据库不是前提