# MLOps 还没解决的几个硬问题

> 原标题：Unsolved Problems in MLOps

- 来源：Hacker News 首页
- 发布时间：2026-07-15T16:15:01.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/44520
- 原文：https://spawn-queue.acm.org/doi/pdf/10.1145/3762989

## 摘要

ACM Queue 这篇文章把现在 MLOps 的尴尬摊开了：传统运维那套靠确定性响应做健康检查、灰度发布、告警的方法，在 ML 系统上基本失灵。核心矛盾就两条——模型输出不是确定的，以及数据跟代码一样在驱动系统行为。文章举了几个扎心的例子：微软 Azure 验证新模型好不好用，居然是让另一批大模型当裁判，再靠内部员工点“赞”来兜底，SRECon 现场...

## 推荐理由

这篇 ACM Queue 文章把 MLOps 的核心矛盾讲得很透：传统运维靠确定性响应做健康检查和灰度发布，但 ML 系统输出不确定，数据跟代码一样在改变系统行为。微软 Azure 的例子尤其扎心——用大模型当裁判验证新模型，再靠员工点赞兜底，说明行业连“模型好不好用”都没个靠谱的自动化标准。对正在把模型往生产环境塞的工程师来说，这篇文章不是给答案，是把问题清单列出来了，实用价值很高。

## 锐评

这篇文章把MLOps的底裤扒了。传统运维靠确定性响应做健康检查、灰度发布、告警，在ML系统上全得推倒重来。核心矛盾就两条：模型输出不是确定的，数据跟代码一样在驱动系统行为。

最扎心的例子来自微软Azure。Brendan Burns在SRECon现场说，他们验证新模型质量就两招——让LLM当裁判给LLM输出打分，再靠内部员工点“赞”兜底。现场听众都惊了。这办法能过滤掉离谱回答，但给不出清晰的质量梯度，而且没几家有微软那么多员工可以当人肉评测员。

文章没给出解法，只是摊开了问题。正文没披露具体替代方案或实验数据，更像一份从业者的集体吐槽。缺的是：有没有团队在尝试新的健康检查范式？用LLM评LLM的可靠性到底有多高？这些都没展开。