为了给模型一个结构，我们会根据模型的组件进行定义，包括数据依存性，脚本，配置以及文件。另外，我们会捕获模型上的元数据及其不同版本，提供额外的商业环境和模型特定信息。给模型提供一个结构，接着就能将模型目录清单存在模型注册表中，包括了不同模型版本，以及执行过程反馈的关联结果。下面的图示解释了这个概念。

　　通过注册表，我们可以：

明确哪个版本的模型正在被使用，并控制它。

查看发布说明，搞清楚某个特定版本发生了什么变化。

查看与模型相关联的资产和文件，这对于创建一个已有模型的新版本或管理维护是有用的。

监管模型执行的性能标准，以及什么程序在使用它。这些信息是在模型执行过程中产生的，直播，会把权值反馈给注册表。

你同样也可以选择在模型某个版本中加入 Jupyter Notebook。这可以让一个审阅者或开发者遍历此版本原始开发者最初开发时的思维过程和假设。有助于模型维护，也有助于组织探索。

这里有一个矩阵，解构了一个模型的不同元素：

　　注册表需要捕捉到数据、脚本和训练过的模型对象之间的联系，图中说明了与一个模型特定版本相关的文件。

这对我们的实践有什么帮助？

通过收集如何运行一个模型所需的资产和元数据，我们就能驱动一个执行工作流，将模型的特定版本用于实时数据，为终端用户预测结果。如果这是批量程序的一部分，我们就可以利用这些信息为模型创造一个暂态的执行环境，来提取数据、脚本、运行模型、在目标存贮里保存结果，并在程序完成后关闭环境，在最大化资源的同时将成本最小化。

从监管角度来看，我们可以支持那些决定模型何时被推向产业化的商业工作流，这些工作流负责允许运行中的模型监视程序去做出一些决定，比如，当我们发现模型预测已不再符合现实情况时是否应该重新训练它。如果你有审计要求，你可能需要跟顾客解释你是如何得到某个特定结论的。为了做到这一点，你需要去考察在特定时间运行的某个特定版本的模型，并且需要知道复现这个结果用到了什么样的数据。

如果我们在一个已有模型中发现了漏洞，我们可以把它标记成不应该使用，修复后发布此模型的新版本。对所有使用漏洞版本的用户发送通知，他们就可以转而使用新的修复版。

　　如果不进行以上这些步骤，我们就有可能让模型维护变成需要试图理解原始开发者意图的冒险行为，部署后的模型不再与那些正在开发中模型相匹配，产生不正确的结果，在已有模型升级后还会扰乱下游用户的正常使用。

　　模型部署

　　一旦模型被批准部署，我们需要通过几个步骤来确保模型能被部署。要有验证正确性的测试，还要测试提取原始数据的管道流程、特征生成，以及分析模型评分以确定模型可以自主运行，以消费者需要的方式产生出结果，满足行业定义的性能要求。还要确保模型的执行过程处于监控中，以防发生错误或模型过时不再产生准确的结果。

　　在部署之前，我们要确保测试了下面几项：

部署后的模型是否达到了原始模型开发者的预期。通过采用一个在开发过程中产生有效结果的测试输入集，我们就能验证部署的代码是否与开发中的预期吻合。之前的一篇博文中说明了此过程的必要性（https://goo.gl/LKQbeu）。

部署后的模型是否在多种不同的输入下都能良好运行，测试输出的极端情况，以及由于数据质量问题潜在丢失的数值。同时应该有防止这些输入毁掉模型并最终影响下游顾客的的控制手段。

　　我们通过两种方式来最小化部署后模型与开发模型匹配时的风险：1）部署到生产环节之前就运行测试，2）捕获环境细节，比如特定的语言版本和模型的库依存性（例如，一个Python requirements.txt 文件）。