OSSかな漢字変換『Egoistic Lily』の紹介＆今後の展望
•
2 likes•1,721 views
IM飲み会2019で紹介したスライドです。 KOFのスライドよりやや高度な内容…？
Recommended
More Related Content
What's hot
What's hot (20)
More from Masahiko Hashimoto
More from Masahiko Hashimoto (20)
Recently uploaded
Recently uploaded (14)
OSSかな漢字変換『Egoistic Lily』の紹介＆今後の展望
- 1. OSSかな漢字変換 『Egoistic Lily』 の紹介 ＆ 今後の展望 はしもとまさひこ＠おーぷん万葉 feat.XDDC IM飲み会 2019 2019/12/28
- 2. 2019/12/28OSSかな漢字変換『Egoistic Lily』 2/24 自己紹介 Name： はしもとまさ（または鹿） Twitter: @shikanotsukimi ● 東海道らぐ (Tokaido Liuxn Uesr Gruop) ● おーぷん万葉プロジェクト オープンデータを使用したかな漢字変換の自作など ● ちびぎーこ保護者会（別名：日本openSUSEユーザ会） ● 仕事は自然言語処理界隈では（たぶん）ない人
- 3. 2019/12/28OSSかな漢字変換『Egoistic Lily』 3/24 『XDDC』とは 正式名称： 『Cross Distribution Developers Camp』 Linuxディストリビューションの枠を超えて 各個撃破…じゃなかった、課題解決しよう！という集まり 参加Linuxディストリビューション – Debian – openSUSE – Ubuntu
- 4. 2019/12/28OSSかな漢字変換『Egoistic Lily』 4/24 今日のお話 DNNを使用したOSS新かな漢字変換 『Egoistic Lily』のお話です ※XDDCの課題のひとつ ＝ かな漢字変換
- 5. 2019/12/28OSSかな漢字変換『Egoistic Lily』 5/24 ※おさらい Mozc 〜 Since 2010 〜 Google日本語入力のオープンソース版 現在のLinuxデフォルトといえばほぼこれ！ – Ubuntu、Debian、openSUSE… – 例外： RedHat系（Fedora、CentOS） Mecab と似たアルゴリズム…？
- 6. 2019/12/28OSSかな漢字変換『Egoistic Lily』 6/24 Mozcの問題点 ● 現在開発が停止してしまっている… – 例えば『令和』 この単語を追加するのに 各ディストリビューション毎に対応する必要が 発生してしまっている状況 （Debian, Ubuntu, openSUSE...） – 連接コストについては『平成』からの丸パクリ対応 – 但し、単語生起コストについては適当な値を入れるしかない ※コーパスを使用しているわけではない
- 8. 2019/12/28OSSかな漢字変換『Egoistic Lily』 8/24 が。 『Egoistic Lily』は 本当にDNNでどうにかしてしまいました 注：RNNではありません
- 9. 2019/12/28OSSかな漢字変換『Egoistic Lily』 9/24 使用しているモデル ＝ AutoEncoder 入力をエンコードして、特徴抽出した後 デコードしてデータを復元し、入力値と比較する ⇛きちんと復元できればそれって異常なし！ 異常検知などでわりとどこでも使われてる一般的なモデルですね 入力 出力 特徴抽出 二乗誤差を算出して 誤差が大きい 異常度が高い⇛
- 10. 2019/12/28OSSかな漢字変換『Egoistic Lily』 10/24 異常度が高い日本語って？ 「私の名前は中野です」＝正常 「私が名前は中野です」＝異常 何故これが異常と言えるのか？
- 11. 2019/12/28OSSかな漢字変換『Egoistic Lily』 11/24 係り受けの関係に着目 ● 「私 / の / 名前」 ⇛「私」が「名前」に係っている 「私」と「名前」という単語を「の」が結んでいる ● 「私 / が / 名前」 ⇛「私」が「名前」に係っていない 上記の３単語は関連性がない つまり、３単語をペアにして、正常か否かを学習させてみる
- 12. 2019/12/28OSSかな漢字変換『Egoistic Lily』 12/24 とりあえずの実装（１） １．係り受けで紐づく３単語をセットにして抽出 ⇛それぞれの単語に16bitの乱数を設定 ⇛16列のベクトル（0 or 1）に変換して ３単語 × 16bit ＝ 48列をひとつの学習データとする 1 0 0 1 …… 1 0 1 1 1 …… 0 1 1 1 0 …… 0 私 の 名前 合計48bitの 0 or 1 をAutoEncoderの入力へ 単語ごとに テキトーな乱数を 16bit化
- 13. 2019/12/28OSSかな漢字変換『Egoistic Lily』 13/24 とりあえずの実装（２）←あくまでとりあえずなので！！ ２．AutoEncoderで学習させて出力として出てきたベクトルを 次回学習時の入力として使用する ※平均をとり、平均以上の値を “1”、そうでなければ “0” として 再度16bitの値へ変換する（ひとまずこれで！！） 入力 出力 48bitの 0 or 1 の行列 48個の float型 の配列 Auto Encoder 配列の平均を取り 0 or 1 の行列へ 変換 再び入力へ
- 14. 2019/12/28OSSかな漢字変換『Egoistic Lily』 14/24 とりあえずの実装（３） ※補足編 実際はこれを一つの正常データとして学習してます 01…000…010…0 1 0 0 1 …… 1 0010000 係り受け解析から得た 単語ベクトル 単語の品詞情報 ※one-hot 名前のの私 直前の単語係り元文節 の付属部 係り元文節 の自立部 これを正常データとして学習 ⇛学習＆変換に使用します Mozcでいうところの連接コストをDNNで求めるイメージ ⇛最終的にはコスト最小法で変換を行います
- 15. 2019/12/28OSSかな漢字変換『Egoistic Lily』 15/24 とりあえずの実装（4） ※補足編 実際の変換の肝となる部分 01…000…010…0 1 0 0 1 …… 1 0010000 係り受け解析から得た 単語ベクトル 単語の品詞情報 ※one-hot 名前のの私 直前の単語係り元文節 の付属部 係り元文節 の自立部 この部分だけを見れば 従来の単語N-gramの変換をDNNで求めてるとも 言えますね
- 16. 2019/12/28OSSかな漢字変換『Egoistic Lily』 16/24 『Egoistic Lily』…その実態は？ Mozcのコスト最小法 ＋ 単語bi-gramによるかな漢字変換 をAutoEncoderを用いて実装した形
- 17. 2019/12/28OSSかな漢字変換『Egoistic Lily』 17/24 その特徴は？ ● RNNよりは学習速度が速い……と思う ● 新単語は品詞情報さえあればそこそこ変換可能 ● 現状、単語生起コストというものが存在しない – 『大阪』と『大坂』の区別不可！ ● 事前アノテーションがめっちゃしんどい！！ – 現在はKNPを使用（←係り受けを行っているため）
- 19. 2019/12/28OSSかな漢字変換『Egoistic Lily』 19/24 きっとココだ！！！ １．係り受けで紐づく３単語をセットにして抽出 ⇛それぞれの単語に16bitの乱数を設定 ⇛16列のベクトル（0 or 1）に変換して ３単語 × 16bit ＝ 48列をひとつの学習データとする 1 0 0 1 …… 1 0 1 1 1 …… 0 1 1 1 0 …… 0 私 の 名前 合計48bitの 0 or 1 をAutoEncoderの入力へ きっとココ！
- 20. 2019/12/28OSSかな漢字変換『Egoistic Lily』 20/24 ここってそれこそ純粋に… それこそ Word2Vec とか BERT とかを 使えばいいんじゃないの！？
- 23. 2019/12/28OSSかな漢字変換『Egoistic Lily』 23/24 今後のToDo ● TensorFlowからPyTorchへ移植 – TensorFlow2.0になってから pipのバージョンを上げる必要があるため 『u』で始まるディストリビューション関係者からクレームがｗ ● 辞書にNEologdを使用したい！！ – ただし、現在使用しているのはKNP……orz ● 単語生起コストも実装しないと – FineTuningでなんとかなる……かな？ – 『自分でコーパスからモデルを作りたい』という人も…本当にいる？ ● 深層学習っぽいことをしたい！←ぉ