微调数据格式详解：适配任务、模型与生态的最佳实践

一、引言：微调在垂直领域的重要性​

通用大模型虽具备强大的基础能力，却在医疗、金融、法律等专业场景中暴露出明显短板：术语混淆（如将“处方药”误作“非处方药”）、风格不符（如法律回答缺失法条引用）、逻辑偏差（如金融分析忽略关键指标）等问题频发。

微调技术正是弥合这一鸿沟的关键：通过在领域专属数据上训练，可将通用能力转化为专业能力。但微调效果高度依赖数据集的结构规范性。格式混乱、角色缺失或字段错位，都会导致模型无法正确学习“输入→输出”的映射关系，轻则训练效率低下，重则完全失效。因此，设计符合目标模型与任务类型的格式，是构建高质量垂直领域模型的基石。

二、问题切入：为什么微调数据集格式五花八门？​

对于刚接触微调的初学者而言，最直观的困惑莫过于 “开源项目的数据集格式为何如此不统一”：同样是对话微调，有的用instruction-output结构，有的用conversations数组；同样是角色定义，有的写user，有的写human。这种差异导致数据难以跨项目复用，往往需要花费大量时间修改格式，甚至因格式不兼容导致训练脚本报错。​

深究背后原因，主要源于四大核心差异：​

1. 模型架构差异：不同模型的设计逻辑决定了其对数据格式的偏好。例如，Llama 系列模型因训练时采用过 Alpaca 格式数据，对instruction input output字段的兼容性更高；而 Qwen 模型为优化多轮对话能力，更适配含role content的结构化对话格式；BERT 类模型主打文本分类、命名实体识别等任务，仅需简单的text label字段即可满足需求。​
2. 任务类型不同：任务目标的差异直接影响格式设计。单轮指令微调（如 “生成产品说明书”）只需明确 “指令 - 输出” 对应关系；多轮对话微调（如 “客服与用户的多轮交互”）则需记录角色交替顺序；思维链训练（如 “数学题解题步骤”）需额外增加推理过程字段；文本分类任务（如 “判断客户反馈是否为投诉”）仅需文本与标签的对应。​
3. 训练框架约定：不同训练框架对数据格式有默认要求。Hugging Face Transformers 库推荐使用 JSONL 格式，且字段命名需与模型的DataCollator（数据整理器）匹配；若使用自定义训练脚本，开发者可能会根据代码逻辑设计独特字段（如用question answer替代user assistant），导致格式与开源框架不兼容。​
4. 社区与生态习惯：开源社区的实践习惯会形成 “格式流派”。Alpaca 项目提出的instruction-input-output格式因简洁易用，被大量开发者借鉴；OpenAI 推出的 ChatML 格式（含system user assistant角色定义）因能精准控制模型行为，成为对话微调的主流选择之一；国内社区围绕 Qwen、ChatGLM 等模型形成的格式规范，也带有明显的本土化实践特征。​

需明确的是，格式差异并非 “错误”，而是 “适配不同需求的结果”。只有理解这些差异的根源，才能根据自身的模型选择、任务目标，设计出真正适配的数据集格式，避免盲目套用他人模板导致的问题。​

三、微调数据集格式分类详解​

3.1 对话角色关键字解析

按功能分为四类，便于根据任务需求灵活组合使用：

【基础对话角色】

• system：设定模型身份、行为规则与输出风格（如“你是执业律师，回答需引用《民法典》”）。适用于所有对话类任务，是控制领域专业性的核心字段。
• user / human：表示用户输入，提供问题、指令或上下文。不同框架命名偏好不同（Alpaca 用 user，部分自研脚本用 human），但语义一致，需在数据集中统一。
• assistant：记录模型应生成的期望输出，是微调时的学习目标。内容需严格遵循 system 约束，确保专业性与准确性。

【单轮指令任务字段】

