34次模型迭代实录：多数问题竟出在评估环节

当模型改进变成了评估调试

在真实的机器学习工程实践中，我们习惯把注意力放在模型架构、特征工程和调参上。然而一位来自 Anexum 的工程师最近在 Reddit 上分享了一段令人深思的经历：他为 AIOps 系统 ANXEngine 构建了一个「有界改进循环」（bounded improvement loop），经过 34 次完整记录的迭代后发现，绝大多数有价值的收获并不是模型本身的提升，而是评估流程中的一系列 Bug。

ANXEngine 是一套用于对大约 200 台网络设备进行每日事件风险排序的运维系统。AIOps（Artificial Intelligence for IT Operations）是将机器学习和大数据分析应用于IT运维的实践，旨在自动化事件检测、根因分析和容量规划等任务。ANXEngine 的核心任务是帮助运维团队将有限的注意力集中在最可能出问题的设备上——这类系统面临的典型挑战包括事件数据的高度不平衡（真正的故障事件远少于正常事件）、标签延迟（设备是否真正发生故障可能需要数天才能确认）、以及设备行为的非平稳性（网络拓扑变更、流量模式季节性变化等）。

作者设计的改进循环逻辑相当克制：注册一个假设（hypothesis）→ 实现最小可测试的变更 → 训练一个挑战者模型（challenger）和一个不变的对照模型（control）→ 评估两者 → 最终决定 KEEP（保留）、REVERT（回滚）或 PAUSE（暂停）。这套流程本身极具工程纪律性——它将机器学习迭代从一种「艺术」转变为一种可审计的流程。在许多团队中，模型改进是松散的：工程师凭直觉修改特征、调整参数，然后在某个数据集上跑一下看结果。三个月后回顾时，团队往往无法解释为什么当前模型是这个样子。有界改进循环通过强制记录假设、控制变量和保留决策日志，本质上是将软件工程中的版本控制和代码审查理念引入了模型开发过程。但真正的价值恰恰来自它暴露出的评估陷阱。

「有界改进循环」的方法论根基来源于科学实验中的假设驱动方法。与无约束的超参搜索或自动化 NAS（神经架构搜索）不同，它强调每次迭代都必须有明确的假设声明、最小化的变量控制和可追溯的决策记录。NAS 是一类通过搜索算法自动设计神经网络架构的技术，代表方法包括 Google 的 NASNet 和 ENAS，它们通常需要大量计算资源在庞大的架构空间中搜索最优结构。相比之下，有界改进循环强调的是人类认知的参与——每次变更背后都有一个可解释的假设，而非盲目的搜索。challenger-control 模式借鉴了金融风控和推荐系统中广泛应用的冠军/挑战者部署策略，其核心是确保每次变更都有一个不变的基准线作为参照，从而将「改变带来的效果」与「随机波动」区分开来。

三个致命的评估 Bug

数据泄漏：0.76 的假象跌回 0.51

第一个问题是训练数据与后续「适应度窗口」（fitness window）存在重叠。在最初的版本中，PR-AUC 指标看起来相当漂亮，达到了 0.72 到 0.76。这个数字足以让人误以为模型表现优异。

然而当作者将训练窗口、门控窗口（gate window）和报告窗口（report window）严格分离之后，PR-AUC 骤降至 约 0.51——几乎接近随机水平。用作者自己的话说，这个结果「痛苦，但诚实」。这是数据泄漏最经典也最隐蔽的表现形式：时间序列数据中的窗口划分稍有不慎，就会让评估结果虚高一大截。

需要理解的是，PR-AUC（Precision-Recall Area Under Curve）之所以被选为主要评估指标，是因为在 AIOps 场景中真正的风险事件（正样本）通常只占总事件的极小比例。相比 ROC-AUC，PR-AUC 不会被大量负样本的正确分类所稀释，因此能更真实地反映模型在稀有事件检测上的能力。具体来说，ROC-AUC 在类别极度不平衡时会给出过于乐观的评估——即使模型只是把绝大多数样本判为负类，也能获得很高的 ROC-AUC，因为真负率（specificity）天然很高。PR-AUC 则完全聚焦于正类的检出质量，在基准率（base rate）很低的场景下能提供更有区分度的评估。

而时间序列场景下的数据泄漏尤为隐蔽——简单的随机划分会破坏时间因果关系，未来的信息可能通过滑动窗口特征、滞后变量或共享的时间段渗透到训练集中。在 ANXEngine 的场景中，泄漏的路径可能还包括：特征工程中使用的统计量（如设备历史故障率的全局均值）如果在计算时包含了验证期的数据，就会引入信息泄漏；滑动窗口特征如果窗口跨越了训练-验证边界，也会造成泄漏；甚至特征选择阶段如果使用了全部数据来计算特征重要性，也构成一种间接泄漏。PR-AUC 从 0.76 骤降到 0.51 的幅度，表明原始评估中存在的泄漏程度相当严重——模型几乎完全依赖泄漏的未来信息来做出预测。标准的解决方案是采用严格的时间前向验证（walk-forward validation），确保训练数据在时间上严格早于验证数据，且两者之间存在足够的间隔期（gap period）以防止短期自相关带来的信息泄漏。

