我所理解的大數據個性化推薦

想起要寫這篇文章，一方面是昨天終于把項亮寫的《推薦系統實踐》給看完了，另一方面是自己負責的推薦系統項目已經處于一個多版本迭代的階段了，并且從最近的AB測試效果來看，新提交的算法模型還是有一定的進步的，如今已經把流量全部切換到了新算法中。

所以，結合看書的一些思考，以及實際操作的一些感想，總是有一些想要表達、分享的東西，不吐不快啊~~ 哈哈！

不過在說個性化推薦之前，說兩個題外話。

首先就是關于看書這個話題，我在《這些年，這些挖掘機算法，這些反思》一文中，曾經說到?？磿翘嵘晕业囊粋€最佳途徑，我說過曾給自己定了一個每月看完一本書的目標，說來慚愧，至今只能算面面強強完成任務。不過關于看書這個觀點，個人還是堅持自己的看法的。

首先是如何給自己擠出看書的時間，一是上下班地鐵的零碎時間，二是睡覺前，三是敲代碼搬磚搬累的時候。我想說的是，想要提升自己，書是一定要找時間看的。記住，這個時間不是為別人擠的，是為了未來你的薪水能夠提上那么個一兩檔而擠的！

其次，關于看書的方法。以前，我看書只是試圖理解作者的意圖，然后從中吸取能夠吸取的知識?，F在，我看書喜歡拿著一支筆，邊看邊涂涂畫畫。

我試圖去理解作者說的話，然后結合自己的認知，寫下自己的感性，甚至是依據自己的認識反駁作者的觀點，然后事后去求證。對于我不熟悉的領域，我會寫下看完后的一些體會。

然后就是對于部分章節，如果我認為其價值量并不值得我去細究，我會迅速的跳過，畢竟時間還是挺值錢的。

所以，后期以來，只要是我看過的書，一些章節要么是涂涂畫畫了很多東西，要么是嶄新的頁面?？偨Y起來就是，看書不能看死書，要有一定的效率和方法，找到適合自己的，然后從中獲益！

OK，說了不少題外話，言歸正傳。

一、由這本書想到的一些東西

先來對這本書(《推薦系統實踐》)來個整體評價吧。

個人對這本書的定位就是：它不是一本推薦系統的工具書，所以他不會詳細的介紹推薦系統的一些算法，更多的筆墨在于講述在設計個性化推薦系統中的一些衡量點、一些思維方式(這個我認為更重要，原因后面細說，甚至于書中的一些實驗參考個人認為可看可不看)。

所以，感覺這本書的題目取的有點稍稍不合理~~

好吧，咱不糾結他的書名了，說一說一些書中個人認為值得一起分享的東西吧。這些東西都是看書之后，結合實踐操作的一些感想。

并且，你會發現這章的內容，絕對不會是書中內容的重復，對于開挖掘機特別是開推薦系統挖掘機的人來說，相信我，我的觀點會有用的！

(1) 首先談一談關于推薦系統評測

我先列一下作者列舉的評測指標：用戶滿意度、預測準確度、覆蓋率、多樣性、新穎度、驚喜度、信任度、實時性、健壯性、商業目標。然后作者說，在設計推薦系統的時候，要盡量的考慮這些指標，特別是推薦的結果盡量滿足多樣性、新穎、能夠驚喜就更好了。

關于這一點，其實個人觀點有點不一樣，我認為評測推薦結果只有一個指標就夠了，那就是商業價值，能夠提升商業價值，給業務帶來更多利益的推薦系統，就是好的推薦系統。

至于說推薦的多樣性、新穎度，如果多樣化的推薦結果能夠提升價值轉換，那我們就在設計推薦系統的時候適當的提高多樣性的權重，同樣，如果新穎的東西能夠提升價值轉換，那么我們就提升新穎的權重。這才是回歸推薦系統的本質！

在這一點上，在個人的實際操作中也是這樣做的。我們會首先定好我們需要達到的目標，比如轉化率或者是收益轉換，我們調整算法的唯一依據就是：轉化率提升了？如果是，那么我們的算法改進就是有效；如果不是，那么這次改進就是一個失敗的改進。

至于說書中的每次實驗，都評估覆蓋率、多樣性以及其他等幾個指標，在我看來，其實是沒有必要的。

