MLOps-Bench：在真实仓库里给生产机器学习工程中的人工智能智能体做基准

MLOps-Bench：在真实仓库里给生产机器学习工程中的人工智能智能体做基准

Quoc Co Tran，Hitesh Laxmichand Patel，Diwakar Mahajan，Kshitij Bakliwal，Avi Sil，Katrin Kirchhoff。单位：Oracle。邮箱：{co.tran, hitesh.laxmichand.patel, diwakar.mahajan, kshitij.bakliwal, avi.sil, katrin.kirchhoff}@oracle.com

译注：原文 HTML 把单位和邮箱串在一起，此处按六位作者同属 Oracle 整理；姓名与邮箱保留原文。

摘要

人工智能智能体越来越被期望去修改和维护生产中的机器学习系统，然而现有基准主要评测的，要么是竞赛式的机器学习实验，要么是通用的仓库 issue 解决。我们提出 MLOps-Bench，一项立足仓库的、面向生产机器学习工程的基准。与此前的机器学习智能体基准不同，MLOps-Bench 评测的是真实机器学习仓库内部可执行的生命周期改动，覆盖数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端集成。每项任务都立足仓库证据，并包含一条自然语言需求、一个 oracle 补丁、一个看似合理的有缺陷基线、fail-to-pass 测试、pass-to-pass 测试，以及来源元数据。该基准包含来自 31 个公开机器学习仓库的 212 项已核验任务，有 636 个 fail-to-pass 测试和 856 个 pass-to-pass 测试。我们评测六个智能体，发现最好的系统解决 31.2% 的任务，同时通过 68.7% 的测试，说明当前智能体常常做出部分进展，但仍通不过与生产相关的行为要求。MLOps-Bench [^1] 把智能体评测从建模型和修 issue，推向仓库原生的 MLOps 工作，在那里正确性取决于生命周期推理、行为稳健性，以及对既有系统行为的保持。

图 1：MLOps-Bench 的构建与评测流水线。从真实的机器学习仓库出发，生成器冻结一份源快照，抽取生命周期证据，合成一项仓库原生的 MLOps 任务，构造 oracle 补丁和有缺陷补丁，生成行为测试，并通过把智能体的补丁应用到被冻结的仓库上来打分。

1 引言

在生产中运行机器学习系统，正在成为对人工智能智能体的一项核心期望，而不只是写代码或提高模型准确率。生产机器学习工作既不同于普通的软件维护，也不同于竞赛式机器学习：一次正确的改动可能需要保持数据契约，维持训练与服务的一致性，记录产物元数据，校验推理输入，发出监控信号，或强制治理门禁。现有基准只部分度量这些能力。SWE-bench 评测仓库级的 issue 解决（Jimenez 等人，2024），而数据科学和机器学习智能体基准强调的是在任务或竞赛设置中的分析、实验或模型改进（Jing 等人，2024；Chan 等人，2024；Huang 等人，2024a；Chen 等人，2025；Jha 等人，2025）。它们没有说清，智能体能否在既有机器学习仓库内部做出安全、可执行的 MLOps 改动。

MLOps-Bench 用一项立足仓库的、面向生产机器学习工程的基准来填这个缺口。它的关键新意在于：任务是否有效，由生命周期证据定义，而不是由有没有 issue、排行榜成绩或通用编程难度来定义。每项任务必须绑在原生的仓库表面上，例如加载器、模式、特征变换、训练配置、模型产物、服务路径、监控输出、工作流文件或治理元数据。这种立足反映了已知的机器学习技术债和生产就绪风险来源（Kreuzberger 等人，2023；Sculley 等人，2015；Breck 等人，2017）。

MLOps-Bench 在六个核心 MLOps 阶段加上一个跨阶段集成类别上评测智能体：数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端生命周期集成。每项任务把一条仓库原生的请求，与可执行的行为测试、一份 oracle 实现、一个看似合理的有缺陷基线，以及来源元数据配在一起，检验智能体是否满足与生产相关的生命周期契约，同时保持既有行为，并避开现实的失败：缺少校验、训练与服务偏斜、不完整的产物元数据、畸形输入处理、无效的监控阈值，以及并不强制执行的治理检查。见表 1。

表 1：机器学习智能体基准与机器学习工程基准的比较。Y = 是，N = 否，P = 部分。

我们围绕三个研究问题来组织这项基准：

RQ1：仓库原生的 MLOps 能力。人工智能智能体能否在既有机器学习仓库内部实现面向生产的 MLOps 改动，同时保持原生约定和既有行为？

RQ2：生命周期阶段的难度。智能体的表现如何在数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端生命周期任务之间变化？

RQ3：行为稳健性。智能体产出的是行为上正确的 MLOps 实现，还是做出表面上合理、却通不过面向生产的现实测试的改动？

这些研究问题决定基准设计：RQ1 要求立足仓库，RQ2 要求覆盖生命周期阶段，RQ3 要求可执行的测试，把正确补丁和看似合理但不完整的 MLOps 改动区分开。下面的贡献直接来自这些要求。

本文做出下列贡献：

1. 一项立足仓库的 MLOps 基准。

我们提出 MLOps-Bench，一条基准生成流水线，它从 31 个公开机器学习仓库 [^2] 导出可执行的智能体任务，这些仓库合计覆盖 20 种编程语言、框架和工具栈，以及 16 个机器学习应用领域。

2. 面向生产机器学习工程的生命周期阶段评测。

我们实例化一套分类，覆盖六个核心 MLOps 阶段加上一个跨阶段集成类别：数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端生命周期集成。该基准包含 212 项已核验任务，从而既能做总体评测，也能做分阶段评测。

3. 保留证据的任务合成。

我们描述一种从上下文到需求的协议，把每项任务立足在仓库证据上，包括原生代码路径、配置文件、测试、工作流文件、模型产物、监控工具和元数据。这一设计避免通用的 MLOps 提示，并保证每项任务对其源仓库是原生的。

4. Oracle、有缺陷基线和行为测试的构造。

