推荐系统之标签体系
為什么要先介紹標簽體系？
一個推薦系統效果好與壞最基本的保障、最基礎的是什么？如果讓我來回答，一定是標簽體系。我這里說的標簽主要是針對物料的，對于電商平臺來說就是商品；對于音樂平臺來說就是每一個首歌，對于新聞資訊平臺來說就是每一條新聞。下一篇要介紹的是用戶畫像，畫像中那些用戶實時變化的興趣點大都也是來自于標簽體系，依據用戶長期和短期行為中對于物料搜索、點擊、收藏、評論、轉發等事件，將物料的標簽傳導到用戶畫像上，就構成了用戶的實時畫像和離線畫像中的各個動態維度。
標簽體系概覽
以京東的標簽體系中的京東超市為例用思維導圖來拆解，后面我們會詳細的介紹如何構建標簽體系。
這里對京東超市標簽拆解粒度到三只松鼠年貨大禮包的實體級別，實際上各個公司的標簽體系大致都是如下構成
一、二、三級分類體系都很好理解，參考京東超市的拆解，相信大家就會明白。標簽體系中實體標簽和概念標簽不好理解。
實體標簽
必須是名詞，且必須是唯一指代。
學術性的解釋逼格高，但是不容易理解，回答下面的問題
老板問：蘋果，是實體標簽嗎？
給你三秒鐘思考
你回答：是！
老板說：錯！
你懵逼：靠！為啥不是？
實體標簽的要求：名詞，且唯一指代。
蘋果，是名詞，但不是唯一指代，蘋果 = 科技公司、手機、水果、牛仔褲
概念標簽
難道我就不能用“蘋果”了嗎？當然可以用，只不過要給它另外起個名字：概念標簽。
概念標簽通常表示的是“一類”或“某種相似”的內容，例如
主題詞
這里以之家的標簽體系舉例，要給買車用戶推薦評測導購（一級）的文章，用戶畫像中車的品牌（二級）偏好太粗，而實體標簽如奔馳GLC又太細，填補這中間的粒度空白，滿足用戶購車意圖的畫像，就加入“代步優選”的主題詞，這樣不僅保持了推薦的多樣性，又不至于過分精準而導致的極度收斂。
以上大致介紹了一下標簽體系，那么我們接下介紹一下如何構建標簽體系以及其構建過程中應遵循的一些原則。
標簽體系構建原則
原則一、放棄?而全的框架，以業務場景倒推標簽需求
原則二、標簽生成自助化，解決效率和溝通成本
原則三、有效的標簽管理機制
分別解釋以下為什么提煉出這三個原則，分別用于解決什么問題？
關于第一項原則：
每個公司的產品、運營、商務對標簽的訴求有較大的差異，同時不同的運營團隊的訴求也存在很大差異，?而全的標簽框架實際是站在用戶視角搭建的，但是標簽的真正應用者是業務方，所以應該從業務視角來實現。
因此最佳的處理方式是，我們應該放棄頂層的用戶抽象視角，針對各業務線或部門的訴求和實際的應用場景，分別將標簽聚類起來提供給相應部門。
之家就是非常典型的情況，商業同學更關心用戶的消費能力相關的標簽；自駕游負責同學更關心用戶的位置和出行相關的標簽；車友圈的同學更關注用戶的社交活躍相關的標簽；所以不可能一套標簽覆蓋整個運營團隊， 這種以業務場景倒推標簽需求的方法，能夠與業務場景貼合更緊密，可用性上升。
關于第二項原則：
1.標簽生成的自助化能夠讓溝通成本降最低。前面講到各業務線對標簽的定義的理解不同，需要標簽系統建設團隊花費大量的時間溝通。如果能夠讓業務方自己定義規則，這必然是溝通成本最低的方式。
2.標簽生成的自助化，可重復修改的規則，降低無效標簽的堆積。業務一直在發展，如果規則一成不變則很難跟上業務節奏的變化。我曾拜訪過一家電商，他們發現半年前定義“母嬰客戶群”的轉化率一直在降低，因此根據實際情況重新修改和定義了“母嬰客戶群”規則，并命名為“母嬰客戶群（新）”，這時之前的規則是無效的，且會一直占據計算資源……諸如此類，如果支持規則重復修改的話，這一類無效標簽就會大量地消失。
3.釋放數據團隊人力，釋放業務團隊的想象力。數據團隊應該花較多的精力在企業的整個數據中臺或新業務模型方面，而不是處理各業務線的標簽訴求和標簽維護上，自動化的標簽生成能夠極大限度地節省人力和釋放團隊想象力。
關于第三項原則：
1.規則及元信息維護：標簽相關的規則和元信息要盡可能的暴露給使用者，讓使用者在使用的時候，能清楚知道標簽的規則是什么、創建者是誰、維護者是誰、標簽的更新頻率周期等，而不是沒有規則，或者將規則存在標簽建設團隊內部的一個 word 文檔中。
2.調度機制及信息同步：標簽之間有一些關聯，標簽之間的鏈條斷裂，是否有個調度機制或者信息同步機制讓大家的工作不被影響。
3.高效統一的輸出接口：將所有的業務信息和用戶數據信息匯總在一起，有統一的輸出接口，改變之前需要針對不同的業務系統開發不同接口的情況。
我們回顧標簽體系構建的三原則，本質上是解決了價值、手段、可持續性三方面的問題：以業務場景倒推需求，讓業務方用起來作為最終目標，讓標簽系統價值得以實現；標簽生成的自助化，它解決的是我們用什么樣的手段去實現價值；有效的標簽管理機制，意味著一套標簽體系能否可持續性地在一家企業里面運作下去。
總之，對企業最重要的是：一套標簽系統能不能在業務上用起來，能不能覆蓋更廣泛的需求，而不是一個大而全的框架。
標簽體系構建的方法
標簽體系的實施架構
標簽體系架構可以分為三個部分：數據加工層，數據服務層，數據應用層。每個層面面向用戶對象不一樣，處理事務有所不同。層級越往下，與業務的耦合度就越小。層級越往上，業務關聯性就越強
以某電商公司為例
數據加工層。數據加工層收集，清洗和提取來處理數據。M公司有多個產品線：電商交易，電子書閱讀，金融支付，智能硬件等等。每個產品線的業務數據又是分屬在不同位置。為了搭建完善的用戶標簽體系，需要盡可能匯總最大范圍內的數據。同時每個產品線的也要集合所有端的數據，比如：App，web，微信，其它第三方合作渠道。
收集了所有數據之后，需要經過清洗：去重，去刷單數據，去無效數據，去異常數據等等。然后再是提取特征數據，這部分就要根據產品和運營人員提的業務數據要求來做就好。
數據業務層。數據加工層為業務層提供最基礎數據能力，提供數據原材料。業務層屬于公共資源層，并不歸屬某個產品或業務線。它主要用來維護整個標簽體系，集中在一個地方來進行管理。
在這一層，運營人員和產品能夠參與進來，提出業務要求：將原材料進行切割。主要完成以下核心任務：
定義業務方需要的標簽。
創建標簽實例。
執行業務標簽實例，提供相應數據。
數據應用層。應用層的任務是賦予產品和運營人員標簽的工具能力，聚合業務數據，轉化為用戶的槍火彈藥，提供數據應用服務。
業務方能夠根據自己的需求來使用，共享業務標簽，但彼此業務又互不影響。實踐中可應用到以下幾塊：
智能營銷
Feed流推薦
個性化消息push
標簽體系的設計
1.業務梳理
以業務需求為導向，可以按下面的思路來梳理標簽體系：
有哪些產品線？產品線有哪些來源渠道？一一列出。
每個產品線有哪些業務對象？比如用戶，商品。
最后再根據對象聚合業務，每個對象涉及哪些業務？每個業務下哪些業務數據和用戶行為？
結果類似如下：
2.標簽分類
按業務需求梳理了業務數據后，可以繼續按照業務產出對象的屬性來進行分類，主要目的：
方便管理標簽，便于維護和擴展。
結構清晰，展示標簽之間的關聯關系。
為標簽建模提供子集。方便獨立計算某個標簽下的屬性偏好或者權重。
梳理標簽分類時，盡可能按照MECE原則，相互獨立，完全窮盡。每一個子集的組合都能覆蓋到父集所有數據。標簽深度控制在四級比較合適，方便管理，到了第四級就是具體的標簽實例。
3.標簽的模型
按數據的實效性來看，標簽可分為
靜態屬性標簽。長期甚至永遠都不會發生改變。比如性別，出生日期，這些數據都是既定的事實，幾乎不會改變。
動態屬性標簽。存在有效期，需要定期地更新，保證標簽的有效性。比如用戶的購買力，用戶的活躍情況。
從數據提取維度來看，標簽數據又可以分為類型。
事實標簽。既定事實，從原始數據中提取。比如通過用戶設置獲取性別，通過實名認證獲取生日，星座等信息。
模型標簽。沒有對應數據，需要定義規則，建立模型來計算得出標簽實例。比如支付偏好度。
預測標簽。參考已有事實數據，來預測用戶的行為或偏好。比如用戶a的歷史購物行為與群體A相似，使用協同過濾算法，預測用戶a也會喜歡某件物品。
4.標簽的處理
為什么要從兩個維度來對標簽區分？這是為了方便用戶標簽的進一步處理。
靜態動態的劃分是面向業務維度，便于運營人員理解業務。這一點能幫助他們：
理解標簽體系的設計。
表達自己的需求。
事實標簽，模型標簽，預測標簽是面向數據處理維度，便于技術人員理解標簽模塊功能分類，幫助他們：
設計合理數據處理單元，相互獨立，協同處理。
標簽的及時更新及數據響應的效率。
以上面的標簽圖表為例，面臨以下問題：
屬性信息缺失怎么辦？比如，現實中總有用戶未設置用戶性別，那怎么才能知道用戶的性別呢？
行為屬性，消費屬性的標簽能不能靈活設置？比如，活躍運營中需要做A/B test，不能將品牌偏好規則寫死，怎么辦？
既有的屬性創建不了我想要的標簽？比如，用戶消費能力需要綜合結合多項業務的數據才合理，如何解決？
模型標簽的定義解決的就是從無到有的問題。建立模型，計算用戶相應屬性匹配度。現實中，事實標簽也存在數據缺失情況。
比如用戶性別未知，但是可以根據用戶瀏覽商品，購買商品的歷史行為來計算性別偏好度。當用戶購買的女性化妝品和內衣較多，偏好值趨近于性別女，即可以推斷用戶性別為女。模型計算規則的開放解決的是標簽靈活配置的問題。運營人員能夠根據自己的需求，靈活更改標簽實例的定義規則。比如圖表中支付頻度實例的規則定義，可以做到：
時間的開放。支持時間任意選擇：昨天，前天，近x天，自定義某段時間等等。
支付筆數的開放。大于，等于，小于某個值，或者在某兩個值區間。
標簽的組合解決就是標簽擴展的問題。除了原有屬性的規則定義，還可以使用對多個標簽進行組合，創建新的復合型標簽。比如定義用戶的消費能力等級。
標簽最終呈現的形態要滿足兩個需求：
標簽的最小顆粒度要觸達到具體業務事實數據，同時支持對應標簽實例的規則自定義。
不同的標簽可以相互自由組合為新的標簽，同時支持標簽間的關系，權重自定義。
推薦閱讀：
基于Spark的大規模推薦系統特征工程
基于Flink商品實時推薦系統項目
微信看一看：推薦系統用戶畫像構建指南
總結
- 上一篇： 一个程序员的日常书单(更新于2018/1
- 下一篇： Oracle-12：伪列rowid和ro