想象你是一位从零开始开餐厅的老板。你不需要一开始就买下整条街的铺面，也不需要立刻研发 5000 道菜——你需要做的，是想清楚这家店开给谁、主厨的招牌菜是什么、中央厨房怎么批量复制、摆盘标准是什么、品控怎么把关、菜单怎么留档，以及每季怎么根据顾客反馈换菜。构建指令数据集，本质上就是经营这样一家“数据餐厅”。你要为 LLM 准备一份高质量的训练菜单——指令微调数据集，让大模型通过这份菜单学会“好好干活”。这篇指南会带你走完从需求分析到持续迭代的完整七步，每一步都对应一个具体的工程动作。走完这一程，你手头不再是一堆杂乱文本，而是一套能支撑可靠训练的数据资产。

岗位关联

对 AI 从业者来说，指令数据集的构建能力是 LLM 微调工程的核心基本功——它直接决定微调效果的上限，也决定了你在算法团队里是“只会跑模型”还是“能养出好模型”。

目录
  1. 可视化演示
  2. 需求分析设计：先想清楚餐厅卖给谁
  3. 种子指令编写：主厨研发招牌菜
  4. 指令自动扩展：中央厨房量产
  5. 格式标准统一：摆盘标准上墙
  6. 质量审核把控：品控团盲测打分
  7. 版本管理记录：菜单留档可追溯
  8. 持续迭代更新：按顾客反馈换菜单
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

需求分析设计：先想清楚餐厅卖给谁

想开餐厅？先别急着买锅碗瓢盆。你得想清楚：这家店开在写字楼还是社区？客人是赶时间的白领还是带娃的家庭？主打麻辣川菜还是清淡轻食？——这就是指令数据集的第一步：需求分析。方向错了，后面再努力，也只是在给错误的客人做饭。

指令微调（让大模型通过看大量问答范例来学会干活）的第一步，不是找数据，而是把“模型将来要在什么场景下做什么事”写成一张需求清单。具体分四步：锁定目标场景（客服、写作、代码、摘要……），把场景拆成任务类型（生成、改写、抽取、问答……），为每个任务设计难度梯度（入门、进阶、挑战），最后估算数据规模。四步合成一张“场景-任务-难度”矩阵，相当于餐厅的经营定位书。

以智能客服为例：场景是“售前咨询”和“售后投诉”；任务类型包括意图识别、话术生成、情绪安抚；难度从“常见问题解答”到“多轮复杂纠纷”。每个格子放多少条样本，不能拍脑袋，要用规模公式估算——总指令数等于每个场景、每个任务、每个难度级别上的指令条数之和。

餐厅定位书越清晰，采购和排班越省心；任务矩阵越完整，后续写种子指令和自动扩展时就越不会跑偏。

Ntotal=∑s=1K∑t=1Ms∑d=1Dnt,d(s)\displaystyle N_{\text{total}} = \sum_{s=1}^{K} \sum_{t=1}^{M_s} \sum_{d=1}^{D} n_{t,d}^{(s)}
这条公式告诉你：总数据量不是“越多越好”，而是由任务矩阵的每一个格子累加出来的，缺了哪个格子，模型就在那个能力上偏科。
  1. 外层求和 KK 是目标场景数量。比如客服、写作、代码三个场景，K 就是 3，表示对每个场景分别计算。
    ∑s=1K\displaystyle \sum_{s=1}^{K}
  2. 中层求和 M_s场景 s 下有 M_s 种任务类型，例如客服场景里有意图识别和话术生成两种任务。
    ∑t=1Ms\displaystyle \sum_{t=1}^{M_s}
  3. 内层求和 D每个任务按难度分为 D 层，n 是某一难度层上应该准备的指令条数。
    ∑d=1Dnt,d(s)\displaystyle \sum_{d=1}^{D} n_{t,d}^{(s)}

种子指令编写：主厨研发招牌菜

定位想清楚了，主厨开始研发招牌菜。种子指令就是主厨手写的几道原创菜谱——数量不多，但每一条都体现食材搭配、火候拿捏和调味逻辑。招牌菜垮了，中央厨房批量复制出来的几百道菜也会一起垮。

