2019-06-06

英文を一文ずつに分割してGoogle翻訳へ投げるAlfred Workflowを作った

Mac Go

これまでに作ったAlfred Workflow

poyo.hatenablog.jp

これまでに作ったAlfred Workflow
これは何？
論文PDFの問題
環境
Google Translate Formatter
まとめ

これは何？

一文ごとに分解して翻訳にかけることで見通しが良くなり，論文を読む速度が上がるWorkflow．

f:id:pudding_info:20190606222320g:plain

サンプルとして使用したのは，機械翻訳ネットワークTransformerを提案した論文*1

論文PDFの問題

全てがそうではありませんが，論文PDFはたまにそのままコピーすると「見かけ上の改行位置がそのまま反映された文章」としてコピーされてしまうことがあります*2．例えば上の例で用いた論文も，Abstractをそのままコピペすると見た目上の改行位置のままコピペされてしまいました．

f:id:pudding_info:20190606223240p:plain — そのままコピペした場合

この場合，文章の途中で改行されてしまうことが多いため，翻訳もめちゃくちゃになってしまいます．

環境

macOS 10.14.5
Alfred 4.0.1
Go 1.12.5

今回もGoを使っているので，使用に当たって特に準備するものはありません．今回に限っては特にGoである必要もありませんでしたが，楽だったので採用しています．
Alfredの最新版4.0系にも対応しています．3系でも動作を確認しています．

Google Translate Formatter

github.com

準備

最新版は以下からダウンロードできます．

Releases · pddg/alfred-google-translate-formatter-workflow · GitHub

AlfredとPowerpack*3が有効になっていれば，ダウンロードしたファイルを開くだけでインストールするウィンドウが出てくるはずです．
使用するためにはインストール後，ショートカットキーを設定する必要があります．

f:id:pudding_info:20190606224842p:plain

使い方

翻訳にかけたい文章を選択する
ショートカットを押す
ブラウザが開く

アプリケーションを問わず動作するため，ショートカットキーのコンフリクトにはお気を付けください．
これは逆に言うとブラウザ，PDFビューワ，エディタ等何にでも使えます．man コマンドのhelpでも使えます．

f:id:pudding_info:20190606225356g:plain

注意点

一文ごとに分解する機能は単なる正規表現マッチとIFの羅列

ソースコードを見れば分かりますが，単なる正規表現で一文を区切っています．さすがにピリオドの位置で分割は頭が悪すぎるので，ピリオドの次に来る文字が英語の大文字であれば改行，というようなことをしています．

Hoge fuga piyo
poyo. Poe poe.

↓

Hoge fuga piyo poyo.

Poe poe.

そのため，1.234のような浮動小数点数のピリオドは改行としては認識されません．逆に言うと，文頭が数字であれば改行としては認識されません．

Hoge fuga 1.234 piyo
poyo. 1 poe poe.

↓

Hoge fuga 1.234 piyo poyo. 1 poe poe.

ピリオドが無い場合は文字列分解できない．

例えば論文中でも，箇条書き等で文末にピリオドが無い場合，文章の終わりを認識できないため，改行されません．

Hoge fuga piyo poyo
Poe poe

↓

Hoge fuga piyo poyo Poe poe

意図的に混入されているハイフンを消してしまう

論文ではよく，改行位置に長い英単語が来た場合，その単語の途中にハイフンを挟んで改行することがあります．この場合に正しく英単語を解釈できるようにするため，改行直前のハイフンを除去して後続の単語と結合するという処理を挟んでいます．これは便利な機能ではありますが，意図的にハイフンを加えられている場合でも削除されてしまうことに注意が必要です．

Hoge fuga piyo-
poyo. Poe poe.

↓

Hoge fuga piyopoyo.

Poe poe.

たまにうまく動かない

ショートカットを押しても，うまくコピーした内容が伝播されず，エラーが出る場合があります．その場合，以下の様な通知が出ますので，選択し直す等でリトライしてみてください．

f:id:pudding_info:20190606230548p:plain

まとめ

もうかれこれ2年近く使っていて知り合いも便利に使ってくれているので，ちょっと整理してgo moduleに対応して供養しておくことにしました．
もう少し良い文章の分割アルゴリズム等があれば，教えて頂けると嬉しいです．いつでもcontributionお待ちしています．

2019/8/16 追記

知らない間にすごく伸びていて驚きました．使って頂いて色んなフィードバックを貰えると嬉しいです．はてブのコメントも読んでいるのでいくつかお答えしておきます．

