GraphNVP

Kosuke Nakago

2019-07-16 12:00:06

本記事は、2018年インターンシップ・PEとして勤務した Kaushalya Madhawa さんによる寄稿です。
本記事はこちらの英語ブログの日本語訳です。

本記事では、私たちが最近投稿した論文 “GraphNVP: An Invertible Flow Model for Generating Molecular Graphs” を紹介します。
コードも公開しています → Github repo

分子の生成モデル

望ましい薬理学的な物性値をもつ新しい分子の発見は創薬の分野において重要な問題です。これまで、候補となる化合物を実際に合成して実験を行うといったことがされてきました。
しかし、化合物のとりえる形の可能性は膨大でそれらを合成し、実験するということはとても時間がかかります。
このように望む物性値をもつ分子を探す代わりに、”de novo drug design” では、新しい化合物を興味対象とする物性値とともに設計するということを行います。

近年の深層学習の技術発展、特に深層生成モデルの分野は “de novo drug design” にとって重要な技術となってきています。

分子の表現方法

深層学習で分子の生成モデルを考える際、初めの重要なステップはどのように化合物を表現するかということです。
初期の研究では SMILES という、文字列ベースの表現方法を採用していました。
これらの研究は、 RNN ベースの言語モデルや、Variational AutoEncoder (VAE) を用いることで、SMILES の文字列を生成しそれを分子に変換します。
このアプローチの問題点はSMILES 文字列での小さな変化が分子全体でみると大きく変化するような場合があるということです。
そこで、分子をグラフを用いて表現しようというアプローチが出てきました。この問題は “molecular graph generation” として扱われます。

分子は無向グラフとして表現されます。原子をノード、結合 (bond) を辺に対応させます。この表記を用いると分子の構造・結合情報は Adjacency tensor (隣接テンソル) \( A \) として、また各ノードの原子(酸素、フッ素など)を node feature matrix \( X \) で表すことができます。この定式化の下で、分子の生成問題はグラフの生成問題として扱うことができ、これまでに技術発展してきた GANやVAEといった深層学習のモデルを用いることができます。さらにグラフの生成問題は2つのタイプに分類することができます。1つめは分子のグラフを”順番に” 生成する方法で ノード (原子) や 辺 (結合) を1つずつ生成していきます。もう1つの方法が直接グラフを生成するタイプで、画像の生成と似たように一度に全体を生成します。

可逆性

上記で紹介したVAEやGANと比較して、可逆な Flow を用いたモデルは尤度の最大化を直接行えるという長所があります。

さらに、Flow モデルは可逆な変換のみで構成されているので、逆変換が可能で100% 分子→潜在変数→分子 の再構成を行うことができます。

GANのみの生成モデルなどEncoder がない場合は、特定の分子を操作して生成・最適化を行うことは困難です。例えば、特定のベースとなる分子 (query) に似ている分子を生成して最適化を行っていくということが (創薬の分野で Lead optimization と呼ばれる) 困難です。一方Flow モデルは 分子の潜在変数を直接計算できるので、query 分子に対する潜在変数を簡単に求めることができそこから最適化を行うことも可能です。

提案モデル

model_reverse

提案モデルであるGraphNVPは上図のような構成をとります。GraphNVPは私たちの知る限りではOne-shot Graph生成モデルとして初めてFlow を用いたモデルです。
このモデルは辺に対応する変数とノードに対応する変数の2つの潜在変数を使用し、グラフ構造や原子種類の分布を表現できるようにします。
これらのをFlowの定式下で計算できるよう、 Adjacency Coupling および Node Feature Coupling と呼ばれる2つのCoupling layerを提案しました。
グラフの生成を行う際は、まずAdjacency tensorを生成し、次に Node feature tensor を graph convolutional network を用いて生成します。

結果

訓練データから分子をとり、その潜在変数 \( z_0 \) をGraphNVPで計算します。そして潜在空間上でランダムに選んだ2つの方向の軸に対して \( z_0\) が中心となるような2次元グリッドを構成し、その各点で潜在変数をデコードして分子を生成したものが下図となります。
下図の可視化結果では、似たような分子が並んでおり、隣どおしでは少しの原子が変わっているだけというようなものとなっており、提案モデルがスムーズな潜在空間の学習をできていることが見て取れます。

zinc_neighborhood_2d

 

 

さいごに:メンターより

Kaushalyaさんのメンターを担当した、中郷・石黒です。
今回の研究は2018年夏のインターンシップから始めたものです。このころはGraphの生成モデルの研究が盛んになり様々なアプローチでの生成モデルが提案され始めたころでしたが、まだFlowを用いたグラフの生成モデルはないので取り組んでみたいというKaushalyaさんの持ち込みからはじまったものでした。