种子指令（就是人工精心编写的、作为扩展起点的少量指令样本）要遵循“三要一不要”：要多样性（覆盖任务矩阵里所有任务类型）、要真实性（尽量来自真实用户提问）、要独立性（单条指令能独立理解）；不要写模型已经见过无数遍的网络套话。同时可以借鉴开源池——Alpaca、ShareGPT、Dolly 等公开数据集，相当于参考名店公开的菜单找灵感，但别直接照搬。

人工精写流程通常是：初稿 → 小组互评 → 修改 → 终审。每条种子可以用质量分公式量化打分：C 是清晰度，看指令会不会产生歧义；O 是覆盖度，看是否踩中任务矩阵的关键格子；N 是新颖度，看是否提供了新知识或新角度。三个分数加权求和，权重由团队根据目标场景自定义。

主厨的每道招牌菜都要反复试吃才能写进菜单，种子指令也要经过同样的评审才能进入下一道流水线。

Q(s)=wc⋅C(s)+wo⋅O(s)+wn⋅N(s)\displaystyle Q(s) = w_{\text{c}} \cdot C(s) + w_{\text{o}} \cdot O(s) + w_{\text{n}} \cdot N(s)
质量分不是摆设：种子阶段砍掉的低分指令，省的是一整个扩展批次的人力与算力成本。
  1. 清晰度 C(s)衡量指令表述是否无歧义。“写一段话”就不如“写一段 50 字的商品退货道歉文案”清晰。
    C(s)\displaystyle C(s)
  2. 覆盖度 O(s)衡量这条种子命中了任务矩阵中的哪几个格子，覆盖越广，后续扩展越省力。
    O(s)\displaystyle O(s)
  3. 加权求和w 是各项权重，三者相加得到最终质量分，用于排序、取舍与评审讨论。
    wc⋅C(s)+wo⋅O(s)+wn⋅N(s)\displaystyle w_{\text{c}} \cdot C(s) + w_{\text{o}} \cdot O(s) + w_{\text{n}} \cdot N(s)

指令自动扩展：中央厨房量产

招牌菜研发完毕，怎么从 50 道变成 5000 道？交给中央厨房。把菜谱投进自动化生产线，批量复制出不同口味的变体。但流水线有个老问题：批量生产会走样、会重复，所以必须加装过滤器。

自动扩展的主流手段是让 LLM 基于种子指令改写变体：改措辞、换场景、换角色、拆分子任务；也可以做模板化改写，把“解释什么是 X”套到不同概念上。扩展后得到的原始指令集合，必须经过两层过滤：去重（用文本相似度或 MD5 指纹加相似度聚类），以及质量门槛（规则打分或小模型打分）。实践中重复率超过 30% 并不罕见。

有效的产出规模需要提前规划，不能盲目追求“生成越多越好”。有效指令数等于原始产出量，先乘上“去重后的保留比例”，再乘上“通过质量检查的比例”。

中央厨房虽然快，但品控环节绝不能省；自动扩展同样需要周期性人工抽查，确保批量产品不砸招牌。

Nvalid=Nraw×(1−rdup)×rpass\displaystyle N_{\text{valid}} = N_{\text{raw}} \times \left(1 - r_{\text{dup}}\right) \times r_{\text{pass}}
这条公式提醒你：自动扩展狂飙出来的数据是虚胖，去重和质检之后剩下的才是模型的真营养。
  1. 去重保留率1 - r_dup 表示去掉重复指令后还剩多少比例。r_dup 是重复率，重复率越高，去重损失越大。
    1−rdup\displaystyle 1 - r_{\text{dup}}
  2. 质量通过率r_pass 是抽检或打分后保留的比例，例如 85% 的候选指令达到质量标准。
    rpass\displaystyle r_{\text{pass}}
  3. 三者连乘原始量先被去重削掉一层，再被质检削掉一层，最后才是真正能进训练集的有效量。
    Nraw×(1−rdup)×rpass\displaystyle N_{\text{raw}} \times \left(1 - r_{\text{dup}}\right) \times r_{\text{pass}}

格式标准统一：摆盘标准上墙

走进任何一家连锁餐厅，你会发现同一道菜的盘子、酱汁杯、甚至香菜摆放位置都一模一样。这不是强迫症，而是为了稳定出品。指令数据格式标准化也一样：让模型在训练时看到的每一条样本结构一致，学习才能稳定。

