LLM 微调数据集整理实战指南格式选择、模板掩码、序列打包与数据集卡片dataset-curation【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读dataset-curation是 llm-finetuning 插件在微调生命周期 Phase 2数据集准备阶段的核心技能负责把原始示例演示数据、偏好判定或任务提示词转化为格式正确、完成打包、通过验证的 JSONL 数据集并产出一张完整的数据集卡片。本文以该技能文档为主体结合仓库内的格式与模板参考、合成数据参考以及/finetune命令的 Phase 2 调用链系统讲解数据格式如何按微调方法选择、聊天模板与损失掩码如何避免静默失败、序列打包如何省算力、合成数据如何防坍缩以及数据集卡片六字段为何是启动训练前的硬性闸门。读完本文你将能独立完成一次可被/finetune接受的、可复现可审计的微调数据集构建。技能定位从方法选择路由到数据准备dataset-curation技能的前置条件非常明确——finetuning-method-selection已经把路由决策传到这里本阶段的任务是准备数据而不是选择方法。该技能在 SKILL.md 中定义的输入输出契约是输入原始示例demonstrations、preference judgments 或 task prompts加上来自finetuning-method-selection的路由决策输出一份格式化、打包、验证过的 JSONL 数据集外加一张填写完整的数据集卡片——这是/finetune在启动训练前检查的 Phase 2 交付物。在仓库的调用链中这一点可以精确印证/finetune命令的 Phase 2: Dataset Preparation 明确要求训练工程师按dataset-curation的格式表构建数据集在任何拼接或打包之前应用聊天模板若启用打包则必须解码并人工检查 5–10 条打包序列写出包含全部六个必填字段的数据集卡片并完整走查 Phase 2 Exit Checklist。而 llm-finetuning-training-engineer agent 的能力清单中数据集准备与验证也正是由dataset-curation负责。这意味着本技能是 Phase 2 的事实标准——方法选型Phase 1的产出training-brief.md经由它落地为可训练的数据而后面的lora-qlora-recipes、preference-optimization、vision-sft等训练技能则直接消费它产出的数据集。按目标方法选择数据格式SKILL.md的 Format Selection 表给出了五种微调方法各自要求的数据形态这是构建数据集的第一个决策点方法数据形态行数要求SFT单轮Instructinstruction/response或prompt/completion约 1,000 起步SFT多轮Conversation / ChatMLmessages列表约 1,000 起步DPO / ORPO偏好对prompt、chosen、rejected视方法而定见preference-optimizationKTO无配对prompt、completion、label视方法而定见preference-optimizationGRPO / RLVR仅提示词prompt verifier 元数据视方法而定见grpo-rlvr-training关于行数文档给出了一个容易被误解的关键澄清约 1,000 行是 SFT 的推荐下限不是目标。低于这个下限时少数几条低质量或重复样本就可能主导梯度高于下限后质量优先于数量——一份更小但经过验证、去重的集合胜过一份更大但嘈杂的集合。为便于读者建立直观印象SKILL.md给出了 ChatML 形态的最小示例{messages: [ {role: user, content: ...}, {role: assistant, content: ...} ]}其余四种格式的具体 JSONL 行示例、ShareGPT 转换说明都集中在 references/formats-and-templates.md下面按格式逐一展开。InstructSFT 单轮两种键值对二选一每行一个示例两种键对任选其一但全数据集必须保持一致{instruction: Summarize the following text in one sentence., input: Q3 revenue grew 14% year-over-year, driven primarily by..., output: Q3 revenue grew 14% YoY on strong core-segment demand.}{prompt: Summarize the following text in one sentence: Q3 revenue grew 14%..., completion: Q3 revenue grew 14% YoY on strong core-segment demand.}ChatML 多轮对话messages列表每行一个messages列表这是SFTTrainer原生支持模板化与损失掩码的形态。多轮示例中掩码后只有最后两个assistant轮次的 content token 承载损失{messages: [ {role: system, content: You are a concise technical assistant.}, {role: user, content: What does a KV cache do?}, {role: assistant, content: It stores attention keys/values from prior tokens so decoding doesnt recompute them each step.}, {role: user, content: Does it grow with context length?}, {role: assistant, content: Yes, linearly — thats why long-context serving is memory-bound on cache size, not compute.} ]}DPO / ORPOchosen/rejected 配对{prompt: Explain why the sky is blue., chosen: Sunlight scatters off air molecules; shorter (blue) wavelengths scatter more, so blue dominates what reaches your eyes from all directions., rejected: Because the sky reflects the ocean.}注意chosen和rejected都是对同一个prompt的完整回答不是 diff 也不是排序分数。如何从评分轨迹集中挑选rejected参考文档指出是从奖励分布中取 μ−2σ而非朴素地取最低分属于preference-optimization的 Pair Construction 部分。KTO无配对二元反馈{prompt: Draft a one-line commit message for a null-check fix., completion: Fix null pointer exception in user lookup, label: true}{prompt: Draft a one-line commit message for a null-check fix., completion: misc changes, label: false}KTO 不要求也不期望行与行之间配对——label: true标记期望行为label: false标记不期望行为。一个健康的 KTO 数据集必须同时包含两种 label。GRPO / RLVR仅提示词{prompt: Solve: 17 * 24 ?, answer: 408, verifier: exact_match}GRPO 不存储回答——训练时从策略中采样补全并通过命名 verifier或奖励函数对照answer打分。奖励函数设计与 GRPO 运行前的人工检查要求在grpo-rlvr-training中展开。聊天模板与损失掩码训练前必须避开的静默失败SKILL.md在本节给出了一个顺序铁律必须在任何拼接或打包之前应用目标模型的聊天模板绝不能之后。对打包后的整体文本做模板化会破坏轮次边界使角色标记相对各示例落到错误位置。三个核心要点只对 assistant 回答训练损失。在 labels 张量中对 system/user 轮次及模板自身的角色标记掩码用-100只有 assistant 轮次的内容 token 贡献损失。模板/分词器不匹配是头号静默失败模式。用一套聊天模板训练、却用另一套模板做推理或评估的模型会无报错地劣化。必须验证训练、推理、评估三处使用的是同一个模板字符串。把数据集保持在messages形态让训练器去做模板化与掩码当前 TRL 中是assistant_only_lossTrue。预渲染成扁平文本字段会摧毁掩码所需的轮次边界。训练前的 sanity-check 代码解码仅未被掩码的位置期望只看到 assistant 文本keep batch[labels][0] ! -100 print(tokenizer.decode(batch[input_ids][0][keep]))当前 TRL API 下的模板应用代码references/formats-and-templates.md 给出了符合当前 TRL 约定的完整代码骨架。要点是保持数据集为messages形态让SFTTrainer应用模板——不要预渲染对话为扁平文本字段。当前 TRL 会对每个示例在任何打包拼接之前正好满足模板先于拼接规则应用分词器的聊天模板并在assistant_only_lossTrue时把损失掩码到 assistant 片段from transformers import AutoTokenizer from trl import SFTConfig, SFTTrainer tokenizer AutoTokenizer.from_pretrained(BASE_MODEL) sft_args SFTConfig( output_dir./outputs-sft, max_length2048, packingTrue, # 启用前先看 SKILL.md 的 Packing 一节 assistant_only_lossTrue, # 损失仅掩码到 assistant 轮次 ) trainer SFTTrainer( modelBASE_MODEL, argssft_args, train_datasetdataset, # messages 形态——不要预渲染文本字段 processing_classtokenizer, # 当前 TRL 写法不是 tokenizer )两个值得注意的细节processing_class而非旧的tokenizer是当前 TRL 的参数名完整的 Unsloth↔TRL kwargs 映射见 lora-qlora-recipes 的 references/unsloth-trl-mapping.md。assistant_only_lossTrue要求分词器的聊天模板标记 assistant 片段{% generation %}关键字。如果模板缺少该标记TRL 会主动报错而非静默地对全部内容训练——此时应修复模板而不是退回扁平文本。参考文档还明确指出apply_chat_template(..., tokenizeFalse)仍然适用于检查模板产出如打包序列的解码检查但不应用于构建训练数据集。老式的扁平文本路径把对话预渲染成text列并设置dataset_text_fieldtext虽然仍能运行但会对整个序列含 user 轮次与模板标记计算损失——这正是SKILL.md警告的静默训练全部内容故障仅适用于确实想要全序列损失的场景如对原始文本做 CPT 式持续预训练绝不适用于对话式 SFT。ShareGPT → role/content 转换老数据集常以 ShareGPT 的conversations形态from/value键、human/gpt角色存在而当前 TRL 期望messages的role/content形态。转换要在模板化之前完成而不是过程中ROLE_MAP {human: user, gpt: assistant, system: system} def sharegpt_to_messages(example): messages [ {role: ROLE_MAP[turn[from]], content: turn[value]} for turn in example[conversations] ] return {messages: messages} dataset dataset.map(sharegpt_to_messages, remove_columns[conversations])转换完成后并抽查若干行才轮到拼接前应用模板的规则生效。仍以from/value形态进入打包或模板化的 ShareGPT 数据集会生成畸形轮次而模板调用不会报错。序列打包省算力但改变批次语义不做打包时40–70% 的计算被浪费在 padding 上——变长示例按固定序列长度批处理时每个示例长度与批次最大值之间的空隙被白白浪费。打包把多个示例拼接进一条序列直到最大长度消掉大部分浪费。但打包带来两个必须正视的后果打包改变批次语义。一条打包序列可能包含多条原始示例因此每 epoch 步数以及任何按示例数量锚定的 LR 调度都会在打包开启后偏移——必须按打包后序列数量重算调度里程碑。强制要求在扩展到完整训练前解码并人工检查 5–10 条打包序列。确认示例边界落在预期位置、每个子示例的模板标记完好、每条打包序列内的损失掩码仍然只对 assistant。这一步不可跳过——打包 bug 是静默的损失曲线看起来正常只会在数小时后的评估质量中浮出水面。检查代码for seq in packed_dataset.select(range(10)): print(tokenizer.decode(seq[input_ids]))在/finetune的 Phase 2 流程中这一步被明确为强制而非抽查训练工程师必须解码并人工检查 5–10 条打包序列并把解码样本本身附加到验证报告中见 finetune.md而不是只写一行 pass/fail。合成数据规则防坍缩、生成方法与接受率预算SKILL.md的合成数据规则是数据规模扩大的防线四条规则层层递进保持 ≥25% 真实数据作为防坍缩底线。在越来越多模型生成数据上训练、却没有真实数据下限会在连续几代中驱动可测的质量坍缩——25% 真实数据是守住这条线的最低值。关键定义通用域 replay 行计入这条底线——这里的真实指不是为这个任务、由这个学生模型生成的而不是人类撰写的。一个全合成构造的数据集可以仅靠 replay 就满足 ≥25% 底线见 references/synthetic-data.md 的 Replay-Mix Construction 配方必须在数据集卡片中说明哪些行算作真实而不是让底线在结构上无法满足。Magpie 和 rejection sampling 是主力方法。Magpie 直接从模型自身的模板先验中抽取提示词rejection sampling 为每个提示词生成多个候选、只保留通过过滤器的那些。两者都优于朴素的一次生成。定向、学生感知的生成比静态生成高 1.3–2 倍样本效率——瞄准学生模型的实际失败模式用更少的过滤样本就能达到质量线。过滤后的典型接受率在 10–30%。据此规划生成量——以 10,000 行目标、15% 接受率计算需要约 65,000 条原始生成。生成方法排序与过滤漏斗references/synthetic-data.md 给出了从弱到强的生成方法排序按同预算下的样本效率与下游质量每一级都包含前一级——rejection-sampling 管线通常在其下用 Magpie 或 persona 条件提示词生成候选Self-Instruct——用模型改写和扩展少量种子集引导新提示词。最便宜也最弱提示词多样性快速触顶质量紧贴种子集。Evol-Instruct——跨代迭代改写提示词以增加复杂度加约束、加深推理、拓宽范围。难度覆盖优于 Self-Instruct但仍依赖种子。Magpie——无需种子提示词直接从目标模型自身聊天模板先验的 user 轮位置采样提取提示词。完全消除种子集偏差这是它成为主力而非小众技巧的原因。Persona-conditioned generation——以采样的人物/角色描述为条件生成提示词拓宽无条件单策略生成之外的风格与主题覆盖。Rejection sampling / verifier-filtered——每个提示词生成多个候选补全只保留过滤器/验证器/裁判接受的那些。它是补全侧的过滤器本身不是提示词生成方法可与上面任意方法组合。定向、学生感知的生成叠加在任意方法之上把提示词或人物选择引向当前学生模型的实际失败模式而非均匀采样这正是SKILL.md所引 1.3–2 倍样本效率的来源。它需要一个学生模型上的评估信号来获知其失败模式没有该信号生成就退化为非定向/静态的。过滤漏斗按成本从低到高排序廉价阶段应先用它削减体量昂贵阶段最后才在剩余小集合上运行见 references/synthetic-data.md精确去重——规范化合并空白/大小写后做哈希精确匹配。最廉价最先跑在后续阶段前清除生成循环重复。语义去重约 0.92 相似度阈值——嵌入每个候选丢弃与已保留行最近邻余弦相似度超过约 0.92 的行。捕获精确去重漏掉的改写级重复。长度过滤——丢弃低于最小或高于最大 token 长度的候选过短回答通常是退化的过长通常是啰嗦或跑题的。语言 ID 过滤——丢弃未通过目标语言检查的候选生成偶尔会漂移语言尤其是多语言基座模型在提示词描述不足时。基于分数的 top-30% 过滤——对剩余候选打分奖励模型、启发式或自洽性分数保留约前 30%——这是最昂贵阶段前的粗略质量切分。裁判 ≥ 阈值——把最昂贵的检查放在最后、最小的集合上LLM 裁判或人类等效质量检查对照固定阈值。此处失败的行无论上游得分如何都丢弃。SKILL.md的10–30% 典型接受率是漏斗端到端的整体产出率六阶段全通过不是任何单一阶段的通过率——必须按全漏斗产出率预算原始生成量。教师→学生蒸馏模式与 Replay-Mix 构造蒸馏不是特殊格式而是一条 provenance 标签references/synthetic-data.md先生成教师轨迹TEACHER对目标任务提示词分布采样补全含推理轨迹、用过滤漏斗验证蒸馏集也是合成数据集仍需 ≥25% 真实数据底线与同样的去重质量阶段、再用标准 SFT 格式与模板规则训练学生。TEACHER身份与生成配置采样温度、用于引出轨迹的提示词模板必须记录在数据集卡片的 provenance 字段——distilled fromTEACHER是/finetune与下游审计都期望在那里看到的事实。Replay-Mix 构造checkpoint-promotion灾难性遗忘升级阶梯的实现配方有五个按出现顺序排列的决策通用域来源选择——选真正通用域的来源两个要避免的失败模式不要教给闸门replay 源与漂移套件基准同分布会污染漂移分数测量若必须使用需按checkpoint-promotion的指令复用披露规则披露且存在更宽的来源时以更宽来源为更可辩护的默认把来源匹配到遗忘特征错误分析显示特定能力丢失时针对该能力的 replay 源恢复更快但会收窄通用域声明——都需在卡片中说明。提示词形态——自然指令、漂移测试台的确切措辞、或裸输入无指令包装三种形态各有权衡按遗忘特征而非默认选择并无论如何都在卡片中披露。答案重格式化——replay 参考答案是否向目标任务输出约定重格式化如把数学数据集的#### N终结符改写为目标任务的提取约定记录确切变换或无——保留源格式。验证集处理——验证集只含任务行eval_loss跨仅 replay 分数不同的运行直接可比但训练循环对 replay 拟合零可见性或验证集也含 replay 行循环内可见 replay 拟合但eval_loss不再与先前任务-only 验证集运行可对苹果比。两者皆非普适正确必须在卡片中说明选择与原因。不相交性验证——训练前必须验证 replay 行与漂移套件或 goldens 集不重叠分裂级分离 精确匹配文本过滤对照eval/goldens.jsonl规范化精确匹配命中即丢弃并在卡片中记录发现的重复数期望 0。还有一个硬规则后续运行改变 replay 分数时用交换而非添加——replay 行进入时把目标任务行移出训练集使总行/步数在旧与新运行之间保持恒定。添加行会同时改变 replay 分数与总优化步数使后续漂移分数变化无法归因。行数不是 token 数——1:1 交换保持行数恒定但 replay 行与目标任务行长度常不同交换仍可能移动总训练 token进而影响固定批次大小与打包方案下的max_steps应在新旧运行之间保持总训练 token 或直接保持max_steps恒定并在卡片中记录每轮的打包 token 数。全合成数据集与 ≥25% 真实底线当训练集按构造 100% 合成全新任务、根本无真实数据池可抽取而非在真实基座上大量合成增强时底线在定义上无法满足除非混合中的某些东西算作真实。解决方案通用域 replay 行计入 ≥25% 底线——真实在此规则中意为不是为这个特定任务、从这个特定学生模型生成的从既有通用指令数据集抽取的 replay 行满足该定义。按上述五决策构建 replay 混合后把 replay 行作为真实份额计算卡片所需的合成/真实比例并在卡片中明确说明这是如何满足比例的避免后续审计把全合成目标任务数据误读为悄悄跳过了防坍缩守卫。数据集卡片六字段闸门而非事后总结每份进入训练的数据集都必须有一张卡片——这是/finetune在启动前检查的必需 Phase 2 交付物。卡片不是自由格式文档必须携带以下六字段Provenance来源——每行来自哪里真实来源、合成方法或两者可追溯到trace-to-training-data的输出。Counts数量——总行数以及若划分了 train/eval/held-out 各 split 的行数。Synthetic/real ratio合成/真实比例——实测比例对照上面 ≥25% 真实底线检查。Dedup method去重方法——精确匹配、语义嵌入阈值或两者参见references/synthetic-data.md的过滤漏斗。Template used所用模板——确切的聊天模板字符串/标识符保持贯穿推理与评估一致——这正是把一次eval-harness-first运行与 checkpoint 关联起来的纽带。Packing config打包配置——是否使用打包、最大序列长度以及上面 5–10 序列人工检查确实已完成的确认。缺任一字段的数据集就不算为/finetune就绪——卡片是闸门不是事后补写的摘要。Phase 2 退出清单移交给 /finetune 前的六项确认在移交给/finetune之前逐项确认格式与目标方法匹配上文格式表。模板在拼接之前应用。损失只掩码到 assistant 轮次。5–10 条打包序列已解码并阅读。最终混合中 ≥25% 真实数据。数据集卡片完整——六字段齐全。对照/finetune的 Phase 2 闸门描述finetune.md数据集卡片与验证报告若用了打包须含解码样本必须按 Phase 2 Exit Checklist 完整Phase 3 才能开始缺失即停在该闸门而不是跳过或即兴推进。技能全景与参考索引dataset-curation处于微调技能网的枢纽位置周边协作关系见 SKILL.md 末尾的 References 与 Related skills如下上游finetuning-method-selection把路由决策送进本技能方法选择与数据形态判断trace-to-training-data是分级轨迹数据集graded-trajectory datasets的 provenance 来源。下游消费方lora-qlora-recipes、vision-sft、preference-optimization消费本技能产出的数据集eval-harness-first对最终 checkpoint 打分其运行通过数据集卡片的 Template used 字段与 checkpoint 关联。参考文档references/formats-and-templates.md——每种格式的 JSONL 示例、当前 TRL 掩码代码、ShareGPT 转换说明references/synthetic-data.md——生成方法排序、过滤漏斗、replay-mix 构造、教师→学生蒸馏模式。一个贯穿全文的提醒SKILL.md与参考文档中的所有代码示例都使用BASE_MODEL、TEACHER、STUDENT占位符仓库不推荐具体基座模型——实际 checkpoint 选择参见finetuning-method-selection的references/model-catalog.md。从格式选择、模板先行、打包检查、合成数据防坍缩到六字段卡片每一步都有明确的验证动作与失败模式对照这正是这套数据集整理方法论能在真实微调运行中落地、而不是停留在文档层面的原因。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LLM 微调数据集整理实战指南：格式选择、模板掩码、序列打包与数据集卡片（dataset-curation）
LLM 微调数据集整理实战指南格式选择、模板掩码、序列打包与数据集卡片dataset-curation【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读dataset-curation是 llm-finetuning 插件在微调生命周期 Phase 2数据集准备阶段的核心技能负责把原始示例演示数据、偏好判定或任务提示词转化为格式正确、完成打包、通过验证的 JSONL 数据集并产出一张完整的数据集卡片。本文以该技能文档为主体结合仓库内的格式与模板参考、合成数据参考以及/finetune命令的 Phase 2 调用链系统讲解数据格式如何按微调方法选择、聊天模板与损失掩码如何避免静默失败、序列打包如何省算力、合成数据如何防坍缩以及数据集卡片六字段为何是启动训练前的硬性闸门。读完本文你将能独立完成一次可被/finetune接受的、可复现可审计的微调数据集构建。技能定位从方法选择路由到数据准备dataset-curation技能的前置条件非常明确——finetuning-method-selection已经把路由决策传到这里本阶段的任务是准备数据而不是选择方法。该技能在 SKILL.md 中定义的输入输出契约是输入原始示例demonstrations、preference judgments 或 task prompts加上来自finetuning-method-selection的路由决策输出一份格式化、打包、验证过的 JSONL 数据集外加一张填写完整的数据集卡片——这是/finetune在启动训练前检查的 Phase 2 交付物。在仓库的调用链中这一点可以精确印证/finetune命令的 Phase 2: Dataset Preparation 明确要求训练工程师按dataset-curation的格式表构建数据集在任何拼接或打包之前应用聊天模板若启用打包则必须解码并人工检查 5–10 条打包序列写出包含全部六个必填字段的数据集卡片并完整走查 Phase 2 Exit Checklist。而 llm-finetuning-training-engineer agent 的能力清单中数据集准备与验证也正是由dataset-curation负责。这意味着本技能是 Phase 2 的事实标准——方法选型Phase 1的产出training-brief.md经由它落地为可训练的数据而后面的lora-qlora-recipes、preference-optimization、vision-sft等训练技能则直接消费它产出的数据集。按目标方法选择数据格式SKILL.md的 Format Selection 表给出了五种微调方法各自要求的数据形态这是构建数据集的第一个决策点方法数据形态行数要求SFT单轮Instructinstruction/response或prompt/completion约 1,000 起步SFT多轮Conversation / ChatMLmessages列表约 1,000 起步DPO / ORPO偏好对prompt、chosen、rejected视方法而定见preference-optimizationKTO无配对prompt、completion、label视方法而定见preference-optimizationGRPO / RLVR仅提示词prompt verifier 元数据视方法而定见grpo-rlvr-training关于行数文档给出了一个容易被误解的关键澄清约 1,000 行是 SFT 的推荐下限不是目标。低于这个下限时少数几条低质量或重复样本就可能主导梯度高于下限后质量优先于数量——一份更小但经过验证、去重的集合胜过一份更大但嘈杂的集合。为便于读者建立直观印象SKILL.md给出了 ChatML 形态的最小示例{messages: [ {role: user, content: ...}, {role: assistant, content: ...} ]}其余四种格式的具体 JSONL 行示例、ShareGPT 转换说明都集中在 references/formats-and-templates.md下面按格式逐一展开。InstructSFT 单轮两种键值对二选一每行一个示例两种键对任选其一但全数据集必须保持一致{instruction: Summarize the following text in one sentence., input: Q3 revenue grew 14% year-over-year, driven primarily by..., output: Q3 revenue grew 14% YoY on strong core-segment demand.}{prompt: Summarize the following text in one sentence: Q3 revenue grew 14%..., completion: Q3 revenue grew 14% YoY on strong core-segment demand.}ChatML 多轮对话messages列表每行一个messages列表这是SFTTrainer原生支持模板化与损失掩码的形态。多轮示例中掩码后只有最后两个assistant轮次的 content token 承载损失{messages: [ {role: system, content: You are a concise technical assistant.}, {role: user, content: What does a KV cache do?}, {role: assistant, content: It stores attention keys/values from prior tokens so decoding doesnt recompute them each step.}, {role: user, content: Does it grow with context length?}, {role: assistant, content: Yes, linearly — thats why long-context serving is memory-bound on cache size, not compute.} ]}DPO / ORPOchosen/rejected 配对{prompt: Explain why the sky is blue., chosen: Sunlight scatters off air molecules; shorter (blue) wavelengths scatter more, so blue dominates what reaches your eyes from all directions., rejected: Because the sky reflects the ocean.}注意chosen和rejected都是对同一个prompt的完整回答不是 diff 也不是排序分数。如何从评分轨迹集中挑选rejected参考文档指出是从奖励分布中取 μ−2σ而非朴素地取最低分属于preference-optimization的 Pair Construction 部分。KTO无配对二元反馈{prompt: Draft a one-line commit message for a null-check fix., completion: Fix null pointer exception in user lookup, label: true}{prompt: Draft a one-line commit message for a null-check fix., completion: misc changes, label: false}KTO 不要求也不期望行与行之间配对——label: true标记期望行为label: false标记不期望行为。一个健康的 KTO 数据集必须同时包含两种 label。GRPO / RLVR仅提示词{prompt: Solve: 17 * 24 ?, answer: 408, verifier: exact_match}GRPO 不存储回答——训练时从策略中采样补全并通过命名 verifier或奖励函数对照answer打分。奖励函数设计与 GRPO 运行前的人工检查要求在grpo-rlvr-training中展开。聊天模板与损失掩码训练前必须避开的静默失败SKILL.md在本节给出了一个顺序铁律必须在任何拼接或打包之前应用目标模型的聊天模板绝不能之后。对打包后的整体文本做模板化会破坏轮次边界使角色标记相对各示例落到错误位置。三个核心要点只对 assistant 回答训练损失。在 labels 张量中对 system/user 轮次及模板自身的角色标记掩码用-100只有 assistant 轮次的内容 token 贡献损失。模板/分词器不匹配是头号静默失败模式。用一套聊天模板训练、却用另一套模板做推理或评估的模型会无报错地劣化。必须验证训练、推理、评估三处使用的是同一个模板字符串。把数据集保持在messages形态让训练器去做模板化与掩码当前 TRL 中是assistant_only_lossTrue。预渲染成扁平文本字段会摧毁掩码所需的轮次边界。训练前的 sanity-check 代码解码仅未被掩码的位置期望只看到 assistant 文本keep batch[labels][0] ! -100 print(tokenizer.decode(batch[input_ids][0][keep]))当前 TRL API 下的模板应用代码references/formats-and-templates.md 给出了符合当前 TRL 约定的完整代码骨架。要点是保持数据集为messages形态让SFTTrainer应用模板——不要预渲染对话为扁平文本字段。当前 TRL 会对每个示例在任何打包拼接之前正好满足模板先于拼接规则应用分词器的聊天模板并在assistant_only_lossTrue时把损失掩码到 assistant 片段from transformers import AutoTokenizer from trl import SFTConfig, SFTTrainer tokenizer AutoTokenizer.from_pretrained(BASE_MODEL) sft_args SFTConfig( output_dir./outputs-sft, max_length2048, packingTrue, # 启用前先看 SKILL.md 的 Packing 一节 assistant_only_lossTrue, # 损失仅掩码到 assistant 轮次 ) trainer SFTTrainer( modelBASE_MODEL, argssft_args, train_datasetdataset, # messages 形态——不要预渲染文本字段 processing_classtokenizer, # 当前 TRL 写法不是 tokenizer )两个值得注意的细节processing_class而非旧的tokenizer是当前 TRL 的参数名完整的 Unsloth↔TRL kwargs 映射见 lora-qlora-recipes 的 references/unsloth-trl-mapping.md。assistant_only_lossTrue要求分词器的聊天模板标记 assistant 片段{% generation %}关键字。如果模板缺少该标记TRL 会主动报错而非静默地对全部内容训练——此时应修复模板而不是退回扁平文本。参考文档还明确指出apply_chat_template(..., tokenizeFalse)仍然适用于检查模板产出如打包序列的解码检查但不应用于构建训练数据集。老式的扁平文本路径把对话预渲染成text列并设置dataset_text_fieldtext虽然仍能运行但会对整个序列含 user 轮次与模板标记计算损失——这正是SKILL.md警告的静默训练全部内容故障仅适用于确实想要全序列损失的场景如对原始文本做 CPT 式持续预训练绝不适用于对话式 SFT。ShareGPT → role/content 转换老数据集常以 ShareGPT 的conversations形态from/value键、human/gpt角色存在而当前 TRL 期望messages的role/content形态。转换要在模板化之前完成而不是过程中ROLE_MAP {human: user, gpt: assistant, system: system} def sharegpt_to_messages(example): messages [ {role: ROLE_MAP[turn[from]], content: turn[value]} for turn in example[conversations] ] return {messages: messages} dataset dataset.map(sharegpt_to_messages, remove_columns[conversations])转换完成后并抽查若干行才轮到拼接前应用模板的规则生效。仍以from/value形态进入打包或模板化的 ShareGPT 数据集会生成畸形轮次而模板调用不会报错。序列打包省算力但改变批次语义不做打包时40–70% 的计算被浪费在 padding 上——变长示例按固定序列长度批处理时每个示例长度与批次最大值之间的空隙被白白浪费。打包把多个示例拼接进一条序列直到最大长度消掉大部分浪费。但打包带来两个必须正视的后果打包改变批次语义。一条打包序列可能包含多条原始示例因此每 epoch 步数以及任何按示例数量锚定的 LR 调度都会在打包开启后偏移——必须按打包后序列数量重算调度里程碑。强制要求在扩展到完整训练前解码并人工检查 5–10 条打包序列。确认示例边界落在预期位置、每个子示例的模板标记完好、每条打包序列内的损失掩码仍然只对 assistant。这一步不可跳过——打包 bug 是静默的损失曲线看起来正常只会在数小时后的评估质量中浮出水面。检查代码for seq in packed_dataset.select(range(10)): print(tokenizer.decode(seq[input_ids]))在/finetune的 Phase 2 流程中这一步被明确为强制而非抽查训练工程师必须解码并人工检查 5–10 条打包序列并把解码样本本身附加到验证报告中见 finetune.md而不是只写一行 pass/fail。合成数据规则防坍缩、生成方法与接受率预算SKILL.md的合成数据规则是数据规模扩大的防线四条规则层层递进保持 ≥25% 真实数据作为防坍缩底线。在越来越多模型生成数据上训练、却没有真实数据下限会在连续几代中驱动可测的质量坍缩——25% 真实数据是守住这条线的最低值。关键定义通用域 replay 行计入这条底线——这里的真实指不是为这个任务、由这个学生模型生成的而不是人类撰写的。一个全合成构造的数据集可以仅靠 replay 就满足 ≥25% 底线见 references/synthetic-data.md 的 Replay-Mix Construction 配方必须在数据集卡片中说明哪些行算作真实而不是让底线在结构上无法满足。Magpie 和 rejection sampling 是主力方法。Magpie 直接从模型自身的模板先验中抽取提示词rejection sampling 为每个提示词生成多个候选、只保留通过过滤器的那些。两者都优于朴素的一次生成。定向、学生感知的生成比静态生成高 1.3–2 倍样本效率——瞄准学生模型的实际失败模式用更少的过滤样本就能达到质量线。过滤后的典型接受率在 10–30%。据此规划生成量——以 10,000 行目标、15% 接受率计算需要约 65,000 条原始生成。生成方法排序与过滤漏斗references/synthetic-data.md 给出了从弱到强的生成方法排序按同预算下的样本效率与下游质量每一级都包含前一级——rejection-sampling 管线通常在其下用 Magpie 或 persona 条件提示词生成候选Self-Instruct——用模型改写和扩展少量种子集引导新提示词。最便宜也最弱提示词多样性快速触顶质量紧贴种子集。Evol-Instruct——跨代迭代改写提示词以增加复杂度加约束、加深推理、拓宽范围。难度覆盖优于 Self-Instruct但仍依赖种子。Magpie——无需种子提示词直接从目标模型自身聊天模板先验的 user 轮位置采样提取提示词。完全消除种子集偏差这是它成为主力而非小众技巧的原因。Persona-conditioned generation——以采样的人物/角色描述为条件生成提示词拓宽无条件单策略生成之外的风格与主题覆盖。Rejection sampling / verifier-filtered——每个提示词生成多个候选补全只保留过滤器/验证器/裁判接受的那些。它是补全侧的过滤器本身不是提示词生成方法可与上面任意方法组合。定向、学生感知的生成叠加在任意方法之上把提示词或人物选择引向当前学生模型的实际失败模式而非均匀采样这正是SKILL.md所引 1.3–2 倍样本效率的来源。它需要一个学生模型上的评估信号来获知其失败模式没有该信号生成就退化为非定向/静态的。过滤漏斗按成本从低到高排序廉价阶段应先用它削减体量昂贵阶段最后才在剩余小集合上运行见 references/synthetic-data.md精确去重——规范化合并空白/大小写后做哈希精确匹配。最廉价最先跑在后续阶段前清除生成循环重复。语义去重约 0.92 相似度阈值——嵌入每个候选丢弃与已保留行最近邻余弦相似度超过约 0.92 的行。捕获精确去重漏掉的改写级重复。长度过滤——丢弃低于最小或高于最大 token 长度的候选过短回答通常是退化的过长通常是啰嗦或跑题的。语言 ID 过滤——丢弃未通过目标语言检查的候选生成偶尔会漂移语言尤其是多语言基座模型在提示词描述不足时。基于分数的 top-30% 过滤——对剩余候选打分奖励模型、启发式或自洽性分数保留约前 30%——这是最昂贵阶段前的粗略质量切分。裁判 ≥ 阈值——把最昂贵的检查放在最后、最小的集合上LLM 裁判或人类等效质量检查对照固定阈值。此处失败的行无论上游得分如何都丢弃。SKILL.md的10–30% 典型接受率是漏斗端到端的整体产出率六阶段全通过不是任何单一阶段的通过率——必须按全漏斗产出率预算原始生成量。教师→学生蒸馏模式与 Replay-Mix 构造蒸馏不是特殊格式而是一条 provenance 标签references/synthetic-data.md先生成教师轨迹TEACHER对目标任务提示词分布采样补全含推理轨迹、用过滤漏斗验证蒸馏集也是合成数据集仍需 ≥25% 真实数据底线与同样的去重质量阶段、再用标准 SFT 格式与模板规则训练学生。TEACHER身份与生成配置采样温度、用于引出轨迹的提示词模板必须记录在数据集卡片的 provenance 字段——distilled fromTEACHER是/finetune与下游审计都期望在那里看到的事实。Replay-Mix 构造checkpoint-promotion灾难性遗忘升级阶梯的实现配方有五个按出现顺序排列的决策通用域来源选择——选真正通用域的来源两个要避免的失败模式不要教给闸门replay 源与漂移套件基准同分布会污染漂移分数测量若必须使用需按checkpoint-promotion的指令复用披露规则披露且存在更宽的来源时以更宽来源为更可辩护的默认把来源匹配到遗忘特征错误分析显示特定能力丢失时针对该能力的 replay 源恢复更快但会收窄通用域声明——都需在卡片中说明。提示词形态——自然指令、漂移测试台的确切措辞、或裸输入无指令包装三种形态各有权衡按遗忘特征而非默认选择并无论如何都在卡片中披露。答案重格式化——replay 参考答案是否向目标任务输出约定重格式化如把数学数据集的#### N终结符改写为目标任务的提取约定记录确切变换或无——保留源格式。验证集处理——验证集只含任务行eval_loss跨仅 replay 分数不同的运行直接可比但训练循环对 replay 拟合零可见性或验证集也含 replay 行循环内可见 replay 拟合但eval_loss不再与先前任务-only 验证集运行可对苹果比。两者皆非普适正确必须在卡片中说明选择与原因。不相交性验证——训练前必须验证 replay 行与漂移套件或 goldens 集不重叠分裂级分离 精确匹配文本过滤对照eval/goldens.jsonl规范化精确匹配命中即丢弃并在卡片中记录发现的重复数期望 0。还有一个硬规则后续运行改变 replay 分数时用交换而非添加——replay 行进入时把目标任务行移出训练集使总行/步数在旧与新运行之间保持恒定。添加行会同时改变 replay 分数与总优化步数使后续漂移分数变化无法归因。行数不是 token 数——1:1 交换保持行数恒定但 replay 行与目标任务行长度常不同交换仍可能移动总训练 token进而影响固定批次大小与打包方案下的max_steps应在新旧运行之间保持总训练 token 或直接保持max_steps恒定并在卡片中记录每轮的打包 token 数。全合成数据集与 ≥25% 真实底线当训练集按构造 100% 合成全新任务、根本无真实数据池可抽取而非在真实基座上大量合成增强时底线在定义上无法满足除非混合中的某些东西算作真实。解决方案通用域 replay 行计入 ≥25% 底线——真实在此规则中意为不是为这个特定任务、从这个特定学生模型生成的从既有通用指令数据集抽取的 replay 行满足该定义。按上述五决策构建 replay 混合后把 replay 行作为真实份额计算卡片所需的合成/真实比例并在卡片中明确说明这是如何满足比例的避免后续审计把全合成目标任务数据误读为悄悄跳过了防坍缩守卫。数据集卡片六字段闸门而非事后总结每份进入训练的数据集都必须有一张卡片——这是/finetune在启动前检查的必需 Phase 2 交付物。卡片不是自由格式文档必须携带以下六字段Provenance来源——每行来自哪里真实来源、合成方法或两者可追溯到trace-to-training-data的输出。Counts数量——总行数以及若划分了 train/eval/held-out 各 split 的行数。Synthetic/real ratio合成/真实比例——实测比例对照上面 ≥25% 真实底线检查。Dedup method去重方法——精确匹配、语义嵌入阈值或两者参见references/synthetic-data.md的过滤漏斗。Template used所用模板——确切的聊天模板字符串/标识符保持贯穿推理与评估一致——这正是把一次eval-harness-first运行与 checkpoint 关联起来的纽带。Packing config打包配置——是否使用打包、最大序列长度以及上面 5–10 序列人工检查确实已完成的确认。缺任一字段的数据集就不算为/finetune就绪——卡片是闸门不是事后补写的摘要。Phase 2 退出清单移交给 /finetune 前的六项确认在移交给/finetune之前逐项确认格式与目标方法匹配上文格式表。模板在拼接之前应用。损失只掩码到 assistant 轮次。5–10 条打包序列已解码并阅读。最终混合中 ≥25% 真实数据。数据集卡片完整——六字段齐全。对照/finetune的 Phase 2 闸门描述finetune.md数据集卡片与验证报告若用了打包须含解码样本必须按 Phase 2 Exit Checklist 完整Phase 3 才能开始缺失即停在该闸门而不是跳过或即兴推进。技能全景与参考索引dataset-curation处于微调技能网的枢纽位置周边协作关系见 SKILL.md 末尾的 References 与 Related skills如下上游finetuning-method-selection把路由决策送进本技能方法选择与数据形态判断trace-to-training-data是分级轨迹数据集graded-trajectory datasets的 provenance 来源。下游消费方lora-qlora-recipes、vision-sft、preference-optimization消费本技能产出的数据集eval-harness-first对最终 checkpoint 打分其运行通过数据集卡片的 Template used 字段与 checkpoint 关联。参考文档references/formats-and-templates.md——每种格式的 JSONL 示例、当前 TRL 掩码代码、ShareGPT 转换说明references/synthetic-data.md——生成方法排序、过滤漏斗、replay-mix 构造、教师→学生蒸馏模式。一个贯穿全文的提醒SKILL.md与参考文档中的所有代码示例都使用BASE_MODEL、TEACHER、STUDENT占位符仓库不推荐具体基座模型——实际 checkpoint 选择参见finetuning-method-selection的references/model-catalog.md。从格式选择、模板先行、打包检查、合成数据防坍缩到六字段卡片每一步都有明确的验证动作与失败模式对照这正是这套数据集整理方法论能在真实微调运行中落地、而不是停留在文档层面的原因。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考