グラフ生成モデルとしては初めての取り組みであり、またFlowを用いるモデルはかなり深いネットワークを使用する必要があり計算量も大きくなるということで、研究には時間がかかりましたが、最終的には論文として形にすることができ、コードも公開することができました。

最後に宣伝となりますが、PFNでは今回の “Drug Discovery / Material Discovery” の分野だけでなく、多種多様な業界で機械学習適用の横断プロジェクトを実施しており、中途・新卒の人材募集も通年で行っております!
興味のある方はぜひこちらのページをご覧ください。

MN-2が動き出しました

土井 裕介

2019-06-26 18:11:02

先日リリースさせて頂いたとおり,MN-2の構築を行っています.MN-2は最新世代の,1024基のNVIDIA(R) V100 GPUが計算力の主力となります.現在利用しているMN-1およびMN-1bにおいて1024基のP100と512基のV100を稼動させていますが,MN-2の追加によりGPU数換算で合計2560基となり,保有計算力を大幅に強化しました.とはいえ,現時点ではKubernetesをはじめとしたソフトウェアサービススタックのセットアップ中であり,GPUは主にベンチマークを実施して状態確認を行っている段階です.

PFNでリサーチャをやっている,土井裕介です.最近はリサーチ業務はあまりやっておらず,社内インフラ関係の全体の世話役のような業務が主担当になっています.今回,物理構築が一段落したのでBlogにてMN-2の概要やポイントを紹介させて頂きます.

構築途中のMN-2

構築中のMN-2

なぜMN-2を作るのか?

よく,「なぜPFNは自前インフラを持つのか?」というご質問を頂きます.自前インフラを持つ理由にはいろいろな側面があって一言では説明できないのですが,土井としては一つ,ハードウェアの全コントロールを握りたいから,という理由があります.例えば,計算のパフォーマンスが出ないという時に,どこをどう改善すればいいか,改善するとしてどのようなアプローチが存在するかを考えます.このとき,実際のハードウェアが上から下まできちんと見えるか,それともクラウドのむこうにあるのかで,取ることができるアプローチの幅にかなりの差が生まれます.特に今回はネットワークも含めて全て自前となっているため,見ることができる計測点が増えており,深層学習に向けたインフラサイドの研究開発の基盤としても活用できると期待しています.

さらに,今後 MN-Coreを使った計算機クラスタ(MN-3)も予定しています.MN-Coreは少なくとも当面はクラウドには置けないので,これを活用するためには自前のインフラを持つ必要があります.電源・冷却・ネットワーク・ストレージを含めて共用する前提で,GPUクラスタ (MN-2) を事前に作ることで,MN-3の構築に必要な経験をPFN社内で貯めている,という側面もあります.

MN-2の設計のポイント

MN-2の設計にあたり,いろいろなことを考えました.考えたことの大半は実現性との兼ね合いや時間との戦いの中で没になりましたが,一部実現したポイントもあるので,かいつまんでご紹介させてください.

ラック設計・電源・冷却

今回採用したGPUサーバは,8GPUを1台に搭載しており,定格で1台あたり3.5kWの消費電力です.床の耐荷重や電源供給・排熱等の問題,またMN-3の先行モデルとしての役割もあり,1ラックあたりの搭載数は4ノードとしています.1ラックあたり4ノード32GPUで定格14kWという計算になります.今となってはこの熱密度は高い方ではありませんが,純粋な空冷設備としてはそれなりに高い部類に入ると思っています.MN-2ではこのGPU計算ラックを連続で16ラック並べたものを背面を対向として2列置いています.合計32ラック128ノードになります.

MN-2クラスタを置かせて頂いているJAMSTEC横浜研究所シミュレータ棟は,冷気が床下から吹き出して天井側から熱気を回収する構造になっています.MN-2のGPUの排熱が他のGPUや地球シミュレータに与える影響を最小限とするため,背面(熱風が出る側)を対向させ,ラックの両端にドアを設置して,熱気が横方向に流れないように閉じ込めています.上方は空けてあるので,下から来る冷気の勢いと対流効果で熱の大半は天井側に送られるデザインです.さらに,ラック背面にフィンを設置して熱風が対向のラックに回りこみにくいようにしています.

稼動中のMN-2 背面

GPUの排熱を上方に逸らす整流板をつけた状態