• instruction：明确任务目标与操作要求（如“分析2024年A股新能源趋势”），常用于无需模拟用户交互的生成任务。
• input：可选字段，用于补充背景信息（如“已知装机量增长20%”），为 instruction 提供执行依据。
• output：对应 instruction 的期望响应，是单轮任务中的目标输出字段。

【推理与工具调用字段】

• think / reasoning：显式记录分步推理过程（如数学题解题步骤），用于训练思维链（CoT）能力。仅支持推理的模型（如 Llama 3、Qwen-Chat）可有效利用。
• function：定义模型可调用的工具及其参数（如天气查询接口），需与 function_result 配套使用。
• function_result：记录工具调用返回的原始数据，作为生成自然语言响应的依据，不可篡改。

【非对话类任务字段】

• text：待处理的原始文本，用于分类、标注等任务（如用户评论）。
• label：text 对应的类别或标签（如“负面反馈”），需提前定义统一标准。
• context：提供背景文档或参考信息，用于问答抽取任务。
• question：明确查询需求，需与 context 中的内容对应。
• answers：从 context 中提取的精准答案，支持多答案数组格式。

3.2 按任务类型分类的格式示例​

不同任务类型对数据格式的需求差异显著，以下将针对每种任务类型，结合 3.1 小节介绍的关键字，详细介绍其推荐格式结构、字段说明、适用场景及设计逻辑，确保字段与关键字一一对应，可直接作为实际微调中的格式模板参考。​

3.2.1 指令微调（单轮）​

单轮指令微调的核心目标是让模型根据单一指令生成对应输出，适用于无需上下文关联的独立任务。其推荐格式基于 3.1 小节的instruction、input、output字段设计，采用 “指令 - 输入 - 输出” 的三层结构，JSON 示例如下：​

{​"instruction": "作为金融分析师，分析2024年A股新能源行业趋势",​"input": "已知2024年新能源装机量同比增长20%，政策端持续加大补贴力度",​"output": "2024年A股新能源行业呈稳步增长态势：从数据端看，新能源装机量同比增长20%，反映行业需求端旺盛；从政策端看，持续补贴为企业提供了稳定的发展环境，尤其在光伏、储能细分领域，技术迭代与成本下降将进一步推动行业规模扩张。建议重点关注具备核心技术壁垒、产能布局完善的头部企业。"​}​

• instruction字段明确任务目标与模型角色，直接传递 “分析行业趋势” 的核心需求；
• input字段补充任务所需的背景数据（装机量增长、政策补贴），为instruction提供执行依据；
• output字段记录模型需学习的专业响应，与instruction形成 “需求 - 结果” 的直接对应。​

若需强化垂直领域约束，可将system字段的规则融入instruction前缀，例如将instruction改为 “你是金融分析师，需基于行业数据与政策动态分析 2024 年 A 股新能源行业趋势”，无需单独新增system字段，简化格式结构的同时，确保模型贴合领域规则。​

此类格式的典型场景包括领域文本生成（如撰写产品说明书、行业研究报告）、专业翻译（如将英文医疗文献译为中文并规范术语）、信息摘要（如提炼法律条文的核心要点）等。设计逻辑上，通过instruction+input明确任务边界与依据，用output定义学习目标，让模型快速捕捉 “任务要求 - 输入信息 - 输出目标” 的对应关系，适配单轮无上下文的任务特性。​

3.2.2 多轮对话微调​

多轮对话微调需模拟真实场景中角色交替交互的过程，核心是记录完整的对话上下文，确保模型理解多轮信息的关联性。推荐格式基于 3.1 小节的system、user、assistant字段设计，采用 “对话数组 + 角色字段” 的结构化格式，JSON 示例如下：​

