ハッカー倫理に準拠した人工知能のアーキテクチャ設計

スポンサーリンク

派生問題:人工知能のアーキテクチャ設計は如何にして可能になるのか

人工知能のとりわけ機械学習の領域では、アルゴリズム設計アーキテクチャ設計を両立することで、全体の俯瞰を可能にする設計が必要となる。そこで私は、一つの「実験」として、GoFのデザイン・パターンUMLなどのようなアーキテクチャ設計のノウハウが深層学習設計にも活用できることを実践的に例示していく。これにより、アルゴリズム設計アーキテクチャ設計の「橋渡し(Bridge)」が実践可能であることを説明していこう。

プロトタイプの開発:深層強化学習のアーキテクチャ設計

ここでの「実験」は、まず深層ボルツマンマシン設計から始める。そして、ここで仕様化したアーキテクチャ機能的な再利用や機能的な拡張を通じて、ニューラルネットワーク深層強化学習をはじめとした様々な機械学習システムを開発するサイクルを繰り返していく。

ソフトウェア要求定義:アーキテクチャとアルゴリズムを両立できる橋渡し(bridge)

TensorFlowやscikit-learnをはじめとしたライブラリは、深層学習の開発に伴う負担を軽減してくれる。これらのライブラリは深層学習アルゴリズムブラックボックス化するばかりか、アルゴリズム設計それ自体をもブラックボックス化している。その結果、アルゴリズム設計が如何にして可能になるのかが不透明になっている。

ここで我々は、<アルゴリズムブラックボックス化>と<アルゴリズム設計ブラックボックス化>の区別を導入することで、双方の差異に敏感にならなければならない。ブラックボックス機能は、機能的な再利用可能性機能的な拡張可能性を提供することにある。オブジェクト指向設計におけるカプセル化の概念が指し示すように、確かにアルゴリズムブラックボックス化は後の実装に有用となる。しかし、アルゴリズム設計それ自体がブラックボックス化されると、アルゴリズム設計アーキテクチャ設計の接点が不透明になる。

この接点が不透明では、アルゴリズムを再設計する際に、アルゴリズムアーキテクチャを包括する俯瞰的な観察と分析が困難となる。その結果、次のような問題が派生することになる。

  1. アーキテクチャ設計者によって選定されたアーキテクチャと、アルゴリズム設計者によって選定されたアルゴリズムが競合する危険がある。
  2. アーキテクチャ設計のノウハウがアルゴリズム設計で活かされない場合や、その逆があり得てしまう。

これらの問題は、機械学習関連のライブラリに伴う逆機能であると考えられる。

アーキテクチャアルゴリズムを両立できる橋渡し(bridge)のロールを探し出さなければならないというのは、研究開発の現場で派生し得る具体的な課題の一例となるだろう。

テラバイト以上の規模のデータを処理する場合には、既存のライブラリではパフォーマンスに限界が生じる可能性もある。その場合には、既存のライブラリの機能的な再利用に留まるのではなく、アルゴリズムアーキテクチャを自らで設計していかなければならなくなるだろう。

上述した諸問題は、アーキテクチャ設計者自身が深層学習アルゴリズム設計できるようになっていれば、解消される。アーキテクチャ設計アルゴリズム設計の双方を「実践」することによって、両者を橋渡し(bridge)する視点を養うことが可能になる。この「実践」は、同時に、アーキテクチャ設計のノウハウをアルゴリズム設計で活かす「実験」の機会にもなる。

使用するプログラミング言語はPython3となる。だが、あえてTensorFlowをはじめとしたライブラリは利用しないという「縛り要素」を加えておきたい。と言うのも、これらのライブラリを利用してしまっては、アルゴリズム設計それ自体のブラックボックス化に伴う上述した問題を回避できなくなるからだ。

アーキテクチャ設計:深層ボルツマンマシン

上述した問題設定から、本開発ではTensorFlowやCNTKやChainerやH2Oなどのように、深層学習アルゴリズム設計ブラックボックス化しているライブラリは再利用せずに、深層ボルツマンマシンアーキテクチャアルゴリズム設計していく。

深層ボルツマンマシンは「制限ボルツマンマシン」を多層化して積み上げた構成をしている。この積み上げ方次第で、このモデルを様々なデータセットの性質に対応した予測モデルとして機能させることが可能になる。

システムの構成

