效果成本雙突破!快手提出端到端生成式推薦系統OneRec!

近日,快手推薦模型團隊提出了一個端到端生成式推薦系統OneRec,該系統采用Encoder-Decoder架構,引入了基于獎勵機制的偏好對齊方法,借助強化學習增強模型效果,可在獎勵模型引導下直接生成契合用戶偏好的視頻內容。通過極致的性能優化,OneRec在推薦模型FLOPs提升10倍的同時,大幅削減了通信和存儲等運營成本近90%。目前,OneRec已在快手/快手極速版雙端承接25%的線上流量,帶動APP停留時長分別提升0.54%和1.24%。

圖片

論文鏈接:https://arxiv.org/abs/2506.13695

當生成式架構重塑AI技術棧時,推薦系統卻仍受困于模塊化設計的“算力泥潭”——傳統級聯架構導致的算力碎片化、優化不一致等問題,限制了這一核心基礎設施的創新步伐。為此,快手技術團隊提出了端到端生成式推薦新范式「OneRec」。

【主要貢獻】

1. 單階段編碼器-解碼器生成框架:該框架巧妙利用Encoder 對用戶全生命周期行為序列進行壓縮處理,以此實現精準的興趣建模,同時基于MoE架構的Decoder具備超大規模參數擴展能力,有力保障了短視頻推薦的端到端精準生成。

2. 引入了基于獎勵機制的偏好對齊方法:通過獎勵反饋機制,并借助強化學習增強模型效果,模型能夠敏銳捕捉到更為細粒度的用戶偏好信息。為此,OneRec精心設計并搭建了一套多維度獎勵系統,涵蓋偏好獎勵、格式獎勵、工業場景獎勵,全方位助力模型理解用戶偏好。

3. 首個工業級端到端生成式推薦落地方案:本系統在快手主站/極速版雙端短視頻推薦主場景完成驗證。為期一周、覆蓋?5% 流量?的 A/B 測試表明,純生成式模型 (OneRec) 僅通過強化學習對齊用戶偏好,即達到與原復雜級聯系統相當的效果。疊加獎勵模型選擇策略 (OneRec with RM Selection) 后,更實現了用戶停留時長顯著提升(主站 +0.54%,極速版 +1.24%),以及7日用戶生命周期 (LT7) 增長(主站+0.05%,極速版+0.08%)的業務突破。

下圖(左)展示了快手 / 快手極速版中 OneRec 與級聯推薦架構的 Online 性能比較,圖(中)展示了 OneRec 與 Linear、DLRM、SIM 的 FLOPs 比較,圖(右)展示了 OneRec 與級聯推薦架構的 OPEX 對比,以及和鏈路中計算復雜度最高的精排模型 SIM 的 MFU 對比。

圖片

一、傳統推薦系統框架的局限性

推薦系統是一種基于用戶歷史行為、物品屬性以及上下文信息,通過模型算法來預測用戶偏好并主動推送個性化信息的信息過濾技術。在個性化新聞推送、音樂推薦、視頻推薦以及商品推薦等眾多場景中,推薦系統都發揮著至關重要的作用。

傳統推薦系統通常采用召回->粗排->精排的多層級聯架構模式,以平衡系統時延和效果,然而在實際應用中,卻面臨著三大核心瓶頸:

其一:算力效率低下。以快手為例的分析顯示,即使是在推薦系統中計算復雜度最高的精排模型(SIM),在旗艦版GPU上進行訓練和推理時,其MFU分別僅為4.6%和11.2%。與之形成鮮明對比的是,大語言模型在H100上的MFU能夠達到40%-50%的水平。

其二:目標函數相互沖突。平臺需要同時優化用戶、創作者和生態系統的數百個目標,這些目標在不同階段相互掣肘,導致系統整體的一致性和效率持續惡化。

更嚴峻的是,技術代差逐漸拉大。隨著AI技術的飛速發展,Scaling Law、強化學習等前沿技術不斷涌現,并在眾多領域取得了顯著成效。然而,現有架構卻難以將這些最新的AI技術成果有效吸納。同時,由于架構的限制,推薦系統也難以充分利用先進計算硬件的能力。這使得推薦系統與主流AI技術的發展步伐逐漸脫節,技術代差日益拉大。