{"conversations": [{"role": "system","content": "你是电商平台客服，需耐心解答用户订单问题，优先提供具体解决方案，避免模糊回复"},{"role": "user","content": "我的订单下单后3天还没发货，订单号是123456，麻烦查一下怎么回事？"},{"role": "assistant","content": "您好，已查询到您的订单（123456）对应商品为预售款，预售周期为7天，当前处于备货阶段，预计2天后发出。若您急需使用，可申请更换同品类现货商品，我可为您提供现货链接；若选择等待，发货后会通过短信告知物流单号。"},{"role": "user","content": "那我选择等待，发货后一定要及时通知我哦"},{"role": "assistant","content": "好的，已为您备注“发货后优先短信通知”，您也可通过APP“我的订单-物流跟踪”实时查看进度，有任何问题可随时联系我~"}]
}

• conversations为数组字段，每个元素包含role（角色）与content（内容）。system放在数组首位，提前设定客服角色的服务规则与风格，确保模型初始行为符合领域要求；
• user字段模拟用户的真实需求，传递订单查询、确认等待等交互指令；
• assistant字段记录模型的专业响应，与user的需求形成 “提问 - 解答” 的对应关系，且需贴合system设定的规则（如提供具体解决方案、避免模糊回复）。​

典型场景涵盖电商客服对话、医疗问诊交互（如患者与医生的多轮病情沟通）、技术支持沟通（如用户与工程师的设备故障排查对话）等。设计逻辑上，通过数组记录对话时序，用system+user+assistant的角色组合明确交互主体与规则，让模型学习 “上下文理解 - 针对性响应” 的能力，避免因信息断层导致回复偏离主题。​

3.2.3 思维链（CoT）训练​

思维链训练的核心是让模型学习 “分步推理” 能力，适用于复杂逻辑任务，需额外记录显式的推理过程。推荐格式基于 3.1 小节的instruction、think、output字段设计，在 “指令 - 输出” 基础上新增think字段，JSON 示例如下：​

{"instruction": "作为数学老师，用小学五年级知识解答应用题：某超市搞促销，3瓶饮料售价15元，买5瓶送1瓶。小明带了45元，最多能买到多少瓶饮料？","think": "第一步，计算单瓶饮料原价：已知3瓶15元，单瓶价格=15÷3=5元；第二步，确定45元可购买的基础瓶数：总金额÷单瓶价格=45÷5=9瓶；第三步，计算赠送瓶数：活动规则“买5送1”，9瓶中包含1个“5瓶”（可送1瓶），剩余4瓶不满足赠送条件；第四步，计算总瓶数：基础瓶数+赠送瓶数=9+1=10瓶；第五步，验证结果：10瓶中，9瓶为购买，1瓶为赠送，总花费=9×5=45元，符合预算。","output": "小明最多能买到10瓶饮料，具体计算过程如下：1. 单瓶饮料价格：15元÷3瓶=5元/瓶；2. 45元可购买基础瓶数：45元÷5元/瓶=9瓶；3. 赠送瓶数：满足“买5送1”，9瓶可获赠1瓶；4. 总瓶数：9瓶+1瓶=10瓶。最终花费45元，符合预算。"
}

• instruction字段明确任务目标（解答数学题）与模型角色（数学老师），传递 “用小学五年级知识” 的约束条件；
• think字段按逻辑顺序拆解推理步骤，每个步骤明确 “计算依据 - 操作过程 - 中间结果”，为模型提供 “如何思考” 的方法论，确保推理链路可追溯；
• output字段基于think过程，用更简洁的语言呈现最终结论与核心步骤，保持与推理过程的逻辑一致性，避免结果与思考脱节。​

需注意的是，think字段仅支持具备推理能力的模型（如 Llama 3、Qwen-7B-Chat），不支持推理的模型（如 BERT、早期 GPT-3.5）无需添加，添加后也无法被解析。​

典型场景包括数学题解题（如小学应用题、初中几何证明）、逻辑推理分析（如判断合同条款是否符合法律规定）、故障排查（如分析工业设备报错代码的原因）等。设计逻辑上，通过think字段向模型传递推理方法，用instruction与output固定 “任务 - 结果” 边界，让模型不仅能输出正确答案，还能理解答案的推导过程，提升复杂任务的可解释性与准确性。​