Google Traslate API使った方が良いのでは？
Google Translate APIの使用のためにはGoogle Cloudへの登録が必要になってきます．料金は良心的ですが，設定が煩雑になる上，（ご指摘の通り）結局どこに表示するかという問題を解決できません．Google翻訳のUIにより表示後にも微調整が可能なため，柔軟性が良くなっていると感じています．
ヘッダやフッタのページ数などの文字列もコピーされてしまうのを除外してくれるといい
これは箇条書きと同じようにただのピリオドの無い文字列として認識されるため，現状対応が非常に難しいです．論文PDFから本文だけ抽出できるようなツールがあれば組み合わせて使えるかも知れませんが…
OmegaTっていうのがあるよ
これは純粋に知りませんでした．が，求めているものとは少し違うなと感じています．これでやりたいのはざっくりした意味の把握なので，精読したり完全な和訳を生成することが目的ではありません．

いくらでもPull Request，Issue歓迎しておりますので機能への不満やバグ等あれば遠慮無くリポジトリの方へよろしくお願いします．

*1:Vaswani, A., Brain, G., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., … Polosukhin, I. (n.d.). Attention Is All You Need. Retrieved from https://arxiv.org/pdf/1706.03762v5.pdf

*2:これはビューワ等に依存するのかもしれません．よくわかりませんが，手元では発生する場合，発生しない場合があるようでした

*3:Alfred Workflowを使用可能にするための課金パッケージ

2019-04-27

弱小大学の研究室における計算機環境の理想と現実

Docker Linux サーバポエム

はじめに
理想
現実
- 今までの環境
- 新しい環境への移行にあたって
新しい環境
理想に近づくために
まとめ

はじめに

これはあくあたん工房GWアドベントカレンダー1日目の記事です．

しがないM2が悲惨なラボ計算機環境をどうにかしたいとあがいている様子です．過度な期待はしないでください．
なおこれは，かなり恵まれた環境で，かなり恵まれた学生が，さらに高望みしているだけの記事です．未だにPCの起動ディスクがHDDだとか，メモリが4GBしかないとか，そういう世界の話はしません．タスクとしては主に軽い深層学習がメインで，MPIを使ってマルチノードで大規模演算！みたいなことはしていません．

理想

プログラムを書いたら，

f:id:pudding_info:20190425174850p:plain

ワンクリックで，

f:id:pudding_info:20190425175603p:plain

いいかんじに強いマシンと沢山のGPUで超高速に計算をして，

f:id:pudding_info:20190425175629p:plain

クラウドにデータをバックアップして，

f:id:pudding_info:20190425180030p:plain

AIに論文を書いて欲しい！！！！！！！！！頼む！！！！！！！！

f:id:pudding_info:20190425180200p:plain

はい．最後の一つはともかく，研究者にとって

計算機上で行う計算自体はあまり意味がない（場合による）
できればその部分で時間を取られたくない
抽象化された計算機が自分のプログラムを勝手にいいかんじにしてほしい

というのは共通の悩み・願望だと思っています．書いたプログラムをシュッとシームレスに動かす，それだけで良いのですが，現実はなかなかに非常だったりします．そもそも物理マシンがある時点で管理しないといけないですしね．

現実

多くの研究室では，予算の都合上一人一台高スペックなワークステーションを割り当てるのは難しいのではないでしょうか？せいぜい研究室に数台，それなりのスペックのものを用意して共通で使用することが多いのでは．弊研究室もその分に漏れず，それなりのワークステーションをサーバとしてみんながsshで接続し，計算を回しています*1．
ユーザこそ後述するLDAPにとって統一された管理を実現していましたが，各マシンの内部の管理は各代の有識者が思い思いに環境を作っており，完全にカオス．CUDAのバージョンもNVIDIA DriverのバージョンもPythonのバージョンも違う，誰もノウハウを残していないので思い思いに計算を回している，逆に謎の遺産によってなぜか動いている，誰がどのマシンを使っているか分からない…etc トラブルが起こったときに場当たり的に解決している状況が続いていては，再発して当たり前です．いちいちその復旧に追われ，研究がままならなくなっては本末転倒…

他にもハードの問題としてそもそもマシンが古くてよく壊れる，起動しなくなる，動いても遅い，などなど…問題は山積みです．

f:id:pudding_info:20190426002727p:plain

これはお金のない研究室の都合なのですが，

一度に買える計算機の台数が少ない
しかし数が足りないために毎年購入

→ スペック，CPU・GPU アーキテクチャが全く異なるPCが何台も存在

年によって使える予算に差
潤沢な年だけマシンのスペックが上がる

→ 特定のマシンに計算が集中

など，管理の問題だけでなく予算の都合による構造的な問題も存在します*2．

加えて研究室のWebサイトやメールなど研究に直接は関与しないサービスを動かすマシンも存在します．この管理も教員や学生がやっており，~~時間が無駄に~~……

これらを踏まえ，まずはこれまでの研究室の計算機環境を見ていきます．

