作者 | zakexu 來源 | CSDN博客

原文由筆者2018年7月份所寫，在此做下整理。

文章目錄

• 一、前言

• 二、背景

• 三、整體推薦框架

  • （一）離線層

    • 1、推薦物料的準備

    • 2、數據處理

    • 3、樣本設計

    • 4、特征提取

    • 5、模型訓練

    • 6、數據上線

  • （二）近線層

  • （三）在線層

• 四、算法二期的迭代計劃

• 五、總結

• 作者簡介

一、前言

自手Q游戲中心V6.0改版以來，產品形態發生了較大的轉變，不再是純粹通過app列表做游戲分發，而是試圖通過內容來帶游戲分發，全新的產品形態給推薦算法帶來了許多的挑戰。截至4月初，算法一期的工作已接近尾聲，借此機會寫下總結，一方面是將整個游戲中心的推薦邏輯進行梳理，并將其中的一些經驗沉淀總結，方便回溯；另一方面也試圖在梳理的過程中，整理出遇到的一些挑戰，能夠更加明確算法二期的一些迭代思路。

二、背景

?手Q游戲中心作為騰訊手游重要的分發渠道之一，既是用戶發現感興趣游戲的重要入口，同時也提供了各手游平臺運營的能力。新版游戲中心不再是純粹地通過傳統app列表的方式做游戲分發，而是新增了一系列通過內容（攻略、視頻、直播、禮包等）拉下載、拉活躍的場景（如圖1所示）。為了更好地提升用戶進入游戲中心的體驗以及滿足平臺精細化運營（拉新、拉活、拉付費等）的需求，通過海量用戶的行為流水挖掘用戶游戲偏好，精準推薦用戶感興趣內容成為了必然趨勢。為此，我們設計了全新的個性化推薦框架，給業務帶來了顯著的轉化率提升。

圖1：游戲中心個性化推薦場景

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

為了更好地制定算法二期的迭代計劃，本文主要對算法一期的工作做一個簡單的復盤，一方面是將項目開展過程中的一些經驗進行總結沉淀，另一方面也是想對游戲中心推薦場景中比較有挑戰性的問題進行梳理，以便算法二期迭代過程中更加具有針對性。

三、整體推薦框架

?本節主要結合游戲中心個性化推薦的算法框架（如圖2所示）以及工程框架（如圖3所示），對項目過程中遇到的一些問題進行總結歸納。游戲中心所采用的推薦框架是業界常見的三段式推薦邏輯：offline—nearline—online。離線層主要負責存儲全量用戶在游戲中心的流水數據、計算用戶長期的行為屬性以及訓練用戶的游戲偏好模型等；近線層主要是為了解決離線層計算周期長，響應速度慢的缺點，通過實時計算用戶的短期興趣，反饋到線上，從而能夠對用戶在游戲中心的行為做到實時反饋；在線層可以理解為推薦引擎，主要是對業務請求通過一系列的計算，返回最終的推薦結果列表，在線層可以細分為召回層—精排層—重排層結構。

圖2：游戲中心個性化推薦算法架構圖

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

圖3：游戲中心個性化推薦工程架構圖

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

（一）離線層

離線層適用于用戶長期興趣的計算、離線模型的訓練、模型參數的實驗以及其他對時效性要求不高的任務，因此離線層主要采取HDFS+Spark的工程實現（批處理的計算方式）。業務數據通過DC或者TDBank上報，累計一定的數據量（游戲中心是以每小時為周期）周期性落地到HDFS或者TDW中以庫表的形式存在，以Spark為計算引擎，對庫表數據進行一系列處理后，將結果數據推送到線上存儲，構成線上推薦引擎的重要數據來源。對于游戲中心這個場景，離線層的工作流可以劃分為6大步驟：推薦物料的準備、數據處理、樣本設計、特征提取、模型訓練、數據上線。

1、推薦物料的準備