以下のコンポーネント図は、二つの制限ボルツマンマシンコンポーネント構成された深層ボルツマンマシンを例示している。

このコンポーネント図で表現されるように、個々の「ニューロン」のコンポーネントが、「可視層」のコンポーネントと「隠れ層」のコンポーネントに大別される。この「可視層」と「隠れ層」の関連は、それぞれ「制限ボルツマンマシン」のコンポーネント制御することになる。ただし「制限ボルツマンマシン」のコンポーネント内部では、「組み合わせ爆発」の問題に備えて、予め近似関数処理に特化したサブコンポーネントを包含することとする。

以上のコンポーネント設計を前提とすれば、本開発で重要なアーキテクチャとなるのは、「制限ボルツマンマシン」のコンポーネントであると考えられる。主題としている「深層ボルツマンマシン」のコンポーネントは、言わばこの「制限ボルツマンマシン」に依存したクライアントとして位置付けられる。

したがって、「制限ボルツマンマシン」のコンポーネントに関しては内部のアルゴリズム設計に注力するべきである一方で、「深層ボルツマンマシン」のコンポーネントに関しては、この「制限ボルツマンマシン」のコンポーネントを如何にして機能的に利用可能にするのかという観点からアーキテクチャ設計に注力する必要がある。

設計の観点:4+1ビュー

IBMのRational Unified Processの4 + 1 Viewに対応付けて設計の観点を記述していく。ただしこの設計観点には次のような注意事項が伴う。

  1. 設計担当者が必要と考えるビューのみに言及するため、製作すべきプログラムの全てを網羅することは最初から意図していない。
  2. このビューの絞り込みにおいて重要視しているのは、アーキテクチャの決定に影響を及ぼす諸要素と、アーキテクチャそれ自体に他ならない。
  3. 複数のビューが取り上げられた場合、設計担当者はビュー間の関連性に注目すべきであると判断していることになる。
ユースケース・ビュー

実装するコンポーネントは、最終的にはバッチプログラムかオンラインのアプリケーションとして運用することになる。ただしその前提として、モデル性能を比較する必要がある。データセットを配置して、ハイパーパラメタを調節しながら、コンソール上から実行することで、適合率や再現率、あるいはF値などのような指標を算出するというユースケースは、機械学習設計実装では避けられない要求の観点になるだろう。

しかし上述した問題設定との関連で言えば、実装するコンポーネントは、その「機能追加」や「改修」などのような「保守」において、アルゴリズム設計アーキテクチャ設計の両立を実践できるようになることが求められる。そのためここではまず、「アルゴリズム設計との関連から要求されるユースケース」と「アーキテクチャ設計との関連から要求されるユースケース」の関連を想定しなければならない。

そしてそのユースケースに対応するアクターとしては、アルゴリズム設計者とアーキテクチャ設計者を汎化させた抽象度の比較的高いアクターだ。このアクターは、抽象的な設計者として、双方の設計を両立できる存在として想定できる。

論理ビュー

上述した「制限ボルツマンマシン」のコンポーネントの内部は、以下のクラス図のような構成となる。

各クラスに関して、幾つかポイントを絞って説明していこう。

抽象基底クラス:Neuron

深層ボルツマンマシンコンポーネント構成を前提とするなら、制限ボルツマンマシンで参照されるニューロンという概念は、次の三つに区別できる。

  1. 可視層のニューロン
  2. 隠れ層のニューロン
  3. 隠れ層のニューロンのうち、特に特徴点として観測されるニューロン

これら三つのニューロン概念に対してジム・コプリエン流の「共通性/可変性分析」を実践するなら、各ニューロンの共通性可変性は次のように分類できる。

ニューロン概念の共通性
  • 各ニューロンは、バイアスを状態として保持する。
  • 各ニューロンは、活性化関数を包含する。
  • 各ニューロンは、活性度を状態として保持する。
  • 各ニューロンは、活性化関数を実行する振る舞いを持つ。
  • 各ニューロンは、バイアスを更新する振る舞いを持つ。
ニューロン概念の可変性
  • 可視層のニューロンが観測データ点の入力を受け付けるのに対して、隠れ層のニューロンは観測データ点を受け付けない。
  • 隠れ層のニューロンのうち、特に特徴点として観測されるニューロンは、通常の隠れ層のニューロンとは異なり、その活性度を疑似的な観測データ点として公開する。したがって、その活性度は可視性をpublicにするか、あるいはメソッドの返り値によって連携できるようにしておかなければならない。
  • 各層のニューロンは、それぞれ異なる活性化関数によって、その活性度を更新する場合がある。
