m204. RAG 生产环境：Chunking 策略与范式演进

Chunking（分块）直接决定 RAG 检索的召回率和精度，是 RAG 系统最容易被忽视、影响最大的设计决策。本章同时覆盖 2024–2025 年 RAG 范式从 Naive 到 Agentic 的演进路径。

2.3.3 Chunking 策略深度拆解

主流策略对比

策略	机制	优势	劣势	适用场景
固定长度	每 N tokens 切分，重叠 M tokens	简单、可预测	忽视语义边界，可能截断完整概念	快速原型
递归字符	按层级分隔符（段落→句子→词）优先切分	比固定长度更尊重结构	仍是字符规则，无语义感知	通用场景
语义切分	计算相邻句子 Embedding 相似度，骤降处切分	语义对齐最好	计算成本高、需调优阈值	对检索质量要求高
文档结构感知	利用标题/章节/列表作为切分边界	对结构化文档效果最好	依赖文档规范性	技术文档、法律合同
Late Chunking	先对完整文档做 Embedding，再切分 chunk，每个 chunk 的 Embedding 包含全局上下文	保留跨 chunk 语义关联	需要长上下文 Embedding 模型	长文档、上下文依赖强

实操参数指引

chunk 大小取决于 context 窗口和 Top-K 设置：Top-K=5 且 context=8K → 每 chunk 不超过 ~1000 tokens
重叠率通常 10%–20%（防止边界信息丢失）
为每个 chunk 附加元数据（来源、章节、页码、时间），用于检索时的精确过滤
不同内容类型用不同策略：技术文档按章节切、FAQ 按问答对切、对话按轮次切

Anthropic Contextual Retrieval（2024）：重要范式更新

传统 RAG 中，chunk 一旦从原文切出，就丧失上下文。例如一个 chunk 写着”该公司 Q3 营收增长 15%“，但不知道”该公司”是谁。

Contextual Retrieval 的做法：在 chunk 存入索引之前，用 LLM 为每个 chunk 生成一段上下文前缀（如”这段文字来自 Acme Corp 的 2024 年年报，第三章财务概述”），然后将前缀 + 原始 chunk一起做 Embedding 和存储。

效果：Anthropic 实验显示，这一改动将 RAG 检索失败率降低了 49%（配合 BM25 混合检索后降低 67%）。

对 PM 的启示：Chunking 不只是”怎么切”的问题，“切完后怎么补充上下文”同样重要——而这是一个产品设计决策，不是纯工程参数。

2.3.4 RAG 范式演进：从 Naive 到 Agentic

2024–2025 年，RAG 架构经历快速演进。选择哪种范式，取决于业务复杂度和对延迟/成本的容忍度。

Naive RAG（基础版）

Query → 检索 Top-K → 注入 Prompt → 生成回答

问题：不判断检索结果是否相关，可能将无关内容注入 prompt，导致幻觉。

适用：知识库覆盖完整、用户 query 清晰、对延迟要求严格的场景。覆盖 80% 的简单问答场景。

Self-RAG（自反思 RAG）

模型在生成过程中自行判断：

是否需要检索？
检索结果是否相关？
生成的回答是否被检索结果支持（Faithfulness，见 m205 §RAGAS）？

通过在输出中插入特殊”反思 token”实现自我评估。

产品价值：

不需要检索的问题 → 跳过检索（降低延迟和成本）
检索结果不佳时 → 不强行使用（降低幻觉）

Corrective RAG（CRAG）

在生成前增加”质量评估”步骤：用轻量级评估器对检索结果打分。如果所有检索结果都低于质量阈值，触发备用检索策略（切换到 Web 搜索、换不同检索引擎、改写 query 重新检索）。

产品价值：解决”知识库中确实没有相关信息时怎么办”——不是硬着头皮用不相关的结果，而是主动寻找替代来源，避免幻觉。

Adaptive RAG

用路由器对用户 query 做复杂度分类：

Query 类型	处理流程
简单事实查询	直接检索 + 生成
需要多步推理的复杂查询	先分解为子查询，分别检索，再综合
不需要外部知识的问题	跳过检索，直接用模型预训练知识

产品价值：成本、延迟、质量三者取得最优平衡。

Agentic RAG（2025 年主流趋势）

将 RAG 的检索-生成过程交给 Agent 驱动（c10 Agent 技术栈）。Agent 可以：

自主决定搜索哪些数据源（向量库 vs 关系数据库 vs Web vs API）
动态改写 query（第一次检索不理想时，自动换角度重试）
在循环中多次检索和推理，直到收集到足够信息
对检索结果做交叉验证（对比多个来源的信息一致性）

多 Agent RAG 典型模式：

Meta-Agent（协调者）
├── Document Agent A（产品文档库）
├── Document Agent B（客户案例库）
├── SQL Agent（结构化数据查询）
└── Web Agent（实时信息搜索）
    ↓
Meta-Agent 汇总 → 综合生成最终回答

PM 的选型建议

不是越高级越好：

场景特征	推荐范式
简单问答，知识库覆盖完整	Naive RAG
知识库覆盖率不完整	Corrective RAG
用户 query 复杂度差异大	Adaptive RAG
需要跨多数据源综合	Agentic RAG

原则：从 Naive RAG 起步，用评估数据（见 m205 评估体系）诊断瓶颈，再有针对性地升级。Agentic RAG 延迟高、成本高、调试难度指数级上升，不应该是默认选择。

相关概念卡：RAG、Embedding、Tokenization、幻觉与校准、Agent、预训练上一章：m203 Embedding 与文档解析下一章：m205 索引运维与评估体系

m204 - RAG 生产环境：Chunking 与范式演进