對于推薦系統來講，第一個需要確定的就是推薦物料（也就是推薦池子）。游戲中心推薦的物品主要有兩大類：第一大類就是游戲app，目前游戲中心接入算法的游戲app主要包括精品游戲、單機游戲，基本上每天變化不大，因此該類物料由業務每天例行上報更新并推送到線上存儲即可。第二大類就是游戲內容了，主要包括攻略、視頻、直播等，該類物料相對來講實時性要求會高一些（新游上線當天需要內容同步更新）。目前游戲中心的內容來源數據鏈路如圖4所示，主要來源是一些上游PGC內容的采購，經過自動Tag提取之后進入到標簽內容庫，算法側直接從標簽內容庫獲取推薦物料，目前是按小時更新。

圖4：內容源數據鏈路

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

2、數據處理

熟悉推薦流程的同學可能比較清楚，數據處理過程繁瑣枯燥且耗時較長，占據了整個算法開發周期60%以上的時間，貫穿整個開發流程。沒入坑之前有些人可能會以為推薦算法工程師是一個高大上的職位，每天舒舒服服地看下paper，研究下算法，做下實驗，特別酷。入坑之后就會發現，每天干的最多的活就是處理數據。但這也充分說明了數據處理的重要性，畢竟只有充分了解數據才能更了解業務，才能更加合理地設計你的推薦策略。這兒講的數據處理主要包括數據驗證、臟數據過濾以及數據轉換等。下面主要總結一下在數據處理過程中所踩過的坑：

（1）一定要做好數據上報準確性的驗證：前端同學有時候可能不是特別了解算法同學對于上報數據的訴求，所以在上報的時候可能會出現目標不一致的情況。常見的情況有：上報邏輯出錯（分頁feeds曝光只上報了第一條feeds的數據）、上報id錯位（曝光的operid報了下載的數據），上報id缺失等。而驗證數據上報準確性的常規操作就是打開游戲中心，將每個場景你有可能會用到的用戶行為都操作一遍，記下操作時間，一個小時后從流水中撈出你的數據，逐一驗證是否合理（噩夢）。

（2）推薦邏輯出現問題時候優先考慮數據的準確性：當推薦結果產生問題或者出現bug的時候，優先檢查數據的準確性。模型的魯棒性以及容錯性一般都較高，最可能出現問題的往往是數據環節。通常都是沿著數據鏈路往上游逐步排查從而定位問題。

（3）對業務流水數據做一層數據中間表做解耦：算法開發過程中，最好不要直接操作operid相關的邏輯，遇上業務改上報id時（比如產品改版換了新的一套operid），改代碼改的你頭疼。? ?

（4）算法接入后一定要跟產品以及前端同學再三確認算法ID的上報準確性：業務在調用推薦引擎時都會獲得一個算法ID，算法ID上報的準確性直接影響效果監控報表的可信度。很多時候上了一個算法策略結果發現線上效果突然下降，排查半天才發現原來部分轉化行為的算法ID上報缺失，所以這兒一定要仔細驗證清楚。

（5）臟數據過濾是一門玄學：臟數據的定義通常需要根據業務場景來決定，有時候信心滿滿地將所有臟數據都過濾之后，線上效果反而降了，所以在過濾數據時要留個心眼（什么樣才是臟數據？臟數據是不是一定沒用？不要想當然，還是用線上效果說話吧！）。

（6）建立完善的報表監控體系：推薦的一個重要環節就是報表監控，不僅僅包括對效果的監控，還包括對池子的監控、核心用戶的監控、item場景表現的監控等。只有建立完善的監控體系，才能在推薦結果受到挑戰時快速定位問題。

圖5：游戲中心報表監控體系

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

3、樣本設計

一般來講，推薦問題都會轉換成二分類問題，也就是判斷用戶對某個物品是否會產生操作行為（通常一個U-I對就是一個樣本），那么要訓練出一個看起來合理線上效果又比較理想的二分類模型，正負樣本的設計顯得極其重要，下面總結一下游戲中心在設計不同場景的樣本時的一些經驗：

