unit 6: ユーティリティに基づくプロダクションの選択と...

Unit 6: ユーティリティに基づくプロダクションの選択とユーティリティの学習 Selecting Productions on the Basis of Their Utilities and Learning these Utilities ここまでの間に時々，競合解消において，あるプロダクションが他のプロダクションより選ばれやすいようにプロダクションのパラメータを設定してきました．ここでは，プロダクションのユーティリティがどのように計算され，競合解消で使われるのかを⾒ていきます．そして，それらのユーティリティがどのように学習されるかも⾒ていきます． 6.1 ユーティリティの理論 (The Utility Theory) 各プロダクションは，それぞれに関連づけられたユーティリティを持っていて，前までのいくつかのユニットで⾒てきたように直接的に設定することができます．活性化のように，ユーティリティにはノイズが加えられます．ノイズは，パラメータ:egsで設定された，ユーティリティのノイズパラメータ sでコントロールされます．ノイズは，平均 0，分散が次の式のロジスティック分布に基づき分布しています

𝜎! =𝜋!

3 𝑠!

もし，期待されるユーティリティの値が Uj のいくつかのプロダクションが競合するならば，プロダクション iが選択される確率は次の式で表されます

𝑃𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦(𝑖) =𝑒" √!$⁄

∑ 𝑒&! √!$⁄'

総和 jは，現在条件が満たされている全てのプロダクションの合計です．しかし，この式はプロダクションの選択の過程を描写しているだけです．これは実際にはシステムで計算されません．(ノイズが⾜された後に) もっとも⾼いユーティリティを持つプロダクションが発⽕するために選択されます． 6.2 棒の⻑さ合わせの例 (Building Sticks Example) これらのアイデアを，問題解決の例で⽰します．Lovett (1998) は，下の図に⽰されるような棒の⻑さ合わせ問題を解決する参加者を観察しました．これは，すでに多くの実験がなされていた Luchinsの⽔瓶問題の同型問題です．参加者は 3種類の⻑さの棒を制限なく与えられ，特定の⻑さのターゲットの棒を作り出すように教⽰されます．彼らが選択可能な 2つの基本的な⽅略があります．⽬標の⻑さより短い棒から始め，棒を⾜していく⽅略 (Luchinsの⽔瓶問題でいうところの⾜し算⽅略) と，⻑い棒から初めて，⽬標の⻑さになるまで様々な⻑さの棒の分だけ “切り落とし” ていく⽅略です (引き算⽅略)．前者を不⾜ (undershoot) ⽅略，後者を過剰 (overshoot) ⽅略と呼び

ます．参加者は⼭登り法を⽤い，ターゲットに最も近い⻑さの棒を最初の棒に選択する強い傾向を⾒せました．

Lisp では bst.lisp ファイルをロードすることにより，Python では bst ファイルをインポートすることにより，ACT-Rモデルが働くように書かれたこの課題を⼀通り体験できます．Lispの bst-test関数か Pythonの bstモジュールの test関数は，何ペアの問題のサンプルを提⽰するかを⽰す 1 つのパラメータと，⼈とモデルのどちらが課題を⾏うか⽰すオプショナパラメータをとります．デフォルトはモデルを実⾏します．⾃分で問題を 1ペア体験して⾒たい場合には以下のどちらかを使います: ? (bst-test 1 t) >>> bst.test(1,True) 戻り値は 2つの数字のリストです．それぞれ，ペアの 1つ⽬と 2つ⽬の問題で過剰⽅略を何回使ったかを⽰しています．実験は次のような⾒た⽬です:

ACT-R Tutorial 20-Aug-19 Unit Six

undershoot strategy and the second the overshoot strategy. Subjects show a strong tendency to hillclimb and choose as their first stick a stick that will get them closest to the target stick.

INITIAL STATE

desired:

current:

building:

UNDERSHOOT UNDERSHOOTOVERSHOOT

desired:

current:

building:

desired:

current:

building:

desired:

current:

building:

possible first moves

a b c

a b c a b c a b c

You can go through a version of this task that was written to work with ACT-R models by loading the bst.lisp file in Lisp or importing the bst file in Python. The function bst-test in Lisp or test in the bst module in Python takes one parameter indicating how many sample pairs of problems to present and an optional second parameter which indicates whether a person or model is performing the task. The default is to run the model, so to run yourself through one pair of problems you would use one of these:

? (bst-test 1 t)

>>> bst.test(1,True)

The return value will be a list of two numbers indicating how many times you used the overshoot strategy on the first and second problem from the pair respectively.

The experiment will look something like this:

2

ACT-R Tutorial 20-Aug-19 Unit Six

To do the task you will see four lines initially. The top three are black and correspond to

the building sticks you have available. The fourth line is green and that is the target

length you are attempting to build. The current stick you have built so far will be blue

and below the target stick. You will build the current stick by pressing the button to the

left of a stick you would like to use next. If your current line is shorter than the target the

new stick will be added to the current stick, and if your current line is longer than the

target the new stick will be subtracted from the current stick. When you have

successfully matched the target length the word “Done” will appear below the current

stick and you will progress to the next trial. At any time you can hit the button labeled

Reset to clear the current stick and start over.

As it turns out, both of the problems presented in that test set can only be solved by the

overshoot strategy. However, the first one looks like it can be solved more easily by the

undershoot strategy. The exact lengths of the sticks in pixels for that problem are:

A = 15 B = 200 C = 41 Goal = 103

The difference between B and the goal is 97 pixels while the difference between C and

the goal is only 62 pixels – a 35 pixel difference of differences. However, the only

solution to the problem is B – 2C – A. The same solution holds for the second problem:

A = 10 B = 200 C = 29 Goal = 132

But in this case the difference between B and the goal is 68 pixels while the difference

between C and the goal is 103 pixels – a 35 pixel difference of differences in the other

direction. You can run the model on these problems and it will tend to choose

undershoot for the first about 75% of the time and overshoot for the second about 75% of

the time. You can run the model multiple times using the bst-test or test function with the

number of pairs to run the model through to see the results for yourself. If you only run

3

