** 编者按：**Netflix 探索了许多通过机器学习提升视频生产效率的方式，比如对话搜索和视频搜索。但由于不同项目均独立开发，维护成本巨大。目前，Netflix 正在着手解决这一问题。本文来自 Netflix 科技博客。

文 / Guru Tahasildar, Amir Ziai, Jonathan Solórzano-Hamilton, Kelli Griggs, Vi Iyengar

译 / 核子可乐

原文

https://netflixtechblog.com/building-a-media-understanding-platform-for-ml-innovations-9bef9962dcb7

摘要

Netflix 坚持利用机器学习为我们的会员打造最佳媒体体验。此前，我们曾分享过其中一种算法的实现细节，介绍了我们的平台团队如何开发出与媒体相契合的机器学习生态系统，也讨论了如何将这些算法中的数据存储在我们的注释服务当中。

当前，很多机器学习文献都偏重于模型训练、评估和评分等。而在本文中，我们将探讨机器学习生命周期中一个尚未被充分研究的角度：将模型输出整合至应用程序当中。‍

使用机器学习技术在《怪奇物语》中查找主角 Eleven 的镜头，并将结果导入工作室软件以供 Netflix 做视频编辑。

具体来说，我们将深入研究如何为 Netflix 的工作室软件建立搜索功能架构。我们将探讨使用机器学习算法解决的具体问题，回顾期间困扰 Netflix 的不同痛点，并概括介绍我们这套新平台的技术实现。

概述

在 Netflix，我们一直在努力为会员提供更优质的内容、提升他们的观看满意度。这种愉悦的体验需要分两部分实现：其一，我们需要制作出会员喜爱的节目内容；其二，我们需要让会员能轻松直观地从媒体库中挑选出适合自己的内容。也就是说，以图像和视频形式快速呈现节目亮点，已经成为 Netflix 会员体验中的重要一环。

当然，这类多媒体 “补充性” 资产不可能凭空出现，而是出自艺术家和视频剪辑师之手。我们开发出创作工具，让这些同事能够集中时间和精力发挥自己的创造力。但很遗憾，他们的大部分精力还是被浪费在了繁琐的准备工作上，于是新的自动化任务就此被摆上议程。

用例汇总

用例一：对话搜索

对话是故事讲述中的核心手段。讲述一段引人入胜故事的最佳方式，往往就是通过角色的口述。那些铿锵有力、令人难忘的台词，也是预告片剪辑师们最需要的素材来源。之前查找这类内容只能采取手动方式，效率之低下可想而知。

剪辑师需要从头到尾观看视频内容，使用时间码转录那些精彩的台词瞬间，并在引用时据此进行检索。而且虽然有确切的时间记录在，但剪辑师在实际操作中可能忘记当时的具体情境，因此经常需要反复重新观看。有些剪辑师干脆把整段内容全部转录下来。用我们一位同事的话来说：

这种画面监视 / 拆分工作非常枯燥，不知浪费掉了多少创作时间！

确实，翻阅几个小时的画面（如果是连续剧，长度可能达到几十小时）来查找某一句台词无疑让人心烦。有时候，剪辑师还需要搜索多部作品，意味着几乎不可能靠手动查找来完成。那么，我们该如何淘汰掉这种落后的翻阅和转录流程？

在理想情况下，我们希望实现以下几种对话搜索功能：

• 按节目标题、标题子集（例如所有剧集）或者完整目录进行搜索；

• 按角色或演员进行搜索；

• 多语种搜索。

用例二：视觉搜索

正所谓 “一图胜千言”，视觉叙事能帮助观众理解复杂的故事，也能以更富感染力的方式传递信息。

艺术家和视频剪辑师往往需要为艺术作品和预告片查找特定的视觉元素。他们可能要翻阅关于特定角色、位置、对象、事件（例如动作片中的追车场景）或属性（例如特定镜头）的帧、画面或场景。如果能让他们使用自然语言查找视觉元素，结果将会如何？

下图所示，为用户在内容库中搜索 “红色赛车” 时输出的结果。

用户搜索 “红色赛车”

用例三：按画面反向搜索

自然语言视觉搜索的确为剪辑师们提供了强大的工具。但如果他们在脑海里已经构建起切片逻辑，现在需要找几个内容相似的画面，该如何操作？例如，假定剪辑师看中了《主厨的餐桌》中一帧效果惊艳的食物画面，接下来要怎样找出剧集中的全部相似素材？

用户提交查询画面，据此找出其他相似画面。

工程方法

方法一：按需做批处理

我们实现创新的第一种方法，就是使用一款工具实现对算法的按需、按节目触发。我们建立一套批处理系统，可供用户提交请求并等待系统生成输出。处理一般需要几个小时才能完成，毕竟很多机器学习算法都需要消耗大量算力，提交的样本中也有大量画面帧有待处理。一般来说，长度为 1 小时的视频中往往包含超过 8 万帧！

