RAG 文档切多长合适？用问题能否答完整来决定

RAG 文档切多长，没有适用于所有企业资料的统一数字。合理的起点是：一条常见问题需要哪些证据才能答完整，这些证据能否在检索后一起进入上下文。模型输入上限是硬约束，片段长度则需要结合内容与问题验证。

先看证据在文档里如何分布

一份设备操作说明可能每个小节都能独立回答问题；一份差旅制度则可能在前文定义适用人员，在后文列标准，在附件解释例外。把两类文档都按相同字符数切开，未必得到同样可用的证据。切分应尊重段落、标题、列表和表格的含义。

先准备少量真实问题，并在原文标出答案位置。这里要标完整证据，而不只是包含关键词的那一句。例如询问“试用期员工能否申请培训”时，资格定义和例外条款可能都不可少。把这种跨度记录下来，才能判断片段是否切得过碎。

用两种方案做可解释的比较

可以先用固定长度作为基线，再比较按章节或段落边界切分的方案。保持文档集合、问题、检索与生成设置一致，分别记录目标证据是否被召回、无关内容占比以及回答是否遗漏条件。一次只改变主要切分因素，结果才容易解释。

重叠用于接续，不用于弥补所有问题

相邻片段保留部分重叠内容，可以帮助跨边界句子保持连续；但重叠比例大，并不自动带来更好的回答。它也会增加重复内容，挤占检索候选和上下文。若关键条件相隔很远，机械扩大重叠可能仍无法把它们正确关联。

Microsoft 的切分文档同时讨论固定大小、按内容特征和组合方法，并建议结合具体内容调整。使用文档中的起始参数时，应把它当实验基线，不应把供应商示例直接写进本单位的质量承诺。中文字符数与不同模型的 token 数也不能简单视为同一指标。

保留能回到原件的线索

每个片段应关联原文标识、版本、章节路径和定位信息。这样团队看到错误回答时，可以确认是源文档缺内容、切分丢上下文，还是后续排序出了问题。只保存匿名文本片段，会让质量排查变成猜测。

最终选择应以重要问题的证据完整性为依据，而不是追求所有片段一样长。对于已经在协作文档中有清晰标题和表格结构的资料，先保留这些结构再比较切分方式。接入哪一种检索系统，都需要对真实资料做这一轮检查。

参考资料

• Chunk Documents - Azure AI Search | Microsoft Learn
• Develop a RAG Solution on Azure - Chunking Phase - Azure Architecture Center | Microsoft Learn