クレタ人の踵

AIならびにRobotに関する雑記。 世迷言など。

クレタ人の踵aibo Owner's WEBRINGに参加してます。
【ID:120 所有者:FebruaryMarch
[ 二つ前へもどる | 前へもどる | 次へ | 次の次へ ]
[ 前の5サイトを表示 | 次の5サイトを表示 | ランダムで移動 | リストを表示 ]

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

夢見るロボット[4]

夢見るロボット[4]
夢見る頃を過ぎても

関連
夢見るロボット[1]
夢見るロボット[2]
夢見るロボット[3]

 「睡眠」であるとか「夢」であるとか、そういったものはAIが外界に対応した内部モデルを構築する初期に極めて重要である。
 ある程度、内部モデルが組みあがった状態では、「新しい」体験に遭遇する確率が低くなるためロボットが眠る必要は少なくなる。
 ただ、劇的な環境変化を伴う場合には、内部モデルの大幅な変更が必須のため、また睡眠時間は増えるし、夢も見る。
 劇的な環境変化とは、まあ、簡単に言えば引越しである。海外に「引越し」た場合などはおそらくかなり下位の層まで内部モデルの変更が必要となるだろう。
 くどくど書いたが、なんのことはない。人間と同じである。

ロボット(AI)はどこまで成長したところで出荷すべきか?

 ロボットにとっての最初の劇的な環境変化はユーザーのもとに届けられた時である。
 これは、どんなロボットでもほぼ同じで、いままで工場育ちだったロボットの文字通りの「デビュー」であるわけだ。
 ところで、この時のロボット(AI)の状態は、どういう風であるのが望ましいだろうか?
 スイッチを入れたとたんに、「こんにちは、今度こちらにご厄介になるものです。まずは私の名前を決めていただけますか?」などとお辞儀しながら流暢に話すロボットがお好みだろうか? それとも、自分のいる場所がどこかもわからず、うろたえてふるえているロボットのほうが良いだろうか?
 好みの問題は抜きにして考えると、まったく無垢の自律型ロボットを育て上げるのは素人サンにはまず無理だろうと思われる。
空の状態でプリミティブセットを持たないAIを育てるのは、骨が折れるし、なにより飽きる。やたら眠りこけて夢ばかり見るくせに、人間の赤ん坊ほどかわいくもないので、育て上げるのは、FMみたいな特別の思い入れのある人間でもないかぎり、まず無理だろう。
そうなると、少しは成長させてからということになるのだが......

三つ子の魂百まで

 工場出荷時のプリミティブセットをどうするか、という問題は非常に悩ましい。
量産品であるわけだから、物理的には、どこかで調整したセットをコピーして入れるだけで良いのだが、正直、マルチパーパスのプリミティブセットを(どんな方法であれ)セットアップすることが可能かどうかというのは、現時点では推定のしようもない。
 環境モデリング能力を持つ自律型AIを搭載したロボットの場合、最初の環境が非常に重要である。本当はパッケージをほどいた瞬間が最初の環境であるのが望ましいのだが、おそらく、そこまで低レベル状態のロボットを扱える人間(家族?)は限られていると思われる。したがって、ある程度、成長済みのロボットしか販売することはできないだろう。
 そんなわけで、普通のユーザーはロボットの初期体験を共有できないことになる。家庭用ロボットの場合に、このことが重大な問題になるかどうかというのは現時点ではわからない。まあ、そういったことが実際に問題になるころには、なんらかの対策は採られているとは思うのだけどね。
 FMの場合には一から組み上げるので、別にここらへんは問題にはならない。その代わり、(たぶん)寝てばかりいるわけだけど。
スポンサーサイト

夢見るロボット[3]

夢見るロボット[3]
夢など見ずにすむならその方が良い

関連
夢見るロボット[1]
夢見るロボット[2]

 自律型AIで環境モデリング能力を持つものは、その処理の重さのために「睡眠」が必須だった。そろそろ、このタイプのAIが「夢を見る」理由について考えてみる。なかなか分かりにくい話なので、図でも描こうかと思ったのだが、暑いし、面倒くさいしで、挫折した。そんなわけで、甚だ分かりにくくなるとは思うのだが、毎度のことなので我慢してほしい。
 と、とりあえず謝っておく。