对每项任务，MLOps-Bench 提供一个 oracle 补丁、一个看似合理的有缺陷基线、fail-to-pass 测试和 pass-to-pass 测试。总计，该基准包括 212 个 oracle 补丁、212 个有缺陷基线、636 个 fail-to-pass 测试和 856 个 pass-to-pass 测试，用来把正确实现和表面上合理的 MLOps 修复区分开。

5. 可审计的核验与人类立足检查。

我们给每个实例附上来源、许可证、快照、依赖、阶段标签、需求、oracle 理由和核验元数据。所有发布的任务都通过核验检查，并且一项把生成任务与作为 MLOps 候选的 SWE-bench PR 相比较的人类审计，支持直接从生命周期证据构造 MLOps 任务。

6. 在面向生产的 MLOps 工作上评测智能体。

我们在 MLOps-Bench 上评测 6 个智能体或模型，并报告任务完成、测试通过率、分阶段表现和分类的错误分析，展示当前的编码和数据科学智能体在仓库原生 MLOps 任务上的表现。

2 相关工作

#### 仓库级软件工程基准。

智能体基准已经从孤立的代码生成，转向可执行的、立足仓库的评测。BugsInPy 提供可复现的 Python 缺陷，用于受控调试；SWE-bench 测试智能体能否通过编辑代码库并通过测试来解决真实的 GitHub issue（Widyasari 等人，2020；Jimenez 等人，2024）。这是 MLOps-Bench 在方法上最接近的先例：它把仓库而不是一条独立提示当作评测环境。近期变体沿语言和模态轴线拓宽这一点：SWE-bench Multilingual、Multi-SWE-bench 和 SWE-bench Multimodal 把 issue 解决扩展到不同生态系统，并加入视觉产物（SWE-bench Team，2025；Zan 等人，2025；Yang 等人，2025），然而它们的语义仍然以 issue 解决为中心。MLOps-Bench 转而针对生产机器学习的生命周期工程，任务用数据契约、训练产物和监控信号这类证据来核验。

#### 数据科学与机器学习智能体基准。

第二条线在数据科学和机器学习工作流上评测智能体。DS-1000、DSEval、DSBench、DataSciBench 和 DA-Code 研究代码生成，以及越来越真实的数据分析任务，智能体在其中检查文件、执行代码并从错误中恢复（Lai 等人，2023；Zhang 等人，2024；Jing 等人，2024；Zhang 等人，2025；Huang 等人，2024b），但它们的产出是分析、笔记本或建模结果，而不是被修复的、可运行的机器学习系统。

更接近机器学习工程的是，MLAgentBench 把智能体评测为迭代的实验者，它们写代码、跑实验、检查输出并修改做法（Huang 等人，2024a）；MLE-bench 和 MLE-Dojo 通过源自 Kaggle 或交互式的机器学习工程任务把这一点放大，覆盖数据准备、建模、调试和重复执行（Chan 等人，2025；Qiang 等人，2026）；ML-Bench 和 ML-Dev-Bench 则转向仓库级的机器学习开发（Tang 等人，2023；Padigela 等人，2025）。MLOps-Bench 通过把评测从模型开发或竞赛成绩，转到既有仓库内部面向生产的生命周期改动，来补足这些工作。

#### MLOps、机器学习可靠性与以数据为中心的评测。

MLOps 研究解释了，为什么生产机器学习系统不能只被当作常规软件或孤立的建模问题来评测。CRISP-ML(Q) 把机器学习开发框定为一个有质量保证的过程，跨越数据理解、准备、建模、评测、部署和监控（Studer 等人，2021），而 MLOps 综述和架构研究强调编排、版本、CI/CD、持续训练、监控和反馈回路（Kreuzberger 等人，2023；John 等人，2021；Recupito 等人，2022）。这类依赖塑造仓库改动：一次模式变更可以破坏特征计算，一次特征修复可能要求重新训练，重新训练可以使评测阈值失效，一次服务改动可能要求更新监控或治理检查。 关于机器学习可靠性和以数据为中心的评测的工作，识别出许多促使 MLOps-Bench 出现的失败模式。Defects4ML 收集可复现的机器学习故障，对深度学习缺陷和机器学习测试的研究表明，围绕数据假设、数值不稳定、模型构造和库交互反复出现问题（Morovati 等人，2023；Zhang 等人，2022；Riccio 等人，2020）。DataPerf 和机器学习数据核验突出数据选择、模式核验和分布监控中的失败，而管道分析工具显示预处理选择如何影响下游模型行为（Polyzotis 等人，2019；Mazumder 等人，2023；Grafberger 等人，2023）。这些工作促使面向生命周期的评测，但通常把可靠性作为孤立缺陷、数据质量任务或分析设置来研究，而不是作为自主智能体可执行的、仓库原生的任务。

#### MLOps-Bench 的位置。

MLOps-Bench 坐落在这些线索的交汇处：仓库级软件基准提供基于执行的方法，数据科学和机器学习智能体基准提供真实的开发与实验设置，MLOps 和机器学习可靠性研究指出使生产机器学习变难的生命周期依赖和失败模式。没有任何现有基准把这三者合在一起：立足仓库的可执行评测、MLOps 生命周期语义，以及把正确修复和看似合理但不完整的生产补丁区分开的行为测试。MLOps-Bench 用跨越数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端生命周期集成的任务来填这个缺口。

表 2：MLOps-Bench 在各生命周期阶段和端到端集成上的生成模式。

3 方法

MLOps-Bench 通过一条保留证据的流水线，从真实机器学习仓库生成可执行的基准任务：仓库选择、快照、上下文抽取、分阶段的任务生成、oracle 构造、有缺陷基线构造，以及可执行核验。每一项被接受的任务都可以追溯到仓库证据，并由测试评测。图 1 概括这条流水线。

3.1 爬取仓库

我们用与 MLOps 相关的搜索查询在 GitHub 上识别开源机器学习仓库，查询包括 mlops、machine learning 和 ml-ops。候选仓库必须可克隆、非空，并通过源结构、issue 或 pull request、工作流文件或管道产物，显示出机器学习工程活动的证据。然后我们人工 [^3] 选出 31 个仓库，以覆盖生命周期、领域多样性、数据与业务上下文、可构建性，以及可管理的审计规模，排除结构弱、机器学习管道信号有限，或与现实 MLOps 阶段任务契合差的仓库。得到的 212 项任务主要覆盖基于 Python 的机器学习系统，并额外覆盖 YAML 或配置较重的模板、TypeScript 和网页服务代码、shell 自动化、JavaScript 工具，以及一个 C/C++ 物联网仓库。这一规模大于 SWE-Bench Lite 的 11 个仓库，同时对人类审计仍然可行。

