集めたツイート数が5000万を超えた

去年の12月から間を開けながらボツボツと集めたツイートが今日の時点で、55,227,803ツイート、ファイルサイズにして738Mbになった。プロセス1個で集めている。プロセスを増やしても、ツイッターアプリ経由で捉えられる(ツイッター社がサンプルで配信する)ツイートは同じものであるので無駄なのだ。地道に集めるしかない。プロセス増やしても、たくさん集まった気になるだけで中身は、単なる水ぶくれになる。プロセスは1個しかダメなのだ。

でも、まあ、ほぼ1年動かしているので、季節による言葉の方よりはだいぶなくなっていると思うので、ここらあたりで締めようと思う。ただ、ツイートの取得はずっと続けていくつもりだ。

1億を目指している。キリがいいので。

当面やりたいのは、ツイッターで使われている単語の頻度を分析することだ。

日本語wikipediaにおける助詞・助動詞の使用頻度

先のいくつかの記事で示しているように、ロボットが知識的文章を短く語る時に、削除した語を繋ぐ助詞をAI的に選択させようとしている。(体言1:名詞・動詞)+(助詞1:助詞・助動詞)+(体言2:名詞・動詞)+(助詞2:助詞・助動詞)の語の並びの中で、体言1、体言2、助詞2が与えられた時に適切な、助詞1を選択させたい。これができれば、うまく、文章を短くできるだろうということである。

そこで、この並びを、日本語wikipediaの前文から拾い出して、それを元に、ディープラーニング用の学習データを作ろうということである。

4語対は、6千万個取れて、語は、word2vecのウェイトベクトルであらわすのだが、そのベクトルを取れる語は、さらに半分以下になってしまう。また、助詞、助動詞部分のパーターンがとてつもなく大きくなってしまう。「の」とか「を」などはたくさんあるが、全体で1回しか現れないようなものも拾ってしまう。これは、広い方のアルゴリズムにも依存するのだが。

そこで、いったいどのような助詞、助動詞が、どのような頻度で現れているのかを調べてみた。

まず、助詞2(ニューラルネットの入力になる)は次のようになっている。

の 	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

上位グループの順序は微妙に変わっている。助詞の位置が影響しているのだ。が、上位グループのメンバーはあまり変わらない。

助詞推定AIの改訂(1)

ロボットが知識データを言い換える時に、助詞を適切なものに切り替える必要があり、前後の体言や助詞からそれを推計するシステムを作ったと、先の記事で書いた。そのシステムを、いざ、即興漫才システムに組み込もうとした時に、いくつか問題が起こって、最初のデータから作り直すことにした。

まず、助詞だけにして助動詞を対象から外していたのを、加える必要がある。名詞や動詞が連続する場合、1語として扱えるようにする。助詞、助動詞も連続して現れる可能性があるので、それも対応する必要があった。

データ作成は、まず、日本語wikipediaから、元データを作成する。基本的に、文章の中にある、

体言1(動詞、名詞) → 助詞2(助動詞も)→ 体言3→ 助詞3(助動詞も)

という4つの語の流れを拾ってくる。例えば、次のようなものである。

肥満::は::一般的::に
一般的::に::正常::な
正常::な::状態::に
状態::に::比べ::て
比べ::て::体重::が
体脂肪::が::過剰::に
過剰::に::蓄積し::た
蓄積し::た::状況::を

ある生存中::の::当事者同士::が
当事者同士::が::有効::に
有効::に::成立し::た
成立し::た::婚姻::を
婚姻::を::婚姻後::に
婚姻後::に::生じ::た
生じ::た::事情::を
事情::を::理由::として
理由::として::将来::に
将来::に::向かっ::て
向かっ::て::解消すること::を

ペットボトル::は::合成樹脂::の
合成樹脂::の::一種::である
一種::である::ポリエチレンテレフタラート::を
ポリエチレンテレフタラート::を::材料::として

