做 RAG 经常会效果不行，就算是把模型换了更大的，回答依然飘；把向量库换了更贵的，召回还是不稳；把 Prompt 改了很多版，效果依然起起落落。

RAG 的瓶颈大多不在「生成」，而在「检索」。检索做不好，生成只能在不完整的输入上硬编；检索做得稳定，模型反而没那么挑。

今天我们聊讲 5 个在工程中里最常用、ROI 比较高的策略：

1. 多向量检索
2. 人工切分打标
3. 标量增强
4. 上下文增强
5. 增加多类型向量

0. 优化什么

RAG 的检索链路，拆开看就两件事：

• 召回：把“可能相关”的材料尽量找全
• 排序：把“真正相关”的材料尽量排前

这两件事对应的常见失败模式也很固定：

• 同义相似但不相关：语义像，但不是答案需要的证据
• 关键词命中但语义不近：专有名词、编号、表格字段，向量不敏感
• 被切碎：答案跨段、跨页，chunk 切断了前后依赖
• 证据形态不对：表格、图片、公式、目录结构，直接 embed 很容易失真
• 同一问题在不同时间答案不同：版本、日期、渠道不清，检索到旧材料

下面的 5 个策略，分别解决这些问题中的一个或多个。

1. 多向量检索

给同一份内容提供多种“检索入口”

1.1 核心思路

多向量检索的关键点不是「存更多向量」这么简单，而是把用于检索的表示和用于回答的原文解耦：

• 检索阶段：用更适合相似度搜索的表示去匹配（比如摘要、问题式描述、表格的自然语言总结、图片的文字说明）
• 生成阶段：把原始内容（全文、原表格、原图片引用）交给模型做答案合成，避免摘要丢细节

这种逻辑可以用把 RAG 从「只适合纯文本」扩展到表格、图片等半结构化/多模态内容：
用总结去检索，用原始材料去回答（尤其表格场景很典型：总结容易被召回，但回答必须看原表格字段和数值）。 这种

1.2 什么时候最值

多向量检索在三类数据上收益很稳定：

• 半结构化文档：表格 + 段落混在一起（财报、年报、审计报告、制度文件）
• 多模态文档：图片、图表、扫描件（说明书、投标文件、报告 PDF）
• 长文档：同一个主题分散在多个章节，单一 chunk embedding 容易错过

1.3 工程落地

落地要解决三件事：

1. 拆分元素类型：把文档切成“文本块 / 表格 / 图片”等元素
   用 Unstructured 这类工具做 partition：先抽取图片块，再用布局模型拿到表格边界、标题候选，再把标题下面的文本聚合成块。

2. 为每类元素生成可检索的文本表示

   • 文本块：可以生成更短的摘要、关键词式描述、可能的问题集合
   • 表格：生成“表格讲了什么”的自然语言摘要（用来检索）
   • 图片：常见的是「先用多模态模型把图片转成文字摘要，再当文本检索」
3. docstore 里保留原件
   检索命中的是 summary，但最后喂给 LLM 的是原文/原表格/原图引用。

1.3 常见坑

• 摘要写得太像原文：检索没变强，只是多存了一份噪声
  摘要应该更「检索友好」：更短、更结构化、包含实体名、指标名、时间范围。
• 一个元素生成太多向量：向量数暴涨，召回变慢、成本变高
  做到「足够覆盖检索入口」即可，别追求花样。
• docstore 的映射不稳定：summary 与原件的 id 对不上，线上会出现“召回到 A，返回了 B”的事故
  id 设计要从第一天就稳定，元素级别的主键要可复现。

2. 人工切分打标

用最便宜的方式把「结构」和「业务语义」补回来

2.1 为什么需要人工介入

很多团队一开始会追求「全自动 ingest」，但现实是：

• 同一套自动切分规则，放到不同类型文档上效果差异很大
• 文档里真正有用的结构信息，往往不在文本里，而在排版、目录、章节层级、表格布局里
• 业务里最关键的“可用性信息”（版本、适用范围、地区、产品线、口径）不一定在正文可直接抽出来

