模型部署与利益相关者协作指南

# 模型部署与利益相关者协作指南 ## 1. 系统运行相关要点 ### 1.1 部署方式选择 在部署模型时，Docker 容器和虚拟机是两种常见的选择。由于 Docker 容器启动比虚拟机更复杂，如果你从未进行过代码部署，从虚拟机开始可能会更容易。不过，即便不能用 Docker 将模型部署到生产环境，使用 Docker 进行可重复分析也有诸多好处。所以，至少花点时间积累一些使用该工具的经验是值得的，即便当下不清楚职业发展中是否会用到。 ### 1.2 负载测试 当有大量系统要使用你的模型，或者一个系统要多次同时使用该模型时，你需要确保 API 在压力下不会失败。API 失败可能是因为运行它的系统内存不足，或者处理每个请求的时间过长导致队列越来越长，也可能是其他各种糟糕的情况。 进行负载测试是确保这种情况不会发生的最简单方法。具体操作步骤如下： 1. 向 API 同时发起大量请求。通常，发起的请求数量至少是预期最高请求量的两倍。 2. 观察 API 的表现。如果 API 能顺利处理这些请求，那就没问题；如果崩溃了，你就需要提高代码效率、扩展系统规模或进行其他更改。 ### 1.3 系统持续运行的考虑 即使 API 成功部署并投入使用，这也还不够，你或组织中的其他人需要继续确保 API 正常工作。有些公司设有开发运维（DevOps）团队，其职责就是确保 API 始终正常运行。即便 API 运行良好，你可能也会因为其他原因进行调整。以下是 API 长期维护的三个重要考虑因素： #### 1.3.1 系统监控 持续监控模型的运行情况是个好主意。你需要关注以下指标： - 每小时接收的请求数量。 - 模型预测的准确性。 - 是否有错误发生。 要跟踪这些指标，最简单的方法是让 API 包含日志记录和遥测功能： - **日志记录**：记录工具内部的问题，例如每次模型出错时的情况。操作步骤为让 API 在每次事件发生时将信息写入文件，之后要查看日志，只需进入 Docker 容器或虚拟机即可。 - **遥测**：记录发生的事件，如每次请求或特定预测的情况。通常是将事件信息发送到远程位置（如集中式服务器），这样多个系统的遥测数据就集中在一处，然后可以创建一个仪表板，实时查看和监控遥测数据。 - **警报设置**：使用警报工具，当出现问题时，公司相关人员能及时知晓。这些警报可以是特定事件发生时自动发送的电子邮件或 Slack 消息。例如，如果模型 API 有请求接收的遥测事件，而一整天都没有请求，就可以发送警报邮件通知相关人员系统可能应该有流量但未收到。 这些不同的监控系统通常会结合使用，公司也会尽量进行标准化，以便以相同的方式监控所有公司的 API。 #### 1.3.2 模型重新训练 机器学习模型投入生产一段时间后，性能往往会下降。因为机器学习模型是基于数据进行训练的，随着时间推移，这些数据会变得不再相关。例如，一个用于预测客户流失的机器学习模型，当新地区的客户开始与公司互动时，可能就会出现问题。当模型性能严重下降时，就需要重新训练。 重新训练的方法如下： - **简单方法**：当模型表现不佳时，重复最初训练模型的步骤，但加载更新版本的数据。这可能意味着在 R 或 Python 中将数据加载到计算机上，重新运行脚本，然后以相同的方式将模型投入生产。 - **更复杂的方法**： - 制定标准的重新训练计划，比如每 n 周或每月进行一次，这样可以避免凭直觉判断何时重新训练。 - 实现自动化重新训练。如果你有一个 Python 或 R 脚本可以加载数据、构建模型并保存，就可以设置一个系统按计划自动执行这些操作。这种系统还可以测试新训练的模型是否和之前的模型表现一样好或更好，如果不是，就向数据科学家发送警报。像 AWS SageMaker