Wiki Notes

Appearance

长文本切片策略专题 ​

版本：v1.1

最后更新：2026-07-06

适用对象：负责企业知识库、RAG、文档解析、向量索引、引用溯源和检索评测的算法、平台、后端与知识运营团队。

1. 为什么长文本切片很重要 ​

很多知识型 AI 系统在早期接入文档时，会先用固定 chunk size 直接切片。刚开始这通常能跑起来，但做久了会发现：

  • 切太大，检索命中后噪声多，模型难以抓重点
  • 切太小，关键上下文断裂，答案缺证据
  • 标题、段落、表格、流程步骤被切坏
  • 引用看起来不可信，因为 chunk 本身不完整
  • 同一问题召回多个碎片，模型需要自己拼上下文
  • 切片策略一改，历史评测指标无法对比

长文本切片是 RAG 的地基。它决定了：

  • 检索的最小知识单元
  • embedding 表示的语义范围
  • rerank 能否判断相关性
  • 模型最终看到的证据质量
  • 引用能否被用户验证

RAG 论文的核心思想是把外部知识检索结果作为生成依据；而在工程上，“检索结果”的基本单位通常就是 chunk。chunk 设计不好，后面的 embedding、rerank、prompt 和引用展示都会被拖累。

2. 什么是切片策略 ​

切片策略可以理解为：

  • 决定如何把长文档拆成适合索引、检索、重排、引用和模型阅读的知识单元

它不是简单的字符串截断，而是一个文档结构理解问题。

一套完整切片策略至少要回答：

  1. 按什么边界切：标题、段落、句子、页码、语义、token
  2. 每个 chunk 多大：字符数、token 数、段落数
  3. 是否需要 overlap：相邻 chunk 共享多少上下文
  4. 是否保留标题路径：章节层级是否进入 metadata
  5. 表格、代码、FAQ、流程如何特殊处理
  6. chunk 能否独立支撑一个引用
  7. 切片变更如何评测和回滚

3. 切片会直接影响 RAG 的哪些环节 ​

3.1 影响召回 ​

如果 chunk 太大，embedding 会混合多个主题，向量表示变得模糊。

如果 chunk 太小，用户问题需要的信息可能散落在多个 chunk 中，单个 chunk 相关性不足。

3.2 影响重排 ​

reranker 通常判断 query 与 chunk 的相关性。chunk 内容越完整，重排越容易判断。

如果 chunk 只有半句话或缺标题，reranker 很难判断它是否真正相关。

3.3 影响引用 ​

引用展示的基本单位通常是 chunk 或 chunk 对应原文片段。

如果 chunk 被切坏：

  • 引用只显示半个表格
  • 引用缺少条款标题
  • 引用没有前提条件
  • 用户无法验证答案来源

3.4 影响上下文成本 ​

切片太碎会召回很多小片段，prompt 里要塞更多上下文。

切片太大则每个 chunk 占用 token 多，噪声也多。

3.5 影响幻觉风险 ​

如果 chunk 缺少关键限定条件，模型可能会根据不完整证据做过度推断。

例如制度文档里：

text
员工可申请报销差旅费用。
但以下情况不予报销：私人行程、超标准住宿、无发票支出。

如果两句话被切开，模型可能只召回第一句，导致错误回答。

4. 切片的核心矛盾 ​

4.1 完整性 vs 精准性 ​

chunk 越大，上下文越完整，但噪声越多。

chunk 越小，检索越精准，但容易缺前提和结论。

4.2 召回率 vs 引用可读性 ​

为了提高召回，有时会切得更细。

但用户看引用时，更希望看到完整段落、完整条款或完整表格。

4.3 通用策略 vs 文档类型差异 ​

固定 chunk size 最简单，但不同文档结构差异很大：

  • FAQ 适合按问答对切
  • 制度文档适合按条款和标题层级切
  • 表格适合按表头和行组切
  • 代码文档适合按函数、类、示例块切
  • 流程文档适合按完整步骤组切

没有一种切法适合所有文档。

5. 常见切片方法 ​

5.1 固定长度切片 ​

按字符数或 token 数切。

优点：

  • 实现简单
  • 容易控制 chunk 大小
  • 适合快速原型

缺点：

  • 容易切断句子和段落
  • 不理解文档结构
  • 表格和流程容易被破坏

适合：

  • 结构弱、内容连续的普通文本
  • 原型阶段

不适合：

  • 制度文档
  • 合同
  • 表格
  • FAQ
  • 技术文档

5.2 递归字符切片 ​

LangChain 的 RecursiveCharacterTextSplitter 思路是按一组分隔符递归切分，优先保留段落、换行、句子等自然边界，直到满足 chunk size。

常见分隔符顺序：

text
章节标题 -> 段落 -> 换行 -> 句子 -> 空格 -> 字符

优点：

  • 比固定长度更尊重文本结构
  • 实现成本低
  • 适合作为默认策略