二、快手端到端生成式推薦系統OneRec

面對這些挑戰,快手團隊提出端到端生成式推薦系統OneRec,其核心在于利用Encoder壓縮用戶全生命周期行為序列實現興趣建模,同時基于MoE架構的Decoder實現超大規模參數擴展,確保短視頻推薦的端到端精準生成。同時配合定制化強化學習框架和極致的訓練/推理優化,使模型實現效果和效率的雙贏。

目前,新系統在以下幾個方面的效果顯著:

  • 可以用遠低于線上系統的成本,采用更大的模型,取得更好的推薦效果;

  • 在一定范圍內,找到了推薦場景的scaling law;

  • 過去很難影響和優化推薦結果的RL技術在這個架構上體現出了非常高的潛力;

  • 目前該系統從訓練到serving架構以及MFU水平都和LLM社區接近,LLM社區的很多技術可以很好地在這個系統上落地。

圖片

2.1 OneRec模型框架

OneRec采用編碼器-解碼器架構(如下圖),將推薦問題轉化為序列生成任務,在訓練過程中使用NTP (Next Token Prediction) 損失函數優化。

圖片

2.1.1 語義分詞器

面對快手平臺上億級別的視頻內容,如何讓模型"理解"每個視頻成為關鍵挑戰。OneRec首創了協同感知的多模態分詞方案:

  • 多模態融合:同時處理視頻的標題、標簽、語音轉文字、圖像識別等多維信息;

  • 協同信號集成:不僅關注內容特征,更融入用戶行為信息建模;

  • 分層語義編碼:采用RQ-Kmeans技術,將每個視頻轉化為3層粗到細的語義ID

2.1.2 編碼器-解碼器

在訓練階段,OneRec通過編碼器-解碼器架構執行下一個token預測,進而實現對目標物品的更高效預測。該架構在不同階段起到的作用分別如下:

  • 多尺度用戶建模:編碼階段同時考慮用戶靜態特征、短期行為序列、有效觀看序列和終身行為序列;

  • 專家混合解碼器:解碼階段采用逐點生成策略,通過Mixture of Experts(MoE)架構提升模型容量和效率。

2.1.3 推薦系統中的Scaling Laws

參數規模實驗是OneRec研究中的另一亮點,它試圖回答一個fundamental的問題:推薦系統是否同樣遵循大語言模型領域已被證實的Scaling Law?實驗結果清晰地表明,隨著模型參數量從0.015B到2.633B的遞增,訓練損失呈現出明顯的下降趨勢。

圖片

技術報告中還介紹了包含Feature Scaling、Codebook Scaling和Infer Scaling等,極大地利用算力來提升推薦的精度。

2.2 RL偏好對齊

預訓練模型雖然可以通過下一個token預測來擬合曝光物品的空間分布,但這些曝光物品來源于過去的傳統推薦系統,這導致模型無法突破傳統推薦系統的性能天花板。

傳統推薦系統通常定義多個目標,如點擊量、點贊數、評論數和觀看時長,然后通過加權融合每個目標的預測值(xtr)將其組合成一個分數。然而,手動調整這些融合權重既缺乏準確性,又缺乏個性化,并且常常導致目標之間的優化沖突。

為了解決這一挑戰,OneRec引入了基于獎勵機制的偏好對齊方法,利用強化學習增強模型效果。通過獎勵反饋機制,模型得以感知更為細粒度的用戶偏好信息。為此,OneRec構建了一套綜合性的獎勵系統,包括如下:

  • 偏好獎勵(Preference Reward)用于對齊用戶偏好

  • 格式獎勵(Format Reward)確保生成的token均為有效格式

  • 工業場景獎勵(Industrial Reward)以滿足各類業務場景的需求

圖片

首先,什么樣的視頻應該被獎勵呢?面對這一問題,OneRec提出采用偏好獎勵模型,能基于用戶特征,輸出對不同目標預測值進行「個性化融合」后的偏好分數。過程中,利用該分數「P-Score」作為強化學習的獎勵ri,并通過GRPO的改進版ECPO(Early-Clipped GRPO)進行優化。結果顯示,相較于GRPO,ECPO對負優勢(A<0)樣本進行更嚴格的策略梯度截斷,保留樣本的同時防止梯度爆炸使訓練更加穩定。

