编者按：
在此前分享的文章中，我们讨论了为什么仅靠大模型的“通识”不够，以及知识库与 RAG 在法律场景中的作用。但对很多法律人来说，更棘手的问题往往是下一步：知识库具体应该怎么建？文档究竟要切成什么样，检索和参数又该如何设置？
本文节选自《法律智能体（Agent）搭建指南：以 Dify、扣子为例快速入门》书稿，围绕知识库搭建与整理，介绍在 Dify 中如何选择数据源、设置分段模式（通用模式与父子模式）、配置索引方式与检索策略，以及在与 LLM 联动时如何使用“查询变量”和“上下文”。文末还结合法天使的实践经验，总结了父子段编辑、表格与流程图预处理、文档整理策略等操作建议，供正在推进或参与知识库建设的法律人参考。
相关文章：
总觉得大模型不够聪明？这篇教法律人怎么给AI带小抄（知识库与RAG）
用户可以便捷地上传多种格式的文档，例如TXT、Markdown、PDF、HTML、DOC等。上传后，Dify会自动对这些文档进行分段，并对分段后的文本进行数据向量化处理，为高效检索奠定基础。
一、选择数据源：文档上传
要在 Dify 中 建立知识库，首先点击界面顶部的“知识库”选项，随后选择“创建知识库”。
（点击图片可放大查看）
Dify 支持三种数据源的导入方式。文本格式推荐 TXT 或 Markdown 格式，方便后续的文本分段与清洗。
（点击图片可放大查看）
不同文本格式的简要对比如下：
这里上传的文本是摘自
二、文本分段与清洗：分段设置
导入文本之后，需要进行分段设置。知识库会对这些文档进行分段（Chunking）和数据清洗，这个过程是将长文本分割成更小、更易于检索的“内容分段”（Chunk）。Dify 知识库支持多种分段模式，包括通用模式和父子模式。这两种模式在检索和召回逻辑上有所区别：通用模式下，用于检索和召回的块是相同的；而父子模式则允许分别定义检索字段（子块）和召回字段（父块）。
1.通用模式。
在通用模式下，知识库会依据预设的分段标识符将文档内容拆分为独立的分段。默认的分段标识符是两个换行符 \n\n，但用户可以根据文档的实际结构修改分段标识符。这要求事先对文档进行预处理，以将分段标识符和文档匹配。
就上图TXT文档而言，根据条款的不同，文档被拆成了不同的父段。每个父段表示一类条款。点击“预览块”，可以在右侧直观地查看分段效果。
2.父子模式。
父子模式下将创建两种块段：父块（Parent-chunk）保持较大的文本单位（如段落），提供丰富的上下文；子块（Child-chunk） 则是较小的文本单位（如句子），用于精确检索。Dify 知识库中默认的分段规则是，\n\n为父块之间的分段标识符，\n为子块之间的分段标识符。
如果采用这种分段标识符，上传的文档中必须预先处理成：子块与子块之间换行，父块与父块之间空一行的格式。
事先文档处理格式的示例：
Plain Text
示例
子块1-1
子块1-2
子块1-3
子块2-1
子块2-2
子块2-3
如上所示，子块间的换行意味着存在\n，子块1-1、子块1-2、子块1-3整体作为父块1，子块2-1、子块2-2、子块2-3整体作为父块2，这两个父块之间是用一行空格区分的，即\n\n。
以图上图TXT文档为例，如果上传该文档，选择父子分段模式的预览块如下图所示：
此时可以看到，父块内容被拆成了若干个小段，每个小段都是原TXT文档中的一行。
3.分段标识符的选择。
分段标识符可以修改，只要该符号与上传文档中的分隔保持一致即可。文本的正确分段与否会显著影响知识检索的效果。如果分段不理想，用户需要选择调整分段标识符，或者重新处理原始文档。因此，务必利用“预览块”功能来核对文档是否被正确分段。
此外，如果某个子段或父段包含较长的文本，应适当调大分段最大长度，否则过长的内容可能会被强制拆分，导致分段不符合预期。Dify 知识库的分段最大长度为4000字符。
三、文本分段与清洗：索引方式与检索设置
1.索引方式
确定分段模式后，接下来需要选择索引方式。Dify 知识库提供了高质量索引和经济索引两种方式，这里推荐使用高质量索引方式。
在经济索引方式下，每个数据块会提取有限的关键词。这种方式依赖于关键词的精准匹配。如果查询中的关键词未能完全匹配，即使内容语义相关，也可能被忽略。
在高质量索引方式下，Dify 知识库会利用 Embedding 模型对文档的每个分段进行向量化处理，生成高维度的语义向量。这些向量存储在向量数据库中，实现语义匹配。这意味着，即使查询中没有出现完全相符的关键词，只要语义相关，也能被准确召回。
选择高质量索引方式后，文本内容会被转换为计算机可理解的多维数字向量。这些向量能够捕捉文本的深层语义信息，而不依赖于关键词的精准匹配。
2.检索设置。
在高质量索引方式下，Dify 知识库提供向量检索、全文检索与混合检索这三种检索设置。
向量检索（Vector Search）是指，用户输入的查询变量也会被转换为向量，通过比较查询向量与知识库中所有文本向量间的距离，来实现语义上的相似性匹配。这些向量捕捉了文本的语义信息，即使两个句子使用了不同的词语，但表达的含义相似，它们的向量也会在向量空间中彼此靠近。
全文检索（Full-Text Search）是指，在文本中查找与查询关键词完全匹配或高度相关的文档。
混合检索（Hybrid Search）则结合了向量检索的语义理解能力和全文检索的关键词精确匹配能力。混合检索通常会同时执行向量检索和全文检索，系统会将两种检索方式的结果进行融合，例如通过加权分数、重排序等方式来生成最终的召回结果。
三种检索设置中都有 Rerank 模型、Top K 和 Score 阈值。
Rerank 模型是指对初步召回的文档片段进行二次评估和重新排序，可以提升召回结果的准确率。想象一下，你在图书馆借书，你通过自己的语义判断或者关键词检索，查询到多本相关图书，但你最终决定带走最相关的三本。Rerank 模型的重排有些类似这里的最终决定过程。
Top K 指的是在所有召回的最相似的文档片段中，最终要选择并发送给大语言模型的数量上限。K 值的设置是一个权衡过程，可以根据知识库的运作效果而调整。K 值越大，召回的信息越丰富，理论上覆盖用户查询所有可能点的机会越大；K 值越小，召回的信息越精简，可能丢失一些潜在相关信息，但能有效控制成本和 LLM 输入。
Score 阈值是相似度阈值，如果选择开启该阈值，只有当文档片段的相似度高于或等于这个阈值时，该片段才会被召回。它是一个准入门槛。
后两个数值的设置应该根据知识库的内容以及知识库的使用需求来定。比如如果我们允许知识库的检索结果为空，甚至为空才是更好的时候，我们就应当设置 Score 阈值；如果知识库有多个父段使用的是同一子段，则应当视情况提高 Top K 值。
四、处理并完成及后续操作
文档处理完成之后，知识库创建成功。
可以在「知识检索」中添加该知识库。
五、常见问题
1.上传 Markdown 文件无法正确分段？
这是因为在 Markdown 语法中，实现换行主要有两种方法：在行尾添加两个或多个空格，然后按回车键，或者使用HTML的标签。单纯的换行并不会被识别成“\n”。这也是为什么推荐使用TXT文档的原因。
2.分段符正确但仍分段错误？
此时需要调整分段最大长度，因为超出设置的最大长度的内容会被强制拆开。Dify 知识库分段最大长度是4000字符。
3.知识库文档索引失败？
可能是 Embedding 模型的原因，可以更换模型再试一试。
一、在「知识检索」中选择查询变量
知识库与 LLM 的联动，就是通过 RAG 的方式，让 LLM 在回答问题时，不再仅仅依赖其训练数据中的可能过时或不全面的知识，而是能够实时地查阅和利用专门的、最新的、精确的知识库内容，从而大大提升 LLM 回答的准确性、可靠性和时效性。
Dify 使用文档：
LLM 接收到用户的问题后，将首先基于关键词在知识库内检索内容。知识库将根据关键词，召回相关度排名较高的内容区块，向 LLM 提供关键上下文以辅助其生成更加精准的回答。
此处提及的“关键词”即指下图中的“查询变量”，知识检索将根据查询变量，在知识库内检索相似度最高的内容段。而召回是指在用户提出问题时，知识库系统根据用户问题，从海量的知识库中检索出最相关的少量内容分段的过程。
（点击图片可放大查看）
在知识库检索过程中，向量化召回机制本质上是一种语义相关性匹配，而非事实判断或逻辑判断。这意味着，「知识检索」在接收到用户查询后，会将其转化为向量，并与知识库中已向量化的文本内容进行相似度匹配。凡是与查询内容语义上接近的段落，都会被召回，即使这些段落所表达的具体观点与用户输入存在冲突或不符。
举例来说，假设知识库中有一段明确说明：“不适用于个人借款合同”；而用户的查询变量是“如何判断个人借款合同的效力？”。由于“个人借款合同”这一关键词在语义上高度相关，该段内容可能仍会被向量检索模块召回。此时，检索模块并不会判断该段内容是否适用于当前问题情境，它只是基于向量相似度选出“看起来可能有用”的内容。
真正对上下文进行理解、筛选和判断的，是 LLM。在收到这些候选知识片段后，LLM 会结合用户问题的具体语境，进行逻辑分析和事实判断，决定哪些信息应被采纳、哪些应被忽略，并据此生成最终回答。
因此，在知识库驱动的问答系统中，检索模块与语言模型之间形成了明确的分工：检索只负责定位可能相关的知识，而判断是否真的适用的任务，交由语言模型完成。
特别需要注意的是：
查询变量不是越详细越好，而只需要保留关键的用于查询的信息。一长串的信息输入可能会误导检索过程，因为不重要的信息也会被向量化，从而影响到查询变量与知识库信息的匹配。
如果上游节点输出内容过长的话，可以利用「代码执行」（见“9. 代码执行”）或「变量提取器」（见“10. 其他节点”）提取合同关键信息，并只将这部分信息用于查询。
二、「知识检索」的单独测试
由于「知识检索」的效果高度依赖于查询变量和子段之间建立的关系，可以试着变换查询变量的不同内容观察「知识检索」能否检索到对应的子段。
比如下图中，当知识库的检索设置为向量检索的时候，对于“林木买卖”“木材采伐产品买卖”的查询变量，都能检索到名为“木材买卖”的子段，并输出对应的父段。
（点击图片可放大查看）
如果选择是全文检索，则即便查询变量和子段是完全相同的意思，但只要语句不相同，也无法被检索出来。此时要么调整子段名称或输入变量，要么更换检索方式。
（点击图片可放大查看）
三、在 LLM 中调用知识检索结果
知识库的检索结果一般都会输入给 LLM 用于生成答复。不过如果直接在「LLM」的提示词中插入变量，会发现列表中并没有找到「知识检索」的输出变量。这是因为，在
「LLM」的节点配置界面中的“上下文”设置即可用于解决该问题。「知识检索」的输出变量 result 需要配置在「LLM」中的“上下文变量”内关联赋值。在“上下文”处勾选变量之后，便可以在提示词的合适位置中插入 Context 来调用知识库的查询结果。
需注意，“上下文”中只能选择一个变量，该变量在提示词中也只能被调用一次。
（点击图片可放大查看）
如果用户的提问在「知识检索」中召回了相关文本，则文本内容会作为上下文变量中的值填入提示词，提供给 LLM 回复问题；若未在知识库检索中召回相关的文本，则上下文变量值为空，LLM 则会直接回复用户问题。
引申理解：
「LLM」中的“上下文”可用于解决如何在提示词中插入 Array 格式的变量的问题，「知识检索」的输出结果是典型。但如果想要输入其他 Array 格式的变量，比如「迭代」中的 Array 格式的输出结果，除了通过「代码执行」进行将 Array 格式转换成 String 格式外，也可以通过此方式调用。
为了方便文档的分段并提高检索效果，文档预处理是至关重要的一环，甚至比单纯调整 Dify 知识库的分段参数更有效。作为一家内容生产公司，法天使在 Dify 知识库文档预处理方面也颇有经验，下面是一些我们在整理知识库过程中总结的经验和方法。
一、父子段模式下确定父子段
在整理知识之前，我们需要明确我们希望通过知识整理实现的目的，通过检索什么字段导出什么上下文，用于什么判断。
对于上图显示的 TXT 文档的文本。其中的父子段是让人困惑的。实际上，那并不是一个好的预处理文本。
如果希望实现根据“一次合同”、“持续合同”、“框架合同”来分别输出参考内容，应当整理成下图右列的形式，这样“一次合同”、“持续合同”、“框架合同”分别作为检索字段，其中的各类条款整体作为父段输出。应用场景可以是，在上游节点判断合同属于“一次合同”、“持续合同”、“框架合同”中的哪一类之后，通过「知识检索」分别导出对应的条款要求，再对原合同予以修改。
（点击图片可放大查看）
最终知识库处理好的页面如下：
（点击图片可放大查看）
二、父子段的再编辑方法
通用设置中不区分子段和父段，整个段落将同时作为检索字段和召回字段。父子模式中，只有子块用于检索，父块整体作为上下文导出。当子块匹配查询时，会同时将对应的父块作为上下文提供给 LLM，以补充完整背景信息。父子模式将会实现更高效的检索和输出，下文是对父子模式下的知识库编辑的介绍。
1.删除多余子段。
在 Dify 知识库中配置父子分段时，所有内容一定会拆分成子段，而父段是所有子段的集合。但这有一个问题，我们知道，子段是用于检索的，问题是并不是所有子段都需要作为检索子段。此时，在 Dify 知识库索引完文档之后，我们需要手动对知识库的分段进行调整。
下图中我们上传了一个合同无效情形的文档，此时已经按照父子分段设置好。在父段-02中有5个子段：
C-1是合同无效的结论，不适宜作为检索字段，因为知识库仅仅负责检索，而不应当用它来做实质判断。
C-2是特定违法无效情形的描述，是一个理想的检索字段，判断上传的合同文本和这个违法无效情形的相似程度。
C-3是涉及的合同类型，也可以用于检索字段，由知识库对上传合同的合同类型和这里的相关合同的相似度进行判断。
C-4是隐藏的法律风险，不适宜作为检索字段，而应当作为上下文输出。
C5是可替代的交易结构，同样不适宜作为检索字段，而应当作为上下文输出。
（点击图片可放大查看）
此时，我们可以手动删除C-1，C-4，C-5，子分段的修改不会导致父段的修改。最终的知识库整理效果如下：
（点击图片可放大查看）
对于其他的字段，也可以按照同样的方式修改。这样的知识库的检索将会更加高效和准确。
2.精简子段。
子段不应该是一句定义，而应该是一个直接明了的短语或句子。因为 Embedding 模型不会通过理解这个定义的方式来对比查询变量。举个例子，我们的查询变量应该是“离婚协议”，而不应该是“夫妻或家庭成员之间，基于平等自愿原则，就财产、子女抚养、家庭事务等权利义务关系达成的书面约定”，如果我们希望能涵盖更多的合同类型，则可以在子段分别列举，如离婚协议、夫妻财产约定种种，而不建议使用定义作为子段。
子段不建议放太多不同的内容，会影响子段的向量位置。比如一个合同类型就作为一个子段，多个合同类型分别作为子段，除非这些合同名称都是一类合同的表达。
三、表格的预处理
如果是表格，可以直接上传，选择“;”作为子段的分段标识符，父段的分段标识符保持“\n\n”不变。比如下面上传的一个《三观四步法》的表格，不同行之间的数据，以及同一行内部的单元格的数据之间都自动作了区分。
（点击图片可放大查看）
但更建议将表格处理成 txt 文档格式，下面是上传 xlsx 文件后的父段示例：
类型":"批准";"细分":"具体交易类批准";"说明":"针对某一项具体交易的批准，例如《商业银行法》（2015年修正）第28条规定“购买商业银行5%以上股权”需经批准"
可以看到所有单元格内容被放在了一段，一旦单元格内容变多，许多内容会杂糅在一起，不方便后续的修改和更新。
此时可以让 AI 进行预处理（不过要测试 AI 是否能理解上传的文档，并且没有遗漏的生成文本），如下图所示：
（点击图片可放大查看）
再将这个文档上传至知识库当中。
四、流程图的预处理
为了确保「知识检索」的检索精度，需要将流程图转换为文本格式，而不是直接以图片形式上传。图片格式不利于智能体进行内容理解和检索，而文本格式则能更精准地提取和匹配信息。具体选择何种文本格式，则取决于希望智能体如何检索和利用这些流程图所呈现的信息。
1.检索目的是获取整个流程图。
如果希望智能体能够一次性输出整个流程的全貌。在这种情况下，将流程图转换为 Mermaid 格式是最佳选择。Mermaid 是一种基于文本的绘图语言，可以直接在 Markdown 中渲染出流程图。这样，既能以结构化文本的形式存储流程图，又能轻松地在需要时将其可视化。
处理方法：在知识库选择父子分段模式，将完整的 Mermaid 流程图代码作为父段，并将流程图的名称或关键信息作为子段。这样，「知识检索」运行时，可以通过流程图的名称快速定位到完整的 Mermaid 代码，并直接输出。
2.检索目的是获取流程中的具体节点或步骤。
如果希望智能体能够精确地输出流程图中的某个具体步骤或决策点。在这种情况下，将流程图转换为纯文本或结构化 Markdown 格式是更好的选择。
处理方法：使用自然语言详细描述每个步骤，可以采用列表、编号或分级标题的方式。例如，将每个流程步骤作为一个独立的小段落，并用清晰的标题概括其内容。这样，智能体就能根据用户的具体问题，精准匹配并返回相关的步骤信息，而不是整个流程图。
3.检索目的是获取流程中关键属性。
如果主要关注的是流程的关键属性（如每个步骤的负责人、耗时、输入/输出），那么将流程图转换为表格形式是一个可行的方案。
处理方法：创建一个表格，将流程的每个步骤作为一行，并设置多列来记录关键属性，例如：“步骤名称”、“负责人”、“开始条件”、“产出物”等。这种方式的优点是结构化程度高，便于进行字段级检索和数据分析。但需要注意，表格形式难以直观表达复杂的条件分支和循环逻辑，因此更适用于流程简单、线性的场景。
目前，市面上大多数 AI 工具都能够实现上面所列出的流程图转换，这对 AI 来说，是个相对简单的任务。但需要注意的是，在转换的过程中，一定要仔细检查 AI 的输出结果是否与流程图完全一致。
五、文档整理策略
1.内容清晰化。
知识库的文档应当使用简洁明了的语言，避免冗长、复杂的句子。确保每个句子和段落的含义清晰，没有歧义。并移除不相关内容。比如，“法天使-中国合同库”只关注合同相关的，因此，在整理法律知识点的时候，会剔除与合同无关的法律内容，提高检索的效率。
2.分隔标准化。
最重要的就是统一分隔符。比如，不同段落之间，统一使用双换行符 \n\n 来分隔不同的自然段落。这将使得 Dify 知识库在父子分段模式下，更容易将每个自然段识别为一个完整的父区块。
3.结构化处理表格。
表格算是一种常用的数据整理格式。在使用表格的时候，需要特别注意拆分合并单元格并填充重复内容。合并单元格会破坏表格的逻辑结构，使得系统难以理解数据项的对应关系，请务必拆分合并的单元格。每个单元格都应独立包含内容，即将原内容一一复制到各个单元格中。例如，如果一类合同对应多个场景，需要在每个场景前面加上该合同名称，而不能用合并单元格。
比如，《民法典》第497条规定了格式条款无效的三种情形。出于美观考虑，我们一般会整理成如下格式。
（点击图片可放大查看）
但是这种格式，并不利于AI进行理解。而应当把合并的单元格拆分，并且在合并后的单元格当中，复制相同的内容。
（点击图片可放大查看）
但是这种处理仍然不够，因为第一行格式条款无效情形并没有直接列明，而是指向其他法条。此时，应当把它的具体内容列明。
（点击图片可放大查看）
精简之后可以形成如下表格：
（点击图片可放大查看）
这种罗列更加清晰了，但也并不意味着是最佳的知识整理。如果“法天使-中国合同库”来整理，还会整理成如下格式，这里把所有“民事法律行为”的表述换成了“交易”，因为“法天使-中国合同库”专注于合同领域，因此，交易的表述比民事法律行为更加符合法天使产品的应用场景，必要时，我们也会为每个情形提供合同类型。
（点击图片可放大查看）
知识点的整理不会是终局的，随着法律的修订，或者新法的推出，知识库文档一直处于不断完善当中。
如果你希望在本文的基础上，进一步系统了解“大模型 + 工作流 + 知识库”如何结合起来服务法律业务，可以参考：《法律智能体（Agent）搭建指南：以 Dify、扣子为例快速入门》。
本书由法天使智能法务部编写，面向不具计算机背景的法律人，介绍如何以 LLM 为基础，通过工作流和知识库搭建出可控、可用的法律智能体，让AI在合同审查、合规管理等场景中真正发挥“勤勉助理”的作用。
欢迎点击下方图书链接了解更多。