如何為技術博客設計一個推薦系統（中）：基於 Google 搜索的半自動推薦

01-29

過去的兩周里，我一直忙於為『玩點什麼』設計一個推薦系統（即，recommend system）。在這個過程中，參考了之前的幾本書籍，查找了一系列的資料。想著這些資料上，大部分都是大同小異的，實現了幾個簡單的推薦功能，改進了標籤推薦演算法，便想著寫篇文章記錄一下。

與統計學相比，基於內容來向用戶推薦相似的內容，往往更容易獲得。對於推薦來說，則有兩種方式：

手動推薦
自動推薦

（PS：我承認，這句話說了等於沒說。）

如下圖所示：

手動推薦。在技術領域，作者通常比大多數讀者更專業，他們往往知道什麼是讀者需要的。如，你看了一個 React 相關的文章，你可能會需要 Redux 相關的內容。

自動推薦。需要一些前提條件：融合現有系統的數據信息，獲取一些用戶的信息。隨後，再計算出相關的內容，最後返回給讀者。

而在這篇文章里，我們將介紹：

標籤生成的方式
基於手動標籤推薦
半自動的標籤推薦
全自動的基於內容推薦

標籤生成

文章與我們平時使用的物品，有很大的不同之處。如手機，擁有固定的規格參數，價格、屏幕尺寸、運行內存（RAM）、機身內存、CPU、後置攝像頭像素、前置攝像頭像素等等，我們可以輕易地通過這些特徵，了解用戶大概需要什麼東西。如果用戶瀏覽的是 2880 的某 pro 7 手機，那麼某米 6 的手機可能更適合該用戶。

而文章是一種非結構化的數據，除了作者、寫作日期這一類的信息，我們很難直接描述其特性，也就難以判定文章之間是否是相似的。因此，我們就需要從文章中抽取出關鍵詞，或稱為標籤，從而判斷出用戶喜歡的是某一種類別。

對於使用標籤來向用戶推薦產品的應用來說，標籤生成方式有四種方式：

手動標籤
機器生成推薦
用戶手動標記（UGC）
混合學習式

手動標籤

即，用作者、發布者手動添加相關標籤，這種方式往往是最靠譜的。畢竟作者會比較專業，如文章《在 Raspberry Pi 上使用 AVS Device SDK 製作 Alexa 智能音箱》，對於讀者來說，他們可能除了 Raspberry Pi，就不懂上面的其它東西，而作者標註了它的關鍵詞（標籤）是 avs device sdk、amazon alexa、amazon voice services、raspberry pi。從某種意義上來說，它相當於這篇文件的特徵，從這幾個關鍵詞我們就可以推斷出文章的大致內容了。

對於商品來說，也是相似的，在上架的時候，就擁有了相應的產品數據，如價格、類型、時間等等。

機器生成推薦

這種方式，會根據文章的內容、標題等信息，提取出相應的標籤。再按一定的權重來計算相關性，比如標籤中所含有的關鍵詞，其相關性會比較強，那麼其權重也應該比較大。那麼，如果兩篇文章里的標籤含有的內容關鍵詞相似，那麼對於用戶來說，他們也可能是相似的。這也就是，我們後面會講到的『基於內容的推薦』。

用戶手動標記（UGC）

對於那些沒有內容的產品來說，他們依賴於用戶手動標記的標籤和評論。諸如豆瓣上的電影、圖書等等，都只能由用戶手動標記，才能找到相似的內容，並推薦給用戶。

於是，這個時候如果一本新書沒有用戶評價，那麼它可能就沒有辦法推薦給相應的用戶。因此這些內容需要進行標籤『冷啟動』方面的探索，諸如生成一些標籤等等。因此，對於那些不能由內容來判定用戶喜歡的，則會在用戶註冊完後，讓用戶手機選擇感興趣的標籤。

混合學習式

在手動標籤的情況下，如果是 UGC 的內容，那麼為了更多的訪問量，用戶可能會有意、無意地加上一些無關的標籤。如 A 標籤的關注用戶比較多，相關的它的流量也會比較大，那麼貼上 A 標籤的文章，也會獲得更多的關注。但是由於文章本身與 A 標籤無關時，必然會導致用戶的不滿。而這個時候，如果普通的用戶能判定該文章，是否是相關文章時，必然能某種程度上降低這種影響。

相似的，如上我們提到機器在生成標籤的時候，也會出現一定的問題。因此，最好的方式就是結合上述的幾種不同的標記方式。

基於手動標籤推薦：標籤數量相關

由於我使用的基於 Django 的 CMS 里，已經包含了後台手動推薦相關文章的功能。因此，我的想法是，先基於某幾個特定的標籤的數量，來篩選中相關的文章。

