RAG 文档切多长，没有适用于所有企业资料的统一数字。合理的起点是：一条常见问题需要哪些证据才能答完整，这些证据能否在检索后一起进入上下文。模型输入上限是硬约束，片段长度则需要结合内容与问题验证。
先看证据在文档里如何分布
一份设备操作说明可能每个小节都能独立回答问题；一份差旅制度则可能在前文定义适用人员，在后文列标准，在附件解释例外。把两类文档都按相同字符数切开，未必得到同样可用的证据。切分应尊重段落、标题、列表和表格的含义。
先准备少量真实问题，并在原文标出答案位置。这里要标完整证据，而不只是包含关键词的那一句。例如询问“试用期员工能否申请培训”时，资格定义和例外条款可能都不可少。把这种跨度记录下来，才能判断片段是否切得过碎。
用两种方案做可解释的比较
可以先用固定长度作为基线，再比较按章节或段落边界切分的方案。保持文档集合、问题、检索与生成设置一致，分别记录目标证据是否被召回、无关内容占比以及回答是否遗漏条件。一次只改变主要切分因素，结果才容易解释。
| 观察现象 | 优先检查 |
|---|---|
| 关键词命中但答不完整 | 定义或例外是否被拆到未召回片段 |
| 一个结果包含太多不同主题 | 片段是否过大，语义重点是否稀释 |
| 多个结果内容几乎相同 | 重叠与重复片段是否占据候选位置 |
重叠用于接续，不用于弥补所有问题
相邻片段保留部分重叠内容，可以帮助跨边界句子保持连续；但重叠比例大，并不自动带来更好的回答。它也会增加重复内容，挤占检索候选和上下文。若关键条件相隔很远，机械扩大重叠可能仍无法把它们正确关联。
Microsoft 的切分文档同时讨论固定大小、按内容特征和组合方法，并建议结合具体内容调整。使用文档中的起始参数时，应把它当实验基线，不应把供应商示例直接写进本单位的质量承诺。中文字符数与不同模型的 token 数也不能简单视为同一指标。
保留能回到原件的线索
每个片段应关联原文标识、版本、章节路径和定位信息。这样团队看到错误回答时，可以确认是源文档缺内容、切分丢上下文，还是后续排序出了问题。只保存匿名文本片段，会让质量排查变成猜测。
最终选择应以重要问题的证据完整性为依据，而不是追求所有片段一样长。对于已经在协作文档中有清晰标题和表格结构的资料，先保留这些结构再比较切分方式。接入哪一种检索系统，都需要对真实资料做这一轮检查。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。