RAG 原理与实践 on 扎塔-Zata

RAG生产实践：常见坑、性能优化与迭代路线图

Wed, 25 Mar 2026 15:55:00 +0800

RAG 的 Demo 很容易做，生产环境却很容易失控。

一开始你可能只要：

一个 embedding 模型
一个向量库
一个聊天模型

但真到线上，问题会迅速变成：

更新怎么做
成本怎么控
延迟怎么降
数据怎么隔离
错误怎么排查
版本怎么回归

所以生产级 RAG 的重点是"工程稳定性"，不只是"回答效果"。

这篇文章会讲：

生产环境最常见的坑
性能优化的思路
一个可执行的迭代路线

一、最常见的 10 个坑

坑 1：把所有文档放进一个大集合

现象：

公司有产品文档、技术规范、内部 wiki、销售话术、HR 制度……全部丢进一个向量库。

问题：

用户问"API 超时怎么配置"，检索结果混入了销售话术（因为提到了"时间"）、HR 制度（因为提到了"加班时间"）。正确答案被噪声淹没。

原理：

向量检索基于语义相似度。“时间"这个概念在很多文档里都出现，如果检索范围太大，语义相似的噪声也会被召回。

解决：

按业务边界拆分 source，检索时指定来源。

知识库结构：
├── product_docs/ # 产品文档
├── api_specs/ # API 规范
├── internal_wiki/ # 内部 wiki
└── hr_policies/ # HR 制度

检索时：
filter = {"source": "api_specs"}

效果：

配置	Recall@5	噪声比例
全量检索	58%	62%
按 source 过滤	84%	18%

坑 2：chunk 没有业务上下文

现象：

按段落切分后，某个 chunk 只剩一句话：“将旋钮调至 3 档，等待指示灯变绿。”

问题：

用户问"ZK-200 怎么校准”，这个 chunk 不会召回。因为产品名、设备类型、操作名称都在标题里——被切掉了。

原理：

Embedding 只能看到 chunk 内部的文字。如果 chunk 里没有"ZK-200"和"校准"这些关键词，向量就不会和这些问题相似。

解决：

把父级标题拼到 chunk 前面：

原始 chunk：
"将旋钮调至 3 档，等待指示灯变绿。"

补充上下文：
"【ZK-200 操作手册 > 2. 使用方法 > 2.3 校准流程】
将旋钮调至 3 档，等待指示灯变绿。"

效果：

配置	Recall@5
原始 chunk	41%
补充上下文后	78%

这是 RAG 里性价比最高的优化之一：成本几乎为零，效果翻倍。

坑 3：只做 dense search

现象：

用户问"错误码 E0028 是什么意思"，向量检索召回的是"常见错误码及解决方案"这种泛泛而谈的文档，而不是精确包含"E0028"的那段。

原理：

向量检索擅长语义相似，不擅长精确匹配。“E0028"作为一个编号，在向量空间里没有特殊意义，它只是一个 token。

解决：

引入 BM25 或 sparse 检索，做混合检索。

混合检索：
向量检索 → 召回语义相似的文档
BM25 检索 → 召回包含精确关键词的文档
RRF 融合 → 合并两路结果

效果：

检索方式	精确匹配查询 Recall@5	语义查询 Recall@5
向量检索	47%	82%
BM25	76%	58%
混合检索	84%	85%

坑 4：假 rerank

现象：

代码里写着"rerank”，但只是把向量分数重新排了一次序。

def rerank(candidates):
 return sorted(candidates, key=lambda x: x['score'], reverse=True)

问题：

这不是真正的 rerank，只是把已有的分数重新排序，效果和没有 rerank 一样。

原理：

真正的 Rerank 需要用 Cross-Encoder：

把 Query 和每个候选 Document 拼在一起
丢进 Transformer，让模型学习两者的交互
输出新的相关性分数

这比双塔结构的向量检索更精确，因为 Query 和 Document 能充分交互。

解决：

使用真正的 Cross-Encoder 模型：

候选文档 → Cross-Encoder → 新分数 → 重新排序

效果：

配置	Recall@5	正确答案平均排名
无 Rerank	72%	4.2
假 Rerank	72%	4.1
真 Rerank	88%	1.8

坑 5：top_k 和阈值写死

现象：

所有场景都用固定的 top_k=5 和 score_threshold=0.3。

问题：

简单问题：只需要 3 个候选就够了，多余的候选增加噪声
复杂问题：需要 10 个候选才能覆盖，5 个不够

原理：

检索参数取决于问题的复杂度、文档的分布、embedding 模型的特性。不同场景的最优参数不同。

解决：

参数可配置，甚至动态调整：

简单事实问题 → top_k=3, threshold=0.5（少而精）
复杂问题 → top_k=15, threshold=0（多召回）
对比类问题 → top_k=20（需要更多信息）

坑 6：没有 context budget 设计

现象：

检索到 15 个 chunk，全部塞进 prompt，总共 12000 tokens。

问题：

成本高：token 消耗大
延迟高：模型处理慢
效果差：内容太长，模型注意力分散（Lost in the Middle 问题）

原理：

LLM 的注意力机制在长文本上会分散。研究表明，当相关信息在 prompt 中间位置时，模型更容易忽略它。

解决：

设计 context budget：

预算：4000 tokens

组装策略：
1. 优先高分 chunk
2. 控制 token 总量
3. 必要时截断过长的 chunk
4. 保持来源多样性（不同 source 的 chunk 都有）

经验值：

场景	推荐 token 预算
简单问答	2000-3000
复杂问答	3000-5000
文档总结	5000-8000

坑 7：文档更新了，索引没同步

现象：

周一用户问"报销流程"，答案正确。周三财务更新了报销规范，周五用户再问，答案还是旧的。

问题：

文档更新后，向量库没有同步，还在用旧版本。

解决：

建立版本管理机制：

方案 1：定时全量同步
- 每天凌晨重建索引
- 简单但成本高

方案 2：增量更新
- 监控文档变更
- 只更新变化的文档
- 复杂但成本低

方案 3：版本标记
- 每个文档有版本号
- 检索时检查版本是否最新
- 过期则重新索引

关键：保留文档的 hash 或时间戳，便于判断是否需要更新。

坑 8：没有证据引用

现象：

模型回答：“报销需要提交发票和审批单。”

用户：“这个答案依据是什么？”

系统无法回答。

问题：

答案和来源脱节，用户无法验证答案的可信度。

解决：

Prompt 中强制要求引用：

要求：
1. 答案必须基于参考资料
2. 回答时标注引用来源，格式：[来源: 文档名 > 章节]
3. 如果不确定，说明不确定

答案示例：

报销需要提交发票和审批单 [来源: 财务规范 > 3.2 报销流程]。

好处：

用户可以验证答案
系统可以追溯错误
增加答案可信度

坑 9：没有离线 benchmark

现象：

开发者说"效果提升了"，产品说"感觉变差了"，谁也说服不了谁。

问题：

没有客观的评价标准，优化靠主观感受。

解决：

建立固定 benchmark：

评测集：
- 50-100 个问题
- 每个问题有期望召回的 chunk
- 每个问题有参考答案

定期评测：
- 每次改动后跑 benchmark
- 对比历史版本
- 设置阈值（如 Recall@5 > 80%）

原则：

评测集要隔离，不参与训练
定期从线上采样真实问题，更新评测集
多指标综合评估

坑 10：没有 inspect 能力

现象：

答案错了，不知道是检索错、排序错、还是模型错。

问题：

无法定位问题，优化靠猜。

解决：

保留每次请求的 Trace：

Trace 包含：
- 用户问题
- 检索候选（top-10）
- Rerank 结果
- 最终 prompt
- 模型答案

有 Inspect 页面，可以查看每一步的中间结果。

好处：

快速定位问题
积累 bad cases
指导优化方向

二、性能优化的思路

延迟分析

一个典型 RAG 请求的延迟分布：

总延迟：400-600ms

├── Query Embedding：30-50ms（5-10%）
├── 向量检索：30-50ms（5-10%）
├── BM25 检索：10-20ms（2-5%）
├── RRF 融合：<5ms（<1%）
├── Rerank：150-200ms（30-50%）← 主要瓶颈
├── Prompt 组装：<10ms（<1%）
└── LLM 生成：150-300ms（30-50%）← 主要瓶颈

两个主要瓶颈：Rerank 和 LLM 生成。

Rerank 优化

思路 1：减少候选数量

Rerank 的计算量与候选数量成正比。

100 个候选 × Cross-Encoder ≈ 200ms
30 个候选 × Cross-Encoder ≈ 70ms

但不能减太少，否则会漏掉正确答案。建议：

