合成十万条指令后，我总结出清洗数据比生成数据难十倍

为什么我放弃了人工标注，转而投奔合成数据

这个项目开始的时候，我其实是抗拒合成数据的。当时我们需要为一个企业内部知识库构建指令微调数据集，目标是让开源模型能在客服场景下准确回答技术问题。一开始我们走的是传统路线：找了一批领域专家，花了两个月时间，手工编写了两千条指令-回复对。每一条都包含一个用户问题、上下文片段和理想回答。听起来挺扎实，但问题很快就暴露了。首先，成本高得离谱——光人力就烧掉近十五万。更糟的是，不同专家的标注风格差异大，有的写得像学术论文，有的简短得像电报，导致一致性很差。我试着用这些数据微调了一个7B模型，结果在内部测试时，它对类似问题的回复经常风格飘忽，有时候长篇大论，有时候就丢个链接。我当时想，这样下去不行，得找别的路。

后来读了不少论文，看到GPT-4在生成高质量指令数据上的表现，特别是在Self-Instruct这类方法里，合成数据微调出的模型在不少基准上都能追平甚至超过人工标注。我决定赌一把。但说实话，刚开始我天真地以为点几下按钮就能产出完美数据。第一次尝试，我直接用GPT-4的API批量化生成指令，提示词写得很简单：“生成50个关于网络故障排除的客服指令”。结果一晚上跑出一万条，我高兴地导出CSV，打开一看，差点晕过去——近四成的内容是重复或高度相似的，有的只是把“路由器”换成“交换机”；还有不少指令本身就有逻辑矛盾，比如用户问“怎么连接WiFi”，但上下文给的却是蓝牙故障描述。更头疼的是，部分输出带有未过滤的技术术语滥用，甚至有少数涉及安全违规的虚构攻击脚本。这让我意识到，生成是快，但没有一套严格的清洗流水线，合成数据就是个花架子。从那天起，我开始把这项目当成数据工程来做，而不是模型调用。

让GPT-4乖乖产出多样化指令，我的“种子+约束”配方

解决了要不要合成的问题后，真正的挑战来了：怎么让GPT-4生成高质量且多样化的指令数据。我试过很多种方法，最后发现核心在于两样东西：种子库和约束策略。种子库就是一些精心挑选的起点，用来引导生成方向。我从现有内部工单系统里抽取了2000个真实用户问题，经过脱敏和简化，作为初始种子。这些种子覆盖了常见技术域，比如网络连接、权限管理、软件安装错误等。然后我用GPT-4对每个种子进行扩展，不是简单改写，而是让模型生成变体。提示词我设计成这样：给一个种子指令，要求模型生成三个不同难度的版本，同时保持领域一致。比如种子是“文件共享权限被拒绝怎么办”，生成的变体可能包括“我作为管理员如何批量设置只读权限”或“SMB协议端口被防火墙拦截怎么诊断”。这样一来，数据集的粒度就丰富了很多。

但光有种子不够，多样性还得靠采样参数和负采样机制。生成时我调高了temperature到0.8，但配合top_p采样来避免太离谱的输出。同时，我建立了一个正在生成的指令缓存，对每条新指令用sentence-transformers计算嵌入，如果与已生成集合的余弦相似度超过0.75，就丢弃并重试。这个负采样循环我后来写成了脚本，每次跑生成任务前先加载缓存，有效减少了冗余。代码大概是这样子：

from sentence_transformers import SentenceTransformer, util
model = SentenceTransformer('all-MiniLM-L6-v2')
def filter_generated(new_inst, cache_insts, threshold=0.75):
    if not cache_insts:
        return True
    new_emb = model.encode(new_inst, convert_to_tensor=True)
    cache_embs = model.encode(cache_insts, convert_to_tensor=True)
    scores = util.cos_sim(new_emb, cache_embs)[0]
    return scores.max().item() < threshold

另一个容易被忽略的点是指令的约束设计。我要求每条指令必须包含三个字段：意图、上下文、输出格式。意图指明用户真正想解决什么，上下文提供技术背景，输出格式约束回复的结构，比如“回答应分为步骤、原因和警告三部分”。这看似增加了生成复杂度，但实际上大大提升了后续微调模型的一致性。有一次我偷懒去掉这个约束，生成数据微调后模型经常跑题，给个错误码就返回天气信息，完全牛头不对马嘴。我意识到，约束不是限制创造力，而是给模型一个思维框架。在批量生成十万条指令的过程中，这个框架让数据有用率从不到30%提高到了85%以上。当然，生成阶段只是第一步，接下来清洗才是重头戏。

清洗流水线比生成更痛苦：去重、安全与质量评分的血泪史