格式标准包含三层。第一层是对话模板：规定 system、user、assistant 的角色轮次怎么编排，例如 system 放全局设定，user 放用户指令，assistant 放期望回答。第二层是字段结构：常用四元组记录每条样本。第三层是序列化存储：通常导出为 JSONL 格式，每行一个 JSON 对象，方便流式读取。

字段结构四元组是社区广泛采用的事实标准。“instruction“ 是模型要执行的任务描述；”input“ 是可选的上下文或材料；”output“ 是期望回答；”meta” 存放来源、任务类型、难度、版本等元数据。字段缺失、类型错误、转义错误都是常见问题，因此要配合 JSON Schema 做自动校验，拒绝畸形样本进入训练管线。

统一的摆盘规则让顾客在任何分店都吃到一样的产品，统一的格式让模型在千百万条样本中稳定学到同一种行为模式。

ri=(instructioni, inputi, outputi, metai)\displaystyle r_i = \left( \text{instruction}_i,\ \text{input}_i,\ \text{output}_i,\ \text{meta}_i \right)
这条四元组定义了一条数据样本的“标准长相”：字段统一，模型才不会被各种各样的格式差异干扰。
  1. 指令字段告诉模型“你要做什么”。例如“把下面的通知改写成邀请函”。
    instructioni\displaystyle \text{instruction}_i
  2. 输入字段可选的上下文材料，没有上下文就填空字符串。
    inputi\displaystyle \text{input}_i
  3. 输出字段模型的期望答案，这是微调时模型主要学习的目标。
    outputi\displaystyle \text{output}_i
  4. 元数据字段记录任务类型、难度、来源、版本号等信息，方便追溯和筛选。
    metai\displaystyle \text{meta}_i

质量审核把控：品控团盲测打分

后厨热火朝天，但每批菜端出去之前都要过品控这一关：资深食客盲测、打分、找问题。数据集构建也一样，自动扩展出的指令不能直接拿去训练，得先通过质量审核。

质量审核有四个环节：分层抽样（按任务、难度、批次分层抽取，而不是随机乱抽）、规则评分（从相关性、正确性、流畅性打分）、一致性评估（多个审核员对同一批样本打分，用 Kappa 系数衡量尺子是否统一）、修正回流（问题样本送回扩展或重写环节修复）。这四步形成一个闭环，缺了任一环，质量都不可控。

Kappa 系数是审核环节最常被忽略却很重要的指标。p_o 是审核员彼此完全同意的比例；p_e 是假设两人随机乱猜也会碰巧同意的概率。Kappa 低于 0.6 说明审核标准不一致，打分结果不可信；高于 0.8 才算是合格水平。

品控不是为了找茬，而是让整条生产链越跑越稳。问题样本回流到种子编写环节，下一批扩展指令就会更干净。

κ=po−pe1−pe\displaystyle \kappa = \frac{p_o - p_e}{1 - p_e}
如果两名审核员一个手松一个手紧，Kappa 系数立刻暴露问题：两人的“一致”很可能是碰巧，而不是真有共识。
  1. 观察一致率 p_o两个审核员对同一批样本给出相同结论的比例，比如 200 条里一致了 160 条，p_o 就是 0.8。
    po\displaystyle p_o
  2. 随机一致率 p_e即使双方完全瞎猜也会相同的比例，由各类别的占比推算出来。
    pe\displaystyle p_e
  3. 整体比值分子是“比随机多出来的真实一致”，分母是“理想情况下最多还能一致多少”。扣掉运气，剩下的才是真实水平。
    po−pe1−pe\displaystyle \frac{p_o - p_e}{1 - p_e}

版本管理记录：菜单留档可追溯

餐厅的菜单不是一成不变的：春季菜单印错了字，改一版叫 PATCH；加了两道新菜，改一版叫 MINOR；餐厅整体转型，菜单大改版叫 MAJOR。版本管理让每一版菜单都有据可查——数据集也一样。

语义化版本号是数据集的身份证：MAJOR 表示不兼容改动（例如字段结构重构），MINOR 表示向后兼容的新增（例如新任务类别），PATCH 表示向后兼容的修复（例如错别字）。每次变更都要记录变更日志，内容包括改动内容、改动原因、操作人和时间。发布前要评审，重大变更要留回滚点。