（1）如何正確定義正負樣本？在純icon推薦的場景，咋一看可以理解為用戶下載了該app就是正樣本，沒有下載就是負樣本。但仔細一想這樣做會產生兩個問題，第一個問題就是正負樣本極其不均衡（機器學習中經典問題之一），因為用戶瀏覽幾十個app可能也就下載1個app，當然，機器學習針對正負樣本不均衡問題會有很多解決方法，這兒就不展開描述了；第二個問題就是用戶沒有下載并不代表就是不喜歡，這兒會有幾個值得推敲的地方：1）用戶曝光了但是從沒有產生過下載行為，可能因為是無效曝光，用戶關注的焦點不在這，所以無法判斷用戶到底是喜歡還是不喜歡；2）用戶在游戲icon曝光的場景并沒有產生下載行為，但是用戶產生了點擊行為，從而進入到游戲詳情頁后產生下載行為，這樣是不是可以認為用戶其實是喜歡的，產生的也是正樣本呢？舉這么個例子主要是為了說明，對于每個不同的推薦場景來說，正負樣本的設計都應該充分結合業務特性，不然容易產生有偏樣本。

（2）設計樣本時應保證每個用戶樣本數的均衡：在app分發或者內容分發場景，容易存在一些刷量用戶；該批用戶頻繁進入游戲中心從而產生多次操作行為，因此在設計樣本時應對多次操作的U-I樣本對去重，并保證每個用戶樣本數的均衡，從而避免模型被少數用戶所帶偏。

（3）樣本權重的設計問題：在feeds推薦的場景中，不同推薦槽位所產生的樣本權重應該有所不同；比方說首頁feeds場景，用戶剛進入場景時，注意力會比較集中，產生的負樣本應該置信度較高，權重也較高；當用戶下滑到后面feeds的時候，對feeds的內容可能會比較乏味了，產生的正樣本置信度應該也是較高的，權重應該也設置較高。

（4）適當豐富樣本來源的多樣性：一般樣本都是基于當前場景所產生的用戶行為來選取的，而當前場景用戶的行為某種程度是受推薦結果而影響的（“你給我推薦了王者榮耀，那么我只能喜歡王者，但是可能我更喜歡你沒給我推的吃雞呢”），隨著算法的迭代，越到后面，算法其實是在迭代自身，越學越窄，這也是推薦系統經典的多樣性問題。youtube所采用的一種緩解的方法就是從其他沒有算法干擾的場景選取部分樣本，來避免這個問題，而在游戲中心的樣本設計中，都會單獨開設一股沒有算法干擾的小流量作為干凈樣本的補充。

4、特征提取

特征決定機器學習的上限，而模型只是在逼近這個上限。可想而知，特征設計的重要程度是多么的高。關于特征設計的方法論有很多，這兒就不具體討論。這里主要介紹一下游戲中心各個場景在設計特征時候的通用思路以及為了解決首頁feeds特征空間不一致時所采用的多模態embedding特征。

（1）通用特征設計思路：如圖6所示。這兒需要提一下的是，游戲中心的推薦場景由于涉及平臺利益，所以一般情況下，特征設計時都需要考慮特征的可解釋性。

?圖6：特征設計思路

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

（2）多模態embedding特征向量：首頁feeds流分發場景是一個具有挑戰性的場景，其中一個比較有意思的難題就是待推薦的內容類型較多。傳統的feeds推薦場景要么都是純視頻流、要么是純文字feeds等，而游戲中心首頁這兒待推薦的內容類型有攻略、視頻、直播、活動、禮包等，而且每一種內容類型的二級承載頁產品形態也不一致，這樣會導致可提取的特征空間維度不一致。比方說視頻承載頁的觀看時長與圖文承載頁的觀看時長量級不一致，視頻承載頁有icon點擊等操作而圖文承載頁則沒有。特征空間的不一致會導致模型在打分的時候會有所偏頗，離線實驗過程中發現視頻由于特征維度較齊全，打分結果整體偏高。因此，為了減緩特征空間維度不一致問題，游戲中心首頁feeds流引入了多模態embedding特征向量，該方法在企鵝電競視頻推薦場景已經取得了較好的效果（如圖7所示）。多模態embedding特征向量的設計主要參考youtube的論文，從而獲得每個user、item的低維特征向量，一方面解決item的原始特征空間維度不一致問題，另一方面也根據用戶的歷史行為，學習user、item的隱語義特征維度，起到信息補充的作用。