我花了三周时间搭这条清洗流水线，现在回想起来，这三周比写业务代码累多了。流水线主要分三块：去重、安全过滤、质量评分，每一块都踩了无数坑。去重听起来简单，用嵌入相似度就好了，但实际执行时细节能把人逼疯。一开始我用spaCy的词向量做相似度，发现对技术指令不敏感，“Ping不通网关”和“ARP表异常”在语义上完全相关，但被当作雷同。换成sentence-transformers的all-MiniLM-L6-v2后效果好不少，但计算太慢，十万条数据两两对比要跑几个小时。我最后改用了FAISS索引加速，先粗聚类再细筛，把处理时间从4小时压到了20分钟。还有个头疼的，相似度阈值设多少？设太低会误删有效数据，设太高又漏掉重复。我做了个抽样，人工检查2000对，发现0.82是个甜蜜点。脚本最终版长这样：

import faiss, numpy as np
def efficient_dedup(instructions, model, threshold=0.82):
    embs = model.encode(instructions).astype('float32')
    index = faiss.IndexFlatIP(embs.shape[1])
    index.add(embs)
    D, I = index.search(embs, k=10)  # 近邻搜索
    keep = []
    for i in range(len(instructions)):
        if all(D[i][j]  i):
            keep.append(i)
    return [instructions[i] for i in keep]

安全过滤那块，我不能只靠关键词屏蔽。早期版本我用正则过滤敏感词，结果漏了一堆伪装的内容，比如“如何获取管理员密码”被拆成拼音混写。后来接入OpenAI的安全API，同时又建了一个内部黑名单，包括几百个常见攻击向量术语。更麻烦的是，安全评分有时会误杀正常教学指令，比如“演示SQL注入原理”本意是防御培训。我被迫加了一层人工抽检，但只抽5%的数据，然后训练了一个微小分类器来模拟决策。这个分类器就是用安全API打标的1万条数据微调distilBERT，召回率到了93%。质量评分是第三步，我让GPT-4自己当法官。给每一条指令打分，提示词是“评估这条指令的清晰度、技术准确性和有用性，从1到5分”。但GPT-4有偏向，给长指令打高分。我用了校准技术，每次送评分时随机混入几条人工标注的锚定样本，调整分数分布。效果还行，保留3分以上的数据后，微调模型的回复准确率提升了一个大段。

整个清洗下来，十万条原始数据剩下六万五千条，损失率35%。说实话，第一次看到这数字我心疼，但后来对比实验证明这是必须的。脏数据微调出的模型在安全评测里触发了12%的违规回复，清洗后降到了0.6%。这个经历教会我一个道理：合成数据的价值不在量，在质，而质量是洗出来的。

微调后的效果让我震惊：合成数据在有些任务上反超人工标注

最后一步就是验证这套数据能不能打。我选了一个Llama-2-7B模型作为基座，分别用三类数据微调：第一组是我那六万五清洗后的合成指令；第二组是外包公司提供的五千条人工标注指令，质量算中等；第三组是混合，二万合成加二千人工。微调都在4张A100上跑，每个配置三个epoch。评估我用了两个指标：自动化指标看ROUGE-L和BERTScore，但说实话自动化指标参考性有限，我重点放到了内部盲测上。找了五个不知情同事，让他们评估240个回复，从准确性、流畅性和安全性打分。结果让我有点意外。合成数据微调的模型在流畅性和格式一致性上全面占优，回复结构干净，步骤清晰。但人工标注组在部分高度专业化任务上更准，比如“配置多因素认证的AD策略”，因为标注员注入了隐性经验。合成数据在这些深水区偶尔会出现表面正确但实质错误的信息，也就是“幻觉”。混合组则基本取了两边的好处，整体最高。

具体数字是，盲测评分里合成组平均3.8分（满分5），人工组3.6，混合组4.1。安全扫描上合成组表现优异，几乎没有违规输出，人工组却有2%的轻度违规，因为标注员有时粗心留下了内部IP信息。成本方面，合成数据的边际成本低太多了，生成加清洗六万条花了200美元API费，加上几周开发时间折算，总成本不到一万；而仅买那五千条人工标注就花了九千美元，而且等了两周才交付。效率差异巨大。但有个反直觉的发现：合成数据多样性虽然高，但在冷门领域会出现模式崩溃。比如数据集中有约500条关于遗留系统的指令，微调后模型对类似问题总用同一种回复模板，像背答案一样。我怀疑是生成时种子覆盖不足，导致这些场景的表示过少。为了修补，我又回头添加了特定种子重新生成，效果改善。

简单说就是这个实验让我对合成数据有了更客观的认识。它不是银弹，不能完全替代人工，但在规模、成本和基础质量上优势明显。最关键的是那套清洗流水线，没有它，合成数据就是数字垃圾。我后来把这套工具链做了模块化，用Python封装成简单脚本，方便复用。分享出来，希望同事们少走我那些弯路。

清洗数据时，我踩过最大的坑是“伪干净数据”

刚拿到首批五万条合成指令的时候，我其实松了口气——格式规整，回复长度适中，粗读几条甚至觉得可以直接用。当时我们只做了一层最简单的清洗：剔除长度小于10 token的、纯符号的、以及包含模型拒绝回答的语句（比如“作为AI我无法…”），再跑了一遍SimHash去重。剩下的四万多条数据，我们用肉眼抽检了200条，正确率超过95%，于是我信心十足地推进了第一轮微调。

