大家好，我是施興（花名叔寶），來自阿里云機器學習平臺 PAI，主要負責產(chǎn)品架構(gòu)。我們團隊主要負責：①搜索推薦，這是我們較為成熟的一個領(lǐng)域；②涉及圖像和視頻多模態(tài)處理，如圖像視頻打標和 Stable Diffusion 文生圖，文生視頻等相關(guān)工作；③在大模型場景下，阿里有通義系列大模型，我們負責通義的底層平臺及相關(guān)訓練推理優(yōu)化工作；④進行 RAG 工程鏈路搭建和大模型評測，包括使用大模型評測大模型。

今天介紹從大數(shù)據(jù)到大模型過程中，我們的大數(shù)據(jù)平臺建設(shè)，以及如何在大數(shù)據(jù)場景下應(yīng)用大模型的能力。分享內(nèi)容分為三大塊：一是搜索推薦廣告的技術(shù)架構(gòu)；二是在搜索推薦場景中的工程和算法實踐；三是結(jié)合大模型的一些探索及相關(guān)工程產(chǎn)出。

這是較為成熟的搜索推薦廣告技術(shù)架構(gòu)，大廠都在使用，未來更偏向?qū)崟r應(yīng)用。簡單解釋一下架構(gòu)：用戶打開淘寶、天貓等 APP 或網(wǎng)站，展示的信息流是推薦系統(tǒng)。用戶操作時，后端系統(tǒng)會發(fā)請求，決定推薦什么內(nèi)容。曝光請求發(fā)送給后端的業(yè)務(wù)引擎和 A/B 系統(tǒng)，它們決定哪些數(shù)據(jù)進行召回、粗排、精排等操作，并通過 A/B 引擎進行分流。各大廠的算法工程師一直在提升模型和算法效果，提高點擊率和購買率，這些都是通過 A/B 系統(tǒng)進行分流。實際的召回、排序在后面的引擎端進行。

模型服務(wù)端有很多模型，如大家熟知的 DeepFM、FM 等。模型推理需要數(shù)據(jù)，數(shù)據(jù)來源一是特征平臺存儲用戶歷史和最近行為數(shù)據(jù)，二是商品特征數(shù)據(jù)，如價格、銷量、點擊量等。

用戶在線操作數(shù)據(jù)會被存儲并落入實時計算層，如 Flink 的實時標準會進行窗口函數(shù)計算，生成實時特征和樣本，這些數(shù)據(jù)會沉淀到離線大數(shù)據(jù)處理平臺。離線平臺準備 day 級別樣本和特征，通過 AI 平臺訓練，生成特征（比如 Embedding 特征）和模型，模型用于線上推理服務(wù)。這就是整個流程。

為了支持復(fù)雜的推薦鏈路，阿里云的技術(shù)架構(gòu)如下：最底層是資源層，包含 CPU、GPU 等各類硬件。通過集群調(diào)度能力，把算力往外輸出，例如 ODPS 飛天集群，阿里云的容器化服務(wù)，以及靈駿智能計算集群。靈駿智能計算集群主要面向大模型時代，滿足高性能算力需求。

底層有大量高性能的異構(gòu)計算資源，如眾所周知的 GPU，包括英偉達以及其他廠家提供的 GPU。還有高性能網(wǎng)絡(luò)來支撐，因為大模型訓練需要幾千張卡，這就需要保證卡之間的通信是高帶寬低延時，因此需要高性能 RDMA 網(wǎng)絡(luò)。另外，為了快速讀取樣本，還需要高性能的存儲，否則就會浪費大量 GPU。這就是我們最底層的資源調(diào)度層，再上一層是“大數(shù)據(jù)+ AI”一體化的 PaaS 平臺。

大數(shù)據(jù)和 AI 的 PaaS 平臺主要分為幾部分：實時和離線一體化的大數(shù)據(jù)平臺，包括 MaxCompute 和 Hologres。MaxCompute 對標開源的 Hadoop，而 Hologre 可以簡單理解為類似 Redis 的實時 OLAP 分析工具。Flink 用于實時計算流，EMR（Elastic MapReduce）則是阿里云上對標的開源大數(shù)據(jù)平臺。