3.2.4 文本分类​

文本分类任务的目标是让模型学习 “文本 - 标签” 的映射关系，无需角色交互，格式需极简以降低模型学习负担。推荐格式基于 3.1 小节的text、label字段设计，采用 “文本 - 标签” 二元结构，JSON 示例如下：

{"text": "这款扫地机器人续航只有20分钟，打扫一半就没电了，而且吸不干净毛发，太失望了","label": "负面反馈"
}

• text字段为待分类的原始文本，需完整保留用户反馈、文档片段等原始信息，避免人工修改导致语义偏差（如示例中保留“续航只有20分钟”“吸不干净毛发”等具体负面描述，确保模型捕捉关键评价点）；
• label字段为文本对应的类别标签，需提前制定统一的标签体系——以客户反馈分类为例，可分为“正面反馈”“负面反馈”“中性反馈”三类，且标签需与文本语义严格匹配（如含“失望”“没电”等负面词汇的文本对应“负面反馈”，含“很快”“干净”等正面词汇的文本对应“正面反馈”）。

需注意的是，文本分类场景中无需添加`system`、`user`等角色字段，避免冗余信息干扰模型对“文本-标签”映射关系的学习。同时，`text`字段需经过预处理：去重（删除完全重复的反馈）、纠错（修正“吸不净”“续行”等错别字为“吸不干净”“续航”）、过滤低质内容（如仅含“好”“差”等无意义文本），确保数据质量。

典型场景除客户反馈情感分析外，还包括用户意图识别（如将客服对话文本分为“订单咨询”“售后维权”“产品推荐”三类）、文档分类（如将法律文本分为“合同文件”“法条汇编”“案例分析”）、垃圾邮件识别（如将邮件文本分为“垃圾邮件”“正常邮件”）等。设计逻辑上，通过极简的“text+label”结构，让模型专注于文本内容与类别标签的关联学习，减少字段干扰，提升分类效率与准确率。

3.2.5 问答抽取

问答抽取任务需模型从指定背景文档（context）中提取与问题（question）匹配的精准答案（answers），核心是明确“背景-问题-答案”的三者对应关系：

{​"context": "《儿童常见疾病用药指南》中关于儿童发烧用药的说明：儿童体温超过38.5℃时，可使用对乙酰氨基酚或布洛芬混悬液；对乙酰氨基酚适用年龄为3个月以上，单次剂量按体重计算为10-15mg/kg，每4-6小时可重复使用1次，24小时不超过4次；布洛芬适用年龄为6个月以上，单次剂量为5-10mg/kg，每6-8小时重复使用1次，24小时不超过4次。",​"question": "3个月以上儿童发烧超过38.5℃，可使用的对乙酰氨基酚单次剂量范围是多少？",​"answers": ["按体重计算为10-15mg/kg"]​
}

• context字段需提供完整、准确的背景文档，作为答案提取的唯一依据（如示例中完整引用《儿童用药指南》条款），不可遗漏关键信息（如用药剂量），避免模型因信息缺失无法提取正确答案；
• question字段需清晰明确地传递查询需求，避免歧义 —— 例如不可用 “这个药的剂量是多少”，需补充 “3 个月以上儿童用对乙酰氨基酚的单次剂量”，确保模型精准定位context中的答案位置；
• answers字段：需从context中直接提取，不可添加额外信息（如示例中 “10-15mg/kg” 直接来自指南原文，未新增 “建议按体重计算” 等额外描述）；多答案时需用数组格式存储，且每个答案需与question的提问点一一对应。​

若需强化垂直领域约束（如医疗问答需符合临床规范），可在格式中新增system字段，例如：

{"system": "你是医疗问答助手，需从参考文档（context）中提取答案，不可编造信息，答案需符合临床用药规范","context": "《儿童常见疾病用药指南》...","question": "3个月以上儿童发烧超过38.5℃，可使用的对乙酰氨基酚单次剂量范围是多少？","answers": ["按体重计算为10-15mg/kg"]
}

