企业官网建设流程全解析

1. 项目背景与核心需求解析

1.1 为什么知识库分段模式值得单独研究

先聊点实际的。用过 Dify 知识库的人应该都有感受：同一个 PDF 或 Word 文档，切分方式不同，最后问答效果能差出好几个档次。默认的自动分段模式在简单文档上表现还行，可一碰到论文、产品手册、合同条款这种长文档，问题就来了——段落切得太碎，答案缺少上下文；切得太大，检索回来一堆无关内容，还浪费 token。

后来 Dify 上线了父子分段模式，我才算找到比较顺手的方案。简单说，父子模式就是先按大段落切一遍（父分段），再把每个父分段内部按小粒度再切一遍（子分段），同时保留父子之间的引用关系。检索的时候命中子分段，返回给大模型的是对应的父分段内容。这样既保证了召回精度，又不牺牲上下文完整性。

我最早是在界面上手动切分的，文档一多就烦了，而且团队其他人也要用，总不能每次都让人进后台点好几层菜单。于是我开始折腾知识库 API，想把“上传文档时自动启用父子模式”这件事用脚本固化下来。

1.2 这篇内容能帮你解决什么问题

如果你是 Dify 的深度用户，或者正在做知识库相关工具链的开发，这篇文章主要解决三个问题：

第一，搞清楚父子分段模式的原理和适用场景，不再靠猜或者盲目照搬别人的配置。第二，完整梳理通过 API 创建知识库、上传文档并指定父子分段模式的流程，让你不依赖界面也能完成全部操作。第三，整理我在实际开发中踩过的坑，包括参数不生效、父子关系丢失、文档处理失败等常见问题的排查思路。

适合谁来参考？正在用 Dify 做 RAG 应用的开发者、想把知识库管理流程自动化的小伙伴，以及对知识库分段策略感兴趣、想深入了解原理的产品和技术人员。如果你只打算在界面手动操作，这部分内容同样有参考价值，只是我会把重点放在 API 调用上。

2. 分段模式的选型思路与原理拆解

2.1 不同分段模式对比：父子模式到底赢在哪

Dify 知识库的分段模式大致分三类。普通模式（通用分段）是“一刀切”，文档进来后按分隔符规则切成固定长度的段，彼此独立，没有层级关系。这是一种最朴素的做法，优点是简单直接，部署成本低；缺点是遇到上下文依赖强的段落时容易切段“断片”——比如一个产品的技术规格表被拆成两块，检索时只命中了其中一半。

还有一种是一级父子模式，也就是我们要讲的重点。它分两步走：先用较大的 chunk size（比如 1000~2000 tokens）把文档切成若干父分段，再在每个父分段内部用更小的 chunk size（比如 100~500 tokens）切出子分段，父段和子段之间通过 ID 关联。检索的时候以子段为最小单元去匹配用户问题，但最终拼接给大模型的内容是子段对应的完整父段。

还有一类是更复杂的多级结构模式，比如按文档标题层级（h1/h2/h3）来动态规划分段边界。Dify 目前没有开放这种完全自定义的多级切分，但父子模式已经能在大多数场景下达到类似效果。

下面用表格对比一下：

2.2 父子分段的内部机制与工作原理

父子模式在底层是怎么跑通的，理解这一点对 API 调参很有帮助。

我用一个比较生活化的类比来解释。把一篇文档想象成一个大书架，父分段就是书架上的每一层隔板，子分段是隔板上的单个文件夹。当用户提问时，系统先在文件夹名称和内容摘要（子段）里找最匹配的那一摞文件，找到之后不是只把那一份文件递过去，而是把整个隔板上的文件一起递给你。这样，模型拿到的信息既有针对性的答案，又有完整的上下文支撑。

具体到 Dify 的实现，一个父分段下包含多个子分段，父分段本身也具备文本内容。父子关系是在文档切分阶段建立的，切分完成后，Dify 会为每个分段生成一个唯一的 segment ID，子分段会记录自己的 parent_segment_id。这个 ID 链条就是后续检索时“子查父回”的关键。

当用户发起对话时，检索链路大概是这样的：

1. 系统将用户问题做 embedding，在子分段集合里做向量相似度检索。
2. 命中若干子分段后，通过 parent_segment_id 找到对应的父分段。
3. 将父分段内容（或父分段 + 命中的子分段内容）一起作为上下文，拼进 prompt 喂给大模型。

