切分单位、预算与基线

本节目标

学完本节，你能够回答三个先后有别的问题：

1. 我在量什么长度？
2. 一个 chunk 为什么要有这个上限？
3. 我如何建立一个以后还能公平比较的基线？

先区分 element、chunk 与上下文

解析器输出的 element 是来源结构单元，例如一个段落、一行表格或一段代码。chunk 是为了索引和检索而组合或拆开的证据单元。模型最终收到的“上下文”又可能由多个 chunks、标题和系统提示组成。

因此：

• 一个 element 可以被超长兜底规则拆成多个 chunks；
• 多个短 elements 可以合并成一个 chunk；
• 一个命中的 child chunk 可以映射回更大的 parent context；
• chunk 不能代替来源记录，最终引用仍要回到 element/span。

这一区分是后续增量更新、删除、权限与评测稳定性的基础。

长度单位不是同一回事

单位	优点	风险	适合用途
Unicode 字符	无依赖、容易复现	与模型 token 数没有固定比例	最小教学基线、文本完整性检查
空格分词后的 word	英文直观	中文、代码、URL 与标点不稳定	特定英文语料的粗略统计
tokenizer token	最接近模型输入约束	与模型/编码版本绑定	生产 hard max 与成本预算
句子/段落	边界较自然	长度长尾明显，分句会出错	递归切分的候选边界
解析 element	保留标题、表格、代码语义	依赖解析质量	结构感知切分的首选输入

“500 字符大约等于多少 token”只能是特定语言、语料与 tokenizer 下的经验。不要把换算系数写成系统常量。OpenAI 的 tiktoken 是一个 tokenizer 工具，但实际项目仍须核对所用模型、编码与当前限制。

本库实验定义的 lexical unit 是正则识别出的英文词、单个汉字或非空白符号。它只用于离线演示，输出中会明确写出“not a model tokenizer”。

从总输入反推预算

生成模型的输入不是只放检索块。用同一个计量器估算：

$$B_{\text{retrieval}}=B_{\text{input}}-(B_{\text{system}}+B_{\text{history}}+B_{\text{query}}+B_{\text{tools}}+B_{\text{output reserve}}+B_{\text{safety}})$$

若计划最多送入 $k$ 个 chunks，每块还要加标题、分隔符和引用元数据，则一个初始正文预算可以写成：

$$B_{\text{chunk body}}\le \lfloor \frac{B_{\text{retrieval}}}{k}\rfloor -B_{\text{per-chunk overhead}}$$

这只是初始上界，还要同时满足：

• Embedding 模型的单输入限制；
• reranker 的输入与候选数量限制；
• 数据库字段或批处理限制；
• 文档中完整表格行、代码块等不可随意破坏的边界。

纯教学算例

假设总预算是 800 个“同一种计量单位”，其他部分和安全余量共 320，计划最多放 4 块，每块标题/引用开销约 20，则正文初始上界是 $(800-320)/4-20=100$。这些数字不是任何真实模型规格；真实值必须从当前官方文档和实测得到。

Soft max 与 hard max

• hard max：任何输出都不能超过。超长单 element 必须进入窗口兜底。
• soft max：相邻完整 elements 合并到这里就准备关闭 chunk，避免大量碎块。
• minimum useful size：不是强制填满，而是监控孤立标题、单标点或无上下文短块。

先保留完整元素，在不超过 hard max 的前提下合并小元素；不要为了凑整把表格行、函数签名或条件句硬切开。

最低输出契约

一个可维护 chunk 至少要回答“来自哪里、如何产生、谁能看、如何验证”：

{
  "chunk_id": "chk_<content-derived digest>",
  "source_id": "api-guide",
  "source_revision": "rev-3",
  "strategy_version": "structure-v1",
  "ordinal": 7,
  "text": "可引用原文",
  "retrieval_text": "标题路径 + 可检索文本",
  "element_spans": [
    {"element_id": "api-e3", "unit_start": 0, "unit_end": 25}
  ],
  "section_path": ["API 指南", "重试"],
  "acl": ["employees"],
  "content_sha256": "<digest>",
  "retrieval_sha256": "<digest>"
}

JSON 标准不允许行尾注释；为保持上面这段可直接解析，字段解释放在代码块外：chunk_id 是内容派生身份，source_id/source_revision 指向稳定来源版本，strategy_version/ordinal 解释产生顺序，text 保留可引用原文，retrieval_text 只服务检索，element_spans 保存原文定位，section_path/acl 分别记录结构和可见范围，两个 SHA-256 字段用于检测正文或检索文本是否漂移。

ordinal 用于展示顺序，不宜单独决定 ID；在文档开头插一段不应让后面全部 ID 漂移。一种可审计做法是把 source/revision、策略版本、element spans、内容哈希和权限纳入规范化哈希。具体身份规则是架构选择，但必须有测试并记录迁移影响。

建立最小基线

第一版不需要“智能”。固定窗口基线的价值是确定、便宜、容易找错。固定以下变量：

• 同一份解析元素和来源版本；
• 同一个计量器；
• 同一 query/gold 集；
• 同一检索器、候选数和过滤条件；
• 同一评测代码；
• 只改变一个 chunking 因素。

最低观测项：

正确性	检索质量	成本
来源单位全覆盖、顺序、hard max、边界隔离	anchor Recall@k、MRR、完整证据率、无答案准确率	chunk 数、重复单位、检索上下文单位、索引重建量

总体均值之外，还要按事实问答、跨段条件、表格、代码和无答案分类。一个策略可能均值相同，却只在某类查询上失败。

常见错误与排查

• 直接使用模型最大窗口作为 chunk 大小：忘了系统提示、工具 schema、历史和输出余量。
• 计量器不一致：切分用字符，监控却用另一模型 token，hard max 形同虚设。
• 只看平均长度：一个超长尾部仍会触发截断或请求失败。
• 同时换 chunking 与 embedding：无法判断变化来自哪一项。
• Gold 写死 chunk ID：策略重建后评测集整体失效。
• 来源文本和检索前缀混在一起：引用时可能把派生标题误称为原文。

练习

1. 为“短 FAQ、长政策、代码库、跨页表格”分别写下首选 element 边界和绝不能跨越的边界。
2. 假设总预算 2,000、保留部分 800、k=5、每块开销 40，算初始正文上界；再说明为什么它仍不是最终最优尺寸。
3. 为上述 JSON schema 增加页码或行号，但不要让一个 chunk 同时出现两种含义不同的 start/end。
4. 写一个失败实验：同时改变 tokenizer 和 overlap，解释为什么结果无法归因。

掌握检查

• 我能说出 element、chunk 与最终上下文的区别。
• 我会用当前模型 tokenizer 计量，而不是引用固定换算。
• 我能从总输入预算推导 chunk 初始上界并保留安全余量。
• 我区分 soft max 与 hard max。
• 每个 chunk 有来源、版本、位置、ACL、策略和哈希。
• 我的基线一次只改变一个因素。

小结与下一步

先把单位、预算、身份和可比条件写清，才有资格讨论“哪种策略更好”。下一步实现确定性切分，并用性质测试锁定正确性：[[Knowledge/AI Agent Engineer/docs-CN/Chunking策略/02-固定窗口与递归切分|固定窗口与递归切分]]。

参考资料

• OpenAI tiktoken
• Azure AI Search: Chunk documents
• Unstructured: Chunking

来源获取日期：2026-07-14。返回 [[Knowledge/AI Agent Engineer/docs-CN/Chunking策略/00-目录|Chunking 策略目录]]。