缺点：

  • 仍然不真正理解业务语义
  • 对表格、PDF 版面、FAQ 不够精细

5.3 结构化切片 ​

按文档结构切。

例如：

  • Markdown 标题层级
  • PDF 页码和标题
  • Word 样式标题
  • HTML heading
  • 表格
  • 列表
  • 代码块

优点：

  • 保留文档原始结构
  • 引用更可读
  • 便于追溯到原文位置

缺点：

  • 需要文档解析能力
  • 不同文件格式要适配
  • 结构解析错误会影响切片

5.4 语义切片 ​

按主题或语义边界切。

思路：

  • 判断相邻句子或段落是否属于同一主题
  • 主题变化时切开
  • 每个 chunk 尽量保持语义完整

优点：

  • 更符合用户提问方式
  • 能减少主题混杂

缺点：

  • 成本更高
  • 结果不一定稳定
  • 需要额外模型或 embedding 判断

5.5 层级切片 ​

同时保留大块和小块。

例如：

text
章节级 chunk：用于粗召回
段落级 chunk：用于精确引用
句子级 chunk：用于 evidence 对齐

优点：

  • 兼顾召回和引用
  • 适合复杂知识库

缺点：

  • 索引和去重更复杂
  • 需要 parent-child 关系管理

6. chunk size 与 overlap 怎么选 ​

6.1 chunk size 不是越大越好 ​

大 chunk 的问题：

  • embedding 主题混杂
  • rerank 难判断
  • prompt 成本高
  • 引用噪声多

6.2 chunk size 也不是越小越好 ​

小 chunk 的问题：

  • 前后文断裂
  • 条件和结论分离
  • 召回结果碎片化
  • 需要拼接更多 chunk

6.3 overlap 的作用 ​

overlap 用来缓解边界断裂。

例如 chunk A 结尾有条件，chunk B 开头有结论，overlap 可以让两个 chunk 都保留部分上下文。

但 overlap 过大也有问题：

  • 索引变大
  • 重复召回增加
  • 成本上升
  • 引用重复

6.4 起步建议 ​

不同系统差异很大，但可以这样起步：

文档类型chunk 建议overlap 建议
普通说明文300-800 tokens50-150 tokens
FAQ一问一答为一个 chunk通常不需要
制度条款按条款或小节保留标题路径
技术文档按标题、段落、代码块适度 overlap
表格按表头 + 行组保留表头
长报告章节粗切 + 段落细切分层处理

这些不是固定标准，而是调参起点。最终要通过回放评测决定。

7. 不同文档类型的切片策略 ​

7.1 FAQ ​

推荐：

  • 一组问答作为一个 chunk
  • 保留问题、答案、适用场景
  • 相似问法作为 metadata 或别名

不要：

  • 把问题和答案切开
  • 把多个无关 FAQ 合并成一个 chunk

7.2 制度与政策文档 ​

推荐：

  • 按标题层级和条款切
  • chunk 中保留标题路径
  • 条件、例外、限制要和结论放在一起

metadata 示例：

json
{
  "doc_title": "差旅报销制度",
  "section_path": "报销范围 > 不予报销情形",
  "article_no": "3.2",
  "page": 4
}

7.3 表格 ​

表格最容易被切坏。

推荐：

  • 保留表头
  • 按语义行组切
  • 每个 chunk 带表格标题
  • 对跨页表格保留续表关系
  • 重要数值字段保留原格式

不要：

  • 只把表格转成无结构文本
  • 把表头和数据行切开
  • 把金额、单位、日期拆散

7.4 流程文档 ​

推荐：

  • 按完整流程阶段切
  • 保留步骤顺序
  • 条件分支不要和结果分离
  • 必要时单独构造流程图或结构化字段

7.5 合同和法律文档 ​

推荐：

  • 按条款切
  • 保留条款编号
  • 保留定义条款和引用关系
  • 对“除外”“但书”“前提条件”特别处理

合同切片最怕只召回结论，不召回限制条件。

7.6 技术文档和代码文档 ​

推荐：

  • 按标题和代码块切
  • 代码示例不要被截断
  • API 参数表要保留字段、类型、说明
  • 错误码表要保留错误码和解释

8. chunk metadata 设计 ​

好的切片一定要有 metadata。

8.1 基础 metadata ​

建议包含：

  • doc_id
  • doc_title
  • source_url
  • file_path
  • page
  • section_path
  • chunk_id
  • chunk_index
  • char_start
  • char_end
  • token_count
  • created_at
  • document_version

8.2 检索 metadata ​

可选：

  • doc_type
  • business_domain
  • risk_level
  • permission_scope
  • language
  • effective_date
  • expire_date
  • owner

这些字段可以支持权限过滤、时间过滤和业务域过滤。

8.3 引用 metadata ​

引用需要：

  • 页码
  • 标题路径
  • 原文位置
  • 表格编号
  • 条款编号
  • URL anchor

没有 metadata，后续很难做可验证引用。