这样做的好处是，答案精确度和上下文完整性不再是一对矛盾，可以同时满足。代价是响应时延略有提升、token 消耗略有增加，因为每次都要把更大的父段内容传进去，这在长文档场景下属于必要的开销。

2.3 什么场景该用父子模式，什么场景不该用

虽然父子模式好用，但它也不是万能的。比如简单的 FAQ 型知识库，一篇文章就三五句话，父段和子段的颗粒度几乎没有差别，这时候强行启用父子模式纯属浪费，只会增加存储和 token 成本。

再比如 OCR 识别出来的扫描件或者排版非常混乱的 PDF，这种文档前期如果不做清洗，切出来的父子段质量都很差，问题不在于模式，而在于数据源本身。这种情况需要先做文本预处理，而不是指望切分模式来拯救。

反过来，下面几种场景就非常适合父子模式：

• 技术文档和用户手册：每个章节是一个完整主题，章节内部包含多个小节，子段负责精细定位，父段保证上下文完整。
• 论文和研究报告：摘要、引言、方法、实验、结论，子段能精确召回某个实验结果，父段则提供必要的背景推导。
• 合同和法律条款：条款之间常互相引用，一旦切碎上下文极易丢失，父子模式能有效保持条款的完整性。
• 产品说明和配置指南：一个功能点散落在多个小节，子段定位后，父段会把相关配置项一起带上，效果明显比单段检索好。

判断标准其实就一条：单段切小了，是否影响模型理解这段内容的完整含义。如果影响，那就是父子模式的用武之地。

3. 通过 API 实现父子分段模式的完整流程

3.1 环境准备与权限前提

开始之前，先把环境准备好。我假设你已经部署好了 Dify 社区版（1.x 版本都支持），并且有一个可以调用的 API Key。在 Dify 里，API Key 分成两类：一个是“数据集”级别的，专门用于知识库的创建、文档上传、分段管理等操作；另一个是“应用”级别的，用于调用对话应用或工作流。这里我们需要的是数据集级别的 API Key。

生成位置在知识库页面右上角的“API 访问”入口，你可以创建一个专属 Key。注意 Key 的权限范围要勾选“仅数据集权限”，这样即使 Key 泄露，也不会影响应用侧的对话接口。

代码方面，我用 Python 写示例，因为 Python 生态里处理文件、调用 HTTP 都方便。如果你用的是其他语言，只要看明白请求结构，照样能迁移。Dify 的 API 是标准 RESTful 风格，没有特别复杂的鉴权机制，请求头里带Authorization: Bearer {API_KEY}即可。

pip install requests

只靠 requests 就够了，不需要额外的 SDK。当然 Dify 官方也提供了 Python SDK，封装更完整一些，不过为了让大家看清底层请求长什么样，这里我直接裸调 API 讲解。

3.2 第一步：创建知识库

如果你已经有了知识库，这一步可以跳过。没有的话，先创建一个。请求方式比较直接，一个 POST 请求搞定：

