尧图网页设计 
简介这份PPT课件面向希望掌握大模型微调语料自动化构建的开发者与AI应用实践者围绕Dify平台展开从概念到落地的全流程教学。内容涵盖大模型微调与语料工程核心价值、传统语料构建痛点与Dify解决方案、Dify工具与工作流架构解析以及微调语料工作流的实战搭建具体拆解开始节点、文档提取器、代码执行、LLM节点与结束节点五个环节的配置方法并给出测试验证与语料质量评估思路。资源包共1个pptx文件大小约15.21MB以图文课件形式呈现便于按章节系统学习与查阅。目前已有110人学习。读者可借此理解如何用低代码可视化工作流完成文档输入、自动处理、智能生成到标准JSONL输出的闭环掌握语料相关性、准确性与多样性的评估要点降低微调语料工程的技术门槛。1. 从一份 PPT 说起Dify 工作流怎么把小说文本变成微调语料很多人第一次接触大模型微调卡住的地方不是训练脚本而是语料。手里有一堆 PDF、TXT、Word 文档想做成{messages: [...]}这种 JSONL 格式要么写 Python 脚本硬啃要么人工复制粘贴标注成本能占到整个项目七成以上。这份《基于 Dify 的大模型微调语料自动化构建实战课程》PPT讲的就是用 Dify 的可视化工作流把「文档输入 → 自动处理 → 智能生成 → 标准输出」串成一条闭环全程拖拽不写一行训练代码。它适合两类人一类是想给自己的垂直领域模型喂私域语料、但不想深陷脚本工程的从业者另一类是已经会用 Dify 搭简单问答、想进一步理解工作流节点参数怎么配、上下文超长怎么截、JSONL 格式怎么卡死的熟手。整份材料围绕 5 个节点展开开始、文档提取器、代码执行、LLM、结束案例用的是《少年歌行》小说 TXT最终产出 17 条规范 JSONL。下面我按自己复现的路径把每个节点的参数、坑和验证方法拆开讲。2. Dify 工作流五节点架构从 attachments 到 JSONL 的数据流2.1 为什么选 Dify 而不是自己写脚本传统语料构建的痛点很集中人工标注贵、Python JSONL 格式门槛高、不同工具间格式转换容易出错。Dify 的定位是开源 LLM 应用开发平台核心能力是工作流可视化搭建、插件扩展、多模型集成。放到语料构建这个场景里它真正省事的地方有三个文档提取器直接吃 PDF/TXT不用自己写解析代码执行节点可以塞一小段 Python 做文本合并和截断LLM 节点负责按提示词生成问答对最后结束节点直接吐 JSONL 文件供下载。选型上要注意Dify 社区版和云版本在插件安装、模型接入上略有差异本地部署教程网上很多但如果你只是跑语料工作流社区版足够。模型侧 PPT 用的是 SiliconCloud 的 Qwen2.5-72B-Instruct-128K这个选择合理128K 上下文能吞下较长文档72B 参数量在问答对生成质量上比小模型稳。如果你本地有 GPU 微调大模型的环境也可以换成自己部署的模型但要注意 Dify 接入本地大模型时 API 兼容性常见做法是走 OpenAI 兼容接口。2.2 五节点闭环的数据流拆解整个工作流的骨架是开始 → 文档提取器 → 代码执行 → LLM → 结束。每个节点的输入输出必须对齐否则后面节点拿不到数据。下面按我复现时的配置顺序说。开始节点配两个输入参数参数名类型必填作用attachments文件列表是上传待处理文档如小说 TXTtrigger字符串是触发词作为 system prompt 的一部分文档提取器节点把attachments数组绑进来输出提取后的文本内容类型是 text 数组。这一步的坑在于如果上传的是扫描版 PDF提取出来可能是空或乱码PPT 案例用 TXT 就是为了避开 OCR 问题。代码执行节点接收articleSections文档 text 数组做两件事合并文本、截取前 80000 字符。为什么是 80000因为 Qwen2.5-72B 虽然标称 128K但实际留给输出的空间、提示词本身占用的 token 都要算进去80000 字符是个保守值能防止上下文超长导致请求失败。输出truncated_text。LLM 节点拿truncated_text加trigger系统提示词里定义 JSONL 格式用户提示词传入文本和触发词。输出就是 JSONL 格式的语料文本。结束节点把 LLM 输出的 text 作为变量输出标准 JSONL 文件支持直接下载。提示五个节点里最容易翻车的是代码执行和 LLM 的衔接。代码节点输出的变量名必须和 LLM 节点里引用的变量名完全一致大小写都不能错否则 LLM 节点会拿到空值生成一堆无意义内容。3. 实战搭建文档提取器与代码执行节点的参数配置3.1 开始节点与文档提取器的绑定细节开始节点本身没什么可调的关键是attachments的类型要选文件列表不是单个文件。很多人第一次配的时候选成 string结果文档提取器绑不上。trigger我一般写成一句明确的角色定义比如案例里的「你是少年歌行小说专家」它会被拼进 system prompt影响 LLM 生成问答对的风格和领域聚焦。文档提取器节点的配置就一步输入变量绑定attachments数组。输出是 text 数组每个上传文件对应一段文本。这里有个隐藏问题如果你一次上传多个文件输出数组会有多段代码执行节点要能处理数组而不是单个字符串。PPT 案例是单文件所以没暴露这个问题但实际做知识库流水线时经常批量上传代码里得加循环或 join。3.2 代码执行节点合并与截断的 Python 实现代码执行节点是整条工作流里唯一需要写代码的地方但逻辑很简单。下面是我复现时用的代码和 PPT 描述的功能一致def main(articleSections: list[str]) - dict: # 将文档提取器输出的多段文本合并为一个字符串 # 用换行符连接保留段落边界避免问答对跨段错乱 merged_text \n.join(articleSections) # 截取前 80000 字符防止 LLM 上下文超长 # 80000 是保守值Qwen2.5-72B 标称 128K但要留出提示词和输出空间 max_chars 80000 truncated_text merged_text[:max_chars] # 返回字典键名必须与下游 LLM 节点引用的变量名一致 return { truncated_text: truncated_text }逻辑说明articleSections是文档提取器输出的 text 数组直接 join 成一段。截断用切片简单粗暴但有效。参数max_chars可以根据你用的模型调整如果换成上下文更小的模型比如 32K建议降到 20000 字符左右如果用 128K 模型且提示词很短可以试到 100000但别贴着上限跑留 20% 余量。返回的字典键名truncated_text就是下游 LLM 节点里要引用的变量名。Dify 的代码节点对返回类型有要求必须是 dict且值要是可序列化的。如果你返回了 list 或其他类型节点会报错。注意代码执行节点里不要做太重的计算Dify 对代码节点的执行时间有限制合并和截断这种 O(n) 操作没问题但别在里面跑模型推理或大文件 IO。3.3 LLM 节点的提示词工程把 JSONL 格式卡死LLM 节点是整个工作流的质量瓶颈。PPT 里模型选的是 SiliconCloud Qwen2.5-72B-Instruct-128K提示词分 system 和 user 两部分。System prompt 的核心任务是定义输出格式我一般会写成这样你是一个微调语料生成助手。根据用户提供的文本和触发词生成符合以下 JSONL 格式的问答对 {messages: [{role: system, content: 触发词}, {role: user, content: 问题}, {role: assistant, content: 解答}]} 要求 1. 每条 JSONL 占一行行内是合法 JSON。 2. 问题要通俗解答要准确基于原文内容。 3. 不要输出任何解释性文字只输出 JSONL 行。User prompt 里传入truncated_text和trigger。这里的关键是「只输出 JSONL 行」这句约束不加的话模型很容易在前面加一段「好的以下是生成的语料」导致结束节点下载的文件第一行不是合法 JSON后续训练脚本解析直接报错。参数上temperature 建议调低0.3 到 0.5 之间太高会让问答对发散太低会重复。max_tokens 根据你要生成多少条问答对来设案例生成 17 条每条大概 200 token设 4096 够用。如果文档长、想要更多问答对可以调高但注意别超过模型输出上限。4. 避坑与排查JSONL 格式、上下文超长和变量绑定4.1 生成的 JSONL 第一行不是合法 JSON现象结束节点下载的文件用jsonlines库读取时报json.decoder.JSONDecodeError打开看第一行是「以下是生成的语料」之类的自然语言。原因LLM 节点没有严格约束输出格式模型习惯性加了前言。System prompt 里虽然写了格式但模型有时会忽略。解决在 system prompt 末尾加一句「不要输出任何解释性文字直接从第一行开始就是 JSONL」并且在 LLM 节点后加一个代码执行节点做清洗用正则去掉非{开头的行。我一般会在工作流里固定加这个清洗步骤比反复调提示词稳。4.2 上下文超长导致 LLM 节点报错现象LLM 节点执行失败日志里出现 token 超限或context length exceeded之类的错误。原因代码执行节点截断的 80000 字符在中文里大约对应 40000 到 60000 token加上 system prompt 和输出预留如果模型实际可用上下文小于这个数就会超。解决先确认你用的模型真实上下文窗口。Qwen2.5-72B-Instruct-128K 标称 128K但 SiliconCloud 的 API 可能有额外限制。把max_chars降到 50000 试如果还报错就继续降。另一个办法是在代码节点里按 token 数截断而不是字符数用 tiktoken 估算但 Dify 代码节点不一定装了 tiktoken所以字符截断更通用。4.3 变量绑定错误导致下游拿到空值现象LLM 节点输出为空或者代码执行节点报KeyError。原因Dify 工作流里每个节点的输出变量名是固定的代码节点返回的 dict 键名如果和下游引用的不一致下游就拿不到值。常见的是代码节点返回truncated_text但 LLM 节点里引用的是text。解决在 Dify 的变量选择器里不要手动输入变量名直接从上游节点的输出列表里点选。手动输入容易拼错或大小写不一致。每次改完代码节点的返回键名都要回去检查 LLM 节点的引用。4.4 文档提取器对 PDF 的兼容性问题现象上传 PDF 后文档提取器输出为空或乱码。原因Dify 的文档提取器对文本型 PDF 支持较好但扫描版 PDF 是图片提取不出文字。另外有些 PDF 编码特殊提取出来是乱码。解决优先用 TXT 或文本型 PDF。如果是扫描版先走 OCR 工具转成文本再上传。PPT 案例用《少年歌行》TXT 就是最稳的路径。做知识库流水线时我一般会在文档提取器前加一个格式判断但 Dify 原生节点做这个比较绕简单做法是人工预处理。4.5 生成语料的质量评估缺失现象JSONL 格式没问题但问答对质量差问题不通俗或解答偏离原文。原因LLM 节点只约束了格式没约束内容质量。模型可能生成泛泛而谈的问答或者把原文里不重要的细节当成重点。解决在 system prompt 里加质量要求比如「问题要基于原文关键情节解答要引用原文事实」。另外PPT 里提到的测试验证环节不能省拿生成结果人工抽检几条看问题通俗性、解答准确性、格式规范性。如果质量不达标调 temperature 或换更大的模型。我一般会先用小样本跑一轮确认提示词有效再全量跑。5. 进阶技巧把语料工作流接进微调流水线工作流跑通、JSONL 下载下来只是第一步。真正做微调时语料还要过几道关。我一般会在 Dify 工作流后面接一个本地脚本做格式校验和去重。下面这段 Python 是我常用的校验逻辑import json import hashlib def validate_jsonl(file_path: str) - dict: seen set() valid_count 0 duplicate_count 0 error_lines [] with open(file_path, r, encodingutf-8) as f: for i, line in enumerate(f, 1): line line.strip() if not line: continue try: obj json.loads(line) # 校验 messages 结构 assert messages in obj assert len(obj[messages]) 3 # 用 user 内容做去重指纹 user_content obj[messages][1][content] fingerprint hashlib.md5(user_content.encode()).hexdigest() if fingerprint in seen: duplicate_count 1 continue seen.add(fingerprint) valid_count 1 except Exception as e: error_lines.append((i, str(e))) return { valid: valid_count, duplicates: duplicate_count, errors: error_lines }这段代码做三件事逐行解析 JSON、校验 messages 结构是否为三条、用 user 内容做 MD5 去重。参数上len(obj[messages]) 3对应 system/user/assistant 三条如果你的格式不同要改。去重指纹用 user 内容因为同一问题不同解答也算重复语料训练时会引入偏差。校验通过后语料就可以喂给微调框架了。如果你用的是 LLaMA-Factory 或 Axolotl它们对 JSONL 格式的要求和 Dify 输出基本兼容但要注意字段名有些框架要求instruction/input/output而不是messages这时候需要再加一个转换脚本。我一般会在 Dify 工作流的结束节点后本地跑一个格式转换把messages映射成框架需要的字段。另一个进阶用法是把 Dify 工作流做成 API用定时任务批量处理文档。Dify 支持把工作流发布为 API你可以用 Python 脚本调用传入文件路径和 trigger拿回 JSONL。这样就能接进知识库流水线新文档进来自动生成语料不用每次手动上传下载。但要注意 API 调用的并发限制和超时设置大文档处理时间较长建议异步跑。从那以后我每次搭语料工作流都会先在代码执行节点里把截断阈值调低跑一遍小样本确认 JSONL 格式和问答质量都过关再放开全量。这个习惯帮我省了很多次重新生成的时间。希望帮到你。本文还有配套的精品资源点击获取 基于Dify的大模型微调语料自动化构建实战：从文档到JSONL工作流
简介这份PPT课件面向希望掌握大模型微调语料自动化构建的开发者与AI应用实践者围绕Dify平台展开从概念到落地的全流程教学。内容涵盖大模型微调与语料工程核心价值、传统语料构建痛点与Dify解决方案、Dify工具与工作流架构解析以及微调语料工作流的实战搭建具体拆解开始节点、文档提取器、代码执行、LLM节点与结束节点五个环节的配置方法并给出测试验证与语料质量评估思路。资源包共1个pptx文件大小约15.21MB以图文课件形式呈现便于按章节系统学习与查阅。目前已有110人学习。读者可借此理解如何用低代码可视化工作流完成文档输入、自动处理、智能生成到标准JSONL输出的闭环掌握语料相关性、准确性与多样性的评估要点降低微调语料工程的技术门槛。1. 从一份 PPT 说起Dify 工作流怎么把小说文本变成微调语料很多人第一次接触大模型微调卡住的地方不是训练脚本而是语料。手里有一堆 PDF、TXT、Word 文档想做成{messages: [...]}这种 JSONL 格式要么写 Python 脚本硬啃要么人工复制粘贴标注成本能占到整个项目七成以上。这份《基于 Dify 的大模型微调语料自动化构建实战课程》PPT讲的就是用 Dify 的可视化工作流把「文档输入 → 自动处理 → 智能生成 → 标准输出」串成一条闭环全程拖拽不写一行训练代码。它适合两类人一类是想给自己的垂直领域模型喂私域语料、但不想深陷脚本工程的从业者另一类是已经会用 Dify 搭简单问答、想进一步理解工作流节点参数怎么配、上下文超长怎么截、JSONL 格式怎么卡死的熟手。整份材料围绕 5 个节点展开开始、文档提取器、代码执行、LLM、结束案例用的是《少年歌行》小说 TXT最终产出 17 条规范 JSONL。下面我按自己复现的路径把每个节点的参数、坑和验证方法拆开讲。2. Dify 工作流五节点架构从 attachments 到 JSONL 的数据流2.1 为什么选 Dify 而不是自己写脚本传统语料构建的痛点很集中人工标注贵、Python JSONL 格式门槛高、不同工具间格式转换容易出错。Dify 的定位是开源 LLM 应用开发平台核心能力是工作流可视化搭建、插件扩展、多模型集成。放到语料构建这个场景里它真正省事的地方有三个文档提取器直接吃 PDF/TXT不用自己写解析代码执行节点可以塞一小段 Python 做文本合并和截断LLM 节点负责按提示词生成问答对最后结束节点直接吐 JSONL 文件供下载。选型上要注意Dify 社区版和云版本在插件安装、模型接入上略有差异本地部署教程网上很多但如果你只是跑语料工作流社区版足够。模型侧 PPT 用的是 SiliconCloud 的 Qwen2.5-72B-Instruct-128K这个选择合理128K 上下文能吞下较长文档72B 参数量在问答对生成质量上比小模型稳。如果你本地有 GPU 微调大模型的环境也可以换成自己部署的模型但要注意 Dify 接入本地大模型时 API 兼容性常见做法是走 OpenAI 兼容接口。2.2 五节点闭环的数据流拆解整个工作流的骨架是开始 → 文档提取器 → 代码执行 → LLM → 结束。每个节点的输入输出必须对齐否则后面节点拿不到数据。下面按我复现时的配置顺序说。开始节点配两个输入参数参数名类型必填作用attachments文件列表是上传待处理文档如小说 TXTtrigger字符串是触发词作为 system prompt 的一部分文档提取器节点把attachments数组绑进来输出提取后的文本内容类型是 text 数组。这一步的坑在于如果上传的是扫描版 PDF提取出来可能是空或乱码PPT 案例用 TXT 就是为了避开 OCR 问题。代码执行节点接收articleSections文档 text 数组做两件事合并文本、截取前 80000 字符。为什么是 80000因为 Qwen2.5-72B 虽然标称 128K但实际留给输出的空间、提示词本身占用的 token 都要算进去80000 字符是个保守值能防止上下文超长导致请求失败。输出truncated_text。LLM 节点拿truncated_text加trigger系统提示词里定义 JSONL 格式用户提示词传入文本和触发词。输出就是 JSONL 格式的语料文本。结束节点把 LLM 输出的 text 作为变量输出标准 JSONL 文件支持直接下载。提示五个节点里最容易翻车的是代码执行和 LLM 的衔接。代码节点输出的变量名必须和 LLM 节点里引用的变量名完全一致大小写都不能错否则 LLM 节点会拿到空值生成一堆无意义内容。3. 实战搭建文档提取器与代码执行节点的参数配置3.1 开始节点与文档提取器的绑定细节开始节点本身没什么可调的关键是attachments的类型要选文件列表不是单个文件。很多人第一次配的时候选成 string结果文档提取器绑不上。trigger我一般写成一句明确的角色定义比如案例里的「你是少年歌行小说专家」它会被拼进 system prompt影响 LLM 生成问答对的风格和领域聚焦。文档提取器节点的配置就一步输入变量绑定attachments数组。输出是 text 数组每个上传文件对应一段文本。这里有个隐藏问题如果你一次上传多个文件输出数组会有多段代码执行节点要能处理数组而不是单个字符串。PPT 案例是单文件所以没暴露这个问题但实际做知识库流水线时经常批量上传代码里得加循环或 join。3.2 代码执行节点合并与截断的 Python 实现代码执行节点是整条工作流里唯一需要写代码的地方但逻辑很简单。下面是我复现时用的代码和 PPT 描述的功能一致def main(articleSections: list[str]) - dict: # 将文档提取器输出的多段文本合并为一个字符串 # 用换行符连接保留段落边界避免问答对跨段错乱 merged_text \n.join(articleSections) # 截取前 80000 字符防止 LLM 上下文超长 # 80000 是保守值Qwen2.5-72B 标称 128K但要留出提示词和输出空间 max_chars 80000 truncated_text merged_text[:max_chars] # 返回字典键名必须与下游 LLM 节点引用的变量名一致 return { truncated_text: truncated_text }逻辑说明articleSections是文档提取器输出的 text 数组直接 join 成一段。截断用切片简单粗暴但有效。参数max_chars可以根据你用的模型调整如果换成上下文更小的模型比如 32K建议降到 20000 字符左右如果用 128K 模型且提示词很短可以试到 100000但别贴着上限跑留 20% 余量。返回的字典键名truncated_text就是下游 LLM 节点里要引用的变量名。Dify 的代码节点对返回类型有要求必须是 dict且值要是可序列化的。如果你返回了 list 或其他类型节点会报错。注意代码执行节点里不要做太重的计算Dify 对代码节点的执行时间有限制合并和截断这种 O(n) 操作没问题但别在里面跑模型推理或大文件 IO。3.3 LLM 节点的提示词工程把 JSONL 格式卡死LLM 节点是整个工作流的质量瓶颈。PPT 里模型选的是 SiliconCloud Qwen2.5-72B-Instruct-128K提示词分 system 和 user 两部分。System prompt 的核心任务是定义输出格式我一般会写成这样你是一个微调语料生成助手。根据用户提供的文本和触发词生成符合以下 JSONL 格式的问答对 {messages: [{role: system, content: 触发词}, {role: user, content: 问题}, {role: assistant, content: 解答}]} 要求 1. 每条 JSONL 占一行行内是合法 JSON。 2. 问题要通俗解答要准确基于原文内容。 3. 不要输出任何解释性文字只输出 JSONL 行。User prompt 里传入truncated_text和trigger。这里的关键是「只输出 JSONL 行」这句约束不加的话模型很容易在前面加一段「好的以下是生成的语料」导致结束节点下载的文件第一行不是合法 JSON后续训练脚本解析直接报错。参数上temperature 建议调低0.3 到 0.5 之间太高会让问答对发散太低会重复。max_tokens 根据你要生成多少条问答对来设案例生成 17 条每条大概 200 token设 4096 够用。如果文档长、想要更多问答对可以调高但注意别超过模型输出上限。4. 避坑与排查JSONL 格式、上下文超长和变量绑定4.1 生成的 JSONL 第一行不是合法 JSON现象结束节点下载的文件用jsonlines库读取时报json.decoder.JSONDecodeError打开看第一行是「以下是生成的语料」之类的自然语言。原因LLM 节点没有严格约束输出格式模型习惯性加了前言。System prompt 里虽然写了格式但模型有时会忽略。解决在 system prompt 末尾加一句「不要输出任何解释性文字直接从第一行开始就是 JSONL」并且在 LLM 节点后加一个代码执行节点做清洗用正则去掉非{开头的行。我一般会在工作流里固定加这个清洗步骤比反复调提示词稳。4.2 上下文超长导致 LLM 节点报错现象LLM 节点执行失败日志里出现 token 超限或context length exceeded之类的错误。原因代码执行节点截断的 80000 字符在中文里大约对应 40000 到 60000 token加上 system prompt 和输出预留如果模型实际可用上下文小于这个数就会超。解决先确认你用的模型真实上下文窗口。Qwen2.5-72B-Instruct-128K 标称 128K但 SiliconCloud 的 API 可能有额外限制。把max_chars降到 50000 试如果还报错就继续降。另一个办法是在代码节点里按 token 数截断而不是字符数用 tiktoken 估算但 Dify 代码节点不一定装了 tiktoken所以字符截断更通用。4.3 变量绑定错误导致下游拿到空值现象LLM 节点输出为空或者代码执行节点报KeyError。原因Dify 工作流里每个节点的输出变量名是固定的代码节点返回的 dict 键名如果和下游引用的不一致下游就拿不到值。常见的是代码节点返回truncated_text但 LLM 节点里引用的是text。解决在 Dify 的变量选择器里不要手动输入变量名直接从上游节点的输出列表里点选。手动输入容易拼错或大小写不一致。每次改完代码节点的返回键名都要回去检查 LLM 节点的引用。4.4 文档提取器对 PDF 的兼容性问题现象上传 PDF 后文档提取器输出为空或乱码。原因Dify 的文档提取器对文本型 PDF 支持较好但扫描版 PDF 是图片提取不出文字。另外有些 PDF 编码特殊提取出来是乱码。解决优先用 TXT 或文本型 PDF。如果是扫描版先走 OCR 工具转成文本再上传。PPT 案例用《少年歌行》TXT 就是最稳的路径。做知识库流水线时我一般会在文档提取器前加一个格式判断但 Dify 原生节点做这个比较绕简单做法是人工预处理。4.5 生成语料的质量评估缺失现象JSONL 格式没问题但问答对质量差问题不通俗或解答偏离原文。原因LLM 节点只约束了格式没约束内容质量。模型可能生成泛泛而谈的问答或者把原文里不重要的细节当成重点。解决在 system prompt 里加质量要求比如「问题要基于原文关键情节解答要引用原文事实」。另外PPT 里提到的测试验证环节不能省拿生成结果人工抽检几条看问题通俗性、解答准确性、格式规范性。如果质量不达标调 temperature 或换更大的模型。我一般会先用小样本跑一轮确认提示词有效再全量跑。5. 进阶技巧把语料工作流接进微调流水线工作流跑通、JSONL 下载下来只是第一步。真正做微调时语料还要过几道关。我一般会在 Dify 工作流后面接一个本地脚本做格式校验和去重。下面这段 Python 是我常用的校验逻辑import json import hashlib def validate_jsonl(file_path: str) - dict: seen set() valid_count 0 duplicate_count 0 error_lines [] with open(file_path, r, encodingutf-8) as f: for i, line in enumerate(f, 1): line line.strip() if not line: continue try: obj json.loads(line) # 校验 messages 结构 assert messages in obj assert len(obj[messages]) 3 # 用 user 内容做去重指纹 user_content obj[messages][1][content] fingerprint hashlib.md5(user_content.encode()).hexdigest() if fingerprint in seen: duplicate_count 1 continue seen.add(fingerprint) valid_count 1 except Exception as e: error_lines.append((i, str(e))) return { valid: valid_count, duplicates: duplicate_count, errors: error_lines }这段代码做三件事逐行解析 JSON、校验 messages 结构是否为三条、用 user 内容做 MD5 去重。参数上len(obj[messages]) 3对应 system/user/assistant 三条如果你的格式不同要改。去重指纹用 user 内容因为同一问题不同解答也算重复语料训练时会引入偏差。校验通过后语料就可以喂给微调框架了。如果你用的是 LLaMA-Factory 或 Axolotl它们对 JSONL 格式的要求和 Dify 输出基本兼容但要注意字段名有些框架要求instruction/input/output而不是messages这时候需要再加一个转换脚本。我一般会在 Dify 工作流的结束节点后本地跑一个格式转换把messages映射成框架需要的字段。另一个进阶用法是把 Dify 工作流做成 API用定时任务批量处理文档。Dify 支持把工作流发布为 API你可以用 Python 脚本调用传入文件路径和 trigger拿回 JSONL。这样就能接进知识库流水线新文档进来自动生成语料不用每次手动上传下载。但要注意 API 调用的并发限制和超时设置大文档处理时间较长建议异步跑。从那以后我每次搭语料工作流都会先在代码执行节点里把截断阈值调低跑一遍小样本确认 JSONL 格式和问答质量都过关再放开全量。这个习惯帮我省了很多次重新生成的时间。希望帮到你。本文还有配套的精品资源点击获取