在大數(shù)據(jù)平臺進行數(shù)據(jù)處理后，通過 AI 平臺提供多種功能。AI 平臺主要包括數(shù)據(jù)標注（PAI-iTAG）、數(shù)據(jù)清洗、特征平臺（FeatureStore）等。有了這些數(shù)據(jù)后，可以進行代碼開發(fā)，包括交互式開發(fā)（PAI-DSW）和可視化開發(fā)（PAI-Designer）。開發(fā)好的代碼需要在數(shù)百臺服務(wù)器上進行分布式訓練，因此有模型訓練（PAI-DLC）模塊。為了提高訓練效率，提供數(shù)據(jù)集加速（DataSetAcc）、網(wǎng)絡(luò)通信優(yōu)化、算子優(yōu)化和硬件并行加速等功能。訓練完成后，通過 PAI-EAS 平臺提供模型服務(wù)。這就是我們大數(shù)據(jù)和 AI 的 PaaS 層能力。

在大數(shù)據(jù)和 AI 平臺上，百煉模型服務(wù)平臺是面向開發(fā)者的大模型開發(fā)平臺。百煉整合了達摩院通義實驗室的多項大模型能力，如圖像處理的通義-萬相、語音識別的通義-聽悟，以及文本處理的通義-千問。此外，還包括了開源社區(qū) ModelScope，供開發(fā)者共享和下載模型。在此之上，平臺支持智能推薦、開放搜索和廣告用戶增長等多個場景，其他還包括傳統(tǒng)電子商務(wù)和智慧醫(yī)療等，形成了一個全面的平臺架構(gòu)體系。

特征平臺（FeatureStore）是一個結(jié)構(gòu)化大數(shù)據(jù)管理和共享平臺，用于存儲、組織、管理機器學習和 AI 訓練中使用的特征數(shù)據(jù)。傳統(tǒng)上，每個算法工程師處理自己的特征表，沒有一個統(tǒng)一的平臺來共享這些特征。而 FeatureStore 平臺支持數(shù)據(jù)從離線平臺如 Hadoop 的 HDFS 和 MaxCompute 同步到 Hologres、TableStore、FeatureDB 等一些在線平臺，并保證數(shù)據(jù)一致性。

在推薦搜索算法開發(fā)中，經(jīng)常會遇到離線訓練模型效果好，但在線服務(wù)時效果不一致的問題。為此，我們通過云上推薦解決方案型產(chǎn)品 PAI-REC，保證了數(shù)據(jù)的離線和在線一致性。另外，線上特征服務(wù)也保證了穩(wěn)定性，并添加了生產(chǎn)隊列監(jiān)控，如實時監(jiān)控 RT/QPS 變化，以及實時特征的寫入請求隊列是否存在風險和堆積等。

在大模型（多模態(tài)）時代，Embedding 特征是必不可少的，如搜索推薦的 user/item 特征，這些特征可以在 FeatureStore 平臺統(tǒng)一管理。有了這些原始特征，需要思考如何高效開發(fā)特征生產(chǎn)工作。因此，我們開發(fā)了一些基礎(chǔ)的特征生產(chǎn)功能，便于特征的二次加工和生成更多的特征。

在性能上，F(xiàn)eatureStore 平臺是為了模型推理時能在線上直接提供特征訪問服務(wù)。但在某些情況下，如搜索推廣場景，整個端到端的請求需要在一兩百毫秒內(nèi)完成，如果跨網(wǎng)絡(luò)獲取特征會導(dǎo)致延時，因此需要在每個環(huán)節(jié)都做到極致。為了加速特征獲取的速度，我們采取了一個優(yōu)化策略，即預(yù)先將數(shù)據(jù)拉到本地，利用本地內(nèi)存換取時間。這也是大家在日常工作中可以參考的一個優(yōu)化點。具體的流程如右邊的圖所示，這里就不詳細展開了。

FeatureStore 平臺還支持特征血緣功能。在分析特征時，如果算法工程師發(fā)現(xiàn)特征存在問題，需要知道該特征是從哪些源表生成，以及被誰使用。這種血緣關(guān)系在結(jié)構(gòu)化數(shù)據(jù)中極為關(guān)鍵，如果最后的結(jié)果出錯，需要找出問題所在。這需要數(shù)據(jù)工程師或算法工程師投入大量精力去追蹤。而有了血緣圖，我們可以一眼就看出該字段是從哪些表中來，又被用在哪里，以及最后服務(wù)于哪些模型，這就是特征血緣功能的作用。

