产品ByteByteGo·原文 2026年10月7日本站收录 2026年10月8日

Netflix工程团队构建GenRec:用大语言模型对全目录内容排序

ByteByteGo发布的文章引用Netflix公开分享的细节,称Netflix工程团队构建了GenRec,将开源基础大语言模型用Netflix专有数据适配后,通过两阶段训练和prefill-only推理为电影、剧集等内容打分排序,以替代数千个手工特征。

AI解读:Netflix原有推荐引擎依赖覆盖用户、内容与交互的数千个手工特征,并配有面向不同功能的专用架构;ByteByteGo的文章称该栈仍很复杂,接入新用例成本高。

GenRec的基本思路是用大语言模型理解用户观看历史,并为Netflix目录中的影片和剧集打分;文章明确表示不能直接把通用大语言模型拿来生成推荐,因为它可能偏好全球热门、推荐目录外内容且不支持个性化。

训练分两阶段:先用Netflix专有数据适配开源基础模型,使其获得Netflix内容和用户行为知识,该阶段模型较稳定、更新不频繁;第二阶段即post-training,按奖励信号和成本目标训练模型排序,更新更频繁。

用户交互记录被转成对话格式的样本:user message包含会员历史、上下文、元数据和推荐任务,assistant message描述用户随后做了什么,例如看了下一部剧、看了多久、是否给出反馈;文章称这种对话只是训练格式,用户并不需要与Netflix对话来获取推荐。

Netflix进行context engineering决定提示中放哪些信息,考虑强证据、重复行为、选择性细节和上下文长度;文章称通过清洗、压缩和措辞调整,tokens被减少到大约原来的三分之一。

GenRec用prefill-only推理,单次前向处理提示并直接输出打分,不逐token生成推荐列表;Netflix用vLLM服务该模型,并通过更小或蒸馏模型控制成本。文章提到当上下文长度约减至三分之一时,服务成本也出现相近幅度的下降。

ByteByteGo发布的一篇文章整理Netflix工程团队公开分享的细节,称Netflix构建了名为GenRec的推荐系统,核心思路是用大语言模型理解用户的观看历史,为Netflix目录中的电影和剧集打分并排序。

文章称Netflix原有推荐引擎建立在覆盖用户、内容与交互的数千个手工特征之上,并针对不同功能使用专门架构;这套栈多年演进后仍然复杂,接入新用例成本较高。

Netflix工程团队没有直接选用现成大语言模型,而是先用开源基础模型和Netflix专有数据适配,再针对排序任务做第二阶段训练,最终通过单次前向推理输出目录内内容的分数。

原有推荐栈与GenRec要解决的问题

文章介绍,推荐系统要回答的基本问题是:推荐列表里什么应该排在最前。Netflix上这些内容可以是电影、剧集、游戏等;排序由ranker负责,根据对特定用户和特定场景的合适程度给内容打分,分数越高越靠前。

文章称,ranker需要的信息包括会员交互历史、内容元数据、设备信息、时段、语言或地区。用户注意力有限,可能只看几个标题就做选择,若没找到感兴趣的内容就可能离开平台,因此排序很关键。

Netflix原有生产系统使用数千个特征、表示和专门的模型组件。文章把特征解释为帮助模型做预测的输入信号,例如用户近期看了多少喜剧、上次观看某内容距今多久、完成一部剧的频率。新增内容类型或产品界面时,需要增加特征、调整模型架构、做基础设施工作并跑多项实验。

Netflix工程团队想验证一个广泛有能力的大语言模型能否承担更多这类解释工作:不用工程化那么多独立信号,而是用纯文本描述相关行为和内容,再训练模型去理解。文章称Netflix把这种用文本表达信息的过程称为verbalization。

文章同时列出通用大语言模型直接做推荐的问题:可能偏好全球热门内容、推荐不在目录内的条目,也不支持个性化。因此Netflix没有采用现成大语言模型,而是构建GenRec。

两阶段训练:先用Netflix数据适配,再学排序

文章称Netflix用两个不同目的的阶段训练GenRec。第一阶段让模型熟悉领域,学习和解释Netflix相关信息;第二阶段再针对排序推荐做特定任务训练。

第一阶段从开源基础大语言模型出发,用Netflix专有数据适配,让模型获得Netflix内容和用户行为知识。这个新训练出的模型成为多条工作线的起点,文章称它相当稳定,Netflix只隔一段时间才更新,频率不高。

第二阶段把基础大语言模型变成GenRec,用具体样本和目标训练,目的是按奖励信号正确排序,同时满足成本目标。文章把这一阶段称为post-training,即让已有模型更适合特定工作的额外训练;Netflix更频繁地运行这一阶段,因为新电影和剧集不断上线,观众选择也在变化。