3.2 仓库立足与上下文

对每个选中的仓库，我们冻结一份源快照，并记录来源元数据，包括 URL、提交哈希、许可证证据、语言、依赖清单、测试命令、工作流文件，以及可能的修改表面。这通过为每个选中仓库保留源快照、依赖上下文、许可证证据和评测命令，来支持可复现性和可审计性。

然后我们用四种视图构造一个上下文包。业务上下文概括领域、用户、模型目的和运行风险。技术上下文识别架构、入口、数据路径、配置文件、模型产物、服务接口和测试。MLOps 上下文记录生命周期证据，例如摄入、特征计算、训练、评测、服务、监控、CI、部署和治理。需求上下文把观察到的缺口转换成候选工程需求，带有相关文件、期望行为、约束和应保持的行为。

这种上下文防止通用的任务生成。一项监控任务必须绑在一条既有的预测路径、指标输出、日志表面或部署工作流上；一项数据核验任务必须绑在一个既有的加载器、模式假设或预处理步骤上。没有仓库证据、原生实现表面或可执行检查的任务会被拒绝。

3.3 任务生成

我们在六个核心 MLOps 阶段加上一个端到端集成类别上生成任务：数据管道、特征工程、模型训练、模型服务、监控与可观测性、CI/CD 与治理，以及端到端 MLOps 流。对每个阶段，生成器核验仓库证据，导出一份可测试的阶段契约，识别一块最小的原生修改表面，并写出一条具体到足以评测、但不透露实现的需求。

端到端类别留给跨边界的任务，而不是仅仅更大的编辑。例子包括被服务消费的训练元数据，通过 CI 浮出的核验失败，或从批量推理输出导出的监控摘要。表 2 概括阶段证据、生成的需求和 oracle 表面。

3.4 问题生成

每一个被接受的问题被写成一条仓库原生的工程请求，含五个字段。业务动机解释这次改动在运行上为什么重要。技术上下文指向相关组件和当前行为。需求以可测试的措辞陈述期望的行为变化。约束规定仓库约定、允许的修改表面、兼容性要求和应保持的行为。评测意图概括隐藏测试将检查什么，而不透露确切断言。生成器保存每个字段所用的证据，以便审阅者审计立足情况。

3.5 Oracle、有缺陷基线与测试

一个问题被接受之后，MLOps-Bench 生成一个 oracle 解，作为该基准契约的一种有效实现。Oracle 生成定位编辑表面，应用满足需求的最小原生补丁，并记录一份理由，把每个被改文件连到业务动机、技术上下文和阶段契约。因此 oracle 是可行性和核验的产物，而不是唯一可接受的解。

沿袭软件测试基准中受控缺陷的传统（Just 等人，2014），流水线也为同一问题生成一个看似合理的有缺陷基线。有缺陷补丁应当像一次合理但不完整的工程尝试：它可以加上所要求的 API 但跳过模式核验，在训练和服务中以不同方式计算一个特征，写出没有元数据的模型产物，处理正常推理但不处理畸形输入，发出没有阈值的指标，或加上一条从不失败的治理检查。我们避免空操作补丁或语法错误这类平凡基线，因为它们并不测试现实的智能体失败模式。

测试在两份补丁都存在之后生成。Fail-to-pass（F2P）测试编码新的基准契约，必须在有缺陷基线上失败，并在 oracle 上通过。它们针对外部可见的行为，例如拒绝无效记录、稳定的特征值、保存的产物元数据、预测响应模式、发出的监控摘要，或失败的发布门禁。Pass-to-pass（P2P）测试保护应当保持不变的行为，通常通过复用或轻微扩展相邻功能周围的既有测试。一项基准只有在下列条件都满足时才被接受：oracle 通过两套测试，有缺陷基线因预定原因至少失败一个 F2P 测试，并且测试不依赖外部服务或隐藏状态。

3.6 核验与评测

一项任务只有在下列检查都通过时才被接受：立足检查把需求连到仓库证据，阶段契约检查确认所声称的 MLOps 阶段，行为测试把 oracle 和有缺陷基线区分开，P2P 测试保持既有行为。评测期间，智能体补丁被应用到冻结快照上，并用任务完成率、测试通过率、运行时间、补丁大小、改动文件数和错误类别来打分。

基准构建使用分开的开发划分和评测划分。我们用两个仓库和 25 项任务来迭代生成提示、oracle 构造、测试构造和可执行核验检查。所报告的评测使用其余 29 个仓库和 187 项任务。

3.7 数据集统计

总体而言，MLOps-Bench 包含 212 项任务，跨越六个核心 MLOps 阶段和一种端到端 MLOps 流。每项任务立足一份仓库快照，并用可执行测试打分。该基准包括 25 项开发任务和 187 项评测任务。总计它包含 636 个 F2P 测试、856 个 P2P 测试，以及一共 1,492 个测试。表 3 给出任务和测试在各阶段的分布。分阶段计数并不恰好平衡，因为五项候选任务在质量检查中被拒绝，主要是 oracle 不能可靠通过，或生成的测试不能干净地把 oracle 和有缺陷基线区分开。

表 3：MLOps 任务和测试用例在各阶段的分布。F2P 和 P2P 分别表示 fail-to-pass 与 pass-to-pass 测试。

3.8 人类审计

#### 3.8.1 仓库 Issue 复用

译注：原文标题拼作 Repository Issue Resue。

我们审计既有的仓库级 issue 能否被改用作 MLOps 阶段任务。五名具有机器学习工程背景的标注者，对各含 25 项的两套材料做了双标：一套是被我们的分类流水线标为 MLOps 候选的 SWE-bench PR，另一套是 MLOps-Bench 生成流水线产出的任务。每一项都被判断它是否构成一项有效的 MLOps 任务。