在推薦搜索算法中，我們發(fā)現(xiàn)每個客戶會實現(xiàn)一些如 DeepFM 的經(jīng)典算法。然而，這意味著每個客戶需要一套自己的 DeepFM 代碼，這增加了開發(fā)工作量。因此，我們建立了 EasyRec 推薦算法庫，方便開發(fā)人員使用不同的計算資源，如 MaxCompute、Hadoop、Spark 等，甚至可以在本地設(shè)備上運行。EasyRec 支持多種數(shù)據(jù)源，如阿里云的 OSS、MaxCompute 或者 HDFS、Hive 等；還提供了 FeatureGenerator 功能，只要配置文件一樣，能確保離線訓練和在線推理的計算邏輯一致，避免引入誤差。EasyRec 集成了針對實際應(yīng)用場景的有效算法；EasyRec 還支持自動調(diào)參（AutoML-HPO）、特征自動生成（Auto Feature）、特征自動選擇（Feature Selection）、模型蒸餾（Distill）、訓練加速優(yōu)化、離線評估以及 Early Stop 等功能，幫助算法工程師減少開發(fā)工作量。

隨著大模型和 user/item Embedding 的引入，為了追求更佳的推薦搜索效果，模型特征和網(wǎng)絡(luò)結(jié)構(gòu)越來越復(fù)雜。原本數(shù)百維的特征膨脹到數(shù)千甚至上萬維，其中包含大量交叉特征。對應(yīng)的 Embedding 日益龐大，由數(shù)十 G 擴展到上百 G 甚至 T 級別，以期獲取更強的表征能力。此外，行為序列（Sequence）長度也從原本的 50 個行為擴展到上萬個長度。這樣的復(fù)雜性帶來挑戰(zhàn)：追求更好效果的同時，訓練的資源需求和速度要求不斷增加，算力嚴重不足。然而，復(fù)雜的推理過程也導(dǎo)致推理延時增加，而推理是實時請求過程，因此推理超時嚴重是一個急需解決的問題。

在搜索推薦廣告場景下，我們對訓練和推理進行了兩大方向的優(yōu)化。

在訓練優(yōu)化上，①多級緩存和特征自動淘汰：引入特征的自動準入和淘汰機制，實時或離線訓練中低頻度特征會被淘汰，減少計算資源和顯存的占用。②WorkQueue 模式：將訓練數(shù)據(jù)變成隊列，解決不同服務(wù)器和顯卡處理速度不一致的問題，通過生產(chǎn)者-消費者模式提高計算效率。③特征選擇與知識蒸餾：優(yōu)化特征和模型結(jié)構(gòu)。④通信優(yōu)化：通過單機融合和流水并行減少通信量，提升效率。⑤硬件加速：與阿里云、英特爾、英偉達合作，使用 AVX/AMX 矩陣加速、AllReduce 同步訓練、SOK 合作以及 Embedding 增量更新，進行實時增量模型訓練。

在推理優(yōu)化上，①AVX/AMX 加速：在 CPU 上加速 embedding_lookup 和 string_split。②量化加速：在 GPU 上引入 bf16+int8 量化，減少計算耗時。③AutoPlacement：在 CPU 和 GPU 之間自動高效地分配算子。④SessionGroup：利用 GPU 的 multi stream 特性加速計算。⑤特征緩存：針對推薦場景進行特征緩存優(yōu)化。我們在電商場景的真實客戶中，通過這些優(yōu)化使 QPS 提升到原生 TF-Serving 的四倍左右。

這是整個推理引擎的數(shù)據(jù)鏈路或架構(gòu)圖。重點在于右側(cè)的推理鏈路，包括 Feature Cache 和 Feature Generator。①Feature Cache：處理離線和實時特征，緩存后進行更新和分級存儲。由于 embedding 達到百 GB 甚至 TB 級別，完全放在內(nèi)存中不可行，因此需要多級緩存。②Feature Generator：在獲取特征后，利用 Feature Generator 進行共享和計算，最后交給模型處理。最下面的圖示，展示了實時特征和離線特征的計算過程，以及增量模型的更新方式。