圖片

OneRec在快手兩個場景進行了強化學習的消融實驗,線上結果顯示:在不損失視頻曝光量的情況下顯著提升APP使用時長。

圖片

其次,在OneRec中,詞表空間遠大于全部視頻數量,這會導致在推理階段生成的語義ID序列可能無法映射回真實視頻ID,即非法生成。OneRec指出強化學習雖然能提升效果,但由于「擠壓效應」會導致模型輸出的合法性顯著下降,不僅推理成本變大且不利于推薦的多樣性。

擠壓效應:負向優勢的梯度會將大部分的概率質量擠壓到當前模型的最優輸出o*,大部分合法輸出的概率被抹平。

圖片

針對這個問題,OneRec提出「以暴制暴」,用強化學習的方法解決強化學習的問題,引入格式獎勵(Format Reward)鼓勵合法的輸出以緩解擠壓效應。OneRec對兩種合法樣本的挑選方法進行了實驗,并觀察到非常有趣的結論:

  • 從生成樣本中挑選概率最大的k個:生成樣本的總體合法性先上升后衰減,所挑選樣本的合法性很快收斂到100%

  • 從生成樣本中隨機挑選k個:生成樣本的總體合法性和所挑選樣本的合法性同時上升,未出現衰減。

圖片

這些現象表明,如果用概率最大的k個樣本訓練,模型會很快捕捉到獎勵的內在機制,從而引發「Rward Hacking」現象。該實驗不僅驗證了格式獎勵的有效性,而且表明獎勵的準確定義十分重要。

除了以上提到的用戶偏好獎勵和格式獎勵,OneRec還引入了工業場景獎勵,以滿足特殊工業需求,如營銷號的打壓、冷啟視頻和長尾視頻的分發等。

2.3 性能優化

從衡量算力效率的核心指標MFU(模型浮點運算利用率)來說,傳統推薦排序模型長期深陷"個位數魔咒",主要有兩方面的原因:

  • 一是業務迭代積累的歷史包袱,如快手精排模型算子數量高達15000+個,復雜結構導致無法像LLM那樣進行深度優化;

  • 二是成本與延遲約束下的規模瓶頸,致使單個算子計算密度低下,顯存帶寬成為性能天花板,GPU算力利用率長期低于10%。

而OneRec的生成式架構帶來破局性變革:通過采用類LLM的encoder-decoder架構精簡組件,將關鍵算子數量壓縮92%至1,200個,配合更大模型規模提升計算密度;同時通過重構推薦鏈路釋放延遲壓力,使訓練/推理MFU分別飆升至23.7%和28.6%,較傳統方案實現3-5倍提升,首次讓推薦系統達到與主流AI模型比肩的算力效能水平。?

除了模型結構的天然優勢,團隊還針對 OneRec 特性在訓練和推理框架層面進行了深度定制優化。

2.3.1 系統深度優化

除了模型結構的天然優勢,我們還針對 OneRec 特性在訓練和推理框架層面進行了深度定制優化。

訓練優化
  • 計算壓縮:針對同一請求下的多條曝光樣本(如一次下發 6 個視頻,平均 5 條曝光),這些樣本共享用戶和 context 特征。我們按請求 ID 分組,避免在 context 序列上重復執行 ffn 計算。同時,利用變長 flash attention,有效避免重復的 kv 訪存操作,進一步提升 attention 的計算密度。

  • Embedding 加速優化:針對單樣本需訓練 1000 萬以上 Embedding 參數的挑戰,我們自研了 SKAI 系統,實現了 Embedding 訓練全流程在 GPU 上完成,避免 GPU/CPU 同步中斷;通過統一 GPU 內存管理(UGMMU)大幅減少 kernel 數量;采用時間加權 LFU 智能緩存算法充分利用數據的時間局部性,并通過 Embedding 預取流水線將參數傳輸與模型計算重疊,有效隱藏傳輸延遲,整體大幅提升了 Embedding 訓練效率。

  • 高效并行訓練:采用數據并行 + ZERO1 + 梯度累計的訓練策略。選擇 ZERO1 是因為模型 Dense 參數較小,單 GPU 可容納完整模型參數和梯度,在 interleaving 多個 macro batch 時能夠減少數據并行組的同步開銷。

  • 混合精度與編譯優化:絕大部分 op 使用 BFloat16 進行運算,對全圖進行編譯優化,通過計算圖優化和 kernel fusion 減少計算開銷。