今までの環境

f:id:pudding_info:20190422012417p:plain — 以前のサーバ構成

M1からこの研究室に来たのですが，既に環境としてはそれなりに整っているという印象でした．もちろん多数の不安定要素がありましたが，日常のオペレーションについては問題なく，みんなそれなりにやっているという感じでした．しかし，

どう考えても古すぎるラボの中心となるMac mini
- メールシステムの認証が要件を満たしていないのかGmailから認証できない
- 再起動の度に設定が吹き飛んで初期化されるApache
- もはや誰もわからないOpenDirectory
- ずっとPHPのバージョン警告が出ているWordPress
使いもしないのにWindowsが入っている計算サーバたち
- システムSSDの空き容量が20GB程度しかない
ディスプレイにつなぎもしないのにDesktop OSが入っている計算サーバたち
- 昔は繋いでいたらしいが，サーバとして使っているのにChromeとかLibre Officeとか入ってて邪魔
完全に粗大ゴミと化している古い計算マシンたち
初期構築以降の環境構築方法を誰も残していないので思い思いにインストールされているCUDAとNVIDIA Driver
怪しすぎるセキュリティ

などなど，課題は山積みでした．前から早くこのMac miniから乗り換えたいよねという話はしていたのですが，やはりなかなか難しく，腰が重かったことは言うまでもないでしょう．しかし僕ももうM2になってしまう，出来る人間が出来るうちにやらないと手遅れになる，という危機感から，春先より気合いを入れて移行を始めました．

新しい環境への移行にあたって

完璧を目指すことは最初から諦めていました．そんなにスキルレベル高くないです．しかし，自分は卒業してしまう身なのでどうにかノウハウだけは残す必要があります．オレオレシェルスクリプトを残すよりはという気持ちで，今回はAnsibleを利用しました．また，

完全自動化は諦める
ぶっ壊れない環境を作るのでは無く，ぶっ壊れた環境を躊躇無く消し飛ばしてできるだけ早く復旧できるようにする
全て自力で解決しようとしない

のようなポリシーでPlaybookを組み，無理なところはおとなしく手動オペレーションでいいやという気持ちになることで，自分の中のハードルを下げています．

結果から言うと

OSのインストール・IPアドレスの固定までは手動（逆に言うとそれ以降は全て自動化）
計算用マシンについては途中トラブってもOSのインストール含め概ね30分〜1時間以内に復旧できる
金でなんとかなるものはなんとかした（NASを買った）

という感じです．かなり頑張った．

新しい環境

f:id:pudding_info:20190425173601p:plain — 新しいサーバ構成

まず，ストレージ周りを全てNASに押し付けて解決を図りました．自分で頑張ってRAID組んで壊れたら復旧させて…とか面倒臭いので，ここはお金で解決*3．

これまでのMac Miniの代わりに，計算以外のタスクを担うサーバとして富士通のPRIMERGY TX1320M3を購入してもらいました．4コアXeon，16GBメモリ，1TB HDD×2（RAID1）でまぁ困らないくらいのスペックかなと*4．これに

OpenLDAP
- ユーザ情報の統一管理．LinuxのPAMから参照してログイン・メール等からも利用
- ユーザの作成等もAnsibleでPlayBook化．かなり無理矢理
- https://galaxy.ansible.com/pddg/ldap_server
Postfix/Dovecot
- IMAPS/POP3S/SMTPSを吐くメールサーバ
- https://galaxy.ansible.com/pddg/dovecot
- https://galaxy.ansible.com/pddg/postfix
apt-cacher-ng
- apt install高速化のためのキャッシュサーバ．
- クライアント側もセットアップ．HTTPSの通信は無視．
- https://galaxy.ansible.com/pddg/apt_cacher_ng
Nginx + Certbot + MySQL + PHP（WordPress）
- ac.jpもLet's Encryptなんだっていう驚きが少しあった
- 元はApacheでしたが好きじゃないのでNginxに
- https://galaxy.ansible.com/nginxinc/nginx
- certbotは自作Role．MySQLも自作RoleでDockerコンテナとしてデプロイ．要望があればオープンにします．
AutoFS
- NFSのマウントに使用．自作Role．
SSHD
- 簡単な設定だけ
- https://galaxy.ansible.com/pddg/sshd_config
Docker
- https://galaxy.ansible.com/geerlingguy/docker
Docker registry + Portus
- DockerHubのミラー用プロキシとして使用してサーバごとのpullを高速化したい
- 間に合わなかったのでGW中にやりたい
Avahi-daemon
- systemd-resolved + systemd-networkdでmDNSがうまく有効にならない…

など，その他いろいろ細かい設定をするRoleを書いて実行しています．当然OpenLDAPもPostfixもDovecotも触ったことないので一から調べました．未だにOpenLDAPはよくわからない．続いて計算機も

