回顧·音樂垂域的自然語言理解
![]()
本文根據小米智能雲秦斌老師在DataFunTalk人工智慧技術沙龍「自然語言處理技術應用實踐」中分享的《音樂垂域的自然語言理解》編輯整理而成，在未改變原意的基礎上稍做刪減。
今天分享的內容有項目研究背景、實現了那些功能，在做音樂領域時有哪些獨有的問題與挑戰，還有就是「小愛」項目具體的實現。
上圖是整個小愛語音交互平台的後台服務架構，小米大腦定位的是一個平台，能夠處理各種數據。在最外部給各種廠商封裝了SDK介面，目的使廠商能夠很快的接入，降低你接入成本，如果你要操作小米相關智能設備就要MOIT授權驗證。後續會有小米語音服務ASR，語音識別都在客戶端，由於平台特性，在雲端接入ASR廠商，如微軟、百度、科大訊飛、獵狐星空等，部署於雲端便於控制和優化，可以額外做一些文本選擇等功能。語音轉化為文本就會進入NLP模塊，在NLP中控部分會做一些個人訓練計劃、公共訓練計劃、還有一些query概率，然後將其發布到精品垂域，採用分而治癒的思想，每一個垂域將這個領域的語料、知識、常見說法給建立起來，由中控選擇最終的垂域。最外部有一個設備開放平台oivs，方便各種硬體設備廠商接入。後續還有一個技能開放平台，第三方技能開發者能夠在平台上很簡單的實現一個技能，如打開成語接龍或閑聊，將query轉給第三方技能。周邊就是機器存儲、機器學習平台等資源平台。
接下來介紹下，一個垂域要做那些事情。如飛機票垂域，要理解用戶的意圖，是要購票還是退票，音樂就是你要找歌手、聽歌、還是找一個推薦；在意圖理解後抽取Slot（一個個的欄位），如時間、出發地、目的地。整體就是將一個純文本機構化，將相關信息抽取出來，這是做語義理解經常要做的事情。
接下來介紹下音樂領域實現了那些功能，第一個就是用戶的個性化推薦，如隨便放首歌、歌單等。再往後就是一個搜索意圖，比如我要聽周杰倫的歌，周杰倫的簡單愛，抽取「歌手/歌名/專輯/標籤」四類欄位(slot)信息。欄位消歧，如「三生三世十里挑花的歌」，其實這是一個專輯，同時也有首歌叫三生三世十里桃花，通過用戶原始信息知道應該是專輯而不是歌名。ASR不可能完全準確還有用戶發音問題，因此需要糾錯，糾錯太多召回存在問題，一言不合就放歌，把握不好就會覺得你太笨，對「歌手/歌名/專輯/標籤」欄位的」同音/補全/亂序」糾錯。如歌手同名問題，歌詞錯誤，歌名與歌手對應錯誤等。
還有一些音樂特色功能：（1）音樂意圖的上下文繼承,對欄位信息進行信息補全或指代消解。如我想聽劉德華的歌，完了又說要播放他的笨小孩，那就是「劉德華的笨小孩」；（2）用戶情感分析。如「我想聽歲月神偷不要聽金玟岐的」，就是對Artist的一個否定；（3）指定播放順序；（4）根據歌詞內容識別歌曲，如「海草海草」識別到是「海草舞」；（5）收聽歷史歌曲，需要提出時間信息。
上面介紹音樂要實現的功能，接下來介紹遇到的挑戰。首先（1）實體名太過複雜，形式多樣，沒有固定的組成規則；知識庫數量巨大，如QQ音樂是千萬級，網易雲音樂數百萬，阿里系也有數百萬。由於歌數量巨大，很多都壟斷，要識別這些歌曲需要建立知識庫，但是原始數據存在很大的噪音，缺少欄位信息，歌名不規範。需要將海量數據爬取下來，判重。（2）用戶說法很亂，不符合自然語言，比較簡單，沒有固定形式，半結構化文本。（3）實體名糾錯。由於實體名自身的複雜性和多義性，存在著同音糾錯，方言糾錯，亂序糾錯等多種糾錯情況。
知識庫很多，實體名很複雜，單純用詞表不能很好地解決這個問題，採用了知識庫加搜索的方案。搜索能很容易解決數百萬知識庫，不存在性能問題，搜素排序演算法技術比較成熟，搜索保留了歌的物理信息，如「王菲紅豆」就能知道是紅豆這首歌，但是如「韓紅紅豆」就不是歌了。歌來源有爬取的也有合作的，進入知識庫後會有一個文本搜素，抽取feature，利用learn to rank排序，通過query確定用戶想聽那首歌，確定歌名，抽取slot，利用GBDT模型打分。還有User feedback，language model，domain frequency（利用用戶行為反饋，改善向量效果）。後面就是個性化的搜索和推薦，如用戶的性別、行為，歌一放出來就切換，還有音樂的熱度、風格、發行時間等。大致流程會對query做一些前置理解，後續從知識庫中找到與之相關的歌，抽取slot，然後進行語義消歧。然後打分，然後利用語言模型判斷是否符合常用規則。
數據是核心，資源主要來自資源方、垂直網站還有人工運營平台。獲取數據後對數據進行歸一化，做相應的映射，打一些標籤。還要排重，一家網站一首歌也會存在很多版本，但是我們只需要原始數據忽略版本。後續就進行DB、內容評審、構建索引等，清洗數據會花費大量時間。音樂NLU整體架構，分為意圖抽取、知識庫搜索排序、欄位抽取、路徑選擇及打分、線上數據反饋。意圖抽取會對query進行預分析，數據預處理，然後中文分詞還有推薦意圖分類器，還有文法規則，最後找到一些主幹query供後續搜索，先理解query語義上的可能的一些傾向性的方向判斷，找到主幹query供第二部使用。
接下來介紹一下推薦意圖分類器，在獲取query時，增加了一個二分類判斷，判斷是否是推薦意圖，目的是簡化搜索，節省時間，同時為策略判斷給出一些特例。具體做法是中文分詞後抽取n-gram特徵，如單詞特徵、二元特徵、三元特徵，最後利用邏輯回歸。後續會使用Woed2vec，因為word2vec 能夠捕捉更多語法和語義特徵。
接下來就是文法規則匹配，自定義了一套文法規則，支持變數的定義、文法的組合、文法替代，目的是對query語義做傾向性判斷。還有影視類、標籤類的詞典，標籤文法對標籤進行了強分類（強標籤、弱標籤）。第二部分局勢知識庫搜索排序，基於Linden做的搜索。Linden是基於開源的Lucene包，Linden就是將其服務化，集群管理，加入類似SQL語言，便於集群查詢。單詞搜索主要針對用戶說法很亂，如果進行切詞可能無法召回，但是出現的問題是召回太多。最後會對初排後結果learn to rank，進行重排。
知識庫中有數百萬的數據，每周都需要評測更新一半的索引，上線有嚴格的流程，線上的策略改動、數據改動都要經過評測才能上線，還有人工審核top query。知識庫索引設計支持歌手、歌名、歌手別名、專輯和影視類欄位的綜合搜索，支持單字和拼音兩類搜索方式。知識庫搜索初排也會支持降權，在搜索時就進行降權。
在初排後進入中間層會利用排序演算法進行二次排序，如從top80裡面選擇一個最相似的文檔。正負樣本比例失衡，適用於Learn to rank演算法，最後選用LamdaMart，採用決策樹模型會學習到很多特徵組合。模型特徵有欄位匹配類別、相似度，欄位匹配長度，欄位糾錯類別，文檔熱度等50多個相關特徵。
通過相關特徵選擇一首歌后，進行欄位抽取。涉及資源欄位的抽取和糾錯，標籤欄位PK資源欄位，如判斷青春是歌手還是歌名，上下文欄位繼承，否定意圖等。欄位抽取是基於純規則，有些熱門歌曲唱錯時也會將其選擇出來，如一個歌手沒唱過這首歌，但是如果是熱門歌曲也會選擇出來。
打分是基於意圖分類和規則打分，還有基於語言路徑的用戶選擇。由於語言的歧義性可能會選擇多條路徑，典型二分類問題，缺少其他domain打分信息結合少量必要規則，替代原有規則系統。最終選定GBDT演算法，利用各種特徵，如職業特徵，郭德綱、岳雲鵬都唱過歌，但是職業是相聲演員，單說歌手就會將其推電台。還有一個優勢就是APP搜索日誌，小米音樂大都是key-words搜索，如果在日誌中找到也是屬於音樂特徵。
文本搜索有用戶點擊信息，但是語音很難找用戶行為特徵信息，尤其命令型語音，得不到用戶反饋。但音樂可以獲取用戶聽沒聽這首歌，聽了多久。利用的是全領域知識反饋模型，利用DFTF思想，如「大王叫我來巡山」在音樂領域用的很多，當出現大王，就很容易召回。另外還有完成率，就是用戶完成行為反饋模型，用戶聽了多少歌，首條完成率，即第一首歌聽完的概率，還有30秒切歌率等指標。
項目目前存在的問題，音樂過召回嚴重，音樂slot抽取準確性仍需提高，知識庫的準確性和完整性存在不足， 聊音樂，想做電台式音樂，這樣顯得智能，一首歌結束會引出小愛的評價，引出下一首歌。端到端，利用click model訓練端到端模型，知道一些query在歷史上選為音樂意圖，當一個新query來後與歷史query比對，如果詞向量相近，直接返回結果，簡化操作。——END
推薦閱讀：
