从实验室到工厂，模型部署中的几个重要问题及解决方案(2)
2017-05-01 编辑：
注册表需要捕捉到数据、脚本和训练过的模型对象之间的联系，图中说明了与一个模型特定版本相关的文件。
这对我们的实践有什么帮助？
通过收集如何运行一个模型所需的资产和元数据，我们就能驱动一个执行工作流，将模型的特定版本用于实时数据，为终端用户预测结果。如果这是批量程序的一部分，我们就可以利用这些信息为模型创造一个暂态的执行环境，来提取数据、脚本、运行模型、在目标存贮里保存结果，并在程序完成后关闭环境，在最大化资源的同时将成本最小化。
从监管角度来看，我们可以支持那些决定模型何时被推向产业化的商业工作流，这些工作流负责允许运行中的模型监视程序去做出一些决定，比如，当我们发现模型预测已不再符合现实情况时是否应该重新训练它。如果你有审计要求，你可能需要跟顾客解释你是如何得到某个特定结论的。为了做到这一点，你需要去考察在特定时间运行的某个特定版本的模型，并且需要知道复现这个结果用到了什么样的数据。
如果我们在一个已有模型中发现了漏洞，我们可以把它标记成不应该使用，修复后发布此模型的新版本。对所有使用漏洞版本的用户发送通知，他们就可以转而使用新的修复版。
如果不进行以上这些步骤，我们就有可能让模型维护变成需要试图理解原始开发者意图的冒险行为，部署后的模型不再与那些正在开发中模型相匹配，产生不正确的结果，在已有模型升级后还会扰乱下游用户的正常使用。
模型部署
一旦模型被批准部署，我们需要通过几个步骤来确保模型能被部署。要有验证正确性的测试，还要测试提取原始数据的管道流程、特征生成，以及分析模型评分以确定模型可以自主运行，以消费者需要的方式产生出结果，满足行业定义的性能要求。还要确保模型的执行过程处于监控中，以防发生错误或模型过时不再产生准确的结果。
在部署之前，我们要确保测试了下面几项：
部署后的模型是否达到了原始模型开发者的预期。通过采用一个在开发过程中产生有效结果的测试输入集，我们就能验证部署的代码是否与开发中的预期吻合。之前的一篇博文中说明了此过程的必要性（https://goo.gl/LKQbeu）。
部署后的模型是否在多种不同的输入下都能良好运行，测试输出的极端情况，以及由于数据质量问题潜在丢失的数值。同时应该有防止这些输入毁掉模型并最终影响下游顾客的的控制手段。
我们通过两种方式来最小化部署后模型与开发模型匹配时的风险：1）部署到生产环节之前就运行测试，2）捕获环境细节，比如特定的语言版本和模型的库依存性（例如，一个Python requirements.txt 文件）。
一旦部署到生产环节后，我们就想对用户显示模型的预测结果。有多少用户会使用这一模型进行预测？在为模型打分时，提供特征数据的速度要有多快？比如，欺诈侦测中，如果特征信息每24小时产生一次，那么，从事件发生到诈骗侦测模型检测到此事件之间，会存在严重滞后。这就是我们需要解决的一些可扩展性和性能方面的问题。
就一个应用程序来说，最理想的方式是通过网页服务向用户展示结果，方式是通过模型实时得分或是以线下批处理过程展示评分结果。或者是，模型需要支持一个商业过程，我们需要把模型的结果放在一个为决策者生成报告并遵照该这些结果予以行事的地方。无论是那种情况，如果没有模型注册表，想要知道哪里可以找到并使用当前模型的结果是很困难的。
另一个应用实例是想要搞清楚模型如何背离实时数据运行，以考察模型是否变得陈旧，或者确定一个新开发的模型性能是否超过旧模型。一个简单的例子就是用回归模型来对比预期值和实际值。如果我们没有监测到模型结果随时间变化，那么，我们可能是在根据不再适用于当前情势的历史数据在做决策。
结论
这篇文章中，我们遍历了模型周期，讨论了对实验室和工厂的需要，意在降低部署那些可能影响商业决策（并且还可能带来高成本）坏模型带来的风险。另外，注册表也提供了组织中模型的透明性和可发现性。这有利于通过呈现组织使用的现有技术，来研发新模型，解决相似问题，也有利于现有模型维护或通过澄清模型当前版本、目前相关资产情况等来提升模型。
在 SVDS ，我们正在研发一个架构，它能支持模型管理，把不同模型版本登入注册表，并管理如何将这些模型版本部署到一个执行引擎中。
原文地址：http://www.kdnuggets.com/2017/04/models-from-lab-factory.html
本文为机器之心编译，转载请联系本公众号获得授权。
?------------------------------------------------
加入机器之心（全职记者/实习生）：hr@jiqizhixin.com
投稿或寻求报道：editor@jiqizhixin.com
广告&商务合作：bd@jiqizhixin.com
相关阅读：
相关推荐：