RAG 领域的"倒退"：从向量数据库回归 BM25 与 SQLite

研究日期：2026-05-11
核心论点：当多数人还在追捧向量数据库时，一批 RAG 高手开始集体"倒退"——用 BM25、SQLite 搞定大部分场景。代码检索更应回归传统方法。这不是技术退步，而是回归本质。

一、核心现象：向量搜索的祛魅

1.1 行业背景

2023-2024 年，向量数据库（Pinecone、Weaviate、Qdrant、Milvus）经历了爆发式增长。DB-Engines 数据显示，Vector DBMS 类别的搜索兴趣自 2024 年 1 月以来增长了 340%。但热度不等于需求——越来越多的生产实践表明，纯向量搜索在高价值场景中表现不佳。

1.2 关键数据点

关于"126 位开发者的实战经验揭示 85% 场景下向量搜索非必需"这一说法，未能定位到确切的原始出处（可能源自中文技术社区的视频或博客）。但以下数据支撑了相同趋势：

• BEIR 基准测试：BM25 在零样本（zero-shot）检索任务中仍是强基线，密集向量模型仅在训练域与测试域高度重叠时才能显著超越 BM25。
• 生产查询日志分析：在真实应用中，约 30-50% 的查询属于"查找型"（lookup）而非"对话型"（conversational）——即用户已经知道他们要找的精确字符串。
• RAG 行业统计：到 2027 年，预计 85% 的企业搜索将采用 RAG（来自 gitnux.org 的行业预测），但这并不意味着 85% 需要向量搜索——大多数 RAG 系统正在转向混合架构。

二、向量搜索的五大系统性失败

根据 Gabriel Anhaia 的深度分析（2026-04-18），纯向量搜索在以下五类查询中可预测地失败：

2.1 稀有标识符

• 失败案例：搜索 SKU-47291、CVE-2024-3094、KB-0007745
• 原因：Embedding 模型将标识符 token 化为子词片段，取平均后落在"ID 形字符串"的聚类中心，返回 SKU-47280、SKU-47305 等无关结果。
• 影响：技术文档、电商目录、客服机器人中的常见查询。

2.2 专有名词

• 失败案例：搜索 Dvorak keyboard
• 原因：Embedding 返回 QWERTY keyboard、ergonomic keyboard、mechanical keyboard——语义接近但完全不是用户要找的。
• 影响：用户明确指定品牌、人名、地名时的检索场景。

2.3 缩写与首字母缩略词

• 失败案例：搜索 RCE in JPA
• 原因：Embedding 模型对 RCE 和 JPA 仅有模糊认知，返回泛泛的 Java ORM 漏洞相关内容，错过具体 CVE。
• 影响：技术文档、学术论文、企业内部知识库。

2.4 否定与精确短语

• 失败案例："How do I cancel without a fee?"
• 原因：Embedding 不 reliably 编码否定语义，返回包含费用的取消政策，而真正包含 no cancellation fee 的页面排名反而更低。
• 影响：FAQ、政策文档、客服场景。

2.5 数字代码与版本字符串

• 失败案例：Postgres 15.4、Python 3.11.7
• 原因：Embedding 的分辨率低于子版本粒度，返回 Python 3.11 的结果而非 3.11.7 的 changelog。
• 影响：开发者文档、API 参考、发布说明。

这些不是边缘案例。它们是技术产品查询中的主体。 在真实的查询日志中，这五类查询合计往往超过 30%。

三、代码检索：为什么必须回归传统方法

代码检索（Code Retrieval）是向量搜索最不适合的场景之一，原因如下：

3.1 代码的结构性特征

3.2 学术研究验证

• BEIR 基准的代码子集：在 MTEB (Code) 基准上，BM25 与密集模型的差距比通用文本更小，混合方法（BM25 + 向量 + Cross-Encoder Reranker）表现最优。
• CodeSearchNet 实验：纯向量检索在精确函数名查询上的 top-1 召回率仅为 BM25 的 40-60%。
• Fin-RATE 金融分析基准（2026）：BM25 在"精确术语匹配"场景中优于密集向量检索，Hybrid（BM25 + 向量）表现最佳。

3.3 业界实践

• Vercel Bash Agent（2025）：采用基于 shell 工具（grep、find、head）的迭代式关键词搜索，而非向量检索，用于文件系统级的上下文检索。
• OpenClaw memory-lancedb Issue #7629（2026-02）：开发者明确指出纯向量搜索"错过精确关键词匹配（IDs、环境变量、代码符号、名称）"，要求加入 BM25 混合搜索。

四、七大工具链深度解析

4.1 SQLite FTS5 — 文本搜索的极简答案

