揀閱一：緣由和系統設計

個人平時比較喜歡看些新聞資訊，比如科技類的huxiu, 36kr，體育新聞等，對相關的APP也有用到，今日頭條做的很不錯，周圍很多人在用，但是在用了一段時間之後發現很多APP都有以下特點:

1. 資訊多而且雜，即使我隻訂閱或者關注了某些類别，推送的消息首先是太多其次是不相關。太多的資訊我消費不了，不相關的資訊我比較反感。

2. 現在的APP号稱可以進行精準和個性化的推薦，頭條做的還行，但是感覺不能及時的捕捉使用者的興趣變化，推薦的結果變化也小， 驚喜度不夠。

3. 聚合類的新聞資訊有很多重複性的内容，而且很多隻是簡單的抓取和展現，對閱讀的方式和體驗都沒有太大改善。

以上大概是用過之後感覺有些不便的地方，之前做過一段時間的推薦和文本處理相關的事情，加上自己有些想法，就想實作一個簡單的系統，拿自己做個試驗試試，也好驗證下自己的想法，針對以上問題，個人的想法是1. 每天給使用者展現一定數量的有價值的新聞，即限制推送給使用者新聞的數量，相關性方面需要針對使用者的特征模組化，預期效果不太明顯，隻能通過一些政策來控制，比如最熱和相關結合，某個事件或者某個類别展現一條新聞等政策實作。2. 針對使用者的行為及時更新使用者的特征權重，及讓變化更實時一點。3.

很多人看文章隻是看文章的大意，很少通讀全文的，如果能對文章進行摘要，對APP類的應該會比較好，但是現在對中文貌似沒有好的摘要方法，隻能不斷的進行嘗試改進，我會用之前文章介紹的摘要算法進行實驗，結合中文的詞法和語義做些嘗試。

以上純粹是個人的觀點和看法，肯定有不妥的地方，這方面有想法的可以在一起交流下。

目前開發工作已經進行了一些，之前一直用java來做web相關的服務和設計，奈何一般的雲伺服器跑java的話費用較高，故采用了python來進行相關的開發工作。系統的簡單設計如下:

系統主要分為OnLine Service, OffLine Service, 其中OnLine 部分主要進行以下操作:

    a).  Fetcher利用UA和PA來擷取推薦展示的新聞資料，首先會向redis請求相關資料計算，然後到MySql擷取資料，目前假定MySql可以滿足一定量的并發請求，以後可以考慮按照資料類型在MySql前面再加一層緩存。 

    b). Updater主要是根據使用者行為來更新緩存中的UA權重，這樣下次就可以根據使用者的最新行為進行推薦展示。

      OffLine部分主要負責的是線下邏輯的處理，主要包括對抓取資料的清洗、特征提取、摘要、入庫等操作，為了解耦，利用MQ來存儲抓取的資料。

    目前采用的方式是tornado 架構來提供web服務，redis作為緩存存儲資料，mysql作為底層資料存儲， rabbitmq 來作為消息隊列，jieba分詞器來進行中文分詞，redis + mysql 目前已經實作，web主要剩下頁面的設計和實作，特征提取和摘要正在進行，由于事情比較多，可能最後實作的跟文章中說的會有很大差別，接下來會講部分想法的實作過程和效果， 具體取決于進度和工作了，如果有興趣可以一起交流。