·
关注 发布于 Towards Data Science ·7 min 阅读·2023 年 1 月 16 日
--
使用模型回滚很有趣！
机器学习社区普遍认同模型可能对传统上被边缘化的群体做出偏见决策。从凯瑟·奥尼尔博士到乔伊·布乌拉姆威尼博士的伦理 AI 研究人员已经付出了巨大的努力，建立了一个基于偏见和不具代表性数据的错误决策模式，这导致了严重的危害。不幸的是，我们的“智能”学习算法仅与我们使它们一样聪明、能干和道德，我们才刚刚开始理解偏见模型的长期影响。幸运的是，我们已有许多策略可以在危害出现时加以缓解。今天，我们将重点关注一种非常强大的策略：通过版本控制进行模型回滚。
当普通的机器学习或 AI 从业者过去构建模型时，模型构建者的优先级通常是这样的：
传统数据工作流
你从云源收集数据，将数据保存到数据库中，然后编码一个高效的模型，将表现最佳的模型交给运营或工程团队，以便将其集成到他们的大型代码库中，并在他们的网页应用程序中部署。
这个框架——虽然简化且整洁——在许多方面都失败了：
-
模型性能通过它们的评分或公司推动的 KPIs 来判断——而不是通过使用模型输出的人的长期影响来判断。
-
模型构建者与模型集成过程脱离，而部署模型的人员对模型如何做出决策知之甚少。这导致对模型构建过程缺乏透明度，工程师们无法检测部署的模型是否按预期工作，或可能持续带来危害。
-
即使模型构建者花时间找到代表性数据，并且有一个在训练过程中没有造成伤害的高效模型，脱离模型部署过程意味着他们对模型在面对新数据时做出的决策几乎没有可见性，而这些数据在“野外”中可能会有偏见。
认识到这些问题及更多问题使得道德上需要一种新的模型构建者类型——一种既认识到构建高效模型的价值，同时理解学习模型集成所带来的独特机会，可以在部署后改善模型性能，同时减少偏见。这些无可挑剔的思维可以在全技术领域的 MLOps、AI 和分析工程团队中找到。与上述模型工作不同，他们的流程扩展为包括以下内容：
MLOps 过程
从数据库中提取数据后，创建多个模型来解决公司的问题，这些模型通过诸如 Docker 之类的服务进行容器化。创建一个 API 指向模型所在的端口主机，它可以为用户交互提供 Web 应用程序的输出。所有输出都通过诸如 MongoDB 之类的服务摄入到云端进行进一步分析，并附加到模型输出的监控系统，例如 Grafana，如果模型无法很好地推广到世界，就提供警报。这个过程可以更好地可视化模型在部署后的性能，并轻松实施模型版本控制技术。
模型版本控制 是一种工作流程，允许工程师跟踪软件随时间的变化，是基于模型的版本控制。当我们在模型集成过程中加入模型构建者，我们能够追踪我们使用的模型，并根据其在集成到更大系统时的表现进行相应调整。
模型构建过程是迭代的，需要随时间进行多次更改。模型构建过程的每一步都可能导致目前用来使模型性能良好的内容被替换、改变或调整，以改善未来性能。模型版本控制将允许每个过程步骤的更改步骤快照，并保存每个模型更改的先前迭代或版本，以备将来可能使用。
这可能看起来像这样：
-
假设最初您从一个人口中提取了数千个特征的数据，但在进行一些特征工程后，通过运行一些特征重要性算法，您将数据集缩小到了人口中最“重要”的特征。模型版本控制可以对您的数据进行跟踪，以追踪所选择用于模型的特征的演变。
-
在训练多个模型时，您选择在超参数调整过程中调整不同的参数。版本控制可以追踪您在模型构建过程中尝试的许多模型版本。
-
在将模型集成到一个更大的系统中时，您选择部署给公众的是模型 1，而不是模型 2 或 3。虽然模型 1 在训练过程中性能最佳，但在集成到更大系统时却不能做出适当的决策。模型版本控制允许您在模型部署时继续对模型进行改进，并推动一个更好的模型版本或切换所选择的模型，甚至恢复到之前的模型版本，而不会对您的网络应用程序造成任何中断。
这就是模型版本控制允许模型回滚的地方。
想象一下，你作为机器学习经理，任务是让你的团队创建一个可以根据个人信用评分做出贷款决定的机器学习模型。在现状下，有一个简单的技术解决方案，设定一个阈值信用评分，低于此评分的客户将被自动拒绝，高于此评分的信用申请将被送到信用风险分析师处，由他们做出最终决定。这个过程虽然比旧系统好很多，旧系统中的每个人的申请都需要信用风险分析师阅读后才做决定，但仍然存在问题。
-
由于应用程序过多，信用风险分析师无法及时做出决定。
-
一些没有信用记录的人被拒绝，可能是贷款的好候选人，但由于阈值技术解决方案，信用风险分析师甚至无法接触到他们。
-
存在性别和种族因素，其中白人男性比其他人更有可能通过技术解决方案的信用检查，而其他人则因仅仅因为信用记录而更容易被自动拒绝。
-
许多人离阈值分数只有几分，这些人被归入那些信用评分远低、风险更高的人群中。
-
这些问题正在为你的公司造成大量的收入损失。
你的团队开始着手创建一个可以解决这些问题的模型。你首先确保你的团队找到你认为具有代表性的数据。一旦完成，你让他们创建多个模型——一个启发式模型，一个逻辑回归模型，最后一个随机森林模型——以确定哪个模型性能最好。然后，你将模型交给另一个团队，将其集成到更大的代码库中。你所在的公司存在各自为政的情况，因此你无法看到模型的部署情况，也不愿了解。在 6 个月后，模型看起来运行良好——直到一篇社论发布了如下标题“信用公司算法歧视非二元性别者和非大学学历者”。你的老板打电话告诉你，模型将立即下线。由于推进模型的简单技术解决方案已经被弃用，因此重新上线需要一些时间。在此期间，所有申请将转到信用风险分析师处。
这种情况在数据行业中发生得远比必要的要多。一个同时与模型构建者和工程师合作的集成团队，或者一个全新的团队，专门利用模型构建者将模型集成到代码库中，并利用模型版本控制的优势，将大大减少这种麻烦。
具体来说：
-
在数据收集过程中，可以保存和标记数据集的版本，以实现透明度，并为模型构建者在未来重新考虑提供机会（如有需要）。
-
在模型构建过程中，每个模型的所有版本都可以被保存，以便模型构建者重新考虑不同的超参数技术，如果部署的模型在使用时开始做出偏见决策。
-
在部署期间的模型版本控制将允许简单的技术解决方案保持运行，同时新的模型被发布到公众。如果出现问题，可以回滚模型，并将简单的技术解决方案推进，机器学习团队则会修复问题。
-
在修复模型问题时，模型构建者将对可能导致这种结果的过程步骤有更大的可见性。这可以减少改进问题所需的时间，从而在长期节省公司时间、资源和金钱。
模型版本控制允许模型回滚，这可以长期节省公司开支，但更重要的是，帮助减少偏见（如果出现的话）。然而，这种技术在你拥有一个不仅了解如何构建模型，还知道如何在生产中优化模型的团队时效果最佳。为了实现这一点，你必须通过模型构建者和工程师之间的协作，或者通过创建一个包含 MLOps、AI 或分析工程师的混合团队，扩展模型构建团队的可见性。
有什么想法？在下面的评论中分享吧！
- 所有图像均由作者创建。
推荐阅读
O’Neil, Cathy. 数学毁灭武器：大数据如何加剧不平等并威胁民主。纽约：企鹅图书，2018 年。
Gebru, Timnit, 和 Joy Buolamwini. “性别阴影：商业性别分类中的交叉准确性差异。”《机器学习研究会议论文集》81（2018 年）：1-15。