WEBVTT 00:00.330 --> 00:04.950 このチュートリアルは､ このモジュールのほぼ最後のチュートリアルです｡ 00:04.950 --> 00:11.870 ワクワクするような結果を得て､ 動画を見る前に､ 全体を実行するメインのコードを説明します｡ 00:11.880 --> 00:15.690 これがメインコードで､ ご覧の通り､ かなり短いものです｡ 00:15.690 --> 00:21.060 まず､ ライブラリやモジュールをインポートし､ モデルファイルからactive critic､ 00:21.060 --> 00:28.680 trainファイルからtrain関数､ testファイルからtest関数など､ 作成した様々なクラスや関数をインポートします｡ 00:28.680 --> 00:31.200 もちろん､ オプティマイザーもインポートしています｡ 00:31.710 --> 00:39.510 そして､ 最初のセクションでは､ クラス､ すべてのパラメータ､ そしてこのparamsに入るところから始めます｡ 00:39.510 --> 00:48.720 このparamsオブジェクトは､ 学習率､ ガンマ､ タウなどのパラメータを取得するたびに､ このparamsクラスから生成されたものであることを思い出してください｡ 00:48.930 --> 00:50.610 では､ さっそく見ていきましょう｡ 00:50.610 --> 00:54.270 こちらの1つ目のRが学習率です｡ 00:54.270 --> 00:56.610 ですから､ ご覧のように小さな学習率を選んでいます｡ 00:56.820 --> 00:59.010 2つ目は､ ガンマパラメーターです｡ 00:59.010 --> 01:01.920 今回も8とします｡ 99. 01:01.920 --> 01:10.620 1種類のパラメータ､ 116のプロセス､ 20ステップ､ 最大長10,000のセットを取る｡ 01:10.620 --> 01:12.210 そのことを話したのを覚えていますか？ 01:12.330 --> 01:18.870 これは､ エージェントが環境の状態に無制限にはまり込まないようにするために設定するパラメータです｡ 01:18.870 --> 01:24.630 つまり､ エピソードの長さがこの最大長を超えると､ ゲームが停止してしまうのです｡ 01:24.750 --> 01:30.780 そして､ 最終的にはもちろん､ 環境の名前､ ゼロを割り出す｡ 01:30.780 --> 01:38.130 ちなみに､ この環境名を変えるだけで､ 他の環境でも遊べるようになります｡ 01:38.130 --> 01:43.800 だから､ もしあなたが他のブレイクアウトバージョンや他のアタリゲームをプレイしたいのなら､ 01:43.800 --> 01:52.890 このブレイクアウトビジュアルを他のゲームに置き換えればいいのですが､ このブレイクアウトビデオはすでに非常にチャレンジングだと言えます｡ 01:53.580 --> 01:53.910 わかりました｡ 01:53.910 --> 01:59.250 つまり､ ここにすべてのパラメータがあり､ そこにメイン実行のコードがあります｡ 01:59.250 --> 02:02.610 で､ ここで､ この最初の行で何をするのかを見てみましょう｡ 02:02.610 --> 02:05.100 1コアに1スレッドを設定しました｡ 02:05.130 --> 02:13.950 次に2行目では､ paramsクラスのオブジェクトを作成してすべてのパラメータを取得し､ 初期化を行っています｡ 02:13.980 --> 02:19.380 これらのパラメータはすべて､ このパラメータ・オブジェクトに付属する変数があるため､ ここにあります｡ 02:19.380 --> 02:27.630 次にシードを設定し､ create entryと関数を使って環境を取得します｡ この環境はbreak out of 02:27.630 --> 02:29.910 zeroという名前です｡ 02:29.910 --> 02:35.100 env nameとそのparamsがゼロでブレークアウトしているのがわかります｡ 02:35.100 --> 02:37.650 それでブレイクアウトの環境が整うわけです｡ 02:37.650 --> 02:42.540 ところで､ これは通常の環境構築の方法とは異なりますが､ 全体のプロセスを改善し､ 02:42.540 --> 02:52.560 パフォーマンスを向上させるために､ 実際に最適化された環境を構築するために､ universeのおかげでこのようなことができるようになりました｡ 02:52.560 --> 02:57.150 Universeは､ オープンエアーにインストールしたすべてのパッケージが付属しています｡ 02:57.630 --> 03:01.380 まあ､ ユニバースのおかげで最適化された環境を手に入れることができましたが｡ 03:01.380 --> 03:03.240 ここがポイントです｡ 03:03.860 --> 03:09.050 そして､ アクティブクリティストクラスのオブジェクトを作成することで､ 共有モデルを取得します｡ 03:09.050 --> 03:14.990 そして､ ここで重要なのは､ この共有モデルが異なるエージェントが共有するモデルであることを理解することです｡ 03:14.990 --> 03:17.690 つまり､ 異なるコアに異なるスレッドがあるわけです｡ 03:17.990 --> 03:25.370 次の行でスレッドといえば､ メモリを共有する共有モデルですが､ これはコンピュータの共有メモリにモデルを格納して､ 03:25.370 --> 03:32.780 すべてのスレッドがたとえ異なるコアにいてもアクセスできるようにしたものです｡ 03:32.780 --> 03:34.400 だから､ ここではそうしているのです｡ 03:34.400 --> 03:36.440 これを可能にするためです｡ 03:36.620 --> 03:45.440 そして､ 共有モデルのパラメータにリンクされたオプティマイザを､ 学習率0として取得します｡ 03:45.440 --> 03:45.440 01. 03:45.650 --> 03:50.870 そして､ 繰り返しになりますが､ オプティマイザも共有モデルで動作し､ 次の行で同じように共有メモリを最適化することになるため､ 03:50.870 --> 03:55.940 共有であることを理解することが重要です｡ 03:55.940 --> 04:02.330 オプティマイザを共有メモリに格納し､ すべてのエージェントがオプティマイザにアクセスしてモデルを最適化できるようにします｡ 04:02.720 --> 04:10.190 そして､ プロセスを初期化することで､ テストプロセスは共有モデルを更新せず､ ただそれを使って1つのパートで試し､ 04:10.190 --> 04:14.660 スコアをプリントし､ ビデオを録画します｡ 04:14.660 --> 04:17.720 つまり､ ここで行われているのはまさに「Target Equals Test」なのです｡ 04:17.720 --> 04:24.230 これがテスト工程で､ この工程はそのマルチプリプロセスのほうで得られたものです｡ 04:24.230 --> 04:31.490 ここで､ 何をするかというと､ 基本的に独立したスレッドで関数を実行するのです｡ 04:31.580 --> 04:38.060 そこで､ P startを実行すると､ この行で初期化された新しいプロセスが開始されます｡ 04:38.060 --> 04:44.990 そして､ このappend Pというプロセスで､ プロセスのリストにプロセスを追加しています｡ 04:44.990 --> 04:54.230 そして最後にこのループの中で､ 共有モデルを更新して学習させる他のすべての処理を実行するループを行うだけです｡ 04:54.470 --> 04:57.860 そして､ このコードの最後の行では､ 基本的にそのようなことが起こっているのです｡ 04:58.130 --> 05:03.350 ですから､ もしあなたがその詳細に触れたくないのであれば､ 理解すべき重要なことは､ これが最適な方法でプロセスを実行するということです｡ 05:03.350 --> 05:12.530 したがって､ 私たちは皆､ このコードを実行し､ 学習済みのモデルを持ち､ 最終的に結果を見れば良いということです｡ 05:12.530 --> 05:14.060 だから､ 早くやりたいんです｡ 05:14.060 --> 05:15.830 これはかなりエキサイティングなことになりそうです｡ 05:15.830 --> 05:19.130 これからキーロールを探して､ みんなで観られるようにしたいと思います｡ 05:19.130 --> 05:21.560 というわけで､ 次回まで､ iをお楽しみください｡