多模态大模型通过Embedding、信息融合与任务学习处理多源数据。Stable Diffusion利用CLIP和UNet实现文本到图像生成，Sora扩展到视频领域，加入时空切块和一致性模块保证连贯性。大模型赋能推荐系统实现个性化内容生成，如GeneRec和PMG。工程实践中需关注模型瘦身、流式训练及多层级评估体系，平衡效率与正确性。

多模态大模型的基本原理

多模态大模型的整体架构，与纯文本大模型没本质区别，都要经原始数据的 Embedding、信息融合与目标任务学习及微调等过程。

5阶段模型训练：

（1） 理解数据并将其 Embedding化。

（2）多模态 Embedding 对齐。

（3）多模态信息交互与融合。

（4）多任务学习。

（5）多模态微调。

Stable Diffusion（稳定扩散模型）

（1）文本编码器：负责把输入的 Prompt 映射到 Embedding 空间。

（2）图像信息生成器：负责在 Embedding 空间把文本 Embedding 转换成包含这些文本信息的图像 Embedding。

（3）图像解码器：利用生成的图像 Embedding 绘制出最终的图像。

负责文本编码的模型，为 CLIP。

为把原始文本 Prompt，编码成适用于图像生成的Embedding，研究人员使用了4亿张图像及其对应的Prompt，来预训练CLIP。

为表达图像和解释文字的相似性，CLIP 用了一个类似双塔的结构。

图像塔是一个图像编码器，负责生成图像Embedding；文本塔是一个文本编码器，负责生成文本Embedding。

对应的图像和解释文字的Embedding 越相近时，模型的Loss 越小；反之，模型的Loss 越大。

训练完毕，文本编码器部分被取出，并应用于 Stable Diffusion。这样训练出来的文本编码器，擅长的就是由文本生成图像 Embedding 的任务。

CLIP 生成的Embedding 相当于输入的 Prompt 在隐向量空间的表达。

如何由这个表达，生成最终图像呢？

由一张随机噪声图像扩散（diffusion）而来，这也是 StableDiffusion 名字的由来。

最终图像是由 UNet 网络经过50步扩散而生成。

UNet 网络如何按 Prompt Bmbedding 的意图生成图像？

在每个 ResNet 层之后，Prompt Embedding 都会通过 Attention 机制接入网络，参与图像 Embedding 的生成，从而一步步“监督”图像按Prompt 的意图细化。

UNet 的训练也值得一提。

为得到足够训练样本，在Prompt 和图像的配对样本的基础上，将随机噪声逐步加入配对样本中的图像中。

比如噪声分为等级0~10，0表示原始图像，10则表示完全是随机噪声，逐步加入噪声后，得到了11张不同噪声级别的图像。

训练中，随机选取一组图像用于 UNet 训练，就可得到大量训练样本序列。

Stable Diffusion 最后一个模块，是图像解码器，负责把图像信息生成器生成的包含了图像语义和细节信息的Embedding，“翻译”为人可视的图像。

这里用了Autoencoder 的解码器部分，通常由多个反卷积层（Deconvolutional Layer）或上采样层（Upsampling Layer）结合卷积层（Convolutional Layer）组成，逐步把语义 Embedding 转换成“真实的”图像。

训练中，图像解码器需与图像信息生成器（UNet）网络一同训练。

因为训练样本是添加了噪声的图像，不是添加了噪声的 Embedding，所以仍需图像解码器的参与，才能完成整个训练过程。

但文本编码器（CLIP）是可以预训练的，因为 CLIP 使用的训练样本与 UNet使用的完全不同，所以 CLIP 会经过预训练再接入 UNet，参与 UNet 和图像解码器的训练。

相比文本到图像的多模态大模型，视频大模型多了个维度，就是时间。

视频大模型也生成系列图像，但这些图像间须满足物理定律的约束，具备连贯性和一致性。

模型训练和生成视频时，Sora 会把视频每帧处理成小的视频块（Patch），不同帧之间的对应视频块，在时间轴上会形成一个时间序列。

每个视频块在时间轴上的连贯性和一致性，是由视频在隐向量空间中的表征一致性决定的。

每一帧的 Embedding 在隐空间中完成了演进，并生成一系列具有连贯性的 Embedding表达。