結合實踐來說，因為你不敢保證提升你的推薦覆蓋度就一定能夠提升轉化率，換言之，如果挖掘長尾能夠提升轉化率，那么，我們就適當提高覆蓋度，并且盡量支持多樣性。然而實際的業務場景是很復雜，這種保證并不是絕對的，需要依據于實際的情況而定，說白，那就是實際操作。

既然說到了實際操作，那我們說一說評測方法相關的東西吧。

書中列舉了三種方式：離線實驗、用戶調查、在線實驗。

首先說一下離線實驗，個人認為在推薦系統中，利用已經現成的用戶行為軌跡(即推薦之后是否點擊之類的數據)，來預測一個推薦系統并不是很靠譜，只能做為一個參考。

因為，例如推薦這種場景，并不是如分類這種的模型，沒有一個絕對值，對就是對，錯就是錯，它只是一個預測程度的提升。

其次，用戶調查這種方式，有一定參考性，但是前提是調查的量要足夠，如果取的量不夠，其意義是不大的。所以，這是一個耗費巨大成本的工程，在實際的操作中并不可取。

所以，個人認為其重點應該是在在線實驗，而且嚴格來說是AB測試。說白點就是，我們把數據分流，一部分數據走A推薦算法，一部分走B推薦算法，然后收集AB算法的推薦結果導致的用戶行為，根據核心價值一對比結果，一目了然。

但這樣，或許就有人有意見了：在線系統是一個很嚴肅的事情，怎么能在線上進行未知效果的算法實驗呢？

關于這個問題，首先，算法上線之前對于新算法肯定是需要進行一定的評估的，比如離線實驗，雖然說不能絕對依靠它，但是作為一個參考完全是可以的。

其他的一些諸如統計調研工作也是不可缺少的，在數據量較大的情況下，是能反映一些問題的，然后算法的設計總是有依據的，這些就是依據。換言之，這些前提工作能夠保證，即使你的新算法不會比現成的算法好，但也不會出現大幅度下降的情形。

如果出現了這種情況，只能說明你們的初期工作做的太爛，你們的算法設計方案是瞎搞的。

其次，我們設計的AB測試機制，必然是可以調節流量分配的，如果不是，那么設計者去面壁吧。在AB測試分流中，我們完全可以控制新算法的流量，達到一個可以觀察到效果，又能保證失誤在可控的范圍內。

(2) 冷啟動，這是一個很嚴肅的問題

關于推薦系統的冷啟動，作者專門看了一個單章來說這個問題，But，在書的最后又提出了一個觀點：忽略推薦系統冷啟動的問題，因為，只要你的推薦系統設計的足夠好，是不擔心數據問題的。

但在我認為，冷啟動是個大問題，特別是對于初入此道的人來說，是繞不開的一個問題。對于冷啟動，有一個好的機制進行解決，那么，我們的推薦系統才有一個好的開端。

諸如推薦系統中的最經典的協同推薦算法，其核心依賴就是用戶行為數據，在一個推薦系統初期，用戶行為是很少的，那么這就是我們急需解決的問題。

辣么，如何累積用戶行為數據呢？

并且，請注意，在累積用戶行為數據的前提下，我們需要盡可能的保證推薦的有效性，也就是說，讓用戶更有可能去點擊你的推薦，對于公司來說，你盡可能的創造價值，對于你本身業務來說，你也可以盡快的收集到更多的數據嘛！

舉個簡單的栗子。我要做一個類似于今日頭條這種APP，進行各種新聞頭條個性化推送。一句話，咋整？

這就是冷啟動中的冷啟動了，因為整個系統都是新的，文章是新的，用戶是新的，沒有任何用戶數據，沒有觀看記錄，沒有頂踩行為。無法體現用戶偏好，甚至于連文章是否是熱點我們都不知道。

這個時候，怎么辦？按照書中所說，利用用戶的注冊信息，然后結合商品信息，進行推薦，這個基本思路是沒有問題的。在這里，商品其實就是各種新聞頭條。

但是，這種方式局限性也很大，一方面，在注冊時信息有限，并且很多時候這種信息是帶有欺詐性質的，所以我們不能過度依賴于其。

這個時候，怎么辦？請忽略針對于用戶個性化的推薦，我們只要掌握大體趨勢就好了。那么，如何掌握大體趨勢。借助外力！

