Ahogrammer

Deep Dive Into NLP, ML and Cloud

日本語 Sentiment Analyzer を作ってパッケージ化した話

Sentiment Analysisと言えば自然言語処理ではよく知られたタスクで、典型的にはテキストをポジティブ/ネガティブの2クラスに分類するものだ。 その使い道としては、Twitter等のSNSから自社製品についての投稿を収集して評価や緊急度によって分類し、問題に対応するチームメンバーを決定したり、カスタマーフィードバックを時系列で分析して顧客のsentimentを追跡することで不満が顕在化する前に対処したり、従業員のアンケートを分析して、時系列で変化する従業員感情の変化を追跡して、懸念が表面化する前に解決に導くといったものがある。

そんなSentiment Analysisだが、英語のテキストを分析するためのソフトウェアはこれまで様々な形で提供されてきた。たとえば、PythonパッケージならTextBlobNLTK等があり、クラウドサービスであれば、Google Cloud Natural Language APIAYLIEN等がAPIを提供している。

一方、日本語に対するSentiment Analysis機能の提供はどうなのかというと、Google Cloud Natural Language APIのようなクラウドサービスでは提供されていることが多いが、オープンソースだと充実していないのが現状だと思われる。私の探した限りだと、極性評価辞書を使ったタイプのパッケージがいくつか公開されている程度であった。この手の極性評価辞書を使ったタイプは、単純に極性を足すだけだと上手くいかないので色々とルールを書く必要があり、メンテナンスにコストがかかる。また、クラウドサービスだと課金する必要があるので、ちょっとしたことに使いにくい。






(´・ω・`) しょーがねーなー。作るか。




そういうわけで作ったものをオープンソースで公開した。スターつけてくれると嬉しい。

github.com

デモサイトも用意してあるので、インストールしなくても実際の動作を確認できる。

f:id:Hironsan:20190208120644p:plain

性能的な話

ソースコードを見てもらえればわかるが、asariの中身はとてもシンプルなものになっている。sklearnのTfidfVectorizerLinearSVCしか使っていない。テストセットに対する評価は以下の通り。

              precision    recall  f1-score   support

    negative     0.8484    0.8404    0.8444      2331
    positive     0.9283    0.9322    0.9302      5164

   micro avg     0.9037    0.9037    0.9037      7495
   macro avg     0.8883    0.8863    0.8873      7495
weighted avg     0.9034    0.9037    0.9035      7495

ちなみに、最近流行りのBERTで評価した結果は以下の通り。データセットを分割する際にシードを固定し忘れたので完全に↑と同じテストセットで評価したわけではないことに注意。

             precision    recall  f1-score   support

   negative     0.8735    0.8841    0.8788      2382
   positive     0.9457    0.9403    0.9430      5112

avg / total     0.9228    0.9225    0.9226      7494

BERTと比較してもそれなりの性能を確保できたので、予測速度等を考えて思いっきりシンプルに作っている。こんなモデルで学習して欲しい等あれば、コードを書いてPull Requestを送ってほしい。善処する。

2018年のふりかえりと2019年にしたいこと

あけましておめでとうございます。

今日までお正月休みで明日から会社に復帰します。三週間ほど家にこもってゲームばかりしていて頭もだいぶボケてきているので、出社前のリハビリがてら2018年のふりかえりをしたいと思います。まずは2018年に何をしていたか思い出すために、やったことを時系列で書いてみました。

翻訳した技術書が発売される

f:id:Hironsan:20190109104619p:plain

2018年の8月に翻訳を担当した「直感ディープラーニング」が発売されました。この本の企画自体は一年前の2017年7月辺りに立ち上がったのですが、それから一年経ってようやく発売されました。書店に並んでいる本を見たときは感慨深かったです。本当にいい経験をさせてもらったのでやってよかったです。

アノテーションツールのリリース

https://github.com/chakki-works/doccano/blob/master/docs/named_entity_recognition.png?raw=true

同じく2018年の8月には開発したテキスト用のアノテーションツールであるdoccanoをリリースしました。doccanoは企画から開発、リリースまで一人で行ったプロジェクトなのですが、最近は徐々にユーザたちがIssueやPRを上げてくれるようになってきました。2019年は開発者であると同時にマネージャとして多くのユーザとともにdoccanoを発展させていきます。

資格取得

2018年はIPAデータベーススペシャリストネットワークスペシャリストの資格を取得しました。IPAの試験を受けるのは学生時代以来(3年ぶりくらい?)で午前試験の免除もなく体力が持つか不安だったのですが、どちらも一発で合格することができました。よく「実際には役に立たない」等の批判を受けているのを目にしますが、私としては資格取得を通じて体系的に視野を広げられたり、勉強法について見直したのは今後も活かせると思っています。

AutoMLの講演

speakerdeck.com

2018年の12月にはAutoMLについて90分間の講演を行いました。相手が技術者ではなかったので話す内容について結構悩んだ上でスライドを作成したのですが、あまりウケなかった(一番前のおじさんが寝てた(´;ω;`))ので失敗だったかなと思います。ただ、内容自体は結構良いと思っていますし、今後確実に伸びてくる分野なので以下の記事と合わせて見ていただくと役に立つと思います。

qiita.com

2019年にしたいこと

