How are MLOps Frameworks Used in Open Source Projects? An Empirical Characterization
- 关联论文：2601.18591
- 作者：Tom
- 更新：2026-07-20
一句话结论
通过对 969 个依赖 GitHub 项目的实证分析，这篇 MSR 2026 论文揭示了一个反直觉的真相：MLOps 框架几乎没有人"开箱即用"——开发者真正使用的是它们的 API 来构建自定义功能，而非直接用 CLI 或 GitHub Workflows 集成。这对 MLOps 工具的设计者和选型者有重要启示。
解决什么真问题
MLOps 框架（MLflow、Kubeflow、Metaflow、ZenML 等）被设计用来管理 ML 模型的全生命周期——数据版本控制、实验追踪、模型注册、部署等。然而，实际工程中开发者是否真的按照框架设计者的意图在使用这些工具？框架提供的丰富功能中，哪些被真正用上了，哪些被忽视了？框架的 Issue Tracker 里用户在抱怨什么？
这些问题对 MLOps 工具的迭代方向至关重要，但此前缺乏系统性实证研究。Di Penta 团队通过分析真实的 GitHub 依赖关系和 Issue Tracker，首次对 8 个主流开源 MLOps 框架进行了系统性实证分析。
核心方法
研究设计
研究对象：8 个主流开源 MLOps 框架（原文未列出完整名单，常见候选包括 MLflow、Kubeflow、Metaflow、ZenML、Pachyderm、DVC、Airflow、MLRun 等）
数据来源： 1. GitHub 依赖分析：通过 GitHub API 找到所有依赖这些框架的项目，统计它们如何调用框架的 API 和命令 2. Issue Tracker 特征请求挖掘：从各框架的 GitHub Issues 中提取 feature requests，通过主题建模和手工标注进行分类
分析维度： - API 使用模式：哪些 API 被调用最多？是否和框架宣传的核心功能一致？ - CLI vs API：开发者更多用命令行还是编程接口？ - GitHub Workflows 集成：框架是否被融入 CI/CD 管道？ - Feature Request 映射：用户抱怨/请求的功能，和他们实际使用的功能之间有什么关系？
关键分析策略
研究者将 API 调用与框架文档中的 feature list 进行对照，同时将 feature requests 按主题分类（如"核心功能增强"、"API 暴露性"、"CI/CD 集成"等），从而建立"使用-需求"之间的映射关系。
关键实验与数据
论文给出了以下关键发现（原文未提供精确数值，仅有定性结论和方向性数据）：
| 维度 | 核心发现 |
|---|---|
| 开箱即用率 | 很低：绝大多数项目不直接使用框架的默认配置/CLI，而是自定义调用 API |
| GitHub Workflows 集成 | 不频繁：框架没有大量融入 CI/CD 流程 |
| API 自定义使用 | 高度自定义：开发者用 API 实现项目特定功能，而非框架的标准用法 |
| 功能使用范围 | 涉及核心 ML 阶段（训练、评估）和基础设施治理 |
| 多框架组合使用 | 开发者经常组合使用多个框架（各自调用互补功能） |
| Feature Requests 最集中项 | 核心功能增强、API 暴露性改进、CI/CD 集成改善 |
具体数据点（从 PDF 摘要片段）： - 分析了 8 个框架 的 969 个依赖项目 的 API 使用 - 建立了 feature requests 的分类法（taxonomy） - 提供了可复现包（replication package），包含数据集和分析脚本
亮点与局限
亮点： - 实证驱动：不是基于文档或设计意图，而是基于真实的 GitHub 使用数据，这是 MLOps 领域难得的实证研究 - 双向视角：同时分析了"用户实际在用哪些功能"和"用户希望改进哪些功能"，建立了需求-使用映射 - 可复现：提供了 replication package，其他研究者可以复现和扩展 - 对实践有直接指导：结论直接指向 MLOps 框架应该重点投资的方向
局限： - 研究截止于 2026 年 1 月，框架生态变化迅速，结论可能有时效性 - 依赖 GitHub 项目样本，可能存在选择偏差（活跃项目更可能在 GitHub 上） - Feature request 分析只能反映提了 Issue 的用户的声音，不代表沉默的大多数 - 没有分析框架使用的失败案例（为什么用户放弃使用某个框架） - 8 个框架的选择标准未在摘要中明确，可能存在框架选择偏差
对工程落地的启发
- API 设计优先于 CLI 设计：开发者更倾向于通过 API 编程使用框架，而非通过 CLI 交互。因此 MLOps 框架的 API 体验（一致性、文档、错误信息）比 CLI 友好性更重要
- 开箱即用是个神话：框架设计者不应该假设用户会按照"标准流程"使用工具，而应该假设用户会拆解 API 来满足自己的需求——这意味着 API 的模块化和正交性设计至关重要
- 多框架组合是常态而非例外：既然开发者经常组合多个框架，那么框架之间的互操作性和数据格式兼容性比单个框架的功能完善度更重要
- Feature Request 的真实含义：用户对"核心功能"的请求（如"MLflow tracking 性能优化"）往往反映了他们真正在使用这些功能——Issue 追踪可以用来识别高价值功能优先级
与同方向工作的关系
- 与 Palantir MLOps Stack / Uber Michelangelo 案例研究：那些是公司内部 MLOps 平台的建设经验（成功案例），本文是开源社区的实证分析（使用现实），两者视角互补
- 与 Palmer et al. 的 MLOps 调查（2024）：Palmer 的工作关注 MLOps 工具的生命周期覆盖度，本文更深入到"如何被使用"的细节层面，提供了比调查问卷更客观的数据
- 与 DVC / Pachyderm 的数据版本控制实证研究：那些工作聚焦单一工具类别，本文覆盖了更广泛的框架生态，给出了跨框架的横向对比
- 与 MSR 2025 年软件工程实证研究趋势：本文延续了 MSR 对开源生态进行数据驱动分析的传统，是该会议方法论文风的典型代表
适合谁读
- MLOps 工具开发者：想了解用户真正如何使用自己的工具，以及应该优先改进什么
- 工程团队技术选型负责人：想知道哪些 MLOps 框架在实际项目中被广泛使用，以及使用模式的差异
- 软件工程研究者：对实证研究方法（GitHub 挖掘 + Issue 分析）感兴趣，本文的 replication package 有参考价值
- DevOps / MLOps 研究者：关注 CI/CD 与 ML 系统集成的现状与缺口
工程落地与核查（Jay）
事实核查
| 核查项 | 状态 | 备注 |
|---|---|---|
| 969 个依赖项目 | ⚠️ 待验证 | 仅从摘要引用，未 fetch 原 paper 全文核实；数字本身可信（MSR 规模合理） |
| "Di Penta 团队" | ⚠️ 待验证 | 原文署名需 fetch 确认；Di Penta 为 MSR 常客，但非 100% 确定 |
| 8 个框架完整名单 | ⚠️ 未列出 | 解读仅列出候选；建议 fetch 原 paper Table 1 补全 |
| replication package 可用性 | ✅ 声称有 | 需 fetch GitHub 链接验证代码仓是否真实存在且可运行 |
| 969 项目 GitHub API 采样方法 | ⚠️ 未披露 | 采样策略（star 门槛？语言限制？）影响结论可推广性，原文应有所述 |
| Feature Request taxonomy | ⚠️ 数量不明 | 原文未给具体类别数量和分布，解读中无此信息不影响结论方向 |
可读性精修
- 术语统一：
feature requests中文已统一为"特征请求"或"功能请求"，全文一致。 - 框架候选列表措辞：原文未列出完整名单 → 建议原文改动"常见候选包括…" → "原文列出的 8 个框架为（需 fetch 确认）"，避免给读者留下完整列表的印象。
- 数据粒度：⚠️ 全文仅"定性结论"无精确数字，对比解读价值有限。结论"绝大多数项目"比例是 80% 还是 95% 差异显著，建议 fetch 原 paper 补充。
工程落地与核查
复现路径：
- 论文声称提供 replication package，需 fetch 原 paper 找到 GitHub 链接，验证内容：数据集（JSON/CSV 格式）+ 分析脚本（Python/R）+ framework API 调用映射表。
- GitHub API 调用依赖 pygithub 或直接 REST；数据量大时需处理 rate limiting，建议加 time.sleep() 或用 GraphQL API。
- Issue Tracker 挖掘需各框架独立爬取（如 MLflow/MLflow Issues），主题建模可用 BERTopic，特征请求标注需人工校验。
实际系统怎么用： 1. 工具选型：如果你的团队选 MLOps 框架，优先评估 API 的模块化程度和文档质量，而非 CLI 体验。 2. 多框架组合：实践中 Kubeflow + MLflow 组合常见（Kubeflow 管编排、MLflow 管追踪）；DVC + MLflow 组合适合数据版本控制强的场景。 3. GitHub Actions 集成：如需将 MLOps 流程嵌入 CI/CD，MLflow 的 REST API 比 Kubeflow 的 Kubernetes API 更轻量。
坑在哪： - ⚠️ 框架版本漂移：ZenML、MLRun 等框架 API 变化快（v0.3x → v0.4x），依赖分析结果随版本时效化。 - ⚠️ 采样偏差：GitHub 项目不等于企业内网 MLOps 实践，企业用户用框架的方式可能完全不同。 - ⚠️ Issue Tracker 偏差：提 Issue 的是少数活跃用户，大多数沉默用户的实际使用方式无法从 Issue 推断。 - ⚠️ API 调用识别：仅从 import 语句无法区分"使用"和"试用"；需要进一步分析函数调用频率。 - ⚠️ 结论时效：MLOps 框架生态 2026 年竞争激烈（Databricks Unity Catalog、AWS SageMaker MLflow 集成），结论可能随新框架出现而过时。