Docker
- 上に同じく
NVIDIA Driver + nvidia-docker2
- 自作Role．
- Ansibleのrebootモジュールを使ってドライバのインストールは全て自動
Neovim
- 趣味と実益を兼ねています
- https://galaxy.ansible.com/pddg/neovim
AutoFS
GPUデバッグコンテナ
- Dockerでの実行に慣れていない人，Dockerfileを書く前にGPUで動くかの簡易チェックをしたい人等に公開している，SSHログインできるコンテナ．
- LDAPの設定をホストからマウントしてLDAPユーザでログイン出来るように
- GitHub - pddg/sel-gpu-debug-container: Interactive CUDA container image for debugging
Sigularity
- DockerではPermissionの問題がある（プロセスがrootとして動作する）
- まだちゃんと試せてないので未導入

という感じで整備．まだSingularityの導入で変わるかも知れませんが，基本的にはユーザの善意を信じて大きくパーミッションを与え，Dockerでの実行をサポートしています*5．nvidia-docker2は容易にCUDAのバージョンを切り替えることが出来るので，他人とバージョンが違っても安心なのがとても良いですね．Dockerの学習コストは少し高いですが，クライアントマシンとサーバマシンで環境を統一してデバッグできるので，メリットは十分大きいと考えています．
ワンクリックでサーバ上で実行！とはいきませんが，

ローカルで開発
ローカルでDockerfileを書いて実行を試す
サーバ上でイメージをビルド
コンテナを作ってデータセットをマウントし実行

で，少なくとも環境構築の手間はかなり省かれたかなと．

監視

業務用のサーバでもないのに，監視なんて必要なのか？という話なのですが，あった方がいいと個人的には思っています．ディスクの空き容量，CPU・GPU・メモリの使用状況等，いちいち自分で確認しに行くよりもWebUIから確認，自動でアラートするなどやっておいて損することは無いと思います．余っていた古いXeonマシンがあったのでこいつでいいやと突っ込むことに．監視ソリューションのOSSとしては

他に一部無料枠として

Mackerel

等がありますが，

僕自身に運用経験があった*6
AlertManagerの通知先としてSlackがサポートされていた*7
GrafanaのUIが使いやすい

等の理由から，Prometheus + Grafana + Alert ManagerをDockerを用いてデプロイしています（全てAnsibleでプロビジョニング）．各サーバに

Node Exporter：ホストの様々なメトリックを取得
cAdvisor：Dockerコンテナに関するメトリクスの取得
DCGM Exporter：GPUがある場合に導入．GPUに関するメトリクスが取れる

等を入れ，監視サーバから叩いています．各ホストに関するメトリクスを簡単にまとめてダッシュボードを作成．以下の様な感じで提供しています．どのサーバがどういったスペックなのかもここで確認できる様になっています．

f:id:pudding_info:20190426223650p:plain — Grafanaのダッシュボード（自作）

アラートも設定しており，例えば10分以上ダウンしていればSlackに通知が来ます．

f:id:pudding_info:20190426223852p:plain — Alert ManagerからSlackへのアラート

アラートはもっと拡充していきたいなと考えていますが，優先度が低いのでまだ後回しになっています．誰か手伝って．

情報共有・記録

これはステマですが，弊研究室はWikiシステムとしてesa.ioを導入しました．

esa.io

そもそもサークルでアカデミックプラン*8を知って使い始めたのですが，使いやすい，デザインが見やすい等かなり良いです．これまではMDWiki.jsを使用していたのですが，

Gitでcommit・pushしないといけない
PushしたときにWeb上に自動で反映させる独自hookが大抵上手く動かない
上記2点も相まって誰も使ってくれない
これ本体に認証システムがないのでApacheで特定のパス以下にLDAPを用いたベーシック認証を加えていたが，Nginxだと自前ビルドが必要で面倒臭い．

などの問題があったため，思い切って先生に提案しました．目に見えて利用率は上がりました．みんなもっと気軽に自分の知見書いて欲しいですね．

他にやりたいこと

使用中であることの明示

現在どのマシンをどのくらい使うか，他の作業との共存の可否，使い終わったか等をSlackで自己申告する様にしています．あんまりいけてないので，Alert Managerでｲｲｶﾝｼﾞにならないか考えているのですが，

Dockerを使うと基本的にプロセスはrootで動く
- 使用ユーザの特定が難しい
Dockerコンテナ名は指定しない限りランダムになる
- コンテナ名で通知しても分からない
「使用している」の基準の設け方が難しい

等があり，自動化出来ていません．誰か上手いやり方を知っている人は教えて頂きたい．

自動ジョブ実行システム

現状，何か計算を実行するのはユーザの手動に頼っています．そのため，

