解析多模态大模型核心原理，涵盖 Stable Diffusion 文本转图像及 Sora 视频生成架构。介绍 CLIP、UNet、Transformer 等关键技术。探讨大模型在推荐系统中的应用，如 GeneRec 和 PMG 框架实现个性化内容生成。工程实践部分详述模型流式训练、样本延迟处理、模型瘦身策略及多层级评估体系（离线、Replay、A/B 测试、Interleaving），旨在平衡效率与正确性，指导技术落地。
多模态大模型通过 Embedding、信息融合与任务学习处理多源数据。Stable Diffusion 利用 CLIP 和 UNet 实现文本到图像生成，Sora 扩展到视频领域，加入时空切块和一致性模块保证连贯性。大模型赋能推荐系统实现个性化内容生成，如 GeneRec 和 PMG。工程实践中需关注模型瘦身、流式训练及多层级评估体系，平衡效率与正确性。
多模态大模型的整体架构，与纯文本大模型没本质区别，都要经原始数据的 Embedding、信息融合与目标任务学习及微调等过程。
负责文本编码的模型为 CLIP。为把原始文本 Prompt 编码成适用于图像生成的 Embedding，研究人员使用了 4 亿张图像及其对应的 Prompt 来预训练 CLIP。
为表达图像和解释文字的相似性，CLIP 用了一个类似双塔的结构：
对应的图像和解释文字的 Embedding 越相近时，模型的 Loss 越小；反之，模型的 Loss 越大。
训练完毕，文本编码器部分被取出，并应用于 Stable Diffusion。这样训练出来的文本编码器，擅长的就是由文本生成图像 Embedding 的任务。
CLIP 生成的 Embedding 相当于输入的 Prompt 在隐向量空间的表达。
如何由这个表达，生成最终图像呢？
由一张随机噪声图像扩散（diffusion）而来，这也是 Stable Diffusion 名字的由来。
最终图像是由 UNet 网络经过 50 步扩散而生成。
UNet 网络如何按 Prompt Embedding 的意图生成图像？
在每个 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 可信度较高的模型架构。
用户给出相对较短且描述粗略的 Prompt 后，Sora 先用 GPT 对用户 Prompt 扩写，扩充包含细节描述的长 Prompt。
这步 Prompt 扩写很重要，Prompt 对细节描述得越明确，视频生成质量越好。
让 GPT 加入细节描述，体现了'在尽可能多的生产环节让大模型辅助或取代人'的思路。
Sora 内部有文本编码器（Text Encoder），它把长 Prompt 对应的文字描述转化成每个 token 对应的 Embedding，这意味着，将文字描述从文本空间转换为隐空间参数。
而这个文本编码器，大概率是 CLIP 模型对应的'文本编码器'，因为 OpenAI 的 DALL-E 系列模型里的文本编码器，用的就是它。
根据 Stable Diffusion 的原理，最终生成的图像，是由随机噪声扩散出的。
因此，Sora 另一个关键输入是，确定了分辨率和帧数的随机噪声图片序列。
在该序列基础上，视频生成模型逐帧生成图像，最终连续起来成为 Sora 生成的视频。
Sora 的模型架构中，最重要也是最不易理解的，是'视频生成器'。
它与 Stable Diffusion 架构高度相似，都由视觉编码器、Transformer 扩散模型、视频解码器组成。
不同的是，Sora 要处理视频，它加入了一个'空间时间隐向量切块（Spacetime Latent Patch）模块'（'切块模块'），来处理多帧视频，以及一个'长时间一致性模块'（'一致性模块'），来保证视频中各帧的一致性。
切块模块的主要作用是，降低视频的维度，进而减少后续模型处理的数据量，同时适配 Transformer 所需的数据格式。
按 Sora 官方介绍，该模块先把原始视频帧切块，每块进行 sum pooling 或 average pooling，生成一维度小得多的二维 Embedding。
Transformer 只接受一维 Embedding 数据，还需把这个二维 Embedding 线性化，比如直接展平成一维 Embedding，或通过 MLP 映射成一维 Embedding。
可把切块模块，当作原始视频帧数据到 Transformer 所需数据的转换器。
一致性模块，是视频生成模型特有的模块，否则生成的视频各帧之间，不具备连贯性和逻辑联系。
保证各帧一致性的方法是，在生成下一帧时，建立该帧和之前已生成帧的联系。
一种是全范围注意力方法：建立从当前帧到之前所有帧的交互关系，这比较'暴力'，计算量过大。
二是轻巧一些的分层注意力方法：先生成前几帧，生成后面帧时不要顺序生成，而是生成关键帧。关键帧与之前帧，也不是逐帧连接的，而是隔几帧挑选一帧进行连接。
这保证了整个视频的全局一致性，而且计算过程较高效。生成关键帧后再逐渐补充剩余帧。
推荐系统的使命是，帮用户发现感兴趣的信息和内容。而大模型强大的内容生成能力，使个性化内容生成，成为可能。
大模型有可能越过'推荐'环节，直接为用户创造一个新世界，这才是大模型可能为推荐系统带来的最大革命。
MoRec、GBNRE 等方案，让推荐系统通过大模型学到更多'世界知识'，更好地理解这个世界；
PALR、UniLLMRec，则通过大模型构造了全新的推荐系统，让大模型成为这个推荐系统的世界本身。
新加坡国立大学，提出下一代生成式推荐系统的框架 GeneRec。
传统推荐系统的内容生成： 人类创作内容，上传到推荐系统的候选物品集中，推荐系统根据推荐模型的选择，从候选物品集中挑选合适的内容，展现给用户。用户产生反馈后，反馈信息被返回给推荐系统，促使推荐模型持续优化。
GeneRec，比传统推荐系统多了个 AI 创作者（AI Generator）： 它根据用户需求生成新内容，创作的内容可直接进入候选物品集，供推荐系统选择，也可直接返给用户，给用户最直接快速的响应。
例：有一类短视频是，截取并整合长视频的片段，来满足用户'快餐式'的观看需求。
对这类需求，根据用户的行为历史来推断用户兴趣，再根据用户兴趣，截取和整合视频，就是 GeneRec 一个很好的应用场景。
比如 5 号用户的历史行为是，看了些风景、宠物的视频。 把这些信息输入给 AI 创作者，它通过大模型理解用户意图和长视频中每一帧内容，从中截取出自然风景相关的短视频，推送给用户。
100 号用户喜看汽车和美女视频，AI 创作者就截取了汽车相关的片段推送给他。
在服装商品推荐场景中，商品展示图中服装的搭配、颜色、模特的姿势和风格，都可直接影响用户的购买决策。
借 GeneRec 框架，可把用户历史行为描述，以 Prompt 的方式，输入给 AI 创作者大模型，从而针对性地生成更能吸引用户的商品缩略图。
推荐系统也可感知用户对商品颜色和模特展示方式的偏好，然后选择最合适的商品缩略图，展示给用户，提升商品点击率。
2024 清华的个性化多模态大模型 PMG（Personalized Multimodal Generation）
PMG 的 2 部分输入： 一部分是要被优化的目标内容——电影《泰坦尼克号》海报，另一部分是用户的历史行为，比如用户曾经点击过的电影，或者用户和大模型的对话记录。 两部分输入，分别被大语言模型转换成了用户偏好关键词和目标物品关键词，再通过预训练的文本编码器，转换成用户兴趣 Embedding 和目标物品 Embedding。
同时，PMG 的上半部分，是一个叫偏置纠正大语言模型（Bias Correction LLM）的模块。 用户的历史行为，通过该模块，也生成了一个用户软兴趣 Embedding（Soft Preference Embedding）。 该 Embedding 主要是为 PMG 更好地完成多模态任务而生成的。
用户偏好 Embedding 和目标物品 Embedding，完全是通过文本关键词生成的，会丢掉一些原始多模态内容的信息，用户的软兴趣 Embedding 恰好在训练中纠正并补充了这部分信息。
三个 Embedding 通过加权生成最终的个性化目标物品 Embedding，并由图片或视频生成器，生成个性化目标物品。
这里的生成器，用的就是 Stable Diffusion 模型。
PMG 提供了一个个性化 AIGC 的框架，即在生成内容时，把用户的历史行为转换成 Embedding 融合进目标物品 Embedding，这就可以在生成的图片、视频中体现用户个人偏好。
除个性化电影海报的生成，PMG 还给出了个性化商品图片、个性化服装设计的例子。
在把 PMG 的内容生成器替换成其他模态的生成器后，文本、音频、视频内容的生成也可以融合个性化的偏好。
谷歌的 TensorFlow，亚马逊的 MX Net、Meta 的 PyTorch、百度的 PaddlePaddle，是各科技巨头推出的深度学习框架。 TensorFlow 和 PyTorch 渐成多数科技公司的首选平台。
样本拼接 流式的样本拼接任务，一般在 Flink 中执行。 Flink 任务接收曝光数据流、点击数据流（点击作为样本标签）和其他数据流（如用户行为数据流）等 Kafka 主题（topic），再从特征数据库中获取用户和物品相关的特征，基于用户 ID 和物品 ID 进行样本拼接，生成训练样本。
模型增量训练 在 TensorFlow 或 PyTorch 等离线训练平台中进行。 一般 Flink 会在积攒几分钟到几十分钟的训练样本后，一次性发给训练平台进行增量训练。 开始前，平台会载入最新模型版本（checkpoint），从 Flink 读取训练样本，采用 mini-batch 的方式进行增量训练；训练样本消耗完后，将当前模型版本保存到离线存储，再交由模型线上服务模块进行处理，载入线上服务器，完成这次增量训练过程。
模型训练的实时性，取决于 Flink 一次积攒的样本量和训练的间隔时长。但一般深度学习推荐模型的体积都比较大，模型上线要消耗几十分钟。所以，流式更新的频率并不是越快越好，而应综合考虑各模块配合的效率后确定。
模型上线 工业级模型规模一般较大，模型上线也分为两部分。 一部分是规模较小的神经网络图部分，可以 ONNX 文件的形式上线到 ONNX Runtime，或直接用 TensorFlow Serving 或 TorchServe 的方式上线。 另一部分是 Embedding 部分，这部分规模大、数量多，如直接跟模型一起打包上线到模型服务中，会导致模型服务被'撑爆'。 因此，Embedding 部分会使用参数服务器上线，Embedding 参数服务器一般是独立于模型服务器的 Redis 或 RocksDB Key-Value 存储。 为保证系统的稳定性，一般会将训练时的参数服务器和线上服务的参数服务器独立部署，并在上线中进行参数检查，以免错误训练影响线上服务。
特征处理 样本拼接和线上服务所用的特征，一般存储在以 Redis 代表的内存数据库中。 特征数据库主用于样本拼接和线上服务时加载特征。特征的更新由样本拼接任务和推荐服务器的特征更新逻辑共同完成。 一般样本拼接任务，会更新需进行复杂计算的统计类特征，推荐服务器，则负责实时更新用户和物品的属性特征及场景特征。 Embedding 层权重会被更新（参照随机梯度下降的参数更新公式理解），这进一步降低了 Embedding 层的收敛速度。
样本拼接中，需把点击数据流和曝光数据流拼接起来，用户看到推荐结果和点击推荐结果这两个事件，往往是有时间差的，短则几秒，长则几分钟。 如样本的标签是购买、游戏付费等，曝光和转化之间的延迟达几小时都有可能。
第一种，负样本缓存。 模型学习样本的延迟过大，很难称得上实时更新。
第二种，负样本打散。 非常实用，很多工程团队借此快速解决了样本回传延迟问题。 缺点也明显，方法较粗糙，无法将正负样本精确匹配，导致很多负样本可能是'假'负样本，这显然影响模型学习的效果。
第三种，训练推荐模型的同时，联合训练一个延迟预估模型。 在训练阶段，对推荐模型和延迟预估模型联合建模；而在预估阶段，舍弃延迟预估模型，只用推荐模型进行预估。 这种方案，包括 Criteo 2014 年提出的 DFM（Delayed Feedback Model），阿里 2020 年提出的 ES-DFM（Elapsed-Time Sampling Delayed Feedback Model）等。 这需要对推荐模型进行较大改造，要求团队有强理论基础，工程落地较难。
第四种，笔者很喜欢，它是 2021 年谷歌提出的叠加式延迟转化模型。 思路：既然在推荐模型里考虑转化延迟这么难，不如干脆把模型拆分成多个同构但目标不同的多级模型，每级模型预估不同延迟的转化，在预估时，把所有模型的预估值叠加，作为最终预估值。 方案还有很多可优化的地方。 例：不同子模型的更新频率可以不同，低延迟的子模型可以采用样本准实时拼接、流式训练的方式； 而高延迟的子模型，由于对时间敏感度低，根据延迟长短，可用小时级别甚至天级别更新的方式。 这样，实时子模型能快速感知到用户行为的变化，长延迟子模型，还可保证长延迟转化也被考虑进来，防止预估值偏离。
在工程领域，任何新技术的引入，都不会是毫无代价的。流式训练也如此。 模型在享受实时训练红利的同时，也变得相当脆弱。 任何数据流的'风吹草动'，都影响模型训练，且模型参数需被高频同步给线上模型服务平台，同步中的任何失误，都直接影响线上预估推荐结果。 流式训练的模型一直是各大公司的事故重灾区。工程团队必须在几个关键处加入容灾措施。
流式训练模型，显著增加工程团队的值班压力及系统的复杂性。做技术决策的时候，不要忽视这部分成本。 当流式模型带来的业务收益大于成本的增加时，流式模型的应用，才物有所值，否则只是技术团队'炫技'罢了。
任何工程师的职责都是相同的：在现有实际条件的制约下，以工程完成和技术落地为目标，寻找并实现最优的解决方案。 '现有实际条件的制约'，可以是来自研发周期的制约、软硬件环境的制约、实际业务逻辑和应用场景的制约，也可以是产品经理的优化目标的制约，等等。
对线上推荐系统来说，为了在线服务，需获取的数据包括 2 部分——模型参数和线上特征。 为保证两部分数据的实时性，很多公司用内存数据库，而 Redis 是最主流选择。 但 Redis 要占用大量内存资源，而内存资源与存储资源和计算资源相比，又是比较稀缺和昂贵的。 无论用 AWS（Amazon Web Services，亚马逊网络服务）、阿里云，还是自建数据中心，使用 Redis 的成本都较高。 Redis 的容量，成了影响推荐模型上线方式的关键因素。 在此因素限制下，工程师要从两方面考虑问题。
成熟工程师的思路：
以上是模型侧的'瘦身'方法。在线特征的'瘦身'计划，可用同样的思路。 先用主成分分析等方法进行特征筛选，在不显著降低模型效果的前提下，减少所用的特征。 对不好取舍的特征，进行离线评估和线上 A/B 测试，最终使特征的数量，达到工程上可接受的水平。
研发周期同样是不可忽视的制约因素。 这就涉及工程师对项目整体的把控能力和对研发周期的预估能力。在产品迭代日益迅速的互联网领域，没人愿成为拖累其他团队的最慢一环。 技术平台升级中，要充分权衡产品新需求和技术平台整体升级的进度。 例：公司希望把深度学习平台从 TensorFlow 整体迁移到 PyTorch。但由于 TensorFlow 1.x 平台的特性、建模方式、模型训练方式和 PyTorch 有较大差别，迁移必然要经历一个较长的研发周期。 在迁移的过程中，如果有新的产品需求，就需要工程师权衡，在进行技术升级的同时，兼顾日常的开发进度。 可能的技术途径有 2 个：
既已决定升级到 PyTorch 平台，理论上，没必要再花时间用 TensorFlow 1.x 平台研发新模型。 要搞清的 2 问题：
第 2 个技术途径，更符合工程实际和公司的选择。
算法工程师都有类似抱怨：'公司的平台资源太少，训练一个模型要花近一天。'小厂囿于研发成本的限制，更容易受硬件平台环境的制约。 无论什么规模的公司，硬件资源总归是有限的，要在有限的硬件资源条件下，优化模型相关的一切工程实现。 这里的优化含 2 方面： 一方面是程序本身的优化。 常有实习生抱怨 Spark 跑得太慢，是他们对 Spark 的 shuffle 机制没深入了解，写的程序，含大量触发 shuffle 的操作，引发数据倾斜问题。 另一方面的优化，就要进行技术取舍了。 能否通过优化或者简化模型的结构大幅提升模型训练的速度，减少模型训练消耗的资源，提升推荐模型的实时性？ 在深度学习模型中，模型的整体训练收敛速度和模型的参数数量，有很强的相关性，而在模型的参数中，绝大部分是输入层到 Embedding 层的参数。 为大幅加快模型的训练速度，可将 Embedding 部分单独抽取出来做预训练，这就可以使上层模型快速收敛。 这舍弃了端到端训练的一致性，但在硬件条件制约的情况下，增强模型实时性的收益可能远大于端到端训练带来的模型一致性收益。 类似的例子，还包括简化模型结构的问题。 如通过增加模型复杂性（例如，增加神经网络层级或增加每层神经元的数量）带来的收益已经趋于平缓，就没必要浪费过多硬件资源以获取微乎其微的效果提升，而应把优化的方向转换到提升系统实时性、挖掘其他有效信息、为模型引入更有效的网络结构等方面。
RecSim 是谷歌基于 TensorFlow 环境开发的推荐系统模拟器。
2023 年由中国人民大学的研究人员研发的 RecAgent 是采用这一方法的典型代表。 RecAgent 生成了 1000 个具备不同性别、年龄、爱好的用户用于模拟测试。 如果只是基本属性不同，用户的区别是非常有限的。 一个用户对于推荐列表的选择结果，还取决于其长短期记忆。 RecAgent 中的记忆模块（Memory Module），为模拟不同用户的长短期记忆而设置。 例如，在一个电影推荐任务中，记忆模块可提供不同用户历史上最喜欢看的几部电影作为 ChatGPT 的输入，使 ChatGPT 可模拟拥有不同记忆的用户的选择。 准备好用户属性和用户记忆后，将它们连同当前的场景信息及与任务相关的指令信息一作为提示词（Prompt）输入 ChatGPT，ChatGPT 就可以成为具有当前用户性格和记忆的用户为模型。模拟器就可以用这个强大的用户行为模型完成对推荐模型的评估了。 RecAgent 是大模型在推荐系统中的一次成功应用。虽然它有一些问题。 例如，受资源限制，能够模拟的用户数仍比较少，以及对评估的公平性仍无法充分论证等。 但它提供了一个扩展性很强的用户行为模型解决方案，让推荐系统模拟器这种终极的离线评估方法更可行。
又称'分流测试'或'分桶测试'，是一种随机实验，在利用控制变量法保持单一变量的前提下，将 A、B 两组数据进行对比，得出实验结论。 互联网场景下的算法测试，可将用户随机分成实验组和对照组，对实验组的用户施以新模型，对对照组的用户施以旧模型，比较实验组和对照组在各类线上评估指标上的差异。 相对离线评估而言，线上 A/B 测试无法被替代的原因，有 3 点。
一般，A/B 测试是模型上线前的最后一道测试，通过 A/B 测试检验的模型将直接服务线上用户，实现公司商业目标。 因此，A/B 测试的指标应与线上业务的核心指标保持一致。
Interleaving 方法，被当作线上 AB 测试的预选阶段。 从大量初始算法中筛选出少量'优秀'的推荐算法后，再对缩小的算法集合进行传统的 A/B 测试，以测量它们对用户行为的长期影响。 Interleaving 能多快速地缩减最初的候选算法集合，比传统的 A/B 测试更快地确定最优算法。
在 Netflix 的场景下，非常活跃的用户是少数，但其贡献的观看时长却占较大的比例。 因此，在 Netflix 的 A/B 测试中，活跃用户被分在 A 组的多还是被分在 B 组的多，将对测试结果产生较大影响，掩盖模型的真实效果。 一个方法是，不对测试人群分组，让所有测试者都自由选百事和可口可乐（测试中无品牌标签，但能区分两种可乐）。 实验结束时，统计每个人消费可口可乐和百事可乐的比例，然后对每人的消费比例进行平均，得到整体的消费比例。
A/B 测试中，Netflix 会选择两组订阅用户：一组接受排序算法 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 方法能在使用较少的线上资源和测试用户的情况下完成评估，这就是所谓的灵敏度比较。 即使与最灵敏的 A/B 测试指标相比，Interleaving 方法也只需 1% 的订阅用户样本就能确定用户更偏爱哪个算法的推荐结果。 利用一组 A/B 测试的资源，可做 100 组 Interleaving 方法的实验。
Interleaving 方法评估指标与传统 A/B 测试评估指标的相关性 除了能够利用小样本快速进行算法评估，Interleaving 方法的结果是否与 A/B 测试一致，也是验证 Interleaving 方法能否在线上评估阶段取代 A/B 测试的关键。 结果表明，二者的评估指标之间存在非常强的相关性，这就验证了在 Interleaving 方法的实验中胜出的算法也极有可能在之后的 A/B 测试中胜出。 但在 Interleaving 方法的实验中所展示的产品页面，并不是单独由算法 A 或者算法 B 生成的，而仅是实验用的混合页面。 要测试某个算法的真实效果，Interleaving 方法是无法完全替代 A/B 测试的。 希望得到更全面和真实的线上评估指标，A/B 测试仍是最权威的测试方法。
Interleaving 方法的优点是，所需样本少，测试速度快，结果与传统 A/B 测试无明显差异。 也存在局限性。
Netflix 设计了'Interleaving+A/B 测试'的两阶段实验结构，完善了整个线上测试的框架。
对公司来说，最公正合理的评估是线上评估，验证模型能否更好地达成公司或团队的商业目标。 为什么不能对所有的模型改进都进行线上评估，以确定改进的合理性？ 因为线上 A/B 测试要占用宝贵且有限的线上流量资源，还可能对用户体验造成影响，因此有限的线上评估机会，远不能满足算法工程师改进算法的需求。 线上评估往往持续几天甚至几周，这将大大延长算法迭代的时间。 线上评估种种限制，离线评估才成为算法工程师求其次的选择。 离线评估，可用近乎无限的离线计算资源，快速得出评估结果，快速实现模型的迭代优化。 在线上 A/B 测试和传统离线评估之间，还有 Replay、推荐系统模拟器、Interleaving 等评估方法。 Replay 方法，能模拟线上的模型更新过程，推荐系统模拟器，能最大限度地在离线状态下模拟线上环境，Interleaving 方法则可以快速建立线上评估环境。 这种多层级的评估方法，共同构成了完整的推荐系统评测体系，在评测效率和正确性之间达到平衡。 底层包含了大量待筛选的模型和待验证的改进想法。它们数量巨大，'评估效率'成为考虑的关键因素，对评估'正确性'的要求则没有那么苛刻，这时应该使用效率更高的离线评估方法。 随着候选模型被一层层筛选出来，在越接近正式上线的阶段，评估方法对评估'正确性'的要求就越严格。 模型正式上线前，应以最接近真实产品体验的 A/B 测试，进行最后的模型评估，等产生最具说服力的在线指标后，模型才能上线，完成模型改进的迭代过程。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
