什么是 文档分块（Chunking）？
文档分块（Chunking）是把长文档或数据源切分为较小可检索单元的过程，这些单元需要保留足够语义上下文，以支持向量嵌入、索引、检索和有依据生成。
工作原理
文档分块是 RAG 中杠杆最高的设计选择之一，因为它定义了可以被索引、检索、引用、鉴权、更新和删除的单元。Chunk 可以是段落、标题章节、表格区域、代码符号或 Token 窗口，但应始终是权威源内容上可追溯的 View。结构感知切分遵循作者或 Parser 提供的边界，语义分块则根据 Embedding 或模型信号推断边界，两者都不是普遍最优。生产系统应保留来源 Offset 与血缘，版本化每次转换，并在相同检索预算下用证据标注查询比较候选方案。
主要特点
- 检索单元设计：定义检索器可以返回的最小索引单位
- 权威血缘：每个单元保留 Source URI、版本、Offset、内容 Hash 与访问范围
- 边界策略：可采用作者结构、固定 Token 窗口、语义变化信号或父子关系
- 分离检索与上下文单元：精确命中的 Child 可以扩展到单独鉴权的 Parent 或区域
- 版本化转换：Parser、Tokenizer、Splitter、Embedding 模型与派生上下文均可复现
- 依赖评估：比较证据召回、排名、重复率、引用、延迟与更新成本
常见用途
- 把产品文档按标题结构拆分，用于 RAG 检索
- 为政策问答创建段落级分块
- 在开发者文档中保留代码块及其周围解释
- 把表格或表单拆成带元数据的可检索记录
- 在相同唯一 Token 预算下比较固定 Token、结构感知、语义与父子分块
示例
loading...
Loading code...常见问题
为什么文档分块对 RAG 很重要？
分块定义了检索器可以返回什么。如果分块形状不好，系统可能检索到不完整证据、混合无关主题、丢失引用边界，或浪费上下文窗口预算。
固定大小分块够用吗？
它是必要基线，但既不是普遍赢家，也不是普遍输家。当标题、表格、列表、代码符号或政策章节提供有效边界时，结构感知切分可作为另一候选；Parser 质量与查询分布也可能反转结果。应在相同唯一检索 Token 预算下比较两者。
应该如何评估分块？
先标注权威证据 Span，再在相同唯一检索 Token 预算下比较候选方案。分别衡量证据召回、排名质量、重复上下文比率、引用正确性、答案忠实度、延迟、索引体积、更新成本、越权泄露与删除传播。
分块会泄露受限数据吗？
会。不得跨访问边界合并内容，也不能把 Metadata 当成强制鉴权。检索 Chunk 或从 Child 扩展到 Parent 时，应重新校验源对象权限，并把撤权与删除传播到 Chunk、摘要、Embedding 和缓存。