召回 50-100 个
Rerank 前 20-30 个
输出 top 5-10 个

思路 2：用更快的模型

模型	延迟（100 候选）	Recall@5
bge-reranker-large	~180ms	88%
bge-reranker-base	~95ms	85%
ms-marco-MiniLM	~45ms	80%

速度和效果的权衡。

思路 3：跳过简单问题

对于简单问题，可能不需要 Rerank：

简单问题（候选集中度高）→ 跳过 Rerank
复杂问题（候选分散）→ 需要 Rerank

判断标准：看 top-5 候选的分数分布。如果第一名分数远高于其他，说明检索已经足够准确。

LLM 优化

思路 1：用更快的模型

GPT-4o-mini 比 GPT-4o 快 3-5 倍，成本是 1/10。

对于大部分 RAG 场景，mini 版足够用。

思路 2：流式输出

不要等完整答案生成，边生成边返回：

传统模式：
用户等待 → 完整答案 → 一次返回（延迟高）

流式模式：
用户等待 → 第一个字 → 第二个字 → ...（感知延迟低）

流式不会减少实际延迟，但能改善用户体验。

思路 3：缓存热门 query

相同问题直接返回缓存：

热门问题 TOP 100：
"报销流程" → 缓存答案
"API 认证" → 缓存答案
...

命中率：10-30%
节省：10-30% 的 LLM 调用

检索优化

思路 1：缓存 query embedding

同一个问题的 embedding 可以缓存：

Query → Embedding（40ms）
Query（重复）→ 缓存（<1ms）

思路 2：预计算

某些场景可以预计算：

FAQ 场景：
- 预计算每个 FAQ 的 embedding
- 预计算每个 FAQ 的最佳答案
- 用户问题直接匹配 FAQ

适合问题集合固定的场景。

思路 3：减少召回数量

如果检索质量已经很高，可以减少召回数量：

top-50 → top-30
节省：向量检索和 Rerank 的时间
风险：可能漏掉正确答案

三、成本优化

Token 消耗分析

单次请求的 token 消耗：

输入 token：
- Query：20-50
- Chunks（5个）：2000-5000
- System prompt：100-200
总输入：2000-6000 tokens

输出 token：
- Answer：100-500

按 GPT-4o-mini 定价：
输入：$0.15/1M tokens
输出：$0.60/1M tokens

单次请求成本：$0.0003-0.001
日均 10000 次 → 月成本：$100-300

成本优化思路

1. 控制上下文长度

上下文太长不仅成本高，效果还差。

经验值：3000-4000 tokens

超过预算时：
- 截断过长的 chunk
- 减少进入 prompt 的 chunk 数量
- 优先保留高分的 chunk

2. 用更便宜的模型

GPT-4o-mini 的成本是 GPT-4o 的 1/10，效果差距不大。

3. 缓存热门问题

10-30% 的请求是重复问题，直接返回缓存。

4. 优化 prompt

去掉冗余的 prompt 内容，精简指令。

差的 prompt（冗长）：
"你是一个非常专业的技术文档助手，你的任务是根据用户提供的参考资料
来回答用户的问题。请注意，你的回答必须严格基于参考资料..."

好的 prompt（精简）：
"根据参考资料回答问题。答案必须基于资料，标注来源[数字]。"

四、迭代路线图

V1：能跑通（1-2 周）

目标：回答对 60% 的核心问题

配置：
- 基础 chunking（按段落）
- 纯向量检索（top_k=5）
- 基础 prompt + 引用要求

验收：
- 能回答常见问题
- 有引用来源
- 能 demo 演示

不要做：

不要全量导入所有文档
不要追求复杂架构
不要过度优化

V2：能诊断（2-3 周）

目标：知道为什么对/错

配置：
- Inspect 页面（看检索候选）
- Metadata 过滤
- 参数可配置
- 离线评测集（50 条）

验收：
- 能看到检索的 top-10
- 能定位问题在哪一层
- 有 Recall@5 指标

V3：能优化（3-4 周）

目标：召回率 80%+

配置：
- Hybrid Retrieval（向量 + BM25）
- 真 Rerank
- Chunking 优化（补充上下文）
- 评测集扩展（100 条）

验收：
- Recall@5 > 80%
- 能回答复杂问题
- Bad cases 持续跟踪

V4：能运营（持续）

目标：持续监控、持续迭代

配置：
- Trace 存储
- 监控大盘
- 告警规则
- 用户反馈收集
- CI/CD 集成

验收：
- 有质量监控
- 能快速定位线上问题
- 每次改动有回归测试

收益递减规律

60% → 80%：基础优化（chunking、混合检索）
80% → 90%：系统优化（Rerank、prompt 调优）
90% → 95%：高级优化（query rewrite、模型微调）
95% → 99%：难度极大，投入产出比低

建议：先做到 85%，再决定是否值得继续投入。

五、团队协作

角色分工

产品/运营：
- 定义知识边界
- 收集 bad cases
- 标注评测集
- 用户反馈归类

算法/NLP：
- Embedding 模型选择
- Rerank 模型调优
- Chunking 方案
- 高级策略

后端工程师：
- Ingestion pipeline
- 向量库维护
- Trace/Inspect 系统
- 性能优化
- 监控告警

协作流程

日常迭代：

1. 产品收集 bad cases
2. 算法分析问题（定位到哪一层）
3. 算法 + 后端共同优化
4. 跑 benchmark 验证
5. 上线 + 监控

问题归属

问题	归属	方向
召不回正确内容	算法	Chunking、检索策略
候选噪声多	算法	Rerank、过滤
答案格式不对	算法	Prompt
延迟高	后端	缓存、异步
系统不稳定	后端	稳定性
模型幻觉	算法	Prompt、模型选择
知识库没更新	产品/运营	文档维护流程

六、判断系统成熟度

如果满足以下条件，说明系统开始成熟：

□ 知道每次回答用了哪些证据
 （有 Inspect，能追溯）

□ 能复现错误回答的完整链路
 （有 Trace 存储）

□ 有固定 benchmark
 （定期跑，有阈值）

□ 能对比不同版本的质量
 （有版本管理，能 A/B）

□ 知道下一步优化哪一层
 （有监控，不是盲调）

如果这 5 条还做不到，最应该投入的不是"换更强模型"，而是把检索、Inspect 和评测体系补完整。

七、系列总结

这四篇文章回答了 RAG 的核心问题：

入门：

RAG 的本质：把知识从参数里剥离出来
Embedding 的原理：对比学习、向量空间
向量检索的局限：对精确匹配不稳定

进阶：

Chunking：按语义切分 + 补充上下文
混合检索：向量 + BM25 + RRF 融合
Rerank：Cross-Encoder 做真正的精排

评测：

分层评测：检索、重排、组装、生成
LLM-as-Judge：让大模型评判答案质量
Inspect：保留完整 Trace，定位单次问题

生产：

常见坑：上下文丢失、假 rerank、无引用
性能优化：缓存、模型选择、候选数量控制
迭代路线：从能跑到能运营

RAG 不是银弹，但它是目前让 LLM 接地气的最实用方案。关键在于：不要追求一步到位，而是建立可迭代的能力。

后续可以深入的方向：

Query Rewrite 和 Query Decomposition
Contextual Retrieval（Anthropic 的方法）
多租户与权限设计
RAG 与 Agent 的结合
多模态 RAG（图片、表格）

RAG评测与 Inspect：如何知道问题出在检索、重排还是生成

Wed, 25 Mar 2026 15:50:00 +0800

很多 RAG 项目最开始都能跑起来，但一到线上就会卡在一个非常现实的问题上：

用户说答案不对，可你根本不知道问题出在：

没召回到正确内容
召回到了，但排序不对
排好了，但没进最终 prompt
进了 prompt，但模型没用
模型用了，但引用展示错了

所以 RAG 一定不能只做"生成结果观测"，还要做"阶段化 inspect"。

这篇文章会讲：

如何分层定位问题
检索层和生成层的评测指标
LLM-as-a-Judge 的原理
Inspect 系统的设计思路

一、为什么评测这么难

RAG 的评测比传统检索或传统 NLP 都复杂，因为它是多阶段的 pipeline。

用户问题 → 检索 → 重排 → 组装 → 生成 → 答案

最终答案错了，可能的原因：

❌ 检索层：正确内容根本没召回
❌ 重排层：正确内容召回但被排到后面
❌ 组装层：正确内容被截断或过滤掉了
❌ 生成层：模型无视证据自由发挥

如果不分阶段评测，你只能知道"答案错了"，但不知道"为什么错"。

一个真实的问题定位案例

用户投诉：“问错误码 401 的意思，答案完全不对。”