接下來介紹我們在與合作伙伴合作中，發(fā)現(xiàn)的搜索推薦領(lǐng)域一些大語言模型帶來的新場景。①電商導(dǎo)購，傳統(tǒng) query 方式無法精準輸出結(jié)果，而大語言模型能助力用戶選品、直播答疑，提供商品售前咨詢和售后服務(wù)。②內(nèi)容推薦，如用戶想購買特定商品或解決某個問題，大語言模型可以給出內(nèi)容推薦。③企業(yè)知識庫，每家企業(yè)都有內(nèi)部文檔庫，新員工可通過 AI 機器人快速學習公司內(nèi)部知識，而不必依賴老員工手把手指導(dǎo)。④教育搜題，大語言模型在教育領(lǐng)域也有應(yīng)用，如搜題生成答案和知識總結(jié)。這些都是客戶在嘗試的一些 LLM 新場景。

在搜推廣場景的實踐中，經(jīng)典的搜推廣通常由數(shù)據(jù)驅(qū)動。例如，淘寶利用用戶行為和商品數(shù)據(jù)構(gòu)建推薦模型，知乎則使用用戶與內(nèi)容的數(shù)據(jù)進行推薦。這種方法往往是領(lǐng)域內(nèi)的數(shù)據(jù)建模，淘寶無法回答知乎的問題，知乎也無法處理淘寶的商品推薦。這導(dǎo)致信息繭房，推薦內(nèi)容局限于內(nèi)部數(shù)據(jù)，無法回答通用問題。

此外，還涉及用戶和商品的冷啟動問題。對于新用戶，沒有任何行為數(shù)據(jù)，只能采用經(jīng)典冷啟動方法。同樣，新商品發(fā)布后，由于沒有歷史數(shù)據(jù)，很難快速曝光。而且推薦的多樣性不夠，無法跨領(lǐng)域推薦。

反觀通用 LLM，其知識面廣泛，能夠回答各種問題，并且知識表達能力豐富。然而，LLM 缺乏推薦廣告領(lǐng)域的專有數(shù)據(jù)，也不具備序列記憶能力，無法有效處理用戶的長期行為記錄。最關(guān)鍵的是，大模型在推薦場景中性能復(fù)雜度很高，推理成本也很大。

業(yè)界通常有兩種處理方式。左邊這種是將推薦場景與大語言模型（LLM）結(jié)合，利用 LLM 豐富的知識表達，將其 embedding 作為特征進行融合，然后進行在線模型服務(wù)。右邊是直接使用 LLM，將專業(yè)領(lǐng)域數(shù)據(jù)輸入 LLM，讓其進行推薦。這包括直接對大模型進行 fine-tuning，以及 RAG 場景。然而，直接使用 LLM 進行推薦搜索，會帶來較高的訓練推理成本，同時還需要解決數(shù)據(jù)稀疏和冷啟動問題。因此，當前主流方法還是上圖中左邊這種。

我們在阿里內(nèi)部的淘寶天貓上積累了一些經(jīng)驗，特別是在 Prompt Engineering 方面。第一個實踐是使用 LLM 進行類目搭配推薦，因為 LLM 具有大量的領(lǐng)域外知識。例如，如果你給它一個類目名稱“手機”，它會推薦手機殼、耳機、數(shù)據(jù)線、手機膜等相關(guān)類目。這是 LLM 利用其通用能力的一種體現(xiàn)。通過 Prompt 模板，給 LLM 一個類目名，它就會幫助生成相關(guān)的類目。但這些生成的類目在真正用于線上時，還需要轉(zhuǎn)化為實際的線上類目 ID。這是一個常見的應(yīng)用場景。

第二個應(yīng)用場景是廣告搜索中的 query 改寫。例如，對于 query“生娃送什么”，直接搜索難以找到具體商品，傳統(tǒng)的 query 改寫會將其改寫為“兒童禮物”。而對于“買一塊可以在草地上鋪的布”，被誤解為“擺盤裝飾”。這就是廣告組買關(guān)鍵詞時遇到的問題，如“滿月禮物”或“野餐墊”。