这一过程，像极了文本生成中，基于当前 token 序列预测下一个 token 的过程，只不过在视频生成中，token 变成了视频块。

既然 Transformer 这样的模型结构，善于捕捉文本token 前后之间的关系，自然也可扩展为理解视频块之间前后关系的模型。

Sora生成视频，先通过 Transformer 模型生成连续视频帧的隐空间表征，然后利用 Stable Diffusion 模型，将连续的Embedding 逐帧转换成图像，从而生成预期视频。

Lehigh 大学和微软人员曾对其技术架构进行逆向解析，新浪微博首席科学家张俊林也对Sora使用的技术进行了分析。

结合二者的分析，给出 Sora 可信度较高的模型架构。

Sora 的技术轮廓

用户给出相对较短且描述粗略的 Prompt 后，Sora先用GPT 对用户 Prompt 扩写，扩充包含细节描述的长 Prompt。

这步 Prompt扩写很重要，Prompt对细节描述得越明确，视频生成质量越好。

让GPT 加入细节描述，体现了“在尽可能多的生产环节让大模型辅助或取代人”的思路。

Sora 内部有文本编码器（Text Encoder），它把长 Prompt 对应的文字描述转化成每个 token对应的Embedding，这意味着，将文字描述从文本空间转换为隐空间参数。

而这个文本编码器，大概率是CLIP 模型对应的“文本编码器”，因为 OpenAI的DALL-E 系列模型里的文本编码器，用的就是它。

根据 Stable Diffusion 的原理，最终生成的图像，是由随机噪声扩散出的。

因此，Sora 另一个关键输入是，确定了分辨率和帧数的随机噪声图片序列。

在该序列基础上，视频生成模型逐帧生成图像，最终连续起来成为 Sora生成的视频。

Sora 的模型架构中，最重要也是最不易理解的，是“视频生成器”。

它与 Stable Diftusion架构高度相似，都由视觉编码器、Transformer 扩散模型、视频解码器组成。

不同的是，Sora 要处理视频，它加入了一个“空间时间隐向量切块（Spacetime Latent Pateh）模块”（“切块模块”），来处理多帧视频，以及一个“长时间一致性模块”（“一致性模块”），来保证视频中各帧的一致性。

切块模块的主要作用是，降低视频的维度，进而减少后续模型处理的数据量，同时适配Transformer 所需的数据格式。

按Sora官方介绍，该模块先把原始视频帧切块，每块进行 sum pooling或average pooling，生成一维度小得多的二维Embedding。

Transformer 只接受一维 Embedding 数据，还需把这个二维 Embedding 线性化，比如直接展平成一维Embedding，或通过MLP 映射成一维Embedding。

可把切块模块，当作原始视频帧数据到 Transformer 所需数据的转换器。

一致性模块，是视频生成模型特有的模块，否则生成的视频各帧之间，不具备连贯性和逻辑联系。

保证各帧一致性的方法是，在生成下一帧时，建立该帧和之前已生成帧的联系。

一种是全范围注意力方法：建立从当前帧到之前所有帧的交互关系，这比较“暴力”，计算量过大。

二是轻巧一些的分层注意力方法：先生成前几帧，生成后面帧时不要顺序生成，而是生成关键帧。关键帧与之前帧，也不是逐帧连接的，而是隔几帧挑选一帧进行连接。

这保证了整个视频的全局一致性，而且计算过程较高效。生成关键帧后再逐渐补充剩余帧。

推荐系统的使命是，帮用户发现感兴趣的信息和内容。而大模型强大的内容生成能力，使个性化内容生成，成为可能。

大模型有可能越过“推荐”环节，直接用户创造一个新世界，这才是大模型可能为推荐系统带来的最大革命。

MoRec、GBNRE 等方案，让推荐系统通过大模型学到更多“世界知识”，更好地理解这个世界；

PALR、UniLLMRec，则通过大模型构造了全新的推荐系统，让大模型成为这个推荐系统的世界本身。

AI 辅助内容生成对推荐系统的意义

（1）大幅提升创作效率，增加内容更新频率。

（2）高效转换、生成大量内容，丰富推荐系统的候选集。

（3）生成新内容，提升内容多样性和新鲜度。