Aさん「今日一日使います」
Bさん「あ，じゃあそのあと使わせてください（あ，じゃあ明日やるかぁ…）」

みたいな場合があり得ます．空くのは分かっていても，わざわざ終わるかどうかを監視して終わったらすぐ実行するなんて面倒なこと，締め切り間際でもしない限りやりませんよね？これを

Aさん「今ジョブ投入しました．今日中に終わると思います」
Bさん「その次投入してありまーす（明日の朝には終わってるかな？）」

みたいにできると，日中にひたすら結果待ちをする時間を省けて幸せになれるんじゃ無いかと思っています．ただ，こういうのやったことないのでどうやれば良いのか全く分かっていません．どうやるんだ…？

今後の課題

Ansibleをちゃんと使える後継者を育成することが一番大変そうです．とは言ってもそんなに難しいことはしていないので，ドキュメントをある程度残していくだけで十分（向こう数年くらいは）運用できると思っています．

理想に近づくために

共用計算マシンの整備

f:id:pudding_info:20190426232756p:plain

まずお金が足りません．重い計算を行うのに，スペックは圧倒的に足りていません．もっとスペックで殴れれば色んなことを試せるんですが，GPUメモリが全然足りていません．これについてはそもそも研究室単位で頑張ることが間違いだと思っていて，学部・大学単位で設備を揃える必要があると思っています．生物系だとたとえば質量分析器や電子顕微鏡等，高価な機材はその学部単位で所有し，各研究室が共同で使用していました．情報工学でもそろそろまともな共有マシン群が欲しい……せめてTesla K80とかが数枚載ったマシンが数台あると大分変わると思うんですが……（ﾁﾗｯﾁﾗｯ

大学側での提供サービスの拡充

研究室Web・メール等は大学側で吸収してくれないかな……と思っています．どちらも別に研究室単位で管理する必要ないですよね？よくガバガバセキュリティでスパムの踏み台にされてる話を聞きますよ？
SMTPはリレーサーバが（おそらくスパム対策で）提供されているのですが，そもそも自分でPostfixの運用をしたくない……
更にLDAPも，大学側がActive Directoryとかで提供してくれると楽になるのにとつらい気持ちになっています．うちではWindowsマシンが一台もない，Mac等は個人が使うのでID統一の必要が無いという条件があるのでOpenLDAPで事足りていますが，Windowsを使う研究室では無理でしょう．あくまで自分の研究室が恵まれているために可能な構成だと思います．

クラウド利用は？

f:id:pudding_info:20190426232605p:plain

Google Colaboratoryは神．ただし軽いタスクに限る．
大学の予算の使い方の仕様上，従量課金制というのがとてつもなく相性が悪いです．産総研のABCIみたいな一定ポイント買い切り制ならまだ良いかも知れませんが，そもそもラボ内のマシンで四苦八苦している人がクラウドのインスタンスでどうのこうのなんて，理解出来ると思いますか？
無料でトライアンドエラーできるのがオンプレの良いところなのですが，これにお金がかかるとなって，結局「みんな怖がって使わない→クラウドインスタンスがエリクサー化」するのも嫌です．やっぱり学内共用計算マシンと，その使用方法講座みたいなのを実施するのがベストなんじゃないかなぁと．

まとめ

大学の計算機環境は様々な事情でレガシーの塊のところも多く，管理者がどんどん変わっていくのでカオス
弊研究室では古い環境を一新してAnsibleで全て整備した
今後求められるスペックに一研究室で対応するのは大変，大学・学部での共用計算資源で大規模な計算もできるようにしてほしい

お金が欲しいですね．
他の研究室でのプラクティスとか全然聞かないんですけど，みんな一体どうしてるんでしょう？実はみんなOpenLDAPもADも完全に理解してて，分かってないのは僕だけとか？もうみんなKubernetesで機械学習基盤組んでて，ラボメンみんなマニフェスト書けるとか？こういうの入れると良いよとか，こういうフローオススメだよとか，無限に募集しています．よろしくお願いします．

では，明日は弊サー期待の新入生が書いてくれるっぽいので楽しみにしています．ﾖﾛｼｸﾈｰ！

*1:なお，弊研究室は一人一台MacBookが支給され，これをクライアントとして用いています

*2:買えているだけマシという話もある

*3:なお，ここでQNAPを選択したのは完全に失敗でした．NAS上のホームディレクトリとNFSで配信する他のサーバで利用するためのホームディレクトリを一致させると，AFP等でNASにログインしたとき，ホームディレクトリのパーミッションが777に書き換えられ，公開鍵でのsshがPermissionのエラーで弾かれるようになります． https://forum.qnap.com/viewtopic.php?t=123842

*4:SSD 1TB×2はオプションが無かった

