Dify RAG 分块大小怎么设：512 还是 1024 token

Q: Dify 的分块长度到底按 token 算还是按字符算？

按字符算。官方文档写的单位是 characters，不是 token。很多教程说“512 token”其实是套用了别的框架的语境，跟 Dify 界面里实际看到的数字不是一回事，中文场景下差得更明显。

Q: General 模式和 Parent-child 模式该选哪个？

内容零散、条目式的（FAQ、参数表、短问答）用 General 模式就够。说明书、合同、长文章这种需要看上下文才能读懂一句话的，用 Parent-child 模式效果明显更好。

Q: Chunk overlap 要不要开？

General 模式下建议开，常见做法是分块长度的 10% 到 20%。Parent-child 模式没有这个选项，因为父块本身已经把上下文兜住了，不需要重叠。

Q: Top K 和 Score Threshold 默认是多少？

官方文档里 Top K 默认 3，Score Threshold 默认 0.5。这两个在知识库的“召回测试”里能实时改数字看效果，不用改完直接上生产再看效果。

AIEII

先说结论：Dify 知识库设置里的“最大分块长度”，单位是字符，不是 token。这一点跟很多教程默认的语境不一样，也是本文标题里“512 还是 1024 token”这个问法本身需要先纠正的地方。中文文档按字符数配置更直接，不用先换算成 token 再倒推字符数。

至于具体设多少：官方文档没有给出一个写死的固定默认值，社区里反馈的常见默认在 500 字符上下，上限是 4000。真正决定效果的不是抄一个网上流传的数字，而是先搞清楚你的文档是"条目式"还是"长叙述式"，再决定用哪种分块模式、字符数往哪个方向调。

Dify 分块长度按字符数算，不是 token

这是最容易踩的坑。Dify 官方文档在"分块设置"这一节明确写的是"最大分块长度"以字符数计算，超出这个长度的文本会被强制切分，不管有没有匹配到设定的分隔符。而很多讲 RAG 分块的通用教程默认在讲 OpenAI 那套体系，用的单位是 token，英文场景下大致 1 个 token 约等于 4 个字符，中文场景下 1 个 token 经常对应 1 到 2 个汉字，两边完全不能直接套用。

结果就是：如果你照抄一篇讲"512 token 起步"的英文 RAG 教程，直接在 Dify 里填 512，对中文文档来说，实际切出来的分块会比预期短不少。反过来想按中文语义去套 1024 token，换算下来可能是 1000 到 1500 字符，超过了不少版本里 UI 给的默认上限提示，得手动往上调。

默认值没有一个固定答案，先看你自己的控制台

官方文档这一页本身没有写死"默认值是多少"，只说明了三个参数：分隔符、最大分块长度、块重叠（Chunk overlap，仅 General 模式下可用）。社区在 GitHub Discussions 和 Issue 里反馈的常见默认数字在 500 字符左右，上限 4000 字符。但 Dify 迭代很快，控制台的默认值、参数名称和位置都可能随版本变化，最靠谱的做法是打开你自己账号里"创建知识库"的分块设置页面，直接看当前显示的数字，而不是照搬任何一篇文章（包括这篇）里写的具体数值。

General 模式：分块长度和重叠怎么配

General 模式是单层结构，所有分块用同一套设置，检索命中哪个分块就直接返回哪个分块。适合内容本身比较零散、独立成段的场景，比如 FAQ 库、参数对照表、简短的操作步骤。

这种模式下有两个参数要一起调：

最大分块长度：中文场景常见起步区间是 300 到 800 字符，具体偏哪一头看你的段落天然长度。如果原文本身是短句短段（比如产品参数、常见问题），分块长度往小了设；如果原文是完整叙述性段落，往大了设，避免一句话被切成两半。
Chunk overlap（块重叠）：只在 General 模式下能设置，常见做法是分块长度的 10% 到 20%。比如分块长度设 500，重叠设 64 到 128 字符，让相邻分块之间保留一段共同内容，防止关键信息刚好落在切分点上被拆散。

Parent-child 模式：中文长文档更适合

Dify 在 v0.15.0 引入了 Parent-child（父子）检索模式，把文本拆成两层：小的子块用来做精准的语义匹配，大的父块在命中后作为检索结果返回，负责把上下文补全。这个模式下没有 overlap 选项，因为父块本身已经承担了"保留上下文"这个作用。

父块的切分方式有两种：按段落切，或者整篇当一个父块（Full Doc 模式）。要注意的是 Full Doc 模式下父块最多只处理前 10000 个 token，超出部分不会被索引，长文档要留意这个硬上限。

子块建议设得比 General 模式更小一些，300 到 500 字符是常见起点，目的是让检索时能精确定位到那句真正相关的话，再靠父块把这句话所在的完整段落或篇章带出来给模型看。产品手册、合同条款、技术文档这类"单看一句话容易断章取义"的内容，用这个模式比单纯调大 General 模式的分块要稳，也不容易出现分块越调越大、检索精度反而下降的情况。

配置步骤（2026-08 控制台）

进入知识库，点"创建知识库"，上传文档后进入索引方式选择页
选"高质量"索引模式（分块参数只有在这个模式下才能自定义，“经济"模式走的是固定规则）
分块模式二选一：General（通用）或 Parent-child（父子）；这一步选完之后不能再改，改分块模式要重新创建知识库
General 模式下填分隔符、最大分块长度、块重叠三个参数；Parent-child 模式下分别设父块和子块的切分方式
右侧预览区看实际切出来的分块效果，觉得不对就退回上一步改参数，不用真的等索引完才发现问题
索引方式（Embedding 模型）和检索设置（Top K、Score Threshold、要不要接 Rerank 模型）在同一个流程里一并配置完
确认无误后点击保存，Dify 开始跑索引任务，任务列表能看到处理进度

界面上的具体入口名称和排列顺序，不同版本可能有细节调整，以你打开的实际页面为准，步骤逻辑基本不会变。

分块调完了，Top K 和 Score Threshold 也要跟着看

分块只是第一步，决定"文档被切成什么样”；检索阶段的 Top K 和 Score Threshold 决定"每次问答从这堆分块里捞几条、捞多准"。官方文档给的默认值是 Top K 3、Score Threshold 0.5：Top K 越大，召回的分块越多，但也越容易把不相关的内容塞给模型；Score Threshold 越高，筛选越严格，召回的分块会变少。

这两个参数不需要靠猜，知识库自带"召回测试"功能，输入一句真实会被问到的问题，直接看召回了哪些分块、分数是多少，比空想调参数直观得多。分块参数改了之后，回到召回测试里重新跑一遍，比只改一次就上线放心。

我的判断

分块大小这件事，与其纠结"512 还是 1024"这种脱离场景的数字之争，不如先分清楚自己的文档属于条目式还是长叙述式：条目式内容用 General 模式，分块往小了设，配 10% 到 20% 的重叠；长叙述、强上下文依赖的内容直接上 Parent-child 模式，子块小一点保证匹配精度，父块负责兜住上下文。中文内容不要照搬英文教程里的 token 数字，Dify 界面看到的是字符数，两者换算比例在中英文之间差异很大，直接按字符数、结合自己内容的段落长度去调，比套任何一个"标准答案"都靠谱。