人工切分打标解决的是：把检索需要的结构和语义先做扎实，后面的向量、排序、重写才有发挥空间。

2.2 切分的三个规则

1. 按语义边界切，不按长度切
   章节、小节、条款、定义、流程步骤、FAQ 一问一答，是天然边界。
   “为了 token 均匀”硬切，很容易切断定义与约束条件。

2. 切分粒度为「可引用证据」服务
   能够被引用、被追溯、被定位的最小单元更重要：

   • 条款编号
   • 表格标题 + 表格整体
   • 小节标题 + 小节正文
   • 定义段落（不要拆）
3. 保留层级关系
   只存平铺 chunks，后面很难做「向上取整段/向下补上下文」。
   最少保留：文档 → 章节 → 小节 → 段落/表格。

2.3 优先打「可过滤、可路由」的标签

别一上来就做很细的本体论，先打最值钱的：

• 文档类型：制度 / 产品手册 / 合同模板 / 会议纪要 / 财报
• 业务范围：地区 / 产品线 / 客户类型 / 适用系统
• 时效性：生效日期 / 版本号 / 是否废止
• 可靠性：来源系统 / 审批状态 / 是否正式发布
• 访问控制：部门、角色、密级

这些标签后面都能进入“标量增强”和“路由策略”，直接影响线上稳定性。

2.4 常见坑

• 打标体系不收敛：每个人一套标签名
  解决办法很朴素：拉一张白名单表，允许的 key 固定，value 做枚举或正则。
• 把「主题」当标签：主题不稳定，且和 embedding 重叠
  标签更适合放「硬约束条件」和「业务边界」。

3. 标量增强

让检索从「相似」走向「可控」

这里的「标量」指的是：时间、版本、来源权重、权限、质量分、业务线等可以过滤或打分的字段。它们不靠向量表达，靠规则或数值逻辑表达。

3.1 标量增强解决什么问题

• 同一问题，不同时间答案不同：检索到旧版本会直接翻车
• 同一概念，不同地区/产品线口径不同：向量相似度分不出来
• 噪声文档混进知识库：相似度很高但质量很差
• 需要可解释、可审计：为什么给出这条证据，要说得清

把这些交给向量相似度，基本靠运气；交给标量逻辑，结果更可控。

3.2 两种最常用的做法

做法 A：先过滤，再向量检索
先用 metadata 把候选集缩小到“可能正确的范围”，再做语义召回。
典型过滤条件：

• 生效日期 <= 查询时间
• 版本号 = 当前版本
• 适用产品线包含用户所属产品线
• 权限满足访问控制

做法 B：向量召回后，用标量重打分
向量给你 TopK，标量给「业务优先级」：

• 新版文档加分，旧版扣分
• 官方来源加分，草稿扣分
• 被引用次数高/被人工验真过的内容加分

最后把两类分数合成一个总分再排序。

3.3 标量增强的关键点

• 标量字段要可维护：自动抽取优先，其次半自动，再其次人工
• 默认值要保守：缺字段宁可不加分，也别乱加分
• 线上要留日志：每个命中结果，把过滤条件、加分项写清楚，排障会省很多时间

4. 上下文增强

补回 chunk 被切断的前后依赖

上下文增强不是「塞更多文本」，它指的是：让每个可检索单元在被 embed 或被召回时，带上必要背景，避免「孤句误读」。

4.1 你会在哪些场景明显感到缺上下文

• 规章制度里一条规定引用了前面的定义
• 财报里一个指标只在章节开头定义一次，后面全是缩写
• 表格字段含义在表格上方说明里
• 会议纪要里“同意/不同意”要回看讨论对象是谁

这些内容即便向量召回命中了，模型也很容易误解，因为证据不自洽。

4.2 上下文增强常用的三种实现

实现 1：Embedding 前拼接轻量上下文
把 chunk 的标题路径、章节名、文档名等拼到 chunk 前面，再去做 embedding。
目标是让向量表达里包含“这句话属于哪里”。

