Dify 知识库三种分段模式实测：通用、父子、Q&A 到底怎么选？

基于 Dify 1.16.x 云端实测（2026-08-28）。

📖 摘要：把文档灌进 Dify 知识库时，「分段模式」只有通用分段这一个选项吗？不是——Dify 还支持父子模式和 Q&A 模式。本文用同一份语料、同一批问题，在云端实测三种分段模式的检索分数与问答效果，给出「文档形态 → 分段模式」的选型建议，并记录三个实测中踩到的坑（doc_form 传错位置、中文语料生成英文问答、Q&A 模式限流）。

导读

• 目标读者：用 Dify 建 RAG 知识库、被「分段怎么切」困扰的开发者
• 版本与环境：Dify 1.16.x（云上部署）、模拟语料（产品手册 + FAQ）、阿里云 embedding
• 你会得到：三种模式的机制差异、实测数据对比、选型矩阵、4 个真实坑

一、业务场景：知识库「分段」不是切就完了

我们接手的很多 RAG 交付，客户甩来一堆文档：「做成知识库，能回答问题就行」。第一步往往是切分——但怎么切，直接决定后面检索准不准、回答全不全。

之前我们一直用通用分段（按分隔符切段），直到最近才发现：Dify 知识库其实还支持父子模式和 Q&A 模式，三种模式的检索行为完全不同。于是我们在云端做了一组对照实验：同一份语料、同一批问题，三种模式各建一个库，用 hit-testing 看召回分数，再建三个同样的问答应用看端到端效果。

二、场景痛点：通用分段的两难

用通用分段（一段一向量，命中哪段返回哪段）时，我们反复撞上同一个矛盾：

• 段切小了 → 检索精准，但上下文碎——命中片段信息不全，回答「缺胳膊少腿」
• 段切大了 → 上下文完整，但一个段塞进多个主题，向量被稀释——问 A 命中的却是 B 段

最典型的翻车现场（本次实验实测）：FAQ 语料里问「首次登录默认账号密码是什么」，通用分段命中的是「固件升级」段——段内塞了太多问答对，向量糊成一团，检索直接错位。

三、解决方案：另外两种模式解决什么问题

Dify 的三种分段模式，本质是三种「定位与回答」的拆法：

• 父子模式解决「定位准 vs 上下文全」的矛盾：子段小而准负责被召回，父段大而全负责喂给 LLM——定位和回答各司其职。
• Q&A 模式解决「文档是叙述体、问答是短句对」的形态错配：把每段转成「问题 → 标准答案」，检索时 question 向量匹配更精准。

四、整体架构：实验怎么设计的

为了公平对比，我们严格控制变量：

五、模块设计：三模式建库参数差异

建库时三模式只有一个关键差异——文档创建 body 里的 doc_form 字段：

{

  "indexing_technique": "high_quality",

  "doc_form": "hierarchical_model",

  "doc_language": "Chinese Simplified",

  "process_rule": {

    "mode": "custom",

    "rules": {

      "segmentation": {"separator": "\n## ", "max_tokens": 300, "chunk_overlap": 0},

      "parent_mode": "paragraph",

      "subchunk_segmentation": {"separator": "\n", "max_tokens": 100, "chunk_overlap": 10}

    }

  }

}

• 通用：doc_form: "text_model"（默认，不传也行）
• 父子：doc_form: "hierarchical_model" + parent_mode + subchunk_segmentation
• Q&A：doc_form: "qa_model" + doc_language 必传（中文文档传 "Chinese Simplified"，否则生成英文问答！）

⚠️ 第一个坑就在这：doc_form 是文档级字段——创建 dataset 时传会被静默忽略（我们第一轮三模式段数一模一样，就是栽在这），必须在 POST /datasets/{id}/documents 的 body 里显式传。

六、运行验证：实测数据对比

6.1 手册类 hit-testing（同 query 召回分数）

6.2 FAQ 类 hit-testing

6.3 端到端问答（同一模板应用，只换绑定的库）

6.4 三种模式回答形态的差异（实测观察）

端到端测试除了「对错」，三种模式的回答形态也明显不同：

• 通用分段：把命中段原文拼进 prompt，LLM 自己从段落里提取答案——答对时中规中矩，但引用池里常混入无关段（问账号密码，引用列表里却有固件升级段），LLM 勉强「矮子里拔将军」
• 父子模式：LLM 拿到的是完整的父段上下文，引用干净、答案稳——四个问题全部精准命中正确来源
• Q&A 模式：prompt 里是现成的「question → answer」对，回答像查字典——答案最结构化；但检索一旦错位（命中了别的生成问题），LLM 拿着毫不相干的 Q/A 对也只能硬答，错误也最「自信」

一句话总结实测观感：父子是「稳」，Q&A 是「准的时候极准、偏的时候极偏」。

七、选型矩阵与建议

成本提醒：父子模式要父段+子段双份向量；Q&A 模式每段都要 LLM 生成 + 全量 embedding——Q&A 段数会爆炸（手册 18 段 → 118 段），限流环境索引容易 429 失败（我们实测踩中，阿里云 Throttling.RateQuota）。

通用分段不是「不能用」，是「要用对」：我们的 H3C 手册知识库（337 份文档、4277 页）至今用通用分段，靠的是建库前的数据清洗管线把文档切成「单段自包含」——每一段都能独立回答问题，段内不混主题（清洗管线实战见《RAG 知识库建库前，数据到底该怎么清洗？》）。所以判断顺序应该是：

1. 先问：文档能被清洗/改造成「单段自包含」吗？能 → 通用分段够用（成本最低）
2. 不能（长文强依赖、段内必然多主题）→ 父子模式
3. 文档是问答体、问题形态明确 → Q&A 模式（并验证生成问题质量）

八、实战坑（都是本次实测踩出来的）

九、启示

分段模式不是越高级越好，是「文档形态 × 问题形态」的匹配问题。通用分段不是不能用，而是要知道它的边界：段内多主题就是它的死穴。父子模式把定位和回答拆开，是长文档的稳健解；Q&A 模式是问题库的加速器，但「LLM 生成的问题质量」是它的命门——生成偏了，检索就偏了。

下次建知识库前，先问自己一句：这份文档是「叙述体」还是「问答体」？用户的问题是「问什么」还是「怎么办」？答案基本就定好了。

本文基于真实项目交付经验撰写（Dify 1.16.x 云端环境）。文中数据均来自我们自己的实测记录（6 个临时知识库 × 2 类语料、hit-testing 分数与端到端问答对照），理论与推断部分以「实测」标注边界，不构成任何平台的官方结论。