シンデレラガールズ台詞判定の 開発・運用・反響について たくみP 2017/05/17 http://www.shuukei.info/

自己紹介  たくみP  担当アイドル: 喜多日菜子  Twitter: @shuukei_imas_cg  もともとはモバマス-Pixiv集計所のための更新状況通知用 アカウントだった  @[email protected]  運営しているサイト・サービス http://www.shuukei.info/  モバマス-Pixiv集計所  シンデレラガールズ台詞判定  ミリオンライブ！台詞判定  喜多日菜子LINE BOT 2017/05/17 2

シンデレラガールズ台詞判定とは  機能1「アイドル判定」  任意のテキストを入力 すると「どのアイドル が発した台詞らしい か」をスコア付きで表 示する  機能2「形態素スコア」  テキスト中、どの形態 素が「アイドルらし さ」に寄与しているか、 重みを表示する  主な使用OSS  Jubatus(機械学習フレームワー ク)  MeCab(形態素解析器)  mecab-ipadic-Neologd(単語区 切り用辞書) 2017/05/17 3

技術的解説は記事を参照  Qiitaに「ノンプログラミングで機械学習サービスが作りた い! テキスト分類編」以下3編で解説しました  http://qiita.com/shuukei-imas-cg/items/ea501e62970b309ceea4 2017/05/17 4

開発の動機1  もともとアイマスハッカソン2016(2016/12/17)の 開発研究テーマだった  「シンデレラガールズの台詞のみから「誰の台詞 か」機械学習で判定する」  Jubatusを用いた台詞判定のコア機能はこのときに 実現していた  ハッカソンのテーマである「アイドルを愛でる、ア イマスにContributeする」を(自分なりに)真正面から マジに実行しようとした  二次創作のインフラを作りたかった 2017/05/17 5 https://speakerdeck.com/shuukeiimascg/sindereragaruzufalsetai- ci-falsemikara-shui-falsetai-ci-ka-ji-jie-xue-xi-depan-ding-suru

開発の動機2  「アイドル判定」機能だけではサービスとして成立し ないと考えていた(すぐ飽きられる)  「どこを変えればより特定のアイドルらしくなるか」 を示す機能があれば実用になるのではないか? →形態素スコア機能  それが実現する見込みが付いた  参考にしたもの: 「かまってちゃん小町」 in Jubatus ハッカソン with 読売新聞 #2  Jubatusの学習後の重みを取り出して「らしさ」として 使うアイデア 2017/05/17 6

