If you don't know the provenance or the source of the artifact, it's not science, it's a pretty thing to look at. — Erin McKean

前言

我们都知道在写程序的时候要使用版本控制来追踪、维护程序码，但在机器学习的领域是否需要类似的方法论呢?
在开始今天的文章之前，先来想想看以下问题该怎麽回答：

• 这个模型使用哪个资料集训练的？
• 使用哪些超参数？
• 使用了哪个 pipeline 来建立这个模型？
• 使用了哪个版本的 TensorFlow (或其他函式库)？
• 什麽因素导致模型失效？
• 上次部属了这个模型的哪一个版本？

这些问题看似无关紧要，反正产品可以用就好，何必对模型进行身家调查，但良好的机器学习系统应该要持续地产生一致的结果，而为了确保可再现性，能流畅的回答这些问题便是关键。
但实务上，要厘清这些机器学习生成物 (Artifact) 之间的脉络与连结可远比使用简单的线性日志来记录还要复杂。
因此，我们必须导入被称为资料版本控制 (Data versions control) 的概念。
而且由於资料档案的尺寸通常比程序码大的多，所以资料版控的工具在本质上与我们熟悉的程序码版控 (Git) 以及环境版控 (Docker) 工具有很大的差异。
常被用来进行资料版控的工具有 DVC、 Git LFS (Large Files Storage)，以及今天我们要介绍的 ML metadata (MLMD)，它可以追踪与回溯资料与模型在训练过程中的改变，进一步帮助我们除错、提昇可再现性以及遵守使用资料的相关法规，那我们就开始吧!

Data Pipeline 与旅程

从原始特徵、标签到最终预测，资料会经过很多不同的转换，而这一连串的操作就组合成了 Pipeline。
当我们在训练模型时，资料就在 Pipeline 中随着模型学习映射函数的过程转换与改变，
厘清资料在整个产品生命周期 Pipeline 中的 "旅程" 可以帮助我们了解资料的 "血统关系 (provenance & lineage)"，也就是回答前言里那些问题的关键。

因为模型本身就是训练资料的一种表示法，所以可以将模型视为资料的转换。

而产品化最重要的工作就是 "重现" 研发时的前处理 Pipeline，以确保演算法在作为产品时接收的输入资料分布与研发阶段相同，其中两个阶段的工作要点如下：
POC (proof-of-concept)：

• 目标为确认这个应用可行而且值得部署。
• 着重於让 prototype 可以运作。
• 就算前处理是手动的也 OK，只是要记得注解清楚。

Production：

• 等专案的基础架构都建立好了之後，使用更优雅的工具来确保资料 pipeline 的再现性：
  • TensorFlow Transform
  • Apache Beam
  • Airflow...

以预测某人是否在找工作为例，可能的 Pipeline 如下图：

其中 [资料+ML code] 代表使用该资料训练模型，[模型+资料] 代表使用该模型对资料进行推论。

这种复杂的 Pipeline 在大型商业系统中并不少见 (通常会更复杂)，可以想见如果其中某个资料集做了改变势必会牵一发动全身。
为了增加这类系统的可维护性，可以试着追踪以下两个资讯：

• 来源 (provenance)：资料的来源，例如 Spam dataset 跟谁买的。
• 族谱 (lineage)：从源头到 Pipeline 结尾的一系列步骤，也就是上面这张图。

而目前的做法就是尽可能纪录各种元资料 (Metadata)，也就是资料的资料。
以瑕疵检测为例，可以记录任何与 x、y 有关的资料，像是影像取得的时间、工厂、产线、相机参数，以及标注者的 ID 等。

这麽做的优点在於：

• 帮助错误分析，特别是找出预料之外的因素，例如模型表现变差可能来自某条产线的相机问题。
• 追踪资料来源 (因此记录中介模型的 ID 也是可以的)。

名词小整理

这里整理一下上面出现的名词：

• Pipeline 部件执行後的结果称为 Data artifacts，例如不同特徵工程阶段产生的资料、训练後的模型、schema、metrics…
• 与 Data artifacts 相关的资讯称为 Metadata。
• Data provenance、lineage 则是随着 Pipeline 运作依序出现的一系列 Artifact，也就是各项转换之间的连结关系，因此可用来解释模型产生的结果，进而协助除错、了解训练过程与比较不同次训练之间差别。

ML metadata

MLMD 为追踪与存取 metadata 的函式库，它可以被整合进 ML Pipeline 中，也可以单独使用。
使用 MLMD 时，我们必须知道资料如何在各个 Pipeline 部件之间流动，其中资料流的每一步都可以用一个实体 (entity) 来描述，这些实体又可以被视为单位 (Unit)。
而每个单位又可以使用性质 (property) 来描述额外的细节资讯，这些性质会储存在相对应的类型 (Types) 中，以下为 MLMD 常用的术语：

• Artifact：进出 metadata store 的基础资料单位，可以被储存或作为 Pipeline 部件的输入与输出。
• Execution：纪录任何在 ML pipeline 中执行的部件以及相对应的执行参数 (runtime parameters)。
• Context：所有 Artifact 与 Execution 都只能与一种部件连结，而每种部件的 Artifacts 与 Executions 都能分别整理在一起，这个集合就称为 Context，例如某个专案、实验、Pipeline 细节的 metadata。

最後，Relationships 会储存不同 Unit 之间互动时产生或使用的 Unit，例如 Event 纪录的就是 Artifact 与 Execution 之间的关系。
简单来说，MLMD 纪录各种 Pipeline 部件的相关资讯，这些资讯会被表成 metadata 物件存进後端储存选项中：

*图片来源：MLEP — Introduction to ML Metadata

在 MLMD 的整体架构中，最上层为 ML Pipeline 中的各种部件，它们各自与 MLMD 的集中式元资料管理 MetadataStore 连接，因此每个部件都可以在 Pipeline 的各个阶段独立存取 metadata。
MetadataStore 的核心为 Artifact (以相对应 ArtifactType 描述)，它可以作为 Pipeline 部件的输入值，而其如何被 Pipeline 部件使用则纪录进 Execution 中。
而 Artifact 作为某部件的输入会被纪录为 input Event，相对应地该部件产生新的 Artifact 作为输出则会纪录为 output Event。
Artifacts 与 Executions 之间的互动则藉由 Attribution 与 Association Relationships 与 Context 连结在一起。
最後，所有在 MetadataStore 产生的资料都会存进各种不同的後端储存选项中，例如 SQLite、MySQL，而大型物件则存进 file system、block store。

*图片来源：ML Metadata

除了追踪资料的血缘关系以外，使用 MLMD 还有以下好处：

• 建立描述 Pipeline 中各部件执行顺序与关系的 DAG，这对除错很有用，例如验证执行时使用了哪些输入。
• 在进行一系列实验後，统整属於某类别的所有 Artifacts，例如所有训练过的模型，如此一来便能比较不同次训练的模型。

MLMD 实作

实作我一率推荐官方教学，这里就不重复说明了。

以上就是今天的内容啦，今天也是机器学习产品生命周期资料部分的最後一篇，明天就要再次回朔一步，谈谈 Scoping 罗。

参考资料

• Coursera — Machine Learning Data Lifecycle in Production
• Coursera — Introduction to Machine Learning in Production
• Building a data pipeline
• ML Metadata: Version Control for ML
• Metadata store