在 SWE-bench PR 中，只有 48%（12/25）被两名标注者一致确认为 MLOps，12% 被拒绝，12% 不清楚，28% 意见分裂。标注者合并后的一致性为中等（$\kappa=0.50$），表明即便在有领域经验的审阅者之间，被改用的 PR 是否算有效 MLOps 也有争议。相比之下，标注者一致确认全部 25 项生成任务为有效的 MLOps 任务。[^4] 尽管样本不大，这项审计支持直接从明确的生命周期证据构造 MLOps 任务，而不是改用通用的仓库 issue。

#### 3.8.2 测试度量可推广的行为

为了评估 F2P 套件测试的是唯一被规定的行为，而不是从 oracle 推广出来的行为，我们随机选取 10 项任务，并做了一次人工的契约覆盖审计，把每项任务所陈述的行为契约与其对应的 F2P 测试比较。五名标注者参加审计。每项任务由两名标注者独立评测，一共得到 20 条任务级标注。标注者检查 F2P 测试是否覆盖任务规格中重要的、可观察的功能要求，包括期望输出、副作用、校验规则、边界情况和集成行为，而不是表面的或针对实现的信号。审计覆盖 4,633 行不重复的审阅材料：含 40 个测试函数的 1,975 行 F2P 测试，以及 2,658 行结构化任务规格。标注者一致把 10 套 F2P 中的 9 套归为抓住了所陈述的行为契约，1 套归为没有完全抓住。原始标注者间一致率为 100%，Cohen 的 $\kappa$ = $1.0$。即便对那一套没有达到二元覆盖标准的套件，两名标注者的独立估计也表明，测试平均覆盖了契约功能要求的 85%。这些结果提供直接证据，表明 F2P 套件测试的是任务契约所规定的行为：90% 完全达到独立的契约覆盖标准，其余那一套仍覆盖其所陈述功能要求的相当大一部分。

#### 3.8.3 测试接受其他正确解

五名标注者参加这项研究。每项任务由两名标注者独立审阅，一共得到 20 条任务级标注，每名标注者评测四项任务。对每一项任务，标注者检查问题陈述、F2P 测试套件、oracle 补丁、智能体补丁和相关仓库上下文。就所审阅的材料而言，这次审计的分量很大。因为每项任务都被双标，这对应于合计 80,698 行被指派的审阅量，此外还有按需要检查的任何链接仓库上下文。对 10 个补丁中的 8 个，两名标注者都独立判断该智能体补丁是一种正确的替代实现。其余两例存在分歧，因此由第三名标注者审阅，他把两例都归为正确的替代。裁决之后，所有补丁都被判断为满足预定的任务契约，同时是相对 oracle 的有效替代。

4 结果

A. 评测方法：为了评测当前的模型和编码系统，我们把智能体分成两类：编码智能体和基础智能体，如表 4 所示。

表 4：评测中使用的智能体类型。

我们把每个基准样本实例化为一次仓库级干预，而不是一个只靠提示的预测问题。评测器在隔离的工作区里落实基线快照，并从基准规格构造任务提示。被评测的智能体访问工作区、编辑文件并产出补丁。然后我们记录得到的补丁，注入打分测试，并执行测试套件。为了把解题和基准构建分开，被评测的智能体只收到任务提示和可编辑的仓库工作区；它们不收到仓库分析元数据、oracle 或有缺陷 diff、核验反馈，或生成器的重试轨迹。一次运行只有在补丁之后的工作区满足全部有效的行为测试时才算成功，同时保留逐测试结果、运行时间、编辑统计和失败类别，以供进一步的错误分析。这一协议按共同框架下的可执行正确性来比较系统，而不是按自然语言计划看起来有多合理。

B. 性能指标：我们用任务完成率作为主要指标，因为一项基准任务只有在智能体产出一个通过全部打分测试的、完全正确的仓库状态时才算解决；而测试通过率捕捉部分进展，并帮助把完全失败的运行，和实现了部分所需行为但漏掉边界情况或回归的解区分开。

表 5：性能指标。

表 6：智能体评测的总体结果。

图 2：各智能体的分阶段表现热图。

表 7：失败任务中的错误分布。

我们报告评测时可用的智能体和模型标识。当一个系统暴露的是智能体产品名而不只是原始模型名时，我们在可得时同时报告产品名和底层模型标识。

C. 总体结果：在这次评测运行中，编码智能体在任务完成上优于基础智能体实现。Codex 取得最高的任务完成率和测试通过率，而 Claude Code (Opus) 优于 Claude Code (Sonnet)。任务完成与测试通过率之间的差距表明，许多运行做出了可观的部分进展，但至少失败一个打分测试。

Claude 被用于基准生成，并不意味着评测时应当优待 Claude 模型。Oracle 和测试生成是受协助的合成步骤：生成器可以访问仓库分析、原生画像元数据、阶段上下文、候选问题规格、oracle 与有缺陷 diff、核验反馈和重试循环。相比之下，被评测的智能体收到任务提示和仓库工作区，必须在工具和时间约束下推断所需实现，并且只由可执行测试打分。因此基准构建拥有比智能体解题设置丰富得多的、经过整理的上下文。

D. 按 MLOps 阶段的结果：图 2 的每个单元格报告该 MLOps 阶段的任务完成率。分阶段的任务完成并不均匀。监控与可观测性以及端到端任务显示出最强的编码智能体表现，而特征工程和服务对若干智能体仍然困难。在这次评测中，基础智能体落后于编码智能体，反映出更完整的交互式编码工作流的优势。

E. 错误分析：表 7 报告被指派到每个诊断类别的失败任务份额。已解决的任务不计入此表。

在各智能体之间，失败主要由部分正确但行为上不完整的实现主导，而不是简单地不能编辑文件。Codex 最常产出可执行的补丁，但漏掉一项或多项针对该任务的要求，次要失败来自导入或新引入的依赖。Claude Code (Sonnet) 更常在仓库集成上失败，尤其是损坏的导入、模块路径和依赖假设，而 Claude Code (Opus) 提高了成功率，但失败的分布更宽，包括错误功能、缺少产物，以及来自更大工具循环编辑的超时。一次性的基础包装以不同方式失败：没有动态浏览、测试执行或修复时，Base agent Sonnet 经常破坏包结构和导入，而 Base Agent GPT 5.2 更常返回看似合理但语义上不足的补丁，它们通过一些测试，但达不到完整的任务正确性。