import requests import json API_BASE = "http://your-dify-host/v1" DATASET_API_KEY = "dataset-xxx" headers = { "Authorization": f"Bearer {DATASET_API_KEY}", "Content-Type": "application/json" } payload = { "name": "产品技术手册库", "description": "存放产品手册、技术白皮书等文档，启用父子分段模式", "indexing_technique": "high_quality", # 高质量索引模式，必须使用 embedding "permission": "only_me", "provider": "vendor" } resp = requests.post(f"{API_BASE}/datasets", headers=headers, json=payload) print(resp.status_code, resp.json())

这里有两个参数值得注意。indexing_technique必须是high_quality，因为父子模式是基于向量检索的，低质量模式（keyword）不支持这个能力。provider参数目前固定在vendor，代表平台内置的向量化服务，如果你在部署时配置了外部 embedding 服务，那就使用默认词向量方案，这个按实际情况来。

创建成功后返回结果里有一个id字段，这就是 dataset_id，后续上传文档都要用到。保存好它。

3.3 第二步：上传文档并指定父子分段参数

创建完知识库之后，可以开始上传文档了。Dify 支持两种方式：直接上传文件，或传入纯文本。这里以最常用的文件上传举例。

API_BASE = "http://your-dify-host/v1" DATASET_ID = "your-dataset-id" API_KEY = "dataset-xxx" headers = { "Authorization": f"Bearer {API_KEY}" } data = { "data": json.dumps({ "indexing_technique": "high_quality", "process_rule": { "mode": "custom", "rules": { "mode": "parent_child", # 核心：启用父子分段模式 "parent_mode": "paragraph", # 父分段切分模式：按段落 "parent_max_tokens": 2000, # 父分段最大长度 "child_mode": "custom", # 子分段切分规则 "child_max_tokens": 500, # 子分段最大长度 "separators": ["\n\n", "\n", "。", "！", "？", "；"], "chunk_overlap": 50 } }, "retrieval_model": { "search_method": "hybrid_search", "reranking_enable": True, "reranking_model": {"model_provider": "openai", "model_name": "gpt-3.5-turbo"}, "top_k": 6, "score_threshold": 0.5 } }) } files = { "file": ("产品手册.pdf", open("产品手册.pdf", "rb"), "application/pdf") } resp = requests.post( f"{API_BASE}/datasets/{DATASET_ID}/document/create_by_file", headers=headers, data=data, files=files ) print(resp.status_code, resp.json())

上面这段代码里有几个关键配置点，我一个个说。

process_rule.mode传custom，表示不用自动规则，改用我们自定义的分段设置。这就是 API 与界面操作的一个差异点：界面上你可以选“自动”让系统替你决定，但 API 调用中要显式声明custom，否则你传的rules不生效。

rules.mode传parent_child，这就是激活父子模式的核心开关。parent_mode表示父分段的切分方式，常用值有paragraph（按段落）和custom（自定义分隔符）。paragraph适合章节结构清晰的文档，custom适合需要完全控制切分边界的场景。大多数情况下，我用paragraph就很够用了。

child_mode是子分段的切分方式。它与父分段最大的不同在于长度上限，这里我给的child_max_tokens是 500，实属比较中庸的配置，后面我会专门讲如何根据自己的文档类型来调这个值。

最后是separators。注意，这里定义的是子分段切分时的分隔符优先级，Dify 会按数组顺序逐一尝试，先用\n\n切，不行再换\n，再不行匹配中英文句号。这个优先级设计很关键，我观察了好几次切分日志才发现它真的是按顺序匹配的，不是同时生效。

3.4 第三步：通过文本方式上传并指定父子模式

如果你不想走文件上传，也可以直接用纯文本创建文档，这种方式在做文档预处理或动态拼接内容时很方便。

payload = { "name": "线上帮助中心文档", "text": "这里是一大段文档内容......", "indexing_technique": "high_quality", "process_rule": { "mode": "custom", "rules": { "mode": "parent_child", "parent_mode": "custom", "parent_max_tokens": 1500, "child_mode": "custom", "child_max_tokens": 300, "separators": ["\n\n", "\n", "。", "！", "？"] } } } resp = requests.post( f"{API_BASE}/datasets/{DATASET_ID}/document/create_by_text", headers=headers, json=payload ) print(resp.status_code, resp.json())

纯文本方式对格式要求更高，因为少了 PDF 或 Word 自身的样式标记，Dify 只能靠分隔符来识别段落。如果你的文本里没有统一的换行或句读习惯，切出来的父分段会很乱。传递文本前，建议自己先做清洗，把多余的换行合并，把标题行用\n\n明显标出。

3.5 第四步：确认文档索引完成

上传文档只是提交了一个异步任务，真正切分和向量化要在后台跑一段时间。文档越长，耗时越长，类型越复杂（比如扫描版 PDF），耗时越不可控。我一般会轮询文档详情接口，确认状态：

DOCUMENT_ID = "your-document-id" resp = requests.get( f"{API_BASE}/datasets/{DATASET_ID}/documents/{DOCUMENT_ID}", headers=headers ) doc = resp.json() print("indexing_status:", doc.get("indexing_status")) print("processing_started_at:", doc.get("processing_started_at")) print("parsing_completed_at:", doc.get("parsing_completed_at")) print("error:", doc.get("error"))

indexing_status常见的取值有waiting、indexing、paused、completed、error。当它变成completed，说明文档已经完成切分和向量化，可以被检索了。如果是error，需要进一步排查，这个我会在后面的常见问题章节详细讲。

3.6 第五步：验证父子分段是否真正生效

文档索引完成之后，最关心的就是“到底有没有按父子模式切？”。通过分段列表接口就能看到结构：

resp = requests.get( f"{API_BASE}/datasets/{DATASET_ID}/documents/{DOCUMENT_ID}/segments", params={"page": 1, "limit": 20}, headers=headers ) segments = resp.json()["data"] for seg in segments: print("segment_id:", seg["id"], "| parent_id:", seg.get("parent_segment_id"), "| 字数:", len(seg["content"]))

你会看到，有些分段有parent_segment_id，有些没有。没有parent_segment_id的分段就是父分段本身；有值的那些是子分段。同一个父分段下的子分段，它们的parent_segment_id是相同的值。

这里有个小技巧。如果你看到父子段数量完全一样，那说明子分段的切分粒度没有生效——大概率是child_max_tokens设置得比父段还大，或分隔符全部匹配失败，导致子段退化成父段的副本。正常情况下一篇 5000 字的文档，父段数量应该在 5~10 个，子段数量应该在 20 个以上，具体取决于文档结构，但数量上肯定存在明显的倍数关系。

4. 参数调优的实战经验

4.1 父分段与子分段的长度配比怎么选

父子模式的参数不是一拍脑袋定的，要看你的文档类型和问答场景。我整理了几个典型配置组合，可以直接拿去参考：

原则很简单：子分段越小，召回越精确；父分段越大，上下文越好。但两者不能走极端。子分段低于 100 tokens 时，信息密度太低，经常匹配到无意义的片段；父分段超过 3000 tokens 时，prompt 太长，模型容易忽略关键细节，成本也会明显上升。

4.2 分隔符优先级如何影响切分质量

我最初一直搞不懂为什么有些文档在父子模式下切得乱七八糟，后来仔细对照日志才明白，分隔符的匹配顺序是致命的。

Dify 会按照你在separators数组里写的顺序，从前往后尝试匹配。比如["\n\n", "\n", "。"]，系统会先用空行切分父段，切完如果还有超过parent_max_tokens的长段，再尝试用换行符切，还没切完，再用中文句号兜底。

如果顺序写反了——比如把。"放在\n\n前面——就会导致句子被提前切破，一段讲同一件事的文字被硬生生拆到两个子段里，检索质量明显劣化。现在我推荐一个比较稳的默认顺序：先按空行，再按换行，最后按标点符号。这个顺序基本适配大多数排版正常的文档。

遇到特殊情况，比如法律条款里每条条款都以“第X条”开始，可以在separators里加入 “第” 作为分隔符，但必须保证每个条款的格式统一，否则反而会切出大量空段落。

4.3 top_k 和 score_threshold 的配合策略

分段模式定了之后，检索参数同样会影响最终效果。有人会把top_k调得非常大，认为召回越多越好，其实这是误区。父子模式下，一个父段可能下面挂 5~10 个子段，最终拼接进 prompt 的是一个完整的父段内容，top_k=6可能返回 2~3 个不同的父段，内容长度可能已经达到 4000~6000 tokens。

如果文档很长，我建议top_k设在 4~6 之间，score_threshold设在 0.3~0.5 之间。score_threshold太低会混入大量无关片段，太高则容易漏召回。我在实际项目中一般先用 0.4 起步，然后根据问答效果微调。

4.4 一个可靠的调参检查清单

调参经验这东西，光看理论不够，得有一套自查流程。我每次调参后都会按下面这个清单过一遍：

• 确认process_rule.mode="custom"，而不是automatic。
• 确认rules.mode="parent_child"，这个字段是最容易漏的，漏了就会退回普通模式。
• 确认parent_max_tokens明显大于child_max_tokens，比如 2000 > 500。
• 确认separators的优先级顺序合理，空行在句号之前。
• 查询分段列表，数一数带parent_segment_id的分段比例是否符合预期。
• 实际发起测试问答，检查返回内容是否包含完整的上下文，而不是只有孤零零的一小段。

5. 常见问题与排查技巧实录

5.1 API 返回 400 或参数不生效

这是最高频的问题。我最初排查时明明在 payload 里写了parent_child，但文档处理完之后一查分段列表，全是平铺的，没有父子关系。最后发现原因很隐蔽：我在process_rule里同时传了rules的外部结构，但mode这一层写成了automatic。Dify 对自动模式的处理策略就是忽略rules里的所有细节，直接按自身逻辑来。

另一种 400 报错常见于 embedding 配置问题。如果知识库创建时的indexing_technique是economical（经济模式），就不能用父子分段。创建时如果一直报Invalid indexing technique，检查一下你的 Dify 部署里是否配置了有效的 embedding 模型，以及模型供应商的 API Key 是否正常。

5.2 文档索引卡在 waiting 或 indexing 很久

上传成功后文档一直处于waiting状态，常见原因是 Dify 的 worker 服务没启动。Dify 是个多服务架构，API 服务和 worker 是分开的，文档处理任务由 worker 消费。如果你用 Docker 部署时只启动了 API 容器，queue 里的任务就永远没人执行。

docker compose ps

确认worker容器处于 running 状态。如果它总是重启，查看日志：docker compose logs worker。还有一种情况是 embedding 模型 API 限流，批量上传大量文档时尤其常见。我试过一次性传 50 篇，跑到第 20 篇就开始排队，这属于正常现象，调大CELERY_WORKER_MAX_TASKS_PER_CHILD和CELERY_WORKER_PREFETCH_MULTIPLIER能缓解，但根本办法还是控制单批上传数量。

5.3 父分段和子分段数量不对，父子关系丢失

有次我处理一份 PDF，分段列表查出来全是父分段，没有子分段。最初以为是参数问题，折腾了很久，后来发现是那份 PDF 是图片扫描件，Dify 的文本抽取器基本抽不出文字，自然没法做切分。这就是前文提到的数据源问题，不管什么参数都救不回来。

解决办法是先用 OCR 工具把 PDF 转成可复制的文本，或者直接用 Dify 服务里的 OCR 组件预处理。如果文档是 Word 或 Markdown，基本不会遇到这个问题。

另一个造成父子数量不对的原因是，我想当然地把自己定义的separators同时用在了父段切分和子段切分上。父段切分遵循的是parent_mode指定的模式，如果你选了paragraph，系统会按文档结构自动识别段落边界，而不是按你提供的分隔符来切。只有当parent_mode="custom"时，separators才会作用于父段切分。搞清楚这一点，排查问题时能少踩很多坑。

5.4 检索效果差：命中了子分段但回答还是不对

还有一个比较隐蔽的问题：检索明明命中了正确的子分段，但最终回答质量依然很差。排查下来发现，问题出在返回父分段的逻辑上——如果命中的子分段恰好位于一个内容非常杂的父分段内（比如一个大章节横跨多个主题），父分段里 90% 的内容都是无关信息，模型会被干扰。

出现这种情况，我一般会调整父段的切分方式，把parent_max_tokens调小一些，让父段更聚焦。或者检查文档本身的结构是否合理，有些 PDF 章节标题和正文混在一起，切分出来的父段天然就很难用。这时候可以考虑先用脚本对文档做预处理，把结构清洗清楚再上传。

5.5 常见问题速查表

6. 知识库 API 的更多实用扩展

6.1 批量上传多个文档时的代码组织

实际项目中不会只有一个文档要传。一次传几十个文件时，建议用循环统一处理，同时加入状态检查和次数限制。下面是我的参考实现：

import time import os import requests import json def create_document_from_file(file_path, dataset_id, api_key): headers = {"Authorization": f"Bearer {api_key}"} data = { "data": json.dumps({ "indexing_technique": "high_quality", "process_rule": { "mode": "custom", "rules": { "mode": "parent_child", "parent_mode": "paragraph", "parent_max_tokens": 2000, "child_mode": "custom", "child_max_tokens": 500, "separators": ["\n\n", "\n", "。", "！", "？"], "chunk_overlap": 50 } } }) } with open(file_path, "rb") as f: files = {"file": (os.path.basename(file_path), f)} resp = requests.post( f"{API_BASE}/datasets/{dataset_id}/document/create_by_file", headers=headers, data=data, files=files ) if resp.status_code == 200: return resp.json()["document"]["id"] else: raise Exception(f"上传失败: {resp.status_code} {resp.text}") def wait_for_index(dataset_id, document_id, api_key, timeout=600): headers = {"Authorization": f"Bearer {api_key}"} start = time.time() while time.time() - start < timeout: resp = requests.get( f"{API_BASE}/datasets/{dataset_id}/documents/{document_id}", headers=headers ) status = resp.json().get("indexing_status") if status == "completed": return True if status == "error": raise Exception(f"文档索引失败: {resp.json().get('error')}") time.sleep(5) return False

这个方案里加了两个防呆设计。一是把文件路径和文件名分离出来，避免不同目录下同名文件互相覆盖；二是加了一个wait_for_index轮询，超时自动抛出异常，防止任务挂在后台一直跑。

6.2 更新文档时保持父子模式的连续性

文档更新是另一个高频需求。每次更新文档时，如果只传新文件而漏掉了process_rule，Dify 会采用知识库的默认规则，大概率把你的父子模式覆盖掉。更新接口和创建接口在参数结构上基本一致，但注意更新操作会先删除旧的分段再创建新的，期间文档会短暂处于不可索引状态。

data = { "data": json.dumps({ "name": "产品手册-2025版", "indexing_technique": "high_quality", "process_rule": { "mode": "custom", "rules": { "mode": "parent_child", "parent_mode": "paragraph", "parent_max_tokens": 2000, "child_mode": "custom", "child_max_tokens": 500, "separators": ["\n\n", "\n", "。", "！", "？"] } } }) } resp = requests.put( f"{API_BASE}/datasets/{DATASET_ID}/documents/{DOCUMENT_ID}/update_by_file", headers=headers, data=data, files=files )

我踩过的坑是：更新文档时没有传indexing_technique，结果 Dify 自动用了知识库创建时默认的economical模式，导致更新后的文档全部脱离向量搜索，检索结果全乱套。所以无论是创建还是更新，只要想用父子模式，每次都要显式声明技术索引模式和相关参数。

6.3 调用聊天应用让父子模式真正发挥价值

文档上传和切分只是前半程，真正让父子模式发挥价值的地方在应用端。在 Dify 应用里，知识检索组件需要正确配置召回模式和参数。举个例子，你在工作流里添加知识检索节点时，需要设置：

• retrieval_mode选hybrid_search，让语义和关键词都能命中。
• top_k设在 4~6，召回太多会把大量无关父段塞进上下文，反而稀释重点。
• score_threshold设在 0.4 左右，太大容易漏召回，太小不相关的段落也挤进来。
• 开启reranking，有条件的话配一个好的重排模型，能显著提升最终排序质量。

这些设置在创建知识库时可以通过retrieval_model参数一并写入，但应用侧的知识检索节点也可以单独配置，优先级更高。实际调优时建议两边都检查一下，很多“检索不到”的问题其实是应用侧把知识库的设置覆盖了。

6.4 将父子模式封装为自动化管道

最后分享一个思路，如何把整个流程做成自动化管道。我目前的团队内部做法是：文档先提交到一个企业内部系统，系统自动做格式校验、敏感信息过滤，然后调 Dify 的 API 创建文档、设置父子模式，完成后自动触发一轮测试问答，用脚本比对回答质量，最后把结果同步回工单系统。

这套流程跑起来之后，知识库的维护成本明显降低。之前每次更新文档都要人工登录后台，选择文件、等索引、手动验证；现在全自动跑完，异常才需要人工介入。核心价值不是省了多少时间，而是让知识库的分段策略能够被稳定、一致地执行，不会因为某次手动操作忘记勾选某个选项而埋下隐患。

7. 写在最后的项目复盘与建议

整个项目做下来，我最深的体会有三个。

第一个是文档质量决定切分上限。再好的分段参数也救不了排版混乱、结构不清的原始文档。如果发现父子模式效果不如预期，先回头检查文档质量，不要急着怀疑参数。

第二个是参数组合要按文档类型各备一套。我维护了一个简单的配置文件，里面放了几组已知有效的父子模式参数组合，按文档类型选用。这样既省心又不会因为临时拍脑袋影响效果。

第三个是API 自动化真正能落地的前提是把状态管理做好。上传、切分、索引、验证，每一步都要有明确的状态记录和异常处理。不要指望一次性把脚本写完美，先跑通主流程，再逐步加固细节。

最后再分享一个我很受益的小习惯。每次调整完分段参数，我都会保留一份当时的文档样本和配置快照，方便后续对照测试。文档会更新，配置会变动，如果没有这些记录，时间一长，你根本说不清楚当前这套效果很好的配置是从哪一组参数演化而来的。

父子分段模式确实是 Dify 知识库能力里含金量很高的一块，值得花时间吃透。希望这篇拆解能帮你少踩几个坑，顺利把知识库的刀磨快。