ニューロン概念のTemplate Method Pattern

以上の共通性可変性差異から、共通部分を抽象基底クラス:Neuronの仕様として実装することとする。一方可変部分については、この抽象基底クラスを継承した下位クラスによって実装していく。可視層のニューロンに特化した部分、隠れ層のニューロンに特化した部分、そして特徴点として観測されるニューロンに特化した部分に関しては、それぞれ下位クラス:VisibleNeuron、HiddenNeron、FeaturePointNeuronにおいて実装する。

あえてGoFのデザイン・パターン表現するなら、これらの下位クラスと抽象基底クラスの関連は、Template Method Patternの構成仕様化していく。つまり、活性化関数やバイアスなどのような変数によって活性度を更新していくというアルゴリズムの大枠としての方向性は共通しているものの、各層のニューロンの差異に応じて個別具体的なアルゴリズムを下位クラスに任せるというクラス構成になる。

活性化関数のStrategy Pattern

要求されるモデルに応じて、ニューロンの活性化関数は可変となる。例えばシグモイド関数、ソフトマックス関数、ロジスティック回帰など、様々なアルゴリズムが要求され得る。とはいえ、各活性化関数の種類に応じて一々ニューロンのクラスを設計して実装しているようでは、冗長なプログラムが制作されてしまう。

そこで、活性化関数責任を有したクラスを上述したTemplate Method Patternから区別する。インターフェイス:ActivatingFunctionInterfaceを仕様化することで、要求されるモデルに対応した活性化関数を上述したニューロンのオブジェクトに委譲できるようにしておく。あえてGoFのデザイン・パターンで言い換えるなら、これは委譲を介したStrategy Patternの構成になる。各層のニューロンに対応したそれぞれのニューロンのオブジェクトは、インターフェイス:ActivatingFunctionInterfaceを参照することによって、活性化関数アルゴリズムブラックボックス化した上で再利用可能な状況になる。

完全二部グラフとしてのシナプス結合のStrategy Pattern

制限ボルツマンマシン完全二部グラフとして構築される。深層ボルツマンマシンは更にこのグラフを言わば再帰的に結合させることで構築される。ただし全体の構成としては、可視層のニューロン、隠れ層のニューロン、そして特に特徴点として観測されるニューロンの「多重度」は可変となる。インスタンス化され得る可視層のニューロンの個数は、観測データ点の分布に応じて変わり得る。隠れ層のニューロンもまた、特徴表現をどの程度豊かに実現させるのかに応じて変わり得る。

これを前提とした上で、本開発では、この完全二部グラフ象徴するクラス:CompleteBipartiteGraphを実装する。ただし、複数のニューロンのシナプス結合を実行するというのは、制限ボルツマンマシンに限らず、様々なニューラル・ネットワークで要求され得るユースケースになるだろう。そこでシナプス結合処理に関しては抽象化する。抽象基底クラス:Synapseを実装することで、完全二部グラフのクラス:CompleteBipartiteGraphをこの抽象基底クラスの下位クラスとして位置付ける。

ここでも「共通性/可変性分析」を実施しよう。抽象基底クラス:Synapseには、他のニューラル・ネットワークとも共通する処理として、結合の重みを更新する処理を実装する。一方、下位クラス:CompleteBipartiteGraphには、完全二部グラフとして、可視層のニューロンと隠れ層のニューロンの結合のみを実行するという制約条件を前提とした重みの更新処理を実装していく。

完全二部グラフのクラス:CompleteBipartiteGraphと抽象基底クラス:Neuronの関連における多重度は1よりも大きい数値になり得る可能性が高い。CompleteBipartiteGraphはlist型のプロパティを保持することで、これら複数のニューロンのオブジェクトを包含することになるだろう。その際、タイプヒントし易くするために、可視層の振る舞いと隠れ層の振る舞いを仕様化したインターフェイスとして、それぞれインターフェイス:VisibleLayerInterfaceとインターフェイス:HiddenLayerInterfaceを実装していく。これらのインターフェイスを前提とするなら、CompleteBipartiteGraphとNeuronの関連は委譲とも呼べる。各ニューロンの活性化のアルゴリズムはカプセル化されているため、この点においてもStrategy Patternの発想が活きてくる。