推理優化

OneRec 在推理階段采用大 beam size(通常為 512)來提升生成式推薦的多樣性和覆蓋率。面對如此大規模的并行生成需求,我們從計算復用、算子優化、系統調度等多個維度進行了深度優化:

  • 計算復用優化:?OneRec 針對大規模并行生成需求,通過多種計算復用手段大幅提升效率:首先,同一用戶請求下 encoder 側特征在所有 beam 上完全一致,因此 encoder 只需前向計算一次,避免了重復計算;其次,decoder 生成過程中 cross attention 的 key/value 在所有 beam 間共享,顯著降低顯存占用和算力消耗;同時,decoder 內部采用 KV cache 機制,緩存歷史步驟的 key/value,進一步減少重復計算。

  • 算子級優化:?OneRec 推理階段全面采用 Float16 混合精度計算,顯著提升了計算速度并降低了顯存占用。同時,針對 MoE、Attention、BeamSearch 等核心算子,進行了深度 kernel 融合和手工優化,有效減少了 GPU kernel 啟動和內存訪問次數,全面提升了算子計算效率和整體吞吐能力。

  • 系統調度優化:?OneRec 通過動態 Batching 策略,根據當前系統負載和請求延遲實時調整 batch 的大小,盡可能提升每個 batch 的并發度。這種方式能夠有效減少單次請求的平均訪存帶寬消耗,進一步提升整體計算效率和系統吞吐。

通過以上系統性的優化策略,OneRec 在性能方面取得了顯著提升。在算力利用率方面,訓練和推理的 MFU 分別達到了?23.7%?和?28.8%,相比傳統推薦模型的 4.6% 和 11.2% 有了大幅改善。運營成本降低至傳統方案的?10.6%,實現了接近 90% 的成本節約。

2.4 Online實驗效果

OneRec在快手主站/極速雙端app的短視頻推薦主場景上均進行了嚴格實驗。通過為期一周5%流量的AB測試,純生成式模型(OneRec)僅憑RL對齊用戶偏好即達到原有復雜推薦系統同等效果,而疊加獎勵模型選擇策略(OneRec with RM Selection)后更實現停留時長提升0.54%/1.24%、7日用戶生命周期(LT7)增長0.05%/0.08%的顯著突破——須知在快手體系中,0.1%停留時長或0.01% LT7提升即具統計顯著性。

更值得關注的是,模型在點贊、關注、評論等所有交互指標上均取得正向收益(如下表),證明其能規避多任務系統的"蹺蹺板效應"實現全局最優。該系統目前已經在短視頻推薦主場景承擔25%的QPS。

圖片

除了短視頻推薦的消費場景之外,OneRec在快手本地生活服務場景同樣表現驚艷:AB對比實驗表明該方案推動GMV暴漲21.01%、訂單量提升17.89%、購買用戶數增長18.58%,其中新客獲取效率更實現23.02%的顯著提升。

目前,該業務線已實現100%流量全量切換。值得注意的是,全量上線后的指標增長幅度較實驗階段進一步擴大,充分驗證了OneRec在不同業務場景的泛化能力。

三、總結和展望

OneRec通過創新的生成式架構重構推薦系統的技術范式。與此同時經過極致的工程優化,在效果與效率雙重維度上實現全面超越。當然,新系統還有很多地方未完善,報告中仍指出了三個待突破的方向:

  • 推理能力:Infer階段step的scaling up能力尚不明顯,這預示著OneRec還不具備很強的推理能力;

  • 多模態橋接:構建用戶行為模態與LLM/VLM的原生融合架構,借鑒VLM中的跨模態對齊技術,實現用戶行為序列、視頻內容與語義空間的統一學習,成為一個原生全模態的模型;

  • 完備的Reward System:目前Reward System的設計還比較初級。在OneRec端到端的架構下,Reward System既能影響在線結果也能影響離線訓練,我們期望利用該能力引導模型更好地理解用戶偏好和業務需求,提供更優的推薦體驗。