定位过程：

第 1 步：检查检索层
- 用户问题："错误码 401 是什么意思"
- 检索候选 top-10：
 1. 常见 HTTP 错误码列表
 2. 认证失败怎么办
 3. 权限问题排查
 ...
 8. 错误码详解：401 Unauthorized ← 正确答案

结论：正确答案在候选里，但排第 8

第 2 步：检查重排层
- Rerank 后：
 1. 错误码详解：401 Unauthorized ← 正确答案排到第 1
 2. 常见 HTTP 错误码列表
 ...

结论：重排正常

第 3 步：检查组装层
- 最终进入 prompt 的 chunk：
 1. 错误码详解：401 Unauthorized ✅
 2. 常见 HTTP 错误码列表 ✅
 3. 认证失败怎么办 ✅

结论：组装正常

第 4 步：检查生成层
- Prompt 包含正确证据
- 模型输出："错误码 401 表示服务器内部错误..."

结论：模型幻觉！401 是认证错误，不是服务器内部错误

最终诊断：
✅ 检索层：正常
✅ 重排层：正常
✅ 组装层：正常
❌ 生成层：模型无视证据，产生幻觉

解决方案：优化 prompt，强化"必须依据证据"的约束

这就是为什么需要分阶段评测——不同阶段的问题，解决方案完全不同。

二、问题分层框架

建议用下面这套分层框架，每层有明确的责任边界和常见问题：

┌─────────────────────────────────────────────────────────────────┐
│ 第 1 层：检索层（Retrieval） │
│ │
│ 职责：从知识库中召回候选内容 │
│ │
│ 常见问题： │
│ ❌ 正确 chunk 不在候选里 → chunking、embedding、检索策略 │
│ ❌ 正确 chunk 排名太低 → 混合检索、Rerank │
│ ❌ 候选噪声太多 → metadata 过滤、召回数量调整 │
│ │
│ 评测指标：Recall@K、MRR │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 第 2 层：重排层（Rerank） │
│ │
│ 职责：对候选重新排序，提升相关性 │
│ │
│ 常见问题： │
│ ❌ 正确 chunk 被排到后面 → Rerank 模型问题 │
│ ❌ Rerank 效果不明显 → 模型选择、候选数量 │
│ │
│ 评测指标：排序提升比例、NDCG │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 第 3 层：上下文组装层（Context Assembly） │
│ │
│ 职责：控制进入 prompt 的内容和数量 │
│ │
│ 常见问题： │
│ ❌ 正确 chunk 被截断 → 调整 token 预算 │
│ ❌ 正确 chunk 被过滤 → 检查过滤规则 │
│ ❌ 内容太长噪声多 → 优化组装策略 │
│ │
│ 评测指标：正确 chunk 进入 prompt 的比例 │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 第 4 层：生成层（Generation） │
│ │
│ 职责：基于证据生成答案 │
│ │
│ 常见问题： │
│ ❌ 模型无视证据 → Prompt 优化 │
│ ❌ 产生幻觉 → 强化约束、Few-shot │
│ ❌ 引用错误 → 后处理校验 │
│ │
│ 评测指标：答案正确率、幻觉率、引用准确率 │
└─────────────────────────────────────────────────────────────────┘

分层的意义

每一层的问题，需要不同的解决方案：

问题层	典型问题	解决方向
检索层	召不回正确内容	Chunking、混合检索
重排层	排序不对	Rerank 模型
组装层	内容被过滤	组装策略、预算调整
生成层	模型幻觉	Prompt 优化、模型选择

不分层的问题：你发现答案错了，只能"盲调"——换模型、调参数，但不知道调的是哪个环节。

分层的好处：知道问题在哪一层，定向优化。

三、检索层评测

检索层的核心问题是：正确的 chunk 召回了吗？排得够靠前吗？

Recall@K

最直观的指标：正确答案是否在前 K 个候选里。

Recall@K = 正确答案在前 K 的请求数 / 总请求数

示例：

评测集 100 个问题
每个问题有 1-3 个正确 chunk

Recall@5 = 82/100 = 82%（82 个问题的正确 chunk 在前 5）
Recall@10 = 91/100 = 91%（91 个问题的正确 chunk 在前 10）

解读：

Recall@5 > 80%：检索质量良好
Recall@5 < 60%：检索需要优化
Recall@5 ≈ Recall@10：排序效果好（正确答案排在前面）
Recall@5 « Recall@10：排序效果差（正确答案在后面）

MRR（Mean Reciprocal Rank）

Recall@K 只看"是否在前 K"，MRR 还看"具体排第几"。

MRR = Σ (1 / 正确答案的排名) / 总请求数

示例：

问题 1：正确答案排第 1 → 1/1 = 1.0
问题 2：正确答案排第 3 → 1/3 = 0.33
问题 3：正确答案排第 5 → 1/5 = 0.20
问题 4：正确答案未召回 → 1/∞ = 0

MRR = (1.0 + 0.33 + 0.20 + 0) / 4 = 0.38

解读：

MRR > 0.6：排序质量好
MRR < 0.4：排序需要优化

NDCG（Normalized Discounted Cumulative Gain）

更精细的指标，考虑多个正确答案的情况。

DCG = Σ (2^rel_i - 1) / log2(i + 1)

其中：
- rel_i：第 i 个位置的相关性（1=相关，0=不相关）
- i：排名位置

NDCG = DCG / IDCG

IDCG 是理想情况下的 DCG（所有相关文档都排在最前面）

直觉：正确答案排得越靠前，分数越高；排在后面会被惩罚（除以 log）。

不同指标的选择

指标	适用场景	优点	缺点
Recall@K	只关心是否召回	直观、易解释	不关心具体排名
MRR	关心正确答案的排名	考虑排名	只考虑第一个正确答案
NDCG	有多个正确答案	全面	计算复杂

建议：日常用 Recall@5 + Recall@10，深入分析用 MRR 和 NDCG。

四、生成层评测

检索层评测相对客观，生成层评测更主观——“答案好不好"没有标准答案。

传统指标

1. BLEU / ROUGE

来自机器翻译和摘要领域，计算模型输出和参考答案的 n-gram 重叠度。

BLEU-1: 单词重叠
BLEU-2: 二元组重叠
...
ROUGE-L: 最长公共子序列

问题：RAG 答案不追求和参考答案"字面相似”，而是追求"语义正确"。

参考答案："使用 Bearer Token 认证"
模型答案："认证方式是 Bearer Token"

BLEU 分数不高，但语义完全正确。

2. BERTScore

用 BERT 编码后计算语义相似度。比 n-gram 更好，但对 RAG 仍不够精确。

LLM-as-a-Judge

让大模型来评判答案质量，是目前最实用的方法。

思路：

输入：
- 用户问题
- 参考答案（可选）
- 模型答案
- 证据内容（检索到的 chunk）

输出：
- 分数（1-5）
- 是否正确
- 是否有幻觉
- 具体问题

Prompt 设计：

你是一个答案质量评判专家。请评判以下答案的质量。

问题：{question}

参考资料：
{context}

参考答案：{expected_answer}

模型答案：{actual_answer}

请评判：
1. 正确性（1-5分）
2. 是否包含幻觉（编造参考资料中没有的信息）
3. 是否遗漏关键信息
4. 引用是否正确

以 JSON 格式输出：
{
 "score": 1-5,
 "is_correct": true/false,
 "has_hallucination": true/false,
 "issues": ["问题1", "问题2"],
 "explanation": "评分理由"
}

为什么有效？

LLM 本身有很强的语义理解能力，能判断"语义相似"而非"字面相似"。而且 LLM 能理解上下文，判断答案是否"基于证据"。

注意事项：

评判模型要强：用 GPT-4 或 Claude，不要用小模型
避免自我评判：生成模型和评判模型要不同
Few-shot 示例：给几个评分示例，提高一致性
多次评判取平均：减少随机性

评测指标的层次

生成层评测应该回答几个不同的问题：

问题	指标	怎么测
答案对吗？	正确率	LLM 评判 + 人工抽查
有幻觉吗？	幻觉率	检查答案是否超出证据范围
引用对吗？	引用准确率	检查引用的 chunk 是否支持答案
用户满意吗？	满意度	用户反馈

幻觉检测是最重要的，因为 RAG 的核心价值是"有据可查"。

幻觉检测的方法

方法 1：LLM 评判

Prompt：
"以下答案是否包含参考资料中没有的信息？"

答案：{answer}
参考资料：{context}

请指出答案中的每一句话，并判断是否有证据支持。

方法 2：NLI（自然语言推理）

用 NLI 模型判断答案和证据之间的关系：

