上传文档之前要定两个数：一段内容切多长，以及为每段建多长的索引。这两个数在界面上都能填，但填进去的值不一定就是最终生效的值 —— 处理方式与设置方式会改写其中一部分。下面这个模块把改写关系摊开：选好处理方式与设置方式，每一项的实际取值、被改写的项、预计的分块数与索引条数都会跟着变。
这几个设置什么时候必须认真定
文档量小、内容形态单一的时候，分块与索引用默认值就够了，不值得花时间调。需要认真定的是下面几种情况。
第一种是单个文件很长而内容密度不均，比如一份几百页的手册里既有目录也有参数表。按固定长度切会把参数表切断，检索时召回半张表，模型看不出完整的字段含义。
第二种是文档带明确结构，比如按章节组织的规范文件或标准。这类文档按段落切能保住结构，按长度切会跨越章节边界，召回时容易把两个不相关章节的内容拼在一起。
第三种是准备走问答拆分。问答拆分会调用大模型把原文改写成问答对，它的分块长度上限和索引长度都与直接分段不同，而且索引长度这一项在这种处理方式下会被改写，界面上填的值不会生效。
第四种是批量导入之前想先估一下要建多少条索引。索引条数直接决定向量库的存储量与建索引的耗时，量级如果差一个数量级，导入过程中的资源占用会完全不同。
交互模块：分块与索引设置估算
选择处理方式与设置方式，填入文件数与平均字数，模块会算出每一项实际生效的取值、哪些项被改写，以及预计的分块数与索引条数。
按字数估算
| 参数 | 参数名 | 生效值 | 状态 |
|---|---|---|---|
| 分段方式 | chunkSplitMode | 按段落 | 被改写 |
| 段落 AI 识别 | paragraphChunkAIMode | 禁用 | 被改写 |
| 段落深度 | paragraphChunkDeep | 5 | 被改写 |
| 段落最小长度 | paragraphChunkMinSize | 100 | 被改写 |
| 分块长度 | chunkSize | 1000 | 被改写 |
| 索引长度 | indexSize | 512 | 被改写 |
| 自定义分隔符 | chunkSplitter | 未提供 | 被改写 |
| 分块长度下限 | minChunkSize | 64 | 固定值 |
两种设置方式下各参数的实际取值
这张表是上面模块的完整取值依据，也可以直接对照使用。「自动」一列里写「强制」的项，表示界面上的所设值不会生效。
| 参数 | 设置方式为「自动」时 | 设置方式为「自定义」时 |
|---|---|---|
| 分段方式 chunkSplitMode | 强制为「按段落」 | 按所选值 |
| 段落 AI 识别 paragraphChunkAIMode | 强制为「禁用」 | 按所选值 |
| 段落深度 paragraphChunkDeep | 强制为 5 | 分段方式为「按段落」时用所设值，其他方式一律置 0 |
| 段落最小长度 paragraphChunkMinSize | 强制为 100 | 按所设值 |
| 分块长度 chunkSize | 问答拆分取模型默认长度（上限 8000），其他处理方式取 1000 | 取所设值与「模型上下文长度、4000 取大者」两者之中的较小值 |
| 索引长度 indexSize | 问答拆分取向量模型的最大长度，其他处理方式取向量模型的默认长度（均为 512） | 问答拆分下仍被改写为向量模型最大长度，所设值不生效 |
| 自定义分隔符 chunkSplitter | 被清空 | 按所填值 |
| 分块长度下限 minChunkSize | 64 | 64 |
自动与自定义的差别，比界面上看起来的大
两种设置方式的差别不止于「几个输入框能不能编辑」。选择自动之后，分段方式被固定为按段落、段落 AI 识别被固定为禁用、段落深度固定为 5、段落最小长度固定为 100，这四项与界面上的显示无关。
更容易被忽略的是自定义分隔符。在自动方式下，这一项会被清空。所以如果先在自定义方式下填好了分隔符，之后又把设置方式切回自动，那个分隔符不会保留，而界面上不会提示这件事。需要用分隔符切分的文档，设置方式必须留在自定义。
自定义方式下也有两条改写规则。一条是分块长度会被模型上限截断，上限取「模型上下文长度」与 4000 之中的较大值，所设值超过上限时按上限生效。另一条是段落深度：只有分段方式选了按段落时才使用所设的深度值，选按长度或按分隔符时这一项被置为 0，界面上填过的深度不再起作用。
三种典型情况怎么设
结构清晰的长文档，比如产品手册、规范、标准。设置方式选自动即可，它会按段落切分并保留结构，段落深度 5 对多层标题的文档足够。如果检索时发现召回的内容经常跨章节，再切到自定义把段落深度调深。
格式统一的半结构化文档，比如按固定分隔符导出的记录、问答对文件。设置方式必须选自定义，分段方式选按分隔符，并填入实际使用的分隔符。这种情况下段落深度会被置 0，属于预期行为，不需要处理。
打算走问答拆分的文档。分块长度会按大模型的默认长度来，上限是 8000，比直接分段的 1000 大很多，因为要给模型足够的上下文去生成问答对。索引长度这一项在这种处理方式下取向量模型的最大长度，界面上填的值不生效，所以不用在这一项上花时间。
分块数与索引条数怎么估
分块数的估法是总字数除以实际生效的分块长度。这里要用实际生效的值，不是界面上填的值 —— 上面那张表里被改写的项，改写之后的数才是分母。按段落切分时实际分块数通常比这个估值多一些，因为段落边界不会正好落在长度上限处，一段不足长度上限时也会单独成块。
索引条数至少等于分块数：每一个分块默认建一条索引。如果为某些内容补了自定义索引，那部分内容的索引条数会成倍增加，一个分块配三条自定义索引就是三条。所以补自定义索引时要算一下总量，它比分块数增长得快。
这两个数决定三件事的量级。一是向量库的占用，它随索引条数与所用向量模型的维度一起增长，换一个维度更高的向量模型会成比例变大。二是建索引的耗时与调用量，每一条索引都要过一次向量模型。三是问答拆分的模型调用量，它按分块数计算，而问答拆分的分块长度上限比直接分段大得多，所以同一批文档走问答拆分时分块数会明显少于直接分段。
批量导入之前把这三个量级估出来，比导入过程中发现资源不够再中断要省事。尤其是首次导入大批文档时，先拿其中十几个文件跑一遍，用实际生成的分块数反推整批的量，比按公式估更准。
常见的三个误判
第一个是把分块长度调大当成提升召回精度的手段。分块变长之后单块内容更完整，但每一块里包含的主题也更多，语义检索时相似度会被无关内容摊薄。这两个方向哪个更划算取决于文档形态，调之前先在小批量上试。
第二个是把索引长度理解为分块长度。这是两个不同的量：分块长度决定一段内容有多长，索引长度决定为这段内容建索引时截取多长。索引长度的可选值是固定的十四档，而且会按向量模型的上限过滤，超过模型上限的档位在界面上不会出现。
第三个是分块长度设得过小。系统的分块长度下限是 64，低于这个值不会生效；而实际使用中长度过小会让每一块都缺少上下文，召回之后模型拿到的是碎片，反而更容易答错。
版本差异与失效说明
本页取值来自 v4.16.2。分块与索引的相关取值在这个版本与开发分支上一致，但索引长度的默认值与可选范围取决于所使用的向量模型的配置，更换向量模型之后需要重新确认。处理方式的可选项在版本之间有增减，升级后请以所部署版本为准。
继续阅读
本页参数与判定规则取自 FastGPT 开源仓库 v4.16.2，核验日 2026-09-09。