我们最害怕 A.I. 的地方，到了资源紧绷的领域里，反而可能成了它最容易被接受的理由：A.I. 能放大人的劳动，让我们用更少资源做更多事，也可能把博物馆员工从琐碎流程里解放出来，去处理更有意思的问题。MLOps 即便在深度学习圈里也算前沿，在博物馆里更几乎是闻所未闻；但我想论证的是，博物馆工作场景本身的一些特殊性，恰恰让这套技术栈最值得引入。通过和开源社区合作，机构内部技术能力不足的问题可以被补上，同时也能凸显博物馆在社会中的独特角色：它们本来就应该是对话的空间，也应该是我们批判性审视自己所用工具的空间。因此，这篇文章会用非技术读者也能进入的方式，讨论下面几个部分：

博物馆技术生态中的主要挑战
机会：为什么博物馆需要 MLOps
案例研究
MLOps 实际长什么样
xOps 概览（DevOps、DataOps 和 MLOps）
架构原则、工具与最佳实践
建议

我会主要从馆藏管理和相关使用场景切入，不过这里讨论的原则和流程，大体上也适用于机构技术生态里的其他系统。

博物馆技术生态中的主要挑战

博物馆技术从业者经常提到的一个难题，是外界误解了博物馆技术项目到底需要多少时间和精力 [1]。这并不意外。博物馆行业的数字技能缺口有时相当严重，Arts Council England 的机构中有 37% “表示能力和知识不足，是实现其数字愿景的主要障碍” [2]。项目范围没划清，或者因为技术判断不足而估算离谱，最后通常就是所有人一起痛苦。这不只是博物馆行业的问题；哪怕在 IT 内部，技术版图也已经大到不讲道理，而且变化极快：区块链、原生应用开发、Web 开发、云技术、无服务器计算、混合现实、数据科学、机器学习、算法等等，其实都是非常不同、非常专门的技能，只是全都被塞进 IT 和数字化这个大篮子里。

如果一个机构的采购流程强制使用瀑布式开发，本身又没有内部开发者，最后往往会得到一堆彼此断开的系统，谁也不跟谁说话。有时这是因为继承了旧系统；有时是因为供应商在自己的工作方式里根本没有动力去做互操作。下游结果就是各种流程被重复做：某个地方更新了，另一个地方不会自动同步；不同的人还可能引用不同的文件来源，于是混乱就很自然地发生了。

这就像你的金库钥匙不在自己手里；每次想找自己的东西，还得先付门票。更糟的是，你可能连金库到底在哪都不知道。即便文档写得很清楚，供应商 A、B、C 分别建设和维护不同系统，也没有什么内在动力彼此协作；真到了必须一起干活的时候，最后更可能是在互相甩锅。这不是说博物馆应该变成科技公司。重点是先看清这些内在限制，再把理想终态描出来，这样才有可能带着这些约束去设计通往那里的一条或几条最优路径。

什么是 MLOps？

如果说在“实验室”条件下做模型，是模型构建作为科学研究的那一面，那么 MLOps 就是同一枚硬币的工程面。它是把计算机视觉 PoC [3] 真正推向生产环境时，常常缺掉的那一味。

“整个 AI 领域都有一个从概念验证走到生产环境的鸿沟。一个机器学习项目的完整周期不只是建模。它还包括找到合适的数据、部署、监控、把数据反馈回[模型]、验证系统是否安全可靠，也就是完成[模型]真正部署所需要的一切。这些事情都超出了在测试集上表现良好这件事；而后者，幸运也好不幸也好，正是我们做机器学习的人最擅长的。”——Andrew Ng

机会：为什么博物馆需要 MLOps

首先，博物馆做 MLOps 的一个核心理由，是把最有可能带来投资回报率（Return on Investment）的 A.I. 技术真正投入运行，如下方图 1 [4] 所示。

图 1。常见 AI 子领域，按博物馆相关性和投入/成本两个维度排列。

相较于区块链、元宇宙这类被炒得很热的技术，它们能想象的设计空间远大于真正可落地的使用场景，因此离大规模实用还更远；A.I. 已经在 MATANA2 这组公司中大规模部署，并且准备走向主流。从下方图 2 可以看到，许多对博物馆行业尤其相关的 A.I. 创新，如今已经进入“启蒙斜坡”（Slope of Enlightenment）阶段；这和图 3 里 NFT、Web3 等其他新兴技术形成了对照。