高端建设响应式网站,网站开发网站页面,做网站公司需要什么条件,网站没被收录一、说明 在这篇博文中#xff0c;我们分享了将 Netflix 大规模搜索和推荐系统的多个相关机器学习模型整合到一个统一模型中的系统设计经验。给定不同的推荐用例#xff0c;许多推荐系统将每个用例视为单独的机器学习任务#xff0c;并为每个任务训练定制的 ML 模型。相比之… 一、说明 在这篇博文中我们分享了将 Netflix 大规模搜索和推荐系统的多个相关机器学习模型整合到一个统一模型中的系统设计经验。给定不同的推荐用例许多推荐系统将每个用例视为单独的机器学习任务并为每个任务训练定制的 ML 模型。相比之下我们的方法从单个多任务机器学习模型中为多个用例生成建议。这不仅提高了模型性能还简化了系统架构从而提高了可维护性。此外为搜索和建议构建通用的可扩展框架使我们能够更快地为新用例构建系统。我们描述了为实现这种整合所做的权衡以及我们学到的可以普遍应用的经验教训。
二、背景 图 1典型推荐系统中的多个用例 在电子商务、流媒体服务和社交媒体等大型现实世界推荐系统应用程序中训练多个机器学习模型以优化系统不同部分的项目推荐。不同的用例有单独的模型如通知用户到项目的建议、相关项目基于项目到项目的建议、搜索查询到项目建议和类别探索类别到项目的建议图 1。然而这可能会迅速导致系统管理开销和维护大量专用模型的隐性技术债务Sculley et al. 2015。这种复杂性会导致长期成本增加并降低 ML 系统的可靠性和有效性Ehsan Basillico2022 年。
图 2 显示了这种具有模型扩散的 ML 系统的外观。通知、相关项、搜索和类别探索等不同用例具有不同的 UI 画布用户可以在其中与之交互。针对这些不同用例的 ML 系统通常会演变为具有多个离线管道这些管道具有类似的步骤例如标签生成、特征化和模型训练。在在线端不同的模型可能托管在不同的服务中具有不同的推理 API。但是离线管道和在线基础结构中都存在许多共性这种设计没有利用这些共性。 图 2ML 系统中的模型扩散 在这篇博客中我们描述了我们利用这些任务的共性来整合这些模型的离线和在线堆栈的努力。这种方法不仅减少了技术债务而且通过利用从一个任务中获得的知识来改进另一个相关任务从而提高了模型的有效性。此外我们注意到在跨多个推荐任务有效实施创新更新方面的优势。 图 3 显示了整合的系统设计。在特定于用例的标签准备的初始步骤之后我们统一了离线管道的其余部分并训练了单个多任务模型。在在线端灵活的推理管道根据延迟、数据新鲜度和其他需求在不同环境中托管模型并且模型通过统一的画布无关 API 公开。 图 3整合的 ML 系统
三、离线设计 在脱机模型训练管道中每个建议任务都映射到需要显示建议的请求上下文。请求上下文架构因特定任务而异。例如对于查询到项目建议请求上下文将由查询、国家/地区和语言等元素组成。另一方面对于逐项建议请求上下文还将包括源项目和国家信息。请求上下文架构的组合是量身定制的以适应每个建议任务的要求。
脱机管道从以下阶段记录的交互数据训练模型
标签准备 清理记录的交互数据并生成request_context标签对。
特征提取为上述生成的request_context标签元组生成特征向量。
模型训练基于feature_vector标签行训练模型。
模型评估使用适当的评估指标评估训练模型的性能。
部署 使模型可用于在线投放。 对于模型整合我们将统一请求上下文设置为跨任务的所有上下文元素的联合。对于特定任务缺少或不必要的上下文值将替换为 sentinel默认值。我们引入了一个task_type分类变量作为统一请求上下文的一部分以通知目标推荐任务的模型。 在标签准备中来自每个画布的数据都会使用统一的请求上下文架构进行清理、分析和存储。然后将来自不同画布的标签数据与适当的分层合并在一起以获得统一的标记数据集。在特征提取中并非所有特征都包含某些任务的值并使用适当的默认值填充。
四、在线设计 大规模提供单个 ML 模型会带来某些独特的在线 MLOps 挑战Kreuzberger 等人2022 年。每个用例在以下方面可能有不同的要求
延迟和吞吐量 不同的服务级别协议 SLA以保证延迟和吞吐量目标以提供最佳的最终用户体验。可用性 模型服务正常运行时间的不同保证无需诉诸回退。候选集不同类型的项目例如视频、游戏、人物等可以根据特定于用例的业务需求进一步策划。预算 模型推理成本的不同预算目标。业务逻辑 不同的预处理和后处理逻辑。 从历史上看特定于用例的模型会进行调整以满足独特的要求。核心在线 MLOps 挑战是支持各种用例而不会在模型性能方面倒退到最低公分母。
我们通过以下方式应对这一挑战
根据用例在不同的系统环境中部署相同的模型。每个环境都有“旋钮”来调整模型推理的特征包括模型延迟、模型数据新鲜度和缓存策略以及模型执行并行性。公开用于消费系统的通用、与用例无关的 API。为了实现这种灵活性API 支持异构上下文输入用户、视频、流派等、异构候选选择用户、视频、流派等、超时配置和回退配置。
五、吸取的教训 将ML模型合并为单个模型可以被认为是软件重构的一种形式Cinnéide等人2016。与软件重构类似其中相关代码模块被重组和整合以消除冗余并提高可维护性模型整合可以被认为是将不同的预测任务组合到单个模型中并利用共享的知识和表示。这样做有几个好处。
5.1 减少代码和部署占用空间 支持新的 ML 模型需要在代码、数据和计算资源方面进行大量投资。设置训练管道以生成标签、功能、训练模型和管理部署非常复杂。维护此类管道需要不断升级底层软件框架并推出错误修复。模型整合是降低此类成本的重要杠杆。
5.2 提高可维护性 生产系统必须具有高可用性必须快速检测和解决任何问题。ML 团队通常有随叫随到的轮换以确保运营的连续性。单一的统一代码库使待命工作更轻松。好处包括几乎没有上下文切换工作流的同质性更少的故障点和更少的代码行。
5.3 将模型改进快速应用于多个画布 使用多任务模型构建整合的 ML 系统使我们能够将一个用例中的改进快速应用于其他用例。例如如果针对特定用例尝试某个功能则通用管道允许我们在其他用例中尝试该功能而无需额外的管道工作。对于其他用例需要权衡潜在的回归因为为一个用例引入了功能。但是在实践中如果合并模型中的不同用例足够相关则这不是问题。
5.4 更好的可扩展性 将多个用例整合到一个模型中需要灵活的设计并在合并多个用例时要额外考虑。因此这种基本的可扩展性使系统经得起未来的考验。例如我们最初设计模型训练基础设施来整合一些用例。然而事实证明整合这些多个用例所需的灵活设计对于在同一基础设施上载入新模型训练用例是有效的。特别是我们包含可变请求上下文模式的方法简化了使用相同的基础设施为新用例训练模型的过程。
六、结语
尽管 ML 系统整合不是灵丹妙药可能并非适用于所有情况但我们相信在许多情况下这种整合可以简化代码允许更快的创新并提高系统的可维护性。我们的经验表明合并对相似目标进行排名的模型会带来许多好处但目前尚不清楚对目标进行排名完全不同且具有非常不同的输入特征的模型是否会从这种合并中受益。在未来的工作中我们计划为何时最适合ML模型整合建立更具体的指导方针。最后NLP 和建议的大型基础模型可能会对 ML 系统设计产生重大影响并可能导致系统级别的更多整合。