实现 2：Parent / Window 思路（召回后扩窗）
先召回一个小块，然后按层级关系取它的父节点（小节/章节）或前后窗口。
这样不会让向量库里每个 chunk 变得巨大，但模型看到的上下文更完整。

实现 3：结构化索引 / 树检索（长文档很常用）
这类方法直接承认“文档是有层级结构的”，检索时先在结构上定位，再下钻到具体段落。

以 PageIndex 为例：它会生成类似「目录」的树结构，然后用 LLM 在树上做推理式检索，强调 No Vector DB、No Chunking、Human-like Retrieval，并且给出可追溯的页码/章节引用。

4.3 常见坑

• 上下文拼太多：embedding 变“平均化”，相似度反而变差
  只拼最有区分度的：标题路径、定义短句、字段解释。
• 扩窗没有边界：一扩就把整章塞给模型，成本和噪声都上来
  扩窗要有上限，优先拿“同小节”而不是“同文档”。

5. 稠密/稀疏两种向量一起用

使用 BM25 集成，把「关键词命中能力」补回来

稠密/稀疏向量是什么。

• 稠密向量检索（Dense / Embedding）：
  适合语义相近的表达，用户措辞变化大也能匹配到。
• 稀疏检索（Sparse / BM25）：
  适合精确词匹配，尤其是专有名词、编号、字段名、错误码、产品型号、合同条款号。

工程上最常见的现象是：
用户问了一个带编号/字段名的问题，向量检索给你一堆语义很像的段落，但就是没有那个编号对应的条款；BM25 往往一搜就中。

BM25 能给我们带来：

• 召回包含关键字的证据，避免向量漏召
• 对“必须精确命中”的问题更稳（例如政策条款号、表格字段、系统接口名）
• 对混合语料更友好（中英混排、代码片段、缩写、符号）

5.1 集成方式

工程里常用两种

方式 A：并行召回 + 合并去重 + 重排

• BM25 TopK 一份
• 向量 TopK 一份
• 合并成候选集，去重
• 用统一的 rerank（或简单规则）排出最终 TopN

这个方式的优点是直观，问题也直观：候选集会变大，要控制 K 和 rerank 成本。

国内阿里云的向量数据库有多维向量的逻辑，可指定权重召回。

方式 B：BM25 做第一阶段召回，向量做第二阶段精排（两段式）
适合语料特别大、向量检索成本高的场景。BM25 先把范围缩小，再在小集合里做语义相似度和重排。

5.2 常见坑

• 把 BM25 当主力：BM25 对同义改写不敏感，用户表达一变就丢召回
• 权重拍脑袋：BM25 和向量的分数尺度不同，直接线性加权经常不稳定
  更稳的做法通常是：先归一化，再做合并；或者交给 rerank 做最终裁决。
• 分词质量不过关：中文 BM25 的效果强依赖分词/词典
  词典里把产品名、缩写、字段名补齐，收益很实在。

6. 小结

以上的策略也不是一定要一起上，可以按阶段实施：

1. 人工切分打标：先把结构、版本、权限、范围做干净
2. BM25 集成：把关键字硬命中能力补齐，减少离谱失败
3. 上下文增强：解决「切碎」和「孤句误读」
4. 标量增强：把线上结果变得可控、可解释、可审计
5. 多向量检索：针对表格/图片/长文档，把跨形态检索打通

这 5 个策略并不冲突，实际生产系统基本是叠加使用：
BM25 兜底精确命中，向量负责语义召回，标量负责边界条件，上下文负责可读证据，多向量负责多形态内容。

在这些策略的基础上，我们可以使用如下的一些评估方式来判断是否优化有效：

• 召回层指标：TopK 是否包含正确证据（有无命中）
• 排序层指标：正确证据在 TopK 的位置分布（越靠前越好）
• 答案层指标：带引用的正确率、引用的可追溯性（页码/条款号/表格位置）
• 线上指标：无答案率、澄清率、人工升级率、重复追问率

尤其建议把「无答案率」和「引用可追溯性」拉出来单独看，它们最能反映检索链路是否健康。

以上。