视频创作工具Capeut的AI化

（1）图像与视频上色。

图像上色模型，将彩色与黑白图像对作训练集，训练一个上色模型，将黑白空间映射到彩色空间，初步上色。

再利用预训练的 Stable Diflusion 模型，继续对彩色图像精修，生成彩色图像。

（2）AI 加字幕。

将视频中的音频转成字幕，利用了大模型从音频到文本的多模态转换能力，提升了效率。

（3）基于文字脚本生成视频内容。

这利用了大模型从文本到视频的多模态转换能力。

新加坡国立大学，提出下一代生成式推荐系统的框架GeneRec。

传统推荐系统的内容生成：

人类创作内容，上传到推荐系统的候选物品集中，推荐系统根据推荐模型的选择，从候选物品集中挑选合适的内容，展现给用户。用户产生反馈后，反馈信息被返回给推荐系统，促使推荐模型持续优化。

GeneRec，比传统推荐系统多了个AI 创作者（AI Generator）：

它根据用户需求生成新内容，创作的内容可直接进入候选物品集，供推荐系统选择，也可直接返给用户，给用户最直接快速的响应。

例：有一类短视频是，截取并整合长视频的片段，来满足用户“快餐式”的观看需求。

对这类需求，根据用户的行为历史来推断用户兴趣，再根据用户兴趣，截取和整合视频，就是GeneRec 一个很好的应用场景。

比如5号用户的历史行为是，看了些风景、宠物的视频。

把这些信息输入给AI创作者，它通过大模型理解用户意图和长视频中每一帧内容，从中截取出自然风景相关的短视频，推送给用户。

100号用户喜看汽车和美女视频，AI 创作者就截取了汽车相关的片段推送给他。

在服装商品推荐场景中，商品展示图中服装的搭配、颜色、模特的姿势和风格，都可直接影响用户的购买决策。

借GeneRec 框架，可把用户历史行为描述，以 Prompt的方式，输入给AI 创作者大模型，从而针对性地生成更能吸引用户的商品缩略图。

推荐系统也可感知用户对商品颜色和模特展示方式的偏好，然后选择最合适的商品缩略图，展示给用户，提升商品点击率。

个性化AIGC的研究

2024清华的个性化多模态大模型PMG （Personalized Multimodal Generation）

PMG的2部分输入：

一部分是要被优化的目标内容——电影《泰坦尼克号》海报，另一部分是用户的历史行为，比如用户曾经点击过的电影，或者用户和大模型的对话记录。

两部分输入，分别被大语言模型转换成了用户偏好关键词和目标物品关键词，再通过预训练的文本编码器，转换成用户兴趣 Embedding 和目标物品Embeding。

同时，PMG 的上半部分，是一个叫偏置纠正大语言模型（Bias Correction LLM）的模块。

用户的历史行为，通过该模块，也生成了一个用户软兴趣 Embedding（Sof Preference Embedding）。

该 Embedding 主要是为 PMG更好地完成多模态任务而生成的。

用户偏好 Embedding 和目标物品 Embedding，完全是通过文本关键词生成的，会丢掉一些原始多模态内容的信息，用户的软兴趣Embedding 恰好在训练中纠正并补充了这部分信息。

三个Embedding 通过加权生成最终的个性化目标物品 Embedding，并由图片或视频生成器，生成个性化目标物品。

这里的生成器，用的就是Stable Diffusion 模型。

PMG 提供了一个个性化 AIGC 的框架，即在生成内容时，把用户的历史行为转换成Embedding 融合进目标物品 Embedding，这就可以在生成的图片、视频中体现用户个人偏好。

除个性化电影海报的生成，PMG还给出了个性化商品图片、个性化服装设计的例子。

在把 PMG的内容生成器替换成其他模态的生成器后，文本、音频、视频内容的生成也可以融合个性化的偏好。

谷歌的TensorFlow，亚马逊的MX Net 、Meta的 PyTorch、百度的PaddliePadale3，是各科技巨头推出的深度学习框架。

TensorFlow 和 PyTorch 渐成多数科技公司的首选平台。

模型流式训练

1. 样本拼接

流式的样本拼接任务，一般在 Flink 中执行。