剛才說了嘛，類似今日頭條。今日頭條肯定做了類似的工作，例如在你沒有登陸的情況下，肯定同樣提供了推薦列表。并且可以肯定的是，這個推薦列表是有數據支撐的，并不是胡亂推送的。也就是意味著，這批推薦名單是比較容易被普通大眾所接受的，換言之，是能夠提升點擊率的。

那我們如何利用它呢？我們復刻一個推薦列表出來。當然，并不是要你直接把人家的文章拿過來直接放上，要是這樣，人家就該告你了。

我們可以通過計算相似度的方式，針對于今日頭條的每一個推擠，在自己的文章庫里計算一個最相似的文章出來，頂上去。不依賴于任何己方的數據，一個推薦列表就出來了。

至于說效率問題，其實類似這種新聞頭條的推薦列表，其變化并不是實時的，所以，計算的代價完全是可以承受的。

至于說如何計算相似度，那就是另外一個范疇了，這里只是提供一個思路。

說到思路，那么，通過這個栗子，我想要表達的意思也差不多了，那就是處理這種冷啟動的問題，我們的處理思路是：借助類似產品的現有成果，并以此為依據。

雖然有點無賴，但是能解決問題，無賴就無賴吧~~

在收集到第一手行為軌跡之后，往后的事就方便多了，該怎么滴怎么滴吧~~

(3) 上下文信息與規則打分模型的關系

書中有提到，所謂上下文信息，主要兩方面：時間上下文，地點上下文。

在我認為，其實是遠遠不夠的，一切可能對于結果有影響的第三方因素都是可以參考的。所謂第三方因素，個人認為可以定義為：與用戶個性化沒有顯性關聯的因子。比如前文說到的時間、地點，又如季節、天氣等等諸如此類。

說到這些，不得不說到規則打分模型。

說到規則打分模型，簡單解釋一下吧。所謂規則，即我們自己定義的一系列操作規范；至于打分，則意味著有某項操作，我們就給某項操作加分。最后看看誰的分多，我們就選擇誰。換個專業點的術語就是規則權重模型，好吧，其實就是權重計算。

很簡單是吧，但是別忽略它的重要性。個人從來就不認為推薦系統就是協同推薦之類的算法作為代表。

推薦系統，這是一個浩大的工程，以協同推薦為代表的算法只是其中的一個因子，它必然是綜合了各種各樣的東西的。而權重模型是一個很簡單，很原始又很有效的方式。

如何定義不同外在因子對于推薦結果的影響，也就是如何針對于不同外在因子賦予其應有的權重比。這需要數據的統計！

特別是在當期大數據的背景下，這種基于統計的規則權重模型愈顯有效。大規模的數據統計是能夠體現數據趨勢的，這點毋庸置疑！

好吧，我承認，這也是為何我把題目中數據加了個“字”的直接原因。

并且在實際的操作中，很多推薦系統的結果都是通過規則權重模型呈現的；還有就是多種推薦方式時，是通過規則權重模型把多種方式結果整合，以達到結果最優化。

所以，在你的推薦系統算法沒有絲毫思路的時候，何不嘗試嘗試走規則權重模型的路子？通過權重模型去修正你的推薦結果，你會有驚喜的！

(4) 無處不在的長尾以及馬太效應

長尾分布或者說長尾效應，這個名詞解釋應該不用我多說了吧。實際上，在現實生活中，這是一個很常見的現象。

然后長尾分布導致的直接結果就是馬太效應，即通俗點說就是強者愈強，弱者愈弱。

即，比如一些熱點物品，其附帶的行為數據越多，其得到的推薦機會就越大，然后被展現的機會越多，然后再次被推薦的機會越多，然后…陷入死循環了，其他物品還有存在的必要嗎？！

所以，作者在實驗結果中除了準確率，另外一直很強調的一個指標就是：覆蓋率或者說多樣性(這也是為何我我一直跳過他實驗描述部分的原因，感覺參考意義不大)。

對于說我們是否需要挖掘長尾，我的觀點跟我之前提到的依然一致：如果挖掘長尾有益提升我們的商業價值，那我們就想方法提高覆蓋度，換言之就是降低熱點物品的權重；如果挖掘長尾對于我們提升價值轉換并沒有益處，那我們為何要這么做。

極端點的栗子就是：假如我每天推薦的是固定這幾個物品，從不改變，但是，它創造的價值比其他任何流弊推薦系統產生的價值都高，那么，它就是一個好的推薦！

