前回から3ヶ月ほど経過。
ようやく30万データを突破しました。

■データの取得先について
対話データについてはTwitterから拾ってきてます。
（貴方の発言がひっそりと雛ちゃんに拾われてる・・・かも）

TwitterAPIの制限上、常にデータを取得できるわけではないので、学習速度のスピードアップができないのがもどかしい。
大雑把に平均は約6万データ/月となりました。
このまま行くと100万データ突破まで丸1年くらいかかりそう。
効率化してるとは言え、多く見積もっても学習量の上限は10万/月くらいなんじゃないかと。
Twitter側からブロックされない事を祈りつつ今日もAPIを叩く作業。

文章まるごとから単語ベースにシフトしたいと思いつつ、結局文章ベースでやってます。
意味解析とか文脈解析辺りでぼんやり思ってるのは、やっぱりフレームワークとして辞書なり正規表現を使うなりでパターンを定義しなきゃならないかなぁと。

以下、 対話データ10万～30万までに試した対話ログ抜粋
（下に行くに連れてデータ保有量が上がっています）

・拒絶
naoe：おひさ
雛：来ないでwwww糞だからwwww
naoe：学習が進むにつれ話しかけるのが怖くなってきた
雛：大丈夫ですよ！
naoe：ほんとかよ・・・

続きを読む »

人工無脳用の対話データを収集していますが、被るデータが大量に出ています。

重複レコードをそのまま放置してても無駄に肥満化するだけなので、お掃除してあげます。

—————————————————————–
対話データテーブル名：talkdata
一時退避先テーブル名：temp
—————————————————————–

退避先の空テーブルをコピーして作成
create table temp like talkdata

tempへ重複レコードを除去しつつコピー
insert into temp select distinct * from talkdata;

対話データテーブルを空にする
truncate talkdata

tempから対話データテーブルにコピー
insert into talkdata select * from temp;

—————————————————————–
重複データ除去おわり。カラムの指定とかもできます。が、必要ないのでやってないです。
ユニークを一つだけ残してくれるのでとってもありがたい。

取得データの登録時に重複チェックをやればいいのですが、データ取得毎にチェックしてたら鈍亀になるので上記の定期除去にしました。
ローカルで稼働させてる現状、レコード数が数十万程度じゃやってもやらなくてもあんまり変わらなかったりしますが。

↑と全く関係ないけど、on duplicate key update とか地味に便利。
趣味でやる分には、思うように動けばいいんです。

参考：重複行を除外(ALL, DISTINCT) – データの取得 – MySQLの使い方

以下久しぶりの対話抜粋

ボルトのくだりは奇跡の返答。

現状、対話学習はセミオートなので、完全自律してるわけじゃないのです。
学習スピードはスロー。とは言えユニークデータで10万突破しました。
100万くらい行ったらどうなるか楽しみ半分、何も変わらないかもしれない不安が半分。

8月9日は厄日。
丁度雛ちゃんの人工無脳も制作してるということで、久しぶりに描きました。

イラスト自体は約1年ぶり、全身を描いたのは約2年ぶり。

工程とか。2年前のと比べるとマシになりました。

厄神様の人工無脳制作
イラストには対話データ15,000レコードと書いてありますが、この記事を書いてる段階で約20,000レコードになりました。
底引き網漁ごとく根こそぎデータを攫っているので、学習スピードはまずまず早い・・・かと。
1億レコードで動かしてる所もあるらしいので、限界点に達するまで まだまだ余裕があります。
対話のメインテーブルはMyISAMで運用。他のテーブルは気分次第。適当。

発言の抽出・会話の継続についてはちょっと詰まり気味。
APIを利用して会話ログから重要キーワードの取り出しを行なってますが、これが話題のキーワードとして直結していない場面も多々あり、別の手段を講じなければならない模様。
まだまだ課題は山積みでございます。

現状、5％くらいまともにキャッチボールしてくれます。
残り95％は好き勝手に大暴投します。コントロールG。

そんな5％の対話抜粋はRead moreからどうぞ。
続きを読む »

ちょっと前から再び挑戦スタートしてます。引き続きPHPにて。
3回目ともなると、PHPやDBでどうプログラムを記述するのか詰まっていた所が少なくなってきました。
3回目になっても会話ロジックについてサッパリなのは変わりませんが。

——————————————————————————————

