大家好,我是施兴(花名叔宝),来自阿里云机器学习平台 PAI,主要负责产品架构。我们团队主要负责:①搜索推荐,这是我们较为成熟的一个领域;②涉及图像和视频多模态处理,如图像视频打标和 Stable Diffusion 文生图,文生视频等相关工作;③在大模型场景下,阿里有通义系列大模型,我们负责通义的底层平台及相关训练推理优化工作;④进行 RAG 工程链路搭建和大模型评测,包括使用大模型评测大模型。
今天介绍从大数据到大模型过程中,我们的大数据平台建设,以及如何在大数据场景下应用大模型的能力。分享内容分为三大块:一是搜索推荐广告的技术架构;二是在搜索推荐场景中的工程和算法实践;三是结合大模型的一些探索及相关工程产出。
这是较为成熟的搜索推荐广告技术架构,大厂都在使用,未来更偏向实时应用。简单解释一下架构:用户打开淘宝、天猫等 APP 或网站,展示的信息流是推荐系统。用户操作时,后端系统会发请求,决定推荐什么内容。曝光请求发送给后端的业务引擎和 A/B 系统,它们决定哪些数据进行召回、粗排、精排等操作,并通过 A/B 引擎进行分流。各大厂的算法工程师一直在提升模型和算法效果,提高点击率和购买率,这些都是通过 A/B 系统进行分流。实际的召回、排序在后面的引擎端进行。
用户在线操作数据会被存储并落入实时计算层,如 Flink 的实时标准会进行窗口函数计算,生成实时特征和样本,这些数据会沉淀到离线大数据处理平台。离线平台准备 day 级别样本和特征,通过 AI 平台训练,生成特征(比如 Embedding 特征)和模型,模型用于线上推理服务。这就是整个流程。
为了支持复杂的推荐链路,阿里云的技术架构如下:最底层是资源层,包含 CPU、GPU 等各类硬件。通过集群调度能力,把算力往外输出,例如 ODPS 飞天集群,阿里云的容器化服务,以及灵骏智能计算集群。灵骏智能计算集群主要面向大模型时代,满足高性能算力需求。
底层有大量高性能的异构计算资源,如众所周知的 GPU,包括英伟达以及其他厂家提供的 GPU。还有高性能网络来支撑,因为大模型训练需要几千张卡,这就需要保证卡之间的通信是高带宽低延时,因此需要高性能 RDMA 网络。另外,为了快速读取样本,还需要高性能的存储,否则就会浪费大量 GPU。这就是我们最底层的资源调度层,再上一层是“大数据+ AI”一体化的 PaaS 平台。
大数据和 AI 的 PaaS 平台主要分为几部分:实时和离线一体化的大数据平台,包括 MaxCompute 和 Hologres。MaxCompute 对标开源的 Hadoop,而 Hologre 可以简单理解为类似 Redis 的实时 OLAP 分析工具。Flink 用于实时计算流,EMR(Elastic MapReduce)则是阿里云上对标的开源大数据平台。
在大数据平台进行数据处理后,通过 AI 平台提供多种功能。AI 平台主要包括数据标注(PAI-iTAG)、数据清洗、特征平台(FeatureStore)等。有了这些数据后,可以进行代码开发,包括交互式开发(PAI-DSW)和可视化开发(PAI-Designer)。开发好的代码需要在数百台服务器上进行分布式训练,因此有模型训练(PAI-DLC)模块。为了提高训练效率,提供数据集加速(DataSetAcc)、网络通信优化、算子优化和硬件并行加速等功能。训练完成后,通过 PAI-EAS 平台提供模型服务。这就是我们大数据和 AI 的 PaaS 层能力。
在大数据和 AI 平台上,百炼模型服务平台是面向开发者的大模型开发平台。百炼整合了达摩院通义实验室的多项大模型能力,如图像处理的通义-万相、语音识别的通义-听悟,以及文本处理的通义-千问。此外,还包括了开源社区 ModelScope,供开发者共享和下载模型。在此之上,平台支持智能推荐、开放搜索和广告用户增长等多个场景,其他还包括传统电子商务和智慧医疗等,形成了一个全面的平台架构体系。
特征平台(FeatureStore)是一个结构化大数据管理和共享平台,用于存储、组织、管理机器学习和 AI 训练中使用的特征数据。传统上,每个算法工程师处理自己的特征表,没有一个统一的平台来共享这些特征。而 FeatureStore 平台支持数据从离线平台如 Hadoop 的 HDFS 和 MaxCompute 同步到 Hologres、TableStore、FeatureDB 等一些在线平台,并保证数据一致性。
在推荐搜索算法开发中,经常会遇到离线训练模型效果好,但在线服务时效果不一致的问题。为此,我们通过云上推荐解决方案型产品 PAI-REC,保证了数据的离线和在线一致性。另外,线上特征服务也保证了稳定性,并添加了生产队列监控,如实时监控 RT/QPS 变化,以及实时特征的写入请求队列是否存在风险和堆积等。
在大模型(多模态)时代,Embedding 特征是必不可少的,如搜索推荐的 user/item 特征,这些特征可以在 FeatureStore 平台统一管理。有了这些原始特征,需要思考如何高效开发特征生产工作。因此,我们开发了一些基础的特征生产功能,便于特征的二次加工和生成更多的特征。
在性能上,FeatureStore 平台是为了模型推理时能在线上直接提供特征访问服务。但在某些情况下,如搜索推广场景,整个端到端的请求需要在一两百毫秒内完成,如果跨网络获取特征会导致延时,因此需要在每个环节都做到极致。为了加速特征获取的速度,我们采取了一个优化策略,即预先将数据拉到本地,利用本地内存换取时间。这也是大家在日常工作中可以参考的一个优化点。具体的流程如右边的图所示,这里就不详细展开了。
FeatureStore 平台还支持特征血缘功能。在分析特征时,如果算法工程师发现特征存在问题,需要知道该特征是从哪些源表生成,以及被谁使用。这种血缘关系在结构化数据中极为关键,如果最后的结果出错,需要找出问题所在。这需要数据工程师或算法工程师投入大量精力去追踪。而有了血缘图,我们可以一眼就看出该字段是从哪些表中来,又被用在哪里,以及最后服务于哪些模型,这就是特征血缘功能的作用。
在推荐搜索算法中,我们发现每个客户会实现一些如 DeepFM 的经典算法。然而,这意味着每个客户需要一套自己的 DeepFM 代码,这增加了开发工作量。因此,我们建立了 EasyRec 推荐算法库,方便开发人员使用不同的计算资源,如 MaxCompute、Hadoop、Spark 等,甚至可以在本地设备上运行。EasyRec 支持多种数据源,如阿里云的 OSS、MaxCompute 或者 HDFS、Hive 等;还提供了 FeatureGenerator 功能,只要配置文件一样,能确保离线训练和在线推理的计算逻辑一致,避免引入误差。EasyRec 集成了针对实际应用场景的有效算法;EasyRec 还支持自动调参(AutoML-HPO)、特征自动生成(Auto Feature)、特征自动选择(Feature Selection)、模型蒸馏(Distill)、训练加速优化、离线评估以及 Early Stop 等功能,帮助算法工程师减少开发工作量。
随着大模型和 user/item Embedding 的引入,为了追求更佳的推荐搜索效果,模型特征和网络结构越来越复杂。原本数百维的特征膨胀到数千甚至上万维,其中包含大量交叉特征。对应的 Embedding 日益庞大,由数十 G 扩展到上百 G 甚至 T 级别,以期获取更强的表征能力。此外,行为序列(Sequence)长度也从原本的 50个行为扩展到上万个长度。这样的复杂性带来挑战:追求更好效果的同时,训练的资源需求和速度要求不断增加,算力严重不足。然而,复杂的推理过程也导致推理延时增加,而推理是实时请求过程,因此推理超时严重是一个急需解决的问题。
在搜索推荐广告场景下,我们对训练和推理进行了两大方向的优化。
在训练优化上,①多级缓存和特征自动淘汰:引入特征的自动准入和淘汰机制,实时或离线训练中低频度特征会被淘汰,减少计算资源和显存的占用。②WorkQueue 模式:将训练数据变成队列,解决不同服务器和显卡处理速度不一致的问题,通过生产者-消费者模式提高计算效率。③特征选择与知识蒸馏:优化特征和模型结构。④通信优化:通过单机融合和流水并行减少通信量,提升效率。⑤硬件加速:与阿里云、英特尔、英伟达合作,使用 AVX/AMX 矩阵加速、AllReduce 同步训练、SOK 合作以及 Embedding 增量更新,进行实时增量模型训练。
在推理优化上,①AVX/AMX 加速:在 CPU 上加速 embedding_lookup 和 string_split。②量化加速:在 GPU 上引入 bf16+int8 量化,减少计算耗时。③AutoPlacement:在 CPU 和 GPU 之间自动高效地分配算子。④SessionGroup:利用 GPU 的 multi stream 特性加速计算。⑤特征缓存:针对推荐场景进行特征缓存优化。我们在电商场景的真实客户中,通过这些优化使 QPS 提升到原生 TF-Serving 的四倍左右。
这是整个推理引擎的数据链路或架构图。重点在于右侧的推理链路,包括 Feature Cache 和 Feature Generator。①Feature Cache:处理离线和实时特征,缓存后进行更新和分级存储。由于 embedding 达到百 GB 甚至 TB 级别,完全放在内存中不可行,因此需要多级缓存。②Feature Generator:在获取特征后,利用 Feature Generator 进行共享和计算,最后交给模型处理。最下面的图示,展示了实时特征和离线特征的计算过程,以及增量模型的更新方式。
接下来介绍我们在与合作伙伴合作中,发现的搜索推荐领域一些大语言模型带来的新场景。①电商导购,传统 query 方式无法精准输出结果,而大语言模型能助力用户选品、直播答疑,提供商品售前咨询和售后服务。②内容推荐,如用户想购买特定商品或解决某个问题,大语言模型可以给出内容推荐。③企业知识库,每家企业都有内部文档库,新员工可通过 AI 机器人快速学习公司内部知识,而不必依赖老员工手把手指导。④教育搜题,大语言模型在教育领域也有应用,如搜题生成答案和知识总结。这些都是客户在尝试的一些 LLM 新场景。
在搜推广场景的实践中,经典的搜推广通常由数据驱动。例如,淘宝利用用户行为和商品数据构建推荐模型,知乎则使用用户与内容的数据进行推荐。这种方法往往是领域内的数据建模,淘宝无法回答知乎的问题,知乎也无法处理淘宝的商品推荐。这导致信息茧房,推荐内容局限于内部数据,无法回答通用问题。
此外,还涉及用户和商品的冷启动问题。对于新用户,没有任何行为数据,只能采用经典冷启动方法。同样,新商品发布后,由于没有历史数据,很难快速曝光。而且推荐的多样性不够,无法跨领域推荐。
反观通用 LLM,其知识面广泛,能够回答各种问题,并且知识表达能力丰富。然而,LLM 缺乏推荐广告领域的专有数据,也不具备序列记忆能力,无法有效处理用户的长期行为记录。最关键的是,大模型在推荐场景中性能复杂度很高,推理成本也很大。
业界通常有两种处理方式。左边这种是将推荐场景与大语言模型(LLM)结合,利用 LLM 丰富的知识表达,将其 embedding 作为特征进行融合,然后进行在线模型服务。右边是直接使用 LLM,将专业领域数据输入 LLM,让其进行推荐。这包括直接对大模型进行 fine-tuning,以及 RAG 场景。然而,直接使用 LLM 进行推荐搜索,会带来较高的训练推理成本,同时还需要解决数据稀疏和冷启动问题。因此,当前主流方法还是上图中左边这种。
我们在阿里内部的淘宝天猫上积累了一些经验,特别是在 Prompt Engineering 方面。第一个实践是使用 LLM 进行类目搭配推荐,因为 LLM 具有大量的领域外知识。例如,如果你给它一个类目名称“手机”,它会推荐手机壳、耳机、数据线、手机膜等相关类目。这是 LLM 利用其通用能力的一种体现。通过 Prompt 模板,给 LLM 一个类目名,它就会帮助生成相关的类目。但这些生成的类目在真正用于线上时,还需要转化为实际的线上类目 ID。这是一个常见的应用场景。
第二个应用场景是广告搜索中的 query 改写。例如,对于 query“生娃送什么”,直接搜索难以找到具体商品,传统的 query 改写会将其改写为“儿童礼物”。而对于“买一块可以在草地上铺的布”,被误解为“摆盘装饰”。这就是广告组买关键词时遇到的问题,如“满月礼物”或“野餐垫”。
query 改写效果不好会导致两个主要问题。一是改写后的 query 匹配不到广告主的关键词,导致在召回阶段就被淘汰。二是无法匹配到高价流量的精确需求,会浪费部分高价流量。比如,广告主买了“儿童礼物”,但实际搜索的是“满月礼物”。这些问题背后的主要技术原因是,传统的方法对于长搜索词的语义理解能力有限,且在语义相关的改写词覆盖上也比较有限。
我们在利用 LLM 进行 Prompt Engineering 时做了一些尝试。LLM 具有举一反三的能力,可以告诉 LLM 一个词,然后生成几个相关的词。例如,返回“华为手机”5 个电商近义词,保证搜索词品牌和类别与“华为手机”一致,LLM 可以生成“华为智能手机”、“华为”、“智能手机”、“华为畅享”、“华为 Mate”。再如,返回“新款高腰微喇裤深蓝色”5 个电商近义词,LLM 输出“高腰”、“微喇裤”、“深蓝色”、“时尚”、“修身”。
一种更好的方法是使用同类目、同方向的相似 query 引导模型输出。例如,把前两个 query“华为手机”与“厨房置物架”替换成“七分夏裤”与“女白色裤”,引导LLM 输出第三个 query,生成的“高腰微喇裤”、“深蓝色新款”、“深蓝色裤”、“高腰裤”、“微喇裤”更贴近实际需求。这种方法在实际使用中效果更好,能快速应用于日常工作。
最后一个场景是在 RAG 上的探索,结合企业客户使用大模型的实践。企业有大量知识库,这些知识库文档需要分片并转化为向量,存储在向量数据库中。目前的向量数据库有 ElasticSearch、Hologres、Milvus 等。在线请求时,用户提问通过 embedding 模型转化为向量,然后在向量数据库中检索,相似度检索结果取出 Top-K 后交给 LLM,提供上下文背景,构建 Prompt,最终生成回答。
开源项目 PAI-RAG 将 RAG 链路过程中的各个环节进行模块化设计。整体过程抽象成文档抽取(Document Extraction)、索引建立(Indexing)、Pre-Retrieval(query 改写在此阶段)、Retrieval、Post-Retrieval、Generation、Evaluation 等。如何排序检索出来的结果,如何让有效的文档排在前面,或者对所有检索出的文档进行总结,以更有效地引导 LLM 生成,最后再进行评估,形成一个完整的 RAG 链路流程。我们目前的主要工作是使 RAG 工程链路变得更方便适配各种场景。比如,如果数据不是 PDF 或 Word,而是 PPT,能很方便添加读取 PPT 文件的功能。对于 Query React,可以轻松地进行二次开发加工等。
PAI-RAG 主要支持的数据类型包括多模态数据、文档的结构化表示、embedding 模型的优化等。我们集成了 OCR 功能,并考虑了文档的层级结构,支持 PDF 和 Word 等多模态的文件,包括文件中的截图。当 Embedding 模型效果不佳时,使用第三方的大模型来丰富知识库,自动生成文档扩充此功能。
使用类似的思想来生成评估集,这对于构建 RAG 链路的企业来说非常有用。它们通常有很多文档,但没有准备很多问题来测试 RAG 的效果。我们使用大模型 RefGPT(不是我们独创)生成评估集。此外,还支持关键字检索和混合检索。
我们的工作还包括①评估大语言模型的优劣,比如把人工评估的工作交给另一个大模型;②支持各种量化指标,如命中率、准确率等;③在回答的质量上,考虑了正确性、语义相似度、忠实性、答案的上下文相关性等多个维度。
这是我们在 PAI 模块化 RAG 中的一个示例图,并使用 Gradio 编写的前端,使得配置 RAG 链路和上传数据变得非常方便,还可以直接进行交互测试。