*5:sudoできるユーザは限られています．dockerグループにデフォルトで所属させ，sudo無しでの実行をサポートしているだけ

*6:poyo.hatenablog.jp

*7:弊研究室は全てSlack経由で連絡を取り合っています

*8:docs.esa.io

2019-03-25

ChainerのEarlyStoppingとOptunaによる最適化

python 深層学習

はじめに
環境
枝刈りと過学習
EarlyStopping
- タイミング
OptunaとEarlyStopping
実際にやってみた
まとめ

はじめに

前回こんな記事を書きました．

poyo.hatenablog.jp

本当は今回の記事もまとめて1つで公開する予定だったのですが長くなりすぎたので分割しました．

環境

環境は全て前回の記事と同様です．

Chainer v5.3.0
CuPy v5.3.0
Optuna v0.9.0

枝刈りと過学習

当初，Optunaのプレスリリースにあった「学習曲線から、最終的な結果がどのぐらいうまくいきそうかを大まかに予測する」という一文から，「過学習を起こしそうだったら早めに切る」という意味だと誤解していました．実際にはその試行内ではなく，過去の試行との比較を行うため，これは全く意味が異なってしまいます．これに関連したIssueは以下です．

github.com

必要な部分だけ抽出すると，

Optunaの枝刈りは過学習を検知するものではない
過学習を気にするなら，例えばChainerならchainer.training.triggers.EarlyStoppingTriggerを使うように

ということです．

EarlyStopping

これは，モデルの学習の収束を判定するための方法です．何らかの指標，例えばvalidation lossを監視し，train lossは減少し続けるのに対して，validation lossが改善されなくなった場合，学習を打ち切ります．ChainerではTriggerとして実装されています．

    # 1 epochごとにvalidationのaccuracyを監視し，3回以上改善しなければstopする
    early_trigger = training.triggers.EarlyStoppingTrigger(
        check_trigger=(1, "epoch"),
        monitor="validation/main/accuracy",
        patients=3,
        mode="max",
        max_trigger=(epoch, "epoch")
    )
    # `(epoch, "epoch")`の代わりに上記のTriggerを渡す
    trainer = training.Trainer(updater, early_trigger, out='output')

これはあくまで終了するだけなので，学習終了後にそのパラメータを読み出したりはしてくれません．そういうことがしたければ以下の記事が参考になります．

qiita.com

タイミング

適当な値を出しますが，こんな感じのlossの推移があり，

epoch	1	2	3	4	5	6	7	8
loss	100	80	60	40	20	30	25	28

EarlyStoppingTriggerのパラメータとして以下の物を渡したとします．

patients=3
mode="min"
max_trigger=(10, "epoch")

patientsは「最小値からいくつ連続して値が改善しなかった場合に学習を止めるか」というパラメータです．例の場合，最小値は5 epoch目の20です．以降，30 → 25 → 28と値が上下していますが，一貫して最小値20を上回っているため，8 epochで中断されます．
modeには，最小，最大どちらの方向で値を監視するかを設定します．lossならば最小の方向になり，accuracyなら最大の方向に監視することになると思います．デフォルトは"auto"ですが，明示した方がトラブルはないんじゃないかなと思います．
max_triggerは値が改善され続けたときにいくつまで学習するかを設定します．

OptunaとEarlyStopping

Optunaは，あくまでも目的関数が返す最後の値を最適なパラメータの選出に使用します．枝刈りを行っても行わなくても，学習過程で記録した最小値が利用されるわけではないため注意が必要です．これを簡単なサンプルで示してみます．

import optuna

def objective(trial):
    sample_losses = [
        [200, 90, 52, 31, 15, 7, 17, 28, 45, 56],  # A
        [143, 82, 56, 40, 26, 18, 24, 23, 26, 28]  # B
    ]
    losses = sample_losses[trial.number]
    # 途中経過を報告する
    for i, loss in enumerate(losses):
        trial.report(loss, step=i)
    # 最後の値を返す
    return losses[-1]

if __name__ == "__main__":
    study = optuna.study.create_study("sqlite:///test.db")
    study.optimize(objective, 2)
    # 全ての試行のvalueをprint
    print("[Trials]")
    for t in study.trials:
        # Trialの番号，その時の値，値の推移
        print(t.number, t.value, t.intermediate_values)
    # Optunaが選んだbestなtrial
    best = study.best_trial
    print("[Best]")
    print("Number:", best.number)
    print("Value:", best.value)

実行されるTrialの順に応じて異なる数列をOptunaへ報告する目的関数を設定し，これを最適化させてみます．この sample_losses をプロットすると以下の様になります．

f:id:pudding_info:20190324234949p:plain — sample_lossesの推移

