其他
揭秘大模型技术在快手搜索的应用
本文整理自快手搜索部门技术专家许坤在 QCon 2024 北京的分享“大模型技术在快手搜索的应用”。演讲深入探讨了大模型技术在快手搜索领域的具体应用，重点介绍了多模态技术，尤其是多模态理解和生成方面的最新科研进展。
本文由 InfoQ 整理，经许坤老师授权发布。以下为演讲实录。
我们在去年 3 月底至 4 月初成立了一个联合项目组，致力于大模型技术的研发。到了 8 月份，我们发布了快手的第一个大模型，命名为快意大模型。
快意大模型目前有三个不同的规模版本，分别是 13B、66B 和 175B。在去年 8 月份的评估中，我们的模型已经达到了或者说接近 GPT-3.5 的性能水平。自那以后，我们团队在内部进行了大量的迭代和优化。特别是 175B 规模的模型，目前在很多场景中，特别是在中文场景下，表现已经超过了 GPT-4。这一进步已经被实际应用到了快手的多个具体产品中，实现了技术的落地和商业价值的转化。
快手大模型技术目前已经在多个领域进行了尝试和应用。以下是几个具体的落地实例：
AI 小快：用户在观看视频时可以通过 @AI 小快来提问有关视频理解的问题。我们的大模型会在评论区中对这些问题进行智能解答，提供用户所需的信息。
智能客服：通过大模型的强大能力，智能客服能够更精准地理解用户需求，并提供更加人性化的服务。
商家视频文案生成：这项服务使得我们的 ToB 用户能够更加便捷地创作文案和制作视频，提高了内容生成的效率和质量。
尽管短视频在视觉呈现上具有优势，但在某些场景下，如 how to 类查询或知识性问答，短视频内容繁多，用户需要观看完整视频才能找到答案，这实际上降低了搜索效率。此外，短视频是由人创作的，创作者与用户之间存在一定的鸿沟。在没有足够视频供给的情况下，我们希望大模型能够对用户的问题进行解答。以下是我们四个产品的具体形态：
GPT 卡片：当用户提出问题时，GPT 卡片会在搜索结果页面直接输出答案。例如，用户询问“桂花不开花是什么原因？”时，我们会利用 RAG 技术聚合视频和网页结果，直接呈现答案。
AI 搜：在某些问题没有索引或视频供给的情况下，AI 搜会利用大模型在线实时生成结果，弥补 GPT 卡片的不足。这也是一种漏斗逻辑，引导用户在看完 AI 搜后，如果有后续问题，进入多轮对话场景。
GPT 多轮对话：用户点击搜索框旁的 AI 图标后，会进入多轮对话场景。与 AI 搜相比，我们会重点放在多轮对话的理解上，并提供特定领域的能力，如文生图设计和朋友圈文案创作。
角色聊天：在上线这些产品后，我们发现许多用户除了知识获取需求外，还有与 AI 进行交流的需求，尤其是在深夜。
搜索智能问答的设计旨在提升搜索效率和补充搜索供给。
我们构建了一个框架，该框架以逻辑流程图的形式呈现。当用户提出一个查询，系统首先进行视频检索，这包括快手自有搜索流水线中的粗排、精排、个性化排序等步骤。在获取相关视频后，系统还会利用快手丰富的知识库资源对查询进行文档检索，检索到的结果将进行答案抽取，并使用生成式模型进行答案聚合。如果查询没有相关的索引资源，我们的基座模型将通过指令检索逻辑进行兜底。
在下图框架中，蓝色部分代表抽取式模型，而红色部分代表生成式模型。
框架中还加入了一个强化学习模块，该模块与传统的大模型训练中的 RLHF 或 DPU 有所不同。我们认识到，答案的呈现形式对用户体验有显著影响。
例如，有时我们希望答案以列表形式出现，有时是图文对，有时则可能是纯文字。强化学习模块的目标是教会模型以最合适的形式回答特定类型的问题。强化学习的信号通常基于用户看到结果后的后验行为，如停留时长、后续查询搜索等。这些信号将反向传递给模型，使模型在学习过程中既能满足用户需求，也能逐步提升用户体验。
通过这种方式，我们可以形成一个闭环，使模型能够每天在线自我迭代。
在开发过程中，我们面临了三个主要挑战。
大模型的幻象：早在三年前 GPT-1 出现时，学术界就对大模型的必要性存在分歧，分为两派，一派主张走符号推理（Symbolic Reasoning）路线，瞄准大模型幻象难以解决的痛点。现在，随着 ChatGPT 等模型的效果显著，大家开始集中研究如何检测大模型幻象。在实际应用中，我们希望有一个模型或模块能够告诉系统，大模型的输出存在问题。
低质索引资源影响答案准确率：在我们的系统中，落地时面临的一个严重问题是资源本身可能存在重复。例如，一个问题可能同时有正确和错误的答案，或者不同的人对同一答案的看法不同。我们如何对这些答案进行聚合，这是我们在研究中需要解决的问题。
Multi-Hop 事实类问题：这类问题在检索时通常无法直接找到答案，因为它们需要进行一定的推理。
尽管大模型有一些索引资源，我们已经对这些索引的质量进行了严格控制，但仍有少数低质资源可能进入最终的排序模块。
我们观察到，绝大多数正确答案通常能够得到足够多的索引资源的支持。基于这一发现，我们构建了一个图神经网络模型。该模型的工作机制如下：它从每个文档（doc）中抽取答案，并计算每个答案被其他文档支持的程度。同时，我们还会计算答案之间的相似度，然后利用整个图的模式来判断哪个答案最有可能是正确的。这是一个常规的解决方案，它在离线测试中表现出色。
我们在线实施了一个类似“source tree”的概念。逻辑是，面对一个复杂问题时，我们需要将这个问题拆解成多个子问题。为此，我们开发了一个模块来拆解问题。拆解后，我们会针对每一个子问题进行解答。当子问题得到正确解答时，我们会进一步探索答案，直到最终解决问题。如果某个子问题没有得到解答，我们会退回到问题的根节点，并寻找另一条路径。有时如果问题确实无法解答，我们也会接受这一现实。
自去年以来，随着 AI 技术的火爆以及国内资本市场的变化，我们观察到市场对角色聊天这一概念非常认可。用户不仅需要获取信息，他们的情感需求也同样重要，这正是我们需要提供的价值。我们的产品框架包含三个主要部分：
角色库：用户可以与所有已存在的角色进行聊天。
当前对话角色：用户与当前正在对话的角色进行互动。
角色发现：用户可以在发现页寻找他们可能感兴趣的新角色。
在角色聊天领域，我们面临一个基本问题，即如何将现有的语言模型升级为角色聊天模型。虽然整体方案没有变化，包含预训练、监督训练和强化学习模块，但每个阶段使用的数据类型有所不同。在角色聊天模型中，我们主要使用了剧本数据、对话数据和人人对话数据。与机构模型使用 3T 到 6T token 的数据量相比，角色聊天模型追求的是少而精，通常 100B 到 200B 的数据量就足够了。
在指定微调阶段，基座模型预训练阶段需要几百万到上千万的指定数据。而在角色聊天中，我们关注的是三类数据：
模型是否能理解角色的含义；
模型是否能理解场景的意义；
模型是否具备通用能力和多轮对话能力，尤其是长上下文的处理能力。
我们特别构造了不同角色间的场景对话能力，以及长上下文对话（long SFT）的数据。虽然在搜索场景中，很多人认为 DPU 没有太大作用，但在角色聊天中情况完全不同，因为高情商的回复与低情商的回复对用户体验的影响非常大。GPT-4 在这方面也无能为力，因为它提供的是更正式的回复，与角色聊天所需的口语化回复不同，常规使用 GPT-4 进行打标的方法在角色对话中并不适用。
因此，在强化学习阶段，我们进行了很多用户模拟器的开发，并结合人工标注进行对齐，以提升模型的情商和对话质量。
由于我们没有大量线上数据，即使有也不一定适用。因此，我们必须从冷启动阶段开始生成数据。我们会生成数万甚至数十万的角色，然后从这些角色中两两配对，并让 GPT-4 在给定场景下生成合理的对话。接下来，我们会进行简单的人工筛选，筛选出的数据将用于训练模型。有了这个基础模型后，我们将其上线。上线后，我们会为用户提供一个功能，允许他们自己创建角色。然后，我们会从用户创建的角色中获取数据，逐步更新原始的数据集。通过这样的多次迭代，我们最终能够达到一个比较理想的效果，使模型能够更好地理解和生成符合角色特性的对话。这个过程需要不断地收集用户反馈，优化数据集，并训练模型，以实现角色聊天功能的最佳表现。
众所周知，GPT 或 Transformer 这类模型框架在进行 NSP（Next Sentence Prediction）任务时，通常是预测下一个 token，这种预测往往依赖于局部信息，而不太涉及全局信息。为了增强模型的长上下文理解能力，我们采取了以下措施：
● 代码预训练：我们加入了代码预训练数据，这样做可以天然地增强模型对于远距离注意力（attention）的效果，从而提升模型对长上下文的理解。
● 线上长对话数据：我们利用线上的长对话数据，让 GPT-4 帮助我们进行标注，以识别出哪些回复可能与前文历史紧密相关。如果发现有相关性，我们会采用拒绝采样（reject sampling）的方式，通过人工挑选来构建长上下文对话训练数据。
● 增强上下文效果：利用特别构建的数据，我们进一步增强了模型的上下文效果，使其能够更好地理解和回应长对话中的上下文信息。
与大语言模型（LLM）相比，多模态模型主要增加了两种模态：语音和视觉（包括图像和视频）。目前常规的方案基本上是以大模型作为基础，通过一个项目将多模态特征映射到 LLM 中的固定数量的 token 上，然后进行建模。最终，根据需要输出图像或语音，只需选择不同的解码器（decoder）即可。
这样的大型模型存在一个显著问题，它们经常使用所谓的"model adapter"结构。在这种结构中，视觉特征或语音特征被固定（fix），然后整个模型的训练主要集中在训练这个 adapter 上。这种做法引发了一系列问题。
● 多模态作为 prompt 的弱点：在建模过程中，多模态输入通常被当作 prompt 使用，它与随后文本的交互天生较弱。这是因为目前大多数模型都采用仅解码（decode-only）框架，导致多模态输入与模型的交互不够充分。
● 任务复杂性：当前的任务，尤其是多模态任务，非常复杂。如果将模型的视觉特征抽取或 LLM 固定，那么 adapter 的训练潜力将非常有限。目前，adapter 主要采用 cross attention 的方式，这可能会严重限制整个模型的能力。
基于现有问题，我们提出了一个新的想法，即将视觉或语音视为一种外语，即另一种语言。
以 LLama 模型为例，我们的处理方式是相同的，不论是中文数据还是图像数据。我们希望将图像离散化，转换成 token，即"万物皆可 token"的理念。Token 化后的数据输入到基础模型中，对于基础模型而言，它们仅仅是一串 token，没有任何区别。这样做的好处在于我们可以随意交叉这些 token 的位置。
为了实现这一目标，我们设计了一个名为"Image Tokenizer"的组件，作用是将图像、视频或音频转换成一系列 token，然后输入到基础模型中。
我们选择使用 LLM 的原因是，LLM 已经将人类文字知识全部压缩在内，在基础之上进行推理、理解和生成任务时，它会具有天然的优势。与从头开始训练模型相比，使用 LLM 作为基础模型可以带来更好的效果，这是我们的基本动机。通过这种方式，我们可以更有效地处理多模态数据，并提升模型的整体性能。
我们最近有一篇论文被 ICLR 接收，论文的基本思想是，当我们处理图像时，首先将其转换成 token，与文本 Tokenizer 处理后的文本拼接在一起，然后输入到模型中。我们的模型名为 LaVIT，其输出的 loss 与语言模型相同，都是采用 ASP loss 预测下一个 token。
与之前方案的最大区别在于，我们将图像离散化，图像的每个 patch 都有一个独特的 ID，在语言模型中它就是一个语义 token，这样我们可以在 loss 上实现同质化处理。通过这种方式，无论是视频理解还是图像理解，只需将图像转换为 token 输入模型，然后让它解码成文字就可以将图像理解任务建模。
此外，我们还可以进行生成任务，比如给模型一张图片和一段文本，然后要求它输出图片。对模型来说这没有难度，因为它只是一系列 token 的输入和输出。唯一的区别在解码阶段，我们通常会选择使用 Stable Diffusion 或 DIT 等方法来进行解码，这种方法使我们能够更灵活地处理多模态数据，并在不同的任务中实现更好的性能。
我们的 Tokenizer 设计涉及离线预训练过程，这个过程不需要文本，只需要图像。图像输入后，我们会使用 VIT（Vision Transformer）作为特征提取器，将图像分割成若干个 patch。每个 patch 都有一个对应的 embedding。
在这个基础上，我们进行 KNN（K 最近邻）检索，将这些 patch 映射到一个 Codebook 中。这个 Codebook 可以理解为我们自然语言中的词汇表，其中包含了大约 1 万到 2 万个“词汇”。有了这些词汇后，我们可以将图像中的每个区域映射成一个词。然后，我们会对编码过程使用一个解码 loss，即要求模型能够恢复出原始图像，这是一个回归 loss，具体来说是均方误差（MSE）loss。
完成这个离线预训练过程后，我们将得到一个优秀的图像编码器和解码器。编码器的作用是将图像转换成一系列的 token，而解码器的作用是将这些 token 还原成图像。解码器的基础我们采用了 Stable Diffusion，并对其做了改进，实现了动态编码。
动态编码的动机其实很简单：在很多图像中，颜色可能非常相近，比如都是红色。我们不希望模型对这类图像使用过长的 token，因为这会使训练过程变得冗长。因此，我们引入了一个名为 token selector 的组件，它会在图像中选择它认为重要的 token 进行编码。
下图展示了视觉 Tokenizer 的效果：
左侧第一张图我们仅使用了 95 个 token，可以从图中观察到，因为有许多颜色是一致的，而右侧灰白部分表示我们没有选择对这些区域进行编码，我们保留的有颜色区域即是保留的 token，未保留的则是我们去掉的部分。
观察右侧的钓鱼图片，可以看到图像中包含的语义信息相当复杂，因此我们大约使用了 108 个 token 来表达。而下面那张鸟站在树上的图片，实际上只需要 79 个 token 就能够进行有效编码。
通过这种动态长度编码的方式，我们能够对图片进行更为高效的编码处理。这种编码方法在我们的模型中能够显著提升训练速度，大约可以提高 3 到 4 倍，从而使得整个模型的训练过程更加快速和高效。
图像编码完成后，接下来的步骤是将其映射到一个词表中。我们使用的是一个包含 16,000 个词汇的词表，每个词汇都代表了一个特定的含义。通过可视化，我们可以发现特定的编码，比如 13014，它代表的是人手臂的语义，而编码 2223 则学会了代表铁轨的语义。本质上，我们的过程是将图像拆解，然后进行语义聚类，之后将其与语言进行同步建模。
图像的处理也是类似的。我们把图像分解，将其中的每一部分映射到相应的语义上，并与语言的语义进行融合，输入到 LLM 中。通过这种方式，我们能够将图像和文本统一到同一个语义空间中，使得模型能够更好地理解和处理多模态数据。这种方法不仅提高了模型的效率，也增强了其处理复杂任务的能力。
完成图像编码和词表映射的工作后，我们进行了多种任务的尝试和应用。首先，我们实现了 Image Caption 和 Visual QA 任务。用户可以直接输入一张图片，然后大模型能够生成对图片内容的描述。例如，模型能够形容图片中的景象或物体。比如，用户可以上传一张图片并提出问题，比如询问图片中有多少只斑马，模型能够理解问题并回答出具体的数字，如“有三个斑马”。
在下面的图表中，我们展示了一些基准测试上的结果。这些结果是我们在去年 12 月份提交论文时的数据。当时，在多模态模型领域，BLIP-2 的效果被认为是最好的，如果大家对多模态模型有所了解，可能对这个模型会比较熟悉。然而，在我们的实验设置中，当我们使用相同规模的大约 7B 参数的基础模型时，我们的结果实际上远远超过了这个竞品。
我们的框架设计得非常通用，既可以处理图片理解任务，也可以进行图片生成。在图片生成方面，我们展示了一些效果，看起来也相当不错。坦白来讲，与当前非常受欢迎的 Mid Journey 和 Stable Diffusion 相比，我们的生成质量并不逊色。
我们进行了一项实验，目的是比较我们的方法与一个强有力的竞争对手 SDXl 在文本提示理解方面的差异。我们特别想知道，在采用 LLM 之后，我们是否能够更好地理解文本提示。
实验中，我们给出了一个文本提示，内容是：“桌子上有两个苹果，这两个苹果没有一个是红的，都是绿的。” 结果显示，SDXl 对这个提示的理解相对较弱，它生成的图像中既有红色的苹果也有绿色的苹果。而使用我们的方法，基于语义建模，生成的图像则非常好，准确地反映了文本提示的要求，即生成了两个都是绿色的苹果。
另一个例子是，文本提示描述了一只猫位于长椅下方的篮子里。SDXl 生成的图像在空间理解上表现不佳，因为它通常使用 CLIP 进行文本建模，与我们使用 LLM 的方法完全不同。相比之下，我们的模型明显在空间理解上做得更好，能够准确地描绘出猫在指定位置的场景。
我们展示了一些文本到图像（Text to Image）的结果，与我们的结果比较接近的是 Parti 的效果，在 FID（Fréchet Inception Distance，一种评估生成图像质量的指标）这个维度上非常接近。
我们的框架非常灵活，不仅可以支持从文本生成图像（文生图），还能处理图像生成文本（图生文）、以及图像加文本或图像加图像的组合（图加文加图）。
如果我们在左边给出一张猫的图片，然后在右边给出一个文本提示，比如说“这只猫在海滩上”，我们的模型就能够生成出一张猫在海滩上的图像。如果我们想让这只猫戴上眼镜，只需在文本提示中加入这一要求，模型同样能够生成出相应的效果。这是一个图像加文本输入的例子。
我们还可以进行图像和图像的输入组合。比如，如果我们将梵高的画作和猫的图片放在一起作为输入，模型能够生成出具有梵高风格的猫的图像。同样，如果我们将一只朋克风格的狗和猫的图片放在一起，模型就能生成出朋克风格的猫的图像。
我们还进行了一项更复杂的实验，即文加图加文加图加文，也就是三个文本和两个图像的组合。例如，假设我们说“这是一幅画”，然后给出一张狗的图片，并希望将这只狗以那幅画的风格呈现出来，我们的模型同样能够生成这样的图像。当然，如果你有更具体的特定需求，比如需要更多的文本描述，或者想要结合两张图片、三张图片以及文本作为输入，这也是可行的。
今年第一季度，我们开发了一个名为 Video-LaVIT 的框架，介绍一下它的基本思想。
在之前框架的基础上，我们进行了视频编码和解码的工作。目前，大家普遍知道 GPT 这样的框架属于较高级的结构。但在国内，许多人处理视频的方法是将其拆解成多帧，然后分别进行建模。另一种流行的方案是 Sora。
我们的工作始于 2 月 6 日，原本计划稍后再推出更新版本，但 Sora 的进展比我们快得多，并且效果显著。Sora 的方案考虑了 3D 方案，与单帧抽取方案相比，其 token 数量非常庞大。这会带来一个问题：如果有 100 万个 token，学习它们之间的 attention 关系将需要巨大的数据量和计算资源，这是我们所不具备的。
我们并没有选择 Sora 的方案，也没有选择单帧抽取方案，因为这样会丢失帧与帧之间的动作时序变化。最终，我们选择了一个从编解码领域借鉴的思路，这是一个折中的方案，旨在保留视频帧之间的时序信息，同时避免上述两种方案的缺点。
如果对视频编码有所了解，你就知道 H.264 方案，这是一个相对传统的标准。它的基本思想是在视频编码或压缩时，将语义信息单独压缩，特别是所谓的运动向量（Motion Vectors）。这个方案的核心思想是对视频中每一帧（patch）与下一帧之间的动作变化进行建模，而像素级别的变化则被正交解耦。我们不需要对每一帧都进行单独建模，也不需要像 Sora 方案那样创建一个非常复杂的 3D token。
我们的基本方案采用了关键帧加运动向量（key frame + motion vectors）的方法。简单来说，我们会从视频中提取关键帧，然后基于这些关键帧对后续动作进行运动向量建模。这样，我们就无需保留整个视频的所有关键帧，只需保留运动向量即可。同时，这种方法也不会丢失视频的时序信息。
基于这个概念，我们设计了一个编码 Tokenizer 和解码 Detokenizer，用于将视频编码并恢复成期望的视频效果。这种方法允许我们以更高效和节省资源的方式来处理视频数据，同时保留了视频内容的核心信息和动态变化。
我们的框架中新增了一个组件，称为 motion tokenizer，它的功能是将视频中的动作编码成 token，并将这些 token 输入到 Video-LaVIT 模型中。这个 motion tokenizer 的训练过程与 LaVIT 的训练过程非常相似，都是将向量通过语义编码转换成 token。具体来说，motion tokenizer 的训练方案与 LaVIT 相同，它使用 MSE loss 来进行训练，这是一个离线过程。与 LaVIT 不同的地方在于，motion tokenizer 的训练不需要文本对齐，它仅依赖视频本身即可完成训练。
我们还开发了一个解码器，目的是在视频预测阶段将关键帧和运动向量恢复成视频效果。为此，我们训练了一个名为 3D U-Net 的框架。简单来说，操作过程是将关键帧和运动向量输入到 3D U-Net 中，然后对其进行加噪处理，接着进行去噪，最终得到视频的输出效果。
在离线训练 Tokenizer 的过程中，我们首先对视频进行编码，然后再次解码，以检验视频信息是否能够被有效复原。尽管我们观察到复原视频的分辨率较低（仅为 520P），因此效果并不完美，但基本的语义信息已经通过模型学习到。
我们特别在两个任务上进行了重点评估。首先，我们对图像理解（image understanding）进行了评测，发现在现有的图像理解基准测试上，我们的效果是最佳的。其次，在视频理解方面，特别是在 ActivityNet-QA 数据集上，该数据集用于衡量视频中的动作，我们的效果显著优于现有所有工作。这是因为我们对 motion 的建模非常精准，而其他许多工作往往忽略了对运动的建模。
我们还尝试生成了较长的视频，用户只需输入一段文本或者提供一张图片，模型就能基于这张图片生成视频。在没有进行任何控制的情况下，视频的稳定性已经达到了一个相当不错的效果。这表明我们的模型在处理长视频生成任务时，即便在没有额外控制机制的情况下，也能够保持较高的稳定性和合理性。
我们制作了一个较长的视频，大约 10 秒左右。LLM 本身对输入长度没有太多限制，不过我们训练集中的大部分视频都在 6 秒左右。因为我们的训练集未曾见过更长的视频，这可能导致对后面关键帧的预测存在一些问题。但总体来说，生成的视频结果还是符合预期的。
我们的长视频是通过拼接多个几秒的视频片段来实现的。虽然与 Sora 相比，我们的效果还有一定差距，但个人认为这个差距可能不是由模型本身造成的，而可能是因为我们目前使用的数据还不够充分。我们没有使用任何闭源数据，也没有使用快手的数据，目前的效果是基于公开数据实现的。
我们的 Video-LaVIT 框架已经引起了包括 Stable Diffusion CTO 在内的一些业界人士的关注。大家对这个框架的优势有明确的认识。
与 Sora 相比，我们只需要其 1/10 的 token 即可进行建模。虽然 1/10 token 可能会在最终生成质量上带来一些损失，但它对视频的理解能力依然非常强。我们进行了一些评测，结果表明我们的效果可以与 Sora 相媲美。
众所周知，广告领域是视频生成的一个非常重要的应用场景，包括在快手内部，我们也进行了一些广告生成的尝试。这些广告通常时长大约在 10 到 15 秒之间，这正好是我们的文生视频模型能够充分发挥作用的场景。因此，我们的模型在广告制作和视频内容生成方面具有巨大的潜力和应用价值。
华为盘古 5.0 强势登场：参数跃升万亿级，理解能力突破至感应 level，团队亲述幕后黑科技！月之暗面被曝进军美国，产品、人才筹备中！阿里腾讯捧出的30亿美元独角兽终于要出海了
Ilya 官宣新公司，主打“恶意”竞争！先拉不缺钱的技术大佬入伙，不盈利也要赢过 OpenAI ！
联创用ChatGPT写的一行代码让公司损失上万美元！网友：老板自己写的，找不到人背锅了
Runway 全新 Gen-3 视频生成模型获网友盛赞：比 Sora 更好