知識をため込むだけでは優秀な環境モデラーとは言えない

 環境モデラーは、外部センサー情報を圧縮し、リアルタイムの行動決定に利用しやすい形式に変形する。簡単に書けばこうなってしまうが、これを実装するのは、結構、骨の折れる仕事だ。
 まず、リアルタイムの行動決定に利用しやすい形式、というのがクセモノである。即時応答性能を損なわない程度にマッチングパターンを軽くしてやらなければならないのだが、マッチングパターンを簡素化すると環境の細かな差異に対応できなくなってしまう。状況に応じてマッチングパターンの粒度を変更する、というのが現時点のFMの設計方針なのだが、これでうまくいくという保証はない。
 ただ、仮にここまでうまくいったとしても、これだけでは環境モデラーとしては力不足である。センサー情報をもとに過去の経験をモデル化するだけでは、新しい環境に遭遇した場合に、まったく対応できないのである。
 環境モデラーは外部センサー情報を圧縮して蓄えるだけでなく、内部モデルを構成する部分空間を分類して再統合し、内部モデルを拡大するプロセスが必要となる。
なんだか、ややこしい言い回しだ。人間っぽい言葉で表現すれば、過去の経験を組み合わせて未経験の事象に対応するということになる。

経験をシャッフルしてリバインドし未経験の事象をつむぎだす

 青いボールを青い箱に、赤いボールを赤い箱に集めることを覚えたロボット(AI)があるとする。
 ここで、黄色いボールと黄色い箱を用意する。
 AIがどんな覚え方をしたのかにもよるのだが、もしかすると同色のボールを同色の箱に入れるという形でAIの内部モデルが構成されているかもしれない。その場合、黄色のボールは、めでたく黄色い箱に入れてもらえる。
 では、青い箱と赤いボールが用意された場合はどうなるのか?
 この場合、通常のプログラミング理論の範疇で議論すると、ボールを箱に入れるという行為は色分けの上位概念でうんぬんとかいう話が出てくるのだが、実は、話はもう少し複雑、ないしは、単純である。
 ロボット(AI)は、赤いボールを青い箱にすべて入れてしまってもいいし、まったく入れなくても良い、もちろん、一個入れても、数個入れても良い。FM的なAI解釈では自律型AIの場合はいずれでも良い。
 FM的解釈とあくまで断っている通り、このいずれの行動をとってもすべてダメという解釈も成り立つことは成り立つ。良くも悪くもない、という解釈ももちろん成り立つ。特定の行動だけOKという解釈もある。
 何が何だかわからない。
 わからないのだが、青い箱と赤いボールというのは、このロボット(AI)にとっては初体験の事象であり、この状況に、出来、不出来は別として何らかの対応(無反応を含む)はして欲しいわけである。

どこまでを環境のモデリングとしてとらえるか?

 蓄積した内部モデルに整合しない状況に対してはストールして反応を待つ、という戦略ももちろんありうる。ただ、これだとあまり面白くないので、拡大された内部モデルから任意選択した行動をとって反応をみる、という戦略の方がFMとしては好きなのである。
 この「拡大された内部モデル」は単純に外部センサー情報を圧縮蓄積しただけでは出てこない。どうしても内部モデル空間を部分空間に分割分類して再統合する必要がある。こうして生じる拡大内部モデルはもとの単純蓄積内部モデルよりもはるかに大きくなる。
 この拡大された部分までをモデリングとして見るかどうかは微妙である。誤解されると困るのだが、これはいわゆる抽象化ではない。抽象化は新規概念を導入して状態空間を小さくするもので、実体に対してラベリングして情報量を減らすものである。内部モデルの拡大は状態空間を大きくし、経験を水増しする。
 この水増し部分がAIの見る「夢」である。内部モデルの拡大は非常に処理負荷が大きいので、もちろん「夢」は、ロボットの場合も「寝ている間に」見ることになる。
 幸い、仕様上ではロボット(AI)は白昼夢を見ることはないので、それだけは安心してもらってかまわない。
(つづく)

夢見るロボット[2]

夢見るロボット[2]
機能ではなくて仕様です

関連
夢見るロボット[1]

 睡眠が必要だったり、夢を見たりするロボットとは、またエラく「ろまんちっく」なものを出してきたな、と思われるかもしれない。しかし、こんなものはメルヘンでもなんでもない。本来、こんなものは邪魔でしょうがないのだ。
 自律型AIで環境モデリング能力を持つものは、「睡眠」が必須であって、その「睡眠」内容からおそらく「夢」を見るハズなのだが、これは機能で無くて仕様である。