可以預見,隨著AI能力的持續融入,OneRec將釋放出更強大的能力,在更廣泛的推薦應用場景中創造更大的業務價值。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/910041.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/910041.shtml
英文地址,請注明出處:http://en.pswp.cn/news/910041.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

flex布局 項目屬性

<!DOCTYPE html> <html> <head> <meta charset"utf-8"> <title>flex布局 項目屬性</title> <link href"css/k.css" rel"stylesheet" /> </head> <bod…

SpringBoot擴展——應用Web Service!

應用Web Service Web Service是一個SOA&#xff08;面向服務的編程&#xff09;架構&#xff0c;這種架構不依賴于語言&#xff0c;不依賴于平臺&#xff0c;可以在不同的語言之間相互調用&#xff0c;通過Internet實現基于HTTP的網絡應用間的交互調用。Web Service是一個可以…

EasyExcel學習筆記

EasyExcel學習 一、EasyExcel簡介 一、EasyExcel是什么 EasyExcel是一個基于Java的簡單、省內存的讀寫Excel的阿里開源項目。在盡可能節約內存的情況下支持讀寫百M的Excel。 官網&#xff1a;https://easyexcel.opensource.alibaba.com/ 學習Easyexcel前需要了解導入和導出…

day4課程

1整體認識和路由配置 2二級分類面包屑導航實現 3基礎商品列表渲染 4列表篩選功能實現 5列表無限加載功能實現 6定制路由滾動行為 7詳情頁整體認識和路由配置 8詳情頁基礎數據渲染 9詳情頁基礎組件封裝和數據渲染 10適配不同title和數據列表 11小圖切換大圖 12滑塊跟隨鼠標移動 …

kubeadm worker節點加入master失敗

文章目錄 1、操作2、問題現象3、問題原因4、問題解決4.1、重新生成token4.2、重新生成hash值 5、驗證 1、操作 執行以下命令&#xff0c;讓worker節點加入到master節點 kubeadm join 103.123.222.241:6443 --token vxe3v1.wzpnks8v1vbbtsu0 --discovery-token-ca-cert-hash s…

二十二、【用戶管理與權限 - 篇四】后端權限定義:模型與 API 實現

【用戶管理與權限 - 篇四】后端權限定義:模型與 API 實現 前言準備工作第一部分:設計并創建 `Permission` 模型第二部分:更新 `Role` 模型以關聯 `Permission`第三部分:生成并應用數據庫遷移第四部分:創建 Serializers第五部分:創建 ViewSets第六部分:注冊 API 路由第七…

猜數字小游戲微信流量主小程序開源

這個智力小游戲采用了數字華容道的玩法&#xff0c;玩家需要通過移動數字方塊&#xff0c;將數字按順序排列完成游戲。代碼嚴格遵循微信小程序的目錄結構&#xff0c;包含以下部分&#xff1a; 完整的小程序配置文件&#xff08;app.js、app.json、app.wxss&#xff09; 游戲頁…

探秘阿里云EBS存儲:云計算的存儲基石

一、引言 在云計算時代&#xff0c;數據如同企業的生命線&#xff0c;數據存儲的重要性不言而喻。隨著企業數字化轉型的加速&#xff0c;海量數據的存儲與高效管理成為亟待解決的問題。云存儲以其卓越的靈活性、可擴展性和成本效益&#xff0c;逐漸成為眾多企業的首選方案。在…

音視頻之H.264的可伸縮編碼SVC

系列文章&#xff1a; 1、音視頻之視頻壓縮技術及數字視頻綜述 2、音視頻之視頻壓縮編碼的基本原理 3、音視頻之H.264/AVC編碼器原理 4、音視頻之H.264的句法和語義 5、音視頻之H.264/AVC解碼器的原理和實現 6、音視頻之H.264視頻編碼傳輸及其在移動通信中的應用 7、音視…

Anaconda安裝env,yml一直卡在Solving environment:不動

如果在使用conda env creat -f env.yml時候&#xff0c;anaconda一直卡住&#xff0c;如下 可以嘗試下面操作。 conda config --set solver libmamba # 使用libmamba引擎&#xff08;Conda≥22.11&#xff09; conda env create -f env.yaml # 重新嘗試