圖7：多模態embedding網絡

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

5、模型訓練

好了，終于到了別人所認為的高大上的步驟了——模型訓練，其實一點都不高大上，尤其是有了神盾推薦這個平臺。目前神盾推薦離線算法平臺已經集成了大部分常見的推薦算法，包括LR，Xgboost，FM，CF等，因此離線訓練只需要準備好樣本跟特征，配置好參數，就可以一鍵點run喝咖啡了（開玩笑開玩笑，是繼續搬下一塊磚）。傻瓜式的模型訓練（調包俠）其實并沒有太大的坑，但是有幾點經驗也在這稍微寫一下哈：

（1）注意調參的正確姿勢：目前神盾默認是將數據集劃分為train跟test，如果盯著test數據集的指標來調參的話，是很有可能出現線下高線上低的情況。因為盯著test指標進行調參的話容易加入個人先驗，本身就是一種過擬合的操作，正規的操作應該是將數據集劃分為train-test-validation。

（2）同樣的業務場景建議共用一個大模型：新版游戲中心目前有9個場景需要算法接入，如果每一個場景都單獨建模的話，一來維護成本高，二來浪費人力。適當對場景問題進行歸納，訓練通用模型可以有效地節省開發時間。比如說首頁分類列表推薦，游戲Tab的熱游列表推薦等，其實都是純icon的推薦，可以用統一的大模型來建模。通用模型首先要考慮的問題就是樣本、特征的選取，樣本可能比較好設計，匯總所有場景的樣本即可，最多就是根據場景特性設計不同的權重；而特征就需要好好斟酌，是分場景提取特征還是匯總后提取、不同場景特征維度不一致如何處理等。

（3）選擇合適的機器學習方案：目前首頁feeds是將排序問題轉化為二分類問題，評估指標選取的是auc，所以優化的重點在于盡可能地將正負樣本區分開（正樣本排在負樣本前面），但對于正樣本之間誰更“正”卻不是二分類模型的關注重點。神盾近來已經支持pari-wise的LTR算法，可以解決任意兩樣本之間置信度問題，后續可以在首頁feeds場景上做嘗試。

（4）選擇合適的優化指標：對于視頻瀑布流場景，優化的目標可以有很多，比如人均播放個數、播放率、人均播放時長，具體需要跟產品同學溝通清楚。

（5）避免對分類問題的過度擬合：前面已經提過，在推薦場景，經常將推薦問題轉化為分類問題來處理，但是需要注意的是，推薦問題不僅僅只是分類問題。分類問題是基于歷史行為來做預測，但推薦問題有時候也需要考慮跳出用戶歷史行為的限制，推薦一些用戶意想不到的item，因此，推薦是一個系統性問題，應當避免過度擬合分類問題。

6、數據上線

數據上線可以說是推薦系統中較為核心的環節，其中會面臨很多難題。這兒的數據主要指的是離線計算好的物料數據、特征數據（用戶、物品）、模型數據等。目前神盾會周期性地對需要上線的數據出庫到hdfs，通過數據導入服務推送到線上存儲，主要是grocery（用戶特征）跟共享內存ssm（物品特征以及池子數據等查詢較為頻繁的數據）。目前這兒會有幾個小問題：

（1）數據的一致性問題：離線模型在訓練的時候，會對樣本數據跟特征數據做拼接，通常都是將當前周期的樣本跟上一周期的特征做拼接，以天為例，也就是今天的樣本會跟昨天的特征數據做拼接。但是離線數據的計算以及上線是會有時間延遲的，尤其是特征數據。有可能今天的凌晨0點到5點，線上所拉到的特征數據其實是前天的特征數據，5點之后，昨天的特征數據才計算完并更新到線上。也就是說凌晨5點之前，所產生的推薦結果其實是用前天的特征數據來計算的，那么離線訓練的時候，拼接的特征數據就會與實際的數據不一致。