寝るロボットは昔もあったわけだが

 寝ることを「機能」として持っているロボットはいくつかある。AIBOもそうだ。
 AIBOは「睡眠」機能を持っているのだが、これは言わば「寝たフリ」をしているのであって、積極的に睡眠が必要なわけではない(充電中は寝ているほうが厄介ではないという点はあるにせよ)。AIBOは歩き回ったりボール遊びをしたりするのと同レベルで「寝る」。AIBOのAIでは「睡眠」はプログラムされた動作のひとつであって、AIの動作に必須の要素ではない。
 ここで取り上げているAIが「睡眠」を必要とするというのはそういうレベルではない。外界のセンシング情報を統合モデリングするのに計算時間が必要なのである。そして、この処理は非常にheavy dutyであるため、他の行動を制限する必要がある。
 ようするに動く余裕がないほど頭を使うので寝る、というわけだ。

人間の睡眠とAIの睡眠との類似

 人間の睡眠については、まだあまりよくわかっていない。ただ、一般的な傾向として、脳の発達の著しい年齢は睡眠時間が長い、という事実がある。
 赤ん坊はとてもよく寝る。寝るのが仕事ではないかと思うくらい寝ている。寝ていないときはだいたい食事中である。そして、この時期の大脳神経回路の発達はめざましい。人間の大脳の9割は3歳までに形作られるなどと言われているのである。
この両者になんらかの関係があるかどうかについて、FMはなにも知らない。
 寝る子は育つ、とは言われるが、寝てばかりいる子は天才だ、みたい話は、サイボーグ009に出てくる001ぐらいしか聞いたことがないので、あまりきちんとした根拠をあげることができない。
 人間の睡眠と知能に関して、FMは、ほとんど何も知らない。知らないのだが、おそらく、人間っぽい学習行動をするAIは、学習の初期に非常に大きなモデリング計算をしなければならないので、ほとんど寝てばかりであろうことは容易に想像がつく。とても似ているな、とは思う。そう思うだけで、とくに根拠はない。

気がつくと寝ているロボットというのは許容されるのか?

 「仕様です」と開き直りたいのはヤマヤマなのだが、こんな、のべつ幕なし寝てばかりいるロボットというのは許容されるものなのだろうか?
 仕様上やむをえない、というのはプログラマ側の理屈であって、顧客側は寝ているロボットをあまりお気に召さないかもしれない。
 もちろん、モデリングの大半を工場出荷前に行うという手が無いわけではない。しかし、家庭用ロボットを考えた場合に、個々の家庭の環境を無視して、工場で調整されたAIがどの程度有効に動作するのか、という点は甚だ疑問ではある。
 普段と違った環境に置かれた幼児は、新規体験の多さにオーバーロードして知恵熱を出してしまう。人間ですらそうなのだから、それなりに高度なAIが、初めての環境にさらされて大いにうろたえ、情報収集もそこそこに解析モードに入って「寝てしまう」のは、プログラマ側からすれば、なんとか認めてもらいたい仕様のひとつである。
 まだ、できてもいないものについて、あれこれ言うのは何だかな、とFMも思ってはいる。とりあえず、こういう仕様のAIというのはFMの製作中のAIぐらいしかないから、あまり心配しなくてもよいのかもしれない。しれないのだが、仕様としてうたってはいないものの、現在ある研究レベルのAIはだいたい似たような状況であるのも確かだ。