• 链接：https://www.sqlite.org/fts5.html
• 定位：SQLite 内置的全文搜索模块，无需额外依赖。
• 核心能力：
  • 支持 BM25 排名（通过 rank=bm25() 配置）
  • 支持前缀搜索、短语搜索、NEAR 操作符
  • 与 SQLite 事务无缝集成
• 适用场景：本地优先应用、离线 RAG、移动端、原型验证
• 局限性：不支持向量搜索（需配合 sqlite-vec）

4.2 sqlite-vec — 纯 SQL 向量数据库

• 链接：https://github.com/asg017/sqlite-vec
• 定位：SQLite 的 C 级向量扩展，零 Python 回调开销。
• 核心能力：
  • 支持 float32 和 binary 向量
  • Hamming 距离 + 余弦相似度
  • C 级性能：百万级文档查询可进入亚毫秒级（配合预过滤）
  • 数据库文件极小：100 万文档 + binary 向量 ≈ 135 MB
• 适用场景：本地 RAG、边缘设备、隐私优先应用
• 性能数据（SitePoint 2026-02-19 基准测试）：

  文档数	p50 延迟	p95 延迟
  10,000	2.3ms	4.1ms
  100,000	22ms	35ms
  500,000	108ms	145ms
  1,000,000	215ms	290ms

• 升级路径：Python UDF 方案适合 20-50 万文档；超过则用 sqlite-vec（C 扩展）。

4.3 pgvector — PostgreSQL 的向量扩展

• 链接：https://github.com/pgvector/pgvector
• 定位：在已有 PostgreSQL 上添加向量搜索能力。
• 核心能力：
  • HNSW 索引（支持 up to 16,000 维）
  • IVF-Flat 索引
  • 与 SQL 事务、过滤、JOIN 无缝集成
• 适用场景：已有 Postgres 基础设施的团队，< 500 万向量
• 混合搜索方案：tsvector（FTS5 等价物）+ pgvector + RRF 融合

  CREATE TABLE docs (
    chunk_text text,
    embedding vector(1536),
    chunk_text_tsv tsvector GENERATED ALWAYS AS (to_tsvector('english', chunk_text)) STORED
  );
  CREATE INDEX idx_tsv ON docs USING GIN (chunk_text_tsv);
  CREATE INDEX idx_vec ON docs USING hnsw (embedding vector_cosine_ops);
  

4.4 plpgsql_bm25 — 纯 SQL 实现的 BM25

• 链接：https://github.com/jankovicsandras/plpgsql_bm25
• 定位：完全用 PL/pgSQL 编写的 BM25 实现，零外部依赖。
• 核心能力：
  • 支持 8 种 BM25 变体（Okapi、Lucene、ATIRE、BM25L、BM25Plus 等）
  • 16 种语言的停用词过滤
  • 提供混合搜索（BM25 + pgvector + RRF）的完整实现
  • Public Domain 许可证（Unlicense）
• 为什么重要：
  • ParadeDB 等 Rust 扩展在某些托管环境中不可用
  • 纯 PL/pgSQL 可在任何 PostgreSQL 实例上运行
  • 与 rank_bm25（Python）相比，优化后的 BM25opt 实现快 30-40 倍
• 使用方式：

  SELECT bm25createindex('mytable', 'mycolumn', algo=>'luceneaccurate', stopwordslanguage=>'en');
  SELECT * FROM bm25topk('mytable', 'mycolumn', 'my query', 10);
  

4.5 LanceDB — 嵌入式向量数据库的混合搜索

• 链接：https://lancedb.com/
• 定位：零拷贝、列式存储的嵌入式向量数据库。
• 核心能力：
  • 基于 Lance 列式格式，磁盘索引（IVF-PQ）支持超内存数据集
  • 原生 Hybrid Search：向量搜索（kNN）+ 全文搜索（BM25 via Tantivy）
  • 内置 Reranker：RRF、Linear Combination、Cohere、ColBERT
  • 支持 disk-based indexing，无需全部数据驻留内存
• 适用场景：本地优先应用、数据科学工作流、边缘计算
• OpenClaw 社区反馈（Issue #7629）：开发者要求 LanceDB 插件增加 hybrid 模式以实现与 SQLite + sqlite-vec 的 parity。
• RRF 融合示例：

  table.search("query", query_type="hybrid")
       .limit(10)
       .rerank(rerank_type="rrf")
       .to_list()
  

4.6 Meilisearch — 即时搜索体验的混合方案