パンダ::は::ネコ目::に
ネコ目::に::属するジャイアントパンダ::と
属するジャイアントパンダ::と::レッサーパンダ::の
レッサーパンダ::の::2種::に対する
2種::に対する::概念上::の
概念上::の::総称::である

この助詞1を体言1、体言2、助詞2から推計しようというのである。後者をword2vecのベクトルデータを用いるなどして入力データに変換して、出力が助詞1のいずれかに推計する。

上記の4語のデータを、日本語wikipediaデータについて、すべてやる。日本語wikipediaデータは、word2vecの時に使用下処理済みデータを用いる。

24スレッドをフル稼働させるプログラムにしたら、10分程度で、全データを処理終えて、4つの語の組み合わせを、63,600,830個拾い出してきた。6千万個以上である。すごい。データは、2ギガくらいのファイルに保存んした。

音声認識から音声合成への一連の手続きの覚書

RaspberryPi上で、Juliusを使って音声認識させ、open_jtalkで音声合成し、音声を出力するまでの一連の手続きの覚書である。
まず、juliusについては、ダウンロードしてコンパイルするだけで良い。ただし、 --enable-words-intオプションをつけたほうが良いかと思うが、現状していない。いずれ、制約が大きいと感じたら、こんんパイルし直せば良い。-mictypeも指定していなかったと思う。記憶は定かではない。
Juliusには、音響モデルと言語モデルが必要なのだが、このキットがダウンロードできる。最終的には、用途にあったモデルを作成する必要があるが、そう難しくはない。『音声認識システム第2版』などを参考にするとよくわかる。
キットを使う場合にはいくつか注意が必要だ。まず、前提として、macで同じことをやろうとすると、juliusをモジュールモードにした時にコマンドが正常に働かない。juiiusをjavaからコントロールする場合、ネットワークソケットを経由するのが最も便利だ。他に、ライブラリのlibjuliusだけを用いて、それをjavaのjnaを使って、javaから呼び出す方法も考えられるが、文字コード変換機能を自前で用意しなければならなかったり(そう難しくないようだ)、いろいろなコマンドを制御しなければならないので面倒になる。
Macでコマンドが働かないと言うのは、音声を喋らせているときは認識をPAUSEしなければ、喋っている音声を認識してしまうので、エコー化してしまう。それが終わったらRESUMEコマンドで再度認識させるようにしなければならないのだが、MACの場合、一旦PUASEしてしまうと再度、RESUMEしても、なぜだか認識するようにならないのだ。いろいろ探ったがダメだった。諦めた。本来、RaspberryPIで動けば良いので、macの問題は無視することにした。RaspberryPIの場合は、PAUSEとRESUMEコマンドは正常に機能する。
次に、文字認識キットの使用方法についてだ。当面使うのがいいと思うが、juliusのサイトには3種類置かれている。ディクテーションキットと話し言葉モデルキットが使われるべきだと思う。まず、後者は、dnn、すなわち深層ニューラルネットが使われているものであり、前者は、深層ニューラルネットとGMMの二つがある。基本、DMMモデルは認識が遅い。時間がかかる。
前者で、GMMを使うときのコマンドラインは、ディクテーションキットがあるディレクトリで、
julius -C main.jconf -C am-gmm.jconf
とやる。モジュールモードにするときは、
julius -C main.jconf -C am-gmm.jconf -module
とすれば良い。ディクテーションキットのdnnを使うときは、
julius -C main.jconf -C am-dnn.jconf -dnnconf julius.dnnconf
と-dnnconfオプションが必要となる。モジュールにする場合は、先と同様に-moduleを付け加えれば良い。
話し言葉キットの場合は、そのディレクトリで、
julius -C main.jconf -dnnconf main.dnnconf
とする。これについては、フォルダに、run.batがあるので、それを確認すれば良い。
次に、open_jtalkを使った音声合成である。
/usr/bin/open_jtalk -m /usr/share/hts-voice/Mei/mei_normal.htsvoice -x /var/lib/mecab/dic/open-jtalk/naist-jdic
の後に-owで出力のwavファイル名を指定して、その後にテキストファイルを直接指定する。上記は女性の声になる。女性の声を入れて置かなければならない。
できたwavファイルについては、aplayで発声させるのであるが、先の記事にも書いたように、
aplay -D plughw:2,0 test.wav
でオプションをつけないと音はならない。
デバイス番号については、
cat /proc/asound/cards
で調べる。私の場合は、
0  [Device         ]: USB-Audio - USB PnP Audio Device
C-Media Electronics Inc. USB PnP Audio Device at usb-3f980000.usb-1.5, full spe
1 [ALSA           ]: bcm2835 - bcm2835 ALSA
bcm2835 ALSA
2 [DAC            ]: USB-Audio - USB Audio DAC
Burr-Brown from TI USB Audio DAC at usb-3f980000.usb-1.3, full speed
で、DACは2番なのだ。
ボリュームについては、
alsamixer -c 2
で、調整する。10Wx2では、相当小さくしないと、うるさい。