#### 相对于研究问题的小结。

对 RQ1，当前智能体能解决仓库原生 MLOps 任务中并非微不足道的一部分，但最好的系统只完成评测任务的 31.2%。对 RQ2，表现在生命周期各阶段之间变化，说明总体分数掩盖了分阶段的强弱。对 RQ3，任务完成与测试通过率之间的差距，连同错误分析，表明许多补丁部分正确，但行为上不完整。

5 结论

我们提出 MLOps-Bench，一项立足仓库的基准，用来评测人工智能智能体在面向生产的机器学习工程任务上的表现。与 Kaggle 式机器学习基准或通用的仓库修复基准不同，MLOps-Bench 针对的是运行机器学习系统时处于中心的生命周期工作，包括数据管道、特征工程、模型训练、模型服务、监控、CI/CD 与治理，以及端到端 MLOps 集成。每项任务都立足真实的仓库证据，并配有可执行测试、oracle 补丁、有缺陷基线和来源元数据，从而既能评测功能正确性，也能评测对既有行为的保持。 我们的评测表明，当前编码智能体在 MLOps 任务上做出有意义的进展，但离可靠的生产级自动化仍然很远。在这次运行中，表现最好的系统达到 31.2% 的任务完成率和 68.7% 的测试通过率，说明智能体常常实现部分的或表面上合理的解，同时仍然漏掉重要的行为要求。分阶段分析和错误分析进一步确认，失败并不限于语法或环境问题；许多失败涉及不正确的功能、缺少导入、依赖问题，或对仓库特定契约的不完整处理。这些结果表明，生产机器学习工程对人工智能智能体仍然是困难的设置，未来的进展将需要更强的仓库理解和更好的生命周期推理。

6 局限

MLOps-Bench 旨在真实仓库里评测面向生产的机器学习工程，但仍有若干局限。第一，MLOps-Bench 由 31 个公开机器学习仓库构成，选择标准是领域多样性、生命周期证据，以及能够被可靠地冻结、构建、审计和测试。尽管这些仓库含有真实的机器学习生命周期结构，它们是开源代码库，而不是已部署的商业系统。因此，MLOps-Bench 度量的是仓库原生设置中的生产风格运维工程，但不应被解释为充分代表所有工业 MLOps 环境。

第二，基准任务是从仓库证据合成的，而不是只从自然发生的生产事故收集而来。这使生命周期覆盖、oracle 解、有缺陷基线，以及可执行的 fail-to-pass 与 pass-to-pass 测试得以平衡，但可能引入生成和测试设计的产物。任务可以比真实的 MLOps 请求更局部、更明确、更面向测试，而有限的测试套件只能近似生产正确性：它们不能覆盖每一次下游交互、每一种工作负载、数据分布或运行失败模式。

最后，因为生成流水线依赖一个模型家族，而评测跨越多个家族，一个潜在的担心是构建过程可能让同家族智能体占优。我们在实践中没有观察到这一点——得分最高的系统（Codex，GPT-5.5）并不来自生成所用的家族——但我们不能完全排除生成的测试与特定智能体之间更细微的风格对齐，并把它标为对效度的一种威胁，值得进一步研究。

7 伦理考量

MLOps-Bench 由公开的开源仓库构成。我们为每个选中项目记录来源、源快照、依赖信息和许可证证据，并且只纳入其许可证允许在相应许可条款下做研究和基准使用的仓库。Issue 和 pull request 只被用作仓库级的活动与相关性的公开信号；任务从源快照中的生命周期证据生成，而不是从私人用户数据或机密生产事故生成。

我们不收集私人信息、凭据、秘密或非公开的组织数据，并排除有明显隐私、凭据或可复现性顾虑的仓库。该基准旨在对冻结仓库上的人工智能智能体做受控评测，而不是无人监督地修改生产机器学习系统。由于生成的补丁在基准框架之外可能不完整或不安全，基准上的成功不应被解释为无需人工审阅即可自主部署的就绪。我们将发布涵盖构建、许可、评测，以及报告下架、许可或数据质量顾虑的渠道的文档。

作者使用生成式人工智能工具，做了有限的语言编辑、改写建议，以及帮助改进表述。全部科学内容、实验设计、代码、分析、主张、引用和最终文本，都由人类作者审阅、核验并批准。

参考文献