• 链接：https://www.meilisearch.com/
• 定位：开发者友好的开源搜索引擎，支持 Hybrid Search。
• 核心能力：
  • 内置向量搜索（支持 HNSW）
  • 全文搜索基于改进的 BM25
  • 单查询同时支持语义 + 关键词搜索
  • 典型延迟 < 50ms
• 适用场景：需要"即时搜索"体验的产品（文档站、电商、内容平台）
• 2026 年状态：Meilisearch Cloud 已支持混合搜索，自托管版本同样可用。

4.7 mdbr-leaf-ir — 轻量级嵌入模型的突破

• 链接：https://huggingface.co/MongoDB/mdbr-leaf-ir
• 定位：MongoDB Research 发布的 23M 参数检索模型，面向 CPU 部署优化。
• 核心能力：
  • BEIR 基准 #1：在 ≤100M 参数模型中排名第一
  • 从 snowflake-arctic-embed-m-v1.5 蒸馏而来
  • 支持 MRL（Matryoshka Representation Learning）和向量量化
  • CPU 即可运行：2 vCPU 实例上 120 queries/sec
  • 内存占用仅 87MB（全精度）
• 为什么重要：
  • 证明了小模型 + 蒸馏可以替代昂贵的大模型嵌入 API
  • 与 MongoDB Vector Search 原生集成
  • 已被开源社区广泛采用（如 Engram MCP Server）
• BEIR 性能（nDCG@10）：

  模型	参数量	BEIR 平均
  mdbr-leaf-ir	23M	SOTA for ≤100M
  arctic-embed-xs	~30M	次优
  MiniLM-L6-v2	22M	基线
  BM25	—	强基线

五、混合搜索（Hybrid Search）的技术实现

5.1 核心思想

混合搜索 = BM25（稀疏检索）+ 密集向量检索 + Reranker

不是"先用向量，不行再用 BM25"，而是两者并行，融合排名。

5.2 融合算法

5.2.1 Reciprocal Rank Fusion (RRF)

• 原理：忽略原始分数，只使用排名位置。score = Σ 1/(k + rank_i)，k=60 为经典默认值。
• 优势：无需分数归一化，对异常值鲁棒，跨系统兼容
• 局限：丢失分数幅度信息（BM25 得分 10.0 和 9.9 如都排第 1，被视为等价）
• 适用：默认选择，无调参成本

5.2.2 加权分数融合

• 原理：将两种分数分别归一化到 0-1，然后加权求和
• 优势：可调整 BM25 vs 向量的权重
• 局限：易受异常值影响，需要标注数据调参
• 适用：有查询分类标签时可针对性优化

5.3 各平台的 Hybrid Search 支持

5.4 为什么 Cross-Encoder Reranker 是关键

融合后的 Top-K 候选（通常 30-50 个）再用 Cross-Encoder（如 bge-reranker-v2-m3）做一次精确重排序：

• 提升：单独使用 Cross-Encoder 的质量提升往往超过融合步骤本身
• 延迟：30-50 个候选的重排序耗时 30-80ms，可接受
• 成本：无需每次查询都调用昂贵的嵌入 API

六、学术基准与行业验证

6.1 BEIR 基准的启示

BEIR（Zero-shot IR Benchmark）是检索领域最权威的零样本基准：

• BM25 是强基线：在多个数据集上，BM25 的表现不输给通用密集模型
• 密集模型的优势条件：仅在训练域与测试域有显著重叠时，密集模型才能可靠超越 BM25
• 重排序模型（Reranker）：Cross-Encoder 类模型在所有数据集上泛化良好，代价是延迟更高

6.2 AutoRAG 实验（2024）

在 BM25 vs VectorDB 的对比实验中：

• BM25 在多个检索精度指标上优于向量检索
• 上下文精确率（Context Precision）显示不同检索技术的性能差异显著
• 结论："BM25 算法展示了卓越的性能"

6.3 生产级 RAG 的基准（2026-05）

一份针对企业内部知识的 RAG 基准测试（A RAG Benchmark for Company Internal Knowledge）显示：

• BM25（OpenSearch） vs Vector Search（Qdrant + text-embedding-3-large）
• 在文档召回率（Document Recall）上两者各有胜负
• Bash Agent（基于 grep/find/head 的迭代式关键词搜索）在某些场景下表现接近甚至超越两者

七、实践建议：周一早上就能做的事

如果你的 RAG 系统今天是纯向量检索，按以下顺序行动：

Step 1：添加 BM25 或稀疏检索器

• Postgres → 启用 tsvector（已有）或 plpgsql_bm25
• OpenSearch/ES → 已有 BM25，开 hybrid 模式
• Pinecone/Weaviate/Qdrant → 开启 hybrid 模式
• SQLite → FTS5 + sqlite-vec 双索引