如何量化两个版本差异有多大？用 Jaccard 相似度：两个版本样本集合的交集大小除以并集大小。J(A, B) 接近 1 说明变化很小，接近 0 说明几乎完全重写。训练前看一眼这个指标，就能判断“这次换数据对模型来说到底是一次微调还是一次重生”。

菜单版本留底，新主厨上任能看懂改动历史；数据集版本留底，模型训练结果才能被复现和追溯。

J(A,B)=∣A∩B∣∣A∪B∣\displaystyle J(A, B) = \frac{|A \cap B|}{|A \cup B|}
版本差异不是感觉出来的，而是算出来的：Jaccard 值低到一定程度，就意味着要按新项目对待，而不是简单继续训练。
  1. 交集分子同时出现在版本 A 和版本 B 里的样本条数，即两个版本共有的数据。
    ∣A∩B∣\displaystyle |A \cap B|
  2. 并集分母把两个版本的所有样本合在一起，重复的只算一次，得到的总量。
    ∣A∪B∣\displaystyle |A \cup B|
  3. 相似度比值分子除以分母得到 0 到 1 之间的相似度，越接近 1 表示两个版本变化越小。
    ∣A∩B∣∣A∪B∣\displaystyle \frac{|A \cap B|}{|A \cup B|}

持续迭代更新：按顾客反馈换菜单

餐厅最大的恐惧是开业三个月后没人来。聪明的老板会盯着线上点评、留意每桌剩菜、按季节调整菜单。指令数据集也不是一次建完就能用一辈子的资产，它需要持续喂养。

迭代闭环包含四步：线上反馈采集（从模型真实使用中收集翻车案例，业界常叫 badcase）、增量补丁构建（把 badcase 变成新的种子指令，只补充短板任务）、回归测试（确认旧版本的核心能力在新数据上不退化）、失效题淘汰（下架模型已熟练掌握或已被业务淘汰的冗余指令）。

在这四步里，增量占比是衡量每次更新幅度的核心指标。新增条数除以新旧总数，得到一个百分比。占比太高说明此前数据存在严重缺口，占比太低说明这轮迭代价值有限。实践中一次迭代的增量占比通常控制在 10% 到 30% 之间。

菜单常换常新，餐厅才有回头客；指令数据集持续迭代，模型才能在真实世界里保持竞争力。

Rnew=NnewNold+Nnew\displaystyle R_{\text{new}} = \frac{N_{\text{new}}}{N_{\text{old}} + N_{\text{new}}}
增量占比像餐厅的“上新率”：每季上新太少，顾客会腻；上新太多，说明原来的菜单本身没做好。
  1. 新增样本分子本轮新增补丁里的指令条数，例如 1000 条新收集的 badcase 改造指令。
    Nnew\displaystyle N_{\text{new}}
  2. 新旧总量分母旧数据加新数据，得到更新后的总条数。
    Nold+Nnew\displaystyle N_{\text{old}} + N_{\text{new}}
  3. 占比比值两者相除得到增量占比。10% 表示小步快跑，50% 以上则要回头审视旧数据的质量。
    NnewNold+Nnew\displaystyle \frac{N_{\text{new}}}{N_{\text{old}} + N_{\text{new}}}

AI 应用场景

智能客服助手微调数据构建

阶段：指令数据构建（需求设计 + 种子编写 + 自动扩展 + 质量审核）

解决的问题：客服数据散落在工单系统里，字段不一致、质量参差，直接训练会让模型学到脏数据。传统做法是人工整理几千条对话就开训，结果模型连“退款政策”和“退款进度”都分不清。用“场景-任务-难度”矩阵梳理客服业务，再走完整流水线，数据质量才有保障。

具体案例：某电商团队做售后智能助手：目标场景锁定“退款咨询”，任务类型含“政策解释、状态查询、安抚话术”；金牌客服人工精写 300 条种子指令；再调用 LLM 批量改写，替换商品牌名和订单细节，扩展到 1.5 万条；分层抽检后计算 Kappa 为 0.78，修订评审后发布 v1.2.0 进入训练。

代码助手的数据飞轮

阶段：问题回流 + 增量补丁 + 回归测试（持续迭代更新）