実際に全GPUに対して模擬的な負荷をかけて稼動させてみましたが,hot側の温度は高くなったものの,cold側の温度はほぼ影響なく,想定通りの結果となりました.

高負荷試験時の温度変化

高負荷試験時の温度変化 (下段: 吸気/COLD側 上段: 排気/HOT側)

ネットワークとインターコネクト

HPCにおいては,計算機を相互接続するインターコネクトは重要です.深層学習においても同じことが言えますが,例えばさまざまな種類の巨大なシミュレーションを連続的に分散実行するようなスーパーコンピュータのワークロードと,学習途中のパラメータを適時同期する深層学習のワークロードにおいては、求められる性質は異なります.深層学習において支配的なデータ通信は,主にデータセットのロードとパラメータ交換であり,パケットサイズがおおきくなり,バンド幅が重要になりがちな傾向があります.

PFNでは技術吟味の結果,ファイルシステムはいわゆるHPC向けのファイルシステムではなく,Hadoopなどで使われているHDFSをメインに利用して,ローカルのデータキャッシュを活用する方向で検討しています.このことから,データセットの読み込みはEthernetが中心となります。従来多く使われてきた(MN-1でも利用している)InfinibandとEthernetの両方で広帯域の確保はPCIeのレーン数の制約から難しい場合があります.また,InfinibandとEthernetの両方に投資することは機能的には二重投資となることもあり,MN-2では冒険的に,インターコネクトの役割も全面的にEthernetとして,RoCEv2(RDMA over Converged Ethernet)を採用しました.パフォーマンスは,一部のInfinibandが得意としているshort packetの領域を除き,Infinibandと遜色ないことを確認しています.

今後

MN-2としての本格稼動は7月を予定していますが,先行して現状のクラスタの概要を紹介しました.
今後MN-3の構築がはじまる見込みで,それにあわせてPFNではインフラ人材も募集中です.特に運用・改善の領域において,Kubernetes上で動作する深層学習のワークロードと,MN-Coreを含めた先端ハードウェアとを両方睨んで最適化を行う,というアツい仕事が待ってます.我こそは! という方は,是非弊社ホームページにある採用の欄からご連絡いただくか,個人的にご存知のPFN社員なり,土井 (doi@preferred.jp) までご連絡ください.

小学生向けディープラーニング体験教室で「ものまね算」のワークショップをしました。

Yuki Nishizawa
エンジニア

2019-06-26 13:33:18

Preferred Networks エンジニアの西澤です。

Preferred Networksでは2019年の6/8(土)に小学校高学年向けのディープラーニング体験教室を行いました。

この体験教室は3部に分かれており、第2部のロボットカーの授業については弊社の丸山史郎よりブログ記事として公開しました。今回は第1部の「ものまね算」の講義について書こうと思います。

 

「ものまね算」

今回、子どもたちに機械学習の概念を説明する時に使用した言葉が「ものまね算」です。機械学習ではたくさんの訓練データを用意し、入力と出力の関係性を学習していきますが、これを機械が「ものまね」していると表現することによって、子どもたちにとってよりイメージの沸きやすい講義ができたのではないかと思います。

 

 

火星語の数字を認識してみよう

ものまね算の講義の後には機械学習の例として「数字認識」を挙げ、実際に機械学習がどのように実社会に応用されるのかを考えてもらった後、「火星語の数字を認識する」というテーマでワークショップを実施しました。

これは、その場で子どもたちに考えてもらった架空の「火星語の数字」についてデータセットを作ってもらい、実際にその場で認識器を訓練し、手描き数字を認識させてみるというものです。みんなで一文字ずつ考えた10個の数字をワークシートに書き、タブレット端末で撮影することによりデータセットとして取り込んで学習します。

 

子どもたちが一体どのような文字を書いてくるのか少し心配していましたが、無事に認識され歓声を上げる子どもたちを見てほっとしました。中にはデータセットにない文字を書いてみる子や複数の字を並べて書いてみる子、点線で書いてみる子などもいて、子どもの柔軟な発想にはこちらも驚かされました。休み時間の間もずっと遊んでくれていたりと、機械学習の技術に興味を持ってくれた子がたくさんいたようでとても嬉しく思います。

 

またPreferred Networksは、2019年9月に文部科学省により実施される「未来の学びプログラミング推進月間」へプログラミング教材「自動化の進展とそれに伴う自分たちの生活の変化を考えよう」を提供予定です。ご興味のある方はぜひこちらも合わせてご覧ください。

https://mirapro.miraino-manabi.jp/lp_pfn.html

2019年 PFN夏季インターンシップのコーディング課題公開