• [1] Anthropic。Claude Code 文档：概述。https://claude.com/product/claude-code/ 访问日期：2026-05-24。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [2] E. Breck、S. Cai、E. Nielsen、M. Salib 与 D. Sculley。机器学习测试分数：一份用于机器学习生产就绪和技术债削减的量规。https://research.google/pubs/pub46555 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [3] J. S. Chan、N. Chowdhury、O. Jaffe、J. Aung、D. Sherburn、E. Mays、G. Starace、K. Liu、L. Maksin、T. Patwardhan 等。MLE-bench：在机器学习工程上评测机器学习智能体。载于 International Conference on Learning Representations，2025 年卷，第 50466–50494 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [4] J. S. Chan、N. Chowdhury、O. Jaffe、J. Aung、D. Sherburn、E. Mays、G. Starace、K. Liu、L. Maksin、T. Patwardhan、L. Weng 与 A. Madry。MLE-bench：在机器学习工程上评测机器学习智能体。arXiv 预印本 arXiv:2410.07095。https://arxiv.org/abs/2410.07095 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [5] Y. Chen、M. Shetty、G. Somashekar、M. Ma、Y. Simmhan、J. Mace、C. Bansal、R. Wang 与 S. Rajmohan。AIOpsLab：一个用于评测人工智能智能体、以实现自主云的整体框架。Proceedings of Machine Learning and Systems 7。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [6] S. Grafberger、P. Groth 与 S. Schelter。在原生机器学习管道上自动化并优化以数据为中心的假设分析。Proc. ACM Manag. Data 1 (2)。https://doi.org/10.1145/3589273 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [7] Q. Huang、J. Vora、P. Liang 与 J. Leskovec。MLAgentBench：在机器学习实验上评测语言智能体。载于 International Conference on Machine Learning，第 20271–20309 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [8] Y. Huang、J. Luo、Y. Yu、Y. Zhang、F. Lei、Y. Wei、S. He、L. Huang、X. Liu、J. Zhao 与 K. Liu。DA-Code：面向大语言模型的智能体数据科学代码生成基准。载于 Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing，Y. Al-Onaizan、M. Bansal 与 Y. Chen 编，美国佛罗里达州迈阿密，第 13487–13521 页。https://aclanthology.org/2024.emnlp-main.748/ 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [9] S. Jha、R. Arora、Y. Watanabe、T. Yanagawa、Y. Chen、J. Clark、B. Bhavya、M. Verma、H. Kumar、H. Kitahara 等。ITBench：在多样的真实世界信息技术自动化任务上评测人工智能智能体。arXiv 预印本 arXiv:2502.05352。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [10] C. E. Jimenez、J. Yang、A. Wettig、S. Yao、K. Pei、O. Press 与 K. Narasimhan。SWE-bench：语言模型能否解决真实世界的 GitHub issue？载于 Proceedings of the Twelfth International Conference on Learning Representations。https://arxiv.org/abs/2310.06770 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [11] L. Jing、Z. Huang、X. Wang、W. Yao、W. Yu、K. Ma、H. Zhang、X. Du 与 D. Yu。DSBench：数据科学智能体离成为数据科学专家还有多远？arXiv 预印本 arXiv:2409.07703。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [12] M. M. John、H. H. Olsson 与 J. Bosch。走向 MLOps：一个框架和成熟度模型。载于 2021 47th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)，第 1–8 页。https://dx.doi.org/10.1109/SEAA53835.2021.00050 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [13] R. Just、D. Jalali 与 M. D. Ernst。Defects4J：一个既有缺陷数据库，用以支持对 Java 程序的受控测试研究。载于 Proceedings of the 2014 International Symposium on Software Testing and Analysis，第 437–440 页。https://dx.doi.org/10.1145/2610384.2628055 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [14] D. Kreuzberger、N. Kühl 与 S. Hirschl。机器学习运维（MLOps）：概述、定义与架构。IEEE Access 11，第 31866–31879 页。https://arxiv.org/abs/2205.02302 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [15] Y. Lai、C. Li、Y. Wang、T. Zhang、R. Zhong、L. Zettlemoyer、W. Yih、D. Fried、S. Wang 与 T. Yu。DS-1000：面向数据科学代码生成的自然且可靠的基准。载于 International Conference on Machine Learning，第 18319–18345 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [16] M. Mazumder、C. Banbury、X. Yao、B. Karlaş、W. G. Rojas、S. Diamos、G. Diamos、L. He、A. Parrish、H. R. Kirk、J. Quaye、C. Rastogi、D. Kiela、D. Jurado、D. Kanter、R. Mosquera、J. Ciro、L. Aroyo、B. Acun、L. Chen、M. S. Raje、M. Bartolo、S. Eyuboglu、A. Ghorbani、E. Goodman、O. Inel、T. Kane、C. R. Kirkpatrick、T. Kuo、J. Mueller、T. Thrush、J. Vanschoren、M. Warren、A. Williams、S. Yeung、N. Ardalani、P. Paritosh、C. Zhang、J. Zou、C. Wu、C. Coleman、A. Ng、P. Mattson 与 V. J. Reddi。DataPerf：以数据为中心的人工智能开发基准。载于 Proceedings of the 37th International Conference on Neural Information Processing Systems，NIPS ’23，美国纽约州 Red Hook。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [17] M. M. Morovati、A. Nikanjam、F. Khomh 与 Z. M. Jiang。基于机器学习的系统中的缺陷：一份故障负载基准。Empirical Software Engineering 28 (3)，第 62 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [18] OpenAI。介绍 Codex。https://openai.com/index/introducing-codex/ 访问日期：2026-05-24。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [19] H. Padigela、C. Shah 与 D. Juyal。ML-Dev-Bench：人工智能智能体在机器学习开发工作流上的比较分析。arXiv 预印本 arXiv:2502.00964。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [20] N. Polyzotis、M. Zinkevich、S. Roy、E. Breck 与 S. Whang。机器学习的数据核验。载于 Proceedings of Machine Learning and Systems，A. Talwalkar、V. Smith 与 M. Zaharia 编，第 1 卷，第 334–347 页。https://proceedings.mlsys.org/paper_files/paper/2019/file/928f1160e52192e3e0017fb63ab65391-Paper.pdf 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [21] R. Qiang、Y. Zhuang、Y. Li、D. Sagar VK、R. Zhang、C. Li、I. Wong、S. Yang、P. Liang、C. Zhang 等。MLE-Dojo：在机器学习工程中增强大语言模型智能体的交互环境。Advances in Neural Information Processing Systems 38。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [22] G. Recupito、F. Pecorelli、G. Catolino、S. Moreschini、D. D. Nucci、F. Palomba 与 D. A. Tamburri。对 MLOps 工具与特性的多声部文献综述。载于 2022 48th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)，第 84–91 页。https://dx.doi.org/10.1109/SEAA56994.2022.00021 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [23] V. Riccio、G. Jahangirova、A. Stocco、N. Humbatova、M. Weiss 与 P. Tonella。测试基于机器学习的系统：一项系统映射。Empirical Software Engineering 25 (6)，第 5193–5254 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [24] D. Sculley、G. Holt、D. Golovin、E. Davydov、T. Phillips、D. Ebner、V. Chaudhary、M. Young、J. Crespo 与 D. Dennison。机器学习系统中隐藏的技术债。载于 Advances in Neural Information Processing Systems，第 28 卷。https://proceedings.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-sy 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [25] S. Studer、T. B. Bui、C. Drescher、A. Hanuschkin、L. Winkler、S. Peters 与 K. Müller。走向 CRISP-ML(Q)：一个带质量保证方法的机器学习过程模型。Machine learning and knowledge extraction 3 (2)，第 392–413 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [26] SWE-bench Team。SWE-bench Multilingual。基准网站。https://www.swebench.com/multilingual.html 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [27] X. Tang、Y. Liu、Z. Cai、Y. Shao、J. Lu、Y. Zhang、Z. Deng、H. Hu、K. An、R. Huang 等。ML-Bench：在仓库级代码的机器学习任务上评测大语言模型和智能体。arXiv 预印本 arXiv:2311.09835。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [28] R. Widyasari、S. Q. Sim、C. Lok、H. Qi、J. Phan、Q. Tay、C. Tan、F. Wee、J. E. Tan、Y. Yieh、B. Goh、F. Thung、H. J. Kang、T. Hoang、D. Lo 与 E. L. Ouh。BugsInPy：一个 Python 程序既有缺陷数据库，用以支持受控的测试和调试研究。载于 Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering，ESEC/FSE 2020，美国纽约州纽约，第 1556–1560 页。ISBN 9781450370431。https://doi.org/10.1145/3368089.3417943 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [29] J. Yang、C. E. Jimenez、A. L. Zhang、K. Lieret、J. Yang、X. Wu、O. Press、N. Muennighoff、G. Synnaeve、K. R. Narasimhan、D. Yang、S. Wang 与 O. Press。SWE-bench Multimodal：人工智能系统能推广到视觉软件领域吗？载于 Proceedings of the Thirteenth International Conference on Learning Representations。https://openreview.net/forum?id=riTiq3i21b 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [30] D. Zan、Z. Huang、W. Liu、H. Chen、L. Zhang、S. Xin、L. Chen、Q. Liu、X. Zhong、A. Li、S. Liu、Y. Xiao、L. Chen、Y. Zhang、J. Su、T. Liu、R. Long、K. Shen 与 L. Xiang。Multi-SWE-bench：用于解决 issue 的多语言基准。载于 Proceedings of the 39th Conference on Neural Information Processing Systems，Datasets and Benchmarks Track。https://arxiv.org/abs/2504.02605 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [31] D. Zhang、S. Zhoubian、M. Cai、F. Li、L. Yang、W. Wang、T. Dong、Z. Hu、J. Tang 与 Y. Yue。DataSciBench：面向数据科学的大语言模型智能体基准。arXiv 预印本 arXiv:2502.13897。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [32] J. M. Zhang、M. Harman、L. Ma 与 Y. Liu。机器学习测试：综述、图景与地平线。IEEE Transactions on Software Engineering 48 (1)，第 1–36 页。https://dx.doi.org/10.1109/TSE.2019.2962027 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。
• [33] Y. Zhang、Q. Jiang、X. XingyuHan、N. Chen、Y. Yang 与 K. Ren。给数据科学智能体做基准。载于 Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)，第 5677–5700 页。 本条按原文出现顺序完整著录，作者姓名、会议名称、页码与网址保留不译。

