什么是 分块大小（Chunk Size）？
分块大小（Chunk Size）是在检索增强生成系统中，为每个被索引文档单元选择的 token、字符或结构长度。
工作原理
分块大小决定每个检索单元包含多少源内容。小单元能更精确地定位证据，却可能拆散限定条件、标题或关系；大单元能保留上下文，却可能稀释排序信号并消耗更多生成预算。任何 Token 数都不是通用默认值。生产系统应根据权威证据 Span 长度、源结构、Tokenizer 限制与查询切片构造候选网格，再在相同唯一检索 Token 预算下比较。最终大小是一项绑定语料、Tokenizer、Embedding 模型与评测集的版本化策略。
主要特点
- 坐标可追溯：Token 长度必须映射回权威源 Offset，以支持引用与删除
- 依赖 Tokenizer：相同文本在不同 Tokenizer 版本下可能具有不同长度
- 绑定预算：分块大小决定检索和生成预算内能容纳多少唯一证据 Token
- 依赖查询：局部事实、比较、流程与主题问题可能偏好不同粒度
- 实验选择：只有通过检索、引用、答案、延迟与成本评测后才能接受策略
常见用途
- 根据证据标注 Span 的长度分布构造候选大小网格
- 测试法律条款是否需要 Parent 扩展才能包含被引用定义
- 让代码 Symbol 与解释注释保留可回溯到权威源的 Offset
- 在相同唯一检索 Token 预算下比较大小不同的单元
- 以检索、引用、答案、延迟和成本回归门禁发布新大小策略
示例
loading...
Loading code...常见问题
RAG 中分块大小多少比较合适？
不存在可迁移的默认值。应根据源结构、证据标注 Span 长度、Tokenizer 限制和查询切片生成候选值；保留简单的固定 Token 基线，再通过等预算检索与端到端评测选择策略。
分块越小越好吗？
不是。较小分块能检索到更精确片段，但也可能遗漏定义、前提、表格或前文上下文，导致回答不完整。
为什么建议按 token 衡量分块大小？
Embedding 与生成 API 都受 Token 预算约束，因此按 Token 计量有助于控制载荷与成本。但必须记录 Tokenizer 及版本，并保留权威字符或字节 Offset，因为 Token 坐标会随 Tokenizer 变化。
所有文档都应该使用同一个分块大小吗？
不能凭假设统一或拆分策略。代码库、政策手册和 FAQ 的源结构与证据需求不同；只有按查询切片的评测证明收益时才采用不同规则，并版本化策略以保证每个索引 Chunk 可复现。