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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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