関数近似のStrategy Pattern

上記のクラス図におけるクラス:RestrictedBoltzmannMachineは、上述した完全二部グラフのクラス:CompleteBipartiteGraphを参照するコントローラとして機能する。ただし制限ボルツマンマシン実装する場合、学習方程式組み合わせ爆発問題との兼ね合いから関数近似が要求される。この関数近似アルゴリズムもまた可変だ。例えばギブスサンプリング、コントラスティブ・ダイバージェンス法平均場近似などが挙げられる。

したがって、関数近似アルゴリズムをクラス:RestrictedBoltzmannMachineから区別すると共に、ここでもまたStrategy Patternを採用することによって、このアルゴリズムをカプセル化したオブジェクトをRestrictedBoltzmannMachineのクラスに委譲可能な状態として仕様化していく。

深層ボルツマンマシンのBuilder Pattern

深層ボルツマンマシンコンポーネントは、以上のような制限ボルツマンマシン仕様を前提とした上で設計されなければならない。深層ボルツマンマシンのクラス構成は以下のようになる。

結局のところ深層ボルツマンマシンは、制限ボルツマンマシンを多層的に積み重ねたオブジェクトに過ぎない。何層の構成で、何個のニューロンがシナプス結合されるのかに関しては、それこそ要求されるモデル次第で可変となる。深層ボルツマンマシンは、そうした要求に応じて柔軟に制限ボルツマンマシンの関連オブジェクトを「生成」できるように設計される必要がある。そこで「生成」に関するクラス構成を一考しておかなければならない。

一つの問題解決策として採用できるのは、GoFのデザイン・パターンで言うところのBuilder Patternだ。Builder Patternは、複合化されたオブジェクトの生成過程をカプセル化することによって、一定の過程で異なる内部構成オブジェクトを生成することを可能にする。このデザイン・パターンは、その名の通り全体を構成している各部分の処理を積み上げていく一連の過程をブラックボックス化することで再利用可能にする点にメリットを有している。

上記のクラス図に準えて列挙するなら、クラス:DeepBoltzmannMachineは入力されたハイパーパラメタに応じて深層ボルツマンマシンオブジェクトを構築するBuilder PatternのClientとして振る舞う。

クラス:DBMDirectorは、Builder Patternにおける「監督者」として、 制限ボルツマンマシンを組み立てることで、深層ボルツマンマシンオブジェクトを生成する責任を担う。

インターフェイス:DBMBuilderは、Builder Patternにおける「建築者」として、制限ボルツマンマシンを生成する上での共通処理部分の仕様を明示化する。

クラス:DBM3LayerBuilderは、Builder Patternにおける「具体的建築者」として、3層の制限ボルツマンマシンを組み立てることで、深層ボルツマンマシンオブジェクトを生成する。回はたまたま3層の積み立てとなったが、別の層数やハイパーパラメタが要求された場合には、それに応じて別の「具体的建築者」となるクラスを実装していくことになる。

疑似的な観測データ点としての特徴点

深層ボルツマンマシンでは、隠れ層のニューロンの一部を疑似的な観測データ点と見立てることになる。これを特徴点と呼ぶ。特徴点表現のために、本開発ではクラス:FeaturePointNeuronを実装する。このクラスは、深層ボルツマンマシン特徴点を疑似的な観測データ点と見立てることを前提に、隠れ層のニューロンを疑似的な可視層ニューロンとしてインスタンス化するクラスとなる。隠れ層のニューロンの機能的等価物であると共に、可視層のニューロンの機能的等価物としても実装することになる。

このクラスは、メソッド:initで初期化処理を実行する際に、隠れ層のニューロンのインターフェイス実装したニューロンのオブジェクトを引数として受け取る。このクラスは、この引数を内部のプロパティとして保持する。つまり自分自身をvisible_layer_interfaceの型で仕様化すると共に、本来のvisible_layer_interfaceを実現した可視層ニューロンを包含することで、自分自身も可視層ニューロンとして振る舞えるようにする。

これにより、このクラスは可視層のニューロンの機能的等価物として観測データ点を疑似的に処理できると共に、隠れ層のニューロンの機能的等価物として活性度やバイアスを計算可能になる。

実装ビュー

ここでは深層ボルツマンマシンのインスタンス化に伴う動的構造を取り上げる。