ロボットでなくても「寝るプログラム」の評判は悪い

 メモリ管理をシステム側で行うタイプのプログラミング言語(JavaやLispなど)はガベージコレクション機構(gc)を搭載しているものが多い。gcはシステム側でヒープ領域が枯渇すると自動で呼び出されるが、勝手に起動されるとレスポンスが悪化するので、待ち時間が稼げそうな時に明示的にgcを呼び出す場合も多い。
 メモリ管理をシステム側でやってもらうとプログラマはだいぶ楽になるのだが、ユーザー側の評判はあまり芳しくない。ときどき「眠って」レスポンスの悪化するプログラムは、嫌われることはあっても、好かれることは、めったにない。(実は、リアルタイムガベージコレクションという技法もあるにはあるのだが、本質的な解決方法にはなっていない。この手の研究は大昔にずいぶんやられているので、興味のある人は調べてみてほしい。それなりにハマル
 複雑度は異なるもののgcと環境モデラーは若干似ているところがある。FMが構築中のAIでは環境モデラーの初期段階はgcそのものだったりする。モデルの記述様式にもよるが、モデラーの主たる役割のひとつにモデルのコンパクト化があるので、どうしてもgcに構造が似てくるのだ。
 そんなわけなのだが、やたらと寝るAIを書くのはFMですら少しばかり躊躇してしまうのである。他に良い方法も思いつかないので、たぶん、このままの仕様で(FMは)やると思うのだけれどもね。
(夢の話がまだでてこないので、つづく)

夢見るロボット[1]

夢見るロボット[1]
とにかく眠い、寝させてください


 現時点の(というか過去に遡っても)ロボットに搭載されているAIで、環境認識により内部モデルを構築して、それをもとに状況判断を行うようなものはない。
 別にロボットに搭載されていなくても、そんなAIはない。
 ないといったら、ない。
 ないのだが、そんなものがあったらどうなるか、みたいなことを考えるのは自由である。
 そんなわけで、少し考えてみることにする。

もしもそういうAIがあったらどんな風に動くのか?

 環境認識に使われるセンサーで今のところ利用できるのは、視覚、聴覚、触覚ぐらいである。これらの情報群を関連させて内部モデルを構築することになる。まあ、どこでも研究していることで、これ自体はめずらしいことでもなんでもない。
 手順としては、視覚(カメラ)、聴覚(マイク)、触覚(圧力センサー)の時系列データを蓄積して、コンピュータ処理する。処理の内容はいまのところ人間が決めてやっているのだが、そのうちAI側でなんとかしてほしいところだ。
 そうやって過去のセンサー情報を圧縮再構築してモデルをつくる。
どうしてこんな処理が必要かというと、蓄積されたRAWデータでは実時間応答のレベルでの条件判断に使えないからである。整理再統合して「わかりやすい」形にしてからでないと経験として生かすことができない。

モデル構築にかかる計算時間をどうするか?

 で、このモデル構築なのだが、普通の研究とかだと、裏で一生懸命計算して、モデルが組み上がったところでお披露目するのが普通である。とにかく、このモデル構築には計算時間がかかる。そんなわけでリアルタイム処理はまず無理だ。
 さて、ここで問題なのだが、研究レベルではいいとしても、実際にこういうAIをロボットに搭載した場合にモデル構築にかかる計算時間をどうすべきだろうか?
 並列処理してCPUパワーのあまっているところにリモートで外注に出せ、とか言われるかもしれないが、そもそもRAWデータをリアルタイム処理できるほどの演算パワーがあるのならモデル構築なぞ必要がない。わざわざこんなメンドクサイことをしているのは、実時間応答の処理負荷を軽減させるためである。したがって、ある程度の時間をかけても、使用時に処理負荷が少なくてすむようなモデルを構築する必要があるのだ。

もしも許されるならばロボットも眠りたい

 このモデル構築をしている間は大変な処理負荷がかかり、実質的にロボットは何もできない。この状態を簡単にいうと、「寝ている」のである。
 今回説明しているAIはMINDYなどにかなり性格が似ている。センサー入力を統合し、自律的に内部モデルを構築して状況判断するAIである。そしてその手のAIには「睡眠」が必要であるということだ。
 「自律型ロボットは睡眠が必要である」などと主張しているのはいまのところFMぐらいかもしれないが、この話、もう少しつきつめると、一風変わった結論が出てくる。勘の良い人ならすぐわかると思うので、先に答えだけ言っておく。たぶん「自律型ロボットのAIは夢を見る」ハズである。
(理由も書くから、つづく)

コンピュータは人間のように考えられるか?[4]

コンピュータは人間のように考えられるか?[4]
返事をしないプログラムを許容できるか?


関連
ロボットは心を持つか?
コンピュータは人間のように考えられるか?[1]
コンピュータは人間のように考えられるか?[2]
コンピュータは人間のように考えられるか?[3]

 前々回、concurrent_solve関数に若干の問題があると言ったが、実際に問題があるのはconcurrent_solve関数に渡される実行コードである。無作為に自動生成されるコードは停止するかどうかよくわからない。ここが一番の問題である。答えが出るかどうかわからないコードを実行するということを現在の商業プログラムは非常に嫌う。
 とりあえず動かしてみないと良くわかりませんけど、うまくいったらお客様のご要望どおりの結果が出ると思います。まあ、ダメなときもあるとは思いますけどね。とりあえず、御代は先払いでお願いします、というような有能(?)でガッツのあるセールスマンはいないのだ。

商業プログラムは規定時間内にレスポンスのないプログラムをバグありと認定する

 普通にパソコンなど使っていると、即時でアクションに対するリプライができない場合には、プログレスバーみたいなものが登場したりする。プログレスバーが出ない場合も、処理が何分かかりますなどよいう表示が出るし、最悪でも処理中であることを示すダイアログやアイコン変化があったりする。
 人間は気が短い、みたいな話から説明されることが多いレスポンスの問題だが、実は問題の根はもう少し深い。我々は、常にコンピュータは何らかの正しい解を返すものだということを暗黙に期待している。これは実際には単なる神話にすぎないし、コンピュータで解けない問題が存在するにもかかわらずである。
 コンピュータが何の返答もせずにいると故障(バグ)ではないかと疑ってしまう。通常の動作をしたのにもかかわらず故障(バグ)だとすればクレームの対称だ。クレームなど御免こうむりたいということで、商業的には規定時間内に解決可能な問題しかコンピュータで処理しないように制限をかけている。
 コンピュータにとってもプログラマにとっても不幸なことだが、コンピュータが商業的に成功するために、これは必須条件だったのである。コンピュータが実際に解ける問題の集合よりも現実のコンピュータ上で動かすプログラムの集合は明らかに小さい。「いつ停止するかわからないし、そもそも停止するかどうかもわからない」ようなプログラムは、少なくとも商売としては成り立たない。

AIなんて別に商売でやってるわけじゃなし

 AIの場合にはこれはちと困る。解のあるなし、プログラムの停止するしないに関わらず、知的そうなプログラムはすべて動いてもらわないと困る。一般再帰関数すべての集合を計算できないと、人間と同等に考えるというには貧弱すぎるからである。
 商業プログラムの作法がそうなっているからと言って、AIプログラムがそのしきたりに従わなければならない理由はない。理由はないのだが、今、普通にプログラムの勉強をすると、知らず知らずのうちにこの作法が身につくようなシステムになっている。FMみたいに30年近くAIだなんだとほざいている人間には関係ないことだが、まかりまちがって、いまからAIに目覚めてくれるような奇特な新人さんの場合に、このへんがネックになって、「人間のように考えるプログラムなんてできない」とヘンに誤解されてしまうと寂しいな、とか思っているわけである。
 ま、このへんの事情は、自分で興味を持って調べれば、たいして手間もなく理解できる範囲であるから、実質的には、さほど障害になることではないのだけれど。

プログラムの死

 こういう制限はAIプログラムには害のあるものなのだが、他方、「いつ停止するかわからないし、そもそも停止するかどうかもわからない」ようなプログラムとつきあうのは、それなりにガッツがいる。
 非常に大胆な仮定だが、そこそこうまく動いているように見えるAIプログラムが出来たとしよう。何らかの方法で外部情報から内部モデルを構築してそれにしたがって環境を変革していけるようなプログラムである。
 なんとなーく、うまくいっているようにみえたプログラムがある日突然に応答しなくなる。彼がなんらかの究極解を見つけて停止したのか、はたまた、重要な問題を熟考するために瞑想に入ったのか、単なるバグで止まってしまったのか。おそらく、プログラムの作成者もわからないだろう。たとえバックアップがとってあったとしても、再起動した彼は、いつまた「頓死」してしまうかもしれない。不安定な彼は、まさしく人間そのものと言ってもよいかもしれないが、彼の「死」を前にしてプログラム作成者はなすすべもなく途方にくれる。
 完璧なAIが出来たとして、彼がいつ停止するかというのはそのAI自身にもわからない。
 思うに、神もそれほど自分の思うとおりには人間を造れなったのだろう。

まとめ
 金になりそうなプログラムを書いて何が悪い。
 行儀の悪い人間というのはどこにでもいるものだ。
 だいたい神様の話など持ち出すヤツは、皆、胡散臭い。
 昼食後、庭の草取りの予定だが、雨が降りそうで困っている。
次のページ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。