留出集复用：13 次实验后的「诚信危机」

第二个问题更加微妙，涉及留出集（holdout）的复用。作者强调他从未在留出集上训练模型，但每一次评估结果都会影响下一个假设的方向。在同一个窗口上做了 13 次实验之后，再声称这个窗口「未被触碰」就显得不够诚实了——因为它已经间接地引导了模型的演化路径。

这一问题的本质是「自适应过拟合」（adaptive overfitting），由 Dwork 等人在 2015 年的开创性论文《The Reusable Holdout》中正式阐述。当分析者根据验证集的反馈反复调整模型时，即使从未直接在验证集上训练，模型选择过程本身也会逐渐拟合验证集的特异性噪声。这类似于统计学中的多重比较问题——每多做一次比较，整体的假阳性率就会膨胀。

从信息论的视角来看，每次在验证集上评估模型并根据结果做出决策，都会从验证集中「提取」一定量的信息。当提取的信息累积到一定程度时，验证集就不再能提供关于模型泛化能力的可靠估计。信息提取的速度取决于多个因素：验证集的大小、每次查询结果的精度、以及决策对查询结果的敏感程度。在只有 200 台设备、正样本稀少的场景下，验证集本身包含的信息量就很有限，因此可用的查询次数自然更少。

Kaggle 竞赛中的排行榜过拟合就是这一现象的经典体现：参赛者在公开排行榜上的分数往往高于最终私有排行榜的分数，因为他们的提交策略已经间接适应了公开测试集。研究表明，即使在数千名参赛者、数万次提交的情况下，公开排行榜与私有排行榜之间的排名相关性也会显著下降——这正是大规模自适应过拟合的直接证据。

为此，他引入了一个明确的约束：每个窗口最多允许 8 次选择性查询（selection queries）。超过之后，该窗口只能作为历史证据保留，不能再用于筛选新的候选模型。8 次的经验限制虽然缺乏严格的理论推导，但它至少建立了一种显式的资源意识——让团队意识到评估数据是一种可耗竭的资源，而非可以无限重复使用的公共品。而模型的晋升（promotion）则需要满足更严格的条件：要么在两个相互独立的正向窗口上验证通过，要么是一个正向选择结果加上一个从未被查询过的全新数据切片。

指标冲突：排序变好，预警反而变少

第三个问题触及了 AIOps 场景的核心权衡。某个特征族将一台「困难设备」的风险排名从第 37 位提升到第 7 位，同时把 Precision@10 从 0.50 提高到了 0.70——单看这些数字，这显然是一次成功的改进。

但同时，真正有效的早期预警数量从 4 个下降到了 2 个。也就是说，模型的排序能力变强了，但提前发现问题的能力却退化了。作者最终拒绝了这个变更，理由很清晰：更好的排序并不值得以牺牲预警提前量（lead time）为代价。这个决策揭示了一个重要原则——单一指标的提升不等于系统整体价值的提升。

Precision@K 是信息检索和推荐系统中的常用指标，衡量的是排名前 K 个结果中相关结果的比例。在本场景中，Precision@10 意味着运维团队每天重点关注排名前 10 的设备时，其中有多少确实出了问题。然而，早期预警关注的是另一个维度——提前量，即模型能否在事件实际发生前足够早地发出信号。

这两个目标可能存在根本性冲突：提高排序精度往往意味着模型更依赖接近事件发生时的强信号特征（如设备已经出现明显的性能退化指标），而这些特征在事件早期阶段可能尚未显现。换句话说，精确排序和早期预警可能需要模型关注完全不同的信号——前者依赖近期的确定性证据，后者则需要捕捉早期的微弱异常模式。这种权衡在医疗诊断、金融欺诈检测等领域同样存在——高精度的诊断模型可能只有在疾病晚期才能给出确定判断，而早期筛查模型则需要容忍更高的假阳性率来换取时间窗口。在实际的 AIOps 部署中，团队可能需要维护多个专门化的模型或建立复合评估框架，而非试图用单一模型同时优化所有目标。

「保留」不等于「改进」

作者提出的另一个关键反思在于：他不再把 KEEP 决策当作模型改进的证明。在最近一次审计中，模型在新数据上的对比结果是不确定的（inconclusive）。模型之所以被保留，仅仅是因为没有足够强的理由将其回滚，而不是因为确认了性能提升。

这是一个在 MLOps 实践中极易被混淆的概念。「没有理由回滚」和「已确认改进」是两种完全不同的状态，但在很多模型注册表（model registry）中它们往往被记录成同一个「上线」状态。模型注册表是 MLOps 基础设施的核心组件，负责记录模型的版本、元数据、血缘关系和生命周期状态。主流工具如 MLflow Model Registry、Vertex AI Model Registry 和 AWS SageMaker Model Registry 通常定义了 Staging、Production、Archived 等状态，但这些状态往往只反映部署决策，而不区分决策背后的置信度。