見て分かるように，実際には試行Aの方が6 epochで（epochではないですが便宜上の単位として使います）最も低い値を記録しますが，Optunaは試行Bをbest trialとして選出します．

[I 2019-03-24 23:45:29,729] A new study created with name: no-name-22ecd572-e23d-4ce4-8370-26a12267b372
[I 2019-03-24 23:45:29,830] Finished trial#0 resulted in value: 56.0. Current best value is 56.0 with parameters: {}.
[I 2019-03-24 23:45:29,918] Finished trial#1 resulted in value: 28.0. Current best value is 28.0 with parameters: {}.
[Trials]
0 56.0 {0: 200.0, 1: 90.0, 2: 52.0, 3: 31.0, 4: 15.0, 5: 7.0, 6: 17.0, 7: 28.0, 8: 45.0, 9: 56.0}
1 28.0 {0: 143.0, 1: 82.0, 2: 56.0, 3: 40.0, 4: 26.0, 5: 18.0, 6: 24.0, 7: 23.0, 8: 26.0, 9: 28.0}
[Best]
Number: 1
Value: 28.0

これは嬉しくありません．正しく最も良い値で判断して欲しいところです．そこで，最終的に返す値を変えます．途中経過の値は枝刈りに使われるのみ*1なので，無視できます．

import optuna

def objective(trial):
    sample_losses = [
        [200, 90, 52, 31, 15, 7, 17, 28, 45, 56],  # A
        [143, 82, 56, 40, 26, 18, 24, 23, 26, 28]  # B
    ]
    losses = sample_losses[trial.number]
    # 途中経過を報告する
    for i, loss in enumerate(losses):
        trial.report(loss, step=i)
    # 最小値を返す
    losses.sort()
    return losses[0]

if __name__ == "__main__":
    # 省略

実行してみます．

[I 2019-03-25 00:02:33,012] A new study created with name: no-name-36544734-db8e-4478-83d5-314d3d999c7b
[I 2019-03-25 00:02:33,122] Finished trial#0 resulted in value: 7.0. Current best value is 7.0 with parameters: {}.
[I 2019-03-25 00:02:33,223] Finished trial#1 resulted in value: 18.0. Current best value is 7.0 with parameters: {}.
[Trials]
0 7.0 {0: 200.0, 1: 90.0, 2: 52.0, 3: 31.0, 4: 15.0, 5: 7.0, 6: 17.0, 7: 28.0, 8: 45.0, 9: 56.0}
1 18.0 {0: 143.0, 1: 82.0, 2: 56.0, 3: 40.0, 4: 26.0, 5: 18.0, 6: 24.0, 7: 23.0, 8: 26.0, 9: 28.0}
[Best]
Number: 0
Value: 7.0

このように，結局は目的関数の返す値によって決定されることが分かりました．よってOptunaで最適化する際には，その試行の中の最良の値を返す必要があるように思われます*2．

枝刈りを行う際の更なる注意点として，Optunaは枝刈りした試行についてPRUNEDというステータスで記録しますが，best trialの選出には PRUNED のものは含まれません*3．これは，過去の同じステップと比べて値が悪化しているのだから当然と考えられます．しかし，前述のように，学習の過程でベストな値を取っても，その後改善せずむしろ過学習により劣化した場合に枝刈りされる可能性は依然としてあり，その場合は本来最適であったパラメータが見逃されることになります．

これはEarlyStoppingを用いても抑制はできるでしょうが完全に防ぐことは出来ないと考えています．その仕組み上，最良の値からいくつかぶん学習を進める必要があるため，その長さ（patients）の分だけ枝刈りの可能性が残されてしまうためです．あまり長い patients を設定することは避けるべきかと思います．

実際にやってみた

前回の記事で使用した実験コードに更に手を加える形で実装しました．

全体は以下にあります．

optuna-sample/main.py at 1b7cfccea08b4a2255ff685d931f746ce0de2007 · pddg/optuna-sample · GitHub

    # 省略
    early_trigger = training.triggers.EarlyStoppingTrigger(
        check_trigger=(1, "epoch"),
        monitor="validation/main/accuracy",
        patients=3,
        mode="max",
        max_trigger=(epoch, "epoch")
    )
    trainer = training.Trainer(updater, early_trigger, out='output')

    # 実行中のログを取る
    log_reporter = extensions.LogReport()
    trainer.extend(log_reporter)
    
    # 省略

    # 学習を実行
    trainer.run()

    # Accuracyが最大のものを探す
    observed_log = log_reporter.log
    observed_log.sort(key=lambda x: x['validation/main/accuracy'])
    best_epoch = observed_log[-1]

    # 何epoch目がベストだったかを記録しておく
    trial.set_user_attr('epoch', best_epoch['epoch'])

    # accuracyを評価指標として用いる
    return 1 - best_epoch['validation/main/accuracy']

