你是否也遇到过这样的困扰？花了不少精力把一份20页的技术白皮书导入Dify知识库，然后询问“如何配置API密钥”，系统却返回了一堆与问题毫不相干的部署步骤说明。问题出在哪里？说实话，很多时候并非模型能力不足，而是你喂给它的材料，在文档切分环节就已经切断了上下文关联。

文档分段策略与chunk size设置，直接决定了检索能否精准定位所需信息。本质上，这更像是系统工程中的关键预设步骤，而非可有可无的选项。

先判断，该用哪种分段模式

通用模式、Q&A模式、父子模式——它们并非并行可选的方案，而是各有适用前提的三类结构，需要先想清楚你手头的文档属于哪一类。

方法一：通用模式。 适合那些内容各自独立、互不依赖的文档。例如产品功能清单、FAQ条目集，或者独立技术博客合集。这种模式会按固定长度将全文硬性切断，因此它的致命弱点是：一旦文档存在跨段逻辑——比如“第一步→第二步→第三步”这类层层递进的关系，使用它几乎必然出现问题。

方法二：Q&A模式。 这个模式有一个硬性要求：原始文档必须是标准的Q&A格式，即每段严格以“Q:”开头、“A:”结尾。Dify不会自动猜测你是否在提问，也不会将普通段落改写成问答对。你传入什么结构，它就按什么结构解析。这是一个容易踩坑的地方。

方法三：父子模式。 目前来看，这可能是唯一能兼顾语义完整与检索精度的选择。你需要主动定义什么是“父块”（例如一个完整功能模块，约1500~2000字），什么是“子块”（比如该模块下的具体操作步骤，每块150~300字）。经验表明，医疗方案类文档启用父子模式后，针对“禁忌症”“用药间隔”等强依赖上下文的检索，召回率可提升约23%。

Chunk Size 不是拍脑袋就能定的数字

Chunk Size本质上是在平衡两件事：一是向量嵌入模型对输入窗口的长度限制，二是我们期望的语义单元粒度。如果盲目将大小设为500或1000，很可能会把一个完整的句子切得七零八落，或者塞进大量无关的冗余信息。

第一步， 先明确你使用的嵌入模型的token上限是多少。例如BGE-small-zh-v1.5是512 tokens，text-embedding-3-large是8192 tokens。用tiktoken统计原始文本的总token数，除以逻辑段落数（不是空行数），乘以0.7后再加64，最后取一个128到512之间的整数——这基本就是你的optimal_chunk_size。

第二步， 针对不同文档类型，可采用不同实测阈值进行微调。例如API文档建议用256，技术白皮书用384，会议纪要则用128。这些数值来自12份真实文档的召回率压测，并非纯理论推导。

第三步， 强制保留自然边界。无论计算出的chunk_size是多少，都必须确保切分点落在句号、问号、换行符或标题之后。Dify默认会按 [\n\n, \n, 。, ?, !, 空格, ] 这个顺序查找第一个可用的分隔符。如果为了凑字数而禁用所有分隔符，仅靠字符数硬切，语义上的割裂几乎无法避免。

Overlap 不是越大越好

Overlap的作用是给被切断的语义单元补充一条“记忆纽带”。但它的价值只有在你重叠的部分确实承载了上下文时，才能真正体现出来。

方法1： 对于父子模式，子块的overlap设为30到50个字符就足够了。因为父块本身就包含了全局上下文，子块只需锚定一些起始关键词，比如“配置步骤：”后面的几个字，就够了。

方法2： 对于通用模式，overlap必须至少是chunk_size的15%。否则像“本功能需配合v2.3以上版本使用”这种横跨两段的句子，前半句在块的末尾，后半句在下一个块的开头，系统根本无法关联。

方法3： Q&A模式不需要overlap。每个问答对本身就是一个语义闭环，添加重叠反而会污染向量空间，降低问题匹配的准确度。

Excel 这类结构化文件，需要单独处理

Excel不是纯文本，Dify默认的分段器会将整行合并后按字符切分，结果就是“A列字段名｜B列示例值｜C列说明”被分成三段，彼此之间完全丢失了关联。

第一步： 将Excel导出为CSV，然后用Python脚本在每行末尾插入一个唯一的分隔符，比如###。命令可参考：sed -i 's/$/###/' data.csv。

第二步： 上传CSV后，在Dify知识库配置中启用“自定义分隔符”，填入###。这样每行数据都成为一个独立的chunk，不会被语义分析干扰。

第三步： 将chunk_size设为实际单行最大字符数再加20（用于预留分隔符和空格），Overlap设为0。这一步不能省略，否则Dify可能将两行强行合并。