【マインド・エンジン】絶対不可能といわれていたコンピュータによる言葉の意味理解。ついに成功したので公開します。
解決!意識のハードプロブレム③ ルンバの意識のプログラムを作ってみた
解決!意識のハードプロブレム③ ルンバの意識のプログラムを作ってみた
もし、お掃除ロボット「ルンバ」に意識が発生したら・・・
たぶん、最初の一言は、きっと、こう言うでしょう。
「俺は、いったい、何をやってるんだ!」
知らんけど。
関西人は、すぐにそういう!
知らんけど。
ほんと、便利な言葉ですよね。
知らんけど。
まぁ、とにかく、意識のプログラムを、具体的に考えようとしましてね。
そこで、ルンバに意識を持たせてみました。
意識にとって、何が、最も必要か。
この動画を見れば、一目瞭然です!
知らんけど。
マインド・エンジンの公開おめでとうございます!
そちらの記事には、またコメントします。
先に、こちらの記事でコメントしたいことがあるのでよろしくお願いします。
ルンバに意識を持たせる説明はわかりました。
そこから更に進んで、ルンバに痛みのクオリアを持たせることは可能ですか?
頭の中の仮想世界を認識するプログラムが意識だというのはイメージ出来ます。
では、痛みのクオリアは?
私には未だに痛みのクオリアが不思議でしょうがないです。
以前、田方さんが痛みのクオリアの説明をしてくれたので
覚えている範囲ですが、それを利用したらこんなやり方になりますか?
ルンバの表面に圧力センサーを取り付ける。
叩かれた強さに応じて、圧力センサーから
情報が意識プログラムと感情プログラムに送られる。
ある一定の閾値を超えると痛いとプログラムされているとする。
感情プログラムには快と不快があり、痛みは不快に結び付けられていて、不快だからこそ
痛みに反応して、痛みを避ける行動を取る。
外から見たら、あたかも痛みのクオリアを持っている。痛みを感じているように見える…。
しかし、これはあくまでもイージープロブレムですよね?
この説明では、本当に痛みのクオリアが発生しているのか?私にはそのようには思えません。
単にプログラムに反応しているゲームキャラと変わらないと思います。
銃で撃ったら反応するキャラクターのように…。
つまり、ルンバやロボットがこのやり方だと
痛がっているように見えるだけの哲学的ゾンビではないですか?人間との違いがわかりません。
よろしくお願いします。
karat様
いつも、コメントありがとうございます!
ハードプロブレムとイージープロブレムをおさらいしますね。
意識があるとか、痛みのクオリアをもってるとかって、外から見て分からないって話がハードプロブレムです。
だから、本当は痛みを感じてなくても、感じてるように振る舞ってる哲学的ゾンビか、本当に痛みを感じてるのかは、外からは分からないわけです。
つまり、外から見て痛みのクオリアを持ってるかどうか分からないからと言って、その人が、痛みのクオリアを持ってないとか、意識を持ってないとか言えないわけです。
逆に言えば、これが痛みのクオリアだって定義して、それを実装して、痛がってるように振る舞うゲームのキャラクターは、痛みのクオリアを持っているといってもいいわけです。
ただし、これは、あくまでも僕の考えですが。
その前提で考えれば、ロボットを作って、苦しい状態と、苦しくない状態を定義して実装するわけです。
苦しいの一つは、電池残量が少なくなるとかです。電池残量が少なくなると、電池を欲するわけです。
充電して、満充電になれば、苦しい状態から抜け出るわけです。
この電池残量が少ない状態を、そのロボットの空腹クオリア、満充電状態を、満腹クオリアと定義したらどうだというのが僕の提案です。
お腹がすいたり、お腹がいっぱいのように振る舞うけども、本当に、お腹がすいたり、いっぱいなのかは、外からはわかりません。
ただ、電池残量が少なくなればなるほど、充電を欲し、体が動かなくなります。
これを、空腹のクオリアといっていいのかどうか、僕も、正直、よくわからないですけどねぇ。
少なくとも、そういうプログラムを作れば、人間と同じように振る舞って、人間の苦しみも理解できるロボットになると思います。
これを空腹のクオリアと認めれるなら、痛みのクオリアも同じように定義できると思います。
それから、全て説明できれば、イージープロブレムってことじゃないです。
説明内容が、主観に結びついていないのがイージープロブレムです。
苦しいって主観をプログラムで定義して、それに結びつければ、ハードプロブレムが解決したってことにしてるわけです。
まぁ、この説明で、誰もが納得するとは思っていませんけど、少なくとも、こうやって、一歩前進して、実際に作って行かないことには、何にも、進まないと思うわけです。
考えるだけが仕事の哲学者は、それでもいいと思いますけど、実際に動くものを作るエンジニアとしては、議論は、作ってからにしましょうって感じですね。