前提（证据）："Token 有效期为 24 小时"
假设（答案）："Token 有效期为 48 小时"

NLI 输出：Contradiction（矛盾）

方法 3：关键词匹配

简单但粗糙：检查答案中的关键信息是否在证据中出现。

答案："API 超时时间是 30 秒"
证据："API 的默认超时时间为 30 秒"

匹配：✅（"超时"、"30"、"秒"都在证据中）

五、离线评测 vs 在线评测

离线评测

目的：在上线前验证系统质量

方法：

准备评测集（50-100 条）
定期跑评测
对比不同版本

评测集构建：

评测集应该包含：
- 核心问题（30%）：业务最常见的问题
- 边界问题（30%）：难度高、容易出错的
- 长尾问题（20%）：覆盖更多场景
- 坏案例（20%）：之前出过问题的

每条评测数据：
{
 "id": "eval_001",
 "question": "API 的认证方式是什么",
 "expected_chunks": ["chunk_012"], // 期望召回的 chunk
 "expected_answer": "Bearer Token", // 参考答案
 "category": "技术问题",
 "difficulty": "easy"
}

评测流程：

1. 运行 RAG 系统，获取结果
2. 计算检索指标（Recall@K、MRR）
3. 计算生成指标（正确率、幻觉率）
4. 汇总报告
5. 对比历史版本

在线评测

目的：在生产环境持续监控

方法：

用户反馈：点赞/点踩、修改问题、人工标注
自动评分：用 LLM 对线上答案打分
行为分析：用户是否追问、是否放弃

采样策略：

不是所有请求都需要详细评测（成本高）。建议：

100% 记录基本信息（延迟、召回数量）
10% 详细评分（LLM 评判）
1% 人工审核

评测陷阱

陷阱 1：评测集泄露

训练 Embedding 模型或 Rerank 模型时，不小心用了评测集里的内容。评测分数虚高，线上效果差。

解决：评测集严格隔离，不参与任何训练。

陷阱 2：评测集不代表真实

评测集都是"理想问题"，线上用户的问题五花八门：口语化、错别字、表达不清。

解决：定期从线上采样真实问题，加入评测集。

陷阱 3：只看单一指标

只看 Recall@5，可能忽略了答案质量。检索到了，但答案仍然不好。

解决：多指标综合评估，建立指标大盘。

六、Inspect 系统：定位单次问题

评测解决"系统整体质量"，Inspect 解决"某次请求为什么出错"。

Inspect 系统的核心能力

能力	回答的问题	需要的数据
检索可视化	召回了什么？排第几？	候选列表、分数
重排对比	Rerank 前后有什么变化？	重排前后列表
Prompt 快照	模型看到了什么？	最终 prompt
引用追溯	答案来自哪？	引用的 chunk

Trace 的数据结构

每次请求都应该保存完整的 Trace：

Trace 结构：

{
 "trace_id": "唯一标识",
 "timestamp": "请求时间",
 "query": "用户问题",

 "retrieval": {
 "dense_results": [
 {"chunk_id": "xxx", "score": 0.82, "rank": 1},
 ...
 ],
 "bm25_results": [
 {"chunk_id": "xxx", "score": 5.2, "rank": 1},
 ...
 ],
 "merged_results": [...], // RRF 融合后
 "reranked_results": [...] // Rerank 后
 },

 "context": {
 "final_chunks": [...], // 最终进入 prompt 的
 "prompt": "...", // 完整 prompt
 "token_count": 3200
 },

 "generation": {
 "answer": "模型回答",
 "citations": [...],
 "model": "gpt-4o-mini"
 },

 "latency": {
 "total_ms": 450,
 "retrieval_ms": 50,
 "rerank_ms": 180,
 "generation_ms": 220
 }
}

Inspect 页面的设计

一个实用的 Inspect 页面应该包含：

1. 概览区

问题：错误码 401 是什么意思
答案：401 表示认证失败...
耗时：450ms
状态：❌ 答案错误（模型幻觉）

2. 检索区

Dense 检索结果：
#1 [0.82] 常见 HTTP 错误码
#2 [0.79] 认证失败怎么办
...
#8 [0.65] 错误码详解：401 ← 正确答案

BM25 检索结果：
#1 [5.2] 错误码详解：401 ← 正确答案
#2 [4.8] 常见 HTTP 错误码
...

Rerank 后：
#1 [0.92] 错误码详解：401 ← 正确答案排到第 1
...

3. Prompt 区

最终进入 Prompt 的 chunk：
[1] 错误码详解：401 Unauthorized
 Token 无效或已过期...
[2] 常见 HTTP 错误码
 ...

完整 Prompt：
[显示完整 prompt 内容]

4. 评分区

检索是否正确：✅
答案是否正确：❌
是否有幻觉：✅（模型说"服务器内部错误"）
备注：________________

Trace 的存储

方案	优点	缺点
SQLite	简单、本地	不适合大规模
PostgreSQL	功能强	需要运维
Elasticsearch	搜索方便	成本高
专用平台（LangSmith、Langfuse）	功能全	可能有成本

建议：小规模用 SQLite/PostgreSQL，大规模用专用平台。

七、排障流程

当你发现某个问题回答不对时，按这个流程排查：

第 1 步：获取 Trace ID
从用户反馈或日志中获取

第 2 步：检查检索层
正确 chunk 是否在候选里？

❌ 不在候选：
 → 检查 chunking（是否被切碎）
 → 检查 embedding（是否理解正确）
 → 检索策略（是否需要混合检索）

✅ 在候选但排名靠后：
 → 继续检查重排层

第 3 步：检查重排层
Rerank 后排名是否提升？

❌ 排名下降或不变：
 → Rerank 模型可能不适合这个场景
 → 考虑换模型或调整权重

✅ 排名提升但仍不在 top-5：
 → 召回数量不够
 → 增加召回数量

第 4 步：检查组装层
正确 chunk 是否进入 prompt？

❌ 未进入：
 → 被截断：调整 token 预算
 → 被过滤：检查过滤规则

✅ 已进入：
 → 继续检查生成层

第 5 步：检查生成层
模型是否正确使用证据？

❌ 模型无视证据：
 → 强化 prompt 约束
 → 添加 Few-shot 示例

❌ 模型幻觉：
 → 明确"不确定时说明不确定"
 → 后处理校验

❌ 引用错误：
 → 优化引用格式要求
 → 后处理修正

八、本文小结

RAG 要做到可迭代，必须建立完整的评测和观测体系：

能力	解决的问题	核心方法
分层评测	定位问题在哪一层	Recall@K、LLM-as-Judge
离线评测	验证系统质量	评测集 + 定期跑分
在线评测	监控生产质量	采样 + 自动评分
Inspect	定位单次问题	Trace + 可视化

核心建议：

先建评测集：没有评测集，优化都是盲人摸象
分层评测：检索和生成分开评，知道优化哪一层
保留 Trace：每次请求都记录中间结果
持续监控：建立指标大盘，设置告警

只有这样，才能从"会用 RAG"走到"会调 RAG"。

下一篇会讲生产环境最常见的坑，以及一条可执行的迭代路线。

RAG进阶：Chunking、召回、Hybrid Search 与 Rerank

Wed, 25 Mar 2026 15:45:00 +0800

很多人第一次做 RAG，默认流程都是：

文档切 chunk
生成 embedding
向量检索 top_k
拼 prompt
让模型回答

这条路径能跑，但往往不稳。真正让 RAG 质量提升一个台阶的，通常是三件事：

chunking 做得更合理 — 切出来的 chunk 能独立成为证据
召回从单路 dense 变成多路召回 — 结合语义和关键词
用真正的 rerank 做精排 — 不是简单重排，而是用 cross-encoder 重新打分

这篇文章会深入讲这三个环节的算法原理。

一、Chunking：为什么"切短一点"不简单

Chunking 的目标不是凑 embedding 输入长度，而是让"一个 chunk 刚好能独立成为证据"。

好的 Chunk 应该满足什么

四个标准：

语义完整 — 一个 chunk 能回答一个独立的问题
粒度适中 — 太大噪声多，太小信息不够
上下文自洽 — 不依赖外部信息也能理解
可追溯 — 知道来自哪个文档、哪个章节

固定长度切分的问题

最简单的做法是按字符数切：

每 500 个字符切一段

问题：

问题 1：语义被切断

原文：
"所有 API 请求必须在 Header 中携带 Bearer Token。Token 有效期为 24 小时，
过期后需重新获取。获取方式：调用 /auth/token 接口，传入 client_id
和 client_secret。"

固定切分后，某个 chunk 可能变成：
"过期后需重新获取。获取方式：调用 /auth/token 接口，传入 client_id"