Flink 任务接收曝光数据流、点击数据流（点击作为样本标签）和其他数据流（如用户行为数据流）等 Kafka 主题（topic），再从特征数据库中获取用户和物品相关的特征，基于用户ID 和物品 ID 进行样本拼接，生成训练样本。

2.模型增量训练

在 TensorFlow 或PyTorch 等离线训练平台中进行。

一般Flink 会在积攒几分钟到几十分钟的训练样本后，一次性发给训练平台进行增量训练。

开始前，平台会载入最新模型版本（checkpoint），从 Flink读取训练样本，采用mini-batch 的方式进行增量训练；训练样本消耗完后，将当前模型版本保存到离线存储，再交由模型线上服务模块进行处理，载入线上服务器，完成这次增量训练过程。

模型训练的实时性，取决于 Flink一次积攒的样本量和训练的间隔时长。但一般深度学习推荐模型的体积都比较大，模型上线要消耗几十分钟。所以，流式更新的频率并不是越快越好，而应综合考虑各模块配合的效率后确定。

3. 模型上线

工业级模型规模一般较大，模型上线也分为两部分。

一部分是规模较小的神经网络图部分，可以 ONNX文件的形式上线到 ONNX Runtime，或直接用 TensorFlowServing 或TorchServe的方式上线。

另一部分是 Embedding 部分，这部分规模大、数量多，如直接跟模型一起打包上线到模型服务中，会导致模型服务被“撑爆”。

因此，Embedding 部分会使用参数服务器上线，Embedding 参数服务器一般是独立于模型服务器的 Redis 或RocksDBKey-Value 存储。

为保证系统的稳定性，一般会将训练时的参数服务器和线上服务的参数服务器独立部署，并在上线中进行参数检查，以免错误训练影响线上服务。

4.特征处理

样本拼接和线上服务所用的特征，一般存储在以Redis 代表的内存数据库中。

特征数据库主用于样本拼接和线上服务时加载特征。特征的更新由样本拼接任务和推荐服务器的特征更新逻辑共同完成。

一般样本拼接任务，会更新需进行复杂计算的统计类特征，推荐服务器，则负责实时更新用户和物品的属性特征及场景特征。

Embedding 层权重会被更新（参照随机梯度下降的参数更新公式理解），这进一步降低了Embedding 层的收敛速度。

样本拼接中的延迟问题

样本拼接中，需把点击数据流和曝光数据流拼接起来，用户看到推荐结果和点击推荐结果这两个事件，往往是有时间差的，短则几秒，长则几分钟。

如样本的标签是购买、游戏付费等，曝光和转化之间的延迟达几小时都有可能。

第一种，负样本缓存。

模型学习样本的延迟过大，很难称得上实时更新。

第二种，负样本打散。

非常实用，很多工程团队借此快速解决了样本回传延迟问题。

缺点也明显，方法较粗糙，无法将正负样本精确匹配，导致很多负样本可能是“假”负样本，这显然影响模型学习的效果。

第三种，训练推荐模型的同时，联合训练一个延迟预估模型。

在训练阶段，对推荐模型和延迟预估模型联合建模；而在预估阶段，舍弃延迟预估模型，只用推荐模型进行预估。

这种方案，包括 Criteo 2014年提出的 DFM （Delayed Feedback Model） ，阿里2020年提出的 ES-DFM （Elapsed-Time Sampling Delayed Feedback Model） 等。

这需要对推荐模型进行较大改造，要求团队有强理论基础，工程落地较难。

第四种，笔者很喜欢，它是2021年谷歌提出的叠加式延迟转化模型。

思路：既然在推荐模型里考虑转化延迟这么难，不如干脆把模型拆分成多个同构但目标不同的多级模型，每级模型预估不同延迟的转化，在预估时，把所有模型的预估值叠加，作为最终预估值。

方案还有很多可优化的地方。

例：不同子模型的更新频率可以不同，低延迟的子模型可以采用样本准实时拼接、流式训练的方式；

而高延迟的子模型，由于对时间敏感度低，根据延迟长短，可用小时级别甚至天级别更新的方式。

这样，实时子模型能快速感知到用户行为的变化，长延迟子模型，还可保证长延迟转化也被考虑进来，防止预估值偏离。

