コニュニケーションへの衝動としての笑い

コンピュータないしはロボット(単にAIとよぼう)は、人に対するコミュニケーション衝動のようなものを持たなければならないと、何回か書いてきた。人に伝えたいことがあってこそ、それをどのように伝えるのかが問題になるのだ。AIは、衝動に基づいて、言葉を選ぶ、構成する。言葉を編集する。外的な刺激に対して、独自の、創造的な衝動を構成する。それをなんとか言語的に相手に伝えようとするわけだ。

衝動は、AIの側に、それを必要とする内的な環境・状態・理由があるから形成される。それをまた明確にしていくことはとても高度の情報処理、知能的活動などが必要になる。

しかし、「笑い」あるいは「人を笑わせる」というのは、極めて単純な動機、衝動となりうる。単純というのは、簡単という意味ではない。明確という意味に近い。

人としての相手を笑わせるためのコミュニケーションである。どのような言葉を選び、どのように言葉を構成し、どのように編集し、どのように文章をつなげれば、人を笑わせることができるのか。これがとてもわかりやすい衝動なのだ。

そういう衝動をAIの側に持たせることは不可能ではないだろう。可能性はある。その衝動から、言葉を創造するのだ。

コンセプトの管理システムの必要性

今、サリーには、2万語以上のコンセプトが組み込めるようになっている。ただ、もう、絶対使わないだろうなというコンセプトも入っている。それは無駄だ。よく使いそうなコンセプトに入れ替えて、まあ、全体として2万語になればいい。

そのためのシステムなり、データベースが必要だ。潜在的可能性のあるコンセプトを貯めておいて、スコアを与え、スコアの高いものから順番に入れておくというのが望ましい。実際に、wikipediaとか、twitterで使われる頻度、辞書への掲載などの基準でスコア化する。もちろん、ライブでお客さんから出されたお題の場合は、さらにスコアを大きくすべきだろう。

Qichatでヴァーチャルなif文を作る(1)

(※ 次の(2)で、単純に説明します、笑)

ロボットは対話で動かすというのが、私の確信だ。NAOを動かすときは、基本Qichatで書かれたtopicファイルに、自作ライブラリを起動するための独自コマンドを埋め込んで、制御する。

この間、一つのスクリプトで、即興漫才と即興謎かけのネタを切り替えるようにした。このスクリプトは、お題として識別できる語数は20000万語を超えている。それも、Qichatに書かれている。

ここで問題は、Qichatの変数 $manzai の値が1の時は、もらったお題に対して即興漫才を実行し、それが0の時は謎かけをするようにしたい。しかも、お題として認識できるのは、標準でこれまで作成したコンセプト2500語に引っかかるのか、その後拡張した18000 語の方に引っかかるのかということがある。混ぜていないのだ。

当初は以下のような書き方をしていた。

u:(お題は _~manzai_concepts です) $manzai==1 $1 ですね。少しお待ちください。 $sub_main=$1 $telepathy_to_emily="emily_getmanzai_subjects/$sub_main"
u:(お題は _~manzai_extended_concepts です) $manzai==1 $1 ですね。少しお待ちください。 $sub_main=$1 $telepathy_to_emily="emily_getmanzai_subjects/$sub_main"
u:(お題は _~manzai_concepts です) $manzai==0 $1 ですね。少しお待ちください。 $sub_main=$1 $telepathy_to_emily="emily_getnazokake_subjects/$sub_main"
u:(お題は _~manzai_extended_concepts です) $manzai==0 $1 ですね。少しお待ちください。 $sub_main=$1 $telepathy_to_emily="emily_getnazokake_subjects/$sub_main"

ロボットの出力文の中に、条件式を入れている。何が違うんだということになるかもしれない。$telepathy_to_emilyというのは、私のライブラリ ibotライブラリのコマンドであり、emilyというのは制御コンピュータの名前で、それに対してお題を送っている。コンピューターからは、作られたネタの要素がこれも、telepathyコマンド(Qichat的にいうとイベント)で返されてくるのだが。つまり、私のibotシステムでは、ロボットとロボット、ロボットとコンピュータの、ローカルネットを経由したやり取りは、すべてテレパシー機能として実現している。それで、お互いのデータのやり取りも2000バイトまでは日本語でもできるようになっているのだ。

Qichatに戻ろう。後の二つが謎かけの、標準コンセプトと拡張コンセプトの場合である。$manzai==1というのは、$manzaiの値が1の時だけ真となる。

Quichatのロボット出力に、一つでも真でないものがあると、その全体が出力しないという機能を使っている。$manzaiが1の時は、前二つのいずれかにマッチングし、そうでない時は、謎かけの後者二つのいずれかにマッチングするはずだった。

しかし、これはうまく機能しないかった。細かくは調べていないが、考えられるのは、Qichatは、マッチングしているイベント処理ステートメントのどれか一つでも偽の文があると、たとえ真の文があってもそれを実行しないということだ。

たとえば「お題はチューリップです」という拡張コンセプトのチューリップに一致した入力文(イベント文)が、漫才と謎かけで二つある。$manzaiが1ならば、漫才の文にだけ一致すると思うのだが、全体が偽となって、実行しなくなってしまうということだと思う。

そこで、まず、次のように改良した。