榕壹云婚戀相親系統:ThinkPHP+UniApp打造高效婚配平臺

引言 在數字化浪潮下,婚戀相親行業正加速向線上遷移。榕壹云公司基于市場需求與技術積累,開發一款功能完備、技術開源的婚戀相親小程序系統,為單身人士提供高效、安全的婚戀平臺。本文將圍繞系統背景、客戶定位、核心技術、功能模塊及優勢場景展開詳細解析,助力開發者與技…

查詢docker-compose 部署的milvus 請求日志

在 Docker Compose 部署的 Milvus 中,日志默認存儲在各個服務的容器內。以下是定位和查詢日志的方法: 1. 查看實時日志 使用 docker-compose logs 命令查看實時日志: bash # 查看所有服務的日志 docker-compose logs -f# 僅查看 Milvus 服務日志(服務名以 docker-compos…

Rsync實操

Rsync實操 一.rsync命令 #類似于cp[rootuser2 ~]# rsync info.sh root192.168.168.130:/rootroot192.168.168.130s password: [rootuser1 ~]# lsanaconda-ks.cfg ceph-release-1-1.el7.noarch.rpm info.sh 二、使用rsync備份push方式 服務器&#xff1a;server 192.168.168…

Java常見八股-(6.算法+實施篇)

Java常見八股-&#xff08;1.Java基礎篇&#xff09; Java常見八股-&#xff08;2.Java高級篇&#xff09; Java常見八股-&#xff08;3.MySQL篇&#xff09; Java常見八股-&#xff08;4.前端篇&#xff09; Java常見八股-&#xff08;5.框架篇&#xff09; 目錄 一、算…

阿里云部署的SMTP服務器安全攻防實錄:深度解析攻擊、防護與加固

阿里云部署的SMTP服務器安全攻防實錄&#xff1a;深度解析攻擊、防護與加固 一次針對云上SMTP服務的持續攻擊事件&#xff0c;揭示了郵件中繼服務面臨的多重安全挑戰。本文將深入剖析攻擊手法、防護策略與系統性加固方案。 某企業在阿里云上部署的Postfix SMTP服務器近期遭遇…

HTTP與HTTPS深度解析:從明文傳輸到安全通信的演進之路

引言 在互聯網的早期&#xff0c;HTTP&#xff08;超文本傳輸協議&#xff09;作為Web通信的基石&#xff0c;憑借簡單高效的特性推動了萬維網的爆發式增長。但隨著互聯網從“信息共享”向“價值交互”演進&#xff0c;HTTP的明文傳輸特性逐漸暴露致命缺陷——用戶的每一次點擊…

滲透實戰:繞過沙箱機制的反射型XSS

Lab 24&#xff1a;利用 xss 繞過 csrf 防御 依然是留言板的問題可以執行<h1>標簽 進入修改郵箱的界面&#xff0c;修改抓包 這里構造修改郵箱的代碼 <script> var req new XMLHttpRequest(); req.onload handleResponse; req.open(get,/my-account,true); req…

K8S篇之利用deployment實現滾動平滑升級

一、更新策略 在 Kubernetes (K8s) 中,滾動平滑升級(Rolling Update)是一種無縫更新部署的方式,允許你在不中斷服務的情況下逐步更新應用程序。這是 Kubernetes 默認的 Deployment 更新策略,它會按照指定的步幅逐步替換 Pods,確保在新版本的應用程序沒有完全替換舊版本的…

【Dify 案例】【MCP實戰】【一】【前置配置】

MCP(Model Context Protocol,模型上下文協議) ,2024年11月底,由Anthropic 推出的一種開放標準。旨在為大語言模型(LLM)提供統一的、標準化方式與外部數據源和工具之間進行通信。 MCP 作為一種標準化協議,極大地簡化了大語言模型與外部世界的交互方式,使開發者能夠以統…

2025高考志愿填報張雪峰資料合集

2025高考志愿填報課程&#xff0c;張雪峰專業指導&#xff01;包含61節課&#xff0c;93個專業詳解&#xff0c;總計1500分鐘視頻。 獨家各省資料包&#xff01;新舊高考政策全覆蓋&#xff0c;適合高三家長和考生。內容整理自互聯網&#xff0c;無償分享&#xff0c;如有侵權&…