AWS Startup ブログ

【開催報告】ML@Loft #5 (NLP)

こんにちは、スタートアップソリューションアーキテクトの針原 (Twitter: @_hariby) です。8月27日に AWS Loft Tokyo で開催された機械学習のコミュニティイベント ML@Loft の第5回では、自然言語処理をテーマとして話が盛り上がりました。興味はあったけどこの日は予定が合わなかった、という方も居られるかもしれないので内容をまとめます。

ML@Loft は機械学習のお悩み相談イベントで、目黒の AWS Loft Tokyo で2019年4月より毎月開催されています。もともとは AWS をお使いのお客さまがサービスの中に機械学習を取り入れて開発・運用していく際のお悩みを気軽に相談できる場が欲しい、ということで始まったイベントです。登壇者 (相談役) が自己紹介を兼ねた10分ほどの Lightning Talk (LT) を順番に行った後、テーブルに分かれて具体的な相談・ディスカッションを行う、という二部構成で開催されています。過去の様子は登壇者のスライド付きでブログにまとまっています [#1(MLOps), #2(MLOps), #3(Recommendation), #4 (Edge)]。

毎回参加者の希望をもとにテーマを決めていて、第5回目となる今回のテーマは自然言語処理 (NLP)、特に日本語を中心とした実務での自然言語処理に関して、様々な課題感と現状のベストプラクティスについて話す会となりました。今回登壇をお願いしたのは 野澤 哲照 氏 (コネヒト株式会社)、島岡 聖世 氏 (株式会社Studio Ousia)、舛岡 英人 氏 (株式会社レトリバ)、榊 剛史 氏・山中 志一 氏 (株式会社ホットリンク)、藤井 美娜 氏 (GVA TECH株式会社) の5社6名です。これら NLP の経験豊富な方々に研究から実運用まで様々な角度から知見を共有して頂きました。

LT セッション

それではセッションの内容を振り返ってみましょう。それぞれ詳しい情報は登壇者のスライドにあるのでチェックしてみて下さい。

「ママ向けコミュニティサービスを支えるNLP」野澤 哲照 氏 (コネヒト株式会社)

日本語の自然言語処理では形態素解析や前処理などやることが多いです。それをプロダクション運用する際に AWS サービスを活用することで “心理的安全性の高い” ML フローを構築したというお話をして頂きました。事前学習の部分は、Gensim の word2vec モデルを作っておいて Amazon RDS → AWS Glue → Amazon S3 で ETL のフローを構成されています。この ETL 部分と AWS Fargate で前処理 (分かち書き、品詞制限、正規化、ストップワード除去、辞書作成、埋め込み行列の作成、テキストのシーケンス化、train/test 分割) するところまでを AWS StepFunctions で書き、TensorFlow のモデルをトレーニング、リアルタイム推論用のエンドポイントにデプロイする流れです。プロダクション環境での精度を継続的にモニタリングするために Re:dash を使った可視化もされているそうです。

ママ向けコミュニティサービスを支えるNLP

「AWS SageMaker導入による機械学習インフラ大改善」島岡 聖世 氏 (株式会社Studio Ousia)

これまで運用してきた機械学習システムの問題点を Amazon SageMaker を使うことで劇的に改善されたお話を聞かせて頂きました。レガシーなシステムでは、機械学習における本質的でない部分に関するコードが肥大化していたこと、各コンポーネントが密結合していることによりモデル改良が困難という2つの大きな課題がありました。島岡さんは Amazon SageMaker がこれらの問題を解決できることに気づき、周辺的な処理をマネージドサービスに任せ、かつインターフェースが統一されることで各コンポーネントが疎結合になるようインフラ改善プロジェクトを主導しました。これにより、40%のコード量削減、70%の学習時間短縮、質問応答において4.4%の正解率向上がみられたそうです。実際社内のエンジニアや顧客からもポジティブな意見が寄せられプロジェクトは大成功しました。

AWS SageMaker導入による 機械学習インフラの再構築プロジェクト

「自然言語処理をはじめるまでの道のり」舛岡 英人 氏 (株式会社レトリバ)

株式会社レトリバでは研究として新聞記事の見出し生成やトップカンファレンスへの論文投稿 [1] などを積極的におこなっていることをはじめに紹介頂きました。研究成果をビジネスに活かす上で、B2B の自然言語処理ではビジネスロジックとの最適なバランスを探し当てるのが困難であるという課題があります。PoC 期間が短いことに対しては検証データの整備・事前学習を、アノテーションデータが少ない場合には教師なし学習・タスクの細分化によって現実的な課題をクリアしています。
さて、自然言語処理を始めるまでには3つのステップがあるといいます。与えられたデータが機械学習に利用可能かを精査します。その上で特徴量が正しく抽出できているかを可視化しながら確認します。そしてアルゴリズムを選定、特にバッチ学習/オンライン学習はどうするか深層学習は必要かを検討します。また、実際の案件では顧客の期待度を調整することが重要となるので、そのあたりの詳しい話をラウンドテーブルのディスカッションでお話しされたようです。

[1] Watanabe, S., Hori, T., Karita, S., Hayashi, T., Nishitoba, J., Unno, Y., Enrique Yalta Soplin, N., Heymann, J., Wiesner, M., Chen, N., Renduchintala, A., Ochiai, T. (2018) ESPnet: End-to-End Speech Processing Toolkit. Proc. Interspeech 2018, 2207-2211, DOI: 10.21437/Interspeech.2018-1456.

20190827_AWS_Loft_LT

「【悲報】TwitterのNLPがﾏｼﾞ??やばたにえん?の無理茶漬けwwwww」榊 剛史 氏・山中 志一 氏 (株式会社ホットリンク)

榊さんからは Twitter を代表とするソーシャルメディアにおける NLP に関して、テキスト分析技術と NLP の関係について解説して頂きました。ソーシャルメディアの文書を入力として前処理の後、形態素解析 (分かち書き) を行います。その後はタスクによって必要な処理が異なりますが、検索の場合はそのまま、話題後・関連後を知りたい場合は複合語処理が必要となります。講演タイトルとして設定頂いたような、Twitter に見られる文書の特徴としては

  • 意味のない煽り文句「【悲報】」
  • コミュニティに特化した略語「NLP」
  • 全角の中に突如現れる突然の半角「ﾏｼﾞ」
  • 絵文字「??」
  • 謎の慣用句「やばたにえん?の無理茶漬け」
  • その慣用句の中に絵文字「?」
  • 長さが不安定な草「wwwww」

などが含まれる場合があります。これらに対処するため前処理を工夫することで「【悲報】TwitterのNLPがマジやばたにえんの無理茶漬け」というテキストに変換した上で分かち書きを行います。
続いて山中さんから、問題に対する具体的な手法の工夫について2つの例を紹介して頂きました。SNS 投稿からのキーフレーズ抽出に BiLSTM – Char CNN – PoS (part-of-speech) – CRF (conditional random field) を使うことで、人手で作成したキーフレーズデータを用いた検証において辞書ベース+ヒューリスティクスの手法を DNN が Precision で上回り、さらにこれらを合わせた手法が Recall, F1 の値でそのそれぞれを上回るという結果を見せて頂きました。SNS 投稿のテキスト分類においては前処理・分かち書きの効果を検証するため、BiLSTM の入力を単語単位と文字単位で比較したところ、単語ベースの方が処理が速くかつ Precision, Recall, F1 ともに高い値を得られました。よって現状の日本語 SNS のテキスト分類では単語を適切に処理した方がいい、ただし、SNS のテキストに対する前処理や分かち書きの知見が社内にない場合は、文字単位の処理でも一定の性能は得られるとも言える、という結論をお話し頂きました。

20190827 AWS ML@Loft#5 by Hottolink

「NLPモデルの解釈性について」藤井 美娜 氏 (GVA TECH株式会社)

藤井さんからは契約書データの特徴を法律文書との比較でお話し頂きました。言語学においては「分野ごとに語彙も文型も異なる」ことが広く知られているため、契約書データにおいても特有の傾向があるはずで、モデル構築や分析のためにはこれを理解することが重要とのことで実際に国立国語研究所のコーパス [2] を使って比較した結果を紹介して頂きました。手法の選定のため品詞構成を見ると、契約書と法律文書は品詞分布 (文の書き方) は似ているが、契約書の方が副詞・代名詞・連体詞が多い (表現豊かな) ことが分かりました。さらに、契約書の方が接続詞が多く (但し書きを文に追加)、逆接の接続詞により意味が反転するため、BOW でうまく処理しきれない可能性があるので next sentence prediction などを考慮する必要がありそうだ、といったことが分かります。また、頻出語彙を比較すると、契約書には頻出する「甲/乙」「受領」「定める/生ずる/負う/支払う/返す」などが法律文書で使われることが少ないという差異、すなわち書き方は似ているが書く内容や責任の課しかたが異なるということが示唆されました。データの解釈により契約書は法務文書を包含するわけではないことが分かりました。
モデルの判断根拠を探るためのモデルの解釈性についても話して頂きました。これに対するアプローチ (大局的/局所的な説明と説明可能なモデル設計) と「解釈性」に関する解釈 (Attention で解釈できる/できない/加工すればうまくいく説) を整理した上で、結局何が分かればモデルを解釈したことになるのかがポイントで、モチベーションがどこにあるかが重要だというメッセージがありました。GVA TECH株式会社の場合はユーザーへの説明責任のため、弁護士が契約書レビューの際に注目するポイントとモデルが注目しているポイントを比較するなど試行錯誤中とのことです。

[2] 現代日本語書き言葉均衡コーパス (BCCWJ)

Round Table ディスカッション

上記6名の方に加えて株式会社Studio Ousia CTO の山田 育矢 氏にも協力頂きラウンドテーブルを行いました。とてもディスカッションが盛り上がり書ききれないほどですが、イベント時に参加者の方が使っていたメモから一部を抜粋して紹介します。

  • 不適切投稿検知の閾値はどう決めている？
    • SageMaker の推論エンドポイントからは [0, 1] の範囲の float で返すようにして、見る側で柔軟に選べるようにしている
    • 違反判定の recall は高く (違反投稿は確実に拾えるように) したかった
  • 差分更新はどうしてる？
    • 月一でモデル更新
      • そもそも不適切ワードは日時によって変わるもの？なぜ再学習が必要？
        • この投稿は荒れそうだ、といった判定をしている。イベントがらみの話題とか
  • BERT の fine tuning ってサクッとできました？
    • 結構学習が必要。SageMaker は並列分散処理で学習時間を短くできるのが良い
    • 言語データも GPU 使わないと現実的な時間で終わらない場合がある
  • 研究テーマは1人でやるか、複数人でやるか、どちらが良いのでしょう？
    • 自然言語処理の研究はなかなか分担が難しい。1人の方がやりやすいのではないか。
    • エンジニアとかと役割で分けるのは可能かもしれないが、リサーチャーの中で役割を分割するのは難しいという実感がある。
  • 属人化しないよう気を付けていることは？
    • コードを綺麗にしておく、というのは基本的なことのようで非常に大事。
  • Jupyter ノートブックなどで書くと実行順がバラバラになりがちだが、どう対処すれば良い？
    • はじめは汚くても素早く作って、結構書き直すことが多い。
  • テストどう書いている？
    • ライブラリに不具合がなければ、NN 自体にあまり複雑な検証が求められることは多くないのでは？という感覚がある。
  • 最近 NLP の pre-trianed 系のがたくさん出ているが、どういうステップで製品に入れているか
    • BERT を試しても効かなくて、word embedding で頑張ることが多い
    • BERT の実装が色々出てるけど中身はそんなに変わらない。最近だと RoBERTa がいいのでは
    • PyTorch transformer でも [CLS] token とったりとか、その辺は普通
    • wikipedia2vec を社内で作っている
  • Wikipedia みたいなグラフ構造がある自然言語処理ってこれから流行る？
    • BERT の文脈と融合してくると面白いですよね
    • ちなみに Wikipedia のグラフのデータは scipy.sparse で 3GB ぐらいなので、意外とメモリに乗る
  • B2B だとモデルが個社ごとにできて大変になりませんか？
    • BERT のように重いモデルは使っていないので問題になってない
  • 文書の校正・校閲などはどこに難しさがあるか？
    • 形態素解析ができないと、正直校正・校閲は難しいと思ってる
    • 新聞社のデータはルールベースで良いぐらいデータが綺麗である
  • 顧客の期待値を調整するとは？
    • まず最低ラインをはじめに決める
    • その上で最終的なゴールを設定する
    • そこから徐々に具体的な課題に落としていく
  • 自然言語処理、はじめにどこから手をつければいい？
    • まず生データを見る
    • 結局何ができる・できないを判断するために、人手で「アテ」を付ける必要がある
  • 前処理ツール何かいいのありますか？
    • NEologd
    • とはいえ結構独自になっちゃう
  • 辞書の使い分け
    • ユーザーに見せるやつなら NEologd が最強かも
    • 細かく分けるなら UniDic
      • 検索とかだと細かく分ける方が使いやすい
    • Sudachi は長単位・短単位がある
      • 速度が問題
  • 辞書の作り方
    • 目的別に作る
    • Twitter とか新しい単語が次々出てくると結構困る
  • NLP プロジェクトの方向性を見誤らないためには？ビジネスをささっと進めるには？
    • とりあえずの何かを作って見てもらう
    • 分類なら FastText で
    • クラウドソーシングで正解データを作る
  • 機械学習の9割ぐらいは前処理ですよね？
    • ちゃんとしたデータがない場合はそうなる
    • ビジネスニュースとかは結構綺麗だったりする
  • 適切な評価が難しくて困っている
    • 何か結果が出そう、と思った後の次のステップが難しい
    • 遠回りのようで、元のデータを分析するのが一番の近道かもしれない
  • 今日覚えて帰って欲しいこと
    • 契約書のタイトルは関係ない
    • タイトルに「準委任契約」と書かれていても中身が請負契約な内容であれば、裁判では中身で判断される

などなど、まだ話し足りないほどでした。ご登壇・ご参加頂いた皆様、改めてありがとうございます。この次も再び自然言語処理と、レコメンド・時系列処理などをテーマに MLPP というイベントと共同開催で9月20日に行われました [ML@Loft #6]。内容については開催報告ブログをお待ち下さい。

このブログの著者

 

針原 佳貴 (Yoshitaka Haribara)
スタートアップ担当のソリューションアーキテクトです。博士 (情報理工学)。