楠本充
エンジニア

2019-06-25 15:27:28

Preferred Networks 2019 夏季インターンシップの選考で用いたコーディング課題を github 上で公開しました。

https://github.com/pfnet/intern-coding-tasks

PFN 楠本です。PFN では毎年8月9月の夏季休暇に約2ヶ月間の長期インターンシップを行っています。コーディング課題はその選考で応募者のプログラミング能力や問題解決能力を見るために出題させて頂いているものです。今年は「機械学習・数理」「バックエンド」「フロントエンド」「チップ」「性能最適化」「コンピュータービジョン(Chainer)」の6種類のコーディング課題を用意し、応募者の希望テーマに応じてこのうちのいずれかを解いていただく形にしていました。

今年のインターンシップでは去年をさらに上回る数の応募を頂きました。PFN では来年以降もインターンシップを開催する予定ですので、これらの課題を見て PFN に興味を持っていただけた方はぜひ応募を検討ください。また、フルタイムの採用も通年で行っております。こちらもご検討いただければ幸いです。

小学生向けディープラーニング体験教室でロボットカーの授業をしました。

maruyama
リサーチャー

2019-06-11 13:05:34

こんにちは。丸山史郎です。

Preferred Networksでは2019年の6/8(土)に小学校高学年向けのディープラーニング体験教室を行いました。
体験教室の内容は大きく3つに分かれており、その中の30分くらいの時間でレゴ® マインドストーム®を使ったロボットカーの体験教室を行いました。この直前に「ものまね」算という形で小学生向けのディープラーニング(機械学習)の解説があり、ここではディープラーニングをロボットに使うとどのようなことができるのかということを実際に体験してもらうことを目的としました。

また、弊社としては小学生向けの体験教室は初めてのことでしたので、ロボットの準備やロボット体験の内容へのアドバイス、当日の運営などを株式会社アフレル様にご協力いただきました。

続きを読む »

ローカル環境のコード差分をリモートで実行する際に再現性を担保できるコマンドラインツール「Git Ghost」公開

Daisuke Taniwaki

2019-05-13 08:00:37

概要

大村谷脇で開発したローカル環境のコード差分をリモートで実行する際に再現性を担保できるコマンドラインツールGit Ghostをオープンソースとして公開しました。このツールを使うことで、試行錯誤しながら実験をするフェーズにおいても、以前修正して実行したローカル環境のコードに簡単に戻ることができます。

開発の動機

機械学習のジョブを実行中に試行錯誤でさらに他のジョブを実行することはよくあります。Git Ghostを作る前では、そのための一番単純な方法として、例えば、ソースコードをgitで管理し、rsyncコマンドでローカル環境での差分をKubernetesクラスターに同期して機械学習ジョブを実行していました。その際、実行したプログラムが良い結果を出した場合に、以前に修正したコードに戻りたいことがよくありましたが、この方法では、gitでソースコードをバージョン管理していても、rsyncで同期したローカル環境での差分についてはバージョン管理がされていないため、以前のコードに戻ることは困難でした。

これに対処するための1つのアイデアとして、ローカル環境での修正を全てコミットしてリモートにプッシュすることがまず考えられます。しかし、たった数文字の変更のためにコミットしてプッシュするのは非常に面倒であり、リモートのレポジトリーがこの細かい修正で汚れてしまうのを好む人はいないでしょう。そこで我々はこのツールを開発することにしました。

使用方法

ローカル環境で行ったfooというファイルの中身をaからbに変更する修正をリモート環境にあるディレクトリーに送りたい場合を考えます。

まず、ローカル環境の差分パッチをGit Ghostで作成します。

$ git ghost push
xxxxxxx yyyyyyy
$ git ghost show yyyyyyy
diff --git a/foo b/foo
index 7898192..6178079 100644
--- a/foo
+++ b/foo
@@ -1 +1 @@
-a
+b

そして、リモート環境に移動し、以下のコマンドを実行しローカル環境の修正を同期します。

$ git ghost diff HEAD
$ git ghost pull yyyyyyy
$ git ghost diff HEAD
diff --git a/foo b/foo
index 7898192..6178079 100644
--- a/foo
+++ b/foo
@@ -1 +1 @@
-a
+b

ローカル環境の修正を簡単にリモート環境に同期することができました。

このようにGit Ghostはすごくシンプルなツールですが、他のツールと連携させることで最大の効果を発揮します。例えば、Kanikoを使ってDocker imageを作成する際にローカル環境の差分を含めることもできます。ローカル環境の差分を含めたDockerイメージを作り、そのイメージを使って再現性のあるジョブを動かすArgo利用例も公開しています。