但需注意，system字段仅用于约束模型行为，不可替代context提供答案依据，避免模型忽略背景文档直接生成答案。​

典型场景包括文档阅读理解（如从产品说明书中提取 “某型号手机电池容量”）、知识检索（如从法条中提取 “劳动合同试用期最长时长”）、医疗问答（如从病历模板中提取 “成人高血压诊断标准”）等。设计逻辑上，通过context固定答案来源、question明确查询目标、answers定义正确结果，让模型学习 “定位问题 - 检索信息 - 提取答案” 的流程，确保输出答案的准确性与来源可追溯。

3.2.6 工具调用微调​

工具调用微调需模型学习 “根据用户需求调用工具→获取工具返回结果→生成自然语言响应” 的完整流程，JSON 示例如下：

{"conversations": [{"role": "system","content": "你可调用“天气查询工具”获取实时天气，工具参数要求：城市（必填，字符串，如“北京”）、日期（可选，默认当天，格式“YYYY-MM-DD”）；调用后需根据工具返回结果（function_result）生成自然语言响应，不可直接输出工具参数，需用用户易懂的语言描述天气情况。"},{"role": "user","content": "想知道上海2024年10月5日的天气，需要带伞吗？"},{"role": "function","content": {"name": "weather_query","parameters": {"city": "上海","date": "2024-10-05"}}},{"role": "function_result","content": "上海2024-10-05天气：阴转小雨，气温18-22℃，东北风2-3级，相对湿度85%，降水概率60%。"},{"role": "assistant","content": "上海2024年10月5日天气为阴转小雨，气温在18-22℃之间，伴有东北风2-3级，空气相对湿度85%，降水概率60%，建议携带雨伞，出行时注意防滑；若需长时间户外活动，可搭配薄外套，避免着凉。"}]
}

• system字段：明确工具调用权限（如 “可调用天气查询工具”）、参数要求（如必填项 “城市”、格式要求）、响应规则（如 “不可直接输出参数，需转化为自然语言”），为模型提供工具使用的 “操作手册”；​
• user字段：传递用户的实际需求（如 “上海 10 月 5 日天气”“是否带伞”），模型需从需求中提取工具调用所需的关键信息（城市 “上海”、日期 “2024-10-05”）；
• ​function字段：记录工具调用的具体信息 ——name为工具名称（需与实际工具接口名称一致，如 “weather_query”），parameters为工具所需参数（需严格匹配参数类型与必填项，不可遗漏 “城市” 等必填信息）；​
• function_result字段：记录工具返回的原始数据（如天气详情），需完整保留工具输出内容，不可篡改（如不可将 “降水概率 60%” 改为 “可能下雨”），确保模型基于真实数据生成响应；
• ​assistant字段：模型需将function_result转化为符合用户需求的自然语言 —— 例如用户问 “是否带伞”，需从结果中提取 “阴转小雨”“降水概率 60%” 等关键信息，明确给出 “建议携带雨伞” 的结论，而非仅复述工具结果。​

说明：此格式适配 Qwen 工具调用版、Llama 3 Tool Use 等模型，若为 OpenAI 生态，需将conversations替换为messages数组（参考 3.3.4 小节）。

若工具调用涉及多轮交互（如用户补充 “那北京当天呢？”），需延续user→function→function_result→assistant的字段顺序，确保对话上下文连贯：

