SFT（有监督微调）的数据集格式
P0 · llm_training
📊 考点：sft · llm-training
🏷 标签：supervised-fine-tuning, dataset-format
1️⃣ 考察意图
面试官想考察你对 LLM 微调流程中“数据工程”环节的掌握程度，而非简单背诵格式。核心是：你是否理解 SFT 数据格式背后的设计逻辑，以及它如何直接影响模型的对齐效果和泛化能力。刁钻点在于：很多人只背了 Alpaca 格式，却不知道为什么需要 system 字段、为什么多轮对话要区分 role、以及数据量级与格式复杂度之间的 trade-off。答好了能展示你对数据构建、任务适配和训练效率的实战理解，这是大厂做模型微调的基础硬实力。
2️⃣ 标准答
SFT 数据集的核心是 “输入-输出对”，但实际落地远比这复杂。我从三个层面拆解：基础格式、任务适配、以及数据质量工程。
基础格式：JSONL 是工业标准
- JSONL（每行一个 JSON 对象） 是主流，因为可逐行读取，适合大规模数据，且易于并行处理。CSV 或纯 JSON 数组（一个文件包含所有数据）在大数据量下会爆内存。
- 核心字段：
instruction（指令）、input（可选上下文）、output（期望输出）。这是 Alpaca 格式的变体，适用于单轮指令任务。 - 多轮对话：必须用
messages数组，每个元素包含role（system/user/assistant）和content。例如 OpenAI 的 ChatML 格式：为什么这么做？ 因为模型需要学习对话的上下文结构，区分不同角色的发言，才能在推理时正确响应。如果只用instruction+output拼接多轮，模型会混淆谁在说话。
任务适配：格式决定模型能力边界
- 分类任务：格式可以是
{"instruction": "判断情感", "input": "这家店真差", "output": "负面"}。但注意：输出必须是模型能理解的 token 序列，不要用数字标签（如 0/1），否则模型学不到语义映射。 - 生成任务：如摘要、翻译，
output需要是完整句子。坑点：如果output过长（>2048 tokens），训练时会被截断，导致模型学不到完整逻辑。解法：对长文本做分块（chunking），或使用支持长上下文的模型（如 YaRN 扩展 RoPE）。 - 代码生成：
output需要包含代码块标记（如 ````python），否则模型不会生成结构化代码。**实际落地的坑**：如果数据中代码和自然语言混排，模型容易在推理时“忘记”输出代码格式。解法：在output中显式加入\n` 和缩进，并做数据增强（如随机插入注释）。
数据质量工程：比格式更重要
- 去重：使用 MinHash 或 SimHash 对
instruction和output做近似去重。为什么？ 重复数据会让模型过拟合到特定模式，降低泛化能力。例如，1000 条“写一首诗”的重复指令，会让模型只会写诗。 - 质量过滤：用规则（如长度、特殊字符比例）或模型（如 GPT-4 打分）过滤低质量数据。trade-off：过滤太严会丢失多样性，太松会引入噪声。经验值：保留 70-80% 的数据，剩余用模型重写。
- 平衡性：确保不同任务类型（问答、摘要、翻译）的数据量大致均衡。坑点：如果翻译数据占 90%，模型会变成翻译器，其他能力退化。解法：按任务类别做分层采样（stratified sampling）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从格式规范、任务适配、数据工程三个层面回答。格式上，工业界用 JSONL，单轮用
instruction+input+output，多轮用messages数组区分角色。任务适配时，分类任务输出用自然语言标签，代码任务要加代码块标记。数据工程上，必须做去重、质量过滤和类别平衡，否则模型会过拟合或能力退化。总结一句：SFT 数据格式不是死板的模板，而是服务于对齐目标和训练效率的设计。”
4️⃣ 高频追问 & 应对
追问 1：如果数据量只有 1000 条，怎么设计格式才能让模型效果最好？
核心思路是数据增强 + 格式多样性。首先，不要只用一种格式（如 Alpaca），而是混用多轮对话格式（ShareGPT）和单轮格式，让模型看到不同结构。其次，对每条数据做改写（paraphrase），用 GPT-4 或 T5 生成 3-5 个变体，增加指令多样性。最后，在
output中引入少量错误修正（如故意写错再纠正），模拟真实对话中的纠错场景。关键取舍：数据量少时，宁可牺牲一点质量（如保留部分噪声），也要保证多样性，因为过拟合比噪声更致命。
追问 2：多轮对话格式中，system 字段可以省略吗？什么时候必须用？
可以省略，但取决于任务。如果模型需要遵循全局规则（如“你是一个客服”），
system字段是必要的，因为它定义了模型的行为基调。如果只是简单问答，system可以合并到第一轮user消息中。实际坑点：有些开源模型（如 LLaMA 系列）在预训练时没有system字段，微调时突然加入会导致分布偏移。解法：要么在微调数据中统一使用system，要么完全不用，保持一致性。
追问 3：如何评估 SFT 数据格式的好坏？有没有量化指标？
有，但间接。最直接的是训练收敛速度：在相同模型和超参数下，好的格式会让 loss 下降更快、更平滑。其次，在验证集上对比不同格式的 BLEU/ROUGE 或人工评分。工程方法：做 A/B 测试，用同一份数据但不同格式（如 Alpaca vs ChatML）微调两个模型，在 100 条测试集上对比。注意：格式差异对效果的影响通常小于数据质量，所以优先保证数据干净、多样。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“SFT 数据格式就是 JSON，包含 prompt 和 response 两个字段” → ✅ 正确切入：必须区分单轮和多轮，多轮要用
messages数组和role字段，否则模型学不会对话结构。 - ❌ 说“数据量越大越好，格式不重要” → ✅ 正确切入：格式决定了模型如何理解上下文，错误格式会导致训练不收敛或推理时输出混乱，数据量再大也没用。
- ❌ 说“所有任务都用 Alpaca 格式就行” → ✅ 正确切入：分类任务需要自然语言标签，代码任务需要代码块标记，生成任务需要控制输出长度，格式必须适配任务。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“数据格式如何影响检索增强”切入，例如多轮对话格式中
system字段可以存储检索到的文档，让模型学会在上下文中引用。 - 如果你只做过传统 NLP：用“序列标注 vs 生成任务”类比，说明 SFT 格式本质是“输入-输出”映射的扩展，传统 NLP 的 BIO 标签格式可以迁移到 LLM 的
output字段设计。 - 如果你是校招无项目：聚焦“Alpaca 格式 vs ShareGPT 格式”的论文复现，展示你对开源数据集的格式差异和训练效果的理解，可以提一句“用 LoRA 微调 LLaMA-7B 对比两种格式的 loss 曲线”。
7️⃣ 延伸阅读
- 《Stanford Alpaca: An Instruction-following LLaMA Model》（Alpaca 数据格式原始论文）
- 《Training Language Models to Follow Instructions with Human Feedback》（InstructGPT 数据构建方法）
- 《ShareGPT: A Dataset for Multi-turn Dialogue》（多轮对话格式参考）
- 《MinHash for Near-Duplicate Detection》（数据去重工程实践）
- 《ChatML: A Chat Markup Language》（OpenAI 多轮对话格式规范）