PyConTW’18: 輿論分析量測電視劇觀看喜好的風向 — slide by slide
2018 年 6 月 1 日，天氣陰有雨，是個難得涼爽的六月天。
第一次站上中央研究院人文社會科學館的 R1 講台，在 PyCon TW 2018 分享過去一年我們如何嘗試將外部輿論的資料化為有用的資訊 ……
身為初登版的菜鳥，還是花了點時間介紹了自己，提到了兩個求學期間參與的兩個 work，2014 ACM ERD Challenge 以及 NL2KB。
前者是大四還是專題生時參加的比賽，在 short text task 中試圖解決搜尋引擎中 query 過短造成的歧異性問題。
舉例來說：
當用戶搜尋「王建民」時，要找的可能是旅美棒球投手？中研院資訊所研究員？中國波音公司總裁？中國解放軍上將？中國解放軍中將？
但是，當用戶搜尋「王建民 郭泓志」時，就很清楚明白他要找的是棒球投手王建民以及郭泓志了。
最終比賽在強者我學長 carry 下有了還不錯的結果，我也就此決定加入台大自然語言實驗室。
後者是碩士班期間，我們試圖解決像 wikipedia 這類知識庫更新過慢的問題，希望透過找出 relation pattern ，未來可以應用在知識庫加速上。
舉例來說，當新聞中出現「一朗歷經長時間等待，以一年75萬美金加盟水手」的句子時，我們希望透過 [人] 加盟 [球隊] 的 relation pattern，了解知識庫中鈴木一朗的所屬球隊應該需要更新（從原先的邁阿密馬林魚改為西雅圖水手）。
畢業後到了 KKStream，現在在 Applied Data Science Team 跟強者同事們一起工作和學習。
除此之外，因為真的很愛 Python 這個語言，每學期都在台大弄了一個 ccClub Python 讀書會，將 Python 和 data 相關觀念分享給非資訊背景的大學生&上班族。每學期 500+人報名，透過篩選後約有 100 多人共襄盛舉。
一開始針對現場觀眾來兩個小調查：
Q1: 有聽過 KKTV 的舉手？ (大概七成)
Q2: 使用過 OTT(over-the-top)服務的舉手？(大概四成)
這是個群雄割據的 OTT 戰國時代，各家業者試圖在一片紅海中突破重圍，然而版權是個重大的挑戰。版權費佔總支出一定比例，如何聰明的買劇便是個重大課題，我們希望藉著數據的力量，來迎戰這個挑戰。
然而，僅透過自家用戶觀影紀錄無法全盤瞭解市場反應，因此我們嘗試藉由輿論監測，瞭解觀影人對於不同戲劇的喜好。
舉個例子，觀眾對於劇的討論量，和該劇上映後受歡迎的程度可能有關係。一般來說，討論量越大的劇會比較受歡迎，反之亦然。
但，有兩個狀況或許才是值得我們特別關注的：
- 討論量很大，但上映後表現沒那麼好 （暫且稱之為地雷）
- 討論量不高但上映後表現很棒（暫且稱之為黑馬）。
因此，偉大的願景是：找黑馬，避地雷
然而，現實的狀況是：盡可能找黑馬，盡可能避地雷
勾勒完理想中的美好世界後，接下來就是盡可能的逼近這個理想。
對於一個資料科學家來說，沒有 data 就沒有分析，一切就從抓資料開始。
我們從 PTT 日劇板、韓劇板、台劇板、陸劇板 蒐集了不同劇種的輿論資料。
為了瞭解每篇文章在討論哪部劇，我們必須要設計一個 NER 的算法，讓程式可以自動化辨別每篇文章討論的劇名，但 NER 是什麼呢？
先看看維基百科上對於 NER 是怎麼定義的，或許可以有點頭緒。
“Named-entity recognition (NER) (also known as entity identification, entity chunking and entity extraction) is a subtask of information extraction that seeks to locate and classify named entities in text into pre-defined categories such as the names of persons, organizations, locations, expressions of times, quantities, monetary values, percentages, etc.” [Wikipedia]
（翻譯蒟蒻）NER 試圖從一段文字中找到預先定義的 entity。
好像還是太抽象了，直接看個例子好了！
你可能曾在新聞中看過這樣的句子：
在知識庫中（如：wikipedia），我們有各式分類，例如：組織、地名、人名等，各分類中又有不同的實體 (entity)，像是洛杉磯天使是個組織的 entity，大谷翔平是人的 entity。
NER 即為嘗試在一段文字中標出實體所在的位置，在這個例子中，我們需要把球隊名「洛杉磯天使隊」、地名「洛杉磯」、人名「大谷翔平」標出來。
回到我們的任務，如同剛剛所說，我們需要找到 PTT 文章標題中的劇名，知道每篇文章在討論哪部劇，才能開始分析。
然而，PTT 文章中的標題五花八門，有些是轉貼新聞資訊，有些是用戶觀影後的心得，這邊列出幾個真實文章標題的例子讓大家有點感覺。
如果你有在追劇應該會發現，紅字部分都是指《月薪嬌妻》這部劇。
為了不重造輪子，我們先試試 Google 自然語言 API，讓估狗大神幫個忙。
官網上的例子是英文的，結果看起來挺棒的，所有 entity 都標出來，Google、Android 這類 entity 也都成功對到 Wikipedia 的頁面。
試試前陣子的體育新聞標題，看中文的效果如何？
看來蠻成功的，「大谷翔平」、「天使隊」這兩個 entity 都有順利被標出，也都順利對到 Wikipedia 頁面。
既然一切都不錯，直接用 PTT 文章標題看結果拉！
先試第一個，「月薪嬌妻」成功被標出來了，雖然類別被標成 person 了。
再多試試幾個例子看看，結果 …
好像哪裡怪怪的？似乎不如預期的順利，劇名都沒被標出來 QQ
最直觀的作法，應該就是字串匹配了！只要先蒐集所有劇的 metadata，就可以把文章標題中的劇名都找到，這真的太棒了！
但，現實是殘酷的，劇名有各地翻譯名稱不同的問題。
舉例來說：日劇《王牌大律師》在大陸地區翻作《勝者即是正義》，在香港地區則翻作《律政狂人》。
因此，蒐集 metadata 時，我們需要多考慮各地譯名的部分都要盡量補足。
這樣就夠了嗎？不！
新聞報導或是討論區文章標題，通常都會有字數限制。
對於劇名較長的狀況，作者通常會將劇名縮寫，以符合標題字數長度的限制。然而，每部劇的縮寫卻很少有個約定俗成的說法，導致同一部劇可能會有若干個縮寫。
除了譯名和縮寫，還有個更棘手的問題：typo。
顧名思義，就是不經意產生的錯誤。例如：日劇《逃避雖可恥但有用》（又名：月薪嬌妻），人們有時會記成「逃避可恥但有用」少了一個「雖」字，有時卻會記成「逃避雖然可恥但有用」，「雖」變成「雖然」了。
真的那麼容易記錯或打錯劇名嗎？
人類的記憶力真的如此不可靠嗎？
為了驗證這件事，我們特地整理了用戶在 KKTV 平台上的搜尋紀錄，針對近期火紅的韓劇《經常請吃飯的漂亮姐姐》做了些統計，而有些驚人的發現…
用戶曾經這樣搜尋《經常請吃飯的漂亮姐姐》：
同樣一部劇，大家的記憶點真的充滿創意，有人把劇名倒裝了，有人貼心加了代名詞(你/我)，有人把「經常請吃飯」記成「經常吃飯」，更有人想要請漂亮姊姊吃飯 XD
理想中，我們希望演算法可以克服上面提到的問題，不論是譯名和縮寫的差異，抑或是用戶記錯（or打錯）了部分劇名，都應成功判別出來。
萬事起頭難，先觀察看看再說，或許會比較有頭緒知道如何開始。
我們發現，中文語言特性中有個東西叫書名號，在較為正式的文章中（如：新聞）都會在有劇名的部分使用書名號。
我們可以將書名號視為人們在成堆文字中，使用書名號將有劇名的地方標上 label。這些 label 在我們做 NER 時是個重要的資訊，我們可以將這些 label 視為該文章標題的重點，並試著將其找到對應的劇名。
特別強調一點，這邊提供的方法是最一開始嘗試的方法，當時的目標是快速做出一個版本，將每篇文章的劇名找出來，然後趕緊做後續的分析。
實務上，如果不使用書名號（或是這世界上不存在書名號這東西），也是能用以下提供的方法做個變形，設計不同的 NER 演算法。
透過這個中文的語言特性，我們可以順利找到該文章討論的劇名。
但其他的呢？
真實文章中，包含這個語言特性的文章是少數，大多數是不包含書名號的！
既然語言特性能讓我們在找劇名的過程中事半功倍，何不最大化他的效益？
想法很簡單，如果原始標題沒有書名號，或許我們可以找一些內容，這些內容有兩個條件：1. 和原始標題是有相關的 2. 包含書名號
如此一來，我們就能用上述的方式，順利找到該文章標題敘述的劇名了！
利用資訊檢索就能夠找到相似的內容了！
你可以嘗試自行爬取娛樂新聞、影評相關網站，利用 Solr 或 Elasticsearch 自建搜尋引擎，來找到和文章標題相似的內容。
然而，當時我們沒這麼做。還記得我們的目標嗎？
我們的目標是快速做出一個 NER 的版本，找出每篇文章的劇名，然後趕緊做後續的分析。
我們選擇使用 Google Search API 做資訊檢索，找尋和文章標題類似的內容。
想像中的流程如下：
- 將文章標題丟到 Google 搜尋 。
- 得到搜尋結果，在網站標題和敘述中尋找具備語言特性的片段。
實務上，打 API 、擷取重要片段、對應到 wiki 的過程應該會是下面這樣：
費盡千辛萬苦，我們終於找到「逃避可恥中的土屋百合」這篇文章，在討論的是《月薪嬌妻》這部劇了。（撒花
BUT！人生中就是有這麼多個 BUT 才會如此精彩（？
真實世界好像沒有我們想像中這麼理想，有些地方好像出了點錯
回顧前面提到的新聞例子，照著剛剛所說的方法，找到語言特性的部分，嘗試將其對應到 Wikipedia 頁面，結果好像失敗了…
對於「月薪」這個詞來說，在 Wikipedia 上卻對到了「工資」的頁面，而非「月薪嬌妻」。
當然這不是特例，像是三國系列的古裝劇，常常也會對應到手機遊戲的 Wikipedia 頁面而非正確的戲劇頁面。
我們改用影評網來取代 Wikipedia，試著解決對應到非劇名頁面的問題。
除了原先本來就成功的例子，剛剛失敗的例子似乎成功了！
試著再把一些細節弄的更完美一點！
剛剛提到，過程中我們有時會透過資訊檢索將原始標題展開成搜尋結果的內容，藉以尋找具備語言特性的片段。
由於資訊檢索時找到的內容和原始標題的相關度越高越好，我們試著先將原始標題做些前處理，去除不重要的內容，再將他丟到資訊檢索系統。
從結果來看，搜尋準確度確實有提升，對於最後 NER 的結果也是有幫助的。
我們的系統去年底已上線，持續針對不同的文章標題做劇名偵測。
PyCon 演講前特地又抽了 2018 年 4 月，PTT 韓劇版的文章來做驗證。看過了半年之後，系統有沒有壞掉（誤），或許當初的成功都只是巧合（？
結果… 鬆了口氣。
我們針對 296 篇文章做人工 label ，判斷正確的有 225 篇，準確率為 76%。
既然來到 PyCon ，介紹一下我們是如何用 Python 實作的。
首先，資料蒐集的部分我們用開源套件 ptt-web-crawler 爬取 PTT 的內容。
NER 的部分，大致就如上述介紹的流程一樣。
先查看原始標題中是否有書名號，如果沒有，那我們需要透過 Google 做資訊檢索，再從搜尋結果中找尋有用的片段。
接著將這些結果依照出現頻率的次數做個加權，最終取加權分數最高者。
最後，大家可能會比較關心實務上我們如何應用這些資料。
實務上，我們的系統每天會定期爬取 PTT 文章並做劇名偵測。
針對每個劇種產出統計報表（週報表/月報表），提供給內部各部門使用。
以下是 2018 年 4 月份，台劇和韓劇的相關統計。
除了簡單統計量之外，我們也可以依據留言的時間，做時序性的分析。
下面是 2017 年 9 月韓劇版的結果，我們取當月討論量 top 9 的劇來分析。
橫軸是日期，分別為 9/1 ~ 9/25，縱軸是該劇當天的留言數佔的百分比。
從圖中我們可以知道，《名不虛傳》（藍色部分）和《王在相愛》（黑色部分）這兩部劇為該月最多討論量的兩部劇，而《再次相遇的世界》（橘色部分）的討論聲量卻是週期性的出現。
仔細回去分析討論文章的內容，發現該劇的討論文章多為「LIVE 文」，亦即戲劇版中粉絲會在電視劇播出的當下張貼討論文，讓大家邊看劇邊和其他粉絲討論劇情。
我們發現，該劇的討論聲量大多出現在戲劇播出的日子，其他時間鮮少有討論，此類現象或許可以作為評估戲劇的另一個指標：「話題延續性」。
除此之外，我們也可以將網路與論的聲量和內部資料做交叉比對。
延伸閱讀：看劇「完食率」：KKTV 提高營運效率的新數據武器！
總結來說，我們建立了一個輿論監測的系統，可以定時抓取輿論資料，並試著與 KKTV 上的用戶資料交叉分析，以利其他部門在做決策時有個參考。
在本演講中我們提了一個直觀的方法，在不用事先擁有戲劇列表，就能找出每篇討論文章所討論的劇名，準確率約為 76%。實務上，若針對細節做出改良，準確率能再提升 10% ~ 15%。
演講中提到，我們為了快速做出一個 NER 的版本，使用了書名號這個語言上的特性。實務中，若不使用書名號，亦可嘗試利用資訊檢索並搭配自然語言處理中常用的方法，亦能達成 NER 的目的。
最後附上兩個參考資料，其實也就是我以前曾經參與過的研究。
這兩個研究的經驗，對於我在面對戲劇劇名 NER 的問題很有幫助。
謝謝大家的聆聽。
敝公司 KKStream 正在熱烈徵才，目前各職位（PM、RD、data）都還有職缺，歡迎投履歷：）
另外，如果你是程式設計的新手，我們團隊 ccClub 下學期仍會開設 Python 讀書會，預計七、八月會釋出相關報名消息，歡迎報名來一起寫 Python。