{"conversations": [// 前序交互（上海天气查询）...{"role": "user","content": "那北京2024年10月5日的天气怎么样？"},{"role": "function","content": {"name": "weather_query","parameters": {"city": "北京","date": "2024-10-05"}}},{"role": "function_result","content": "北京2024-10-05天气：晴，气温12-20℃，西北风3-4级，相对湿度40%。"},{"role": "assistant","content": "北京2024年10月5日天气为晴，气温12-20℃，伴有西北风3-4级，空气干燥（相对湿度40%），无需携带雨伞，建议做好防风措施，可搭配长袖外套应对早晚温差。"}]
}

典型场景包括智能助手工具调用（如查询股票行情、预订火车票、翻译文档）、工业设备控制（如调用传感器查询 “设备 A 当前温度”、发送指令 “启动生产线 B”）、办公自动化（如调用 Excel 工具 “统计 Q3 销售额”、调用邮件工具 “发送会议通知”）等。设计逻辑上，通过完整记录 “需求 - 调用 - 结果 - 响应” 链路，让模型学习工具参数提取、结果转化的能力，实现 “工具辅助决策” 的目标，避免模型因缺乏工具支持无法完成复杂任务（如实时数据查询）。

3.3 按主流模型生态分类（简要对照）​

不同模型生态因训练数据、技术路线的差异，对数据集格式有明确偏好，选择格式时需优先适配目标模型生态，减少格式转换成本，确保模型能正确解析字段含义。​

3.3.1 Llama / Alpaca 生态

该生态以 Llama、Llama 2、Llama 3 系列为代表，早期受 Alpaca 项目影响深远，对单轮指令格式兼容性极强，同时支持多轮对话的 conversations 结构。

格式偏好：

单轮任务：推荐使用 Alpaca 风格的三字段结构：

{"instruction": "将以下英文翻译成中文：Myocardial Infarction","input": "","output": "心肌梗死"
}

其中 input 可为空字符串，若任务无需额外背景。

多轮对话：需使用conversations数组格式（字段命名与 ChatML 一致，均为role/content，但无messages顶层数组）：

{"conversations": [{"role": "system", "content": "你是一名医学翻译专家"},{"role": "user", "content": "Myocardial Infarction 是什么？"},{"role": "assistant", "content": "中文名为心肌梗死，是一种急性心血管疾病。"}]
}

关键要求：

• Llama 3 的 tokenizer 原生支持 system/user/assistant 角色标记，强烈建议在多轮任务中显式包含 system 以提升领域控制力；
• 单轮任务中，可将角色约束融入 instruction（如“作为医生，请翻译……”），避免格式冗余；
• 微调时推荐使用 Hugging Face 的 LlamaTokenizer 或 AutoTokenizer，其会自动处理对话模板（chat template）。

工具支持：

• Hugging Face Transformers 提供 apply_chat_template() 方法，可自动将 conversations 转为模型可识别的 token 序列；
• 社区广泛使用的 llama-factory、unsloth 等微调框架均原生支持上述两种格式，只需指定 --dataset_format alpaca 或 --dataset_format sharegpt 即可自动解析。

3.3.2 Qwen / ChatGLM 生态​

该生态以通义千问（Qwen）系列和智谱 AI 的 ChatGLM 系列为代表，专为中文场景优化，强调结构化对话能力与工具调用支持。两者均采用基于角色数组的 conversations 格式，对 system 字段依赖较强，适用于单轮指令、多轮对话及工具调用等多种任务。

格式偏好：​

单轮任务：仍需包装为 conversations 数组，不可使用 Alpaca 式的扁平字段。即使仅一轮交互，也必须包含 system、user、assistant 三角色：

{"conversations": [{"role": "system","content": "你是一名金融分析师，回答需基于公开数据，语言简洁专业。"},{"role": "user","content": "简述2024年A股新能源板块的投资逻辑。"},{"role": "assistant","content": "2024年A股新能源板块核心逻辑为：政策支持持续、技术迭代加速、全球需求回暖。建议关注具备成本优势与出海能力的龙头企业。"}]
}

多轮对话：自然延续 conversations 数组，按交互顺序交替添加 user 与 assistant 消息，system 仅出现在首位：

{"conversations": [{"role": "system", "content": "你是电商客服，需提供具体解决方案"},{"role": "user", "content": "订单123456三天没发货"},{"role": "assistant", "content": "该订单为预售商品，预计2天后发出……"},{"role": "user", "content": "那我选择等待"},{"role": "assistant", "content": "已为您备注发货后短信通知……"}]
}

关键要求：​

• 角色顺序严格：system字段必须放在conversations数组首位，且不可省略（即使无特殊规则，也需填写基础角色定义，如 “你是专业助手，回答需准确简洁”），否则模型可能忽略领域约束；​
• 工具调用格式统一：Qwen 工具调用版（如 Qwen-7B-ToolCall）需使用function与function_result字段，且需嵌套在conversations数组中；
• 中文字段仅适配 Qwen/ChatGLM 官方微调脚本，若使用 Hugging Face 第三方框架（如transformers），建议优先用英文字段（role/content），避免解析失败。

工具支持：​

• 官方提供微调脚本（如 Qwen 的finetune.py、ChatGLM 的ptuning_v2.py），直接适配conversations格式，可通过参数--data_path指定数据集路径，脚本自动解析角色字段；​
• 提供格式校验工具（如 Qwen 的check_data.py），可批量检查数据集是否存在角色缺失、顺序错误等问题，输出错误样本列表便于修正。

​3.3.3 BERT / RoBERTa 生态​

该生态的代表模型包括 BERT-base/-large、RoBERTa-base/-large，主打文本分类、命名实体识别、语义相似度等 “非生成类任务”，无需角色交互，格式设计以 “简洁高效” 为核心，仅需核心任务字段。​

格式偏好：​

文本分类任务：采用text+label二元格式，示例如下（情感分析场景）：

{"text": "这款笔记本电脑续航长达12小时，运行流畅，非常适合办公使用","label": "正面"
}

命名实体识别任务：采用text+entities格式，entities记录实体类型与位置，示例如下（金融领域）：

{"text": "2024年9月，阿里巴巴集团在杭州举办了云栖大会，发布了最新的人工智能模型“通义千问2.0”","entities": [{"type": "时间", "value": "2024年9月", "start": 0, "end": 6},{"type": "企业", "value": "阿里巴巴集团", "start": 8, "end": 14},{"type": "地点", "value": "杭州", "start": 16, "end": 18},{"type": "产品", "value": "通义千问2.0", "start": 28, "end": 36}]
}

语义相似度任务：采用sentence1+sentence2+label格式，label表示两句语义相似度（如 0 = 不相似、1 = 相似），示例如下：

{"sentence1": "医生建议患者每天运动30分钟","sentence2": "患者需遵医嘱每日进行半小时体育锻炼","label": 1
}

关键要求：​

• 无角色字段：无需添加system、user等对话类字段，避免数据冗余导致模型训练效率下降；​
• 文本预处理严格：需对text/sentence进行分词（如使用 BERTTokenizer）、截断（长度不超过模型最大输入序列，如 BERT-base 为 512 tokens）、padding 处理，确保输入格式统一；​
• 标签编码规范：分类任务的label需转化为整数（如 “正面 = 0”“负面 = 1”“中性 = 2”），不可直接使用字符串标签，需提供标签映射表（如label2id.json）供模型解析。​

工具支持：​

• Hugging Face transformers库提供DataCollatorWithPadding，可自动对文本进行 padding，适配不同长度的输入；​
• 官方提供run_classification.py等任务脚本，直接支持text-label格式，仅需修改数据加载函数即可适配自定义数据集。

3.3.4 OpenAI 生态（GPT 系列）​

该生态的代表模型包括 GPT-3.5-Turbo、GPT-4、GPT-4 Turbo，格式设计以 “ChatML” 为标准，支持对话、工具调用等多种任务，强调 “人与模型的沟通协议”，字段定义严谨且通用。​

格式偏好：​

对话微调任务：使用messages数组，角色字段包括system、user、assistant，示例如下（法律咨询场景）：

{"messages": [{"role": "system","content": "你是法律咨询师，专注于劳动合同纠纷，回答需基于《中华人民共和国劳动合同法》，提供具体法条依据与解决方案"},{"role": "user","content": "公司未与我签订劳动合同，工作满6个月，我可以主张哪些权益？"},{"role": "assistant","content": "根据《中华人民共和国劳动合同法》第八十二条，用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当向劳动者每月支付二倍的工资。你工作满6个月且未签订劳动合同，可主张以下权益：1. 要求公司支付5个月的二倍工资差额（自用工第2个月起计算）；2. 要求公司补签书面劳动合同；3. 若公司拒绝，可向劳动争议仲裁委员会申请仲裁，提交工资流水、工作记录等证据证明劳动关系。"}]
}

工具调用微调任务：新增function_call与function字段，示例如下（航班查询场景）：

{"messages": [{"role": "system","content": "可调用“航班查询工具”获取航班信息，参数：出发地（必填）、目的地（必填）、日期（必填）、航空公司（可选）"},{"role": "user","content": "查询2024年10月10日从北京飞往上海的东方航空航班"},{"role": "function_call","content": {"name": "flight_query","parameters": {"departure": "北京","destination": "上海","date": "2024-10-10","airline": "东方航空"}}},{"role": "function","content": {"name": "flight_query","parameters": {"departure": "北京","destination": "上海","date": "2024-10-10","airline": "东方航空"},"result": [{"flight_no": "MU5101", "departure_time": "08:00", "arrival_time": "10:30", "status": "正常"},{"flight_no": "MU5103", "departure_time": "14:30", "arrival_time": "17:00", "status": "正常"}]}},{"role": "assistant","content": "2024年10月10日北京飞往上海的东方航空航班信息如下：1. 航班号MU5101，08:00起飞，10:30抵达，当前状态正常；2. 航班号MU5103，14:30起飞，17:00抵达，当前状态正常。建议提前2小时到达机场办理值机，具体登机口以机场通知为准。"}]
}

关键要求：​

• 字段命名固定：必须使用messages数组与role/content字段，不可自定义（如不可用 “dialogs” 替代 “messages”）；​
• system作用显著：system字段对模型行为的控制优先级最高，需精准描述角色、规则与输出要求，避免模糊表述（如 “回答需简洁” 应改为 “回答控制在 300 字以内，分点列出核心结论”）；​
• 格式兼容性：微调数据集需保存为 JSONL 格式（每行一个 JSON 对象），不可使用 JSON 数组格式，否则无法通过 OpenAI API 上传。​

工具支持：​

• OpenAI 提供openai-cookbook代码库，包含格式转换脚本（如将普通对话数据转为 ChatML 格式）、数据校验工具（如检查 JSONL 格式合法性）；​
• 通过openai.fine_tuning.jobs.create接口上传数据集时，API 会自动校验格式，若存在字段错误，会返回具体错误信息（如 “缺少 assistant 角色”“function_call 字段格式错误”）。​

四、总结

微调数据集的格式并非“越复杂越好”或“越通用越好”，而应根据目标模型的技术规范、主流社区的实践习惯，以及自身微调任务的具体目的三者综合权衡。

• 模型规范是底线：不同模型（如 Llama、Qwen、BERT）对字段命名、角色顺序、输入结构有硬性要求，格式不符将直接导致训练失败；
• 社区习惯是捷径：遵循 Alpaca、ChatML 等主流格式，可复用成熟的工具链（如数据校验、模板转换、微调脚本），大幅降低工程成本；
• 微调目标是指南针：单轮生成、多轮对话、思维链推理、工具调用等任务本质不同，需匹配最能表达任务逻辑的字段组合，避免“用对话格式做分类”或“用扁平结构训多轮”。

例：若用 Qwen-7B 做医疗多轮对话微调，优先级为：

① 遵循 Qwen 生态‘conversations数组 +system首位’的模型规范（3.3.2 小节）；

② 采用社区通用的role/content字段（而非中文字段）；

③ 匹配多轮对话任务的‘角色交替’逻辑（3.2.2 小节），最终确定格式。