アーキテクチャ

アイデアは非常にシンプルです。このツールはリモートのレポジトリーに対してローカル環境でのコミットの差分およびコミットされていない差分のパッチを別のリポジトリで管理します。そして、リモート環境でそのパッチを適用することで、ローカル環境を再現します。細かい点ですが、ローカルコミットの差分とコミットしていない差分を別々のパッチで管理することで、ローカルコミットをリモートのレポジトリーにプッシュした際にコミットしていない差分をそのまま使うことができるようになっています。

他のツールや認証情報を不要とするため、Gitレポジトリーをパッチのストレージとして使っています。

我々はこのツールをKubernetesクラスターで使っていますが、その他の環境でも同じように使えるはずです。オンプレミスのサーバーにラップトップでの変更をトラッキングしつつ送りたいという場合でも使えます。

 

是非試しに使っていただいて、GitHubにてフィードバックをよろしくお願いします!

KubernetesのSchedulerを評価するためのシミュレーター「k8s-cluster-simulator」公開

Daisuke Taniwaki

2019-04-11 08:00:27

概要

2018年夏のインターンおよびPEとして勤務した薮内さんとそのメンターである谷脇大村で開発したKubernetesクラスターのシミュレーターであるk8s-cluster-simulatorのアルファ版をオープンソースとして公開しました。このシミュレーターはKubernetesクラスタに投入されるPodのワークロードを時間とともにシミュレートできるため、Kubernetesのスケジューラーを本番環境に投入する前に評価することができます。

開発の動機

PFNでは巨大なオンプレのGPUクラスタを持っており、その上でKubernetesを使って様々な実行時間の機械学習ジョブを研究者が実行しています。我々クラスターサービスチームのミッションの一つとして、GPUの利用率を向上させ費用対効果をあげることが挙げられます。一方で、研究者間で使えるリソースの平等さも考慮しなければなりません。これを実現させるために、我々はKubernetesのスケジューラーを独自で開発したり、Extender (例 kube-throttler)を拡張したりしています。しかし、新しく開発したロジックを本番環境で走っている機械学習ジョブに影響させずに評価するのは難しく、また頻繁に試行錯誤を本番環境上で行うのは好ましくありません。バグのあるスケジューラーをデプロイしてしまった場合には研究者の仕事を止めてしまうことになるので、絶対に避けなければなりません。またスケジューラーのアルゴリズムを試すためだけに、大規模なクラスタを用意し、多くのワークロードを実際に可動させることも現実的ではありません。これらの理由からKubernetesのスケジューラーを評価するためのクラスタのシミュレーターの開発を開始しました。

デザイン

シミュレーターを開発するにあたって以下のことを考慮しました。

  • シミュレーター用のスケジューラーの実装を最小限の変更で本番環境で動かせるようにする。
  • 時間をシミュレートすることで評価を高速化するとともに、通信や内部処理のレイテンシーがスケジューリングのロジックの評価に影響しないようにする。
  • シミュレートするワークロードを自由に設計できる。
  • 後段の分析のために様々なメトリックスを出力できる。

 

アーキテクチャ

以下は簡単なフロー図になります。

 

アイデアはすごく簡単です。シミュレーターはループのステップ毎にクロックを1つ進めます。各ステップでサブミッターにそのクロックで投入するPodがあるかどうかを聞いて、サブミッターは投入または削除するPodがあればPodのリストを返します。シミュレーターはPodのリストをスケジューラーに渡し、スケジューラーはBindするものと削除するPodを選んでイベントとして返し、シミュレーターがリソース管理を行います。そして、この時に処理されたPodのメトリックスをMetrics Loggerに出力する流れになります。

 

以下はハイレベルなクラス図になります。

 

本シミュレーターでは拡張できる点は以下の2つになります。

 

Submitters

シミュレーターの定義するインターフェースに沿っていれば任意の数、組み合わせのサブミッターを使用することができます。複数のサブミッターをシミュレーターにプラグインできるので、例えばAさんは朝たくさんのPodをサブミットする傾向があるが、Bさんは夕方たくさんのPodをサブミットする傾向があるといったシミュレーションをする場合、それぞれのユーザの振る舞いモデルを独立に開発してシミュレーターにプラグインできます。

また、サブミッターはクロック毎のメトリックスを受け取ることができるため、クラスターの利用状況に応じて挙動を変えることも可能です。

Scheduler