u:(お題は _~manzai_concepts です) $1 ですね。少しお待ちください。 $sub_main=$1 [ $getmanzai_script=1 $getnazokake_script=1 ]
u:(お題は _~manzai_extended_concepts です) $1 ですね。少しお待ちください。 $sub_main=$1 [ $getmanzai_script=1 $getnazokake_script=1]
u:(e:getmanzai_script) $manzai==1 $telepathy_to_emily="emily_getmanzai_subjects/$sub_main"
u:(e:getnazokake_script) $manzai==0 $telepathy_to_emily="emily_getnazokake_subjects/$sub_main"

ポイントは、初めのロボット出力文の最後に、オプション処理の [ ] でくくっって、のちの、テレパシー送信文の漫才と謎かけのいずれかを実行するようにしたのだ。

これでいいかと思った。実際、ちゃんと謎かけのお題を与えると、パソコンにデータを送信し、回答をもらうようになった。そして、ネタ見せもこれでやった。

ただ、問題があることもすぐにわかった。たとえば、漫才の一つ目のお題をもらって実行する。それはちゃんとやる。しかし、それを終えて、もう一つお題をもらう。すると、「〇〇ですね、少しお待ちください」と言ったあと黙ってしまうのだ。そういう時は、もう一度お題を伝えると、今度はちゃんとテレパシーを送ってパソコンからの回答ももらう。

それで、さっき原因がわかった。 [  ] のオプションオペレータを使ったからなのだ。つまり[ ]がロボットの出力に与えられると、実行するたびに、一つずつ変わるようになっている。だから、最初のお題は、漫才用に対応するが、次にまたお題をもらうと、次の謎かけの処理をしてしまうのだ。

結局!!この [ ] を外したら思う通りの処理するようになった。 [ ]を外すと、選択せずに毎回両方実行する。その先のイベント処理の出力の中に、真があろうが偽があろうが関係なしに実行するのだ。だから、$manzaiが1の時は、つねに偽になっている、謎かけは実行されずに、漫才の処理だけが実行されるのだ。

あまりに単純なことで、笑ってしまいそうなくらいだった。

人工知能のインターフェイスとしてのロボット

ロボットに一つのお笑い芸をさせたい。
具体的には、即興的に与えられた大喜利のお題に答えるというものだ。お題に対して答えるのは、人工知能的にやらせれば良い、答えをコンピュータから出すのではなく、ロボットにさせた方が、人は答えを受け止めやすい。
ロボットは、インターフェイスとなるのだ。
大喜利の答えを集めて、人工知能の教育材料とするためのサイトを作成した。
http://aicomedian.com(その後中止)
どなたでも、遠慮なく、ぜひ試していただきたい。

Juliusにwav音声ファイルをテキスト化させる

先の投稿の手続きの段階の、chromeのweb speech apiの代わりに、juliusを使えないかと試したところ、ほぼ、問題ないレベルで答えを出すことがわかった。
Juliusにwavファイルで、音声データを与えて、それをテキストに変換させてみた。

 
 
これで、プロセスとプログラムが、単純化される。

音声認識でweb speech api を使う

今日考えていたことをメモがわりに書いておこう。
(1)ロボットNAOが受け取った人の言葉を音声ファイルに出力することは制御できるだろう。C++でライブラリ化することができる。
(2)そのファイルをPC、つまりMACbookに、無線ネットワーク経由で送ることもできる。
(3)MacでChromeを開いていて、ibotサイトを表示しているとすると、Chromeのweb speech api が使えるだろう。
(4)受け取った音声ファイルをJAVAで、実際の音として出力することはできるだろう。
(5)その音を、物理的コードを使って、マイク入力として直接入力することができるだろう。
(6)その入力に反応して、音声をweb speech apiがテキスト化することができるだろう。
(7)javascriptからjavaを呼びだして、そのテキストを、JAVAで解析して、求める答えを構成させることができたとする。
(8)それをロボットに送り込み、qichatの変数に組み込み、それを読み出させるイベントを発生させることができるだろう。
(9)ロボットは、その内容を喋るだろう。
※PCはインターネットに接続していなければならない。
以上

ロボットを舞台に立たせてみた

先日、松竹芸能の関東ゲラゲラBRONZEライブの出場をかけたネタ見せがあり、ロボットネタをやってみた。
この間、ロボットのコマンドモードを充実させて、コマンドをプログラム化したファイルを与えれば、こちらが対話的に指示を出すとそのプログラムを起動するようにしている。通常の対話とこのプログラムモードを駆使して、ネタ尺2分間で、ロボットとの面白さを表現するネタを作った。
会場の外で、ロボットのibotシステムを起動し、topicファイルを組み込み、休みモードにする。休みモードにすると、座って、音を出さないようにしているので、例の警報音が出ても他に迷惑をかけないようにする。
自分の番の時、初めて舞台の登場させ、立たせ、袖で「ここにいるんだよ」というと、ネタが開始するという段取り。基本、いうことを機会ないロボットに翻弄される教授という設定で、笑いを取る。動きと会話のやり取りが基本だ。途中から、しょうがないからということで、隣に立たせて漫才風になる。
なんと、ほぼ4倍の競争のところを、ネタ見せ合格になりました!!来月12月6日の関東ゲラゲラBRONZEに出場します。
http://www.kadoza.jp/shinjuku/schedule/2016/12/06.php
その後、NAOのサウンドファイル演奏機能をコマンド的に呼び出されるようにライブラリ(libwsibot.so)を改訂して、リズムネタを挟めるようにしました!!これで、必ず笑いを取れる、鉄板ネタができるはずです。
実に、高度なプログラミングだと、自分を褒めています。