複雑系・人工知能ゲーム
人間などの生命体の振る舞いは非常に複雑であり、いまだになぜこのような複雑さが出てくるのかは解明されていません。
｢複雑系｣や｢複雑適応系｣の学問は、これを解明していくことを主眼にしていますが、このページは、｢広く、浅く、楽しく｣複雑系の世界をのぞいていきます。
 | 強化学習
Richard S.Sutton, Andrew G.Barto, 三上 貞芳, 皆川 雅章 おすすめ平均 
人工知能・ニューラルネットワークにともなう学習方法に関して勉強するなら、この本がかなりお勧め。 Amazonで詳しく見る |
 | 複雑系―科学革命の震源地・サンタフェ研究所の天才たち
M.ミッチェル ワールドロップ, M.Mitchell Worldrop, 田中 三彦, 遠山 峻征 おすすめ平均 
この本で複雑系に目覚めた人もおおいはず。複雑系のおもしろさを語る名著!! Amazonで詳しく見る |
- 第1回 (03/04/08) 複雑系に興味を持った
- 第2回 (03/04/11) カオス創発実験-森林火災シミュレーション
- 第3回 (03/06/17) 複雑適応系に興味を持った
- 第4回 (03/08/21) 複雑適応系に興味を持った2
- 第5回 (03/09/25) 強化学習/ニューラルネットワークを利用したゲーム: ハムレット
- 第6回 (03/10/27) 強化学習/ニューラルネットワークを利用したゲーム: ハムレット2
- 第7回 (03/10/27) 強化学習/ニューラルネットワークを利用したゲーム: ハムレット3
複雑系に興味を持った
最近、遅れ馳せながら『複雑系』というものに興味を持ち始めています。細かくは、『複雑系』、『複雑適応系』などと分かれるようですが、私は素人なので漠然と『複雑系』として思い付いたことを書いて、実験していきたいと思います。
分子、細胞、生命体、社会、経済などはすべて『複雑系』システムであるといわれています。これは、いったいどういうことか、私なりに以下にまとめます。
- 局所ルールと相互作用に基づく大域的な振る舞いの創発
例えば、細胞を構成する分子は、分子としての局所ルール(化学、熱力学など)に基づき相互作用することにより、大域的に見れば細胞/組織(耳、目など)としての活動が見えてきます。
また、人は各々の局所ルール(価値観など)で行動をおこしますが、相互作用の結果『バブル』『恐慌』『ブーム』などの大域的な現象が創発しているように見えます。
- ランダムでもなく画一的でもない(カオスの縁)
ここは、まだ勉強中ですが、ランダムなシステムでは、システムが平衡点(アトラクタという)を持たないか、もしくは、小さな変化に対しての影響が非常に大きくなり(バタフライ効果という)、システムが非常に不安定な状態となります。
反対に画一的なシステムでは、アトラクタが少なく、システムへの変化がすべてそのアトラクタに引き込まれてしまいます。
これらのことから、生命のような『安定』していて『変化に対応できる』ような『複雑系』システムは、ランダムと画一的の中間にあるのではないかといわれています。(カオスの縁という)
カオス創発実験-森林火災シミュレーション
局所ルールと相互作用の創発実験として、有名な森林火災のシミュレーションを書いてみました。
ルールは、以下の通りです。
- 木(緑)は、周りが火災なら火災状態となる(赤)
- 火災状態(赤)は、燃え尽きて空き地になる(黒)
- 空き地(黒)は、確率p(ここでは左から、1、0.05、0.013を使用)で木(緑)になる
以下のリンクに実験javaアプレットがありますのでどのような現象が起こるか確認してください。
森林火災シミュレーションあまりにも遅いので、シングル版を作りました。
森林火災シミュレーション2単純な局所ルールと相互作用によりカオス的な複雑な現象が創発するのが確認できたでしょうか？
また、木の生成確率により、ランダム(カオス的)な現象(確率0.05)、収束する現象(確率1, 0.013)が確認できたでしょうか？
また、確率0.013の時は、クリックを何回かすることにより、偶発的にカオス的な現象に移行することが確認できたでしょうか？
残念ながら、第1回で書いたようなカオスの縁と呼ばれるような現象がどのあたりの確率で出てくるのか、またどのように見えるのか、私にはわかりませんでした。
非常に汚いですが、ソースを載せます。
森林火災シミュレーションsource複雑適応系に興味を持った
『複雑系』と『複雑適応系』とは明確に分かれる分野だということが、ようやく理解できてきた今日このごろです。
以下に私の理解を書きます。
- 『複雑系』
局所ルールによる大域的な振る舞いの創発およびその複雑性に関する研究。
カオス、フラクタルなどの複雑な創発現象及びその性質(初期値鋭敏性(バタフライ効果)、ストレンジ・アトラクタなど)の研究。
- 『複雑適応系』
生物などの『環境に適応』していくような系に関する研究。
ニューラル・ネットワーク、クラシファイア・システム、遺伝的アルゴリズム(GA)など生命の適応系を模倣するような系の研究。
個人的には、最近になって『複雑系』全般への興味から『複雑適応系』への興味に移行しつつあります。
大きな理由としては、『複雑系』より『複雑適応系』のほうが個人としての成果物(例えば『人工知能』を用いたゲームなど)が挙げやすいというところです。
やはり『マンデルブロー集合』の描画より『人工知能オセロ』のほうが趣味でやっていく分には面白そうだというところでしょうか。
その他の興味として『エージェント・シミュレーション』(Boid, SimCityなど)がありますが、これがどちらのカテゴリに属するかは、いまだ不明です。
さて、『複雑適応系』に話しを絞って考えた場合、系の特徴としてどのようなものを備えてなければならないでしょうか。
- 解の探索
系は何らかの入力に対して、取り得る出力(問題の解など)の中から適応度の高いものを出力します。
この取り得る出力をどのように探索するかに『複雑適応系』の一つの特徴があります。
普通のプログラミングでは、全探索になってしまうような状況であっても、適応度の学習結果などからより効率的な探索が行えるだろうということです。
- 汎化
系は、何らかの入力をより一般化(汎化(generalization))して扱うことが望ましいと思われます。例えば、人間も、『サッカー・ボール』、『テニス・ボール』などを『ボール』として一般化して扱うことができます。
特に探索領域の広い問題を扱う場合は、このような『汎化』ということが重要になると思われます。
- 適応度学習
系は何らかの入力に対して、取り得る出力(問題の解など)の中から適応度の高いものを出力します。
適応度は、状況に応じて変化することが考えられるため、進化や学習といったものを通して常に適応度の判断基準を最新にする必要があります。
ここで、問題となるものに『遅延報酬』というものがあります。系が何らかの出力を取ったとしても、その結果、適応度が上がったのか、下がったのかがすぐに分からないケースです。
このような問題は一般的によくある(オセロもそうですね)ので、このことにも留意して考える必要があります。
- 適応地形
『複雑適応系』を考える場合は、その対象とする問題にも前提があると思われます。
適応地形とは、『取り得る出力』それぞれの適応度をプロットした図のようなものです。
例えば、『プログラムの実行ファイル』を考えます。実行ファイルの実行効率を上げるために、ビットを1ビット反転させることを考えた場合、このプログラムが正常に動く可能性は、極めて低いことが容易に想像できます。
これは、『プログラムの実行ファイル』適応地形を考えた場合、ある一点の適応度だけが高く、それ以外は適応度が無いに等しいからです。
このような適応地形を持つ問題は、『複雑適応系』のシステムには向いていないと言えます。
- 局所ルール
『複雑適応系』は、『複雑系』の流れを受け継いでいると私は思いますので、系は、局所的なルールの相互作用により、適応度をあげるというものであるべきだと思います。
現在研究されているいろいろな『複雑適応系』によりそのアルゴリズムは異なりますが、『解の探索』、『汎化』、『適応度学習』といったことが行われていると考えられます。
- 遺伝的アルゴリズム(GA)
『遺伝的アルゴリズム(GA)』では、課題に対する取り得る『解』を遺伝子とみなし、その遺伝子の変異・交叉を通して『解の探索』を行うことを主眼にしています。
このアルゴリズムでは、最適な解が『適応度の高い解』の変異・交叉で得られることを前提に『適応度学習』を行っていると考えられます。
GAの私的見解:『解の探索』○、『汎化』X、『適応度学習』△(適応地形に前提がある)
- ニューラル・ネットワーク(NN)
『ニューラル・ネットワーク』では(いろいろな種類がありますが。。)入力・中間・出力の各層に脳細胞に見立てたセル(入力の大きさが閾値を超えた場合に『発火』する)を配備し、
各セル間の信号の連結度(シナプス可塑性に見立てている)を変化させることにより学習を行います。
例えば2入力1出力の『ニューラル・ネットワーク』でOR回路を学習する場合入力(0,0)の場合に出力(0), その他の場合、出力(1)となるようにセル間の連結度を変化(適応)させます。
この連結度の変化の方法に対していろいろな研究がされていて『バック・プロパゲーション』などが有名です。
この方式では、あらかじめ『最適な解』がわかっていることが前提となっているように個人的には思います(教師あり学習という)。『汎化』したものに対する学習した解を出力するというイメージです。
NNの私的見解:『解の探索』X、『汎化』○、『適応度学習』△(最適解を教師として入力が必要)
この他にもいろいろな系(クラシファイア・システム、強化学習システムなど)がありますが、『人間の脳』には、まだ遠いようです。
複雑適応系に興味を持った2
前回では、代表的な『複雑適応系』のアルゴリズムとして遺伝的アルゴリズムとニューラル・ネットワークを挙げましたが、最近『強化学習』という本を購入したので、そちらの紹介もしようと思います。
- 強化学習(RL: Reinforce Learning)
『強化学習(RL)』では、RLエージェントは、環境に対し何らかの"行動(action)"をとることにより、環境の"状態(state)"を変化させます。
一方、環境は、"状態(state)"と共に"報酬(reward)"をRLエージェントに対し与えます。
そこで、RLエージェントは"将来にわたってもらえる報酬(reward)"が最大になるように"行動(action)"を変化させるような学習を行います。
RLエージェントは、"状態の価値","ある状態でのある行動をとる価値"といったものを持っていて、環境から報酬をもらうたびに"状態価値"、"行動価値"を適応させていきます。
"状態価値","行動価値"は、複数ステップ前のものに対して適応させていくことも可能です。
例えば、サッカーでゴールを決めたことにより"報酬"が選られた場合、その前の行動である"シュート"や、さらにその前の"センタリング"などの"行動価値"が高いというふうに適応させます。
これにより、同様のシチュエーションになった時、RLエージェントはスムーズに"センタリング"や"シュート"という行動を取ることになります。
RLの私的見解:『解の探索』△(行動選択のアルゴリズムに工夫がいる)、『汎化』X(別のNNなどと組み合わせる)、『適応度学習』○(報酬の入力が必要)
強化学習/ニューラルネットワークを利用したゲーム制作: ハムレット
理論ばかり読んでいてもつまらないので、実際ゲームを作ってみようと思います。
今回作成するのは『ハムレット』というゲームです(この名前は、ツクダオリジナルの登録商標のようなので、他では『立体4目並べ』、『Win4』などと呼ばれています)。 このゲームの選定理由は、『3目並べ』よりゲームに幅があり、『オセロ(これも登録商標。。。Reversi)』よりゲームに幅がないという理由です。
まずは、強化学習を利用するということで、強化学習の基本原理から。
RLの基本的な構造
強化学習は、下図のように、基本的に環境との相互作用で学習していく方式となります。
RLの基本的な構造
+--------+
+-------->|RL Agent|
| +---->| |----+
| | +--------+ |
| | |
State| | Reward | Action
| | |
| | +-----------+ |
| '---|Environment|<--+
+-------| |
+-----------+
RLをクラスで考える
RLをクラス構造として考えるため、上記のRLの基本構造から流れを追っていきます。
- Agentが、現在のStateを取得する: Environment --> RL Agent
- Agentが、最も価値の高い次のStateを自分の価値関数(Value Function)から調べる: RL Agent --> Value Function
- 上記のStateに移行するためのActionをEnvironment(環境)になげる。: RL Agent --> Environment
- 環境からのReward(報酬)をえる。: Environment --> RL Agent
- 報酬を元に価値関数をアップデートする。: RL Agent --> Value Function
V(s)<-V(s) + α[reward + γV(s')-V(s)] :TD(0)方式
(言葉にすると、現在のStateの価値は、次のステートの価値+rewardに近づくように学習されるということ)
これをそのままクラス図に書くと下図のような感じになります。
RLのクラス図
+--------+ 1 +--------------+
|RL Agent|--------|Value Function|
| | +--------------+
| | 1 +--------------+ 1 +-----+
| |--------|Environment |------|State|
| | |(Singleton) | +-----+
+--------+ +--------------+
ただし、とれるActionの種類がStateによって変わる場合は、Environment側で次に取れるActionのリストを送るほうが実際的だと思われます。例えばハムレットの場合、上まで駒が入ってしまった列には、それ以上駒が入らないので、StateによりとれるActionが変わるということです。
これを反映させると、RLの構造的には、以下のようになり、
RLの基本的な構造2
+--------+
+--------------->lRL Agent|
| +-------->| |
| | +---->| |----+
| | | +--------+ |
| | | |
Action| State| | Reward | Action
List | | | |
| | | +-----------+ |
| | '---|Environment|<--+
| +-------| |
+--------------| |
+-----------+
クラス図で書くと以下のようになります。
RLのクラス図2
+--------+ 1 +--------------+
|RL Agent|--------|Value Function|
| | +--------------+
| | 1 +--------------+ 1 +-----+
| |--------|Environment |------|State|
| | |(Singleton) | +-----+
+--------+ | | 1 +-----------+ * +-------+
| |------|Action List|---------|Action |
+--------------+ +-----------+ +-------+
2playerゲームに適応してみる。
上記を2playerのターン制ゲーム(3目並べ、ハムレット、オセロなど)に適応させることを考えると、あらたにゲーム進行役のクラスが必要となります。
2player gameのクラス図
+---------+ +--------+ 1 +--------------+
|Game Host| 2 |RL Agent|--------|Value Function|
| |-------| | +--------------+
| | | | 1 +--------------+ 1 +-----+
+---------+ | |--------|Environment |------|State|
| | |(Singleton) | +-----+
+--------+ | | 1 +-----------+ * +-------+
| |------|Action List|---------|Action |
+--------------+ +-----------+ +-------+
上記の図を見ていると、EnvironmentとRL Agentの橋渡し(State, Action List, Reward, Actionのやり取り)は、Game Hostの役目にしたほうがよさそうです。
2player gameのクラス図2
+---------+ +--------+ 1 +--------------+
|Game Host| 2 |RL Agent|--------|Value Function|
| |-------| | +--------------+
| | +--------+ +--------------+ 1 +-----+
| | 1 |Environment |------|State|
| |-------------------------|(Singleton) | +-----+
+---------+ | | 1 +-----------+ * +-------+
| |------|Action List|---------|Action |
+--------------+ +-----------+ +-------+
次回は、それぞれのクラスの設計に移る予定です。
強化学習/ニューラルネットワークを利用したゲーム制作: ハムレット2
今回は、前回出てきたクラスを肉付けしていきます。設計の方針として、以下のことを考慮するようにします。
- 2playerのボードゲームでplayerが交互に行動をとるようなゲームに対応できる柔軟性を持たせる。
- RL(Reinforcement Learning)のAgent以外に人やその他のアルゴリズムを実装できるよう柔軟性を持たせる。
また、クラスの命名規則は、以下のようにしています。
- Ifxxxxx: インタフェース
- Absxxxx: 抽象クラス
- その他 Hamletxxxxなど: Concreteクラス
それでは、それぞれのクラスのインタフェースを考えていきましょう。
Game Host
- Game Hostは、mainから生成されるこのアプリケーション自身をあらわすクラスとして考えます。
- Game Hostは、ゲームに参加するAgent(player)や、Environentなどを保持しています。(前回のクラス図より)
- Game Hostは、ゲームを進めるため、AgentやEnvironementとの間を取り持ちます。
上記から、mainから呼ばれるメソッドは、
- GameHostにAgent/Environementを初期設定するためのメソッド。
- Gameをスタートさせるためのメソッド。
が必要そうです。 以下のように簡単に書いてみます。
IfGameHost
+------------------------------------------+
| << interface >> |
| IfGameHost |
+------------------------------------------+
+------------------------------------------+
| public void initialization(Agent, Agent) |
| pubilc void startGame() |
+------------------------------------------+
しかし、このままではmainがAgentを知っていなければなりません。個人的には、mainは、"Agentの種類"は知っているが、"Agent Class"は知らない。という状態にしたいと思います。これによって、mainが勝手にAgentのメソッドを使用することをなくしたいのです。
そこで、IfGameHostをFactory Methodにし、同時にGameHostの抽象クラスを設計してしまいます。
IfGameHost2, AbsGameHost
+--------------------------------------------+
| << interface >> |
| IfGameHost |
+--------------------------------------------+
+--------------------------------------------+
| public void initialization() |
| public void initGameAgent(String, String) |
| pubilc void startGame() |
+--------------------------------------------+
+----------------------------------------------+
| << abstract >> |
| AbsGameHost implements IfGameHost |
+----------------------------------------------+
| protected Agent _player[] |
| protected Environment _environement |
| protected Map _agentList |
+----------------------------------------------+
| public AbsGameHost() | <- Call initialization();
| public abstract void initialization() | <- GameHostのConcreteクラスがAgentの全種類を
| | singupPlayerを呼び出して、signupする。
| protected void signupPlayer(String, String) | <- Call _agentList.put();
| public void initGameAgent(String, String) | <- _agentListから該当クラスを見つけ、
| | Instanciateし、_player[]に代入。
| pubilc void startGame() | <- gameを進めるメインのメソッド。
+----------------------------------------------+
Environment
- Environmentは、現在の状態(State)を保持しています。
- Actionを受け取り、状態をupdateします。
- Actionに対する報酬を計算します。
- 次に取れるActionのリストをリストアップします。
- ゲームが継続可能かどうか判断します
- ゲーム中に一つだけ存在します。(Singleton)
本来なら、拡張性を考え、いろいろなゲーム毎にEnvironmentのサブクラスをインプリするのですが、Singletonなので、サブクラスを作成するのが非常に面倒です。
今回は、サブクラス化は、あきらめてConcreteクラスをいきなり作る方法でインプリすることにします。
インタフェースですが、以下のようなものが必要となりそうです。
IfEnvironment
+----------------------------------------------+
| << interface >> |
| IfEnvironment |
+----------------------------------------------+
+----------------------------------------------+
| public static Environement getEnvironment() | <- Singleton用インスタンス取得
| public void initState() | <- State(盤面の状態)の初期化
| public void updateToNewState(player, Action) | <- ActionによるStateの更新
| pubilc double getReward() | <- 報酬の計算
| pubilc ActionArray possibleActions() | <- 次のターンで取り得るAction
| pubilc boolean isContinuable() | <- ゲーム終了かどうか
| |
| pubilc State getCurrentStateCopy() |
+----------------------------------------------+
最後の"getCurrentStateCopy"は、強化学習(Reinforcement Learning)の学習において、State毎の価値(Value)を学習するということがあるため、Agentで使用する"State"を得るために入れてあります。
State
- Stateは、盤面の状態を保持します。
- Stateは、Environmentからの要求により、盤面の状態の変更を行います。
IfState
+----------------------------------------------+
| << interface >> |
| IfState |
+----------------------------------------------+
+----------------------------------------------+
| public void initState() | <- Stateの初期化Game開始時に呼ばれる
| |
| public State getNewState(player, Action) | <- Action後の盤面のコピーを返す
| | (現状の盤面は、変化しない)
| |
| public boolean equals(Object) | <- Stateオブジェクトの同一性(override)
| pubilc int hashCode(); | <- StateのHashTable保持用(override)
+----------------------------------------------+
真ん中の"getNewState(player, Action)"は、強化学習においては、自分が手を打った後の盤面に対して価値(value)の学習を行うため、実際の盤面を変更せずに"手を打った後の盤面のコピー"が必要となるためいれています。
下の2つは、強化学習においてState毎に価値(value)の学習を行いますが、同一Stateかどうかの判断を行う場合に必要となります。
Environmentから使用するメソッドも含めて抽象クラスを書くと、下記のようになります。
AbsState
+--------------------------------------------------------+ | << abstract >> | | AbsState | +--------------------------------------------------------+ +--------------------------------------------------------+ | public abstract void initState() | <- Stateの初期化Game開始時に呼ばれる | public State getNewState(player, Action) | <- Action後の盤面のコピーを返す | | (現状の盤面は、変化しない) | | : getCopy()-->updateToNewState(p,A) | public abstract boolean equals(Object) | <- Stateオブジェクトの同一性(override) | pubilc abstract int hashCode(); | <- StateのHashTable保持用(override) | | | protected abstract void updateToNewState(player,Action)| | protected abstract double getReward() | <- 報酬の計算 | protected abstract ActionArray possibleActions() | <- 次のターンで取り得るAction | protected abstract boolean isContinuable() | <- ゲーム終了かどうか | protected abstract State getCopy() | +--------------------------------------------------------+
AbState側に、possibleActions()や、isContinuable()などをインプリすることにより、、Environment側ではAbStateに委譲するだけというインプリにしています。
このとき、EnvironmentおよびStateからのみ呼ばれているものは"protected"にして保護しておきます。
Action/ActionList
ActionとActionListは、典型的なデータオブジェクトで、getter/setter以外には、メソッドを持ちません。
これらのクラスは、最初からConcreteクラスとしてインプリすることにし、インタフェース・抽象クラスの設計をしません。
(というか、データオブジェクトの抽象クラスの作成ってできるの？)
RL Agent
- Agentは、現状のState(盤面の状況)に対し、可能なAction(ActionList)の中から、実施するActionを返します。
- Agentは、Actionにより得られた報酬(reward)により学習します。
IfAgent
+---------------------------------------------+
| << interface >> |
| IfAgent |
+---------------------------------------------+
+---------------------------------------------+
| public void initAgent() | <- Agentの初期化Game開始時に呼ばれる
| public Action returnAction(ActionList,State)| <- Actionの選択肢リストと現在のState
| | から次のActionを返す
| pubilc double setReward() | <- 報酬の受け取りと学習
+---------------------------------------------+
次回は、強化学習の肝であるValueFunction(価値関数)に関してです。
強化学習/ニューラルネットワークを利用したゲーム制作: ハムレット3
今回は、ValueFunctionに関してです。まずは、強化学習におけるValueFunctionの流れを見てみます。
IfAgent
Case: 後攻の場合
(最初の状態)
[ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]
<oldState>
|
|
相手の手
|
+-----------------------+-----------------------+--------------------
(自分の手の選択) | | |
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] ......
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[2][ ][ ][1][ ][ ][ ] [ ][2][ ][1][ ][ ][ ] [ ][ ][2][1][ ][ ][ ]
<newState>| (選択された手)
|
相手の手
| <reward(報酬)を得て、valueFunctionのアップデート(学習)>
|
| <oldState=newState>
+-----------------------+-----------------------+--------------------
(自分の手の選択) | | |
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ] ......
[ ][ ][ ][1][ ][ ][ ] [ ][2][ ][1][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ]
[2][2][ ][1][ ][ ][ ] [ ][2][ ][1][ ][ ][ ] [ ][2][2][1][ ][ ][ ]
<newState>| (選択された手)
|
相手の手
|
:
上記図において、ValueFunctionは、２つの働きをしています。
- 手の選択のため、取り得る手から"価値の最も高い"手を選択する。
- Actionにより得られたreward(報酬)を元に、手の価値をアップデートする(学習)。
なお、この方式は、TD(0)と呼ばれるもので、これ以外にも"Action(行動)とState(状態)の組"で学習するものや"価値を評価する関数と行動を選択する関数を別にもつもの"などがあります。
今回は、"Stateに対してあるActionを取った場合、次のStateが特定できる"ため、Stateのみの関数で実装します。(TD方式)
- 手の選択のため、取り得る手から"価値の最も高い"手を選択する。
このためには、現在のStateとActionListを渡すことにより、Action選択後の価値がもっとも高いものを選ぶメソッドが必要となります。
インプリの仕方として今回は、
ActionListのそれぞれに対して: 現状StateにActionを行った場合のStateを得る。 新しいStateの価値を自分自身の価値関数から得る。 得られた価値の最も高いものを出力 - Actionにより得られたreward(報酬)を元に、手の価値をアップデートする(学習)。
この学習は、以下の式をもとにインプリされます。
- V(s)<-V(s) + α[reward + γV(s')-V(s)] :TD(0)方式
上記の図の書き方に読み替えると、
- "oldStateの価値"="oldStateの価値" + α["reward" + γ"newStateの価値"-"oldStateの価値"]
これにより、oldStateの価値は、Action後の価値(newState)にActionにより選られた報酬(reward)を足したものに近づいていくことになります。
但し、いきなり"oldStateの価値 = reward + newStateの価値"としてしまうと学習が発散してしまう可能性があるため、徐々に学習を行うよう"α, γ"といったパラメータで学習効率を設定しています。ValueFunctionのインタフェースは、以下のようになります。
IfAgent
+-------------------------------------------------+ | << interface >> | | IfRLValueFunction | +-------------------------------------------------+ +-------------------------------------------------+ | pubilc viod getStateValue(State) | <- Stateの価値を得る | pubilc void updateStateValue(State,State,reward)| <- oldState,newState,reward +-------------------------------------------------+ ->価値関数更新次回は、インプリに進みたいと思います。
ページトップに戻る トップページに戻る - V(s)<-V(s) + α[reward + γV(s')-V(s)] :TD(0)方式