4.1 建知识库：文档上传与分段策略

4.1 建知识库：文档上传与分段策略

**分段（chunking）**是知识库质量的地基：把长文档切成一个个小段，每段独立向量化、独立参与检索。切得好，检索命中精准；切得差，答案被拦腰截断在两个分段里，再好的模型也接不回来。Dify 允许你控制分段标识符、最大块长与重叠三个旋钮，本节讲清每个旋钮的物理意义。

承接第 3 章末尾的翻车现场（编造临期商品政策），本章主线从建库开始。本节产出是"售后政策库 1.0"；4.2 节会给它配检索，4.3 节做验收。

从一沓文档开始

小艺的口粮是三类文件：一份十五页的《售后政策总则》、一份运营维护的 FAQ 表格、几页退换货流程截图（先不管图，首期只做文本）。进入控制台"知识库-创建"，上传文件后，界面停在分段设置页——这里是本节的主战场，也是整个 RAG 效果的第一道决定性关口。

先看 Dify 给的默认值，再逐个理解：

分段设置（默认）
分段标识符：\n\n          （两个换行，即空一行算一段边界）
最大分段长度：500 tokens  （单段超过就强制切断）
分段重叠：50 tokens       （相邻段之间重复的部分）

索引方式：高质量          （用嵌入模型生成向量，检索质量好）
Embedding 模型：系统默认（2.2 节设的那个）
​

分段标识符决定"在哪里允许下刀"。总则文档是标准的章节结构，段落之间空行分明，\n\n 天然合身。FAQ 表格则完全不同：一行一条问答，正确的刀法是按行切——标识符改成 \n，让每条问答独立成段。一份文档一个刀法，这就是为什么我反对"上传完一路下一步"。

最大块长的物理意义是"一次检索带回的知识粒度"。太短（比如 100），一条完整的退货政策被切成三段，检索只命中其中一段，答案缺胳膊少腿；太长（比如 2000），一段里混了四个主题，向量的语义被稀释，检索精度下降。客服政策的经验区间是 300 到 800 tokens：一条政策的完整表述通常落在这个范围。

重叠是为"刀口截断关键句"上的保险。相邻段重复 50 tokens，即使一句政策横跨刀口，两段里至少各有一份大部分内容。代价是存储与检索时的少量重复，50 是代价可忽略的安全值。

分段实验：同一段政策的两种切法

拿总则里的一条真实条款做对照实验。原文：

第七条 会员退货优惠：铂金会员自签收之日起 30 天内可申请无理由退货，
普通会员为 7 天。特殊定制类商品不适用无理由退货。
​

切法甲（块长 100，无重叠）：这句话被切成"铂金会员……普通会员为"与"7 天。特殊定制类……"两段。用户问"定制商品能退吗"，第二段被命中，模型看到的是没有主语的碎片，回答含混。

切法乙（块长 600，按 \n\n 切）：整条第七条完整落在一段里，命中即全句，回答干脆。这就是分段策略的价值——它决定了模型在检索窗口里看到的世界。

FAQ 表的处理还有一招：Dify 支持表格类文档按行切分后，问答天然成对（问题在一行、答案在同一行），检索命中率远高于把整张表塞成一大段。上传 FAQ 时把分段标识符改成换行，是本节最立竿见影的一条操作。

索引方式与嵌入模型：两个不可逆决定

索引方式二选一。高质量：用嵌入模型生成向量，支持语义检索（"想退货"能命中"退回商品流程"），消耗嵌入计算与向量存储；经济：只用关键词倒排，省资源但语义能力弱。客服场景用户问法千奇百怪，语义检索是刚需，无脑选高质量。

嵌入模型与索引绑定。4.1 节定下的嵌入模型会把每段文本转成一个高维向量，入库之后这些向量就是"这段话的坐标"。换嵌入模型等于换坐标系——旧坐标全部作废，必须全量重建索引（大库要重新跑嵌入，耗时耗钱）。所以 2.2 节那句话在这里兑现：嵌入模型是一次性决策，建库前定死。

决策清单（上传任何文档前过一遍）
[ ] 文档结构是什么？段落体还是表格体 → 定分段标识符
[ ] 单条知识的完整长度大概多少字 → 定最大块长（略大于它）
[ ] 条款是否经常横跨段落 → 定重叠 50 起步
[ ] 索引方式选高质量了吗？
[ ] 嵌入模型确认不再更换了吗？
​

建库之后的两件日常事

**其一，更新文档。**政策改版时，在知识库里替换文档（旧分段会被清除重建）。运营侧要养成"改政策先改库"的习惯——库里还是旧版政策时，小艺会一本正经地引用过期条款，这比编造更难被发现。替换后跑一遍 4.3 节的召回测试集，确认新政策命中正常。

**其二，检索测试与分段预览。**上传设置页就有分段预览：切完的每一段直接可见。发布前逐段扫一眼，检查有没有被拦腰截断的条款、有没有混进目录页码这类噪声段。这是十秒钟成本、高回报的动作。

问题：几十份文档该建一个库还是分几个库？

看两件事：检索时会不会互相干扰，以及更新节奏是否一致。总则与 FAQ 更新节奏都频繁、且内容性质相近，合一个库没问题；产品手册（每季度随版本变）与活动规则（每周变）就该分库——否则活动规则一改版，整个混库的检索分布都在漂移。分库的代价是应用侧要选择挂哪个库（或按问题路由，见 4.3 变式三），合库的代价是噪声互扰。小团队的起步建议：先一个库跑起来，4.3 的验收数据会告诉你什么时候该分家——命中排行里频繁出现"不该出现的文档"就是分家信号。

⚠️ 常见坑一：一份 PDF 里混着目录、页眉页脚，按默认设置入库后这些噪声也成了分段，检索时与正条政策抢位置。处理办法：上传前清理文档，或在预览里发现问题后回到源文档删掉噪声再重传。常见坑二：图 scanned PDF（扫描件）里根本没有可选中的文本层，入库全是空的或乱码。先确认文档是文本版，扫描件要先过 OCR。

💡 关键直觉：分段策略的本质是替未来的检索问题预设答案的边界。你切的每一段，都是在回答"用户问到某个点时，希望模型同时看到多大范围的上下文"。想清楚这句话，参数就不再是数字玄学。

本节要点回顾

• 三个旋钮：分段标识符定刀口、最大块长定粒度、重叠防刀口截断，按文档结构分别定值；
• 段落体与表格体刀法不同：总则按 \n\n，FAQ 按行切，一刀法走天下必翻车；
• 经验区间：块长 300–800 tokens、重叠 50 起步，客服类知识的完整表述多落在此区间；
• 索引高质量、嵌入一次性：嵌入模型与索引绑定，换模型等于全量重建；
• 更新即替换：政策改版先改库，替换后重跑召回测试集；
• 预览扫段：上传设置页的分段预览是成本最低的质量闸门。

库建好了，每段知识都有了坐标。下一节配检索：用户的问题进来，怎么把最相关的几段捞出来。