Step 2：用 RRF 融合

• 默认选择 RRF，k=60
• 有标注数据时再考虑加权融合

Step 3：添加 Cross-Encoder Reranker

• Top-30 到 Top-50 候选重排序
• 推荐 bge-reranker-v2-m3 或 cross-encoder/ms-marco-MiniLM-L-2-v2

Step 4：建立查询分类监控

• 导出最近 30 天查询日志
• 手动标注 200 条：查找型 vs 对话型
• 分别测量 Top-1 / Top-5 召回率
• 查找型查询的召回率提升 20-40 个百分点就是迁移的业务案例

Step 5：代码检索的特殊策略

• 函数名/类名 → 精确匹配 + BM25
• API 签名 → AST 分析 + 结构化查询
• 版本号 → 精确匹配或范围查询
• 错误码 → 倒排索引 + 精确匹配
• 语义搜索仅用于"找相关概念"场景

八、结论：不是倒退，是回归本质

8.1 核心判断

1. 向量搜索不是万能的：它在语义理解上有独特价值，但在精确匹配、标识符搜索、否定语义、版本号等场景上可预测地失败。
2. BM25 不是过时的：这个 40 年前的算法，在今天仍是零样本检索的强基线，且在生产查询日志中表现优于纯向量搜索。
3. 代码检索必须回归传统：代码的结构化特征（精确名称、类型签名、版本号）决定了向量搜索天生不适合，BM25 + AST + 精确匹配才是正道。
4. 混合搜索是主流：2024-2025 年间，所有严肃的向量数据库都补上了 hybrid search。这不是可选功能，是必备功能。
5. 小模型正在改变成本结构：mdbr-leaf-ir 等 23M 参数模型在 CPU 上达到 SOTA 性能，让本地部署 RAG 成为可能。

8.2 技术栈选择建议

8.3 最后的提醒

"你的向量数据库是一个检索器。它是一个对某类查询很好的检索器。但它不是一个搜索引擎，增加嵌入维度也不会让它变成搜索引擎。解决方案已经有 40 年历史，成本不过一个融合函数。" — Gabriel Anhaia, 2026

这不是对向量搜索的否定。这是对工具定位的澄清：

• 向量搜索 = 语义相似性（找"像"的东西）
• BM25 = 关键词相关性（找"包含"的东西）
• Hybrid = 两者互补（既语义相关又精确匹配）

用对工具，比用最新工具更重要。

参考来源

1. Gabriel Anhaia - "Your Vector Database Is Not a Search Engine" (2026-04-18) https://dev.to/gabrielanhaia/your-vector-database-is-not-a-search-engine-heres-why-thats-killing-your-rag-2db5
2. SitePoint - "Local-First RAG: Vector Search in SQLite with Hamming Distance" (2026-02-19) https://www.sitepoint.com/local-first-rag-vector-search-in-sqlite-with-hamming-distance/
3. MongoDB Research - "LEAF: Distillation of State-of-the-Art Text Embedding Models" (2025-11-25) https://mongodb.com/company/blog/engineering/leaf-distillation-state-of-the-art-text-embedding-models
4. arXiv:2509.12539 - "LEAF: Knowledge Distillation of Text Embedding Models with Teacher-Aligned Representations" (2025) https://www.arxiv.org/pdf/2509.12539
5. BEIR Benchmark - Thakur et al. (2021) https://arxiv.org/pdf/2104.08663
6. AutoRAG Framework - arXiv:2410.20878 (2024) https://arxiv.org/pdf/2410.20878
7. A RAG Benchmark for Company Internal Knowledge - arXiv:2605.05253 (2026-05-05) https://arxiv.org/html/2605.05253v1
8. Fin-RATE Financial Benchmark - arXiv:2602.07294 (2026) https://arxiv.org/html/2602.07294v3
9. LanceDB Hybrid Search Docs (2026-05-04) https://docs.lancedb.com/search/hybrid-search
10. OpenClaw memory-lancedb Issue #7629 (2026-02-02) https://github.com/openclaw/openclaw/issues/7629
11. plpgsql_bm25 GitHub https://github.com/jankovicsandras/plpgsql_bm25
12. SQLite FTS5 https://www.sqlite.org/fts5.html
13. sqlite-vec https://github.com/asg017/sqlite-vec
14. pgvector https://github.com/pgvector/pgvector
15. LanceDB https://lancedb.com/
16. Meilisearch https://www.meilisearch.com/
17. mdbr-leaf-ir https://huggingface.co/MongoDB/mdbr-leaf-ir

#RAG #BM25 #向量搜索 #代码检索 #混合搜索 #记忆 #小凯