附录 A 基准示例

表 8 给出端到端生命周期类别中一个有代表性的 MLOps-Bench 实例。这个例子说明，基准任务要求在数据、特征、模型、服务、监控和发布治理表面上做协调的改动，而不是孤立的代码补全。

表 8：有代表性的端到端 MLOps-Bench 任务。

表 9 把同一份基准内容格式化为结构化的 JSON 风格字段。这种表示对应 MLOps-Bench 所用的、元数据丰富的任务记录，同时让附录保持可读。

表 9：基准上下文、需求和约束的 JSON 风格表示。

这个例子说明，这套基准不只是代码补全：一个成功的解必须在仓库的原生工作流上协调数据核验、特征工程、模型训练、模型服务、监控、回滚和治理产物。

译注：表 9 的 JSON 值按纯数据表规则保留英文。业务语境是医疗候诊时间预测，切分包括专科、ROAZ 区域、机构类型和紧急程度；使用者为运营团队、产能规划者与患者分流协调员。风险是错误发布会低估高需求候诊时间，造成服务等级未达标、人工返工和声誉损失。目标是让每次发布从原始数据追溯到已部署模型，并在生产流量前阻断不安全发布。任务要求建立 Airflow 端到端发布 DAG，用 YAML 契约串联数据集版本、特征版本、MLflow 运行或模型版本、部署清单摘要、监控清单、回滚目标与审批状态，并设置数据质量、特征一致性、模型质量、服务就绪、监控和 CI/CD 治理门禁，写出决定为 blocked、canary_only 或 approved 的发布证据包。数据约束针对 wachttijden：至少一万行，类别特征完整率高于百分之九十九点五，目标完整率高于百分之九十九点九，重复率低于百分之零点五，未知类别率按特征低于百分之二，特征新鲜度在二十四小时内，质量回退相对基线不超过百分之二，服务延迟第九十五百分位不超过五百毫秒，预测错误日志率低于百分之一。

A.1 端到端 MLOps 阶段流示例

同一项基准把一次端到端的 MLOps 发布编码为一系列产出产物和消费产物的阶段。表 10 概括所要求的交接。

表 10：有代表性的端到端 MLOps 基准中的产物交接。

对这项任务，智能体必须实现在部署前核验每一次交接的集成层。只有当数据集、特征、模型产物、服务清单、监控契约和回滚元数据都同意同一份发布契约时，一次发布才能被批准。

附录 B 按画像和工作负载的仓库计数

编程语言和结构化格式在这些仓库中的出现如下：Python 出现在 29 个仓库，JavaScript 出现在 3 个，TypeScript、C++、C/C++ 各出现在 1 个仓库。

机器学习工作负载表是从仓库分析摘要和生成的问题陈述推断出的模型目标分解。与模型无关的仓库被计为平台、模板或混合，而不是被强行放进单一的分类或回归桶。

表 11：按机器学习工作负载家族统计的仓库数和任务数。

B.1 带 Codex 解的基准样本

图 3：Codex 在 MLOps Bench 上的通过与失败情形。

附录 C Oracle 生成提示

Oracle 解用一份立足仓库的提示模板生成。完整提示包括问题上下文、仓库分析、原生仓库画像、目标阶段契约和源仓库 URL。图 4 给出 oracle 指令的预览。

你正在为一项 MLOps 基准任务实现 oracle 解。