9. 切片与引用设计联动 ​

很多引用不可信，不是 UI 问题，而是 chunk 本身无法独立支撑结论。

9.1 好 chunk 的标准 ​

一个可引用 chunk 应该：

  • 有明确主题
  • 保留必要标题
  • 条件和结论完整
  • 能追溯到原文位置
  • 不混入太多无关内容
  • 能被用户独立阅读

9.2 引用最小单位 ​

不同场景的引用单位不同：

场景推荐引用单位
FAQ完整问答对
制度条款或小节
表格表头 + 相关行
合同条款编号 + 条款内容
报告段落 + 页码
技术文档参数表或代码块

10. 切片策略评测 ​

切片策略必须通过回放评测，而不是只靠感觉。

10.1 评测样本 ​

准备：

  • 高频真实问题
  • 历史检索失败问题
  • 高风险问答
  • 需要表格证据的问题
  • 需要多段证据的问题
  • 证据不足应拒答的问题

10.2 指标 ​

建议看：

  • Recall@K：正确证据是否进入前 K
  • MRR：正确证据排名是否靠前
  • nDCG：排序质量
  • 引用准确率
  • 答案忠实性
  • 证据完整率
  • 平均 chunk token
  • 检索成本
  • 重复召回率

10.3 切片回放流程 ​

text
固定问题集
 -> 方案 A 切片并索引
 -> 方案 B 切片并索引
 -> 跑同一批检索
 -> 对比召回、排序、引用和答案质量
 -> 分析失败样例

切片方案变更必须能解释指标变化。

11. 常见失败与修复 ​

失败现象可能原因修复
检索结果主题混杂chunk 太大减小 chunk 或按结构切
召回片段缺前提chunk 太小或 overlap 不足增加 overlap 或按条款切
表格问答错误表头和数据行分离表格专用切片
引用不可读chunk 缺标题和位置增加 section_path 和页码
同一内容重复召回overlap 过大或重复文档去重、调小 overlap
长报告只召回局部缺层级索引章节级 + 段落级双索引
权限过滤失效metadata 缺权限字段增加 permission_scope

12. 切片策略变更治理 ​

切片策略属于知识库基础设施变更，不能随手改。

每次变更要记录：

  • 策略版本
  • chunk size
  • overlap
  • 分隔符
  • 文档类型规则
  • 影响文档范围
  • 重建索引时间
  • 回放评测结果
  • 是否需要回滚

12.1 版本示例 ​

json
{
  "chunking_policy_version": "chunk_policy_v2.1",
  "doc_type": "policy",
  "chunk_size_tokens": 600,
  "chunk_overlap_tokens": 100,
  "split_rules": ["heading", "paragraph", "sentence"],
  "metadata_required": ["doc_id", "section_path", "page", "permission_scope"]
}

12.2 什么时候需要重建索引 ​

需要重建：

  • chunk size 变化
  • overlap 变化
  • 结构解析规则变化
  • metadata 字段变化
  • 文档解析器升级
  • 权限字段变化

重建后必须跑回放评测。

13. 推荐落地流程 ​

text
文档解析
 -> 识别文档类型
 -> 应用对应切片策略
 -> 生成 chunk + metadata
 -> 建立向量索引和关键词索引
 -> 检索回放评测
 -> 分析失败样例
 -> 调整策略并版本化

13.1 最小可用版本 ​

如果团队刚开始，可以先做：

  • Markdown/HTML 按标题切
  • 普通文本用递归切分
  • FAQ 一问一答切
  • 表格保留表头
  • 所有 chunk 保留 doc_id、title、section_path、page

13.2 生产增强版本 ​

更成熟后补充：

  • 文档类型识别
  • 表格专用解析
  • 层级索引
  • 权限 metadata
  • 切片策略版本
  • 回放评测
  • 失败样例归因

14. 落地检查清单 ​

14.1 策略设计 ​

  • 是否区分不同文档类型
  • 是否保留标题层级
  • 是否保留页码或原文位置
  • 是否对表格、FAQ、流程、代码做专用策略
  • 是否设置合理 overlap

14.2 metadata ​

  • 是否有 doc_id
  • 是否有 chunk_id
  • 是否有 section_path
  • 是否有 page 或位置
  • 是否有 document_version
  • 是否有 permission_scope

14.3 评测与治理 ​

  • 是否有固定问题集
  • 是否能计算 Recall@K 和引用准确率
  • 是否能比较不同切片版本
  • 是否记录切片策略版本
  • 是否把检索失败样例回流
  • 是否能回滚到旧索引

15. 推荐搭配阅读 ​

16. 推荐资料 ​

以下资料在 2026-07-06 检查时可访问。

官方文档 ​

论文 ​

17. 一句话总结 ​

长文本切片策略的核心不是找到一个万能 chunk size，而是根据文档结构、业务场景、引用要求和检索评测结果，把长文档拆成既能被准确召回、又能独立支撑答案的知识单元。