> 透明声明：这篇讲检索层的工程实现，原理部分不依赖 CoreNote，任何技术栈都能复用；涉及产品配置的地方我会标注来源是官方 README，没写明的地方我会直说"官方未明确"，不推测。

## 一、先看纯向量检索在什么情况下漏内容

上一篇《为什么把 PDF 丢给 AI 聊，答出来的东西你不敢用》讲了决定 RAG 准确率的三个技术决策，检索方式是其中之一。这篇把检索这一层单独拆开写透，因为它是最容易被"用了向量数据库就完事"心态糊弄过去的一层。

纯稠密向量检索（把 query 和 chunk 都编码成一个 1024 维向量，算余弦相似度）有三个典型的漏召回场景：

- **精确字符串**：查"mIoU 72.4"或"rule_id=NS-014"，语义相近的 chunk 都会被排在前面，但包含这个精确数字的那条 chunk 反而可能排到第 15 位——向量空间里"0.1 的差异"不构成显著语义距离。
- **专有名词和缩写**：BM25 这类稀疏检索对未登录词的命中能力远强于稠密向量。一个项目内部代号、一个 rare 术语，embedding 模型大概率没见过，只能给出模糊的语义邻居。
- **中英混查**：用中文查英文文献里的术语，纯单语 embedding 模型的跨语言对齐能力有限。

这三个场景的共性是：**query 里含有必须逐字命中的信息**。语义检索擅长"意思相近"，不擅长"完全一致"。所以工程上的答案不是二选一，而是双路召回。

## 二、BM25 补的就是"必须逐字命中"这一路

BM25 是基于词频的稀疏检索算法（Robertson & Zaragoza, 2009, The Probabilistic Relevance Framework），本质是 TF-IDF 的改进版：query 分词后的每个词项在 chunk 中出现的频率越高、且这个词项在整个语料库中越稀有，这条 chunk 的得分越高。

它对上面三个场景全部有效：查"mIoU 72.4"，包含这个字符串的 chunk 必然在词项匹配上得高分；查内部代号"NS-014"，只要这个词在语料里出现过，就能精确命中；中英混查时，query 里的英文词项直接和文档里的英文词项对上。

BM25 的短板也正好和向量检索互补：它不理解同义改写。"模型幻觉"和"LLM 编造内容"在 BM25 眼里是两组完全不同的词，在向量空间里是近邻。

所以混合检索（hybrid search）的逻辑是：**向量路负责语义泛化，BM25 路负责精确命中，两路各自召回、合并去重，谁漏了另一路兜底。**

## 三、bge-m3：一路模型同时出稠密和稀疏两种表示

传统做法是跑两个独立模型：一个 embedding 模型做稠密，一个 BM25 索引做稀疏。BGE-M3（Chen et al., 2024, BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embedding Through Self-Knowledge Distillation, arXiv:2402.03216）把这件事合成了一路：同一个模型对同一段文本，同时输出稠密向量、稀疏权重（词级 lexical weight）和多向量表示，训练时通过自知识蒸馏让三种表示互相对齐。

对个人 RAG 来说，这带来三个实际好处：

- **一次编码两路可用**：入库时算一次，稠密走向量索引，稀疏走词项索引，不用维护两套编码管线。
- **8192 token 的长上下文**：比常见 512 上限的模型更能整段编码，配合父子分块时父块不容易被截断失真。
- **多语言 + 跨语言对齐**：中文资料、英文论文、混着术语的技术文档，在同一个向量空间里检索。

CoreNote 的默认 embedding 就是 bge-m3 的稠密 + 稀疏双路模式，EMBEDDING_DIMENSION 默认 1024（来源：官方 README）。注意一个部署时容易踩的坑：**EMBEDDING_DIMENSION 必须和向量库 Collection 的 Schema 维度严格一致**；更换 embedding 模型或维度时，必须新建 Collection 或全量重建向量，新旧索引混用会导致检索结果错乱——README 原文专门强调了这一点。

## 四、完整链路：从一句提问到一条带出处的答案

下面是检索层的完整数据流（依据官方 README 的架构图整理，参数为默认设计值）：

```text
用户提问
   │
   ▼
Query Rewrite / Query Expansion（检索增强配置，改写扩展查询）
   │
   ▼
意图路由 ──► 按问题类型路由到不同向量分区
   │            ns_rules（规则咨询）
   │            ns_cases（案例参考）
   │            ns_queries（问题相关）
   │            ns_sop（流程问题）
   ▼
Query 向量化（bge-m3 稠密 + 稀疏双路）
   │
   ▼
混合检索：向量召回 + BM25 关键词召回
   │
   ▼
Top 20 召回、去重（近重复相似度 > 0.98 的 chunk 剔除）
   │
   ▼
重排序：bge-reranker-v2-m3，保留 Top 8
   │
   ▼
用 parent_chunk_id 取回父块（子块定位，父块回答）
   │
   ▼
父块注入 Prompt → LLM 生成 → Chunk 级引用与置信度
   │
   ▼
证据与置信度达标？──是──► 输出可核验答案（来源 + 版本 + 页码）
   │
   否
   ▼
拒答 / 转人工 / 建议重述问题 → Badcase 记录回流
```

