默认Recursive分块因分隔符优先级不合理而割裂上下文：技术文档常无空行，换行切碎列表，逗号切散关键短语；需重排separators将标题置顶并改用token计数，方能提升召回率。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你在Dify知识库中上传了一份32页的《AI安全合规白皮书》，用户提问“第三章提到的审计日志留存要求是否覆盖API调用记录”，系统却返回了第二章的加密算法说明——这不是模型没读懂，而是Recursive Character分块在默认配置下切碎了跨段逻辑链。
为什么默认Recursive分块会割裂上下文
默认使用separators=["\n\n","\n","。",","," ",""]时，分块器先用空行切，但技术白皮书常无空行；再用换行切，结果把“审计日志应包含：①时间戳 ②操作主体 ③API端点”这种列表硬切成三块；最后落到逗号上切，直接把“API端点、请求参数、响应状态码”拆成孤立短语。
这一步不改分隔符顺序，chunk_size设成200也没用——它根本没机会用到句号这一级，早在换行或空格就强行截断了。
关键参数对比：chunk_size与length_function的陷阱
方法一：用len()统计字符数（默认）
中文文本里400个字符≈180–220个token，远低于all-MiniLM-L6-v2的512 token上限，导致块过小、碎片激增；而英文文档400字符可能超512 token，触发向量截断。【同一chunk_size值对中英文实际承载信息量差异可达2.3倍】
方法二：用SentenceTransformer tokenizer统计token数
替换length_function=count_tokens后，分块器真正按模型能吃的token数切分。实测同一份混合中英文的技术文档，召回准确率从61%升至89%。
分隔符优先级重排实战
第一步：识别文档结构特征。技术白皮书含大量标题（### 第三章 审计要求）、编号列表（3.1.2）、代码块（curl -X POST），这些天然语义边界比句号更重要。
第二步：把标题分隔符提到最高优先级。修改separators为["### ","## ","# ","\n\n","\n","。","？","！"," ",""]。
第三步：强制保留标题与其后内容在同一块。测试发现，当“### 第三章 审计要求”和紧随其后的三段正文被切进同一chunk，用户问“第三章要求”时，召回率提升47%。
注意：Markdown标题符号必须带空格，否则###会误匹配代码块中的### comment。
重叠策略失效的典型场景
chunk_overlap=80在连续段落中有效，但在标题+列表结构中会出问题。例如：
### 第三章 审计要求
1. 日志须留存180天
2. 必须包含API端点
3. 响应状态码需记录
若第一块末尾是“1. 日志须留存180天”，第二块开头是“2. 必须包含API端点”，重叠区只覆盖数字序号，丢失“审计要求”这个核心主题词。此时应关闭overlap，改用父子模式。
这一步操作起来很简单：在Dify知识库设置中将分段模式从“通用”切换为“父子”，手动指定标题为父块，每条编号条目为子块。
