当文档量级从测试环境跃升至千万级别，纯向量检索的RAG系统为何会突然失效？本文揭示了混合检索架构才是规模化应用的关键。核心内容：1. 纯向量检索在文档量激增时性能急剧下降的原因2. 7家大厂采用的混合检索（BM25+向量+重排序）架构详解3. 开源与商业重排序模型的效果对比及实践建议
| 你的 RAG 在 10 个文档上跑得好好的，放到 1000 万就崩了 |
去年我帮一个团队排查 RAG 系统。他们的原型在 200 个 PDF 上表现完美——准确、快速、幻觉率几乎为零。
然后他们导入了公司全部知识库。
10 万份文档。
症状来得很快： - 问"德国外包商的年假是多少天"，返回的是员工手册、远程办公指南、福利概览——唯独没有外包商政策那一页
- 搜索"ERR_CONNECTION_RESET_1045"，向量检索返回了一堆"连接问题排查"的通用文档
- LLM 开始"编造"答案，因为它收到的上下文全是噪音
这不是 prompt engineering 的问题。这是检索架构退化——当文档量超过某个阈值，纯向量检索会从"够用"变成"灾难"。 |
| 7 家大厂的一致答案：RAG 的本质是 IR 问题 |
我调研了 7 家在生产环境部署百万级以上文档 RAG 的公司：Perplexity、Glean、Notion、Dropbox Dash、GitHub Copilot、Sourcegraph Cody、Cursor。
没有一家用纯向量检索。
他们的架构惊人地一致： 1查询改写 → 并行检索(BM25+向量+知识图谱) → 多级重排序 → Prompt约束+引用强制 → 输出
2 ↑ 召回 100-100K 候选 ↑ 精排到 10-200 |
|
Anthropic 在 2024 年的实验是迄今最权威的单点验证： | 检索方式 | 检索失败率 |
|---|
| 纯向量 | 5.7% | | 混合检索 (BM25+向量) | 2.9%（-49%） | | 混合 + 重排序 | 1.9%（-67%） |
|
BM25 在精确查询上碾压向量检索——错误代码查询 Recall 0.97 vs 0.68，命名实体查询 0.96 vs 0.71。向量检索只在概念查询上胜出。
两者互补，不互斥。 |
在 20 万文档的基准测试上，加入 Cohere Rerank（或其他重排序器）的效果： | 指标 | 纯向量检索 | +重排序 |
|---|
| Precision@10 | 45% | 68% | | Recall@10 | 68% | 72% |
|
开销也很可控：向量检索取 top-100，重排序挑 top-10，增加 300-500ms 延迟。
目前开源 SOTA 是 mxbai-rerank-large-v2（BEIR NDCG 57.49，Apache 2.0），超过了 Cohere Rerank 3.5 的闭源模型。 |
| 一个被严重高估的建议：Semantic Chunking |
你可能会看到很多教程推荐"语义分块"——按段落、按主题、甚至用 LLM 来切分文档。
别用。
Vecta 在 2025 年做了一个 7 种分块策略的基准测试，结果非常反直觉： | 分块策略 | 准确率 | 成本 |
|---|
| Recursive 512 tokens | 69% | 极低 | | Semantic (聚类) | 54% | 高 | | Semantic (LLM) | 91.9% | $3.25/100 文档 |
|
LLM 语义分块确实最准——但成本是递归分块的 100 倍，不适合规模化。聚类语义分块反而比递归更差。
80% 的 RAG 应用，Recursive Character Splitter（400-512 tokens，10-20% overlap）就是最优解。
NVIDIA 的独立基准也验证了这一点：页面级分块（简单按页切）准确率最高（0.648），方差最低（0.107）。简单方案在规模面前反而最稳定。 |
这是原文最大的 Oversimplification。
真实数据： | 系统/领域 | 幻觉/失败率 |
|---|
| Anthropic 最优配置 | 1.9% 检索失败 | | Stanford 法律 RAG | ~17% | | 医疗领域 | 15.6% | | Perplexity 引用错误 | 37%（普通）/ 7.7%（Deep Research） |
|
Perplexity 的引用错误率尤其值得注意。哥伦比亚新闻评论 2025 年审计了 8 个 AI 搜索引擎——Perplexity 是行业最佳，但仍有 37% 的引用是错的。
所以真正的目标不是"消灭幻觉"，而是"让幻觉可被审计"——每个回答必须附带可验证的引用，让用户自己判断。 |
如果你今天要搭一个 10M+ 文档的 RAG 系统，可以全部自托管、零 SaaS 依赖： | 组件 | 推荐 | 协议 |
|---|
| 向量数据库 | Milvus（100M+）/ Weaviate（10-50M） | Apache 2.0 / BSD-3 | | 混合检索 | RRF 融合 BM25 + 向量 | 标准算法 | | 重排序 | mxbai-rerank-large-v2 | Apache 2.0 | | 分块 | Recursive 400-512t | — | | 文档解析 | Docling（IBM） | MIT | | 评估 | 自建领域测试集 | — |
|
这套栈在 Perplexity 的量级（200B+ URL，7.8 亿月查询，p50 延迟 358ms）已经被验证可行。 |
RAG 规模化的问题不是 LLM 的问题，是信息检索的问题。
纯向量检索在小规模上够用，但千万级文档时，BM25 的关键词召回 + 向量的语义召回 + 重排序的精排——这三件套是唯一经过大厂验证的路径。
语义分块被严重高估。Recursive 分块在大多数场景下不仅更简单，而且更准。
"零幻觉"不存在，但可以被压制到 2-5% 的水平——前提是你有完善的引用机制让用户核实。 参考资料：Anthropic Contextual Retrieval · Perplexity Search API · Notion Vector Search · Chroma Chunking Research · Vecta Chunking Benchmark · Stanford HAI Legal Hallucination |