在工程领域，任何新技术的引入，都不会是毫无代价的。流式训练也如此。

模型在享受实时训练红利的同时，也变得相当脆弱。

任何数据流的“风吹草动”，都影响模型训练，且模型参数需被高频同步给线上模型服务平台，同步中的任何失误，都直接影响线上预估推荐结果。

流式训练的模型一直是各大公司的事故重灾区。工程团队必须在几个关键处加入容灾措施。

（1）数据流的监控。

必须监控数据流总样本数量的变化、正负样本比例的变化以及延迟情况。一旦发现异常，果断切断数据流，避免脏数据污染线上模型。

（2）模型训练的监控。

训练中，每隔一段固定时间，就要自动进行一次离线验证，比如利用最近的样本计算AUC。

一发现模型被“训飞”，果断停止训练，并将模型切换到上一个稳定版本。

（3）模型上线的监控。

流式训练模型的线上同步，一般5～10分钟一次。每次上线前，需先在训练时的参数服务器上，验证预估值，如发现新训练的模型预估值与线上预估值偏离较远，应阻止这次上线并人工排查。

流式训练模型，显著增加工程团队的值班压力及系统的复杂性。做技术决策的时候，不要忽视这部分成本。

当流式模型带来的业务收益大于成本的增加时，流式模型的应用，才物有所值，否则只是技术团队“炫技”罢了。

任何工程师的职责都是相同的：在现有实际条件的制约下，以工程完成和技术落地为目标，寻找并实现最优的解决方案。

“现有实际条件的制约”，可以是来自研发周期的制约、软硬件环境的制约、实际业务逻辑和应用场景的制约，也可以是产品经理的优化目标的制约，等等。

对线上推荐系统来说，为了在线服务，需获取的数据包括2部分——模型参数和线上特征。

为保证两部分数据的实时性，很多公司用内存数据库，而Redis 是最主流选择。

但 Redis 要占用大量内存资源，而内存资源与存储资源和计算资源相比，又是比较稀缺和昂贵的。

无论用AWS（Amazon Web Services，亚马逊网络服务）、阿里云，还是自建数据中心，使用Redis 的成本都较高。

Redis 的容量，成了影响推荐模型上线方式的关键因素。

在此因素限制下，工程师要从两方面考虑问题。

（1）模型的参数规模尽量小，特别是对深度学习推荐系统而言，模型的参数规模较传统模型提升了几个量级，更应着重考虑减小模型的参数规模。

（2）线上预估所需的特征数量，不能无限制地增加，要根据重要性，做一定的取舍。上线推荐系统，必然要舍弃些次要因素，关注主要矛盾。

成熟工程师的思路：

（1）对上千万甚至更高量级的特征维度，理论上参数也在千万量级，线上服务是很难支持这种级别的数据量的。

这就要在工程上关注模型的稀疏性，关注主要特征，舍弃大量次要特征，舍弃一定的模型预测准确度，提升线上预估的速度，降低工程资源的消耗。

（2）考虑增强模型的稀疏性的关键技术点，加入L1 正则化项，采用FTRL 等稀疏性强的训练方法。

（3）实现目标的技术途径有多种，在无法确定哪种技术效果更佳的情况下，实现所有备选方案，通过离线和在线的指标进行比较和观察。

（4）根据数据确定最终的技术途径，完善工程实现。

以上是模型侧的“瘦身”方法。在线特征的“瘦身”计划，可用同样的思路。

先用主成分分析等方法进行特征筛选，在不显著降低模型效果的前提下，减少所用的特征。

对不好取舍的特征，进行离线评估和线上A/B测试，最终使特征的数量，达到工程上可接受的水平。

研发周期同样是不可忽视的制约因素。

这就涉及工程师对项目整体的把控能力和对研发周期的预估能力。在产品迭代日益迅速的互联网领域，没人愿成为拖累其他团队的最慢一环。

技术平台升级中，要充分权衡产品新需求和技术平台整体升级的进度。

例：公司希望把深度学习平台从 TensorFlow 整体迁移到 PyTorch。但由于TensorFlow 1.x 平台的特性、建模方式、模型训练方式和 PyTorch 有较大差别，迁移必然要经历一个较长的研发周期。