query 改寫效果不好會導(dǎo)致兩個主要問題。一是改寫后的 query 匹配不到廣告主的關(guān)鍵詞，導(dǎo)致在召回階段就被淘汰。二是無法匹配到高價流量的精確需求，會浪費部分高價流量。比如，廣告主買了“兒童禮物”，但實際搜索的是“滿月禮物”。這些問題背后的主要技術(shù)原因是，傳統(tǒng)的方法對于長搜索詞的語義理解能力有限，且在語義相關(guān)的改寫詞覆蓋上也比較有限。

我們在利用 LLM 進行 Prompt Engineering 時做了一些嘗試。LLM 具有舉一反三的能力，可以告訴 LLM 一個詞，然后生成幾個相關(guān)的詞。例如，返回“華為手機”5 個電商近義詞，保證搜索詞品牌和類別與“華為手機”一致，LLM 可以生成“華為智能手機”、“華為”、“智能手機”、“華為暢享”、“華為 Mate”。再如，返回“新款高腰微喇褲深藍色”5 個電商近義詞，LLM 輸出“高腰”、“微喇褲”、“深藍色”、“時尚”、“修身”。

一種更好的方法是使用同類目、同方向的相似 query 引導(dǎo)模型輸出。例如，把前兩個 query“華為手機”與“廚房置物架”替換成“七分夏褲”與“女白色褲”，引導(dǎo)LLM 輸出第三個 query，生成的“高腰微喇褲”、“深藍色新款”、“深藍色褲”、“高腰褲”、“微喇褲”更貼近實際需求。這種方法在實際使用中效果更好，能快速應(yīng)用于日常工作。

最后一個場景是在 RAG 上的探索，結(jié)合企業(yè)客戶使用大模型的實踐。企業(yè)有大量知識庫，這些知識庫文檔需要分片并轉(zhuǎn)化為向量，存儲在向量數(shù)據(jù)庫中。目前的向量數(shù)據(jù)庫有 ElasticSearch、Hologres、Milvus 等。在線請求時，用戶提問通過 embedding 模型轉(zhuǎn)化為向量，然后在向量數(shù)據(jù)庫中檢索，相似度檢索結(jié)果取出 Top-K 后交給 LLM，提供上下文背景，構(gòu)建 Prompt，最終生成回答。

開源項目 PAI-RAG 將 RAG 鏈路過程中的各個環(huán)節(jié)進行模塊化設(shè)計。整體過程抽象成文檔抽取（Document Extraction）、索引建立（Indexing）、Pre-Retrieval（query 改寫在此階段）、Retrieval、Post-Retrieval、Generation、Evaluation 等。如何排序檢索出來的結(jié)果，如何讓有效的文檔排在前面，或者對所有檢索出的文檔進行總結(jié)，以更有效地引導(dǎo) LLM 生成，最后再進行評估，形成一個完整的 RAG 鏈路流程。我們目前的主要工作是使 RAG 工程鏈路變得更方便適配各種場景。比如，如果數(shù)據(jù)不是 PDF 或 Word，而是 PPT，能很方便添加讀取 PPT 文件的功能。對于 Query React，可以輕松地進行二次開發(fā)加工等。

PAI-RAG 主要支持的數(shù)據(jù)類型包括多模態(tài)數(shù)據(jù)、文檔的結(jié)構(gòu)化表示、embedding 模型的優(yōu)化等。我們集成了 OCR 功能，并考慮了文檔的層級結(jié)構(gòu)，支持 PDF 和 Word 等多模態(tài)的文件，包括文件中的截圖。當 Embedding 模型效果不佳時，使用第三方的大模型來豐富知識庫，自動生成文檔擴充此功能。

使用類似的思想來生成評估集，這對于構(gòu)建 RAG 鏈路的企業(yè)來說非常有用。它們通常有很多文檔，但沒有準備很多問題來測試 RAG 的效果。我們使用大模型 RefGPT（不是我們獨創(chuàng)）生成評估集。此外，還支持關(guān)鍵字檢索和混合檢索。

我們的工作還包括①評估大語言模型的優(yōu)劣，比如把人工評估的工作交給另一個大模型；②支持各種量化指標，如命中率、準確率等；③在回答的質(zhì)量上，考慮了正確性、語義相似度、忠實性、答案的上下文相關(guān)性等多個維度。

這是我們在 PAI 模塊化 RAG 中的一個示例圖，并使用 Gradio 編寫的前端，使得配置 RAG 鏈路和上傳數(shù)據(jù)變得非常方便，還可以直接進行交互測試。