处理完成后，用户下载由算法生成的输出以供离线使用。这套规模受控的试点系统，大大减少了用户手动分析内容所花费的时间。下图所示，为整个流程的可视化形式：

按需批处理系统流程图

方法二：通过预计算实现在线请求

在试水阶段取得成功之后，我们决定为几种算法添加在线支持。这也是用户第一次能够在整个目录中发现匹配项，查找那些他们不熟悉、甚至不知道其存在的精彩内容。无需任何本地设置、没有延迟，所有数据都已预计算完毕并等待使用。

具有预计算数据流的交互式系统

我们的用户也对这套系统的上线赞不绝口：

“我们想在一部剧集中找到所有跟餐厅有关的画面。几秒钟后，我们就完成了这项以往需要一、两个人花费一整天才能搞定的工作。全部 10 集中所有的餐厅画面就这样呈现在眼前，太棒了！”

Dawn Chenette，设计主管

这种方法给产品工程带来了一系列助益，让我们能够在不影响用户体验的情况下透明更新算法数据，还能梳理出哪些查询模式和算法洞见对用户更有吸引力。另外，我们也得以执行 A/B 测试，借此验证或否定在调整搜索体验时做出的假设。

主要痛点

我们的早期尝试，确实让创意工作者们感受到了机器学习的巨大价值。与此同时，我们也遭遇到越来越多的工作难题，导致无法继续推进扩展。

首要挑战，就是如何维护多种不同系统。这些系统当初是由不同团队在不同的技术栈之上构建而成，因此维护成本很高。每当机器学习研究人员开发出一种新算法时，都需要将其单独整合至各个系统当中。事实证明，区区两套系统加少量算法，就足以让运维团队满负荷运转。我们知道，随着将机器学习技术扩展至更多用例和研究人员，这种情况只会变得更糟。

在线应用程序虽然为我们的用户带来了前所未有的交互性，也证明我们的探索方向是正确的，但其扩展性着实太差。新算法和新用例的添加仍然非常耗时，需要工程师们付出大量努力。这种 “一事一议” 的整合成本不够稳定，实施时间也在几周到几个月之间剧烈波动。另外，由于实施方式的限制，我们也无法对所有可用机器学习源进行全目录范围的搜索。

总而言之，这套模型属于应用程序到数据的紧密耦合架构，其中机器学习算法与后端、UI/UX 软件代码堆栈混合在一起。为了解决实施时间难以预测的问题，我们需要对不同算法的集成方式做标准化改造 —— 包括具体执行方式，保证数据被始终如一地交付给所有使用者。后续我们还将开发出更多能够理解媒体内容的算法并扩展至更多用例，所以现在必须投资以重新设计系统架构，确保来自不同团队的研究人员和工程师都能或独立、或协同地开展创新工作。基于这些需求，媒体搜索平台（MSP）倡议就此诞生。

虽然我们刚刚开始进军媒体搜索领域，但搜索本身对 Netflix 来说并不陌生。我们拥有面向无数订阅用户的搜索和推荐功能，已经具备成熟而强大的使用体验和表现。我们知道，同事们在这里探索出的经验教训将成为指导媒体搜索平台建设的宝贵指导。为了跟我们 “高度一致、松散耦合” 的企业文化保持一致，我们希望工程师能够快速、独立地参与到算法设计和改进当中，同时让工作室和产品应用都能轻松与媒体理解算法相对接。

能否实现平台的模块化、可插拔和可配置性，成为决定成败的关键。通过这种方式，我们能够保留平台的分布式所有权特性，为不同的专业团队提供不同的平台贡献组件。为此，我们从其他用例中提取出现成服务，在进行功能扩展之后用于支持新的需求。

接下来，我们将具体探讨系统架构，了解不同模块之间如何交互、共同实现端到端流程。

系统架构

系统架构

Netflix 的工程师们一直努力迭代，希望以 “MVP”（最小可行产品）方法尽快获得早期反馈，最大限度减少前期投资成本。因此，我们没有完全构建所有模块，只是明确划分了试点实施的范围，确保能让最紧要的功能运行起来。同时，我们还充分保证了设计开放性，为未来的扩展留足空间。下面，我们就重点介绍其中几个组件示例。

接口 ——API 与查询

从架构最顶端开始，我们的平台可以通过 gRPC 或 GraphQL 接口与应用程序交互。接口的多样性能够更好地满足应用程序开发者的实际需求。在 Netflix，gRPC 主要用于后端到后端通信。借助我们开发者生产力团队提供的活跃 GraphQL 工具，GraphQL 已经成为 UI 到后端集成的首选方案。我们也一直在项目当中使用域图服务框架。

在查询 schema 的设计过程中，我们考虑到未来的潜在用例，确保它能够支持后续扩展。我们的目标是让 schema 足够通用，以便隐藏实际搜索系统的具体查询执行细节。另外，它还要直观易懂且功能丰富，可用于表达复杂的查询。用户可以灵活执行多模态搜索，包括输入简单的文本表达、图像或短视频。如前所述，搜索既可针对 Netflix 的整个目录执行，也可以仅限于特定标题。用户可能更倾向于以特定方式组织结果，例如按影片分组、按时间戳排序等。当存在大量匹配项时，我们允许用户对结果进行分页（页面大小可调），而不是必须获取全部或固定数量的结果。