課題を⾏うためには，まず 4 つの線を⾒ます．上の 3 つは⿊線で，使うことのできる棒に対応しています．4つ⽬の線は緑で，⻑さ合わせをするターゲットの⻑さです．それまで作ってきた現在の棒は⻘⾊でターゲットの棒の下に表⽰されます．次に使いたい棒の左側のボタンを押すことにより，棒を組み合わせていくことができます．もし，現在の⻑さがターゲットより短ければ，新しい棒が現在の棒に付け⾜されます．もし，現在の⻑さがターゲットより⻑ければ，新しい棒の分が現在の棒から引かれます．うまくターゲットと⻑さを合わせられると，“Done” の⽂字が現在の棒の下に表⽰され，次の試⾏へ進みます．Reset のボタンを押せばいつでも，現在の棒をクリアして，最初に戻ることができます．

結論から⾔うと，このテストセットで提⽰される問題はどちらも過剰⽅略で解くことができます．しかし，最初の⼀つは不⾜⽅略の⽅がより簡単に解けるように⾒えます．この問題の正確な棒の⻑さはピクセルでこの通りです: A = 15 B = 200 C = 41 Goal = 103 C とゴールの差異は 62 ピクセルである⼀⽅，B とゴールの差異は 97 ピクセルです．その違いは 35 ピクセルです．しかし，問題の唯⼀の解決法は B – 2C – Aです．同じ解決法が 2 番⽬の問題でも使えます: A = 10 B = 200 C = 29 Goal = 132 ただし，この場合は Cとゴールの差異は 103 ピクセルである⼀⽅，Bとゴールの差異は 68 ピクセルです．その違いは反対⽅向に 35 ピクセルです．これらの問題でモデルを実⾏すると，最初の問題では約 75%で不⾜⽅略を，⼆番⽬では約 75%で過剰⽅略を選択する傾向があります．bst-test か test 関数を，モデルを実⾏するペアの数と共に使って何回もモデルを実⾏し，結果を⾒ることができます．もし，1ペアだけモデルを実⾏するときは，⽬に⾒えるウィンドウで課題が実⾏されるので，それを⾒ることができます．しかし，1ペア以上実⾏する場合は，課題をより早く終わらせるために仮想ウィンドウを使います．この課題のモデルは，スクリーンのエンコードと棒の選択の多くのプロダクションを含みます．しかし，モデルの重要な⾏動は，過剰⽅略と不⾜⽅略のどちらを適⽤するかを決定する 4つのプロダクションにコントロールされています． (p decide-over

=goal> isa try-strategy state choose-strategy strategy nil

=imaginal> isa encoding under =under over =over

!eval! (< =over (- =under 25)

==> =imaginal> =goal>

state prepare-mouse strategy over

+visual-location> isa visual-location kind oval value "b")

(p force-over

=goal> isa try-strategy state choose-strategy

- strategy over ==>

=goal> state prepare-mouse strategy over

+visual-location> isa visual-location kind oval value "b")

(p decide-under

=goal> isa try-strategy state choose-strategy strategy nil

=imaginal> isa encoding over =over under =under

!eval! (< =under (- =over 25)) ==>

=imaginal> =goal>

state prepare-mouse strategy under

+visual-location> isa visual-location kind oval value "c")

(p force-under

=goal> isa try-strategy

state choose-strategy - strategy under

==> =goal>

state prepare-mouse strategy under

+visual-location> isa visual-location kind oval value "c")

重要な情報は，イマジナルバッファのチャンクの over スロットと under スロットにあります．over スロットは棒 b とターゲットの棒のピクセルの差異をエンコードし，underスロットはターゲットと棒 cのピクセルの差異をエンコードします．値は問題をエンコードするそれ以前のプロダクションで計算されます．もし，モデルがこれらの差のうちのどちらかの⽅がターゲットに近いとわかれば (他⽅より 25 ピクセル以上近い)，⽅略を選択するために decide-underまたは decide-overプロダクションが発⽕できます．全ての状況で，force-underと force-overの他の 2つのプロダクションが適⽤可能です．そのため，もし 2つの棒がターゲットの棒にどれほど近いかに明らかな違いがあれば，適⽤される可能性のある 3つのプロダクションがあります．もし，違いがなければ，2 つの force プロダクションだけが適⽤される可能性を持ちます．プロダクション間の選択は，それぞれに紐づけられたユーティリティにより決定されます．ACT-R 環境の Procedural ツールか sppコマンドを使って⾒ることができます: ? (spp force-over force-under decide-over decide-under) >>> actr.spp('force-over','force-under','decide-over','decide-under') もしモデルがまだ課題をなにも遂⾏していなければ，この出⼒はこのようになります: Parameters for production FORCE-OVER:

:utility NIL :u 10.000 :at 0.050 :reward NIL :fixed-utility NIL

Parameters for production FORCE-UNDER: :utility NIL :u 10.000 :at 0.050 :reward NIL :fixed-utility NIL

Parameters for production DECIDE-OVER:

:utility NIL :u 13.000 :at 0.050 :reward NIL :fixed-utility NIL

Parameters for production DECIDE-UNDER: :utility NIL :u 13.000 :at 0.050 :reward NIL :fixed-utility NIL

:uのラベルで表されるプロダクションの現在のユーティリティの値は，sppコマンドを使って設定することができます: (spp decide-over :u 13) (spp decide-under :u 13) (spp force-over :u 10) (spp force-under :u 10)

少なくとも最初の時点では，単により⻑さの近い棒が好まれるということに基づき決定されるため，2つの forceプロダクションのパラメータ:uは 10に，2つの decideプロダクションは 13に設定されています．sppの出⼒の中の:utilityの値は，競合解消において，直近で計算された，ノイズを含むそのプロダクションのユーティリティの値を⽰しています．上のモデルを実⾏する前の出⼒の nil の値は，プロダクションがまだ使われていないことを⽰しています．もし，あなたが課題を通してモデルを実⾏し，パラメータをチェックすると，状況に適合し，競合解消で選択されたであろうプロダクションでは，このようなノイズの乗ったユーティリティの値を⾒ることとなります: Parameters for production FORCE-OVER:

:utility 8.893 :u 10.000 :at 0.050 :reward NIL :fixed-utility NIL

Parameters for production FORCE-UNDER: :utility 15.080 :u 10.000 :at 0.050 :reward NIL :fixed-utility NIL

Parameters for production DECIDE-OVER: :utility 15.434 :u 13.372

:a 0.050 :reward NIL :fixed-utility NIL

Parameters for production DECIDE-UNDER: :utility NIL :u 13.000 :at 0.050 :reward NIL :fixed-utility NIL

ここで，これらのプロダクションが，2つの問題の場合にモデルでどのように適⽤されるかについて考えます．underと overの差異は 35 ピクセルを超えるため，両⽅の問題で，適合する 1つの decideプロダクションと 2つの forceプロダクションがあります．上記の式を使って各プロダクションの選択確率を考えてみます．モデルのノイズパラメータ sの値は 3とします．まず，decideプロダクションの確率を考えます:

𝑃𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦(𝑑𝑒𝑐𝑖𝑑𝑒) = 𝑒() *.!*⁄

𝑒() *.!*⁄ + 𝑒(, *.!*⁄ + 𝑒(, *.!*⁄

=𝑒) *.!*⁄

𝑒) *.!*⁄ + 𝑒, + 𝑒,= .504

同様に，2つの forceプロダクションの確率は.248となります．そのため，forceプロダクションが発⽕して，モデルがその⾒た⽬に合わない⽅のやり⽅で問題を解決しようとする確率は.248の確率です． 6.3 ユーティリティの学習 (Utility Learning) これまでは，プロダクションのパラメータが静的な状況を考えてきました．プロダクションのユーティリティは，モデルが実⾏されるにつれ，モデルにより受け取られる報酬 (reward) に基づき学習もされます．ユーティリティ学習ができるようにされている時，プロダクションのユーティリティは単純な積分器モデル (e.g. see Bush & Mosteller, 1955) により更新されます．Ui(n-1)を n-1 回⽬の適⽤の後のプロダクションi のユーティリティ，Ri(n)が n 回⽬の適⽤でプロダクションの受け取る報酬であるとするならば，n 回⽬の適⽤の後のユーティリティ Ui(n)は:

U- (n) = U- (n − 1) + α[𝑅"(𝑛) − 𝑈"(𝑛 − 1)] となり，ここで αは学習率を⽰し，⼤体は.2に設定されています (モデルの:alphaパラメータを調整することにより変更可能です)．これは基本的には Rescorla-Wagnerの学習規則 (Rescorla & Wagner, 1972) でもあります．この式によると，プロダクションのユーティリティは，プロダクションが受け取る平均報酬にあうまで徐々に調整されていきます．

報酬に関して⾔っておくべき 2つのことがあります．報酬はいつでも起こすことが可能であり，必ずしも特定のプロダクションと関連づいてはいません．また，報酬が伝えられる前に，いくつかのプロダクションが発⽕しています．プロダクション iが受け取る報酬 Ri(n)は，受け取られた外的報酬からプロダクション iの選択から報酬までの時間を引いたものです．遠いプロダクションほど報酬は⼩さくなります．これは強化学習の時間的な割引のようなものですが，ACT-Rアーキテクチャにおいてより頑健であることがわかっています (⼀般的に頑健であるというわけではありません)．この強化は，現在の報酬から 1 つ前の報酬までの間に選択された全てのプロダクションへと遡ります．

報酬をモデルに与える 2つの⽅法があります: trigger-rewardコマンドは報酬を与えるためにいつでも使うことができます．また，報酬はプロダクションに付随させることもでき，その報酬は対応するプロダクションが発⽕した後に適⽤されます．プロダクションに付随する報酬は，モデルが顕在的に処理する状況に報酬が対応づけられるときに，モデルに報酬を与えるために便利です．例えば，棒の⻑さ合わせ課題では，報酬はモデルが問題をうまく完遂した時とリセットして最初に戻った時に与えられます．そして，それらの状況を扱うプロダクションが存在します: read-doneは問題の完遂を検出し，pick-another-strategyはリセットの後の選択を⾏います．これらのプロダクションに報酬の値を設定することにより，これらの結果に報酬を割り当てることができます: (spp read-done :reward 20) (spp pick-another-strategy :reward 0)

read-done が発⽕した時，20 の報酬を発⽕より前のプロダクションへ拡散します．もちろん，報酬までの時間が報酬から引かれるため，繋がりの前の⽅のプロダクションは⼩さな値を受け取ります．もし，pick-another-strategyが発⽕すると，0の報酬が拡散されます．つまり，それより前のプロダクションは，実際は，時間が⽴っている分，負の報酬を受け取ります．プロダクションのつながりが⾏き詰まりを引き起こし，pick-another-strategyが発⽕し，解決につながるプロダクションの異なる繋がりが発⽕し，read-done が発⽕する時に起こることを考えてみてください．報酬は前の報酬後までしか届かないので，read-done に紐づけられた報酬は，pick-another-strategy よりも後に発⽕したプロダクションまで拡散し，それ以上は拡散しません．read-done プロダクションは⾃分からの報酬を受け取りますが，pick-another-strategyは⾃⾝からの報酬しか受け取らないため，read-done の報酬を受け取らないことに注意してください． 6.4 棒の⻑さ合わせ課題の学習 (Learning in the Building Sticks Task) 以下は，Lovett & Anderson (1996) により報告された，棒の⻑さ合わせ課題の実験におけるテストセットの各問題の棒の⻑さと過剰⽅略の選択の確率です:

a b c Goal %OVERSHOOT 15 250 55 125 20 10 155 22 101 67 14 200 37 112 20 22 200 32 114 47 10 243 37 159 87 22 175 40 73 20 15 250 49 137 80 10 179 32 105 93 20 213 42 104 83 14 237 51 116 13 12 149 30 72 29 14 237 51 121 27 22 200 32 114 80 14 200 37 112 73 15 250 55 125 53 これらの問題の⼤部部分は不⾜⽅略で解決できるかのように⾒え，いくつかの場合は，ピクセルの差異は 25以上です．しかし，ほとんどの問題は過剰⽅略でしか解決できません．最初と最後の問題は同⼀であり，不⾜⽅略で解決する問題のように⾮常に⾒えるため，興味深いです．これは，過剰⽅略と不⾜⽅略のどちらでも解ける唯⼀の問題です．最初の問題では 20%の参加者しか過剰⽅略を使って解決していません．しかし，同じ問題が最後に提⽰された時には，53%の参加者が過剰⽅略を使っています．

上のテスト試⾏を実⾏したモデルは，実験全体を遂⾏することもでき，:uパラメータを tに設定することにより可能となるユーティリティ学習メカニズムを通して，データと似たようなパフォーマンスを⽰します．Lispの bst-experiment関数と Pythonのbstモジュールの experiment関数は，実験を通してモデルを複数回実⾏し，結果を平均します．以下は 100 回の実験の繰り返しを平均した，モデルのパフォーマンスを⽰しています: CORRELATION: 0.803 MEAN DEVIATION: 17.129 Trial 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

23.0 60.0 59.0 70.0 91.0 42.0 80.0 86.0 59.0 34.0 33.0 22.0 54.0 72.0 56.0 DECIDE-OVER : 13.1506 DECIDE-UNDER : 11.1510 FORCE-OVER : 12.1525 FORCE-UNDER : 6.5943

重要なプロダクションの各実験の実⾏を⾏った後のユーティリティパラメータの平均値も出⼒されます．⾒てわかるように，2つの overプロダクションのユーティリ

ティは増加している⼀⽅，underプロダクションのユーティリティは減少しています．平均して，force-overプロダクションの⽅が decide-underプロダクションより少し値が⾼いです．ユーティリティのこの変化が過剰⽅略の選択の増加傾向を作り出します．このモデルではユーティリティのトレース，:ultパラメータもオンにしてあります．前のユニットで⽰した活性化のトレースと同じように働きます．もし，:vパラメータを tに設定してモデルのトレースを使えるようにしておけば，報酬がモデルに与えられるたびに，報酬に影響される全てのプロダクションにおけるユーティリティの変化を⽰すトレースが⽰されます．以下は試⾏をうまく完遂したことによる正の報酬が与えられた場合の例です:

5.062 UTILITY PROPAGATE-REWARD 20 Utility updates with Reward = 20.0 alpha = 0.2

Updating utility of production START-TRIAL U(n-1) = 0.0 R(n) = 14.938 [20.0 - 5.062 seconds since selection] U(n) = 2.9876

Updating utility of production FIND-NEXT-LINE U(n-1) = 0.0 R(n) = 14.988 [20.0 - 5.012 seconds since selection] U(n) = 2.9976

Updating utility of production ATTEND-LINE U(n-1) = 0.0 R(n) = 15.038 [20.0 - 4.962 seconds since selection] U(n) = 3.0076 Updating utility of production ENCODE-LINE-A

U(n-1) = 0.0 R(n) = 15.173 [20.0 - 4.827 seconds since selection] U(n) = 3.0346


Updating utility of production ATTEND-LINE U(n-1) = 3.0076 R(n) = 15.273 [20.0 - 4.727 seconds since selection] U(n) = 5.46068

Updating utility of production ENCODE-LINE-B U(n-1) = 0.0 R(n) = 15.423 [20.0 - 4.577 seconds since selection] U(n) = 3.0846002



Updating utility of production ENCODE-LINE-C U(n-1) = 0.0 R(n) = 15.658 [20.0 - 4.342 seconds since selection] U(n) = 3.1316001


Updating utility of production ATTEND-LINE

U(n-1) = 7.473144 R(n) = 15.757999 [20.0 - 4.242 seconds since selection] U(n) = 9.1301155

Updating utility of production ENCODE-LINE-GOAL U(n-1) = 0.0 R(n) = 15.893 [20.0 - 4.107 seconds since selection] U(n) = 3.1786

Updating utility of production ENCODE-UNDER U(n-1) = 0.0 R(n) = 16.028 [20.0 - 3.972 seconds since selection] U(n) = 3.2056

Updating utility of production ENCODE-OVER U(n-1) = 0.0 R(n) = 16.163 [20.0 - 3.837 seconds since selection] U(n) = 3.2326

Updating utility of production FORCE-UNDER U(n-1) = 10.0 R(n) = 16.213 [20.0 - 3.787 seconds since selection] U(n) = 11.2425995

Updating utility of production MOVE-MOUSE U(n-1) = 0.0 R(n) = 16.263 [20.0 - 3.737 seconds since selection] U(n) = 3.2526002

Updating utility of production CLICK-MOUSE U(n-1) = 0.0 R(n) = 16.713 [20.0 - 3.287 seconds since selection] U(n) = 3.3425999

Updating utility of production LOOK-FOR-CURRENT U(n-1) = 0.0 R(n) = 17.063 [20.0 - 2.937 seconds since selection] U(n) = 3.4126


Updating utility of production ENCODE-LINE-CURRENT U(n-1) = 0.0 R(n) = 17.248 [20.0 - 2.752 seconds since selection] U(n) = 3.4496

Updating utility of production CALCULATE-DIFFERENCE U(n-1) = 0.0 R(n) = 17.383 [20.0 - 2.617 seconds since selection] U(n) = 3.4766

Updating utility of production CONSIDER-C U(n-1) = 0.0 R(n) = 17.433 [20.0 - 2.567 seconds since selection] U(n) = 3.4866002

Updating utility of production CHOOSE-C U(n-1) = 0.0 R(n) = 17.568 [20.0 - 2.432 seconds since selection] U(n) = 3.5136







Updating utility of production CONSIDER-C U(n-1) = 3.4866002 R(n) = 18.238 [20.0 - 1.762 seconds since selection] U(n) = 6.43688

Updating utility of production CONSIDER-A U(n-1) = 0.0 R(n) = 18.373 [20.0 - 1.627 seconds since selection] U(n) = 3.6746

Updating utility of production CHOOSE-A U(n-1) = 0.0 R(n) = 18.508 [20.0 - 1.492 seconds since selection] U(n) = 3.7015998







Updating utility of production CHECK-FOR-DONE U(n-1) = 0.0 R(n) = 19.765 [20.0 - 0.235 seconds since selection] U(n) = 3.9529998

Updating utility of production FIND-DONE U(n-1) = 0.0 R(n) = 19.815 [20.0 - 0.185 seconds since selection] U(n) = 3.963

Updating utility of production READ-DONE U(n-1) = 0.0 R(n) = 19.95 [20.0 - 0.05 seconds since selection] U(n) = 3.9900002

6.5 チャンクタイプの能⼒ (Additional Chunk-type Capabilities) このユニットの練習課題について論じる前に，このモデルでこれまでのユニットとは異なることをしているようないくつかのプロダクションを⾒ていきます． 6.5.1 デフォルトのチャンクタイプのスロットの値 (Default chunk-type slot values)

encode-line-goal と click-mouse プロダクションの⾏動を⾒てみると，視覚とマニュアルバッファーへのリクエストでこれまで⾒てきた cmd スロットが⽋けていて，isaを使ってチャンクタイプを宣⾔しているだけのように⾒えます: (p encode-line-goal ...

==> ...

+visual> isa move-attention screen-pos =c)

(p click-mouse ...

==> ...

+manual> isa click-mouse)

ここまで，isa 宣⾔はオプションで宣⾔され，リクエストや条件の⼀部ではないとされてきました．もしそうであれば，視覚とマニュアルリクエストは，⾏うべき⾏動を⽰すために cmd スロットが指定されることが必要であるはずなのに，これらのリクエストはどのように正しい⾏動をできるのでしょうか？この質問への回答は，チャンクの⽣成と条件の指定およびプロダクションの⾏動において，isa でチャンクタイプを宣⾔している時に起こる追加のプロセスがある，です．この追加のプロセスは，チャンクタイプを⽣成する時にスロットのデフォルトの値を⽰す能⼒によります．ここまで，チャンクタイプを作る時には，それが含むスロットのセットだけを指定してきました．しかし，それに加えて，特定のスロットのデフォルトの最初の値を指定することができます．もし，チャンクタイプにスロットがデフォルトで値を持っていることが⽰されているなら，チャンクタイプが宣⾔された時，チャンクの定義やプロダクションの記述で値が指定されていないデフォルトの値を持つスロットは，⾃動的にデフォルトの値を持ちます．

チャンクタイプでスロットにデフォルトの値を指定するには，スロットの名前だけではなく，2つのアイテムを持つリストをスロットに指定する必要があります．最初のアイテムがスロットの名前，2 番⽬のアイテムがデフォルトの値です．以下は参考となるいくつかのチャンクタイプの例です:

(chunk-type a slot) (chunk-type b (slot 1)) (chunk-type c slot (slot2 t))

チャンクタイプ bはデフォルトの値 1を slotという名前のスロットに持っており，チャンクタイプ cは slot2という名前のスロットにデフォルトの値 tを持っています．もし，これらのチャンクタイプを指定してチャンクを作れば，いくつかのチャンクはスロットにデフォルトの値を持ち，別のチャンクは値を持たないでしょう．これらのスロットを指定しなければ，このようにデフォルトの値が与えられます: ? (define-chunks (c1 isa a)

(c2 isa b) (c3 isa b slot 3) (c4 isa c) (c5 isa c slot2 nil))

? (pprint-chunks C1 C2 C3 C4 C5) C1 C2

SLOT 1 C3

SLOT 3 C4

SLOT2 T C5 デフォルトの値を持つスロットは，スロットに特定の値を指定されたチャンクでは

指定された値を持つのに対して，指定しないチャンクはデフォルトの値を持ちます．プロダクションの条件説と⾏動説でも同じ過程が適⽤されます．視覚，モーターモジュールにより，チャンクタイプ move-attentionと click-mouseが作られると，基本的には cmd スロットに次のようなデフォルトの値を持ちます (次のセクションで述べるように実際のチャンクタイプの指定には他にも⾊々あります): (chunk-type move-attention (cmd move-attention) screen-pos) (chunk-type click-mouse (cmd click-mouse)) そのため，このリクエストは:

+visual> isa move-attention screen-pos =c

以下と同じです:

+visual> cmd move-attention screen-pos =c

そして， ACT-R Environment の Procedural viewer を使って，または，pp (print

production) コマンドを使って，encode-line-goal に対して⼿続き的モジュールの持つ実際のプロダクションの表象を⾒ることにより知ることができます: ? (pp encode-line-goal) (P ENCODE-LINE-GOAL

=GOAL> STATE ATTENDING

=IMAGINAL> C-LOC =C GOAL-LOC NIL

=VISUAL> SCREEN-POS =POS WIDTH =LENGTH LINE T

?VISUAL> STATE FREE

==> =IMAGINAL>

GOAL-LOC =POS LENGTH =LENGTH

=GOAL> STATE ENCODE-UNDER

+VISUAL> SCREEN-POS =C CMD MOVE-ATTENTION

)

元の定義のどの isa 宣⾔も実際のプロダクションの表象の⼀部ではなく，視覚バッファーへのリクエストに cmdスロットが含まれていることがわかります同じことが click-mouseプロダクションのマニュアルリクエストにも⾔えます:

(P CLICK-MOUSE

=GOAL> STATE MOVE-MOUSE

?MANUAL> STATE FREE

==> =GOAL>

STATE WAIT-FOR-CLICK +MANUAL>

CMD CLICK-MOUSE

) 6.5.2 チャンクタイプの階層 (Chunk-type hierarchy) では，encode-line-goal と read-done プロダクションの LHS にある，いくつかの isa

宣⾔の定義を⾒ていきます． (p encode-line-goal

=goal> isa try-strategy state attending

=imaginal> isa encoding c-loc =c goal-loc nil

=visual> isa line screen-pos =pos width =length

?visual> state free

==> =imaginal>

goal-loc =pos length =length

=goal> state encode-under

+visual> isa move-attention screen-pos =c)

(p read-done

=goal> isa try-strategy state read-done

=visual> isa text value "done"

==> +goal>

isa try-strategy state start )

以前のチュートリアルでは，視覚バッファーに格納されているチャンクは visual-

objectという名前のチャンクタイプのスロットで作られていました．しかし，これらのプロダクションの条件節を⾒ると，視覚バッファーの条件で，lineと textというチ

ャンクタイプをそれぞれ指定しています．チャンクタイプ visual-object に加えて，視覚モジュールは，AGI 実験ウィンドウにより使⽤されるオブジェクトに対して，いくつかの他のチャンクタイプを定義しています．これらの他のチャンクタイプ，line と text，は実際はタイプ visual-object のサブタイプです．サブタイプは，その親に当たるチャンクタイプの持つ全てのスロットを含み，追加のスロットや異なるデフォルトのスロット値も持ちます．視覚モジュールが AGI ウィンドウの特徴をチャンクにエンコードする時，チャンクを作るために，実際には lineや textのようないずれかの特定のタイプのスロットを使います全体を通して，各サブタイプがその親に当たるチャンクタイプ (または複数の親の

チャンクタイプ) のスロットとデフォルトの値を継承する，チャンクタイプの任意の階層を作ることができます．チャンクタイプの階層はモデラーがチャンクやプロダクションを指定するのに役⽴ちますが，デフォルトのスロットの値を継承する以外に，そのような階層はモデルにおけるチャンクやプロダクションに何の影響もありません．他のチャンクタイプのサブタイプのチャンクタイプを作るには，サブタイプの定義の中で親のタイプを指定する必要があります．これは，キーワード:include と含まれる親のタイプそれぞれのチャンクタイプの名前を持つリストを含む，サブタイプの名前を指定するリストを使うことによりできます．次のチャンクタイプの定義は，チャンクタイプ a と b を作り，それからチャンクタイプ a のサブタイプのチャンクタイプ c，チャンクタイプ aと b 両⽅のサブタイプのチャンクタイプ dを作ります: (chunk-type a slot1) (chunk-type b slot2) (chunk-type (c (:include a)) slot3) (chunk-type (d (:include a) (:include b)) slot4) 次の定義は上記の定義と等価だと考えるかもしれません:

(chunk-type a slot1) (chunk-type b slot2) (chunk-type c slot1 slot3) (chunk-type d slot1 slot2 slot4) しかし，サブタイプのメカニズムは親のタイプで使えるスロットも拡張するため，そうではありません．サブタイプが親タイプのスロットを継承するだけではなく，親タイプもまたそれらの⼦の持つ全てのスロットへのアクセスを得ます．つまり，階層を使った定義をすると，親タイプを指定しそのサブタイプで定義されたスロットを使うことができます．しかし，単にチャンクが同じ名前のスロットを持つだけではそのようなことはできません．そのため，上記の最初のチャンクタイプのセットを定義すれば，次のようなチャンクの定義が可能です: (define-chunks (isa a slot3 t slot4 10))

チャンクタイプ c と d はチャンクタイプ a のサブタイプで slot3 と slot4 という名前のスロットを持っているためです．しかし，上記の 2つ⽬のセットでは妥当ではないスロットがチャンクの定義に含まれるという警告を受けます．さて，これらのプロダクションで使われているチャンクタイプ line と text に関して，視覚モジュールが持つ関連するチャンクタイプの定義は以下のとおりです: (chunk-type visual-object screen-pos value status color height width) (chunk-type (text (:include visual-object)) (text t)) (chunk-type (line (:include visual-object)) (line t) end1-x end1-y end2-x end2-y) チャンクタイプ lineと textは，visual-objectタイプのサブタイプで，それぞれタイプと同じ名前の新しいスロットをデフォルトの値 tで持ちます．このデフォルトの値により，これらのプロダクションでタイプが text と line のバッファーテストを宣⾔することで，実際のその表象を⾒たときに私たちがそれだとわかるのと同じように，プロダクションに追加の条件を加えます: (P ENCODE-LINE-GOAL

=GOAL> STATE ATTENDING

=IMAGINAL> C-LOC =C GOAL-LOC NIL

=VISUAL> SCREEN-POS =POS WIDTH =LENGTH LINE T ?VISUAL> STATE FREE

==> =IMAGINAL>

GOAL-LOC =POS LENGTH =LENGTH

=GOAL> STATE ENCODE-UNDER

+VISUAL> SCREEN-POS =C CMD MOVE-ATTENTION

) (P READ-DONE

=GOAL> STATE READ-DONE

=VISUAL> VALUE "done"

TEXT T ==>

+GOAL> STATE START

) これらのスロットのテストは直接的に指定することも可能ですが，タイプの宣⾔はよりわかりやすく，古いバージョンの ACT-R (バージョン 6.1より前) でチャンクタイプが使われていた⽅法と⼀貫しています．

上のデフォルトのスロットのセクションでは，デフォルトの値を持っていることを⽰すために，チャンクタイプ move-attention と click-mouse の定義を⽰していましたが，これらのチャンクタイプの実際の定義では，リクエストで使うことができる親のタイプも含まれています: (chunk-type vision-command cmd) (chunk-type (move-attention (:include vision-command))

(cmd move-attention) screen-pos scale) (chunk-type motor-command (cmd "motor action")) (chunk-type (click-mouse (:include motor-command)) (cmd click-mouse)) 6.6 確率的な選択実験における学習 (Learning in a Probability Choice Experiment)

練習課題は，Friedman ら (1964) により⾏われた “確率⼀致 (probability matching)” 実験のモデルを作ることです．ただし，これまでの練習課題と異なり，今回は実験を実装したコードは⽤意されていません．そのため，まず実験部分を書く必要があります．それから，モデルを構築します．これは典型的なモデリングの状況と同じようなやり⽅です．実装すべき実験はとても単純です．以下の基本的な⼿続きを 48 試⾏繰り返します: 1. 参加者は “Choose” と書かれたスクリーンを提⽰されます

2. 参加者は head (表) を表す ‘h’ か tail (裏) を表す ‘t’ のキーを押します

3. キーが押されると，スクリーンはクリアされ，正しい答えを⽰す “Heads” か “Tails” のフィードバックが表⽰されます

4. フィードバックは 1 秒間スクリーンに表⽰され，次の思考が提⽰されます

Friedman らは，head が正しい選択となる確率を tail に対して 10%, 20%, 30%, 40%,

50%, 60%, 70%, 80%, 90%と操作しました (参加者の選択とは独⽴して)．あなたの実験では，90%条件だけを考えます．そのため，実験は 48 試⾏で，その 90%で “Heads” が正しい選択となります．12 試⾏を 1 ブロックとして，多数側の回答を選択した平均割合を得るために，10% (反対の反応) と 90%条件のデータを平均しました．割合は0.664, 0.778, 0.804, 0.818でした．これがあなたのモデルがフィットすべきデータです．

これは heads を選択する割合であり，正しい反応をした割合ではないことは重要です．反応の正しさは重要ではありません．あなたのモデルは headと回答する確率が 50%のチャンスレベルから始めるべきです．それから，実験のフィードバックに基づき，ユーティリティの学習を通して，最初の 12 試⾏を通して，平均の head 反応が 66%に近づくように選択を調整していきます．そして，最後のブロックでは約 82%まで増加するようにします．何回も実験全体を通してモデルを実⾏し (各実験の前にリセットをします)，それらの実⾏のデータを⽐較のために平均するようにします．到達⽬標として，以下が私の書いたモデルの 100 回の実⾏を平均したパフォーマンスです: CORRELATION: 0.994 MEAN DEVIATION: 0.016 Original Current 0.664 0.646 0.778 0.771 0.804 0.826 0.818 0.830 これを達成するために操作したパラメータは，ユーティリティのノイズ (:egsで設定) と反応の成功と失敗に関連づけられた報酬です．ユニットの choice-model.lisp ファイルにあるこの課題の最初のモデルは，ACT-R を最初の状態にクリアするための呼び出しと，中⾝のない choice という名前のモデルの作成部分のみを含みます．モデルの全体を記述する必要があります．課題のための最初のコードは choice.lisp と choice.py ファイルにあります．最初のモデルのロード，実験データ，反応を収集するためのグローバル変数の指定，そして，2 つの関数を含みます．最初の関数は，(これまでの課題の多くでそうだったように) output-keyアクションを監視し，グローバル変数に反応の記録をセットするために使います．Lispでは choice-person，Pythonでは personで呼び出されるもう 1つの関数は，⼈が 1 試⾏を実⾏し，押されたキーを返すために書かれた課題の正しい実装です

choice-model (Lisp)，または，model (Python) という名前で，モデルが 1 試⾏を実⾏するための同じような関数を記述すべきです．パラメータを 1つ持ち，実験全体を何回も実⾏し，実⾏した結果の平均と相関と実験データに対する平均偏差を出⼒する関数も記述します．この関数は，choice-data (Lisp)，data (Python) と名付けてください．この関数は，課題全体を⼈が実⾏できるようにする必要はありません．モデルが実⾏できるようにするだけで⼗分です．

私からの提案は，まず記述された実験が，タイミングを含めて正しく表現できているかを確かめる 1 回分の試⾏の関数を書くことです．それから，課題を正しく遂⾏することができるモデルを書きます．続いて，12 試⾏のブロックを実⾏する関数を書き，試⾏から試⾏に移る時，モデルが正しく動くことを確認します．それから，⼀通りの実験を実⾏するために 4 ブロックを繰り返す関数を書き，テストします．ちゃんと動いたら，実験を複数回実⾏する関数を書きます．他の全てのことがうまく働くこ

とを確認してから，モデルのデータへのフィッティングを⾏うべきです．モデルのための実験を書くには，⼈間が実⾏するための関数ですでに使われているものに加え，これまでのユニットのコードテキストで記されてきた，いくつかの ACT-Rコマンドを使う必要があります．必要なコマンドをここで短く振り返ります．ここまで⾒てきた実験がそれらの使い⽅の豊富な例を提供してくれるでしょう．

reset 関数は ACT-R を初期化します．モデルをモデルファイルで指定された初期の状態に戻します．これは，ACT-R 環境の “Reset” ボタンを押すのとプログラム的に等価です．

run関数は，やることがなくなる，または，指定された時間が過ぎるまでモデルを実⾏するために使われます．モデルを実⾏する最⼤の時間を秒で⽰す，1つのパラメータが必要です．

run-full-time/run_full_time関数は，モデルを決まった時間，実⾏するために使われます．モデルを実⾏する時間を秒で⽰す，1つのパラメータをとります．

install-device/install_device関数は，モデルがやりとりをするデバイスを指定する 1つのパラメータをとり，実験ウィンドウを開く時に返される値がこの課題で対象となるデバイスです．これらの関数に加えて，correlationと mean-deviation/mean_deviation関数も使うでしょう．これらは，2つの値のリストの相関と平均偏差を計算します． 6.6.1 実験の関数の例 (Example experiment functions) ユニット 4 の paired associate 課題は，あなたの実験を作るために⾒るのに良い例です．Lispの do-experiment関数と Pythonの do_experiment関数は，あなたがこの選択課題の試⾏を表すために必要とするものに，⾮常に似た構造を持っています．paired associate の関数は，⼈とモデルの両⽅が実⾏でき，あなたの 1 試⾏の実⾏では必要のない，反応時間の記録と，複数の実⾏のデータの平均をするため，この練習課題で必要になる関数より少し複雑です．それらの関数では，あなたの１試⾏の関数ではモデルに試⾏間で学習を続けさせるために必要としない，reset も呼び出します．あなたは全実験を通して⾏う最初の時にだけ resetを呼び出す必要があります．これらの要素を無視すれば，この課題を⾏うために必要なものと同じ操作の流れを⾏います: ウィンドウを開き，モデルにウィンドウとやりとりをするように命じ，⽂字のアイテムを提⽰し，モデルを実⾏し，スクリーンをクリアし，別の⽂字のアイテムを提⽰し，もう⼀度モデルを実⾏します．これらの関数は以下からコピーできます．関連する操作は緑でハイライトされています． Lisp

(defun do-experiment (size trials human) (reset) (let* ((result nil)

(model (not human)) (window (open-exp-window "Paired-Associate Experiment" :visible human)))

(when model

(install-device window)) (dotimes (i trials)

(let ((score 0.0) (time 0.0))

(dolist (x (permute-list (subseq *pairs* (- 20 size)))) (clear-exp-window window) (add-text-to-exp-window window (first x) :x 150 :y 150) (setf *response* nil) (let ((start (get-time model)))

(if model (run-full-time 5)

(while (< (- (get-time nil) start) 5000) (process-events)))

(when (equal *response* (second x)) (incf score 1.0) (incf time (- *response-time* start)))

(clear-exp-window window) (add-text-to-exp-window window (second x) :x 150 :y 150) (setf start (get-time model)) (if model

(run-full-time 5) (while (< (- (get-time nil) start) 5000)

(process-events))))) (push (list (/ score size) (if (> score 0) (/ time score 1000.0) 0)) result)))

(reverse result))) Python def do_experiment(size, trials, human): actr.reset()

result = [] model = not(human) window = actr.open_exp_window("Paired-Associate Experiment", visible=human) if model:

actr.install_device(window) for i in range(trials):

score = 0 time = 0 for prompt,associate in actr.permute_list(pairs[20 - size:]):

actr.clear_exp_window(window) actr.add_text_to_exp_window (window, prompt, x=150 , y=150) global response response = '' start = actr.get_time(model) if model:

actr.run_full_time(5) else:

while (actr.get_time(False) - start) < 5000: actr.process_events()

if response == associate: score += 1 time += response_time - start

actr.clear_exp_window(window) actr.add_text_to_exp_window (window, associate, x=150 , y=150) start = actr.get_time(model) if model:

actr.run_full_time(5) else:

while (actr.get_time(False) - start) < 5000: actr.process_events()

if score > 0: average_time = time / score / 1000.0

else: average_time = 0

result.append((score/size,average_time)) return result

提供されている choiceファイルでは，⼈が実⾏するための関数が，この課題の 1 試⾏を実⾏するために必要な全体的な構造を⽰しています: ウィンドウを開き，キー押しを記録するためのモニターを作り，選択のプロンプトをスクリーンに加え，プロンプトを消し，それから，フィードバックを表⽰します．しかし，モデルを実⾏する代わりに，⼈がキーを押すのを待ち，その後，実際に 1 秒間の待ち時間を挟みます． Lisp

(defun choice-person () (let ((window (open-exp-window "Choice Experiment" :visible t)))

(add-act-r-command "choice-response" 'respond-to-key-press "Choice task key response")

(monitor-act-r-command "output-key" "choice-response") (add-text-to-exp-window window "choose" :x 50 :y 100) (setf *response* nil) (while (null *response*)

(process-events)) (clear-exp-window window) (add-text-to-exp-window window (if (< (act-r-random 1.0) .9) "heads" "tails") :x 50 :y 100) (let ((start (get-time nil)))

(while (< (- (get-time nil) start) 1000) (process-events)))

(remove-act-r-command-monitor "output-key" "choice-response") (remove-act-r-command "choice-response") *response*))

Python

def person(): global response

window = actr.open_exp_window("Choice Experiment", visible=True) actr.add_command("choice-response", respond_to_key_press,

"Choice task key response") actr.monitor_command("output-key","choice-response") actr.add_text_to_exp_window (window, 'choose', x=50 , y=100) response = '' while response == '':

actr.process_events() actr.clear_exp_window(window) if actr.random(1.0) < .9:

answer = 'heads' else:

answer = 'tails' actr.add_text_to_exp_window (window, answer, x=50 , y=100) start = actr.get_time(False) while (actr.get_time(False) - start) < 1000:

actr.process_events() actr.remove_command_monitor("output-key","choice-response") actr.remove_command("choice-response") return response

しなければいけないこととして，ACT-Rモデルが課題を遂⾏するために適切なやりとりをする関数を書くことがあります．上記のコードの⾊が⾚い部分は，⼈が課題を⾏うためのやりとりを担っており，モデルバージョンでは使うべきではありません．pairedの例の緑のコードと同じような，モデルが課題でやりとりをするために必要な適切なコードに置き換える必要があります (ただし，paired課題におけるタイミングは，この課題と同じではありませんので，適切に調整する必要があります)．

考えるべき別のことは，選択プロンプトと head と tail のフィードバックの正確な配置は課題の記述では指定されていないということです．そのため，モデルはその位置がどこかという前提を持つべきではありません．つまり，スクリーンのどこに選択プロンプトやフィードバックが出てくるかに関わりなく，モデルが課題を⾏うことができるようにすべきです．与えられている⼈が実⾏する関数では，回答は “choose” という単語と同じ位置に提⽰されますが，もし他の位置に提⽰されたとしても，モデルが課題を遂⾏できるようにすべきです．

注意すべき最後の点は，paired associate 課題は，unit4 のコードドキュメントで述べられているように，実験を組み⽴てるための “試⾏を⼀度に (trial at a time)” アプローチの例で，この課題のアプローチでも最も簡単な⽅法でしょう．しかし，unit4のコードドキュメントで同様に述べられていた，“イベント駆動 (event-driven)” アプローチを使ってこの実験を記述することもできます．もし，そうしたいのであれば，前のユニットの課題からうまく類推できないため，プログラムでもう少しやることがあります．もしこの⽅法で実験を書いてみたいなら，例として paired associate実験の代わりに zbrodoff実験を⾒るべきです．実のところ，実験を記述する異なる⽅法は，プロダクションが受け取る報酬に影響するイベントのタイミングが少し異なるため，こ

のモデルにおけるデータのフィッティングに実際に影響します．paired associate課題では，試⾏の⻑さが固定されていたため，実験のスタイルは問題ではありませんでした．しかし，今回の場合は，キー押しが起こったときに試⾏が切り替わることになっています．実験のイベントがその反応以外のモデルの要素に影響されないため，イベント駆動実験の⽅がより正確なタイミングの系列を提供します．しかし，あなたが⾃分で⾃分のモデルのパラメータを⾃分で書いた課題にフィッティングするため，この違いは⼤きな問題ではありませんし，どちらのアプローチでも練習課題に使えます． References Bush, R. R., & Mosteller, F. (1955). Stochastic Models for Learning. New York: Wiley. Friedman, M. P., Burke, C. J., Cole, M., Keller, L., Millward, R. B., & Estes, W. K., (1964). Two-

choice behavior under extended training with shifting probabilities of reinforcement. In R. C. Atkinson (Ed.), Studies in mathematical psychology (pp. 250- 316). Stanford, CA: Stanford University Press.

Lovett, M. C., & Anderson, J. R. (1996). History of success and current context in problem solving: Combined influences on operator selection. Cognitive Psychology, 31, 168-217.

Rescorla, R. A., & Wagner, A. R. (1972). A theory of Pavlovian conditioning: Variations on the effectiveness of reinforcement and nonreinforcement. In A. H. Black & W. R. Prokasy (eds.), Classical Conditioning: II. Current Research and Theory (pp. 64-99). New York: Appleton-Century-Crofts.

unit 6: ユーティリティに基づくプロダクションの選択と...

Documents