用户问"Token 有效期多久？"，这个 chunk 不会召回。

问题 2：上下文丢失

原文：
"### 2.3 校准流程
将旋钮调至 3 档，等待指示灯变为绿色后松开。"

按段落切分后：
"将旋钮调至 3 档，等待指示灯变为绿色后松开。"

用户问"ZK-200 怎么校准"，这个 chunk 不会召回。
因为"ZK-200"在标题里，"校准"在章节名里——都被切掉了。

语义切分的思路

更好的方法是按文档的自然结构切分：

1. 按 Markdown 标题切分

Markdown 文档有天然的层级结构：

# 一级标题
## 二级标题
### 三级标题

切分策略：每个标题下的内容作为一个 chunk，并保留标题作为上下文。

Chunk 1:
【API 规范 > 2. 认证 > 2.1 认证方式】
所有 API 请求必须在 Header 中携带 Bearer Token...

Chunk 2:
【API 规范 > 2. 认证 > 2.2 Token 获取】
调用 /auth/token 接口获取 Token...

2. 按段落切分

对于没有明确结构的文档，按段落切分比按字符数好：

段落边界通常是语义边界。
一个段落讲一个观点，不会把一句话切两半。

3. 语义切分（高级）

用 Embedding 模型判断相邻段落的语义相似度：

步骤：
1. 把文档按句子切分
2. 计算相邻句子的 embedding 相似度
3. 相似度低的地方 = 语义边界，切分

直觉：如果两句话语义相似度低，说明在讲不同的话题，应该分开。

代价：计算量大，不一定比结构化切分更好。

Contextual Chunking：最重要的一步

无论用什么切分方法，都建议做一步：把父级标题拼到 chunk 前面。

原始 chunk：
"将旋钮调至 3 档，等待指示灯变为绿色后松开。"

补充上下文后：
"【ZK-200 操作手册 > 2. 使用方法 > 2.3 校准流程】
将旋钮调至 3 档，等待指示灯变为绿色后松开。"

为什么有效？

原理：Embedding 模型会把整个 chunk 编码成一个向量。如果 chunk 里包含"ZK-200"和"校准"，当用户问"ZK-200 怎么校准"时，相似度就会高。

实测效果：

配置	Recall@5	说明
原始 chunk	41%	大量 chunk 缺上下文
补充标题上下文	78%	效果翻倍

成本几乎为零，但效果提升明显。这是 RAG 里性价比最高的优化之一。

Chunk 粒度的权衡

太大 vs 太小：

问题	太大（1000+ 字）	太小（<100 字）
噪声	噪声多，关键信息被埋	信息不够，上下文缺失
检索	容易召回不相关内容	可能召回片段，语义不完整
成本	Token 消耗大	Chunk 数量多，索引大

经验值：300-500 tokens（中文约 200-350 字）

但比长度更重要的是语义完整性。宁可长度不均，也不要语义被切断。

不同文档类型的切分策略

文档类型	推荐策略	原因
FAQ	一条一 chunk	每条 FAQ 天然独立
技术文档	按标题/小节	标题是天然语义边界
产品手册	按操作步骤	一个步骤一个 chunk
合同/法规	按条款	每条条款有独立法律意义
对话记录	按问答对	一问一答是完整语义单元

二、BM25：关键词检索的经典算法

向量检索擅长语义相似，但对精确匹配不稳定。解决方案是引入关键词检索。

最经典的关键词检索算法是 BM25（Best Matching 25）。

BM25 的原理

BM25 是 TF-IDF 的改进版。先理解 TF-IDF：

TF-IDF = TF × IDF

TF（Term Frequency）：词在文档中出现的次数
- 出现越多，越重要？不完全是，需要惩罚高频词
IDF（Inverse Document Frequency）：词的稀有程度
- 在所有文档中很少出现 → 区分度高 → 权重高
- 在所有文档中都出现（如"的"、“是”）→ 区分度低 → 权重低

问题：TF 会过度奖励高频词。一个词出现 10 次不代表比出现 1 次重要 10 倍。

BM25 的改进：对 TF 做饱和处理。

BM25 公式

score(D, Q) = Σ IDF(qi) × (f(qi, D) × (k1 + 1)) / (f(qi, D) + k1 × (1 - b + b × |D|/avgdl))

其中：
- D：文档
- Q：查询（包含多个词 q1, q2, ...）
- qi：查询中的第 i 个词
- f(qi, D)：词 qi 在文档 D 中的词频
- |D|：文档 D 的长度
- avgdl：平均文档长度
- k1：词频饱和参数（通常 1.2-2.0）
- b：长度归一化参数（通常 0.75）

IDF(qi) = log((N - n(qi) + 0.5) / (n(qi) + 0.5) + 1)
- N：总文档数
- n(qi)：包含词 qi 的文档数

直觉理解：

词频饱和：(f × (k1+1)) / (f + k1) 是一个饱和函数。当 f 很大时，增长变慢。一个词出现 10 次，权重不是 10 倍，而是趋于 k1+1。
长度归一化：长文档天然有更高的词频，需要惩罚。|D|/avgdl 是相对长度，通过参数 b 控制惩罚程度。
IDF 奖励稀有词：在少数文档中出现的词，IDF 高，权重高。

BM25 的特点

优点	缺点
对精确匹配敏感	不理解语义
对编号、术语稳定	同义词问题（“电脑"和"计算机"是两个词）
计算快，可解释	需要分词（中文需要额外的分词步骤）
不需要训练	不适合自然语言问题

适用场景：

用户查询包含编号、版本号、专业术语
文档中有大量缩写、代码
需要精确匹配的场景

中文分词

BM25 依赖词的边界。英文天然有空格分隔，中文需要额外的分词步骤。

常用分词工具：

工具	特点
jieba	最流行，词典+HMM
pkuseg	北大出品，准确率高
HanLP	功能全，支持多种任务

分词质量直接影响 BM25 效果。比如：

"用户体验设计"

分词 1：用户 / 体验 / 设计（三个词）
分词 2：用户体验 / 设计（两个词）
分词 3：用户 / 体验设计（两个词）

不同的分词，检索结果不同。

三、Hybrid Retrieval：语义 + 关键词

向量检索和 BM25 各有优劣，互补性很强。

为什么需要混合

向量检索：
- 擅长：语义相似、同义词、自然语言问题
- 弱项：精确匹配、编号、专业术语

BM25：
- 擅长：精确匹配、编号、专业术语
- 弱项：语义理解、同义词、自然语言问题

实测对比：

查询类型	向量检索 Recall@5	BM25 Recall@5
语义查询（“怎么获取令牌”）	82%	58%
精确匹配（“错误码 401”）	47%	76%
编号查询（“版本 v2.3.1”）	38%	69%
混合查询（“API v2 认证方式”）	64%	71%

没有哪种方法在所有场景下都最优。混合检索可以兼顾两者。

混合检索的架构

Query
 │
 ├─── 向量检索 ──→ Dense 候选集（top-50）
 │
 ├─── BM25 检索 ──→ Sparse 候选集（top-50）
 │
 └─── Metadata 过滤 ──→ 过滤后的候选集
 │
 ▼
 结果融合
 │
 ▼
 Rerank（可选）
 │
 ▼
 最终结果（top-5）

结果融合：RRF（Reciprocal Rank Fusion）

两路检索结果怎么合并？简单的方法是按分数加权，但问题：向量分数和 BM25 分数不在同一个尺度，不好比较。

更优雅的方法是 RRF（Reciprocal Rank Fusion）：不依赖分数，只依赖排名。

RRF 公式：

RRF_score(d) = Σ 1 / (k + rank_i(d))

其中：
- d：文档
- rank_i(d)：文档 d 在第 i 路检索中的排名
- k：平滑参数（通常取 60）

直觉：

排名第 1 的文档得分：1/(60+1) ≈ 0.0164
排名第 2 的文档得分：1/(60+2) ≈ 0.0159
排名第 10 的文档得分：1/(60+10) ≈ 0.0143

排名越高，得分越高，但差距被平滑。k 越大，不同排名之间的得分差距越小。

为什么有效？

不依赖分数：避免了分数归一化的问题
鲁棒性强：单路检索的异常高分不会主导结果
简单高效：只需要排名信息，计算量小

示例：

Query："错误码 401"

向量检索结果：
1. Doc_A（向量分数 0.82）
2. Doc_B（向量分数 0.79）
3. Doc_C（向量分数 0.76）

BM25 检索结果：
1. Doc_D（BM25 分数 5.2）
2. Doc_C（BM25 分数 4.8）
3. Doc_A（BM25 分数 4.1）