解决的问题：代码生成模型在私有框架上表现差，因为公开代码数据里几乎没有该框架的用法。传统方式是一次性买数据、一次性训练，效果三个月就失效。把用户反馈的失败案例作为新种子，增量补充私有框架问答对，才能形成数据飞轮。

具体案例：一家 DevOps 公司收集了 2000 条私有 API 问答的 badcase，构建“代码解释、缺陷定位、脚本生成”三类增量补丁。每次迭代约新增 15% 数据，三轮迭代后私有任务准确率从 41% 提升到 76%，公共代码能力回归测试零退化。

法律文书摘要的一致性格审

阶段：质量审核（Kappa 一致性评估）

解决的问题：两位律师对同一份判决书的摘要重点经常不一致，导致标注标准漂移。传统流程只检查“有没有错别字”，不检查“两个人的标准是否一致”，数据标注越多，噪声越大。引入 Kappa 系数后，可以在批次层面拦截系统性偏差。

具体案例：法律科技团队为“判决书摘要生成”项目标注 5 万条数据，每批 200 条双人背靠背审核，Kappa 低于 0.6 时暂停标注并重新对齐标准，稳定在 0.82 以上才放行进入训练，最终模型摘要的 F1 提升 22%。

Python 演示

python80 行
import jsonimport hashlibimport randomfrom collections import Counter  class InstructionDataset:    """指令数据集构建流水线: 种子 -> 扩展 -> 去重 -> 质检 -> 导出"""     def __init__(self, version="0.1.0"):        self.version = version        self.records = []        self.category_counts = Counter()     def add_seeds(self, seeds):        """人工编写或收集的种子指令"""        for item in seeds:            item["category"] = item.get("category", "general")            self.records.append(item)            self.category_counts[item["category"]] += 1     def expand_by_template(self, variants_per_seed=3):        """基于改写模板做简单扩增"""        expanded = []        templates = [            "请回答: {instruction}",            "帮我想想: {instruction}",            "用简洁的话说明: {instruction}",        ]        for item in self.records:            for t in templates[:variants_per_seed]:                new_item = dict(item)                new_item["instruction"] = t.format(instruction=item["instruction"])                expanded.append(new_item)        self.records = expanded     def deduplicate(self):        """按指令 MD5 摘要去重"""        seen = set()        kept = []        for item in self.records:            digest = hashlib.md5(item["instruction"].encode("utf-8")).hexdigest()            if digest not in seen:                seen.add(digest)                kept.append(item)        self.records = kept     def export_jsonl(self, path):        """导出为标准 JSONL 文件"""        with open(path, "w", encoding="utf-8") as fp:            for item in self.records:                fp.write(json.dumps(item, ensure_ascii=False) + "\n")     def quality_check(self, rate=0.2):        """随机抽检并返回通过率"""        if not self.records:            return 0.0        sample_size = max(1, int(len(self.records) * rate))        sample = random.sample(self.records, sample_size)        bad = 0        for item in sample:            instruct = item.get("instruction", "")            output = item.get("output", "")            if len(instruct) < 6 or len(output) < 6:                bad += 1        return round(1 - bad / len(sample), 2)  if __name__ == "__main__":    ds = InstructionDataset(version="0.2.0")    ds.add_seeds([        {"instruction": "解释什么是学习率", "output": "学习率控制模型每步更新的幅度。", "category": "科普"},        {"instruction": "把这段话改写成邀请函", "output": "尊敬的用户，诚挚邀请您参加本次活动。", "category": "改写"},    ])    ds.expand_by_template(variants_per_seed=2)    ds.deduplicate()    print("扩展后总条数:", len(ds.records))    print("类别分布:", dict(ds.category_counts))    print("抽检通过率:", ds.quality_check(rate=0.5))    ds.export_jsonl("instruction_dataset.jsonl")
目的：用不到 60 行 Python 实现一个极简的指令数据集流水线，演示种子添加、模板扩展、去重、质检和 JSONL 导出的完整闭环。
  1. self.category_counts = Counter()用计数器记录每类种子数量，方便观察任务分布是否均衡
  2. templates[:variants_per_seed]控制扩展倍数，避免一次生成太多导致数据爆炸
  3. hashlib.md5(...).hexdigest()生成指令指纹，快速去重，是“中央厨房”的第一道过滤器
  4. random.sample(self.records, sample_size)随机抽检保证样本代表性，模拟分层抽样的简化版
  5. json.dumps(item, ensure_ascii=False)保留中文直接写入 JSONL，保证数据可读
  6. quality_check(rate=0.5)演示时把抽检率提到 50%，平时建议按批次 5%-10% 抽检