word2vecでロボットに言葉の演算をやらせた

この間、ずっとはまっていたのは、word2vecを使い、wikipediaに登場する単語を演算可能にすることだった。そこに、ボケの匂いを感じたのだ。word2vecは、ニューラルネットを使って、言葉を数量ベクトル化する手法だ。すると、言葉の演算がベクトル演算に変化できて、面白い結果が出てくる。
http://www.blog.umentu.work/ubuntu-word2vec%E3%81%A7%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88wikipedia%E3%82%92%E8%87%AA%E7%84%B6%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/

http://qiita.com/tsuruchan/items/7d3af5c5e9182230db4e
を参考にした。
wikipediaデータをmecabで分かち書きした膨大な単語について、演算が可能になった。たとえば、
ギター+キーボード
という演算をやらせると「セッション」になるとか。面白い。ネタになる。
隠れユニット200個で、学習結果のウェイトマトリクスデータが、900メガバイトを超える。
このデータは、ロボットNAOのストレージには入らない。そこで、NAOのUSBポートからデータをロードしようとしたら、当然のことなのだが、mallocで確保しようとしたヒープのメモリが、確保できない。仕方がないので、このデータを処理するライブラリを、パソコン上において、naoqiのリモートライブラリとすることで解決した。
人工知能など、およそ、その機能をロボットに全部組み込む事は不可能なので、PC上のリモートライブラリにするのはある意味自然なのだが、ロボットを立ち上げ、さらにリモートでライブラリを立ち上げるのは面倒だ。
しかも、言葉の聞き取りは、これも実に面倒なのだが、qichatを使って、トリがを与え、ロボットに喋りかけた言葉をwav音声データにして、パソコン上のサーバーに送って、それをさらにrawデータに変換したりして、Google cloud APIの音声認識システムに送って、テキスト化し、それをまたパソコン上で、形態素分析して、必要なデータを取り出し、またロボットのqichatのスクリプトの中にイベントとして取り組むと言う、質面倒臭いことをやる。それで、10秒くらい使ってしまうのが痛い。
しかし、まあ、これで、結構な人工知能をロボットに組み込んだことになる。

形態素解析と係り受け解析

どちらもGoogle Cloud APIでできるのだが、もうひとつ、いいものだという実感がないので、日本で開発されたMecabとCabochをインストールしてみた。以前、kuromojiも動かしたことがあるので(このサイトにも掲載してある)その辺りはある程度わかっているが、どれをどのように使うのかという迷いはある。kuromojiで形態素解析をして、その要素を使うだけで良いような気もするが、係り受け解析は必要か。
Google Cloud APIのいいところは、rootの単語を拾い出すことのような気がする。
しばらく迷う必要がある。ただ、あと2週間以内に、ロボットにちょっとしたことをさせたいと思っている。
以下は、CaboChaでの出力の画像である。