在迁移的过程中，如果有新的产品需求，就需要工程师权衡，在进行技术升级的同时，兼顾日常的开发进度。

可能的技术途径有2个：

（1）集中团队的力量完成 TensorFlow 1.x到PyTorch 的迁移，在新平台上进行新模型和新功能的研发。

（2）部分成员利用稳定的 TensorFlow 1.x平台，快速满足产品需求，为PyTorch的迁移、调试、试运行留足时间。

另一部分成员全力完成 PyTorch的相关工作，力保在大规模迁移之前新平台足够成熟。

既已决定升级到 PyTorch 平台，理论上，没必要再花时间用TensorFlow 1.x平台研发新模型。

要搞清的2问题：

（1）再成熟的平台，也需团队磨合调试较长时间，绝不可能刚迁移至 PyTorch，就让它支持重要的业务逻辑。

（2）技术平台的升级换代，应作为技术团队的内部项目，最好对其他团队透明，不应成为减缓对业务支持的直接理由。

第2个技术途径，更符合工程实际和公司的选择。

算法工程师都有类似抱怨：“公司的平台资源太少，训练一个模型要花近一天。”小厂囿于研发成本的限制，更容易受硬件平台环境的制约。

无论什么规模的公司，硬件资源总归是有限的，要在有限的硬件资源条件下，优化模型相关的一切工程实现。

这里的优化含2方面：

一方面是程序本身的优化。

常有实习生抱怨 Spark 跑得太慢，是他们对 Spark 的 shufile 机制没深入了解，写的程序，含大量触发 shufle 的操作，引发数据倾斜问题。

另一方面的优化，就要进行技术取舍了。

能否通过优化或者简化模型的结构大幅提升模型训练的速度，减少模型训练消耗的资源，提升推荐模型的实时性？

在深度学习模型中，模型的整体训练收敛速度和模型的参数数量，有很强的相关性，而在模型的参数中，绝大部分是输入层到Embedding 层的参数。

为大幅加快模型的训练速度，可将 Embedding 部分单独抽取出来做预训练，这就可以使上层模型快速收敛。

这舍弃了端到端训练的一致性，但在硬件条件制约的情况下，增强模型实时性的收益可能远大于端到端训练带来的模型一致性收益。

类似的例子，还包括简化模型结构的问题。

如通过增加模型复杂性（例如，增加神经网络层级或增加每层神经元的数量）带来的收益已经趋于平缓，就没必要浪费过多硬件资源以获取微乎其微的效果提升，而应把优化的方向转换到提升系统实时性、挖掘其他有效信息、为模型引入更有效的网络结构等方面。

RecSim是谷歌基于 TensorFlow 环境开发的推荐系统模拟器。

用户行为模型vs推荐模型

（1）模拟器要评估的，不仅是推荐模型在某一固定状态下的效果，更重要的是，模拟并评估推荐模型在整个生命周期中的整体效果。

用户行为模型会使用所有历史数据训练一个尽可能强大的模型，而推荐模型，则是从零开始学习，逐渐探索用户行为模型的性格和兴趣，逐渐提升效果。

这一学习的速度和效果，决定了推荐模型在整个生命周期中的表现。

（2）用户行为模型可用一些推荐模型无法感知到的信息。

使用其他数据源的信息来训练用户行为模型，能丰富它的知识总量。

例如，通过庞大的第三方语料库，来预训练一个用户行为模型，就可以生成一个更强大、更全面的行为模型，用于推荐模型的评估。

第2点就是用 ChatGPT这类预训练大语言模型来构建用户行为模型的思路。

2023年由中国人民大学的研究人员研发的 RecAgent 是采用这一方法的典型代表。

RecAgent 生成了 1000个具备不同性别、年龄、爱好的用户用于模拟测试。

如果只是基本属性不同，用户的区别是非常有限的。

一个用户对于推荐列表的选择结果，还取决于其长短期记忆。

RecAgent 中的记忆模块（Memory Module），为模拟不同用户的长短期记忆而设置。

例如，在一个电影推荐任务中，记忆模块可提供不同用户历史上最喜欢看的几部电影作为 ChatGPT 的输入，使ChatGPT 可模拟拥有不同记忆的用户的选择。