RRF 融合（k=60）：
Doc_A: 1/(60+1) + 1/(60+3) = 0.0164 + 0.0159 = 0.0323
Doc_B: 1/(60+2) + 0 = 0.0159（BM25 没召回）
Doc_C: 1/(60+3) + 1/(60+2) = 0.0159 + 0.0159 = 0.0318
Doc_D: 0 + 1/(60+1) = 0.0164（向量没召回）

最终排序：Doc_A > Doc_C > Doc_B > Doc_D

Doc_A 在两路都有出现，最终得分最高。这就是 RRF 的魅力：两路都召回的文档，更有可能是相关的。

Metadata 过滤

除了向量检索和 BM25，还可以利用元数据做过滤：

用户问："销售合同模板在哪下载？"

先过滤：source = "sales_docs"
再检索：在销售文档范围内检索

好处：
- 缩小检索范围，减少噪声
- 提高检索精度
- 支持权限隔离（不同用户可见不同来源）

过滤可以在检索前（pre-filtering）或检索后（post-filtering）。主流向量库都支持 pre-filtering，效率更高。

四、Rerank：精排的原理

召回阶段的目标是"别漏掉”，所以召回数量较多，难免混入噪声。Rerank 阶段的目标是"降噪"，从候选中选出最相关的。

为什么需要 Rerank

向量检索和 BM25 都是"双塔"结构：

Query → Encoder → Query Vector ─┐
 ├→ Similarity
Document → Encoder → Doc Vector ─┘

Query 和 Document 各自编码，只在最后计算相似度。

问题：Query 和 Document 之间的交互太少。编码时看不到对方，只能依赖各自的信息。

Rerank 的思路：让 Query 和 Document 充分交互，更精确地判断相关性。

Cross-Encoder 的工作原理

Cross-Encoder 是"单塔"结构：

Query + Document → Transformer → Relevance Score

把 Query 和 Document 拼在一起，丢进 Transformer，让模型自己学习两者的交互。

示意：

输入：[CLS] Query [SEP] Document [SEP]

Transformer 会计算每个 token 和其他所有 token 的注意力，
包括 Query token 和 Document token 之间的交互。

输出：[CLS] 位置的向量 → 全连接层 → 相关性分数

为什么比双塔更准？

双塔：Query 编码时看不到 Document，只能用通用的语义表示。单塔：Query 和 Document 一起编码，模型可以看到两者之间的关系。

比如：

Query："苹果的价格"
Document 1："苹果公司股价下跌"
Document 2："水果店苹果 5 元一斤"

双塔可能把两个 Document 都召回（都包含"苹果"和"价格"相关词）
Cross-Encoder 能判断：Document 2 更相关（语义上"价格"指水果价格，不是股价）

为什么不能替代检索？

Cross-Encoder 需要把 Query 和每个 Document 都拼起来过一遍模型。

计算量 = 候选数量 × Transformer 计算量

如果候选是 100 万，计算量巨大，延迟无法接受。

所以只能用在召回之后，对小规模候选做精排。

Rerank 模型

常用 Rerank 模型：

模型	特点	延迟（100 候选）
bge-reranker-large	开源，效果好	~180ms
bge-reranker-base	开源，更快	~95ms
cohere rerank-3	API，效果好	~120ms
ms-marco-MiniLM	开源，轻量	~45ms
jina-reranker-v2	开源，多语言	~80ms

选择考虑：

追求效果：bge-reranker-large 或 cohere rerank-3
追求速度：ms-marco-MiniLM 或 bge-reranker-base
中文场景：bge-reranker-large 或 jina-reranker-v2
私有化部署：bge 系列

Rerank 的效果

实测对比：

配置	Recall@5	正确答案平均排名
向量检索	72%	4.2
混合检索（无 Rerank）	79%	3.5
混合 + Rerank	88%	1.8

Rerank 后，正确答案的平均排名从 3.5 提升到 1.8——明显更靠前，更容易进入最终的 prompt。

五、完整的检索流程

结合以上内容，一个完整的检索流程如下：

┌─────────────────────────────────────────────────────────────────┐
│ 用户 Query │
│ "错误码 401 是什么意思" │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 阶段 1：候选召回（Recall） │
│ │
│ 目标：不漏掉，召回足够多的候选 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 向量检索 │ │ BM25 检索 │ │
│ │ top-50 │ │ top-50 │ │
│ │ │ │ │ │
│ │ 擅长语义相似 │ │ 擅长精确匹配 │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ └─────────┬──────────┘ │
│ ▼ │
│ ┌─────────────┐ │
│ │ RRF 融合 │ │
│ │ ~80 候选 │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ Metadata │ │
│ │ 过滤 │ │
│ │ ~60 候选 │ │
│ └──────┬──────┘ │
└─────────────────────┼──────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 阶段 2：精排（Rerank） │
│ │
│ 目标：从候选中选出最相关的 │
│ │
│ 输入：~60 个候选 │
│ 处理：Cross-Encoder 重新打分 │
│ 输出：top-10 │
│ │
│ 耗时：~150ms │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 阶段 3：上下文组装 │
│ │
│ 目标：控制进入 prompt 的内容 │
│ │
│ 输入：top-10 候选 │
│ 处理： │
│ 1. 控制总长度（如 4000 tokens） │
│ 2. 保持多样性（不同 source 的 chunk） │
│ 3. 去重 │
│ 输出：5-8 个 chunk │
└────────────────────────┬────────────────────────────────────────┘
 ▼
 构建 Prompt
 调用 LLM
 答案

各阶段的参数建议

阶段	参数	推荐值	说明
向量召回	top_k	50-100	宁多勿少
BM25 召回	top_k	50-100	宁多勿少
RRF	k	60	经验值，一般不用调
Rerank	输入	20-30	不用太大，计算慢
Rerank	输出	10-15	给 prompt 组装留空间
Prompt 组装	最终数量	3-8	不宜过多
Prompt 组装	token 预算	3000-4000	根据模型调整

各阶段的延迟占比

总延迟：~300-500ms

向量检索：30-50ms（10%）
BM25 检索：10-20ms（5%）
RRF 融合：<5ms（<1%）
Rerank：150-200ms（50%）← 主要瓶颈
Prompt 组装：<10ms（<5%）
LLM 调用：100-200ms（35%）← 另一个瓶颈

优化方向：

减少 Rerank 候选数：从 30 减到 20，节省 ~50ms
用更快的 Rerank 模型：bge-reranker-base 比 large 快 ~80ms
缓存热门 query：相同问题直接返回，跳过整个流程

六、Query Rewrite：高级优化

检索质量不仅取决于检索算法，还取决于 Query 本身。

用户的问题往往不够清晰，需要"改写"才能更好地检索。

常见的改写策略

1. 同义词扩展

原始："怎么获取令牌"
改写："怎么获取令牌 OR token OR access_token"

2. 拼写纠正

原始："错误码 4O1"（字母 O）
改写："错误码 401"（数字 0）

3. 核心词提取

原始："我想了解一下关于 API 超时时间的配置方法"
改写："API 超时时间 配置"

去掉无意义的词，保留核心检索词。

4. Query 分解

原始："对比 v2.0 和 v2.1 版本的 API 差异"
分解：
- Query 1："v2.0 版本 API 特性"
- Query 2："v2.1 版本 API 特性"
- Query 3："v2.0 v2.1 版本差异"

复杂问题拆成多个简单问题，分别检索，再合并。

5. 假设文档生成（HyDE）

原始："API 的认证方式是什么"
生成假设文档：
"API 的认证方式使用 Bearer Token。所有请求需要在 Header 中携带
Authorization: Bearer <token>。Token 有效期 24 小时..."

用假设文档去检索，而不是原始 query。

直觉：假设文档和真实文档的相似度，可能比 query 和文档的相似度更高。

Query Rewrite 的权衡

优点	缺点
提高检索质量	增加 LLM 调用成本
处理复杂问题	增加延迟
适应用户表达习惯	可能改写错误

建议：

简单问题不需要改写
复杂问题、长尾问题适合改写
可以用规则+LLM结合，降低成本

七、一个推荐的升级路线

如果你现在还是单路向量检索，建议按这个顺序升级：

第一步：优化 Chunking（成本低，效果好）

从固定长度改为按段落/标题切分
给每个 chunk 补充父级标题上下文

预期效果：Recall@5 从 60% 提升到 75%

第二步：引入 BM25（成本中）

部署 BM25 检索
实现 RRF 融合

预期效果：Recall@5 从 75% 提升到 82%

第三步：接入 Rerank（成本中）

部署 Cross-Encoder 模型
调整召回数量和精排数量

预期效果：Recall@5 从 82% 提升到 88%