将两者混为一谈会导致所谓的「置信度债务」（confidence debt）——随着多次不确定的 KEEP 决策累积，团队可能错误地认为当前生产模型经过了充分验证，而实际上它可能只是一系列「不够差到被替换」的结果的堆叠。这与技术债务的累积机制类似：每一次妥协单独来看都是合理的，但它们的复合效应可能在某个时刻突然暴露为系统性风险。更实际的做法是在模型注册表中引入置信度标签，例如将状态细分为 CONFIRMED_IMPROVEMENT、INCONCLUSIVE_KEEP 和 REGRESSION_REVERTED，从而为后续的审计和回溯提供更精确的信息。将这两者明确区分，能够避免团队对模型能力产生虚假的信心累积。

悬而未决的工程难题

作者坦承，他最没有把握的部分是查询预算（query budget）的设定。「8 次」是一个实用的经验限制，而非能从数据中干净推导出来的理论值。由于标签到达缓慢，不断创建新的评估窗口成本高昂，这使得数据的复用与新鲜度之间存在天然的张力。

标签到达缓慢的问题绝非 AIOps 独有。在信用风险评估中，贷款是否违约可能需要数月甚至数年才能确认；在药物发现中，临床试验结果的反馈周期以年计；在预测性维护中，设备从出现异常信号到实际故障可能间隔数周。这种慢反馈特性从根本上限制了团队能够进行的有效实验次数，使得每一次评估数据都弥足珍贵。传统的机器学习研究范式假设数据获取成本低廉、标签即时可得，但在这些工业场景中，评估数据的稀缺性才是制约模型迭代速度的真正瓶颈。

他向社区抛出了三个开放性问题：

• 固定查询预算是否合理？ 还是应该采用序贯检验（sequential testing）或可复用留出集（reusable-holdout）等更严谨的统计技术？
• 当正样本标签到达缓慢时，如何创建新鲜的评估数据？
• 在模型注册表中，是否应该用不同方式区分「无回滚理由」与「已确认改进」？

这三个问题几乎击中了所有小样本、慢反馈场景下 MLOps 系统的痛点。

序贯检验（sequential testing）是统计假设检验的一个分支，允许在数据逐步到达的过程中持续进行检验，而非等到固定样本量收集完毕。常见的方法包括 SPRT（Sequential Probability Ratio Test，序贯概率比检验）——由 Abraham Wald 在二战期间为军品质量检验而发明——和更现代的 always-valid p-values（也称为 anytime-valid inference）。SPRT 的核心思想是在每个新数据点到达时计算似然比，当该比值超过预设阈值时立即做出接受或拒绝的决定，从而避免了固定样本量设计中的资源浪费。在 MLOps 场景中，序贯检验允许团队在新数据到达时动态决定是否继续实验——如果效果已经明显优于或劣于基准线，就可以提前终止实验并释放资源。

而可复用留出集技术的代表——Google Research 提出的 Thresholdout 算法——其核心思想是在回答每次查询时向结果中注入校准过的噪声，使得分析者无法通过反复查询来精确拟合留出集。具体而言，只有当训练集上的估计与留出集上的真实值之间的差异超过某个阈值时，算法才会返回留出集上的真实值（加噪后）；否则直接返回训练集上的估计。该算法在理论上保证了即使进行指数级次数的自适应查询，累积的过拟合风险也能被控制在预定范围内，代价是每次查询结果的精度会略有下降。这两种技术或许能为固定预算方案提供更有理论保障的替代方案，但它们的工业落地仍需解决实现复杂度和团队认知门槛等现实问题。

对 MLOps 从业者的启示

这段实践记录的价值，不在于它交付了一个更好的模型，而在于它诚实地揭示了一个常被忽视的真相：在很多机器学习项目中，评估基础设施的质量往往比模型本身更值得投入。一个有泄漏的评估管线会持续误导整个团队的决策方向，而 34 次迭代中「大多数收获来自评估 Bug」的结论，恰恰说明了扎实的评估纪律有多稀缺。

这一现象在行业中有更广泛的印证。Google 在其著名的论文《Hidden Technical Debt in Machine Learning Systems》中指出，真实的 ML 系统中，模型代码只占整个系统的极小部分，而数据收集、验证、特征提取、评估和监控等基础设施才构成了系统的主体。评估基础设施的债务尤为危险，因为它不会像训练失败那样立即暴露——一个有泄漏的评估管线可能在数月内持续给出乐观的信号，导致团队在错误的方向上越走越远。

对于正在构建生产级 ML 系统的团队而言，这里有几点可以直接借鉴：严格的时间窗口分离、对留出集查询次数的显式约束、拒绝单指标优化的整体权衡思维，以及在模型注册表中区分「保留」与「改进」的语义。这些看似繁琐的工程约束，恰恰是让 AIOps 系统长期可信的基石。值得注意的是，这些原则的落地不需要复杂的工具链——一个结构化的实验日志、一套明确的窗口划分规则、一个带有置信度标签的模型注册表，可能就足以避免本文描述的大部分陷阱。关键不在于技术复杂度，而在于团队是否愿意为「诚实的评估」付出额外的工程成本。

核心要点

核心要点