「Builder Pattern」として設計しておくことで、制限ボルツマンマシンを別の積み上げ方で組み込むことになった場合でも、同一のインターフェイス:DBMBuilderを実現したクラスとして実装することで対応できるようにしておく。

プロセス・ビュー

活性化関数を呼び出すニューロンと活性化関数それ自体のアルゴリズムとの関係は、「Strategy Pattern」のような委譲の関連とする。活性化関数にはインターフェイスを設置しておく。回はシグモイド関数実装することになるが、次回以降の再利用時にはソフトマックス関係など様々な関数が要求される可能性もある。

制限ボルツマンマシンと近似処理の関連は、委譲による「Strategy Pattern」の関連にしておく。回はコントラスティブ・ダイバージェンス法を採用しているが、近似処理の方法は一つではない。予めインターフェイス越しにカプセル化しておくことで、別のアルゴリズムで近似できるようになったとしても対応できるようにしておく。

配置ビュー

回は省略する。

アーキテクチャ設計:ニューラルネットワーク

上述した深層ボルツマンマシンアーキテクチャ設計内容を再利用することによって、ニューラルネットワーク設計していく。

ニューラルネットワークにおけるニューロンの仕様に関しては、深層ボルツマンマシンとの関連で設計した抽象基底クラス:Neuronをニューラルネットワークの用途から機能的に拡張することで設計していく。特に出力層のニューロンに関しては、深層ボルツマンマシンでは要求されなかった。これについては、抽象基底クラス:Neuronを前提とした別様のアルゴリズムとなる。故にGoFのデザイン・パターンの一つであるTemplate Method Patternによって、この抽象基底クラスを前提とした出力層のニューロンの具象的な処理を実装していく。

フォワードプロパゲーションとバックプロパゲーション機能は、既に深層ボルツマンマシン完全二部グラフの親クラスとして設計していたクラス:Synapseを継承することで設計していく。

深層ボルツマンマシンの生成過程は、制限ボルツマンマシンオブジェクトをGoFのデザイン・パターンの一つであるBuilder Patternの要領で組み立てていく仕様とした。同様にニューラルネットワークについても、上述したクラス:Synapseを継承したグラフオブジェクトをBuilder Patternで構築していく。

設計の観点:4+1ビュー

深層ボルツマンマシン設計と同様に、IBMのRational Unified Processの4 + 1 Viewに従って、各設計観点を記述していく。

ユースケース・ビュー

モデル性能評価のユースケースは、深層ボルツマンマシンにおけるユースケースと等価となる。

論理ビュー

抽象基底クラス:Neuronを前提としたTemplate Method Patternの具象クラスとして、クラス:OutputNeuronを新たに導入している。これにより、ニューラルネットワークに必要となる可視層(入力層)、隠れ層(中間層)、そして出力層のニューロンを揃えることができる。

一方、これらのニューロンを紐付けることでフォワードプロパゲーションやバックプロパゲーションを実現するクラスとして、クラス:NeuralNetworkGraphを導入する。このクラスはクラス:Synapseの下位クラスとなる。このグラフオブジェクトによって、ニューラルネットワークリンク部分の重みをバックプロパゲーションによって更新していく仕様を実現していく。

各インスタンスの生成は、深層ボルツマンマシン同様に、GoFのデザイン・パターンの一つであるBuilder Patternで仕様化する。生成したニューラルネットワーク関連のインスタンスを保持するクラス:NeuralNetworkが、各オブジェクトを参照することで、フォワードプロパゲーションやバックプロパゲーションを実行するコントローラのような責任を担うことになる。

実装ビュー

深層ボルツマンマシン設計で取り上げた実装ビューと同様に、ニューラルネットワークの生成過程はBuilder Patternをそのまま再現した仕様となる。

プロセス・ビュー

Synapseの型を有したオブジェクトと活性化関数との関連は、制限ボルツマンマシンと同様の構成になる。

配置ビュー

回は省略する。

アーキテクチャ設計:深層強化学習

上述した深層ボルツマンマシンアーキテクチャ設計内容を再利用することによって、ある種の「深層強化学習(Deep Reinforcement Learning)」を設計していく。

