去年我做过一个特别蠢的决定。 老板让团队把智能客服的意图识别准确率提上去，我第一个念头就是微调 Llama-3-8B，毕竟开源，毕竟谁都在吹。 折腾了三天，LoRA 参数全配好（rank=8, lr=1e-4, batch_size=32），但测试集 F1 一直在 71% 附近抖动。 模型不是没反应，但就是到不了那个所谓的 SOTA 值。 后来我实在没招，打开训练集去抽了 1000 条样本，发现 239 条标签错得离谱——客户在对话框里刷了一屏“我要退款”，后台标注却被人为改成“投诉”。 那一瞬间我觉得自己不是 AI 工程师，而是洗碗工——锅糊了，你换再贵的炉子也没用。
这个经历让我意识到一个大家都不愿意承认的事实：模型选型带来的收益，越来越不如数据质量带来的收益。 对比一下就明白了。 传统软件工程里面，出错一定有 stack trace，代码逻辑是确定的，你能顺着调用链一步步找到问题；AI 项目呢？ 损失函数 training loss 下不去，你根本分不清是标签噪声、特征泄漏、模型容量不够、优化器选错，甚至只是 CUDA 环境有 bug。 背后的原因在于软件开发是“确定性建造”，AI 开发更像是“材料冶炼”——矿石品位决定最终成材的下限，熔炉只看能不能不浪费它。 所以别把敏捷开发那套照搬过来，动不动就估点、排期，AI 项目里最大的不确定性根本不是代码量，而是数据的“品位”到底几成。
别人问我那怎么把数据品位搞上去？ 我的土办法先建立一条数据置信度基线。 具体操作三件事。 第一，每批新数据到手，先抽 200～300 条，请三个不同背景的标注员独立重新标注，然后算 Cohen's Kappa；如果低于 0.8，说明标注标准出了问题，此刻不要碰模型，把所有数据都送到人机协同清洗流程里。 第二，不用大模型，先用 TF-IDF 词频基线跑一次 5 折交叉验证，把置信度低于 0.6 的样本全部捞出来，让标注主管复核；土办法找出来的脏数据往往比几千块的预标注 API 更准，因为模型复杂反倒会把错误“合理化”。 第三，训练过程中实时记录每个 batch 的预测熵，如果熵突然暴涨，立刻停在当前 epoch，去检查是不是有从未见过的新意图混进来，而不是条件反射去调低学习率。 这三步很简单，但救过我好几次。
具体到去年的客服项目，这些笨功夫带来什么结果？ 我把 2.7 万条工单重新过了三遍清洗和一致性校验，最终标签 Cohen's Kappa 从 0.47 提到 0.91。 这中间一个模型参数都没加，还是那台普通服务器上跑的 bert-base-chinese，F1 从 0.72 涨到 0.85。 为验证‘模型大才有用’，我故意把网络层数加倍，参数量膨胀差不多 180%，结果 F1 只多了 0.02，还开始过拟合。 反观数据清洗的花费：三个人，两个星期，加上几十杯咖啡，总共大约一万二的人力成本。 拿一万二换 13 个点的 F1，不比烧十万算力卡强？ 这笔账我觉得不难算。
当然，这种论调在算法工程师圈子里不讨喜，毕竟搞网络结构、写改进论文多体面，涮数据总透着一股人工气。 可我看过太多客户的项目了，十几万租来的 A100 跑微调，却连一份像样的标注规范都没有。 最后模型确实训出来了，一到线上人工接管率超过 40%，用户问“退货流程”它回复“感谢您的理解”，活脱脱人工智障。 所以我最后想说的是：AI 开发的下一波红利，不太可能是 attention 的又一个变体，也不该依赖算力疯狂膨胀，更可能是有人愿意把数据当一个真正的产品来治理。 这条路不酷，不性感，但老老实实做数据的团队，一定能活到下一轮大模型泡沫退潮以后。
