一、项目背景

某客服场景想用 LoRA 微调让模型更贴自家话术，但初版训练数据是从历史会话直接扒的。我们抽查时发现，里面混着脏话、客户隐私字段、还有大量答非所问的劣质样本。第一次训出来的模型反而更爱胡说，把客户的订单号当闲聊吐出来，吓得团队赶紧下线。这件事给所有人上了一课：微调不是把数据丢进去就行，数据质量直接决定模型是变好还是变坏。

更深层的问题是，团队之前没有数据清洗的规范，谁导出数据谁就直接喂，口径完全靠个人自觉。我们进场时，连一份像样的训练数据清单都没有，根本不知道模型到底学了些什么脏东西。

二、落地场景

我们把微调拆成数据、训练、评估三段治理。微调语料清洗是第一段，做去噪、去隐私和脱敏，把脏样本和泄露样本剔掉。质量分层标注是第二段，按样本质量打标，优质样本多喂、劣质样本直接弃，而不是一股脑全塞进去。训练评估指标单独建，除了常规的 loss，还看领域任务的准确率和幻觉率，因为我们真正关心的是它在客服场景下答得对不对、会不会编造。版本回归放在最后，每次新版本都要和上一版在相同测试集上比，防止越训越退，也方便我们向业务方证明新版本确实更好。

案例片段（已脱敏）： 微调语料清洗与质量分层配置片段（示意）：finetune_data:  dedup: true  pii_mask: [phone, order_id, name]  quality_tiers: [A, B, C]  drop_tier: C eval:  test_set: curated_500  metrics: [accuracy, hallucination, regression]清洗后训练集从约 12 万条降到约 7 万条，质量合格率从约 58% 提到约 92%。微调后领域任务准确率从约 71% 升到约 88%，幻觉率从约 9% 降到约 3%，版本回归通过率保持百分百。

三、关键技术挑战与解决思路

第一个坑是隐私泄露。初版直接喂原始会话，模型把订单号学进去了。我们建了 PII 识别加脱敏流水线，订单号、手机号、姓名统一打码，训练数据里一丝真实信息都不留。这一步现在看是底线，不是优化项，任何客户数据进训练前都必须过这道。

第二个难点是质量分层的标准。什么叫好样本没有统一说法，我们拉了三轮人工标注对齐，定下 A 类是对话完整且话术规范、B 类是基本可用、C 类是噪声，C 类直接丢弃。这里踩过的亏是早期不舍得丢数据，把 C 类也喂进去，结果拉低了整体效果。我们后来接受了一个观念：微调里删数据比加数据更重要。

第三个点是回归测试集的维护。测试集不能一成不变，要随业务话术更新。我们设了季度刷新，但保留一部分固定样本做长期对比，防止指标假涨。有一次新版本在刷新集上分数高了，但固定集上掉了，一查是测试集偏向了新话术，这才没被假涨骗过去。

四、效果数据

清洗后训练集约 7 万条，质量合格率约 92%，微调后领域准确率约 88%，幻觉率约 3%，版本回归通过率百分百。模型终于能稳定用在生产，而不是上线即翻车。我们统计过，清洗前后同样一轮训练，准确率差了约十七个点，这十七个点全靠把脏数据剔掉。（数据均为脱敏示意值）

还有一点值得记下来：清洗不是一次性的。业务话术在变，新的脏模式会不断冒出来，我们把清洗规则做成了可配置的策略集，发现新的污染类型就加一条规则，不用改代码。评估环节我们也接了线上采样，生产里模型答错的样本会自动回流到测试集，形成闭环，这样回归测试集始终贴近真实分布。我们后来把这套数据治理的流程文档化，新接一个业务线做微调时，直接套用同一套清洗和评估骨架，踩坑少了一大半。数据治理这件事，前期麻烦，后期越用越省，是典型的先苦后甜。

我们在数据治理上还做了一个容易被忽略的动作，就是训练数据的版本化。每一版清洗后的训练集都打上版本号和对应的规则集编号，哪天线上模型表现异常，可以精确回溯当时喂了什么数据。这个习惯在一次线上回滚时帮了大忙，我们快速定位到是新一版数据引入了一批标注偏差的样本。版本化听起来琐碎，但在微调这种数据敏感的环节，它是兜底的安全绳，没有它出了问题只能靠猜。

我们后来把数据质量当成一个持续的指标在盯，而不是上线一次就结束，因为模型会跟着数据一起慢慢变老，只有把清洗和评估做成日常动作，效果才能稳得住。

五、可复用经验总结

微调是垃圾进垃圾出最典型的场景，数据清洗花的功夫远比调参多，语料不干净，模型再大也救不回来。隐私脱敏是底线不是优化项，别等泄露了才补。质量分层要敢丢数据，C 类硬留只会拉低整体。回归测试集要维护但不能全换，固定样本做长期对比才有意义。我后来判断，微调项目成败七成在数据，三成在训练。很多团队把精力全花在调 LoRA 参数上，却不肯花半天清洗数据，本末倒置。