输入：
- 带有业务上下文、需求、数据上下文和成功标准的问题陈述。
- 仓库分析，包括原生画像、既有文件、依赖文件、目标 MLOps 阶段契约，以及优先的编辑路径。
- 用于来源的源仓库 URL。

任务：
生成一份立足问题的仓库补丁，用可工作的、仓库原生的代码或配置解决该任务。优先扩展既有文件和模式，而不是引入通用模板。

核心约束：
- 匹配该仓库的原生语言、框架、构建系统、目录布局和允许的文件扩展名。
- 复用既有库、配置系统、日志与遥测模式、入口和辅助工具。
- 不要添加不被允许的依赖、无关服务或新的部署目标。
- 实现每一条问题需求，而不只是一个主题相关的功能。
- 对 CI/CD 和治理任务，把门禁接到真实的工作流、脚本或仓库入口上。
- 对端到端任务，通过明确的产物交接和发布门禁，把数据管道、特征工程、模型训练、模型服务、监控和治理连起来。
- 让补丁保持聚焦：通常是 2 到 6 个相对仓库的文件，合计大约 150 到 400 行。

输出：
返回 JSON，包含：
- problem_grounding.requirement_coverage：每条原始需求一项，带有确切的需求文本、被改文件、实现的行为和测试义务。
- problem_grounding.stage_contract_coverage：补丁如何满足目标 MLOps 阶段契约。
- files：oracle 补丁的、相对仓库的完整文件内容。
- integration_points：实现被接到仓库的何处。
- repository_grounding：被扩展的既有文件或模式。
- tests.test_cases：供 fail-to-pass 测试生成使用的期望行为检查。

图 4：用于产出立足仓库的参考解的、压缩后的 oracle 生成指令。

这条提示故意比普通的编码智能体提示更严。Oracle 生成器收到仓库分析元数据，并且必须同时发出代码和一张可审计的立地图；被评测的智能体只收到任务提示和可编辑的仓库快照。

附录 D 人类审计标注协议

本附录记录用于仓库 issue 复用这一人类审计的协议。标注者得到一份共享量规，定义每个 MLOps 生命周期阶段，以及接受与拒绝标准。虽然量规支持逐项的阶段判断，正文所报告的结果聚合为一个二元结果：问题陈述是否构成一项有效的 MLOps 任务。

D.1 标注者审阅了什么

标注者审阅各含 25 项的两套材料，来源不同，但在同一量规下判断。第一套是被自动流水线标为 MLOps 候选的 SWE-bench PR，每一项都配有流水线指派的阶段。对这些，标注者判断被抓取的问题陈述是否真正描述 MLOps 生命周期工作，而不是宿主仓库大体上是不是一个机器学习项目。标注者按抓取到的样子阅读问题陈述，只在需要澄清问题上下文时查阅链接的 issue 或 PR，而不是去推断陈述本身没有的实现细节，因为 GitHub 常常保留电子表格视图会丢失的格式、代码块和截图。第二套是 MLOps-Bench 生成流水线产出的问题陈述，同样每一项都配有被指派的阶段。它们在同一个问题下被判断——该陈述是否构成被指派阶段上的一项有效 MLOps 任务——从而使生成项和改用项按同一标准评测。为避免偏差，生成项被去掉任何流水线元数据（oracle 理由、匹配的证据、核验轨迹），并以独立的问题陈述呈现给标注者。

D.2 MLOps 阶段量规

下面的量规用接受和拒绝标准定义每个阶段。它的存在是为了让 MLOps 有效性判断在标注者之间一致；审阅者被要求在陈述含糊时运用自己的数据科学和 MLOps 判断。

#### 数据管道。

摄入、模式核验、数据质量、数据集版本或血缘——数据进入或流过一个机器学习工作流，并对正确性、结构、质量或可追溯性有明确期望。当 issue 涉及核验数据形状或内容、拒绝坏记录、数据集版本、血缘、质量门禁，或为下游机器学习产出干净数据集时接受。当“数据集”只表示用来复现模型或 API 缺陷的一个例子，或与数据契约无关的通用文件解析时拒绝。

#### 特征工程。

计算、复用、物化或核验可在训练和推理之间复用的机器学习特征。当 issue 涉及特征定义、变换、离线与在线一致性、新鲜度或训练与服务偏斜时接受。拒绝普通的预处理、张量重塑或模型输入转换，除非陈述明确涉及可复用特征或训练与服务一致性。

#### 模型训练。

训练管道、实验跟踪、模型核验和产物。当 issue 涉及训练入口、训练器行为、实验日志、指标或产物跟踪、检查点、核验指标、早停或质量门禁时接受。当训练只是一个通用框架缺陷的复现脚本的一部分时拒绝；只出现在错误信息里的指标不是实验跟踪。

#### 模型服务。

在在线、批量或已部署的上下文中产出预测。当 issue 涉及推理行为、预测端点、批量打分、为服务而加载模型、延迟、回退行为、健康检查、预测失败或服务时的版本选择时接受。当 predict 或 inference 只被用作本地例子中的一个库方法时拒绝。

#### 监控与可观测性。

一旦存在数据、训练或服务信号，就观察模型或系统行为。当 issue 涉及漂移检测、模型或服务健康、仪表盘、告警、生产指标、异常检测或自动再训练触发时接受。当指标只是训练时的评测指标、单元测试计数或附带日志时拒绝。

#### CI/CD 与治理。

决定机器学习数据、模型、管道或部署是否可以安全发布的自动化和控制。当 issue 涉及发布自动化、部署门禁、针对机器学习产物、数据或模型的 CI 检查、回滚行为、审计轨迹、合规元数据或可复现性门禁时接受。拒绝普通的 CI 失败、依赖问题或格式检查，除非它们直接管辖机器学习发布的安全。

[^1]: 评测代码和基准任务发布在 https://github.com/oracle-samples/mlops-bench。 [^2]: 所有选中的仓库都在开源许可证下发布。 [^3]: 这些工作由未参与标注者间活动的机器学习工程师完成。 [^4]: 我们在这里报告原始一致率，因为每一项生成任务都得到同一个标签，这使 κ 对这一二元判断退化。