准备好用户属性和用户记忆后，将它们连同当前的场景信息及与任务相关的指令信息一作为提示词（Prompt）输入 ChatGPT，ChatGPT 就可以成为具有当前用户性格和记忆的用户为模型。模拟器就可以用这个强大的用户行为模型完成对推荐模型的评估了。

RecAgent是大模型在推荐系统中的一次成功应用。虽然它有一些问题。

例如，受资源限制，能够模拟的用户数仍比较少，以及对评估的公平性仍无法充分论证等。

但它提供了一个扩展性很强的用户行为模型解决方案，让推荐系统模拟器这种终极的离线评估方法更可行。

A/B 测试

又称“分流测试”或“分桶测试”，是一种随机实验，在利用控制变量法保持单一变量的前提下，将A、B两组数据进行对比，得出实验结论。

互联网场景下的算法测试，可将用户随机分成实验组和对照组，对实验组的用户施以新模型，对对照组的用户施以旧模型，比较实验组和对照组在各类线上评估指标上的差异。

相对离线评估而言，线上A/B测试无法被替代的原因，有3点。

（1）离线评估无法完全消除数据有偏（Data Bias）现象的影响，得出的离线评估结果，无法完全替代线上评估结果。

（2）离线评估无法完全还原线上的工程环境。离线评估往往不考虑线上环境的延迟、数据丢失、标签数据缺失等情况。

离线评估环境是理想状态下的工程环境，得出的评估结果存在一定的失真现象。

（3）线上系统的某些商业指标，在离线评估中无法计算。

离线评估一般针对模型本身进行评估，无法直接获得与模型相关的其他指标，特别是商业指标。

例如，在评估新的推荐模型时，离线评估关注的往往是ROC曲线、P-R 曲线等的改进，而线上评估则可以全面了解该推荐模型带来的用户点击率、留存时长、PV 等访问量的变化。这些都需要通过 A/B 测试全面评估。

一般，A/B 测试是模型上线前的最后一道测试，通过A/B 测试检验的模型将直接服务线上用户，实现公司商业目标。

因此，A/B 测试的指标应与线上业务的核心指标保持一致。

Interleaving 方法，被当作线上AB 测试的预选阶段。

从大量初始算法中筛选出少量“优秀”的推荐算法后，再对缩小的算法集合进行传统的A/B 测试，以测量它们对用户行为的长期影响。

Interleaving 能多快速地缩减最初的候选算法集合，比传统的 A/B 测试更快地确定最优算法。

在 Netfix 的场景下，非常活跃的用户是少数，但其贡献的观看时长却占较大的比例。

因此，在Netflix 的A/B 测试中，活跃用户被分在A组的多还是被分在B组的多，将对测试结果产生较大影响，掩盖模型的真实效果。

一个方法是，不对测试人群分组，让所有测试者都自由选百事和可口可乐（测试中无品牌标签，但能区分两种可乐）。

实验结束时，统计每个人消费可口可乐和百事可乐的比例，然后对每人的消费比例进行平均，得到整体的消费比例。

A/B 测试中，Netfix 会选择两组订阅用户：一组接受排序算法 A 的推荐结果，另一组接受排序算法B的推荐结果。

Interleaving 方法中，只有一组订阅用户，这些订阅用户会收到通过混合算法 A和算法B 的推荐结果生成的列表。

这就使用户可以在一行里，同时看到算法 A 和算法B 的推荐结果（用户无法区分一个物品是由算法A还是由算法B推荐的）。

通过计算观看时长等指标，可衡量到底是算法 A 的效果好，还是算法B 的效果好。

用 Interleaving 方法测试时，必须考虑位置 Bias 的存在，避免算法A推荐的视频总排在第一。

要以相等的概率，让算法 A 和算法B的推荐结果交替领先。

这类似球类比赛中，两个队长先通过扔硬币决定谁先选人，再交替选队员的过程。

厘清了 Interleaving 方法的评估过程后，还要验证评估方法能不能替代传统的A/B 测试，会不会得出错误结果。

Netflix 从2方面进行了验证：

一是 Interleaving 方法的“灵敏度”，二是 Interleaving 方法的“正确性”。

