以下內容均基於百度關鍵詞推薦系統進行討論
本文內容主要集中在使用機器學習方法判斷兩個短文本的相關性爲基礎構建商業關鍵詞推薦系統。 爲方便讀者理解， 會先介紹該技術的具體應用背景及場景。
廣告主在百度或google上進行廣告投放時， 需要選擇關鍵詞， 以向搜索引擎表述自己想要覆蓋的有商業價值的網民搜索流量。 在選擇關鍵詞後， 還需要設定具體的關鍵詞匹配模式， 以告訴搜索引擎選擇的關鍵詞以何種方式去匹配網民的搜索。 舉個例子： 網民在百度上搜索 ‘鮮花快送’， 假設商家A是賣花的， 搞鮮花速遞業務的， 則A可以在百度鳳巢系統中選擇‘鮮花快送’這個關鍵詞，同時設定匹配模式爲精確匹配(即網民搜索和A在鳳巢系統中選擇的關鍵詞完全一致時纔出A的廣告， 更多細節參見：http://yingxiao.baidu.com/)，
假設B在鳳巢中未選擇‘鮮花快遞’， 但選擇了‘鮮花速遞’， 假設B選擇了廣泛匹配（語義近似即匹配，具體參見http://yingxiao.baidu.com/）， 則B的廣告也會被觸發（具體是否會展現， 還和出價， 質量度等諸多因素有關）
此時會面臨一個問題： 廣告主在鳳巢系統中選擇關鍵詞時， 僅憑自己去想， 很難完全想到所有符合自己需求的關鍵詞（網民的搜索query千奇百怪）， 故需要提供工具， 幫助鳳巢客戶快速找到和自己推廣意圖一致或相近的關鍵詞，即： 關鍵詞推薦工具。
從交互上來看，可以將關鍵詞工具看成一個搜索引擎，鳳巢客戶輸入一個種子詞(種子query)，返回一個和種子query意圖相近的推薦詞list。
當然作爲推薦系統， 其中還會包括屬性披露， 推薦理由， 關鍵詞行業分類， 關鍵詞自動分組等支持， 這些內容會在接下來的其他博文進行介紹。
整個推薦流程大致如下
整個推薦流程， 大致分爲5步：
- 基礎日誌，數據清洗即預處理
- 候選詞觸發： 根據輸入種子query觸發得到系統性能支持的最大關鍵詞候選（供後續流程進行篩選過濾及排序），當然爲保證性能， 該過程中會保留觸發關鍵詞的各種基礎屬性，例如PV， 行業， 主題等； 一般業界的檢索，推薦系統會有較多觸發邏輯邏輯，故觸發出的關鍵詞會比較多
- 相關性過濾：因爲觸發出的推薦關鍵詞較多，故需要判斷推薦關鍵詞與種子query的相關性；既要保證召回，又需要保證準確性。
- ranking
- 使用業務，商業規則對最終結果進行排序調整及過濾（最經典的， 黃賭毒必須過濾刪除）
對於相關性過濾，很早以前我們也是使用規則進行過濾，但隨着規則數量的急劇增加，一方面導致系統架構性能下降，另外一方面也使系統策略越難約維護，故最終決定使用機器學習方法進行相關性過濾。
涉及到機器學習方法解決問題， 就會涉及到3方面的問題： 用哪些數據，準備哪些數據，如何處理數據？ 使用哪些特徵？ 選用何種model ？
數據
一般來說，如果數據選擇有問題， 那基本可以說後邊無論再做多少努力， 這些努力都會付諸東流， 公司裏這樣的機器學習相關的項目也不少見： 幾個人全情投入幾個月或是1年多，效果總提不上去，回過頭來發現數據就有問題，哭都沒有眼淚。
所以一開始我們選擇數據就比較慎重，還好關鍵詞推薦工具隱性和顯性反饋數據都還算比較豐富（推薦系統中都需要有這些信息， 將整個數據流形成完整的迭代閉環）： 我們可以認爲用戶輸入一個query並選擇了這個query返回的某個候選推薦詞的pair，就是一個正例（即模型是判斷<Q,W>是否相關，相關爲正例，不相關爲），而輸入一個query後，用戶將返回的某個詞放入垃圾箱（關鍵詞工具交互上支持該操作），則query及被放入垃圾箱的關鍵詞組成的pair，即爲負例。
獲得數據後， 很快就發現一個問題： 客戶操作得到的正例， 就是毫無疑問的正例；但用戶的負反饋（用戶使用種子query搜索得到返回結果後，被扔入垃圾箱的的case）很多時候並不一定和query不相關， 甚至是很相關，只是因爲用戶個性化的原因導致客戶認爲這個case 不適合自己。
比如： 一個客戶主要賣各種花茶， 像菊花茶， 桂花茶等，但他不賣茉莉花茶，此時如果用戶輸入花茶， 從相關性來說， 推薦‘菊花茶’，‘茉莉花茶’， ‘桂花茶’其實都是OK的，但用戶將‘茉莉花茶’放入垃圾箱，因爲他不賣該產品。其實並不能說明花茶和茉莉花茶不相關。
爲了消除因個性化帶來的負例不準的情況，我們人工標註了1.5W非個性化的負例。 並進行隨機sampling， 使正負例數量基本相當。
最終使用1/10數據作爲測試樣本，9/10作爲訓練樣本。
特徵
數據準備就緒後，下一步就是如何選擇合適的特徵了。 因爲整個關鍵詞推薦系統所能觸發的關鍵詞各式各樣， 各種類型千奇百怪， 所以如果直接使用各種地位特徵（例如字面，或是ID類）的話，會導致特徵空間較大而數據比較稀疏，導致完成分類基本上變成不可能完成的任務； 所以我們不能直接使用字面， ID作爲特徵進行分類，而是要使用更加泛化，高維的特徵。
在特徵選擇過程中，我們也充分貫徹了站在巨人的肩膀上遠眺的方式，充分利用手頭的資源，例如短串核心判斷，同意變化擴展等基礎工具進行特徵設計。更詳細的特徵此處不便於列出，僅列出兩個有代表性的特徵供大家參考。
- 推薦詞與種子query經過切詞後的相同term的長度之和與種子query經過切詞後的term的長度之和的比值；類型爲double類型。
- 推薦詞基本切詞後切詞順序包含 query, 特徵值爲1，默認值爲0；類型爲double類型。
- 推薦詞，種子query的topic向量相似度。
- 。。。。更多高維特徵。。。。。
利用多個類似的高維特徵，就能很好地覆蓋推薦詞與種子query； 當然特徵的設計會直接影響關鍵詞推薦中相關性的定義，例如如果字面（重合）相關特徵較多， 則推薦主要表現爲字面相關，如特徵主要爲語義特徵， 則推薦結果反映爲語義相關。如果特徵中有用戶的歷史行爲信息特徵（例如用戶已經選擇的關鍵詞），則可以認爲相關性模型就已經實現了個性化處理。
模型
很多項目因爲週期比較趕， 所以小步快跑的起步階段並沒有太多時間去做模型和參數的雙向搜索，所以綜合效率和時間的代價，選擇了部分模型及在經驗參數下的效果，進行模型的初選。
最終綜合考慮性能，準確性和召回諸多因素下，選擇了adaboost，在adaboost ratio 和 弱分類器數量上進行了參數實驗。 準確性/召回 效果如下：
具體adaboost算法參見： adaboost介紹
| WLRatio | 300 | 500 | 1000 | 1500 |
| 0 | 0.87/0.89 | 0.87/0.91 | 0.87/0.9 | 0.86/0.91 |
| -0.1 | 0.81/0.95 | 0.79/0.96 | 0.8/0.96 | 0.8/0.97 |
| -0.2 | 0.74/0.98 | 0.73/0.98 | 0.73/0.98 | 0.73/0.98 |
| -0.3 | 0.66/0.99 | 0.64/1 | 0.65/1 | 0.64/1 |
評估
以上內容均屬於線下模型優化部分，所有的指標均可以線下獲得， 但最終需要用線上的效果說話， 最後說服力的， 還是線上A/B Test， 因爲是後臺策略的升級， 故這樣的實驗在成熟的A/B test框架下比較容易做； 線上實驗的最終效果也比較符合預期， 保證準確性的情況下召回大爲提升（此處就不貼具體數值）
後文：後來將adaboost直接替換爲Random Forest，在未改變模型的基礎上效果立刻提升非常多，可見模型選擇也較爲重要。
參考文獻：
百度鳳巢關鍵詞工具： www2.baidu.com
百度鳳巢關鍵詞工具介紹：http://support.baidu.com/product/fc/4.html?castk=11820ss78c2e1602bd140
Data.Mining.Concepts.and.Techniques.2nd.Ed
也可關注微博： weibo.com
或是直接訪問： http://semocean.com