使用开源框架构建持久代理（赞助内容）
大多数 AI 代理在演示环境中运行良好，但在生产环境中却会失败。了解如何使用 Orkes Agentspan 和 Conductor 等开源框架构建持久耐用、企业级的 AI 代理。本白皮书探讨了如何通过内置的治理、可观测性、重试机制和人工审批，来编排长时间运行且具有容错能力的代理工作流。了解 Agentspan 与 LangGraph、CrewAI 和 AutoGen 在实际企业级 AI 系统中的比较。如果您正在构建需要可靠性、可扩展性和可控性的 AI 工作流，本指南将展示实现生产级代理所需的架构模式。
Netflix 一季剧集就能产生超过 2000 小时的原始素材，相当于 2.16 亿帧。
当电影剪辑师需要找到某个角色在特定地点说出特定台词的确切时刻时，他们面临的是软件工程中最棘手的搜索难题之一。而解决方案与构建更优秀的AI模型关系不大，这着实令人惊讶。真正的挑战在于底层架构。
Netflix 的剪辑团队过去常常要花费数天时间，从浩如烟海的原始素材中寻找特定的精彩片段。例如，一位导演可能需要某个角色在特定场景中的所有镜头；一个市场营销团队可能想要整个系列中最具视觉冲击力的五个动作场景。找到这些片段意味着要花费数小时手动筛选数千小时的素材。在这种情况下，创作动力就会停滞不前。
解决这个问题的团队构建了一个从表面上看很简单的东西，就是一个搜索栏。但它的底层却是一个三层管道，它协调一系列人工智能模型，将它们的输出在共享的时间线上融合，并以亚秒级的延迟处理混合文本和向量查询。
当多个AI模型处理同一段视频素材时，原本2.16亿帧的基准数据会爆炸式增长到数十亿个多层数据点。存储、对齐和交叉处理如此庞大的数据量，同时还要保持亚秒级的查询性能，这远远超出了任何传统数据库的单独处理能力。
在本文中，我们将了解 Netflix 如何构建这套系统以及它面临的挑战。
免责声明：本文基于 Netflix 工程团队公开分享的信息。如果您发现任何不准确之处，请留言。
为什么需要多种模型
为什么 Netflix 要对同一段视频素材运行多个 AI 模型，而不是依赖一个功能强大的模型来完成所有操作？
这是因为专门的模型在特定任务上始终优于通用模型。专门训练用于人脸识别的模型比通用视觉模型更能准确地识别人物；针对场景分类调整的模型能够更精确地映射环境；对话转录模型能够更可靠地捕捉语音。
因此，Netflix 运行着一个由多个专业模型组成的团队。例如，一个模型负责识别角色，另一个负责对场景和环境进行分类，第三个负责转录对话，第四个负责检测物体。每个模型都擅长各自的工作，但它们各自产生的输出结果也截然不同。
例如，字符识别模型可能会输出类似“Joey”这样的文本标签。相比之下，场景分类模型会生成一个512维的向量嵌入，它本质上是一个数字列表，以机器可以比较的方式表示场景的数学“含义”。另一方面，对话模型输出带有时间戳的文本记录。这些是完全不同的数据类型，需要不同的查询策略。
请看下图：
格式问题只是挑战的一半。每个模型还会将视频分割成不同的、相互重叠的时间段。例如，角色模型可能会在第 2 秒到第 8 秒之间检测到“Joey”，而场景模型可能会在第 4 秒到第 9 秒之间检测到“厨房”。这些模型之间没有共享的时间线。虽然时间段相互重叠，但它们并不对齐。
所以仔细想想，工程团队必须解决一个核心挑战。
如何将所有这些以不同时间分辨率、不同格式生成的不同输出合并到一个可搜索的索引中？
Netflix 也在探索一种截然不同的方法来解决这个问题，他们使用名为 MediaFM 的统一基础模型来同时处理音频、视频和文本。未来究竟是倾向于专业化的集成模型还是统一的通用模型，在多模态人工智能领域仍然是一个悬而未决的问题。但就目前而言，生产系统依赖于一个三阶段的流水线，分别处理每个方面。
三阶段管道
从原始模型输出到可搜索情报的过渡遵循一个解耦的三阶段过程。
每个阶段只处理一个问题，而且仅此而已。这种分离是整个系统的架构支柱，其存在的原因在于，在 Netflix 这样的规模下，任何两个阶段的耦合都会造成瓶颈。
第一阶段：事务持久化
所有模型的原始标注数据都会被采集并存储在 Apache Cassandra 中，这是一个针对高速写入吞吐量优化的分布式数据库。此阶段严格把控数据完整性。模型输出的每一条数据都会被安全地捕获，不做任何转换。系统会按照模型生成时的原样存储数据。
为什么要将这一阶段与之后的所有内容分开？
这是因为如果系统在数据摄取过程中尝试处理或融合数据，繁重的计算会降低实时摄取的速度。解耦确保无论运行多少模型或产生多少数据，摄取层都能保持响应速度。
第二阶段：离线数据融合
原始数据安全持久化后，事件会触发异步处理任务。这个离线融合层是系统的架构核心。它负责实时路径之外的繁重计算工作，因此复杂的数据交汇不会干扰正在进行的数据摄取。
这里的关键技术是时间分桶。
请看下图：
该流程通过将所有模型输出映射到固定的一秒时间间隔内，来对其进行归一化处理。此过程分为三个步骤：
-
首先是分桶映射。连续的检测结果会被分割成离散的1秒间隔。如果角色模型在第2秒到第8秒检测到“Joey”，则流程会将这段连续时间映射到7个不同的1秒桶中。
-
其次是标注交叉。当多个模型对同一秒的视频片段生成标注时，系统会将它们合并成一条完整的记录。例如，如果“Joey”和“厨房”都出现在第4秒到第5秒的视频片段中，它们就会合并成一条记录，表明“在这一秒的视频片段中，Joey在厨房里”。
-
第三点是优化持久化。这些经过丰富和融合的记录会作为独立的实体写回 Cassandra。最终形成一个逐秒更新的多模态交叉索引，将每个融合的标注与其源视频资源精确关联起来。
一个重要的细节使得这个过程是渐进式的。
该管道使用 upsert 操作，这意味着如果找到现有记录，它将更新现有记录；如果找不到现有记录，它将插入新记录。管道使用复合键，将资产 ID 和时间段组合起来作为唯一标识符。
如果某个特定秒的视频片段已存在时间桶（可能是由之前的模型运行填充的），系统会更新现有记录，而不是创建重复记录。这为每一秒的视频素材建立了一个单一的真实数据源，也意味着系统能够优雅地处理随着时间推移而添加的新模型。
一秒钟的桶大小本身就是一个有意义的设计决策。
更小的存储桶意味着更高的时间精度，但同时也意味着更多的记录。以秒为分辨率，一个 2000 小时的存档会产生 720 万个存储桶，每个存储桶可能包含来自多个模型的多个标注。Netflix 选择秒作为分辨率，是为了在精度和可管理性之间取得平衡。
第三阶段：实时搜索索引
一旦丰富的临时存储桶被持久化，后续事件就会触发它们被摄入到 Elasticsearch（系统的查询引擎）中。
每个时间桶都以嵌套文档的形式构建：
-
父级捕获总体资产上下文，包括资产 ID、电影 ID 和时间间隔。
-
子文档中包含特定的多模态标注，例如角色数据、场景嵌入和对话文本。这种层级结构使得跨标注查询成为可能。
当用户搜索“厨房里的乔伊”时，Elasticsearch 可以在单个查询中将同一个父存储桶中的角色注释和场景注释进行匹配。
两种搜索方式，却得到一个结果
有了融合索引的时间线，系统就可以向用户实际看到的部分开放了。
当收到查询时，系统在操作索引之前会运行一个三步预处理阶段。
-
查询类型检测会动态地对请求进行分类，以便将其路由到最有效的检索路径。
-
过滤器提取过程会提取语义约束（例如角色名称或环境上下文）来缩小候选对象范围，然后再开始耗时的计算。
-
最后，向量变换将原始文本查询转换为高维的、特定于模型的嵌入，以进行语义匹配。
然后，系统将此结构化计划编译成优化的 Elasticsearch 查询，并针对预先融合的时间桶执行该查询。
混合搜索
像“厨房里的乔伊”这样的查询需要两种截然不同的匹配方式。
“Joey”是一个专有名词，需要精确的关键词匹配。“Kitchen”是一个语义概念，可以采用向量相似度搜索，系统会比较查询嵌入和索引中存储的场景嵌入之间的数学距离。
仅使用关键词搜索会遗漏带有相关术语的场景。同样，仅使用向量搜索也难以处理专有名词和精确短语。将两者结合起来称为混合搜索，其性能始终优于单独使用任何一种方法。
Netflix 为用户提供了对这种混合引擎的精细控制。
它们可以在精确的 k 近邻搜索和近似最近邻算法之间切换。精确的 k 近邻搜索可以保证数学上最接近的匹配，但计算成本很高；近似最近邻算法则牺牲少量的准确性，以换取在大规模数据集上显著更快的结果。
他们可以选择余弦相似度或欧氏距离等距离度量方法，因为不同的模型对向量空间的划分方式不同，“接近”的定义也取决于模型的训练方式。他们还可以设置置信度阈值，即最低分数线，以过滤掉低概率匹配项，确保创意团队只审查符合高相关性标准的结果。
对话搜索和文本分析
对于涉及特定语音的搜索，该系统采用分层文本分析策略。
短语匹配功能带有一个可配置的“误差范围”参数，该参数控制搜索词之间可以相隔多少个单词才算匹配，从而能够应对人类记忆的不完美。例如，如果用户搜索《怪奇物语》中的一句台词，但对原文的记忆略有偏差，系统仍然能够找到正确的场景。
通过在输入时对部分单词片段进行索引，实现了边输入边搜索功能，可以在编辑人员开始输入的瞬间提供帧精确的搜索结果。
跨多种语言的词干提取确保“running”与标记为“run”或“ran”的场景相匹配，将语法差异简化为单一的搜索意图。模糊匹配能够容忍字符级别的拼写错误和笔误，从而弥补转录错误，确保不会因细微的数据缺陷而丢失任何有价值的镜头。
整理结果
原始搜索结果需要经过后处理才能使用。
该系统采用自定义聚合方式对输出结果进行聚类，例如，筛选出每集演员最相关的 5 个片段。这可以防止任何单一素材主导结果，并避免因查看数百帧几乎相同的画面而造成的疲劳。时间重建层会将内部的素材边界转换回自然的场景边界，从而使编辑人员能够看到连贯的场景级结果，而不是任意的一秒片段。
该系统还根据查询意图提供两种结果模式。“联合模式”返回所有匹配标注的完整范围，优先考虑覆盖面，并捕获指定特征出现的任何实例。“交集模式”仅返回所有条件同时出现的精确重叠时间段，优先考虑精确度。用户可自行选择使用哪种模式。
这种架构的成本是多少？
Netflix 的每一个建筑设计选择都伴随着权衡取舍，团队会慎重考虑他们愿意付出哪些代价。
离线融合意味着新内容需要经过一段时间才能在所有平台上完全可搜索。Netflix 选择提高吞吐量而非实时更新，因为另一种方案（即在内容摄取过程中融合数据）会成为整个流程的瓶颈。
对于一个以数千小时为单位增长的制作存档来说，这种权衡是合理的。然而，对于一个需要即时搜索功能的系统来说，这却是一个错误的选择。
精确最近邻搜索和近似最近邻搜索之间的切换，直接体现了精度与速度之间的权衡。精确的 k-NN 算法能够保证找到数学上最优的匹配结果，但大规模应用时计算成本会非常高。近似方法速度更快，但可能会遗漏一些相关的结果。Netflix 将这种权衡呈现给用户，而不是让用户自行选择。
而这种整体方法本身就是一种赌博。
通过三阶段流程运行多个专用模型并融合其输出，可以产生出色的单项任务准确率，但这需要相当大的基础设施复杂性。
单一的统一模型可以简化架构，但可能会降低特定任务的准确性。Netflix 同时投资于集成管道和 MediaFM 基础模型这两种方法，表明这种权衡取舍仍未最终确定。
结论
Netflix 工程团队目前实施的系统只是其宏伟蓝图的第一阶段。其中有三个规划中的演进方向：
-
首先是自然语言发现。系统目前接受结构化查询有效载荷，但目标是实现流畅的对话式界面，让编辑人员可以输入类似“查找汤姆·霍兰德在屋顶奔跑的最佳跟踪镜头”这样的语句，而无需理解底层查询结构即可获得结果。
-
其次是自适应排名。通过构建机器学习反馈回路，分析编辑团队如何与视频片段互动并选择它们，系统可以逐步自我调整其相关性的数学定义。搜索引擎会随着时间的推移而不断改进，从实际使用模式中学习，而不是依赖静态的评分算法。
-
第三点是领域特定个性化。剪辑高冲击力营销预告片的团队与剪辑叙事场景或进行深度档案研究的团队，其相关性标准截然不同。系统会动态调整搜索权重和检索行为，以匹配用户的上下文。
这些扩展指向一个更宏大的目标，即从搜索引擎发展成为智能创意伙伴。
然而，目前的系统已经给我们带来了宝贵的建筑学启示。
当多个AI模型针对同一底层实体生成不同类型的数据时，最难的工程设计在于融合层。模型本身固然重要，但真正让整个系统运转起来的是用于持久化、对齐和索引模型输出的管道。
参考：
原文： https://blog.bytebytego.com/p/how-netflix-is-using-multimodal-ai