对抗验证：AI 系统快速调试法

多年来，我一直依靠一种直截了当的方法来识别模型输入或训练数据中的突然变化，这被称为"漂移"(drift)。这个方法叫做对抗验证(Adversarial Validation)，既简单又有效。最妙的是？它不需要任何复杂的工具或基础设施。

Drift 导致 AI 中出现 bug 的例子：

• 用于评估的数据与模型在生产环境中接收的输入存在本质差异，导致评估结果具有误导性。
• 对 prompt、函数、RAG 等元素的更新没有纳入微调或训练数据，导致模型在生产环境中出现意外行为。

无论你有多小心，bug 仍然可能漏网。一项高 ROI 的活动是定期审计你所有的 AI/ML 项目中的 drift。

这个方法是如此简单，以至于可能看起来不够酷。你不会给任何数据科学家留下深刻印象。尽管如此，它太有价值了，不能忽视。

我关于 MLOps 工具演讲中的这张幻灯片解释了对抗验证背后的技术²：

过程如下：

收集两个数据集进行比较。例如：

• 来自两个不同微调运行的训练数据
• 训练数据 vs. 评估数据
• 训练数据 vs. 生产数据（组织成相同的格式）
• 来自两个不同时间段的数据

从数据集中创建特征。这里展示了一个从 token 创建特征的基本示例³。

给数据集 #1 标记为 0，给数据集 #2 标记为 1。

拟合一个二分类器（随机森林、逻辑回归等）来区分两个数据集。

如果分类器表现出足够的预测能力（例如：AUC >= 0.60），我们就知道存在 drift。

如果你使用的是可解释模型（如逻辑回归、随机森林等），你可以检查特征重要性指标来理解 drift 的根本原因。如果你使用更复杂的模型（如神经网络），你可以使用 SHAP 值或其他方法来理解导致 drift 的原因。我建议从简单的可解释模型开始。

如果这个过程没有检测到 drift，并不意味着不存在 drift。它只是意味着我们无法用所使用的模型和特征检测到它。

最小示例：ft_drift

我与很多使用 OpenAI API 进行模型微调的人合作。我创建了一个小型 CLI 工具 ft_drift，可以检测两个多轮对话格式的 jsonl 文件之间的 drift。目前，ft_drift 仅检测 prompt 模板、schema 和其他基于 token 的 drift（相对于语义 drift）。然而，这是理解对抗验证一般概念的好起点。以下是这个工具的演示：

这个演示来自一个真实案例，其中 prompt 模板的意外更改导致模型行为异常。演示显示该工具检测到两个数据集 file_a.jsonl 和 file_b.jsonl 之间的差异。之后，会展示一个重要 token 的表格，这些 token 占 drift 的比例，如 END-UI-FORMAT、UI-FORMAT 等。我们能够应用该工具并快速找到问题的根本原因。建模代码位于 ft_drift/model.py，简单得出奇。关键是你不需要复杂的技术来上手。你可以通过向特征中添加 embedding 来进一步推进这种方法，从而也能检测语义 drift。类似地，你可以手工添加其他特征，比如对话轮数、消息长度等。

我在 2016 年首次从 Zygmunt Zając 的博客文章中了解到这种技术¹。多年来，我看到这种技术被用在各种不同的背景下，有时还有不同的名称。↩︎

我在 2016 年首次从 Zygmunt Zając 的博客文章中了解到这种技术。多年来，我看到这种技术被用在各种不同的背景下，有时还有不同的名称。↩︎

这张幻灯片使用"skew"这个词，在这种情况下可以与"drift"互换。↩︎

这张幻灯片使用"skew"这个词，在这种情况下可以与"drift"互换。↩︎

对于经典 ML，如果你已经在这些数据上训练模型，你可能有一个特征工程管道可以重用。↩︎

对于经典 ML，如果你已经在这些数据上训练模型，你可能有一个特征工程管道可以重用。↩︎