搜索网关

客户端生成的输入查询，会首先被交付至查询处理系统。由于我们的大多数用户执行的都是针对性查询，例如搜索对话 “别对朋友说谎”，目前的登台系统会执行轻量化处理，并提供 hook 以集成 A/B 测试。未来，我们计划将其发展成一套 “查询理解系统”，可支持更自由的搜索形式，能够减轻用户负担并简化客户端查询的生成过程。

查询处理系统会修改查询以匹配目标数据集，包括 “嵌入” 转换和翻译。对于指向基于嵌入的数据源的查询，该系统会将文本或图像等输入转换成相应的向量表示。每个数据源或算法都可以使用不同的编码技术，由登台系统确保相应的编码适用于所提交的查询。我们之所以要求不同算法使用不同的编码技术，是为了实现对单帧图像和由多帧画面组成的视频实现不同的处理。

随着全球业务扩张，我们也开始面对母语不是英语的用户群体。平台上的所有文本模型均使用英语进行训练，因此需要将其他语种的文本翻译成英语。虽然翻译结果并不完美，但在我们用例中的效果仍然良好，也让我们的工具能够为更多非英语用户服务。

在查询转换完毕并做好执行准备后，我们会将搜索执行委托给一个或多个搜索器系统。首先，我们需要统筹将哪条查询路由至哪个系统，这部分工作由查询路由器和搜索器代理模块负责。在初始实施中，我们使用单一搜索器来执行所有查询。但通过后续可扩展方法，该平台已经能够支持更多搜索器，并利用这些搜索器开发出新的算法和实验原型。

搜索可能会交叉或聚合来自多种算法的数据，因此当前抽象层需要将单个查询分散到多条搜索执行当中。我们在这一层内为各个受支持搜索器实现了 “搜索器代理”，各代理负责将输入查询映射到符合搜索者期望的查询结果处。之后，代理会处理来自搜索器的原始响应，再将结果交给后处理器组件。

结果后处理器负责处理一个或多个由搜索器返回的结果，可以通过自定义评分对结果进行排名，再根据其他类似搜索对搜索建议做出补充。另外，我们还在评估该层中的另一项功能，使用相同的底层数据动态创建出不同的视图。

为了便于协调和维护，我们将查询处理和响应处理抽象在同一个名为 Search Gateway 搜索网关的模块当中。

搜索器

前面提到，查询执行由搜索器系统负责处理。当前实施中使用的主搜索器名为 Marken，是 Netflix 构建的可扩展注释服务。它能支持多种不同搜索类型，包括全文和基于嵌入向量的相似性搜索，还可以存储和检索时间（时间戳）及空间（坐标）数据。该服务的数据存储和检索利用 Cassandra 和 Elasticsearch 实现。在加载嵌入矢量数据时，我们还进行了广泛的基准测试来评估可用的数据存储。这里需要强调一点，虽然我们已经建立起专用于特定查询模式的数据存储，但最后出于可维护性和一致性的考虑并没有实际引入。

我们还确定了一些常见的 schema 类型，并对来自不同算法的数据做了存储方式标准化。各算法仍可以灵活地对 schema 类型做自定义。我们正在这方面积极创新，最近又添加了对不同算法的数据进行交叉的能力，有望让来自多种算法的数据相互叠加、以创造性的方式快速获取所需结果。

算法执行和摄取

以上内容主要探讨的是如何查询数据。我们的系统中还有另外一种同样复杂的机制，用于为算法执行和数据生成提供支持。这项工作由我们的媒体机器学习平台团队担纲，他们专门构建了一套特定于媒体的机器学习工具。除了以媒体为中心的特征存储和计算编排之外，它还能协助对媒体资产（例如音频、视频、图像和文本等）进行无缝访问。

在这个项目中，我们还开发出一个自定义接收器，能够根据预先定义的 schema 将生成的数据索引至 Marken 当中。但首次回填数据时要特别小心，避免系统因大量写入而不堪重负。

最后同样重要的是，我们的 UI 团队构建了一个可配置、可扩展的库，用以简化该平台与最终用户应用程序间的集成过程。在这套可配置 UI 的帮助下，各应用程序和算法能够轻松根据实际需求对查询生成和响应处理做定制化调整。我们未来将继续构建更多本机小部件，进一步简化 UI 操作。

总结

我们这套能够理解媒体内容的平台，相当于机器学习算法与各种应用程序和功能之间的一种抽象层。这套平台已经让我们在多种应用程序中无缝引入了搜索和发现功能。相信未来随着各方面成果的发展成熟，将帮助更多用例和应用程序释放价值。希望这篇文章能帮助大家了解我们如何推动架构革新，后续我们也将继续分享相关工作的动态和进展，敬请期待。