這又回歸到了我之前的觀點：衡量推薦系統好壞的唯一標準就是，它是否能夠提升價值轉換！

那么，我到底該不該挖掘長尾呢，大家都挖？還問這個問題的人一定是個死腦筋。是否挖掘長尾，看業務場景，然后進行充分的AB測試，來決定是否提升覆蓋度、多樣性，提升多少，這一切的標準唯一衡量就是，它能給我帶來更多的money嗎？

如果它能給我帶來更多的money，長尾就長尾吧，馬太就馬太吧，又何妨？

二、我那悲慘的推薦系統實踐經歷

寫這個之前，我仔細的反思一下，我策劃并且實施的那個推薦系統算是推薦系統嗎？然后我想了想，感覺應該還算是，只不過不是典型推薦系統，但是在整個實施的過程中，思考的方式還是可以借鑒的。

并且，可以預見的是，實際的工程操作哪有像教科書似得，都是特定場景，特定條件下的產物。也就是說，沒有通用的推薦系統，即使有，肯定也是不好用的！

我想，在整個過程中，一些思考，一些處理問題的方式，對大家在以后類似工程的實施中還是有一些參考意義的。

所以，我還是決定把它寫下來~~

(1) 業務場景是這樣滴

還記得那會兒是三月份還是二月份來著，我所在的A公司上線了在線教育頻道，一段時間后，主持運營在線教育的B君突發感想，博客頻道辣么多流量，隨隨便便不就可以引一大坨流量過來了嗎？于是乎，任務跑到了我所在的數據部。

需要說明的是，A公司主要是做IT技術論壇社區博客的，而在線教育客戶也是程序猿，所以業務上并不沖突，這個引流思路也是對的。

言歸正傳。

我當時一看，這不是推薦系統么！然后再仔細一看，這是推薦系統嗎？好吧，我承認，有點繞口了。

我們首先來回顧一遍，我們正經的推薦系統是什么樣的。吃個栗子，啊不，舉個栗子：我們在一個視頻網站上看視頻，然后下面給你推薦了一坨視頻，可能是根據你的偏好，也可能是根據網站用戶的數據給你推，反正不管，這是正經的推薦系統；你在某寶買東西，然后瀏覽物品的時候，下面列出一坨東西，這是正經的推薦系統；等等諸如此類。

然后再回到我們的場景，我在瀏覽一片IT技術博文，然后下面你給我推薦一坨在線教育視頻。這叫啥事兒！

對比一下發現了沒有，上述的場景跟我們的場景哪里不一樣？是的，他們推的東西都是一類，而我們的東西完全是兩套東西，一個是IT技術博文，一個IT在線培訓視頻，他們有著不同的屬性。

如果運營在線教育B君說，blogchong sir，我想在我們在線教育頻道做視頻的推薦，來給整一套吧。

那我會很愉快地按照行業標準，迅速的整一個推薦系統出來，然后按部就班的調算法，優化效果，從此過上快樂的生活！

But，事實擺在眼前，需要面對就是這么一個業務場景。我仔細想了想，這是一個推薦系統，只不過是一個不那么正兒八經的推薦系統。

然后設計方案、組織人手、推動項目進行等這個活落到我頭上了。這是上天的安排，對我的考驗嗎？事實上是組織給我的安排，對我的考驗。頓時淚牛滿面~~

好吧，那就干吧！

(2) JUST OT IT

在那之前，雖然對于數據挖掘領域有所涉獵，但是在推薦這一塊，還是處于基本理論了解到水平，并且當前部門里并沒有其他太多的可參考的東西。

我開始著手調研這個業務場景，然后很杯具的發現，業內基本沒有出現類似的這種業務場景。是的，有誰能夠想到要從X事物關聯到Y事物啊，但事實就是如此。

然后我開始分析，在博客與視頻之間到底有什么樣的聯系。我挨個梳理兩者的屬性列表，然后發現他們其實還是有共同點的，比如：他們主要IT方向的，他們都有中文Title，都有tag，都有des也就是詳細地中文描述。

是的，我們無法從業界進行參考，我們無法通過用戶行為進行參考(相當冷的啟動)，那么他們兩唯一的關聯就是主題了。

拋開用戶行為，推薦相同或者相似主題的內容，這是不會錯的，這是推薦系統的常規方式之一。