第四步：高级优化（成本高）

Query Rewrite
Query Decomposition
HyDE

预期效果：Recall@5 从 88% 提升到 92%+

收益递减规律

从 60% 到 80%：相对容易，基础优化即可从 80% 到 90%：需要系统优化，混合检索+Rerank 从 90% 到 95%：难度大增，需要高级策略和大量调试

建议：先做到 85%，再考虑是否值得继续投入。

八、本文小结

RAG 做得好不好，很多时候不是模型不够强，而是：

Chunk 没切好 — 语义不完整、缺上下文
候选召回太单一 — 只用向量，对精确匹配不稳定
Rerank 没真正落地 — 用"假 rerank"或根本没 rerank

核心要点：

Chunking：按语义结构切分 + 补充上下文
混合检索：向量（语义）+ BM25（精确）+ RRF 融合
Rerank：Cross-Encoder 做真正的精排
Query Rewrite：处理复杂和长尾问题

下一篇会讲：如何做 RAG 的评测和 Inspect，才能知道问题到底出在哪一层。

RAG入门：从问题定义到系统设计

Wed, 25 Mar 2026 15:40:00 +0800

RAG，全称 Retrieval-Augmented Generation，核心思想其实很朴素：不要把所有知识都塞进模型参数里，而是在回答问题前，先从外部知识库里把最相关的信息找出来，再交给模型生成答案。

这套方法之所以重要，是因为纯大模型回答经常会遇到三类问题：

知识过期 — GPT-4 的训练数据截止到 2023 年底，你问它 2024 年 3 月的新闻，它要么说不知道，要么编一个。
专有知识缺失 — 你们公司的内部文档、API 规范、业务规则，模型从来没见过。
幻觉问题 — 模型会"自信地胡说八道"，尤其是当它不确定的时候。

RAG 的目标不是让模型"更聪明"，而是让系统"更可控"。你把知识更新、答案依据、召回范围、调试手段都从模型参数里解耦了出来。

一、RAG 解决的本质问题

先想清楚一个问题：为什么不让模型直接回答，而要先检索？

答案是：模型的参数空间是有限的，但知识是无限的。

GPT-4 有 1.8 万亿参数，看起来很多，但这些参数要编码：语言规律、世界知识、推理能力、常识……真正留给"事实知识"的空间并不多。而且参数一旦训练完成，就固定了。你想让它知道你们公司最新的报销流程？只能重新训练，成本几十万起步。

RAG 的思路是：把"事实知识"从参数里剥离出来，放到外部存储里。

传统模型：
知识 → 训练 → 参数 → 推理 → 答案
（知识固化在参数里，更新成本高）

RAG：
知识 → 索引 → 向量库 → 检索 → 推理 → 答案
（知识和模型解耦，更新成本低）

代价是：每次回答前，需要先检索。检索的质量直接决定了答案的质量。

二、Embedding：把文本变成向量

RAG 的第一步是让机器"理解"文本。方法是 Embedding——把文本映射到一个高维向量空间。

Embedding 的直觉

假设我们有一个 3 维空间，每个词可以表示为一个点：

"猫" → (0.2, 0.8, 0.1)
"狗" → (0.3, 0.7, 0.2) ← 和"猫"很近，都是宠物
"汽车" → (0.9, 0.1, 0.3) ← 和"猫"很远，不同类别

在这个空间里，语义相似的词距离近，语义不同的词距离远。

实际的 Embedding 维度是几百到几千维，但原理一样：让语义相似的文本在向量空间里距离近。

训练 Embedding 模型

Embedding 模型是怎么训练出来的？核心思想是：让相似文本的向量靠近，不相似文本的向量远离。

常用的训练方式有两种：

1. 对比学习（Contrastive Learning）

准备大量"相似对"和"不相似对"：

相似对：
("如何重置密码", "密码重置方法")
("API 超时设置", "配置 API 超时时间")

不相似对：
("如何重置密码", "API 超时设置")
("密码重置方法", "今天天气怎么样")

训练目标：让相似对的向量距离小，不相似对的向量距离大。

损失函数（InfoNCE Loss）：

L = -log( exp(sim(q, p+)/τ) / Σexp(sim(q, pi)/τ) )

其中：
- q 是 query 的向量
- p+ 是正样本的向量
- pi 是所有样本（包括正样本和负样本）
- sim 是相似度函数（如余弦相似度）
- τ 是温度参数

直觉解释：让正样本的相似度占主导，负样本的相似度被压制。

2. 自监督学习

不用人工标注，利用文本本身的结构：

同一个句子/段落的不同部分互为正样本
不同句子/段落互为负样本

代表性方法：SimCSE，把同一个句子丢进模型两次（不同的 dropout mask），得到的两个向量应该相似。

主流 Embedding 模型

模型	维度	特点	适用场景
text-embedding-3-small	1536	OpenAI，多语言	通用场景
text-embedding-3-large	3072	OpenAI，更高精度	高质量要求
bge-large-zh	1024	开源，中文优化	中文场景
bge-m3	1024	开源，多语言	多语言混合
e5-large-v2	1024	开源，需要加前缀	英文场景

选择原则：

中文为主：选 bge-large-zh
多语言混合：选 text-embedding-3-small 或 bge-m3
追求高质量且有预算：选 text-embedding-3-large
私有化部署：选 bge 系列

三、向量检索：在高维空间找邻居

有了向量，接下来是检索：给定一个 query 向量，找到最相似的文档向量。

相似度计算

最常用的是余弦相似度：

cosine(a, b) = (a · b) / (||a|| × ||b||)

其中：
- a · b 是向量点积
- ||a|| 是向量的模长

结果范围：[-1, 1]，越大越相似

为什么用余弦相似度而不是欧氏距离？

因为 Embedding 的方向比长度更重要。两个文本的语义相似，体现在向量方向相近，而不是长度相近。余弦相似度只看方向，不看长度。

暴力检索的问题

最简单的检索方式是暴力计算：把 query 和所有文档向量都算一遍相似度，排序取 top-k。

问题：慢。

假设向量维度 1024，文档数量 100 万：

单次检索计算量：
100万 × 1024 = 10亿次浮点运算

耗时估算：
单核 CPU ≈ 100-500ms
GPU ≈ 10-50ms

100 万文档还算小，到了 1000 万、1 亿，暴力检索就撑不住了。

近似最近邻搜索（ANN）

解决方案：用精度换速度。不要求找到"最近的"，只要找到"足够近的"。

主流算法：

1. HNSW（Hierarchical Navigable Small World）

思路：构建一个多层的图结构，每层是一个小世界网络。

第 0 层：所有节点
第 1 层：部分节点（概率选取）
第 2 层：更少的节点
...

搜索时：
从最高层开始，快速跳到目标区域附近
逐层下降，越来越精确
最后在第 0 层找到最近邻

类比：找北京的某个人。先在世界地图上定位到中国，再在中国地图上定位到北京，再在北京地图上定位到朝阳区……每一步都在缩小范围。

2. IVF（Inverted File Index）

思路：把向量空间划分为多个区域（聚类中心），每个区域维护一个倒排表。

离线阶段：
1. 用 K-means 聚类，找到 K 个中心点
2. 把每个向量分配到最近的中心点
3. 每个中心点维护一个列表（倒排表）

在线检索：
1. 找到离 query 最近的几个中心点
2. 只在这几个中心点的倒排表里搜索
3. 不用遍历所有向量

参数选择：nprobe（探测几个中心点）。nprobe 越大，精度越高，速度越慢。

3. PQ（Product Quantization）

思路：压缩向量，减少内存占用和计算量。

原始向量：1024 维浮点数 = 4096 字节

压缩方法：
1. 把 1024 维分成 8 组，每组 128 维
2. 每组用 K-means 聚类，生成 256 个中心点
3. 每个向量每组只需 1 字节（存储中心点编号）

压缩后：8 字节
压缩比：512 倍

代价：精度损失。但换来的是内存占用大幅降低，可以索引更多文档。

向量库的选择

向量库	算法	特点	适用场景
Chroma	HNSW	轻量，易上手	开发/小规模
Qdrant	HNSW	开源，功能全	中等规模生产
Milvus	多种	分布式，高性能	大规模生产
Pinecone	专有	全托管，免运维	不想运维
Weaviate	HNSW	原生支持多模态	多模态场景

四、为什么单靠向量检索不够

向量检索很强大，但有天生的局限。

局限 1：对精确匹配不敏感

例子：

文档："错误码 401 表示认证失败"
用户问："401 是什么意思"

向量检索可能召回：
"常见错误码及解决方案"（语义相似）
"权限问题排查"（语义相似）

而不是精确包含 "401" 的那段。