■現行（Ver3）について
データ登録
原文＋形態素解析文＋原文の次の文章　をセットで登録。
現状、発言部分のデータは創作からの加工品

発言ロジ
対話者の発言をNgram（もしくは形態素）で分割してデータベースに登録した形態素解析文を検索。
と、同時に過去の会話から重要キーワードを取り出し、検索キーに追加。
と、同時にDBのwith query expansionなど、おもしろそうな機能は解放。
発言する文章は、単語を組み立てるのではなく、登録した発言データをそのまま返す。
対話で学習していく機能はつけてない。

メリット
データが増えれば増えるほど自動で返答バリエーションが増えます。（当然か）
LIKE検索を使ってないのでデータベースが肥大化しても検索がクソ早い（はず）です。
単語からの組立ではなく、登録した返答文をそのまま返すので、日本語でおｋ的な文章がほぼ皆無。

デメリット
データを用意するのが著しく面倒。既存の物があれば緩和。
データの精度を上げようとするととても面倒。
話題の扱いが不十分なので、話題があっちに飛んだり、こっちに飛んだり一貫性がありません。
意図しない返答が多数含まれる。
単語で学習しないので、保有データに対して伸びシロが案外少ない。

——————————————————————————————

現状はとてつもなくシンプル。
TwitterBotとの連携は現状コアができてないので組んでません。
前Verの感情については未対応。前Verは単語区切りで、今回は1文単位のデータ区切りにしているので。そのうちこっちでも入れてみたいなぁと。
現行VerはローカルPC環境で稼働させてるので、むちゃくちゃなPHPでも、ブンブンDB振り回しても迷惑をかけない。
感情DBをペロペロしまくって共用鯖がえらいことになったのが懐かしい。

あと、品詞区切りのデータ登録をやめた理由は、
・普段、イチイチ品詞を気にして文章を組み立てて喋ってないと思った
・パターンを大量に用意していけば良い感じになるんじゃね？という淡い期待（これは単語でも同じか）

ですよ。
結局のところ不明点ばかり。品詞も実は気にしないとダメかもしれないしねぇ。
それじゃ、以下（Read moreクリックで）現行Verの対話抜粋です。
続きを読む »

人工無脳制作。
次の取っ掛かりとして感情判定いれてみる事にしました。
感情の分類については8種（Plutchik’s wheel of emotionsから採用）に設定しています。
が、ここで重大な問題が発生してます。

【サーバーの負荷メーター】

ぐーん

ぐーーーーん

ぐーーーーーーーーーーーーーん
負荷かけまくりやん。

赤の部分で負荷増大疑惑。

感情DBと比較する時に、結構な回数でDBをペロペロするので、負荷がえらい事になってるみたいです。
何回か動かすとレッドゾーン。共用サーバーでこれはマズイ。
管理者からの警告は今のところ無いですが、対策しないと凍結食らってしまうかもです。
いよいよ自前で環境用意しないといかんか・・・？
用意するにしてもすぐは難しいので比較の仕方を変えて一先ず負荷を抑えようと思います。はい。

返答文の生成部分については、ずっと考えてますが妙案が浮かばず保留中。

とてもフランクな雛さん。

以前からのプログラムを少しずつ改修してますが、現在のロジックでの伸び白が無くなってきました。シンプルが故にすぐ頭打ちになってしもた。
そろそろ次の段階へ進みたいのですが、取っ掛かりがいまいちつかめず、データを食べさせては調整している次第。
オウム返し形式ですが、たまにまともな返答がくるのでこれはこれでおもしろくて良いのではないかとも。

以下会話キャプチャ
続きを読む »

数年前に制作したTwitterBOTを再度いじくってます。性懲りも無く。
プログラムとデータベースは残っていたので、それらを改良する感じで。
Cronを仕掛けていないので現在自動応答はしませんが。

Twitterへの投稿についてはEasyBotterをベースにしています。
学習機能と学習した言葉を喋る部分について拡張してあります。
学習は形態素解析で分割したものをDBに登録。
喋る部分は、もらったリプライを分割して適当な単語でDBに検索をかけて、携帯の予測変換形式で文章を組み立てて喋ります。
BOTはRubyとかPythonとかがメジャー？ですが、PHPでやってます。

事前に特定の言葉に反応するデータを用意してそれを喋らせるのもいいですが、意味不明なことを喋りまくる学習型も楽しいです。

以下（Read more）1対1の対話キャプチャ。
続きを読む »