常见误区

误区团队以为指令数据量越多越好，从网上爬了上千万条“问题-回答”直接丢给模型训练，结果效果反而变差，还白白烧掉大量训练经费。

正解数量堆不出质量。重复、错误、格式混乱的样本会变成噪声，模型不仅学不到能力，还会把错误表达一并记下。应该走“任务矩阵 + 种子 + 自动扩展 + 质量门”的流水线，保证每条样本都有明确任务、正确答案和统一格式。餐厅堆再多食材，不洗不切不调味，也做不出好菜。

为何常见：预训练阶段确实依赖海量数据，很多人把预训练的“大力出奇迹”惯性思维带到了指令微调阶段，忽略了两个阶段的学习目标完全不同。

误区让 LLM 自动生成几万条指令，复制粘贴进 JSONL 就能训练了。肉眼抽查几条觉得不错，就以为整体都没问题。

正解LLM 生成的内容天然带有幻觉、重复和分布偏差。自动生成只能当“生产线”，不能当“质检员”。必须配套去重、规则过滤和分层人工抽检，发现问题批次整批回炉。流水线上出来的菜，上桌前必须过品控，这是连锁餐厅的底线。

为何常见：LLM 生成样例看起来“很像那么回事”——语法通顺、结构完整，但单个样本的正确性不等于整个分布的正确性，系统性偏差很难靠肉眼发现。

误区有人觉得反正模型能理解自然语言，字段名乱一点、角色轮次随意一点没有关系，语义对就行。

正解指令微调阶段模型在学习“稳定的行为模式”，字段混乱会让训练信号在不同格式之间反复横跳，事倍功半。统一 instruction/input/output/meta 结构并用 Schema 校验，模型才能稳定地把“看到标准输入”和“给出标准输出”绑定起来。

为何常见：人类阅读时会自动修正格式差异，所以觉得“格式无所谓”。但模型只认统计规律，格式不一致会稀释学习信号，这是人的直觉与模型学习机制的错位。

误区团队建好一份数据集就反复复用，甚至直接覆盖旧文件。哪天效果崩了，谁也说不清上一次训练用的是哪一版数据。

正解没有版本管理就无法复现训练结果。语义化版本号 + 变更日志 + 回滚点构成数据工程底线。每个版本发布前要评审，重大变更要留回滚点，否则一次错误的数据更新会把整个迭代链拖垮。

为何常见：小团队往往没有专职数据工程师，git 只管代码，忽略了数据也是需要版本管理的重要资产。

误区觉得种子指令反正是给自动扩展当引子的，随便写几条意思一下，后面靠 LLM 批量生成就够了。

正解种子是扩展的上限，不是下限。种子覆盖不到的任务空间，扩展也覆盖不到。种子质量决定整个数据集的骨架，宁缺毋滥。就像主厨的招牌菜如果敷衍了事，中央厨房复制出来的只会是几百份同样的敷衍。

为何常见：种子阶段样本量小，看不出规模效应，容易让人低估它的杠杆作用——但恰恰是这个小样本，决定了后续所有数据的方向。

面试题

Q1. 构建指令数据集时，第一步应该做什么？

单选题 · easy

  • A.批量下载网络文本并清洗
  • B.明确目标任务与业务场景← 正确答案
  • C.训练一个专用的生成模型
  • D.采购第三方商业标注数据

答案：B。指令数据集构建的第一要务是需求分析，明确目标任务与业务场景，相当于餐厅开业前先定菜品定位。批量下载文本、训练生成模型、采购数据都是后续动作，没有清晰的任务矩阵，这些动作都是无源之水。

Q2. 种子指令在数据集构建中的主要作用是什么？

单选题 · easy

  • A.覆盖核心任务空间与难度← 正确答案
  • B.减少数据集的存储体积
  • C.替代全部的大规模扩展
  • D.隐藏训练数据的敏感信息

答案：A。种子指令是人工精写的高质量样本，作用是覆盖核心任务空间与难度层级，是自动扩展的骨架。它不能替代扩展，也不负责压缩体积或隐藏信息，所以后三个选项都不对。