于是按照這個思路，我開始做設計。一開始，對于很多方面的思考都不成熟，所以映射也比較簡單，直接通過博客的tag去找視頻。

方案開始實施，考慮到后期視頻內容量的增長，我使用博文tag通過搜索引擎的方式聚合出視頻，于是推薦列表有了。

產品經理C君說，光通過博文進行推薦不行啊，我們需要考慮那些熱點視頻。好吧，那就加上吧，于是，我在推薦列表中加了一部分觀看次數TopN的視頻。

C君又說，光有博文推薦出來以及最熱視頻也不行啊，我們得考慮用戶。于是，我和擅長數據批量處理D君把公司里所有活躍用戶近一個月的博文瀏覽行為跑了一遍，其實就是看用戶看了寫了那些博文，并且對所有博文tag根據讀寫不同權重進行排序，選擇前N作為用戶的核心技能。而且，我們在調度中心做成了定時任務，定時更新用戶畫像中技能字段。

好吧，用戶的tag也有了，剩下的過程與博文沒啥區別了。

接著需要考慮的問題就是，三種方式得來的列表，我們該怎么分配，因為推薦位就那么幾個，總的分一分吧。

然后C君說，拍腦袋吧，于是，我們拍腦袋給他們定了個權重。

只怪我當初太年輕，太好騙，啥也不懂~~

好吧，不管怎么樣，我們的第一版推薦系統正式上線了(沒法離線評測)，然后我讓BI小組的G君給網頁上埋了點，進行結果收集。

BI報表出來了，結果差強人意，這是顯然的。

(3) 工作還得繼續

我和數據分析小組的E妹一起跟蹤行為歷史log，發現了其實很多博文很多用戶根本就沒有tag，這樣會導致我們都給人家推的是Hot數據。換言之，很多根本是毫不相干的。

于是，我開始著手解決這個問題。沒有tag，那我就給造tag。在推薦的時候，我通過博文的Title，進行分詞，并且把停用詞去掉，把分出來的詞填充到臨時tag中，用于視頻的聚合，并且通過直覺略微調整了下三種方式的權重。

結果又好了辣么一點點。

這事被F君知道了，他說，如果要獲取一個比較客觀的博文主題，為何不從整個博文中進行抽取呢？有道理！

我跟D君開始進行主題抽取的研究，并且最終又把800G的較新博文跑了一遍，在數據中心為它填充了一個新的主題詞描述字段。媽媽再也不用擔心我的tag了！

于是乎，我們的結果又好了辣么一點點。

又過了一段時間，數據分析小組的G妹通過分析發現，其實很多視頻課程跟我們的博文相關度并不是很大的。我說不對啊，我們抽取tag詞中，雖然有些不相關的詞，但是基本上對應的技能大部分還是比較靠譜的呀。

然后我再梳理了一遍通過tag詞聚合視頻課程的過程，確實存在課程不是很匹配的情況。

原因在于主題詞抽取雖然大部分情況下都把對應的技能詞給提取出來了，但是權重排序很難做到很準確，而我們的檢索引擎匹配又是匹配更多的詞的結果，權重會較高。

于是，我認為應該把主題詞分主次。舉個簡單栗子，假如主題詞有三個：hadoop、應用、開發。那么，我完全可以認為，hadoop其實才是最主要的詞，其他兩個都是次要的。

就比如，我希望匹配到是hadoop視頻課程，而目前結果恰巧那種“XX應用開發視頻教程”會排在前面。當然，如果能完全命中“hadoop應用開發教程”，那就更好了。

我跟G妹開始梳理在線視頻教育的技術點，把認為能夠體現技術特征的詞整理成了一份數百詞的核心詞字典。

于是，在聚合邏輯上，我會優先考慮核心詞的命中，然后才考慮次要的詞。這樣，我們的結果似乎又好了一點點。

后續，我們又做了一些小的修改，但發現，結果提升的幅度越來越小。

如果按照這個路子下去，估計我們的結果也就這樣了。

里程碑式的跨越，是在我跟F君進行的一次深度的討論。

(4) 里程碑式的跨越

在討論之中，我們在深刻反思，我們的路子走的對不對。假設在主題詞提取的足夠正確的前提下，我們是否全盤考慮了所有詞對于視頻匹配的貢獻呢？