这条链路里有四个值得单独讲的设计。

## 五、设计一：意图路由 + 分区，而不是全库一把梭

如果知识库里只有一种资料，检索就是"全库搜"。但真实资料库是混杂的：规则文档、案例、历史问题、流程 SOP 的语言风格和匹配逻辑完全不同——查规则要精确到条款编号，查案例要语义泛化。

CoreNote 的做法是入库时把不同性质的资料分到不同分区（README 架构图中的 ns_rules / ns_cases / ns_queries / ns_sop 四个分区），查询时先做意图路由，再把 query 打到对应分区检索。

这一层的价值经常被低估：**检索上限很多时候不是模型决定的，是路由决定的**。把规则类问题误路由到案例分区，后面模型再强也找不回正确证据。个人知识库体量小时可以不做分区，但资料过千、类型超过三种时，这一步的收益会非常明显。

## 六、设计二：Top 20 召回 → 重排 Top 8，宽进严出

两阶段检索（召回 + 重排）是搜索领域的成熟架构，RAG 里同样适用：

- **召回阶段求宽**：向量路和 BM25 路各召回一批，合并去重后取 Top 20。这一步用 ANN 索引和倒排索引，速度快，但排序粗糙。
- **重排阶段求准**：Cross-Encoder 结构的 reranker（bge-reranker-v2-m3）把 query 和每条候选 chunk 拼在一起过模型，直接输出相关度分数。它的精度远高于双塔式的向量相似度，但计算量大——所以只对 20 条做，不做全库。

为什么保留 Top 8 而不是 Top 20：注入 Prompt 的上下文长度有限且噪声有害，8 条经过精排的证据通常优于 20 条粗排证据。这个数字不是教条，是"上下文窗口 × 信噪比"的权衡，你可以按自己的窗口大小调整。

## 七、设计三：子块定位，父块回答

这是父子分块（parent-child chunking）在检索侧的收口。分块时父块 800–1200 token 保完整上下文，子块 200–300 token + overlap 50 保精确命中；检索命中子块后，不直接把子块喂给模型，而是用 parent_chunk_id 取回完整父块注入 Prompt。

原因：检索要的是"精确的定位点"，生成要的是"完整的论证上下文"。子块 200 token 里如果有半句话术没头没尾，LLM 照着它生成就是答非所问的常见来源。

另一个配套机制是**近重复控制**：相似度大于 0.98 的 chunk 在召回去重阶段剔除。同一个文档被重复导入、或模板化内容大量雷同时，这一步防止 Top 20 被同一段内容的十几个副本占满。

## 八、设计四：证据不足时降级，而不是硬答

链路最后一步是置信度判断：证据与置信度达标，输出带 rule_id、版本、页码的可核验答案；不达标，明确拒答或转人工，并把这次提问记为 Badcase 回流到资料和评测集。

这是检索层和生成层的交界。检索层的质量指标（召回多少、排得准不准）最终都会汇聚成这个置信度信号——前面任何一环漏召回，最后的表现就是"证据不足"。把它显式做出来，比让模型拿着不靠谱的证据硬编一个答案强得多。

## 九、配置落地：向量后端怎么选

CoreNote 的向量后端可配，两种路线（以下配置项来自官方 README）：

**本地向量后端**——数据不出本机，适合个人和隐私敏感场景。本地模式启动：

```bash
git clone https://github.com/zhangjianxin477/knowledge-hub.git
cd knowledge-hub
cp .env.example .env
docker compose -f docker-compose.local.yml up -d --build
curl http://localhost:8080/api/v1/health
```

**Milvus / Zilliz**——资料量大、需要独立向量服务扩展时用，在 .env 中配置：

```bash
VECTOR_BACKEND=milvus
MILVUS_URI=https://your-cluster.serverless.cloud.zilliz.com
MILVUS_TOKEN=your_milvus_token
MILVUS_COLLECTION=knowledge_hub_chunks
MILVUS_METRIC_TYPE=COSINE
```

两种路线的选择依据（README 未明确写性能基准，以下为选型逻辑分析，非官方数据）：

| 维度 | 本地向量后端 | Milvus / Zilliz |
| --- | --- | --- |
| 数据位置 | 完全在本机 | 在自建 Milvus 或 Zilliz 云 |
| 运维成本 | 零额外服务 | 多一个向量服务的部署/监控 |
| 适合体量 | 个人级（万级 chunk 内） | 百万级 chunk、多分区 |
| 扩展性 | 受单机内存限制 | 可水平扩展 |
| 适合谁 | 个人研究者、隐私优先 | 小团队、资料量大、要分区路由 |

个人起步用本地后端完全够；等资料上量、或者要做上面说的意图分区路由时，再迁 Milvus，迁移成本主要在向量全量重建。

## 十、怎么验证你的检索层真的变好了

别靠感觉。README 里给的方法是值得直接抄的：**准备一组真实问题及其期望来源（Golden Set），持续回归测 Recall@5、引用准确性、响应时间和 Badcase**。