Q3. 指令自动扩展最常用的自动化方式是？

单选题 · easy

  • A.人工逐条手写变体样本
  • B.调用大模型批量生成变体← 正确答案
  • C.爬取搜索引擎相关问答
  • D.从数据库随机拼装字段

答案：B。自动扩展的主流做法是让 LLM 基于种子指令批量改写变体，即“中央厨房”模式。人工手写效率太低，爬取问答缺少任务目标，随机拼装字段会制造噪声，都不适合作为生产手段。

Q4. 下列哪一项属于指令格式标准化的目标？

单选题 · mid

  • A.统一字段结构与对话模板← 正确答案
  • B.降低服务器磁盘的占用率
  • C.缩短模型推理时显存消耗
  • D.减少购买数据的预算成本

答案：A。格式标准化要解决的是字段结构、对话模板和序列化存储的统一问题，让模型学到稳定的行为模式。磁盘、显存和预算都不是格式标准化的直接目标。

Q5. 质量审核中引入 Kappa 系数的目的是什么？

单选题 · mid

  • A.比较数据压缩前后的体积
  • B.衡量审核员超出偶然的一致性← 正确答案
  • C.测试数据在磁盘上的读写速度
  • D.统计样本指令的平均文本长度

答案：B。Kappa 系数剔除了随机巧合因素，衡量审核员之间的真实一致性。它不看体积、速度或长度，而是回答“两位食客都说好，是真的好，还是碰巧都觉得行”。

Q6. 语义化版本号 2.3.1 中的数字 3 代表什么？

单选题 · mid

  • A.主版本号，表示不兼容重构
  • B.次版本号，表示新增兼容功能← 正确答案
  • C.补丁版本号，表示修复缺陷
  • D.构建序号，表示自动构建次数

答案：B。语义化版本号是 MAJOR.MINOR.PATCH 三段式，2.3.1 中 3 是次版本号，代表向后兼容的新增功能。主版本对应第 1 段，补丁版本对应第 3 段，与构建序号无关。

Q7. Jaccard 相似度计算两个数据集版本差异时，分母是什么？

单选题 · hard

  • A.两个版本数据集的交集大小
  • B.两个版本数据集的并集大小← 正确答案
  • C.新版数据集的总样本条数
  • D.旧版数据集的总样本条数

答案：B。Jaccard 相似度是交集大小除以并集大小。分母是两者的并集，即所有样本去重后的总和。并集越大说明两个版本共享内容越少，相似度越低，差异越大。

Q8. 计算新增指令增量占比时，正确的分母是哪些？

多选题 · hard

  • A.新增条数加上旧数据集总条数← 正确答案
  • B.更新后数据集的总样本条数← 正确答案
  • C.旧数据集总条数乘以二倍
  • D.新增条数减去旧数据集总条数

答案：AB。增量占比 = 新增条数 /（旧条数 + 新增条数），而“更新后数据集的总条数”在只做增量追加的语义下与新旧总数相等，所以 A 和 B 都对。C 只有在新增恰好等于旧数据时才成立，D 是减法，明显错误。

Q9. 质量审核抽样环节应重点覆盖哪些维度？

多选题 · mid

  • A.不同的任务类型与难度层级← 正确答案
  • B.不同的自动扩展批次来源← 正确答案
  • C.只采样模型预测正确的样本
  • D.只抽取最早的种子指令样本

答案：AB。分层抽样要按任务类型、难度层级和扩展批次等维度分层覆盖，保证每个角落都被审到。C 和 D 都是“只采样部分样本”的偏颇做法，无法代表整体质量。

Q10. 关于语义化版本管理，以下说法正确的有哪些？

多选题 · extreme

  • A.不兼容字段重构应升级主版本号← 正确答案
  • B.修复错别字应升级补丁版本号← 正确答案
  • C.新增兼容功能应升级次版本号← 正确答案
  • D.数据集不需要保留任何历史版本

答案：ABC。语义化版本号规定：主版本号用于不兼容的重构，次版本号用于向后兼容的新增功能，补丁版本号用于向后兼容的缺陷修复。数据集作为训练资产必须保留历史版本以便复现和回滚，D 与版本管理的基本理念完全相悖。