形態素スコア機能について  Jubatusモデルファイルから重みを取り出す  [アイドル名: [形態素: 重み]] の形に転置する { “アナスタシア”: { "あげる-動詞": -0.0977340885989, "あたし-名詞": -0.400298029184, "あたたかい-形容詞": 0.0333652123809, "あちこち-名詞": -0.145350828767, "あと-名詞": -0.158124983311, "あの-連体詞": -0.29390492117, "あまり-副詞": -0.213139493779, "あら-感動詞": -0.296767287815, "あり-動詞": 0.28585652128, "ありがとう-感動詞": 0.119166985699, "ありません-名詞": 0.246373766782, "ある-動詞": -0.115131826326, "あれ-動詞": -0.244251795935, "あー-フィラー": 0.376662068107, … 転置した「重み」のJSONファイル 実行例→

開発の動機3  Twitterで需要を聞いてみたところ (フォロワー300 のこのアカウントにしては)反響があった  320RTくらい 2017/05/17 8

開発の動機4  来るべき「第6回シンデレラガール総選挙」に 向けて喜多日菜子のダイマがしたかった 2017/05/17 9 [ひらひらふわり]喜多日菜子+ …の 代わりに 「盆踊りをする女性」 ©いらすとや 日菜子、 かわいいよ!

設計・開発開始 10 2017/05/17

アーキテクチャの選定1  制約と前提条件  このサービスのために新しくレンタルサーバ/VPSの 類を契約したくなかった  そんな金があったらガチャを回すから  ガチな24h/365Dayサービスを提供するわけではない  既存のサイトでAWS S3による静的Webホスティング の経験があった  自宅サーバのリソースに余裕があって回線が安定し ていた  いい機会なのでWebフロントエンドの技術を勉強し たかった 2017/05/17 11

アーキテクチャの選定2  JavaScriptによるフロントエンド(いわゆるSPA)を AWS S3に、バックエンドを自宅サーバに配置する ことに決定  フロントエンドがSPAなら、バックエンドが死んでい ても正常にエラーを返せるという期待がある  JSフレームワークの選定: Vue.js  仕様がコンパクトで学習コストが低い  今回は小規模なプロジェクトなのでフルスタックフ レームワークは不要  バックエンド: Python標準のWebサーバ  simple_serverで十分(とこのときは思っていた) 2017/05/17 12

システム構成 13 Amazon S3 Vue.js + Bootstrap フロントエンド Dospara Core-i7 970 Mem: 24GB HYPER-V Server 2012 R2 VCPU: 2 mem: 6GB • Pythom(Falcon + Gunicorn) • Jubatus • MeCab バックエンド Vue-resourceで HTTP通信

開発日程  2016年12月17日  アイマスハッカソンでプロトタイプ作成  2017年2月4日  思い立ってTwitter上で需要をリサーチする → 320RT  2月5日  制作決定、VMインスタンスの整備、バックエンド制作  2月6～9日  フロントエンドの制作  2月9日 18:02  公開 2017/05/17 14

開発中の課題1  Webフロントエンドよくわからん問題  Webpack, Gulp(タスクランナー), Vue.js, CORS, CSS フレームワーク, SASS, トランスパイラ…  覚えることが多すぎる  解決策1: とにかくボイラープレートをベースにして、 JSのエコシステムに完全に乗っかってしまう  解決策2: 逆にまったく使わない。Vue.jsだとHTMLに scriptタグ1行書くだけで導入はできる HTML+CSSで書き始めて、部分的にVue.jsを導入する  そもそもJavaScriptよくわからん問題  ES5, ES2015(ES6), ES2016…  Vue.jsのボイラープレートで入るLinterが指摘してくれ るので、そのとおりに書くだけ  最初にコストをかけても開発環境を整えるべき 15

開発中の課題2  タスクに応じた形態素解析辞書は不可欠  MeCabのユーザ辞書を適切に構築する必要がある  が、単語生起コストを設定するのが難しい  mecab –F オプションで既存形態素のコストを確認しな がら登録する  mecab -F"%m,%c¥n"  単語生起コストが適切でないと…  例:名前が他のアイドル名の部分文字列である場合  菊地真の「真」を生起コスト0で登録 → 真鍋いつきが「真」「鍋」「いつき」に分割されてし まう 2017/05/17 16

公開してみた 17 2017/05/17

公開前の負荷見積もり  観測: 需要リサーチのツイートは320RT, 300Like だった  予想: 2～3日かけて、反応してくれた3～400人が試 してくれればいいかな～  さて、いざ実際に公開してみると…  2017/02/09(木) 18:02 以下の内容でツイート 2017/05/17 18

18:22(公開20分後) 2017/05/17 19

18:26(公開24分後) 2017/05/17 20

18:37(公開35分後) 2017/05/17 21

一気にリクエストが集中  判定(WebAPI)サーバへのリクエスト  判定結果の表示まで10秒以上かかるか、タイムア ウト連発の状態に 2017/05/17 22 時間帯 総リクエスト req/sec 18:00 33709 9.36 19:00 44995 12.50 20:00 41215 11.45 21:00 33229 9.23 22:00 23006 6.39 23:00 17409 4.83

サーバの負荷状況  しかし、サーバの負荷自体は問題なし  CPU load: 15～20%  メモリ: 特にスワップしてない  I/O: 問題なさそう  ネットワーク: たぶん問題ない  Webサーバ(simple_server)がタイムアウトしてプロ セスのkillとforkを繰り返している  設定が適切でないのは明らか  …が、設定方法がよくわからない  このときはWebフレームワークとWSGIサーバの関係も よく解っていなかった 2017/05/17 23

対処  案1: フロントエンドの改修  とりあえず、「判定」ボタンをリクエストが返って くるまで押せないようにDisableする  30分作業してうまくいかないのであきらめた  案2: WebAPIサーバ自体の改修  「Python web API サーバ 高速」でググることからは じめる 2017/05/17 24

WebAPIサーバの改修  2時間ほどかけて(21:18完了)構成を変更  変更前: webapp2 + simple_server  変更後: Falcon + Gunicorn  一瞬(20～50ms)で表示できるように  事前の負荷テストが大事  事前に負荷を見積もってもそれを超えるアクセスが 押し寄せることはある  せめてサーバリソースを適切に使い切ろう  開発用のsimple_serverで本番稼働しようなどという 甘い考えを持たないことが大事 2017/05/17 25

公開当日のアクセス状況  2/9～10の2日間の状況 2017/05/17 26

運用とその後の改修 2017/05/ 17 27

運用1  フロントエンド  ビルド  Webpackを使う  npm run devで開発、npm run buildでビルド  SPAのフロントエンドは環境依存性があまりないので特 にステージング環境は用意していない  必要だとすればCORSやGoogle Analyticsの部分か  デプロイ  gulp deploy で一発でS3にSyncするよう設定[重要]  サービスイン後にはどうせ何らかの問題が発生して修 正が必要になるので、それを素早く行えることが重要  AWSのWeb管理画面からアップロード…みたいなのは 結局コスト高につく 2017/05/17 28

運用2  バックエンド  PyCharm(Python統合開発環境)のDeploy機能で同期  開発用には別ポートのGunicornとJubatusを立てる  学習データの追加や改修時  Jubatusのモデル更新時の停止時間を短縮する方法  あらかじめ別プロセスでjubaclassfierを起動して学習し、 モデルデータをセーブしておく  120,000個の台詞の学習に約10分かかる  Gunicorn終了→Jubatus終了→Jubatusで新モデルを ロードして起動→Gunicorn起動  慣れれば5秒くらいで再起動できる 2017/05/17 29

その後の改修1  ミリオンライブ！ 台詞判定対応(2/20)  1つの判定器(同一のjubaclassifierプロセス)に複数の 特徴を同居させるテクニックを使用  バックエンドを1本化  ミリデレ混合モードの搭載(4/28)  あらかじめ台詞データを結合しておき、上述のテク ニックを使用  1つの判定器プロセスに3つの特徴が入っている状態  「セクシー」や「カフェ」で判定すると面白い結果に なるのでおすすめ 2017/05/17 30

その後の改修2  判定精度の向上  品詞情報(名詞、動詞、形容詞…)の利用  感動詞の「え」とフィラーの「え」を区別する  0.5%くらい向上  ドメイン固有の形態素解析辞書の使用  あだ名や典型的な呼び方を既存資料をもとに登録  「このみ姉さん」問題も同時に解決  やはり0.5%くらい向上 2017/05/17 31

利用者の反響 2017/05/17 32

反応1  最初のリリースツイート 2017/05/17 33

反応2  よくある使われ方  アイドルがどの言い方を好むかの確認に使われる  「あまり」 VS 「あんまり」  「ロックにいくぜー!」 VS 「ロックにいくぜ!」  2人のアイドルが発現頻度的に両思いか否か  「志保ちゃん」→矢吹可奈  「可奈」→ 北沢志保  完全に意図を汲んだ使われ方も  https://twitter.com/ndmctsr/status/853475003316056064 からの一連のツイート  ミリオンライブドラマシアターの推敲に 2017/05/17 34 ＼かなしほ／

反応3  意外な? 使われ方  曲の歌詞をぜんぶぶち込んでくる人がいる  ワンドロのお題探し  適当なタイトルの台詞を入力して判定結果のアイドル で絵を描く  「日常で使える淫夢語録」を片っ端からぶち込む  君だけのBE MY BABYを作ろう！  判定結果上位2人でBMB  自分が言ってほしい台詞を入力して、いずれかのア イドルと判定されることで「システムに承認され た」承認欲求が満たされるらしい 2017/05/17 35

NEologdにゆいちな※採録1 (※大槻唯・相川千夏のカップリング) 2017/05/17 36

NEologdにゆいちな採録2  まだ半信半疑の筆者 2017/05/17 37

NEologdにゆいちな採録3  ガチでシンデレラガールズのゆいちなだった 2017/05/17 38

アイマス人名が追加(5/13)  アイドル282人中276人正しく解析できる  765AS(13), 876(3), ミリ(37), デレ(183), 315(46)  残る6人は報告中 → 5/15の更新で5人修正  みんなもNEologd使おう 2017/05/17 39

まとめ1  低コストで持続的にWebサービスを提供する例を説 明した  金額的コスト、心理的コスト  サービスとしてリリースすることの重要さ  技術記事を書くだけでなく実際のシステムとしてリ リースすることで、技術者でないPにもリーチする (そして意外な使われ方に関する知見が得られる)  一時的な高負荷への対処  いかに負荷見積もりを行っても偶然バズる可能性は ある(そしてあっという間に波が引いていく)。対処 方法について一応考えておく 2017/05/17 40

まとめ2  スマホからのアクセスは7割  スマートフォンの機種によっても横幅は違うので、 実機かエミュレータで確認することが望ましい  機械学習は楽しい  最先端のディープラーニング手法でなくともまだま だできることはある(使いこなすアイデアが追いつい てない)感  サービスの横のつながりがほしい  せっかくバックエンドをWebAPIにしたのだから、 他 サービスから使ってもらう等 2017/05/17 41