（2）數據的實時性問題：前面也講了，業務數據一般會周期（按小時）落地到hdfs或者tdw以庫表形式存在，基于spark進行數據處理之后又推送到線上存儲，這種復雜的數據處理鏈路導致數據時效性得不到保證（頻繁地數據落地以及數據上線所導致）。因此，離線層僅適用于對數據時效性不高的任務，比如長期興趣的計算等。

（二）近線層

前面已經提到，離線層在數據時效性以及數據一致性的問題上面臨較大的挑戰。本質上是由于數據頻繁落地以及上線導致的延遲所引起的，給游戲中心推薦帶來較大的困擾。企鵝電競也面臨同樣的問題，因此，兩個業務聯合設計了近線層（如圖8所示）。目前整個數據鏈路已經打通，并且也在企鵝電競業務上試點成功。整個框架是基于kafka+spark streaming來搭建的，目前主要實現兩個功能點：實時特征的提取以及實時樣本特征的拼接。由于近線層不需要落地以及線上導數據服務，而是直接對業務流水進行操作后寫入線上存儲，因此耗時較少，基本可以做到秒級別的特征反饋，解決了離線層計算周期長的缺點，適用于用戶短時興趣的捕捉。

實時樣本特征的拼接主要是為了解決數據一致性問題。離線層對樣本、特征進行拼接的時候一般都是默認當前周期樣本拼接上一周期的特征，當由于特征上線的延遲，有部分當前周期樣本的產生其實是由t-2周期的特征所導致，因此為了保證訓練數據的準確性，我們在近線層設計了實時的樣本特征拼接。當用戶請求時，會帶上讀取的特征數據，拼接到用戶的操作流數據上，構成離線層的訓練數據。

圖8：近線層功能邏輯

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

（三）在線層

在線層是推薦系統的關鍵環節，直接影響最終的推薦結果。一般分為召回層，精排層、重排層（或者是matching、ranking、rerank）。召回層一般是起到粗篩的作用，對于內容推薦來說，推薦的池子一般都是上萬級別，如果直接進行模型打分的話，線上服務壓力會比較大，因此，通常都會采用各種召回的策略來進行候選集的粗篩。目前游戲中心所采用的召回策略主要有標簽、熱度、新鮮度、CF等。精排層所干的事情就比較純粹了，一般就是模型加載以及模型打分，對召回的物品進行一個打分排序。最后就是重排層，主要是對模型打分結果進行一個策略的調整。游戲中心的重排排層主要有以下幾個邏輯：1）分類打散：首頁feeds在推薦的時候，如果只由模型進行打分控制的話，容易出現游戲扎堆的現象，也就是連續幾條feeds都是同款游戲，因此需要重排層來調整展示的順序；2）流量分配：游戲的分發涉及平臺的利益，每款游戲的曝光量會影響平臺的收入，因此需要合理分配每款游戲的展示量；3）bandint策略：主要是用于興趣試探，feeds場景會涉及多種內容類型，如何在推薦用戶歷史喜歡的內容類型以及嘗試曝光新的內容類型之間做平衡是推薦系統典型的E&E問題，這兒我們設計了一個簡單的bandint策略，下面會詳細講一下。4）運營策略：一些偏業務性質的運營策略也會在重排層體現。

推薦系統中會遇到一個經典的問題就是Exploitation（開發） VS Exploration（探索）問題，其中的Exploitation是基于已知最好策略，開發利用已知具有較高回報的item（貪婪、短期回報），而對于Exploration則不考慮曾經的經驗，勘探潛在可能高回報的item（非貪婪、長期回報），最后的目標就是要找到Exploitation & Exploration的trade-off，以達到累計回報最大化。對于游戲中心首頁feeds而言，一味推薦用戶歷史喜歡的內容類型或者大量嘗試曝光新的內容類型都是不可行的；首先用戶的興趣可能會有所波動，過去可能喜歡視頻類型，但是下一刻就可能不喜歡了；其次一味推薦用戶歷史喜歡的內容類型，可能會讓用戶產生厭倦。為了平衡兩者之間的關系，我們在重排層設計了一個簡單的策略，具體如圖9、圖10所示。

圖9：游戲中心bandit策略算法邏輯? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