Netlix 进行的“灵敏度” 实验，旨在比较 Interleaving 方法与传统 A/B 测试在验证算法 A和算法B 优劣时所需的样本量。

线上测试的资源往往是受限的，自然希望 Interleaving 方法能在使用较少的线上资源和测试用户的情况下完成评估，这就是所谓的灵敏度比较。

即使与最灵敏的 AVB 测试指标相比，Interleaving 方法也只需1%的订阅用户样本就能确定用户更偏爱哪个算法的推荐结果。

利用一组 A/B 测试的资源，可做100组nterleaving 方法的实验。

Interleaving 方法评估指标与传统 A/B 测试评估指标的相关性

除了能够利用小样本快速进行算法评估，Interleaving 方法的结果是否与 A/B 测试一致，也是验证 Interleaving 方法能否在线上评估阶段取代A/B测试的关键。

结果表明，二者的评估指标之间存在非常强的相关性，这就验证了在Interleaving 方法的实验中胜出的算法也极有可能在之后的A/B测试中胜出。

但在 Interleaving 方法的实验中所展示的产品页面，并不是单独由算法 A 或者算法B 生成的，而仅是实验用的混合页面。

要测试某个算法的真实效果，Interleaving 方法是无法完全替代A/B测试的。

希望得到更全面和真实的线上评估指标，A/B 测试仍是最权威的测试方法。

Interleaving 方法的优点是，所需样本少，测试速度快，结果与传统 A/B 测试无明显差异。

也存在局限性。

（1）工程实现的框架，较传统 A/B 测试复杂。

Interleaving 方法的实验逻辑和业务逻辑纠缠在一起，因此业务逻辑可能会被干扰。为了实现 Interleaving 方法，需要将大量辅助性的数据标识添加到整个数据流中，这增加了工程实现的难度。

（2） Interleaving 方法只能对“用户对算法推荐结果的偏好程度”进行相对测量，无法提供算法的真实表现。

希望了解算法 A 能够将用户整体的观看时长增加了多少，将用户的留存率提高了多少，用 Interleaving 方法，是无法得出结论的。

Netfix设计了“Interleaving+A/B测试”的两阶段实验结构，完善了整个线上测试的框架。

推荐系统的评估体系

对公司来说，最公正合理的评估是线上评估，验证模型能否更好地达成公司或团队的商业目标。

为什么不能对所有的模型改进都进行线上评估，以确定改进的合理性？

因为线上A/B 测试要占用宝贵且有限的线上流量资源，还可能对用户体验造成影响，因此有限的线上评估机会，远不能满足算法工程师改进算法的需求。

线上评估往往持续几天甚至几周，这将大大延长算法迭代的时间。

线上评估种种限制，离线评估才成为算法工程师求其次的选择。

离线评估，可用近乎无限的离线计算资源，快速得出评估结果，快速实现模型的迭代优化。

在线上 A/B 测试和传统离线评估之间，还有 Replay、推荐系统模拟器、Interleaving 等评估方法。

Replay 方法，能模拟线上的模型更新过程，推荐系统模拟器，能最大限度地在离线状态下模拟线上环境，Interleaving 方法则可以快速建立线上评估环境。

这种多层级的评估方法，共同构成了完整的推荐系统评测体系，在评测效率和正确性之间达到平衡。

底层包含了大量待筛选的模型和待验证的改进想法。它们数量巨大，“评估效率”成为考虑的关键因素，对评估“正确性”的要求则没有那么苛刻，这时应该使用效率更高的离线评估方法。

随着候选模型被一层层筛选出来，在越接近正式上线的阶段，评估方法对评估“正确性”的要求就越严格。

模型正式上线前，应以最接近真实产品体验的 A/B 测试，进行最后的模型评估，等产生最具说服力的在线指标后，模型才能上线，完成模型改进的迭代过程。

如何学习AI大模型？

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

这是一份大模型从零基础到进阶的学习路线大纲全览，小伙伴们记得点个收藏！

第一阶段：从大模型系统设计入手，讲解大模型的主要方法；

第二阶段：在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段：大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段：大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段：大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段：以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段：以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

100套AI大模型商业化落地方案

大模型全套视频教程

200本大模型PDF书籍

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

LLM面试题合集

大模型产品经理资源合集

大模型项目实战合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