具体操作：收集 30–50 个你真实问过的问题，人工标注每题的期望命中文档；每次调整分块参数、换 embedding、改重排配置后跑一遍，看 Recall@5 的变化。仓库的 scripts/ 目录包含与检索评测相关的脚本。

一个诚实的提醒：我在公开资料里**没有找到 CoreNote 各配置组合下的 Recall@5 具体数字**，README 也只给了方法没给基准值。这类数字和你的资料形态强相关，别人的基准对你参考价值有限——用自己的 Golden Set 测出来的才有意义。

## 十一、边界，说实话的部分

- 复杂 PDF、扫描件 OCR、表格解析的质量会直接影响检索上限——检索层再好，垃圾进垃圾出。README 明确说这些"需要人工检查"。
- 这套链路（双路召回 + 重排 + 父子回取）的代价是每次查询的计算量比纯向量检索高，重排那一步尤其明显。个人量级无感，高并发场景需要另行设计，CoreNote 官方也明确不承诺大规模高并发。
- Query Rewrite / Expansion 配置不当会引入查询漂移（改写后的 query 偏离原意），开启前建议在自己的评测集上对比开关前后的 Recall。

## 十二、小结

一句话版本：**检索层的准确率 = 双路召回的覆盖率 × 重排的精度 × 分区路由的正确率**，三者缺一不可，而验证手段只有 Golden Set + Recall@5。

bge-m3 的价值在于把稠密和稀疏两路合成一次编码；重排的价值在于用 Cross-Encoder 的精度补 ANN 粗排的不足；分区的价值在于让不同性质的资料用不同的匹配逻辑。这三个决策和上一篇讲的溯源、分块决策合在一起，才构成一个"答案敢用"的 RAG 知识库。

## FAQ

**问：bge-m3 和普通 embedding 模型（如 text-embedding-3-small）有什么区别？**

答：核心区别是 bge-m3 同时输出稠密向量和稀疏权重，一套编码同时支撑语义检索和关键词检索，且支持 8192 token 长文本和多语言。OpenAI 的 embedding 接口只提供稠密向量，稀疏那一路需要自己另建 BM25 索引。两种方案都能做出好的混合检索，bge-m3 的优势在管线更省、可本地部署。

**问：混合检索一定要用 bge-m3 吗？**

答：不是。任何 embedding 模型 + BM25（如 Elasticsearch、Milvus 的 BM25 能力）都能组成混合检索。bge-m3 只是把两路编码合并了，工程上更省。

**问：Reranker 可以关掉吗？关了会怎样？**

答：可以（README 中重排是"可选"环节）。关掉后直接用粗排 Top N 注入 Prompt，查询延迟更低，但信噪比下降——Top 20 粗排里通常混着不少弱相关 chunk，对生成质量的影响需要用你自己的评测集验证。

**问：VECTOR_BACKEND=milvus 时 embedding 维度要注意什么？**

答：EMBEDDING_DIMENSION 必须与 Milvus Collection Schema 一致；更换 embedding 模型或维度时必须新建 Collection 或全量重建向量，不能混用旧索引（README 原文明确强调）。

**问：个人知识库需要做意图分区（ns_rules 这种）吗？**

答：资料量小、类型单一时不需要。资料过千、类型超过三种（规则/案例/问答/流程）时，分区 + 意图路由的收益会明显大于维护成本。

---

写在最后：本文所有产品配置项（EMBEDDING_DIMENSION、VECTOR_BACKEND、MILVUS_* 系列变量、分区名、重排模型名）均来自 CoreNote 官方仓库 README（github.com/zhangjianxin477/CoreNote，MIT License）；bge-m3 的能力描述来自其论文（arXiv:2402.03216）。性能基准类数字本文一个都没有——因为你该用自己的数据测。

透明声明：这篇讲检索层的工程实现，原理部分不依赖 CoreNote，任何技术栈都能复用；涉及产品配置的地方我会标注来源是官方 README，没写明的地方我会直说"官方未明确"，不推测。

为什么你的 RAG 检索总漏内容？——bge-m3 双路召回 + 混合检索 + 重排的完整链路

编程语言

本文深入解析RAG检索层工程实现，聚焦纯向量检索的三大漏召回场景（精确字符串、专有名词、中英混查），提出BM25+稠密向量双路召回方案。详解bge-m3模型统一编码、意图路由分区、父子分块回取及重排序等核心设计，提供完整数据流与配置落地指引，强调用GoldenSet+Recall@5验证检索质量，构建可信RAG系统。

向量数据库

Elasticsearch 

代码解释

知识蒸馏

数据流

数据库

路由

GitHub

2026上云采购 | AI焕新·智启新局

lexiang

serverless-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

为什么你的 RAG 检索总漏内容？——bge-m3 双路召回 + 混合检索 + 重排的完整链路-腾讯云开发者社区-腾讯云

为什么你的 RAG 检索总漏内容？——bge-m3 双路召回 + 混合检索 + 重排的完整链路

为什么你的 RAG 检索总漏内容？——bge-m3 双路召回 + 混合检索 + 重排的完整链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