圖10：游戲中心bandit策略具體實現

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

四、算法二期的迭代計劃

?目前游戲中心個性化推薦所遇到的難點以及下一步的迭代計劃主要如下：

1、外部數據的引入：

1）結合第三方數據做推薦：目前游戲中心個性化推薦的依據主要是用戶的場景表現、游戲內表現以及一些基礎的畫像數據，數據來源較為單一。引入更多的第三方業務數據（比如企鵝電競），一方面可以豐富用戶的特征維度，另一方面可以給用戶帶來體驗上的提升（用戶剛在企鵝電競看了個吃雞的直播，來到游戲中心就給推薦了“刺激戰場”）。

2）豐富推薦物料：目前游戲中心的內容來源部分存在“同質化”現象，素材類型還不是特別豐富，需要引入更多優質的外部內容。

2、多模態特征提取：游戲中心的推薦內容類型較為豐富，包括了視頻、圖文、活動、禮包等，如何在同一個特征向量空間對各個item進行信息抽取是目前遇到的難題之一。現有的解決方案是基于youtube的embedding網絡進行user、item的embedding向量學習。該網絡的輸入是無序的，也就是沒有考慮用戶歷史行為的軌跡，那么是否可以用圖來表示行為的軌跡，基于graph embedding的方法獲得信息更加豐富的item向量？目前業界也有若干基于graph embedding的推薦案例（手淘首頁、阿里湊單）。

3、內容元信息的提取：目前游戲中心對于item的特征提取要么是基于統計的特征，要么就是基于item歷史行為的embedding特征或者tag提取，對于內容本體信息的提取還較為薄弱，如何有效地提取非結構化內容的信息是下一步迭代需要考慮的問題。

4、模型的快速更新：對于用戶興趣的實時捕捉，不僅依賴于數據的實時更新，同樣依賴于模型的實時更新。目前線上的模型是按天例行更新，如何快速地訓練模型以及部署模型是后續不可避免的問題。

5、優化指標考慮收入相關因子：當前的優化指標基本是轉化率、時長等推薦系統常見的指標，但游戲中心涉及平臺收入，需要綜合考慮每個游戲的收益（類似廣告系統中的競價）。如何設計合理的優化指標（考慮游戲arpu、ltv等）以及在用戶體驗跟平臺收入之間做平衡也是下一步迭代的關鍵。

6、流量分配問題：首頁feeds場景既涉及游戲流量的分配，也涉及內容類型流量的分配，如何有效地設計流量分配方案，從而減輕重排邏輯的負擔也是需要考慮的優化點。

7、拉活還是拉新：如何根據用戶在游戲生命周期的不同階段推薦合適的內容是首頁feeds場景需要考慮的問題。

8、新品試探：目前我們只是在內容類型上做了一些簡單的策略，后續還需要調研更加成熟的解決方案來解決E&E問題。

五、總結

本文主要是對游戲中心在算法一期的接入過程所遇到的問題做一些總結，以及梳理下一步迭代的計劃。由于算法一期的重心在于算法的快速接入，因此整個個性化推薦框架中所涉及到的策略可能都略顯“著急”，希望各位同行大佬多多包涵。關于游戲中心個性化推薦問題，歡迎隨時交流。

作者簡介

zakexu，碩士畢業于華南理工大學，現任騰訊云AI算法工程師，負責騰訊云NLP的公有云產品架構以及標準化產品交付！

個人博客：https://zakexu.blog.csdn.net/

知乎ID：zakexu

掃碼查看原文

▼▼▼

（*本文為AI科技大本營轉載文章，轉載請聯系作者）

◆

精彩推薦

◆

2019 中國大數據技術大會（BDTC）再度來襲！豪華主席陣容及百位技術專家齊聚，15 場精選專題技術和行業論壇，超強干貨+技術剖析+行業實踐立體解讀，深入解析熱門技術在行業中的實踐落地。 6.6 折票限時特惠（立減1400元），學生票僅 599 元！

推薦閱讀

總結

以上是生活随笔為你收集整理的手Q游戏中心的个性化推荐实战 | CSDN博文精选的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。