然后關于視頻屬性的命中，我們又在考慮，命中位置對于匹配度的貢獻是一樣的嗎？

除了視頻中文相關的一些中文描述，難道沒有其他的一些屬性能夠給我們的推薦建議帶來一絲貢獻嗎？

于是，我一方面讓D君繼續優化主題提取的準確率，一方面思考新的設計方案，推翻原來的方案基礎上進行思考。

常規的協同推薦路子走不通，那我們就走規則權重模型。在這個方向偷摸滾打這么久，總是需要長點記性的。

于是我列舉了一些可能為模型帶來貢獻的屬性，并且初步設計了一個嵌套了兩層的規則權重模型。通過幾次的小組會議，增刪了一些屬性，并且稍微的修改了一下模型。

其中需要說明的就是，我添加了不少視頻中與博文沒有任何關系的屬性，我們的目的在于，這些屬性或多或少都是有影響的。

于是我著手開始進行視頻相同統計屬性的量化操作，諸如發布時間無窮增長的值，諸如是否收費這樣的二值屬性，進行0到1之間的量化。

有了量化，我們的E妹就可以根據數據分析，那些指標跟點擊率是正相關的，那些是無相關的。我們進一步刨除了一些無相關的統計屬性。

對于初始階段，我們沒有任何數據可以參考進行權重設計，于是在慎重考慮之后，我為嵌套的兩層規則模型設計了一個看起來比較合理的權重比。

然后在數據初篩的階段，使用每一個主題詞進行視頻N值提取，然后在N*M個初篩的視頻中，根據規則模型對N*M個視頻進行打分(這會犧牲一部分性能，但是這種思路為部門內部搜索優化項目提供了參考)。然后按照要求的個數進行截取就OK了。

其中有一點需要說明的就是，在我們的場景中，登陸用戶的比重與游客的比重是1/60，所以，我們的重心一直不在用戶身上，這個就不多說了。

還有一個跨越式的進展就是，我設計了AB分流測試機制。當時回想一下，冷汗淋淋啊，之前辣么多的版本，我們就這樣悶頭直上了，那可是線上的系統啊。之所以沒有出問題，一大部分原因就是，在新版本中，我們進行了足夠的思考。

好了，如今，有了AB分流機制，我在保證系統不受大影響的情形下，在轉化率可能下降并且可接受的范圍內，為新模型分了1/4的流量。別小看這四分之一的流量，那可是上百萬的流量啊。

不用等多久，因為我提前讓G君埋好了點，第二天我們就看到了效果，具體的數值俺就不多說了。我們果斷的把流量全部切到了新模型中。

此后，我們的工作重點在于如何有效優化權重比例。這一點，我跟E妹進行討論分析，最后E妹的敏捷思維還是說服了我。

E妹說，我們是在有數據傾向的前提下來預測權重值，這不就是邏輯回歸嘛，跟計算邏輯回歸的參數有何區別呢？啊不，區別還是有的，區別就是我們需要的是正參數。

好吧，后續的我就不多說了，再說這就是一篇小說了。

后續我們又做了一些其他思考，比如我們認為技術應該是分層級，加入一個技術水平分高中低三級，如果博文體現出來的技術水平是初級的，那我們是不是應該適當的給人家推薦對應中級的技術視頻。

又諸如，技術之間是有關聯的，人家看hadoop的博文，是不是可以適當的給人家推薦spark的視頻課程？這種關系如何提??？

其中涉及到的技術以及其他種種，我就不多說了，再說下去，我就得寫到凌晨兩點了。

(5) 做一個象征性的總結吧

也不算是總結吧，整個過程反倒像是我在記流水賬了。但不管怎么樣，有些觀點我認為還是有意義的。

首先對于我們不熟悉的領域，我們需要果斷的去做，有些東西是需要吃過一點虧才明白的，畢竟書上的東西只是書上的東西，這句話可明白？

其次，在做新算法改進，乃至于其他改進，或者諸如其他項目時，我們需要經過慎重的思考，然后再做方案，然后再實施。這也是為何我們在AB測試機制出來之前，無數次“勇敢”上線，覆蓋線上版本，而沒有出問題，效果沒有下跌的直接原因。

針對于推薦系統的設計，我想說的就是，我們需要解決的是主要矛盾。針對于我們的這個項目實踐來說就是，我們的一切努力方向就是提升流量從博客頻道到在線教育頻道的轉化率。