専ら深層強化学習において名を馳せているのは、Googleが「Q学習(Q Learning)」と「畳み込みニューラルネットワーク(Convolutional neural network)を組み合わせることで設計したDeep Q-networks(DQN)だ。しかし強化学習問題の枠組みの観点から観れば、この組み合わせの選択は別のあり方でもあり得る。強化学習アルゴリズム深層学習のようなアルゴリズムとの結合を要求するのは、状態あるいは状態対行動の組み合わせが大量にあり得る場合のメモリやデータ量の面で限界に直面してしまうからだ。つまりこの場合の深層学習は、強化学習アルゴリズムで状態や状態対行動の組み合わせの「複合性の縮減」が如何にして可能になるのかという問題設定を前提とした問題解決策として導入されているのである。

これは、言い換えれば「一般化(generalization)」の問題として設定できる。状態や状態対行動の組み合わせの観測データを一般化することで、より広汎な状態や状態対行動の組み合わせに対する近似を構成していくことが求められているのだ。

この問題設定に対する問題解決策として第一に挙げられるのは、DQNでも採用されているように、「関数近似(function approximation)」であろう。それは強化学習問題の枠組みにおける価値関数をはじめとした目的関数からサンプルを抽出して、そこから関数全体を近似するように一般化を実行していく。関数近似教師あり学習の一種だ。畳み込みニューラルネットワークは、これを可能にする具体例の一つとなるだろう。

しかし抽象化するなら、この一般化問題に対する機能的に等価問題解決策は直ぐに思い付く。例えば観測データから未知のデータをベイズ的に予測する統計的機械学習のモデルは、状態や状態対行動の組み合わせに対しても適用できる。状態や状態対行動の組み合わせに関する観測データから未知の潜在的な構造を推定することによって、より効率的に報酬を探索していくこともまた、状態や状態対行動の組み合わせに伴う複合性への対処法となるはずだ。

したがってここでは、DQN同様にQ学習を軸とするものの、畳み込みニューラルネットワークはあえて採用しない。代替として、上述した深層ボルツマンマシンアーキテクチャ機能的に再利用する。

設計の観点:4+1ビュー

深層ボルツマンマシン設計と同様に、IBMのRational Unified Processの4 + 1 Viewに従って、各設計観点を記述していく。

ユースケース・ビュー

実装するコンポーネントは、迷路探索の強化学習エージェントとする。以下のユースケース図のように、アクター:エンドユーザがバッチプログラムをデバッグモードで実行することによって、強化学習エージェントが迷路探索を開始する。途中、コンソール上には迷路の地図(map)が表示される。その地図の情報から、エージェントの位置情報報酬獲得状況を確認できるようにする。

尚、エンドユーザから観て、深層強化学習における深層学習の部分はブラックボックス化されていた方が良いだろう。何故なら、深層学習はあくまでも強化学習問題の枠組みにおける補佐的な位置付けにあるからだ。強化学習であれ、深層強化学習であれ、外部から観た振る舞いは極力同様であった方が無難だ。これを踏まえて、ユースケース図のシステム境界では「ReinforcementLearning」が参照するように描写した。

論理ビュー

ここでは、ボルツマン選択によるQ学習とε-greedy法によるQ学習区別を導入する。双方のアルゴリズム的な差異を前提に、共通性/可変性分析を実行する。共通部分を抽象基底クラス:QLearningに纏め上げる一方で、可変部分の処理は下位クラス:BoltzmannQLearningと下位クラス:GreedyQLearningで記述する。

上記のユースケース図でも示した通り、回のデモで取り上げるのは迷路探索だ。したがって、迷路探索に特化した処理はそれぞれの下位クラスであるMazeBoltzmannQLearningとMazeGreedyQLearningに記述する。迷路探索の共通処理はインターフェイスとして定義しておく。そしてこのインターフェイス上のメソッドを深層強化学習による迷路探索に特化したクラス:MazeDeepBoltzmannQLearningから呼び出す。

これらのことから、Q学習の共通部分と可変部分はTemplate Method Patternの構成設計する。深層強化学習に特化したクラス:MazeDeepBoltzmannQLearningは、このQ学習関連のクラスと深層ボルツマンマシンのクラスを機能的に再利用するコントローラとしての責任を担うことになる。

実装ビュー

上記のように、深層強化学習用のクラス:MazeDeepBoltzmannQLearningのメソッドの呼び出す順序は、Q学習関連のクラスのメソッドの呼び出す順序と等価にする。

プロセス・ビュー

回は省略する。

配置ビュー

回は省略する。

実装成果物

ソースコードは以下の通りGitHub上で公開している。

スポンサーリンク