在我的第一個原型里，採用的方式比較原始：

獲取文章的所有標籤
對所有文章的標籤進行統計，計數
獲取文章標籤中計數最多的 tag，查找相同標籤的博客
在剩餘的博客中，選擇第二多 tag，再過濾剩餘的博客

可這樣的推薦演算法會出現一些問題：如果同一系列的文章太多，如網上各類的 Vue 高仿站點，那麼用戶可能已經掌握了，文章的價值就沒有那麼高，或者可能如雞湯一樣沒有價值。如在『玩點什麼』的文章中，出現一系列的 home assistant、raspberry pi 相關的文章，它也不能體現出一些差異。

缺點

在站點內，該演算法有其特定的意義：標籤數量多。但是它並不能真正地解決用戶的問題？能體現地體現出網站的價值，但是不一定是對於用戶是有價值的。

假如用戶搜索了一篇 raspberry pi + homebridge 的文章，那麼它確實可以閱讀一些相關的文章，而諸如 raspberry pi alexa gpio 從上圖來看似乎是一個用戶更加喜歡的選擇。

而，在這種時候由編輯推薦出來的，反而比較準確。與商品不同的是，文章的手動推薦，往往會是讀者可能感舉的內容。那麼，我們就能留得住用戶，同時獲得更可觀的用戶行為流。

上圖是『玩點什麼的』用戶行為流：

起始頁面，在 387 次會話中，有 260 次用戶中途離開
首次互動，在 127 次會話中，有 47 次用戶中途離開
第 2 次互動，在 80 次會話中，有 31 次用戶中途離開

這意味著，有 32% 的用戶在訪問了某個頁面後，又訪問了其它頁面；而有 20% 的用戶在上面的基礎上，又訪問了某個頁面。如果能在這之上，完善推薦系統將首次互動提高至 50%，那麼就會有相當可觀的流量了。

為了改進我們的演算法的準確性，這個時候我們可能需要一些額外的東西：權重，於是就需要一個加權計演算法。對於文章來說，有一種簡單的加權方式，就是計算標題中的關鍵詞。可是我強烈的懷疑這種方式，是不能真正地起到作用的。單一的關鍵詞，只對於網站本身是有價值的，對於用戶來說，則不是如此。

半自動標籤推薦：基於 Google 搜索權重優化

於是，在我使用 Google Analtyics 的時候，我突然想到可以通過 Google Search Console 來獲取用戶搜索的關鍵詞。即：

如下表所示，會在 Google Search Console 寫明其相應的位置、點擊率、出現次數等等的信息：

作為一個專業的程序員，我們搜索內容的時候，都會採用『關鍵詞』這種面向機器的介面方式。而作為一個專業的 md 程序員及 SEO 專家，在編寫文章標題的時候，我們也應該在標題上寫上關鍵詞。

如對應於上面的第一個搜索結果 homebridge-miio，它的標題是《Homekit + Siri 控制小米插座：基於 HomeBridge 與 homebridge-miio》；相似的，用戶在 Google 上搜索 home assistant broadlink 的時候，它對應的文章標題便是《Raspberry Pi + Home Assistant 智能家居（二）：萬能搖控 Broadlink RM Pro 紅外控制所有家電》，以此類推。

因此，這才是真正有『價值』的權重。

更新權重

於是便下載 CSV，創建新的 model，導入到資料庫中。然後，做了一個簡單的權重演算法：

第一個關鍵詞 = 關鍵詞次數 * 0.25 + 關鍵詞查詢次數 * 0.75

代碼如下所示：

for keyword in keywords:n related_queries = Query.objects.filter(queries__contains=keyword.title)n keywords[index].item_count *= 0.75nn if related_queries:n for query in related_queries:n keywords[index].item_count += query.clicks * 0.25nn if index > 1 and keywords[index].item_count > keywords[index - 1].item_count:n top_rank_keyword = keywords[index].titlenn index += 1n

代碼中的，第二個關鍵詞則仍然是『按頻率取詞』，如果出現與第一關鍵詞重複，則選用第二頻率的關鍵詞~~

考慮了 Google Search Console 的搜索結果相當有意義。便順手也做了一個相關性搜索，當用戶搜索 Raspberry Pi，那麼它可能還會結合 Arduino ?? 那麼，它可以在網站的右側，為用戶顯示出可感興趣的搜索內容。

不過，這個關鍵詞表的最大意義在於，找出用戶最需要的關鍵詞；同時，也能幫我們找到，那些能在 Google 排到個好位置的詞語。

更多推薦系統相關的精彩內容，請期待下一篇『基於內容的推薦與協同過濾』。

原文鏈接：如何為技術博客設計一個推薦系統（中）：基於 Google 搜索的半自動推薦