原因：Embedding 模型学习的是语义相似性，不是字面匹配。“401” 这个数字在向量空间里没有特殊意义，它只是一个 token。

局限 2：对专业术语不稳定

例子：

文档："JSON Web Token 的有效期默认为 1 小时"
用户问："JWT 的有效期"

向量检索：可能召回，也可能不召回，取决于模型是否学过 JWT = JSON Web Token

如果模型训练数据里没见过这个缩写，就找不到关联。

局限 3：对编号/版本号不稳定

例子：

文档："v2.3.1 版本新增了批量导出功能"
用户问："v2.3.0 有什么新功能"

向量检索：可能召回 v2.3.1 或 v2.3.2 的内容，因为"版本更新"语义相似

版本号之间的微小差异，在向量空间里可能被"版本"这个大概念淹没。

解决方案：混合检索

这就是为什么生产环境几乎都用 Hybrid Retrieval：

候选集 = 向量检索（语义） + 关键词检索（字面） + 元数据过滤（业务规则）

下一篇文章会详细讲混合检索和 Rerank 的算法。

五、RAG 的三阶段架构

理解了 Embedding 和检索，我们来看 RAG 的整体架构。一个成熟的 RAG 系统分为三个阶段：

┌─────────────────────────────────────────────────────────────────┐
│ 阶段 1：索引（Indexing） │
│ │
│ 文档 → 解析 → 切分 → Embedding → 写入向量库 │
│ │
│ 核心问题：怎么切分才能让每个 chunk 成为独立的证据？ │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 阶段 2：检索（Retrieval） │
│ │
│ Query → Embedding → 向量检索 → 关键词检索 → 融合 → Rerank │
│ │
│ 核心问题：怎么召回相关内容，同时减少噪声？ │
└────────────────────────┬────────────────────────────────────────┘
 ▼
┌─────────────────────────────────────────────────────────────────┐
│ 阶段 3：生成（Generation） │
│ │
│ Query + Chunks → Prompt 组装 → LLM → 答案 + 引用 │
│ │
│ 核心问题：怎么让模型严格依据证据回答，不自由发挥？ │
└─────────────────────────────────────────────────────────────────┘

每个阶段都有特定的优化空间，而且问题往往出现在你忽视的地方。

索引阶段的关键决策

1. 切分粒度

太大：噪声多，模型注意力分散太小：信息碎片化，上下文丢失

经验值：300-500 tokens（中文约 200-350 字）

但比长度更重要的是语义完整性。一个 chunk 应该能独立成为一个"证据"。

2. 上下文补充

一个常见的坑：

原始文档：
### 2.3 校准流程
将旋钮调至 3 档，等待指示灯变为绿色。

按段落切分后，chunk 变成：
"将旋钮调至 3 档，等待指示灯变为绿色。"

问题：用户问"ZK-200 怎么校准"，这个 chunk 不会召回，因为：
- 没有"ZK-200"（在文档标题里）
- 没有"校准"（在章节标题里）

解决方案：把父级标题拼到 chunk 前面。

补充上下文后：
"【ZK-200 操作手册 > 2.3 校准流程】
将旋钮调至 3 档，等待指示灯变为绿色。"

这个技巧叫 Contextual Chunking，成本低，效果好。

3. 元数据设计

每个 chunk 至少要存储：

{
 "id": "唯一标识",
 "content": "文本内容",
 "document_id": "所属文档",
 "source": "知识库来源",
 "title": "文档标题",
 "section": "章节路径",
 "chunk_index": "在文档中的位置",
 "created_at": "创建时间"
}

这些元数据在检索时可以做过滤（只搜特定来源）、在回答时可以做引用（答案来自哪个文档）。

检索阶段的关键决策

1. 召回数量

召回太少：容易漏掉正确答案召回太多：噪声多，成本高

经验值：

召回阶段：50-100 个候选
Rerank 后：保留 10-20 个
最终进 prompt：3-8 个

2. 检索策略

简单场景：纯向量检索够用复杂场景：向量 + BM25 混合高精度场景：混合 + Rerank

3. 过滤策略

利用元数据缩小检索范围：

用户问："销售合同模板在哪下载？"

不过滤：
搜索范围 = 所有文档（产品、研发、销售、HR...）
结果可能混入研发部门的合同管理规范

按 department="sales" 过滤：
搜索范围 = 销售部门文档
结果更精准

生成阶段的关键决策

1. Prompt 设计

核心原则：让模型"不得不"依据证据回答。

差的 Prompt：

参考资料：{chunks}
问题：{query}
请回答：

模型可能无视参考资料，自由发挥。

好的 Prompt：

你是一个文档助手。请根据以下参考资料回答问题。

要求：
1. 答案必须基于参考资料，不要编造
2. 如果参考资料中没有答案，请直接说"根据现有资料无法回答"
3. 回答时标注引用来源，格式：[来源: 文档名 > 章节]

参考资料：
{chunks}

问题：{query}

请回答：

2. 上下文预算

模型有上下文长度限制，不能无限塞内容。更重要的是：内容越多，模型注意力越分散。

经验值：检索内容不超过 4000 tokens（约 3000 字中文）

分配建议：

关键证据：2000-3000 tokens
Prompt 模板：200-300 tokens
用户问题和输出：预留 1000+ tokens

3. 引用机制

让模型标注答案的来源：

答案："API 的超时时间默认为 30 秒 [来源: API 规范 > 3.2 超时配置]"

好处：

用户可以验证答案
系统可以追溯错误
增加答案的可信度

六、RAG vs 微调：怎么选

很多人问：应该用 RAG 还是微调？

答案：不冲突，解决的问题不同。

问题类型	解决方案	原因
知识过时	RAG	更新知识库即可
专有知识缺失	RAG	模型没见过这些知识
输出格式不稳定	微调	让模型学会特定格式
输出风格不对	微调	让模型掌握特定风格
工具使用不规范	微调	让模型学会调用模式

RAG 擅长：解决"知道什么" 微调擅长：解决"怎么做"

实际项目中，往往是两者结合：

微调：
- 让模型学会输出 JSON 格式
- 让模型学会引用来源
- 让模型学会说"不知道"

RAG：
- 提供最新的业务知识
- 提供可追溯的证据
- 提供领域专业信息

七、第一版 RAG 应该怎么搭

如果你从零开始，我的建议是：

不要一上来就追求复杂架构。第一版的目标是"可解释"，不是"最优"。

模块	配置	原因
文档导入	手动，按需导入	先保证质量，再追求自动化
切分策略	按段落，500 字左右	简单可控，效果有保障
Embedding	text-embedding-3-small 或 bge-large-zh	成熟稳定，效果好
检索	纯向量检索，top_k=5	先跑通，再优化
Prompt	明确约束 + 引用要求	确保答案有依据
Inspect	保留每次检索的候选列表	方便定位问题

第一版容易犯的错误

错误 1：上来就全量导入

把公司所有文档都丢进去，结果检索噪声巨大，答案质量很差。

正确做法：先导入核心文档（100-200 篇），验证效果，再逐步扩展。

错误 2：忽视元数据

只存内容和向量，其他什么都不留。后面想做过滤、引用、增量更新，发现数据不够。

正确做法：一开始就设计好元数据结构，chunk 要保留来源、章节、时间等信息。

错误 3：不做评测

优化全靠"感觉"，没有客观标准。

正确做法：准备 20-50 个测试问题，固定评测，每次改动都要看指标变化。

错误 4：没有 Inspect 能力

答案错了，不知道是检索错还是生成错。

正确做法：保留每次请求的中间结果（候选列表、分数、prompt），方便排查。

八、如何判断系统准备好了

在上线前，问自己这些问题：

□ 能回答核心问题吗？
 └── 准备 20 个关键问题，正确率 > 70%

□ 能解释答案来源吗？
 └── 每个答案都有引用，用户能追溯

□ 答案错了能定位吗？
 └── 有 Inspect 页面，能看到检索结果

□ 知道下一步优化什么吗？
 └── 有评测指标，知道哪类问题表现差

□ 文档更新后能同步吗？
 └── 有增量更新机制，不是全量重建

如果这些问题都回答不了，说明系统还不成熟，需要继续打磨。

九、下一篇文章讲什么

这篇文章讲了 RAG 的基础：

Embedding 的原理和选择
向量检索的算法和局限
三阶段架构的关键决策

下一篇会深入讲：

Chunking 的策略：怎么切才能保留语义完整性
混合检索：BM25 算法原理、RRF 融合公式
Rerank：Cross-Encoder 的工作原理、为什么比向量检索更准

这些是 RAG 质量提升的关键，也是最容易踩坑的地方。