文章称,Netflix记录多种用户交互,包括点击付费、观看时长、点赞或点踩、加入观看列表、放弃观看的会话等。团队把这些记录转成对话样本:user message包含会员历史、上下文、元数据和推荐任务,assistant message描述用户随后执行的动作。例如输入描述一个用户最近看完几集悬疑剧、给出正面反馈、现在晚上看电视;输出描述该用户接下来看的剧、看了多久、是否给出反馈。

文章强调,对话只是便于训练的格式,并不是用户需要和Netflix聊天才能获得推荐。训练时对话格式便于实现语言目标;实际使用时,GenRec接收上下文并根据排序组件给电影和剧集打分。

上下文工程与训练目标

文章称大语言模型按token处理文本,发送的token量会影响成本并占用上下文预算,因此描述用户全部活动历史会很贵,需要决定提示里放什么信息。Netflix把这称为context engineering,在构建上下文时同时考虑某个事件的有用程度和用文字表达它需要多少文本。

文章列出几个考虑因素:强证据,例如长观看会话或明确正面反馈值得详细描述,而很短观看或快速悬停可能只是偶然或随意探索,团队会省略这类事件以避免在弱证据上花token;重复行为,例如用户连续看很多相似剧集,可以压缩成对某部剧的一次长观看会话;选择性细节,例如互动历史很少的新电影类似冷启动,需要更丰富的元数据;上下文长度,团队测试加入更多历史事件如何改变排序质量,起初增加历史帮助很大,之后改善变小。

文章称Netflix调整描述事件用多少词,通过清洗、压缩和措辞调整,报告token减少到大约原来的三分之一。

训练目标方面,主要目标是教GenRec给目录中每部电影或剧集打出更高分。Netflix用长播放时间或强反馈等参与行为识别正样本,并应用阈值和过滤降低标签噪声,因为一次动作并不总是用户偏好的可靠信号,不能把每次短暂播放都视为同等重要;模型若在可选项中对相关目录内容给出的概率过低,也会被惩罚。

文章还提到Netflix保留文本语言建模目标,帮助模型理解用户历史、影片和剧集,并按自然语言指令行动,也就是推荐训练应保留基础模型的语言能力;团队也保留未来文本应用的可能性,例如解释推荐。

另外,Netflix用reward-weighted training避免模型对某些事件赋予过大影响。例如反复追剧会产生多个事件,但不应对其过度加权,否则系统可能过于集中于某类内容。文章称Netflix有单独的奖励模型提供信号,一部分信号指向更长期结果,例如回访行为、探索、持续参与,另一部分帮助平衡不同类型内容、新片发布和其他热门标题。

打分方式、推理与评估

文章称GenRec训练后能把文本描述转成Netflix目录中电影和剧集的分数。首先,一个叫verbalizer的组件把用户观看历史、当前上下文和相关元数据汇成文本;大语言模型处理该文本序列并产生内部数值表示。Netflix还提取pooled hidden state,即适合某次推荐请求的信息的紧凑数值表示。

每个目录内容有学习到的表示和嵌入。打分头连接用户上下文表示与影片或剧集嵌入,生成分数;文章称打分函数可以包括点积或小型神经网络,关键是学习两种表示之间的关系。GenRec用softmax把分数转成分布,非负且在被评分集合上总和为一,并用它排序推荐项。Netflix联合训练主大语言模型、排序头和目录内容嵌入,使它们支持同一任务;由于打分头只给Netflix目录内容打分,它无法推荐目录外内容。

推理方式上,典型文本生成大语言模型分两阶段:先处理输入提示,称为prefill;再逐个生成输出token,称为自回归解码。GenRec使用第一阶段理解推荐上下文,然后从排序头获得分数。Netflix把这称为prefill-only inference:提示只处理一次,模型在一次前向中给目录或候选集打分,不逐token生成答案,因此没有让大语言模型写出推荐列表的成本。

文章称Netflix用vLLM服务GenRec,并通过更小或蒸馏模型控制成本。蒸馏模型是学习较大模型行为的小模型,目标是以更低计算成本获得较高质量结果。Netflix还组织提示以最大化共享前缀,方便前缀缓存;文章提到在其实验中,上下文长度大约减至三分之一时,服务成本也出现相近幅度下降。

评估方面,来源摘要称Netflix工程团队同时使用离线评估和线上A/B测试。文章没有在提供的片段中给出评估结果数据。

信息来源

ByteByteGo原始来源