上記のコードの途中でTrialオブジェクトに対してuser_attrとして最良であった場合のEpoch数を記録していますが，これは後から以下の様にして取り出すことが出来ます．

    print("[Best Params]")
    best = study.best_trial
    print("Epoch:", best.user_attrs.get('epoch'))

これを用いて，枝刈り無し，MedianPrunerによる枝刈り有り，SuccessiveHalvingPrunerによる枝刈り有りの3種類でそれぞれ100回の最適化を行いました．EarlyStopping無しの結果については前回の記事をご覧ください．また，前回から繰り返し書いていますがこれは厳密な時間測定ではなく，なんとなく感覚を掴んでいるだけですので，悪しからず．

枝刈り無し

[I 2019-03-24 15:57:00,465] A new study created with name: prune_test
[I 2019-03-24 15:57:42,481] Finished trial#0 resulted in value: 0.03238105773925781. Current best value is 0.03238105773925781 with parameters: {'n_unit': 36, 'batch_size': 105}.
# 省略
[I 2019-03-24 20:16:07,683] Finished trial#99 resulted in value: 0.022976338863372803. Current best value is 0.018449485301971436 with parameters: {'n_unit': 95, 'batch_size': 37}.
[Trial summary]
Copmleted: 100
Pruned: 0
Failed: 0
[Best Params]
Epoch: 9
Accuracy: 0.9815505146980286
Batch size: 37
N unit: 95

4時間強程度の時間がかかりました．思ったより全然時間を短縮できませんでしたね．今回は最大で20 epoch学習をおこなっているのですが，これが思ったより多すぎなかったということなのでしょうか．とはいえ，Best Paramsを見て頂ければ分かるように，9 epoch目でベストの値をたたき出していることが分かります．

MedianPrunerによる枝刈り

[I 2019-03-24 15:56:47,192] A new study created with name: prune_test
[I 2019-03-24 15:57:31,076] Finished trial#0 resulted in value: 0.02388054132461548. Current best value is 0.02388054132461548 with parameters: {'batch_size': 67, 'n_unit': 116}.
# 省略
[I 2019-03-24 16:29:43,264] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 14
Pruned: 86
Failed: 0
[Best Params]
Epoch: 8
Accuracy: 0.9790022373199463
Batch size: 69
N unit: 125

約30分程度で済んでいます．EarlyStopping無しで行った時よりも多少時間が短縮できているようですが，たまたまかも知れません．こちらもBest Paramsは8 Epoch目と比較的早い段階で収束していることがわかります．

SuccessiveHalvingPrunerによる枝刈り

[I 2019-03-24 15:56:58,310] A new study created with name: prune_test
[I 2019-03-24 15:58:00,723] Finished trial#0 resulted in value: 0.023097515106201172. Current best value is 0.023097515106201172 with parameters: {'batch_size': 61, 'n_unit': 70}.
# 省略
[I 2019-03-24 16:26:50,098] Setting status of trial#99 as TrialState.PRUNED. Trial was pruned at epoch 1.
[Trial summary]
Copmleted: 8
Pruned: 92
Failed: 0
[Best Params]
Epoch: 9
Accuracy: 0.9769024848937988
Batch size: 61
N unit: 70

30分弱程度で完了しました．やはり枝刈りは強力ですね．こちらも9 Epoch目で学習が収束していることから，今回のサンプルネットワークを用いたMNISTの学習では8，9 epochあたりで十分収束するということでしょうか（もちろん触るパラメータ次第だとは思いますが）．

まとめ

ChainerのEarlyStoppingTriggerは簡単に使えて強力ですので，無意味に長い学習を行って計算リソースや時間を無駄に消費したくない方は是非導入してみてはいかがでしょうか．

また枝刈り有り・無しの場合で，かかる時間と得られる最適化の妥当さのバランスがどうなっていくのか，上記の結果を見る限り同じ100回の最適化でもそれぞれ異なるパラメータに行き着いており，最終的にどこに収束していくのか，気になります．

あとこれはどなたかご存じの方がいらっしゃれば教えて頂きたいのですが，こういった最適化のようなタスク，および実際の学習において numpy.random.seed(0)のようにseed値を固定すべきなのでしょうか．再現性を中途半端に考慮するより最初からランダムにし，複数回行って平均等を見るべきなのでしょうか．

深層学習は難しいですね．

*1:と解釈しているのですが，パラメータのサンプリングに使われたりするのでしょうか

*2:むしろOptunaはなぜ途中で値を報告させる機能を有しているにも関わらず，それらを考慮しないのでしょう．

*3:少なくともv0.9.0ではそうなっています． optuna/base.py at v0.9.0 · pfnet/optuna · GitHub