大家好，我是施兴（花名叔宝），来自阿里云机器学习平台 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 链路和上传数据变得非常方便，还可以直接进行交互测试。