但实验报告出来的那一刻我就懵了。模型在内部测试集上的准确率不仅没有提升，反而在几个高频问法上出现了严重的模式崩塌——不管用户问的是“打印机驱动怎么装”还是“网络硬盘怎么挂载”，模型都倾向于用同一套话术回复，开头必带“您好，请按以下步骤操作”。更离谱的是，某些回答里把型号 A 的配置步骤原封不动地套在了型号 B 上，而这两个产品的菜单结构完全不同。这不是生成的问题，是清洗没到位。

我回头重新分析那批“干净”数据，才发现问题远比想象中复杂。简单规则和去重只能过滤掉那些明显坏掉的样本，而真正危险的，恰恰是那些看起来完美但实质上带着隐性缺陷的“伪干净数据”。我把它们分成了三类，每一类都逼着我们重新设计清洗流水线。

第一种：模板化回复污染

合成数据时，我们为了让模型产出格式统一的回答，在prompt里写了“请用亲切、条理清晰的方式回答”，结果生成器学会了一套万能模板：开头问候，中间分点列表，结尾追问是否需要进一步帮助。五万条数据里有近40%都嵌套了这个结构，但内容其实没有实质差异——当用户问题变种较少时，这种模板会被过度复制，最终导致模型把“格式”当成了“答案”本身。

自动检测这种污染并不容易，因为从单条数据看完全无害。我们的解法是利用n-gram重复度计算“模板签名”：对每条回复抽取1-4 gram的短语，计算在整个数据集中的短语频率，如果一条回复中高频短语的占比超过某个阈值，就标记为可疑。下面是我们当时写的一个快速检测脚本片段，基于CountVectorizer统计高频帧：

from sklearn.feature_extraction.text import CountVectorizer
import numpy as np

def template_ratio(texts, ngram_range=(3,4), top_k=50):
    vec = CountVectorizer(ngram_range=ngram_range, min_df=10)
    X = vec.fit_transform(texts)
    freq = np.asarray(X.sum(axis=0)).flatten()
    top_indices = freq.argsort()[-top_k:]
    top_ngrams = set([vec.get_feature_names_out()[i] for i in top_indices])
    
    ratios = []
    for text in texts:
        tokens = text.split()
        ngrams = set([' '.join(tokens[i:i+3]) for i in range(len(tokens)-2)] 
                     + [' '.join(tokens[i:i+4]) for i in range(len(tokens)-3)])
        overlap = len(ngrams & top_ngrams) / max(len(ngrams), 1)
        ratios.append(overlap)
    return ratios

我们将 ratio 超过0.35的数据全部拉出来人工复核，果然里面充斥着套话连篇的回复。后续我们在生成prompt中加入了“随机化输出结构”的指令，并在合成后主动过滤高模板化样本，才把这个窟窿补上。

第二种：事实嫁接错误

这是我们遇到的最阴险的一类脏数据。合成模型在生成时会把不同实体（如产品、版本、文档段落）的属性张冠李戴。例如针对“X200路由器如何重置？”的问题，回复里可能混入了X300的IP地址或完全错误的物理按钮位置，但整段语言看起来非常专业、流畅，连标点都用得恰到好处。

对于这类错误，基于统计的方法几乎全部失效。我们尝试过用NER（命名实体识别）抽取产品型号和技术参数，然后与知识库做比对，但合成数据的多样性让规则很难覆盖——型号可能被缩写、全称、代号等多种方式指代。后来我们采用了一种“软对抗”的思路：用少量人工标注的“事实一致性”样本微调一个轻量级检查模型。具体做法是，从知识库中构造一批正确的三元组，并故意生成一些错误嫁接的负样本，训练一个基于bert-base-chinese的实体匹配判别器。推理时，对于每条合成指令，我们用判别器对回复中出现的实体与知识库片段进行比对，输出一个置信度，低于阈值的就暂时剔除。

虽然这个判别器的准确率只有大约82%，但至少帮我们挡住了最致命的硬件配置类错误。剩余的可疑数据我们还是不得不依赖领域专家抽检，这一步至今无法完全自动化。

第三种：隐式格式断裂

最后一种脏数据往往出现在多轮对话指令或带特殊标记的模板中。例如我们有一部分数据是用ChatML格式包装的，合成时偶尔会出现角色标记缺失、对话截断、或者系统提示被错误嵌套到用户消息里的情况。单轮数据看起来没毛病，但一放到多轮上下文里，模型的state就乱了。我们用正则和解析器构建了一套严格的格式验证器，对所有合成数据做了解析测试，将无法被完美解析的样本直接打回重生成。这部分逻辑不算复杂，但在十万条规模下，光格式验证脚本就跑了一整夜，错误率高达2.3%，意味着有两千多条数据被白白浪费——而这些数据如果混入训练集，对模型多轮能力的损害是灾难性的。

走过这些坑我才真正理解，清洗数据从来不是一把筛子就能解决的问题。它是对领域知识、数据工程和模型行为的复合考验，每一步偷懒都会在微调结果里加倍偿还。那十万条合成指令最终被我们筛选到只剩三万多条可用，而花费在清洗上的时间，整整是生成阶段的十倍。