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

今天介紹從大數據到大模型過程中，我們的大數據平臺建設，以及如何在大數據場景下應用大模型的能力。分享內容分為三大塊：一是搜索推薦廣告的技術架構；二是在搜索推薦場景中的工程和算法實踐；三是結合大模型的一些探索及相關工程產出。

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

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

用戶在線操作數據會被存儲并落入實時計算層，如 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 鏈路和上傳數據變得非常方便，還可以直接進行交互測試。