エンジニアMのAI学習記録（2018年2月分）
当社のWeb関連技術の公開と採用活動のために掲載しています。
（2018年3月5日更新）
みなさんこんにちは、エンジニアのMです。
これは当社の技術やAIに興味のある方に向けた日誌になります。
今月も毎週更新していきます、よろしくお願いします。
2月5日
■ 久々に小説生成モデルの実験
しばらくぶりに小説生成モデルの学習を回してみる。
当時はあまり深く考えていなかったが、使っていたのは「Seq2Seq+Attentionモデル」である。
簡単な解説、比較は以下を参照してほしい。
- Seq2Seq+Attentionのその先へ – Qiita [リンク]
コードを再確認したところ、num_heads変数で注目単語数を変更できるようだったので、数を1→3として出力の傾向がどう変化するか確認したいと思う。
一文が長いタスクなので、少なからず有効ではあると思うのだがどうだろうか。
現環境で3,300step/h程度（バッチサイズは64）の速度で学習が進んでいるが、収束にはしばらくかかりそうだ。
i5-7400（4コア）を100%使ってこの速度である。
Windows側で割り当てるコア数を制限し、20step単位での所要時間を確認したところ以下のようになった。
- 1コア 52秒/20step
- 2コア 30秒/20step
- 3コア 24秒/20step
- 4コア 18秒/20step
数字自体はかなりブレがあるので参考程度。
TensorFlowはきっちりリソースを使い切ってくるので、コア数をさらに増やせばある程度の時間短縮になることは間違いない。
自前のPCで機械学習をある程度（お試しではなく）回してみたいのであれば、CPUは十分高性能なほうが良いだろう。一般向けCPUは最上位モデルでもそれほど高価ではない。
2月6日
■ 昨日の続き
引き続き小説生成モデルの学習を進める。Perplexityの値が十分に下がるまではまだまだかかりそうだ。
ソースコードを眺めていたら、アテンション処理の一部にCPUを割り当てていることが分かった。1→3に注目数を増やした分だけCPUへの負荷が高まっていた結果、昨日のコア数による大きな差が生まれていたわけだ。
借りてきたコードを改変して使っているので、意識して読んでいないと案外気づかないものだなと思う。
■ 経過
Perplexityが約35まで下がったところで少し文の出力を試してみた。
まだまだ途中の段階だが、出力が偏っている感じはあまりしなかった。
文の構造がかなり怪しかったので、もう少し学習を見守っていく必要がありそうだ。
2月7日
■ 引き続き学習を回していく
学習率の減衰を少しきつくしすぎたような感覚はあるが、少しづつPerplexityの値は小さくなっていっているのでこのまま回していく。
若干1000ステップあたりの時間が短縮されてきているのは、学習が進んでネットワークが疎になってきたためと解釈していいのだろうか。
■ PythonでGUIアプリケーションを作る方法を調べる
すぐに何かを作るというわけでもないが。
基本的にPythonしか使っていないので、Pythonでの記述方法について知っておいたほうが良いと考えた。
そうすれば以前Pythonで記述したコードに、GUIのインターフェースを付けることも可能になる。
将来性を考えて「kivy」を触ってみることにした。
スマートフォンを含むクロスプラットフォームなGUIライブラリということで、後々広く使えそうだというのがその理由だ。
触ると言っても機械学習でPC使用率はほぼ常時100%なので、とりあえずはネット上のサンプルコードを眺めることになるが。
■ 「kivy」で色々試してみた人の記事を読んで
- Python Kivyの使い方① ～Kv Languageの基本～ [リンク]
思っていたよりややこしいか、と思ったがGUIアプリケーションの作成ならこんなものだろうか。
昔、C言語でWindowsAPIを使う場合について調べて心が折れた頃に比べれば、遥かに難易度は低い。
マルチプラットフォームとは言っても、当時のAndroid、iOSへの対応はあまり良くなかったようで、今どうなのかについては明日調べてみようと思う。
2月8日
■ 小説生成モデルの精度向上は難しい
アテンションの数を増やした効果はあったように感じるが、気のせいかもしれない。
まだまだ試せるアイデアはあるが、メモリ消費量が大変なことになってだんだん厳しくなってきた。機械学習にはCPU、GPUの強化以上にまずメモリを積んだほうが良いのではと感じるレベルである。RNNはメモリ消費が非常に重い。
まずはSSDに頑張ってもらって、もう少し実験を続けたい。
■ GUIアプリ作成に「Tkinter」はどうなのか
Pythonに標準でついてくる「Tkinter」というGUIライブラリがあるが、デザインが今となっては古いという話でとりあえず選択肢からは外していた。
画像検索で見る限り、確かに（好意的に捉えれば）レトロな印象である。
コードの書き方自体は「kivy」より遥かに簡単そうだ。初心者向けという紹介をしているブログは見かけていたが、その通りと言えよう。
自前のツールをとりあえずで作る分には「Tkinter」でも問題無さそうだ。標準ライブラリなので導入の手間もない。
2月9日
■ 小説生成モデルの学習を回す
チェックポイントを取るのに12分もかかる（1000ステップの学習は24分程）ので、こまめにチェックポイントを取っていると無駄が多い。
チェックポイントを取るだけでメモリ消費量が+5GBされる重い仕様である。
学習経過はほとんど分からなくなるが、5000ステップ単位で進めていくことにする。
なお以前は無理やりReLUを活性化関数に使っていたが、どうやっても値が発散してしまったのでTanhに戻して実行している。
これも含めて結果にどう影響するか、確認していきたい。
2月13日
■ 小説生成モデル
活性化関数にtanhを使うと、やはり挙動が怪しい。まだ2万ステップほどしか回していないが、繰り返しの出力が多い。
ReLUにも、発散に気をつけなければならないRNNをさらに発散させやすくしているという弱点はあるのだが。
他の活性化関数を試してみるというのもありかもしれない。
■ 経過
ReLU系の活性化関数はどうやっても発散してしまったので、tanhと似た別の活性化関数で試してみている。
あまり期待はしていないが、SSDのKeras実装コードを読んだりしている間に回して、経過・結果を見ていきたいと思う。
2月14日
■ Google AutoML
1ヶ月ほど前にα版が公開された「Google AutoML」。
現在は「Vision（画像認識）」のみの公開で、テスト段階である。
いずれは一般物体認識などの機能もAutoMLでできるようになるのだろうと思うが、そうなると私のような初級エンジニアの仕事は立案とデータ収集
、モデル検証くらいでおしまい、となる。
ある手法の仕組みから勉強して実装したいなどの目的でなく、業務にうまく適応してサービスとして動かしたいが、仕組みや実装については気にしないという場合はAutoMLのようなサービスを使ったほうが、高精度かつ高速に適応できることになる。
■ これを踏まえてどう勉強していくべきか
Googleの担当者も「AIの民主化」という言葉を使って、誰でも簡単に機械学習を活用できるようにする方向性を打ち出している。AutoMLの適用範囲はどんどん広がっていくだろう。
そうなると必要な知識は、
- 機械学習の基礎
- 必要なデータの見積もり（収集方法、規模、種類）
- データの前処理（欠損値、異常値などの対応）
- モデルの検証（精度、速度の検証、改善方法の提案）
- AIを活用したサービス、社内システムの企画立案
こんなところだろうか。もっと自動化される可能性も十分にある。
こうなってくると、AIエンジニアというよりAIマネージャーと言ったほうがしっくりくる。
AIの進歩が想像以上に早く、ほとんど先が読めない雰囲気になってきた。
その時々で何が必要なのか見極めて、時代に適応していきたいところだ。
■ WSL（Windows Subsystem for Linux）上でTensorFlow
WSL上のUbuntuでTensorFlowを動かしてみる。
Ubuntuはほとんど触ったことがないので、Ubuntuの使い方から勉強していく。
- Windows 10でLinuxプログラムを利用可能にするWSL（Windows Subsystem for Linux）をインストールする – @IT [リンク]
- Windows 10のBash on Windowsで、apt-getを使ってパッケージをインストールする – @IT [リンク]
- ubuntu16.04でのTensorFlow環境構築手順メモ – HELLO CYBERNETICS [リンク]
- Ubuntu 16.04 に NVIDIA ドライバを導入する – Tech Memo [リンク]
Nvidiaドライバーのインストールを開始して眺めていたら、途中でBad Addressと表示されインストールに失敗したファイルが。
様子を見ていたが一向に変化がなく確認してみると、メモリ使用率が100%かつディスク使用率100%という地獄のような状態になっていた。
最新のPCとは思えない恐ろしく重い状態の中、なんとかリソースモニターにたどり着いて確認すると、ディスクI/Oが 4GB/s とかいう訳の分からない表示。
Windowsシステムを筆頭に恐ろしい量のディスク要求が発生していた。
■ 諦めて強制終了
再起動してイベントログを見るとMcAfee関連ファイル（MFEAvSvc.exe）でエラーが発生していた。
そしてその前後に、
カスタム マーシャリングされたオブジェクトのマーシャリングを解除するときにマーシャリング解除のポリシー チェックが実行され、クラス {(略)} が拒否されました
というログが複数あり、Ubuntuとの間で何か不具合が生じた様子。
WSLとUbuntuが悪いのか、McAfeeが悪いのか判断しかねるが、こうやってホストOSを巻き込んでトラブルを起こされると少々怖い。マーシャリング云々だと、McAfeeは被害者かもしれない。
WSLは重い処理を実行させるのには、向いていないのだろうか。
■ Nvidiaドライバーはインストールしたが
改めてインストールを実行したところ、一応完了できた。
「nvidia-smi」で無事インストールされたか確認してみたが、
NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
このようにFailedと言われてしまった。
WSLからGPUを利用することはできない、という解釈でいいだろう。
というわけでTensorFlowのインストールを試すまでもなく、断念となった。
非GPU版なら動くのだろうが、正直あまり試す意味はないので割愛する。
興味がある方は自分で試してみてほしい。
2月15日
■ 企画書・提案書などの作り方について学ぶ
本を参考に、いわゆるビジネス文書の書き方を学んでいきたいと思う。
- 企画書・提案書の上手な作り方（中経出版・ISBN 978-4-8061-3190-8）
- 報告書レポート提案書の書き方 すぐ書ける そのまま使える140文例（日本実業出版社・ISBN 978-4-534-04721-2）
2月16日
■ Wordのテンプレートを使って企画書を書いてみる
内容はさておき、ビジネス文書のフォーマットで文書を作る。
Wordを扱うのは久々なので、操作を思い出しつつ触っていく。
■ 小説生成モデルの実験
- 2作品を学習データに使っていたが、1作品に絞る
- 元の文章の2文を1単位として入出力する
- 「！」「？」「…」などの記号をデータ処理段階で削除しない
- 活性化関数をtanhではなくsoftsignにする
- 入出力が長くなるので、Attention Headsの数を1→6とする
各設定を大幅改変して学習を継続中である。
それぞれの意図は、
- それぞれの癖に合わせようと混乱していた可能性を考え、1作品に絞った。
- 1回の情報量を増やして、話の流れを少しでも再現できることを期待する。
- 正しく学習が進めば適切に記号も扱えるはず。
- tanhより0付近の傾きは小さいが影響は未知数。何か好影響があれば。
- 記号類を延々繰り返すのを回避するなどの効果があれば。
といったところだ。今度はどうなることやら。
2月19日
■ 文書検索手法について調べる
概念検索や、あいまい検索といった単なる単語一致ではない検索手法について調べる。
- 単語の類似度と感情表現を考慮した質問記事の判定手法 [リンク]
- 検索質問の主題分析に基づく類似文書検索と特許検索への応用 [リンク]
- あいまいさを含む質問文章による過去の類似（質問一回答）文書検索法 [リンク]
- 概念検索はなぜ上手に 検索できるのか？ [リンク]
- 文書ベクトルの次元削減に基づく有効な類似文書判定 [リンク]
2月20日
■ 本を読み返しつつ思案
いままで読んできた本を読み返しながら、当社の業務に適用するとしたらどういう風になるか予想してみる。
過去全くイメージしてこなかったわけではないが、改めてそういったテーマを持って読み返してみる。
■ フリーミアムモデルについて
当社のサービスはいわゆるフリーミアムモデルに該当するわけだが、成功しているフリーミアムのサービスやその特徴などについて調べてみる。
私の話だと、「基本無料」のサービスはこれまでに色々と触ってきているが、無料部分でもそれなりに不満が無いことが重要な感覚はある。
制限されすぎると有料登録しようという気がそもそも起きてこないので、そのあたりの調整が重要なのではないだろうか。
あとは「有料サービスの試用期間」も重要だろう。課金前に試せることは、リスクが低減されるように感じられるからだ。
感覚として、有料サービスを過剰に提案されるのもストレスかもしれない。顧客を煽るようなビジネス（例えばフリー版と称してPCを検査して存在しないエラーを見せて有料版に誘導する、とか）がよろしくないのは明白だろう。ついでに運営企業のイメージまで悪化する。
こう書いていると、ユーザーは多かれ少なかれわがままなものだなと感じられる。こういったユーザー目線の感覚は忘れないようにしたい。
2月21日
■ 簡単な企画書を書く
練習用の1枚企画書を書く。
専門知識もまだまだなので破綻しないように書くのが大変だが、必要なことを1枚にしっかりまとめる練習には良い。
以前に読んだ参考書も見返しつつ、それっぽくまとめていく。
2月22日
■ 小説生成モデルの経過
Attentionの数を増やすなど色々変更したおかげか、記号類をそのままにしても学習はそこそこ進んだようだ。
しかし「…（三点リーダ）」の繰り返しが多くなってしまい、肝心の文が少なくなってしまった。三点リーダの使いすぎで読みづらい例、のような形でこれはこれで面白い結果だったが。
入出力を1文単位に戻し、また様子を見たいと思う。
2文ずつ入力した時の出力は非常に長いものから、非常に短いものまで見られていたので、短文に引きずられなくなっていると判断した。
記号は、「！」「？」「、」「。」「…」の5種類について、2個以上続く部分を1個に減らす正規化をした。
2月23日
■ 三項演算子について
PHPの学習書を読んでいてふと思った。
C言語でそれなりにコードを書いていたのに、三項演算子を使ったことがないと。
「三項演算子 可読性」あたりで検索するといろんな意見が出てくる。
ネストしなければいい、ネストして読みにくいのは書き方が悪い、とか。
一番理由として納得できたのは、
- 三項演算子は可読性を落とすか – Qiita [リンク]
こちらの説明だろうか。
値のチェックと、値がNull（あるいはFalse）でないという保証を同時にすることができている。ここではエルビス演算子で良いケースということで、三項演算子は使わなくなっているが…。
使われる必然性というのが重要であって、玄人感を出そうとして使うのは何か違うと思う。if文だらけのコードもきれいとは言いづらいが。
■ Pythonの場合
Pythonにも順番は違うが、if elseによる三項演算がある。
>>> x = 100
>>> y = 50 if x > 50 else x
>>> print(y)
50
>>> i = None
>>> j = 0 if i is None else i
>>> print(j)
0
>>>
if else で記述されるので、記法に馴染みが無くてもなんとなく伝わる感じはする（例を1文字変数にしたせいでわかりにくくなったが）。
>>> i = None
>>> k = 0 if i is None else 50 if i > 50 else i
>>> print(k)
0
>>> i = 100
>>> k = 0 if i is None else 50 if i > 50 else i
>>> print(k)
50
Pythonでこんな書き方をしたら袋叩きに遭いそうである。
>>> k = 0 if i is None else \
... 50 if i > 50 else \
... i
文字の位置を揃えてみたが、しっくりこない。
ネストしなければならない場面で使ってはいけないと言って良さそうだ。
■ 結論
無理やり使ってもいいことは無さそうなので、使う必然性があれば使うものなのだろう。
コードに対する美意識は、良いコード、悪いコードを嗅ぎ分ける感覚にも通ずるところはある。
一概に否定はできないが、変に独自性を出してはいけないのではないだろうか。
2月26日
■ 先週の復習
練習用企画書を書き、自然言語処理関係の論文を読み返す。復習である。
その後fastTextを試そうと思い過去の分かち書き用コードを探したが、MeCabを使ったものが見当たらず。
仕方がないので、使えそうな部分を引っ張ってきて書き直すことにする。
2月27日
■ fastTextを試してみた
fastTextはWindows Subsystem for Linux（WSL）のUbuntu上で実行した。
この程度の実験なら仮想マシンをわざわざ作る必要もないので、非常に便利に感じる。権限回りでややこしくなるケースはあるかもしれないが、Windows上のファイルにも簡単にアクセスできる。
さて本題のfastTextだが、小説生成の実験でもお世話になっている「リゼロ」をMeCab+NEologdで形態素解析したものを対象とした。ベクトルは100次元とし、他はデフォルトのまま学習させた。
$ python3 eval.py 死
死, 1.0
戻り, 0.8595630800366383
淵, 0.6866154104721947
やり直す, 0.677229095129615
斬殺, 0.6703081974462186
やり直せる, 0.6559778781581258
にまつわる, 0.6491483128559868
犬死, 0.6435226430067184
都度, 0.6232727418300338
瀕, 0.6211536873397154$ python3 eval.py 徽章
徽章, 1.0
滅ぶ, 0.7536414383206341
盗ま, 0.7331187296945424
盗ん, 0.6809288072357506
盗難, 0.6793105120793896
盗む, 0.6309422405579205
ちゃんとこの作品に準じた隣接語が出ているので、問題無さそうだ。
fastTextはカタカナ語に弱いとのことだが、実際に確認してみる。
$ python3 eval.py フェルト
フェルト, 1.0
ーフェルト, 0.8698293414246024
ラインハルト, 0.6723662179158383
ーラインハルト, 0.6635320875622458
コボルト, 0.6254556333691073
偽, 0.6063687037096018$ python3 eval.py エミリア
エミリア, 1.0000000000000002
エミリアー, 0.8752356992230073
エミリア派, 0.7620399139554747
ーエミリア, 0.7358914017793182
彼女, 0.6813483780143982
ーリア, 0.665470351208798
フォルトナ, 0.6517902795345258
寄り添い, 0.6501491599702426
たんだい, 0.6340961566431474
過保護, 0.6144478948510178
おどおど, 0.6061596835770475
なるほどといった感じだ。弱点はあれど、Word2Vecより妥当な類似語が出る印象である。
2月28日
■ 文書分類などに使われる技術の復習
単語共起行列、tf-idfなどの基本的な技術から、Word2Vecなどの最近の技術まで復習していく。
fastTextの性能が良さそうだったので、組み合わせて使えそうな技術についても探していきたいと思う。
3月1日
■ fastText用にコードを書いていく
fastTextを使った実験がしやすいように、ファイル読み込み、分かち書き、単一のテキストファイル化などをするための簡易なライブラリを作っていく。
実験用だが、ある程度使いまわしできるように構造を考えつつ作っていきたい。