スケジューラーの拡張方法は2種類あります。
Kubernetesのスケジューラー(kube-scheduler)をそのままもしくは拡張したアルゴリズムを利用したい場合、kube-schedulerが用意しているのと同様, Prioritizer, Extender, Predicateをセットできるミミックスケジューラーが用意されています。kube-schedulerはキューベースのスケジューラーですが、複数のPodを条件に応じてまとめてスケジュールするような、例えばより複雑なスケジューラーをシミュレーションしたい場合には、シミュレーターが定義するインターフェースを実装するように少しラッパーメソッドを書くと、それも評価できるようになっています。

*kube-schedulerの挙動については大村によるQiita投稿をご覧ください。

ロードマップ

現在、シミュレーターの使いやすさを向上させ、またより現実的な環境をシミュレーションできるように、ベータバージョンに向けて以下の機能を開発しています。

  • より疎結合なコンポーネント(例:スケジューラーとサブミッターにRPCインターフェースをサポート)
  • よく使われるサブミッターの提供(例: 典型的な確率分布に従うサブミッター(一様分布、二項分布、ポアソン分布等)
  • より多くのクラスターイベントへの対応(ノード故障、突発的なPod故障、ノード追加、削除)
  • デファクトなプロッターツール(matplotlib, gnuplot等)で直接読み込める出力フォーマットのサポート

興味のある方は是非試していただいて、フィードバックをいただけると幸いです。

 

Rust向け字句解析器生成器「rflex」を公開しました

kashihara
エンジニア

2019-04-09 08:00:14

Rust向け字句解析器生成器である「rflex」をOSSで公開しました。ここでは簡単に、「rflex」や開発に至った経緯について紹介します。

PFNエンジニアの柏原です。あまりリサーチブログには出てきませんが、前回は「[BoF] How to choose programming language for product/in-house software development」というブログを書きました。

「rflex」はプログラミング言語処理系のフロントエンドにおける文字列解析を行うコンポーネントである字句解析器(Lexical analyzer)と構文解析器のうち、前者の字句解析器のコードを生成するツールです。字句解析器生成器の「flex」とよく似たツールとなっています。構文解析器の生成では 「GNU Bison」が有名です。

開発のモチベーション

個人的には「rflex」開発においては社内外での言語処理系開発の盛り上がりについて期待を込めて作っている部分もあります。実務に役立つのはもちろんありがたいことですが、コンパイラ・言語処理系の開発といったプログラミングを楽しむことにも役立ててもらえると開発者として嬉しいと思っています。

PFNでは、業務中の活動として20%に相当する時間を個人の研究テーマや、新規アイディアのプロトタイプ実装などに当てることが認められています(20%ルール)。

今回、私は字句解析器生成器がRust に存在しないことを確認した、2018年7月頃から「rflex」の開発を開始しました。正確には、2018年1月頃から個人的に字句解析器生成器の開発のための学習をしていましたが、せっかくなので制度を活用することにしました。
「rflex」の開発においては既存ライブラリの再実装・移植、つまり車輪の再発明という側面が強いですが、以下の点でメリットがあると考え実装に至りました。

  • Rust向けのツールとして、字句解析器生成器を提供することができる
    • プログラミング言語処理系のフロントエンド開発(Rust)において、字句解析器の作成が楽になる
    • GitHubに公開することでユーザを増やし、バグレポート等の対応により品質の向上が期待できる
    • ブログ執筆時点で社内ユーザは確認できていないが、将来的に社内で必要なテキスト処理・言語処理系フロントエンド開発を手伝える可能性がある
  • Rustを業務時間内に学習できる
  • 字句解析器生成器の仕組みを再実装を通して学習できる
    • 正規表現パーサの実装
    • 非決定性オートマトン(NFA)及び決定性オートマトン(DFA)を構築するコードの実装
    • 決定性オートマトンの最小化アルゴリズムの実装

終わりに

PFNではこのような個人の活動を支援する制度(20%ルール)があり、何かに挑戦したい人にとって嬉しい仕組みだと思います。私自身も「rflex」のユーザとして応用的(言語処理系フロントエンド開発といった)な活動を新たに挑戦していく予定です。これからも「rflex」は継続的に開発を続けていく予定ですので、GitHubでのPull Request/Issueを通してフィードバックをお待ちしています。

最後に宣伝となりますが、今年もPFNはインターンを募集しています。

深層強化学習エージェント可視化ライブラリChainerRL Visualizer公開

ofk
エンジニア

2019-03-19 12:40:11

本記事は、2018年インターンシップを経て、PEとして勤務した石川さんによる寄稿です。

ChainerRLで学習したエージェントの挙動などを, ブラウザ上に可視化するライブラリ「ChainerRL Visualizer」を公開しました.

PFN2018年夏季インターンシップに引き続き, 現在アルバイトをしている東京大学の石川貴大です.

このライブラリは「強化学習のデバッグを容易にする」「強化学習のエージェントの仕組みの理解に貢献する」という思想の元で作られ,
学習済み, 及び学習途中の強化学習のエージェントの挙動をインタラクティブにブラウザ上から観察できるような機能が実装されています.

使い方は非常に簡単で, このライブラリで提供されている launch_visualizer という関数に,
ChainerRLで実装した agent オブジェクトと, 特定のインターフェースを満たした env オブジェクトを, オプションと共に渡すだけです.

from chainerrl_visualizer import launch_visualizer

# Prepare agent and env object here
#

# Prepare dictionary which explains meanings of each action
ACTION_MEANINGS = {
  0: 'hoge',
  1: 'fuga',
  ...
}

launch_visualizer(
    agent,                           # required
    env,                             # required
    ACTION_MEANINGS,                 # required
    port=5002,                       # optional (default: 5002)
    log_dir='log_space',             # optional (default: 'log_space')
    raw_image_input=False,           # optional (default: False)
    contains_rnn=False,              # optional (default: False)
)

実行するとローカルにサーバーが立ち上がり, ブラウザ上から以下のような操作ができます.

1. 指定したステップ分, エージェントをサーバー上で動作させる
サーバー上でエージェントが指定されたステップ分の動作をし, エージェントのモデルの出力が時系列で可視化されます.
以下の動画では, A3Cで学習されたエージェントの Probability of next action と State Value が時系列で出力されています.

2. エージェントを1ステップずつ動作させ, その時の挙動をモデルの出力と共に可視化する
以下の動画では, A3Cで学習されたエージェントを1ステップずつ(前後に)動作させ, その出力をenvの様子と共に観察しています.
右下の円グラフは, 各ステップにおける Probability of next action を表しています.

3. Saliency mapの可視化 (モデルの入力が画像のピクセルデータの場合のみ)
エージェントが画像のどの部分に特に注目して特徴量を抽出しているのかを可視化する機能を, モデルの入力が画像のピクセルデータの場合に特化して実装しました.
この機能は, Visualizing and Understanding Atari Agents を参考にして実装しました.
以下の動画では, CategoricalDQNで学習されたエージェントのSaliency mapを可視化しています.
現時点でSaliency mapを可視化する計算コストがかなり大きいため, Saliency mapを可視化するステップの範囲を指定できるようにしています.

4. その他様々な可視化
エージェントの種類に応じて様々な可視化をサポートしています.
例えば以下の動画では, CategoricalDQNで学習したエージェントの, ステップごとの価値の分布を可視化しています.

とりあえず動かしてみるためのクイックスタートガイドを用意しています.

これまでの多くの可視化ツールは, 「学習の進行に合わせたスコアの表示, およびその他指標の遷移」を可視化することに主眼が置かれていましたが,
ChainerRL Visualizerは, 学習済み, 及び学習途中のエージェントの挙動を動的かつインタラクティブに可視化したという点に, これまでにない可視化ツールとしての特徴があります.

似た思想の元作られたライブラリとしては, Uber Researchによる Atari Zoo が挙げられます.
このライブラリは, 強化学習エージェントを理解するための研究を加速することを設計理念として掲げ, 学習済みモデルと, その学習済みモデルを分析するツールを提供することによって, 計算リソースを十分に持たない研究者に対して, 強化学習エージェントを理解するための研究を促進することを狙っています.
Atari Zooでは, 特定のアーキテクチャ(RawImagePIxel => Conv => Conv .. => FC => FC..)とALEという環境に限定した学習済みモデルと分析ツールを提供しているのに対し, ChainerRL Visualizerでは, ChainerRLで学習したエージェントならばユーザーが学習したどんなエージェントも動的に可視化できるという点で差別化ができています.

また, DQNViz のようにDQNに特化して各種メトリクスを可視化し, DQNのエージェントがどのようなStrategyを学習過程で獲得しているのかを研究しやすいようにサポートするツールの提案も出てきています.

これまで数多くの強化学習の性能向上に関する研究がなされてきましたが, 強化学習のエージェントがどのように環境を解釈し, 何を学習したのかについての研究は比較的少ないものでした.
しかし今後, 以上に見た各種ツールの提案に見られるような強化学習エージェントを理解するための研究が徐々に増えていくことが予想されます.

現在ChainerRL Visuailzerはベータ版であり, エージェントを分析するための機能もまだまだ少ない状態です.
今後発展していくであろう強化学習エージェントを理解するための研究開発に少しでも貢献できるようなライブラリとして進化していけるように, さらなる継続的な開発が必要です.

機能の追加やUX向上に関する調整に関して, OSSなどを通したChainerRL Visualizerへの貢献を歓迎しています.

プログラミング教育推進月間の教材について

Hiroshi Maruyama

2019-02-18 18:00:37

PFNフェローの丸山です。2月18日に、PFNは文部科学省、総務省及び経済産業省の「未来の学び プログラミング教育推進月間」に協力して、小学校向けのプログラミング教材を作成することを発表しました。この教材は、今年の9月に一部の小学校で、総合学習の一環として利用されることを目指しています(指導案のページはこちらです)。この記事では、私達PFNがなぜこのような活動をしているかをお話ししたいと思います。

PFNは若い会社です。多くの若い社員が次々に家庭を持ち、子どもを育て始めています。社長の西川をはじめ皆、次の世代が活躍し、よりよい社会を作っていくことを強く願っています。これからの社会を考えたとき、マーク・アンドリーセンが「ソフトウェアが世界を侵食する」(Software is eating the world) と言ったことに象徴されるように、社会の価値の多くが情報技術、特にソフトウェアから得られることは明らかです。ですから、私達の次の世代の誰もが、小さい頃から情報技術に親しみ、プログラミングの楽しさを知る機会を持てることは、私達にとっても大変喜ばしいことです。そんな若い人たちが、ソフトウェアに興味を持ち、将来社会のあらゆる場で活躍している、そんな社会の実現をPFNは願っています。

新しいスタイルのプログラミング

同時に私達は、技術の進歩によって、今までとは違う新しいスタイルのプログラミングが現れつつあることも強く認識しています。簡単にするため、プログラムとはある入力Xに対して出力Yを計算する箱であると考えます。

このようなプログラムを作る1つの方法は、計算のルールを書き下すことです。たとえば、商品の価格を入力としてその消費税を出力するプログラムを考えましょう。このようなプログラムは、入力Xに対して「X の0.08倍を計算してYとせよ」 というルールで表現することができます。これが普通のプログラムの作り方で、ここではルールによるプログラミングと呼ぶことにしましょう。

しかし、深層学習という新しい技術によって、別の形のプログラミングが現れてきました。こんな例を考えてみましょう。人とじゃんけんをする機械を作るために、カメラで撮った手の画像を入力として、それがグー・チョキ・パーのいずれであるかを判定して出力するプログラムを作りたいとします。

このようなプログラムを、ルールによるプログラミングで作るのは容易ではありません。カメラで撮影した画像は画素が格子状に並んだものですが、ある画素が肌色だからこれはチョキだ、と判断するわけにはいきません。同じチョキでも位置や角度や光源が違ったりして毎回異なる画像になるからです。

そこで、深層学習では、様々に異なるチョキの画像をプログラムに見せて「これはチョキだよ」と教えていくことによってプログラミングを行います。これを例示によるプログラミングと呼ぶことにします。例示によるプログラミングでは、ルールを書くのが難しいようなプログラムも作ることができます。

一方で、例示によるプログラミングでは、例示に使うデータによっては、必ずしも毎回正解が出ないかもしれません。あるいは例示に偏りがあった場合には、偏りのある結果が出るかもしれません。これは、ルールによるプログラミングが(プログラムに誤りが無い限り)常に正しい答えを出すこととは対照的です。

将来のソフトウェア

例示によるプログラミングは、ここ10年ほどの、深層学習の急速な発展によって可能になってきていて、今までのルールによるプログラミングでは難しかった画像認識、音声認識、機械翻訳などに応用されつつあります。これは、1950年代にデジタル計算機が発明されて以来の最大のパラダイムシフトかもしれません。おそらく、将来のソフトウェアの多くは、ルールによるプログラミングと例示によるプログラミングを組み合わせたハイブリッドなものになるでしょう。

私達が今回の「未来の学び プログラミング教育推進月間」にご協力している真の理由はここにあります。今の子供達が大人になって、社会におけるソフトウェア開発の一翼を担うころには、例示によるプログラミングが広く使われていることは間違いありません。ルールによるプログラミングが苦手でも、例示によるプログラミングは得意だ、という子どももいるでしょう。

「プログラミング」を狭く捉えないで、いろいろな考え方があるのだ、ということを知ってほしい、それが私達の願いです。