2018年の失敗は色々なことを同時並行にやろうとしたことだと思っています。よく言われていることではあると思いますが、マルチタスクで進めると切り替えのコストが高いことに加えて、一つ一つの仕事がなかなか進まないのでモチベーションがどんどん落ちていくのを感じました。2019年は一つずつ片付けるような仕事のやり方に変える予定です。

2019年は以下のことに絞って取り組みたいと考えています。

  • doccanoのマネジメントとサービス化
  • 研究成果のソフトウェア化
  • 書籍の出版

doccanoはありがたいことにどんどん成長しています。はじめは一人で開発していたので誰かに何かをして貰う必要はなかったのですが、開発してくれる人が増えてきたので何らかの対策を打たないとまずい状況になっています。なので、今年はOSSのマネージャとしてプロダクトを成長させつつ経験を積んでいきたいと思います。

研究成果のソフトウェア化では、研究結果を誰にでも使える形で公開しようと思っています。2019年はテキストからの知識の獲得と活用について取り組もうと考えているのですが、まずはその要素技術である固有表現認識とエンティティリンキングについてソフトウェアを公開できればと思います。

固有表現認識は以下のような感じ。

f:id:Hironsan:20190109122446p:plain

エンティティリンキングは以下のような感じ。以下は「原辰徳」についてエンティティリンキングをした結果です。固有表現を知識ベースにリンクすることで様々な情報を取得できることを示しています。

f:id:Hironsan:20190109122545p:plain

もう一つ取り組みたいのは書籍の出版です。実は昨年から自然言語処理の入門本を書いているのですが、なかなか筆が進まず昨年中に書き終えることができませんでした。今年の早い段階で書き終えて年内には出版できるようにしたいです。

最後になりますが、今年もよろしくおねがいしますm( )m

テキストの構造化を支える技術 -OpenIEの未解決問題-

第3回目の今回は節ベースのOpenIE手法を紹介する予定でしたが、予定を変更してOpenIEの未解決問題について紹介することにします。

2018年に発表された論文「A Survey on Open Information Extraction」では、OpenIEには以下の未解決問題があると主張しています。

  • OpenIEシステムの評価
  • 多言語への拡張
  • フレーズの正規化

各問題について見てみましょう。

OpenIEシステムの評価

OpenIEにおける課題の一つとして、異なるOpenIEシステムを大規模、客観的かつ再現性のあるやり方で評価・比較した研究がほとんど無い点を挙げられます。その理由として、何が妥当な関係タプルなのかという明確かつ正式な仕様についての合意が取れていない点があります。このような状況がアノテーションされたgold standardなデータセットを作るのを妨げています。したがって、客観的かつ再現可能な形で他のシステムと比較するのが難しいわけです。

また、評価における課題として、評価で使われるコーパスがニュースやWikipedia、Webドメインコーパスに限られている点があります。第一回目で書いたように、OpenIEの手法はドメイン独立であるのが望ましいので、様々なデータセットに対処できるべきです。しかし、評価で使われるコーパスが偏っているため、様々なジャンルのテキストに対して手法が有効なのかがわからないという現状があります。

多言語への拡張

OpenIEの2つめの問題点として、英語以外の言語は置き去りにされている点を挙げられます。第1回目と第2回目で紹介したTextRunnerとReVerbは英語を対象とした研究ですし、他の多くの研究でも英語を対象としています。そのため、提案された手法が英語以外でも使えるかと言うと疑問が残ります。それは、ReVerbで関係フレーズを抽出する際に使った以下のパターンが日本語では使えないことからもわかるでしょう。

f:id:Hironsan:20181015101518p:plain
Identifying Relations for Open Information Extractionより引用

言語化を目指した研究の一つとして、PredPattの研究があります。この研究ではUniversal Dependency(UD)パーサの解析結果に対してパターンを書くことで、多言語に対応したOpenIEシステムを作成しています。UDとは、ザックリ説明すると、言語ごとに違っていた依存関係のラベルを統一した規格のことです*1。ラベルを統一することで、UDのラベルに対してパターンを書けば、様々な言語を処理できることが期待されるのです。

以下はGoogleCloud Natural Language API構文解析をした結果です。オレンジ色のラベルがUDのラベルを示しています。このようなUDのラベルに対してルールを書くことで、多言語対応したOpenIEを作ろうというわけです。

f:id:Hironsan:20181024112045p:plain

フレーズの正規化

OpenIEの2つめの問題点として、抽出した関係フレーズやargsの正規化があります。ここで、正規化とは抽出した関係フレーズやargsを代表的な形式に帰着することを指します。たとえば、「originally founded by」のような関係フレーズが抽出された場合、副詞である「originally」を除去するのは正規化の一種です。

正規化が問題となるのは、OpenIEで抽出した関係タプルを下流のタスクで使用する場合です。伝統的な情報抽出システムでは、あらかじめ決められた関係クラスだけを抽出していたので、下流のタスクではクラスを想定して処理を書くことができました。OpenIEだと事前にクラスを定義しないため、クラスを想定して処理を書くことは困難です。

おわりに

第3回目の今回は、OpenIEの未解決問題について紹介しました。次回は、節ベースで関係タプルを抽出する手法について紹介する予定です。

私のTwitterアカウントでも機械学習自然言語処理に関する情報をつぶやいています。

この分野にご興味のある方のフォローをお待ちしています。

参考文献