まとめると、Qichatで、もし 変数 $varが1の時は、Aという処理、0の時はBという処理をするというのは次のように書く。
u:(実行しなさい) わかりました $exec1=1 $exec2=1 u:(e:exec1) $var==1 Aを実行します u:(e:exec2) $var==0 Bを実行します
これだけのことである。もちろん、これ以外にもいろんなやり方はあるだろう。
u:(実行しなさい) わかりました $var==1 Aを実行します u:(実行しなさい) わかりました $var==0 Bを実行します
これでもいいかと思ったのだが、私がやった場合は、動かなかった。このような単純化すれば動くかもしれない。ただ、ぱっと見、「実行しなさい」が二つのイベントルールにマッチするような書き方が違和感がある。
u:(実行しなさい $var==1) わかりました Aを実行します u:(実行しなさい $var==0) わかりました Bを実行します
これでも動きそうな気がする。「実行しなさい」の代わりにイベントだったらどうなるだろう。
（※ 次の（２）で、単純に説明します、笑）
ロボットは対話で動かすというのが、私の確信だ。NAOを動かすときは、基本Qichatで書かれたtopicファイルに、自作ライブラリを起動するための独自コマンドを埋め込んで、制御する。
この間、一つのスクリプトで、即興漫才と即興謎かけのネタを切り替えるようにした。このスクリプトは、お題として識別できる語数は20000万語を超えている。それも、Qichatに書かれている。
ここで問題は、Qichatの変数 $manzai の値が１の時は、もらったお題に対して即興漫才を実行し、それが０の時は謎かけをするようにしたい。しかも、お題として認識できるのは、標準でこれまで作成したコンセプト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の値が１の時だけ真となる。
Quichatのロボット出力に、一つでも真でないものがあると、その全体が出力しないという機能を使っている。$manzaiが１の時は、前二つのいずれかにマッチングし、そうでない時は、謎かけの後者二つのいずれかにマッチングするはずだった。
しかし、これはうまく機能しないかった。細かくは調べていないが、考えられるのは、Qichatは、マッチングしているイベント処理ステートメントのどれか一つでも偽の文があると、たとえ真の文があってもそれを実行しないということだ。
たとえば「お題はチューリップです」という拡張コンセプトのチューリップに一致した入力文（イベント文）が、漫才と謎かけで二つある。$manzaiが１ならば、漫才の文にだけ一致すると思うのだが、全体が偽となって、実行しなくなってしまうということだと思う。
そこで、まず、次のように改良した。
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が１の時は、つねに偽になっている、謎かけは実行されずに、漫才の処理だけが実行されるのだ。
あまりに単純なことで、笑ってしまいそうなくらいだった。
サリーやマリーが、即興漫才や謎かけのお題を取得するのは、音声認識機能を使うが、クラウドを全く使わないので、全てローカルでやっている。googleのクラウドなんかも使えなくはないのだが、テレビのスタジオやライブの舞台にネットが繋がるとは限らない。テレビの収録では、ほぼ期待できない。そういうことがわかっているのに、クラウドでしか音声認識ができないというのは、馬鹿げた戦略である。
ローカルでNAOがお題を認識するためには、qichatのconceptを使う。この夏までは、コンセプトに２千数百個を入れて、お客さんのお題に対応していた。少ない。そこで、システムを変えて、日本語wikipediaや数千万のツイートを使って、自力でネタをその場で生成するシステムに変更し、お題の認識可能性も8000語に増やした。それが、10月の初め。
さらに今日、AI的手法で、ウィキペディアやツイートから取得した関連語20000語を識別させようと入力したら、認識のための音素にコンパイルするのに3分以上かかったが、できたのだ。ちゃんと認識する。
NAOのコンピュータは相当古いが、ネタに必要な自作ライブラリやスマホからコントロールするためのHTML5関係のファイルしか入れていないので、メインメモリにもディスクにも比較的余裕があった、ので可能になったのではないかと思っている。
今、実際のネタ作りは、同じローカルネット内のパソコンにお題を送って作成させている。インターネットにつなぐ必要はなく、サリーとマリーとパソコンがローカルネットに繋がっていれば良いので、閉鎖空間でも対応できる。
何れにしても、今日はNAOが２万語以上も識別可能性を持っていることにただ驚愕した。下手すれば、メモリのある限り認識するのではないか。上限が推測できない。まだまだいけそうな気はする。
（その後、2万3千語あたりが、実質的限界であることがわかってきた。それ以上にすると、コンピュータの実行速度が低下する。メモリの誓約だと思われる 2018年11月24日追記）
先のいくつかの記事で示しているように、ロボットが知識的文章を短く語る時に、削除した語を繋ぐ助詞をAI的に選択させようとしている。（体言１：名詞・動詞）＋（助詞１：助詞・助動詞）＋（体言２：名詞・動詞）＋（助詞２：助詞・助動詞）の語の並びの中で、体言１、体言２、助詞２が与えられた時に適切な、助詞１を選択させたい。これができれば、うまく、文章を短くできるだろうということである。
そこで、この並びを、日本語wikipediaの前文から拾い出して、それを元に、ディープラーニング用の学習データを作ろうということである。
４語対は、6千万個取れて、語は、word2vecのウェイトベクトルであらわすのだが、そのベクトルを取れる語は、さらに半分以下になってしまう。また、助詞、助動詞部分のパーターンがとてつもなく大きくなってしまう。「の」とか「を」などはたくさんあるが、全体で１回しか現れないようなものも拾ってしまう。これは、広い方のアルゴリズムにも依存するのだが。
そこで、いったいどのような助詞、助動詞が、どのような頻度で現れているのかを調べてみた。
まず、助詞２（ニューラルネットの入力になる）は次のようになっている。
の 4848543 を 3418017 に 3153274 が 2271523 は 1676994 と 1359190 で 1134953 た 833487 な 515517 から 481586 や 449712 も 403445 て 391692 である 384000 として 321609 ている 278220 には 264654 では 242007 ていた 141653 によって 117531 であり 109701 により 109549 であった 107166 による 101919 へ 97715 でも 97698 との 95020 という 95008 まで 94623 への 88007 にも 87645 ない 80116 での 77605 たが 71719 だった 71462 など 69269 ており 69104 だ 68336 ず 64151 などの 62250 より 56385 とは 53537 において 50758 たと 47488 からの 46761 における 45079 について 38801 ば 34365 たり 33421 に対して 32896 なかった 32558 はと 31786 としては 31599 か 31034 に対する 30519 であると 30483 としての 30440 うと 30412 とも 29750 とともに 29742 ていたが 29645 だが 29500 などを 28746 までの 28607 ながら 27353 と共に 26439 へと 25588 に関する 25518 だと 25209 よりも 24233 であるが 24219 などが 23941 ではなく 23687 については 23225 であったが 21177 ているが 20375 にて 20046 てきた 19284 でいる 19168 からは 19166 ても 18992 ていない 18033 などで 17049 に対し 16993 といった 16725 だったが 16552 をと 16238 ていく 15419 などに 15401 ていると 15107 てしまう 14659 までに 14412 にと 14395 においては 13755 でいた 13566 ずに 12898 のみ 12697 なく 12433 たものの 12417 にかけて 12292
明らかに、代表的助詞型を圧倒している。だから、全部を対象にすることはない。だいたい、上位128個くらいの使い方がわかればそれでいいのではないかと思う。入力に関しては次のようになっている。
の 6087401 は 2794515 に 2311801 を 1850357 が 1667993 で 1144968 と 1039936 た 1026311 な 563759 や 531865 から 515033 て 502233 には 461876 では 405320 も 340662 である 297177 として 239221 ている 200314 という 145218 であり 141251 ていた 140480 との 135622 により 135543 による 124273 への 116794 での 114556 たが 110351 によって 100663 まで 99795 などの 99002 ており 98666 など 95691 でも 91841 ず 91712 とは 87425 であった 78465 ない 76015 にも 73529 より 69404 だ 67224 において 65830 からの 63813 における 59617 だった 59331 ば 53503 へ 50134 としての 44902 に対する 40913 に対して 40079 だが 39554 としては 38818 に関する 37624 について 37003 ていたが 36863 までの 35317 とともに 33629 からは 33043 ながら 32942 たり 31465 であるが 31366 については 30835 と共に 30434 か 28826 はと 28675 ではなく 27939 なかった 27507 といった 26896 などを 25960 に対し 25781 であったが 25642 よりも 24764 においては 24509 ているが 24095 ても 22715 にかけて 22410 にて 22061 とも 20988 だったが 20078 てきた 18660 までは 15710 はの 15630 などで 15530 たものの 15429 などが 15169 うと 14569 へと 14314 までに 14160 にとって 13547 ていない 13388 たという 13324 でいる 12949 ずに 12844 についての 12823 のの 12695 でいた 12154 ので 12077 ほど 11709 のみ 11541 であると 11315 だと 11167 はという 11122 がと 11042 をと 11024 ていく 10883 てしまう 10794 などに 10719 においても 10605 にと 10454 を通じて 10373 たと 9804 だけでなく 9448 ての 9116 しか 9065 にの 9027 によっては 8952 かの 8682 であるという 8620 に関しては 8216 てしまった 8172 ほどの 8126 ていて 8058 はなく 8000 からも 7909 ては 7779 てくる 7631 てから 7518 にという 7329 つつ 7309
上位グループの順序は微妙に変わっている。助詞の位置が影響しているのだ。が、上位グループのメンバーはあまり変わらない。
学習データ作成時に、日本語wikipediaからのデータの体現部分はword2vecでウェイト化する。それを、これまで、mariadbに載せたウェイトにアクセスする形にしていたが、そうすると、アクセスのための時間がかかって、マルチスレッドでやっている意味がないほどに、時間がかかった。何しろ、6000万を超える４対語である。プログラムを45スレッド、CPUは24スレッドで処理したのだが、数スレッドしか実際に稼働しなかった。
そこで、元々のword2vecのバイナリファイルから、ウェイトを冒頭に全て読み込んで、データベースへのアクセスを不要にしたら、一挙に処理速度があがった。数十倍早くなったと思う。当初は、十数時間かかりそうだったのに。
ロボットが知識データを言い換える時に、助詞を適切なものに切り替える必要があり、前後の体言や助詞からそれを推計するシステムを作ったと、先の記事で書いた。そのシステムを、いざ、即興漫才システムに組み込もうとした時に、いくつか問題が起こって、最初のデータから作り直すことにした。
まず、助詞だけにして助動詞を対象から外していたのを、加える必要がある。名詞や動詞が連続する場合、１語として扱えるようにする。助詞、助動詞も連続して現れる可能性があるので、それも対応する必要があった。
データ作成は、まず、日本語wikipediaから、元データを作成する。基本的に、文章の中にある、
体言１（動詞、名詞） → 助詞２（助動詞も）→ 体言３→ 助詞３（助動詞も）
という４つの語の流れを拾ってくる。例えば、次のようなものである。
肥満::は::一般的::に 一般的::に::正常::な 正常::な::状態::に 状態::に::比べ::て 比べ::て::体重::が 体脂肪::が::過剰::に 過剰::に::蓄積し::た 蓄積し::た::状況::を ある生存中::の::当事者同士::が 当事者同士::が::有効::に 有効::に::成立し::た 成立し::た::婚姻::を 婚姻::を::婚姻後::に 婚姻後::に::生じ::た 生じ::た::事情::を 事情::を::理由::として 理由::として::将来::に 将来::に::向かっ::て 向かっ::て::解消すること::を ペットボトル::は::合成樹脂::の 合成樹脂::の::一種::である 一種::である::ポリエチレンテレフタラート::を ポリエチレンテレフタラート::を::材料::として パンダ::は::ネコ目::に ネコ目::に::属するジャイアントパンダ::と 属するジャイアントパンダ::と::レッサーパンダ::の レッサーパンダ::の::2種::に対する 2種::に対する::概念上::の 概念上::の::総称::である
この助詞１を体言１、体言２、助詞２から推計しようというのである。後者をword2vecのベクトルデータを用いるなどして入力データに変換して、出力が助詞１のいずれかに推計する。
上記の４語のデータを、日本語wikipediaデータについて、すべてやる。日本語wikipediaデータは、word2vecの時に使用下処理済みデータを用いる。
24スレッドをフル稼働させるプログラムにしたら、10分程度で、全データを処理終えて、４つの語の組み合わせを、63,600,830個拾い出してきた。6千万個以上である。すごい。データは、2ギガくらいのファイルに保存んした。