作者：邱震宇（華泰證券股份有限公司 算法工程師）
知乎專欄：我的ai之路
很久沒寫文章了，今天一不說論文（攢了一堆還沒複現），二不說算法基礎（沒複習），主要來說說我到華泰NLP後做的第一個比較有意義的事情——熱門話題生成。事實上，我在接手這個子產品時，已經有其他同僚輸出了一個較為完整的解決方案，效果也尚可，隻是還有一些需要改進優化的地方，是以，我的主要工作是在其基礎上從性能和效果兩個方面進行各種優化。本文主要是總結了個人在經曆該項目期間的一些工作和思考，如果有不合理的地方，歡迎同行留言交流。
首先，介紹一下熱門話題生成這個功能需求。它的載體是我們内部開發的一套基于自然語言處理技術的金融輿情事件分析系統，該系統主要目标是建構風險、交易事件信号，助力投資交易、風控領域。
關于這套系統具體内容，我們團隊長之前在公衆号AINLP上有投過文章，标題為：《自然語言處理在金融實時事件監測和财務快訊中的應用》，有興趣的同學可以自行檢索檢視。
而熱門話題生成的需求目标則是通過對目前最新新聞的快速分析，擷取目前世界範圍内比較熱門的、與金融相關的話題，話題内容包括但不限于公司金融事件、國内外政治軍事事件等。使用者可以通過該功能子產品快速感覺目前全球的熱點話題，為期在做投資決策時提供輿情情報。這個功能可能與一些社交平台上的熱點、熱門比較類似，不過我們主要針對的是不同平台釋出的新聞資料，大部分以金融新聞為主。下圖為熱門話題展示的結果樣例：
以第一條為例，下圖展示了第一條示例的新聞聚簇效果，可以看到該話題的聚簇效果還是不錯的。
我們内部有一套完整的新聞資料擷取與處理流程，使得我們能從多個資料源總實時快速擷取大量的新聞資料，這塊内容我就不過多介紹了，下面着重描述熱門話題生成子產品的實作過程，主要分為三個小節：
1、子產品問題定義與需要解決的問題。主要闡明熱門話題任務需要解決哪些問題。
2、子產品解決方案基本架構。主要介紹初版解決方案的基本流程。
3、子產品優化過程。主要介紹在初版方案的基礎上進行的一系列優化工作。
首先我們将熱門話題生成任務拆解成三個子問題：
1、首先必須從新聞文本中提取話題。不同于一些比較傳統的NLP任務，如文本多分類、多标簽分類、資訊抽取等，這個任務并沒有一個很明确的學習目标，即我們并不知道要抽取的話題的schema集合，因為每天出現的新的話題都是未知的，這種場景下的資料一般也是無标注的，是以無法用有監督的學習方式來解決。
2、除了提取話題之外，我們還需要将包含類似話題的新聞聚合起來，以獲得目前階段的話題簇，這樣我們就可以計算出每個話題的熱度，将熱度較高的話題推送給使用者。
3、最後，對于每個話題簇，我們需要為其生成一個話題描述文本或者标題等等，用于直接展示給使用者檢視。生成的描述需要充分代表該話題簇的話題内容，且需要一定的可讀性。
對于問題1，相對于目前比較火熱的深度神經網絡NLP方法，通常會使用基于統計學方法的topic model來做話題抽取，經典的方法如LDA等等。topic model通常會無監督的對每篇新聞文本抽取話題，它的産物包括得到文檔-話題的機率分布，每篇文本可以使用這個機率分布來當做向量表示；對于問題2，可以使用解決問題1時得到的文本向量基于無監督的聚類方法做無監督的聚類；對于問題3，則相對複雜一些，目前并沒有現成的方法工具能夠直接解決這個問題，是以需要設計适合該場景的方法，具體見下文描述。
基于上述問題定義，我們團隊基于此設計了一個基礎的方案架構，架構流程如下圖所示：
具體來說，主要分為以下幾個子產品：
1、新聞資料定時批量推送與文本預處理子產品。基于性能和效率的考量，我們并非是實時對新的新聞文本進行話題抽取分析，而是設定了定時機制，以T分鐘為間隔，每隔T分鐘執行一次算法那服務，将過去一天内的所有新的新聞作為話題抽取的源資料（已經對這些新聞進行了去重）。另外，我們舍棄了新聞的正文，隻将新聞标題送入到話題抽取子產品。這樣做的原因有兩點，其一是新聞文本的内容通常較多，而且topic model的訓練時間通常都比較長，我們對于正文内容抽取話題的時間成本是無法忍受的；其二是很多新聞正文内容通常包含多個不同的主題，對其進行主題抽取和聚類後，得到的話題簇效果較差，存在簇與簇之間區分度不高的問題。另外，我們的目标隻是對目前熱門的新聞話題進行聚合，是以隻用标題進而産生的一些資訊損失也是可以接受的。對于新聞标題，我會做一些常見的文本預處理，例如繁體轉簡體，中文分詞（我們嘗試使用了哈工大的LTP和Baidu的LAC分詞，效果差不多）、去除停用詞等。
2、主題抽取與聚類。該子產品使用topic model對新聞标題集合進行主題抽取，然後對每條新聞進行向量化。最後使用這些向量使用無監督的聚類方法進行聚類。
主題抽取可以說是整個方案的核心，主題抽取的品質決定了後續步驟得到的話題簇以及話題描述的品質。通常我們會使用LDA來對文本集合進行主題的抽取，然而在我們這個場景中，這種方法并不合适。主要原因為LDA的稀疏性問題。對于長文本來說，每篇新聞都能包含足夠多的文本篇幅來囊括不同主題詞的資訊，對于一篇文檔來說其本身通過一個Dirichlet分布采樣得到一個文檔-主題的機率分布
，生成文章的某個詞時，根據
生成主題隐變量z，然後根據z從另一個Dirichlet分布采樣得到主題-詞的分布
,最後根據
采樣生成詞。對于短文本來說，由于一篇文章包含的詞過少，上述生成過程的統計意義就不明顯了，無論增加多少篇文章都不能緩解這個問題。（有關LDA的具體原理詳見網上其他部落格）
最後，我們經過一番調研，決定使用一種專門針對短文本主題抽取的topic model方法，即BTM(Biterm Topic Model)。
詳細的BTM算法在知乎上也有部落格專門總結，這裡我就不詳細得描述了，僅僅針對其原理做簡要的介紹。可參考目前有比 Topic Model 更先進的聚類方式麼？比如針對短文本的、加入情感分析的？- 蘇格蘭折耳喵的回答 - 知乎 https://www.zhihu.com/question/298517764/answer/760362033 或者zhuanlan.zhihu.com/p/11
BTM的學習過程其實與LDA是類似的，但是它在做機率分布學習之前，對文檔詞的處理方式不同，主要展現Biterm上。所謂的Biterm就是從分詞後的文檔詞集合中，抽取兩個詞組成一個詞對，以詞對為基礎元素進行主題詞的學習。另外，它不同于LDA，所有文檔共同使用一個機率分布
，使得主題稀疏的問題得到了緩解，很适合标題短文本中詞較少的場景，另外對于一個新聞标題來說，很多情況下隻會包含一個主題。
得到得到話題分布後，我們相當于得到了每篇新聞标題文本的向量化表示，然後我們嘗試了最簡單的k-means方法拉進行聚類，這種方法需要指定聚簇的個數，不過實作和調試比較友善，在經過了幾輪資料的調參後，也比較友善确定一個大概的聚簇個數。另外，我們還嘗試了Xmeans，這種聚類方法不需要指定聚簇的個數，但是也要指定聚簇的一個大概範圍，每次疊代計算，它通過BIC score（Bayesian Information Criterion）來判斷的目前聚簇是否要分裂。最終通過綜合考慮，我們還是使用了xmeans作為最終的聚類方法。
關于話題聚類，還有一個細節要說明一下。通過BTM學習後，我們能夠得到文檔-主題的機率分布，以及主題-詞的機率分布。我們主要使用文檔-主題的機率分布來做話題聚類，聚類完成後，我們通過整合聚類後每個聚簇中心的話題分布和主題-詞機率分布，能夠得到每個聚簇上的詞的分布，這個機率分布大緻可以表示一個詞在該聚簇上的重要性。後續在做聚簇優化時，可以利用該關鍵詞資訊進行聚簇的合并或者分裂。下圖為某個聚簇計算得到的關鍵詞結果：
3、聚類後處理。上述話題抽取和聚類後，已經能夠得到一些相對不錯的結果。但是還會存在一些品質不高的聚簇，此時需要通過引入一些規則，對做聚簇的合并和分裂，這塊内容将着重在下一章節的優化介紹中進行詳細的描述。
4、話題熱度計算。對于話題熱度，目前我們隻是暫時考慮了新聞在不同新聞源上的出現次數，并未考慮全網中其他平台的轉發、引用等情況。是以該熱度隻能在一定程度上反應一個話題的熱門程度，不過通過一段時間的驗證可以發現這種熱度的計算方式基本能反應話題間的相對熱度關系。
5、話題描述生成。本子產品主要對每個話題聚簇生成一個合适的話題描述用于代表該簇并展示給使用者。初始的實作方式是通過使用哈工大的LTP工具對聚簇中的所有标題進行句法分析，抽取标題文本中的主謂賓、定語後置動賓關系、介賓關系主謂動補等結構。然後對一個聚類中的新聞提取的文法要素進行相似度的分析，并抽取重合度最高的文法結構拼接得到臨時話題描述。這種方式實作上來說比較簡單，但是存在一些問題，具體将在下章節優化介紹中描述。
6、曆史話題合并。本子產品主要是将本疊代計算得到的話題簇和其對應的話題描述與曆史疊代得到的話題結果進行合并。之是以要做這一操作的原因在于我們的熱門話題服務子產品是每個N分鐘定時執行，一般兩天之内，某些話題的新聞會在不同時間段重複出現，是以目前的疊代産生的話題有很大機率與前幾次疊代的結果有重合，我們需要對重合的話題進行合并，更新其熱度。初版方案的合并過程為：
擷取過去24小時内的已經抽取話題聚簇news_topic_latest_24_h
将目前疊代處理的每條新聞，與news_topic_latest_24_h中的每個話題描述，計算其相似度。具體相似度計算方法參考使用了fuzzywuzzy的文本相似度計算工具。當相似度大于預設的門檻值時，則視為重合，則進行合并，同時更新話題的熱度。
若上述步驟計算得到的相似度小于預設的門檻值，則檢視該新聞對應的關鍵詞清單與目前話題的關鍵詞清單的重合程度（關鍵詞清單由話題聚類後得到，每個話題簇有一個關鍵詞清單，每個簇下面的新聞共享這個關鍵詞清單。）
可以看到上述方法實作時比較簡單的，但是從性能和效果上都有很多待優化的地方。具體将在下章節優化介紹中描述。
本章節将着重介紹本人對熱門話題生成各個階段中的瓶頸分析和優化過程，希望對業界的同行在業務落地時有一定的借鑒意義。
此處優化主要針對的是利用BTM進行話題抽取以及聚類後得到的話題聚簇結果。優化前，通過聚類得到的話題簇存在以下問題：
1、BTM本身話題抽取的誤差，以及聚類算法的誤差會向後傳遞，使得聚簇的純度不高，如下圖所示，微軟推遲ES2010擴充支援結束日期話題明顯不屬于目前話題。
2、BTM與聚類本身需要指定超參數來決定最後話題聚簇的粒度，這也導緻後續某些聚簇的話題被誤分裂，如下圖所示，紅框中的兩個話題應當是能夠合并的。
3、有些聚簇雖然說的話題是相似的，但是其本身資訊量不是很大，對于使用者來說價值不大，反而容易将其他真正有價值的話題擠掉，如下圖所示（忽略該圖中的話題描述錯誤），雖然這幾個新聞都講與融資相關的事情，但是基本上是與不同實體公司相關，且新聞間也沒有關聯度，這種話題簇應該進行分裂。
基于上述問題描述可以總結出，對于初步得到的聚簇結果，我們需要做進一步的後處理，來保證聚簇的純度和區分度。主要從每個新聞标題關聯的實體以及關鍵詞來入手，引入一些啟發式的規則，來進行聚簇的精煉。以關鍵詞為線索，可以引入如下規則（示例）：根據關鍵詞清單，如果兩個聚簇中的關鍵詞重合度大于某個門檻值，則進行合并。若不大于該門檻值，則看其重合的關鍵詞的機率是否均排在所有詞的top3，如果是，則合并。
以實體為線索，則相對複雜一些，主要流程如下：
1、使用百度的LAC工具，對新聞标題進行實體标注和詞性的标注，找出标題中類型為PER，ORG,nr,nt的實體詞，打上标記。另外對于聚簇關鍵詞清單中的實體詞也打上相應标記。
2、通常來說，一個聚簇中真正相關的實體個數不會太多，一般隻會有一個，如果在原有聚簇的基礎上，加入實體的因素來判斷是否合并或者分裂聚簇，最後可以得到一個更加純淨的聚簇結果。是以，可以引入一些實體相關的規則來進行後處理，示例如下：對于兩個待處理的聚簇，如果兩個聚簇中關鍵詞包含的實體有重合，且重合度較高大于某個門檻值（重合度根據實體類型以及實體内容綜合判斷，一般是ORG類型的實體權重較高，因為新聞通常關注機構的事件），則進行合并；若關鍵詞中的重合實體不滿足要求，則将兩個聚簇中各自的實體清單進行比對，同樣根據不同類型實體的權重計算重合度，若重合度大于某個門檻值，則合并。
3、其他規則。另外，我們分析了一些bad case，發現有一些話題新聞本身确實沒有問題，但是對于使用者來說意義不大，且容易幹擾其他話題，如下圖所示，這些新聞通常包含物價類新聞、研報點評類等等，可以在話題聚類之前就過濾掉這些新聞。
通過分析一些bad case，可以總結出初代版本的話題描述生成存在的幾個問題：
1、話題描述語句不通順。因為是使用開源的NLP分析工具提取句法結構，然後将其簡單拼接，是以難免會得到可讀性較差的文本。如下圖所示。
2、話題描述與目前聚類下的新聞可能會不一緻。這個問題與曆史話題合并也有很大關聯。由于曆史話題合并子產品的一些問題，使得合并後的話題新聞并不純淨，使得産生的話題描述也會受到污染。如下圖所示，這個話題本意應當是講對外投資相關的話題。
除了算法效果之外，初版方法的性能也不太理想。由于需要對所有新聞标題進行句法分析工具，然後進行相似度的計算，是以計算成本較高。這對于一次性處理接近萬條的資料來說，是不太滿意的。
基于性能和效果的雙重考量，我設計了一種新的方式來做話題描述，即利用rank類（例如TextRank）的抽取式摘要算法來幫助生成描述文本。可行性在于通過rank類摘要提取出來的摘要句，通常會傾向于選擇相似性比較高的一類句子作為摘要句，雖然在摘要抽取裡面這回帶來備援的問題，但是在我們這個場景下，這種特性反而是一種優點，通過rank類抽取出來的權重較高的句子，通常是能夠代表該聚類中大部分句子内容的，是以能夠作為話題聚簇中的代表性描述。具體的算法流程如下：
1、對于話題聚類以及後處理得到的話題聚簇，将一個聚簇内的所有新聞标題文本拼接成一段文本，每個标題文本作為一個候選摘要句。
2、使用TextRank算法做抽取式摘要任務，得到權重分數排名前5的句子作為候選描述句。這一步驟主要關注的是如何去向量化新聞标題以及計算兩個标題句的相似度。由于需要兼顧性能要素，是以不能使用太複雜的方式，經過綜合考慮後，決定基于詞的tfidf特征來向量化标題句，并使用餘弦相似度來度量兩個句子的相似程度。這種方式性能還是不錯的，最後效果也不錯。後續所有用到相似度計算的子產品基本上都沿用這個方法。
3、若候選描述句中包含聚簇的實體詞，則優先選擇該句作為描述句。
4、前三步驟得到的句子會有一些問題，如有些标題本身很長，或者有些标題比較備援，此時需要對這種标題進行後處理。目前設計為先判斷句子長度是否大于某個門檻值，若是，則對描述句進行句法分析，抽取出其主成分，将其作為最後輸出的描述句。
最後介紹一下曆史話題合并中的優化問題。初代版本的方法在性能和效果上都有一些問題：
1、性能方面，每一輪更新時，從資料庫中查詢僅24小時内的已抽取話題，其歸納整理後的topic數量大概是600+，而每次新處理的新聞的量級大約在400-600的數量級（已去重），其中新id的新聞大緻占總量的20-40%，假設平均的數量級為50+。做新聞話題合并時，需要将每篇新聞與目前已有的話題進行相似度以及實體相關的分析處理，而一條新的新聞完整合并邏輯的流程時間大概需要20秒（其中，大部分時間主要集中在需要和600+數量的topic逐一進行相似度比較，相似度計算的時間會比較長）。那麼50+的新聞的合并流程則需要16+分鐘，還需要加上資料庫的入庫操作的時間消耗，這個時間成本是不太理想的。
2、效果方面，由于之前的話題描述生成效果不佳，同時使用的相似度計算方法（fuzzywuzzy）也并不好，是以合并的效果也不好，如下圖所示，兩個羅永浩被列為老賴的話題是在不同疊代中生成的話題，但是最終沒有被合并上。
基于話題描述優化以及相似度計算優化的工作，我對曆史話題合并進行了改造，具體如下：
除了上述優化外，我還花費了一些時間探索了其他優化的方法。例如通過使用一些複雜的句子表示方式以及相似度計算方式，來提升子產品整體的效果，諸如使用sentence-Bert或者usif的方式來向量化一個句子。但是這些方法無一例外，計算成本都較高，對于我們的場景來說不太适用。有感興趣的同學可以自行深入研究。
本文主要描述了一個實際的NLP需求場景的落地過程，同時也展現了一部分算法人員的日常工作。這些工作往往并不會涉及到一些高大上的負責算法，有時候負責的算法基于性能原因也無法實際應用。個人認為，在金融NLP領域這塊，需要具備一定的bad case分析和優化能力，簡單點說就是能用效率最高的方法解決bug。不同于推薦場景需要硬名額的提升，我們很多場景的評測是沒有辦法量化評測的，就比如本文所說的熱門話題生成，這種場景一般隻能靠人力來質檢，是以我們就需要快速對質檢結果進行回報，上線疊代版本。總而言之，算法和工程要兩手抓兩手硬。
本文由作者授權AINLP原創釋出于公衆号平台，歡迎投稿，AI、NLP均可。原文連結，點選"閱讀原文"直達：
https://zhuanlan.zhihu.com/p/268564361
歡迎加入AINLP技術交流群
進群請添加AINLP小助手微信 AINLPer（id: ainlper)，備注NLP技術交流