![[PukiWiki Adv.]](/LiplisWiki/Webroot/image/pukiwiki_adv.logo.png){kind=logo}
|
| Liplisの設定はこちら |
SQLServer2014にしましたが、またもデータが溜まってきて、
少しパフォーマンスが落ちてきました。
2008R2だった場合、現在の1/3くらいの容量で止まってしまう
レベルでしたが、今回は一応まだ大丈夫そうです。
しかし、このままいくとまたダメになりそうなので、
Liplisのニュースやツイートの配信を行うデータベースは
完全にテンポラリにしてしまおうと思います。
設定的には1週間のデータしか引っ張れないようになっていますし、
あまり古いデータを引っ張っても仕方ないので、
影響は無いと思えます。
このため、配信データは半月ほど保持するようにして、
この容量を保つようにしたいと思います。
そして別途学習用のデータベースを作っておき、
使えるようにしようと思います。
今度は、学習用DBのパフォーマンスをいかに上げるかって
ところですが・・・。
ここで列指向DBを使うときがくるか・・・？
会話データもカサンドラを捨てて、SQLサーバーに収集し始めましたし。
今までホームにおけるウィジェットと言ったら、
Android独自のものでしたが、どうやらiPhoneにも搭載されるようです。
しかし、通知領域に表示されるものということで、
Liplisを載せることができるかは未知数です。
マックはあるけど、アイフォーンの実機が無い・・・。
第五世代型iPodTouchがありますが、壊れてしまっているし・・・。
iPhone6をスタートダッシュで買う気は起きません。
5sが型落ちで安くなることを期待してみましょうか。
落ち着いたら、色々やろうと思っているのですが、一向に落ちつかないです・・・。
今も、リリちゃんリニューバージョンにかかっていますし。
落ち着いたらやろうと思っていたことの１つ。
おもむろに置いてあるこのパソコン、Clalisのデータベースサーバーです。
この娘をラックに収めねばという話です。。
6月に新サーバーを構築してからずっとこのまま。
LANケーブルや電源ケーブルが仮設状態なので、危険・・・。
忙しいということもありますが、おいそれと止められないので、
ずっとこの状態に・・・。
来週辺り、フロント側に縮退して、サっと収めてしまいますかね・・・。
リリ Renewの各感情の立ち絵の配分を考えるために、
どのくらい感情値がバラけるか、統計的に確認してみました。
詳しい数字は以下のページに記載しました。
https://liplis.mine.nu/lipliswiki/webroot/?技術資料 感情値の出現頻度
うれしい/かなしいが結構高い割合になりました。
出現率が高いところに注力するのが費用対効果が大きそう・・・。
プラスの感情が多いのは、比較的楽しい話題を収集するように
仕向けているからだと思われます。
焦燥、軽蔑、無関心、呆れ、驚き-
このあたりのマイナスの感情は、設定している単語が少ないこともあり、
出現率が低くなっていると思われます。
立ち絵としては集約してしまっても問題が無いと考えられるところですね・・・。
全体を見ると、割りといいバラけ具合だと思います。
Clalis4.0のおしゃべりの動きを見て、それなりに
バラけているなーと思っていましたが、
データからも見て取ることが出来ました。
今月でちょうど携帯電話の契約が2年になり、今の機種の支払いが終わったので、
頃合いということも有り、機種変更することにしました。
現機種は「Xperia GX」。
良い機種です。アップデートで、Android4.2にもなっていますし。
しかし、バッテリーがバテてきているのと、
残メモリーがかなり少なくなってきていました。
LiplisのテストAPKをインストールしまくってということもありますが・・・。
ということで、次に選んだ機種はこれ！ Xperia Z2
http://www.sonymobile.co.jp/xperia/docomo/so-03f/
どうやら人気があって、在庫が無いとのことでした・・・。
Z3が9月に出るという話もありましたが、
スペックはあまり変わらなそうなので、注文という形で予約してきました。
下の設計でデータを集め始めたので、試しに検索してみたのですが、
どうもおかしい。むしろ凄いとも言える結果ですが・・。
"艦これ"という単語が含まれる会話データを抽出した結果です。
この結果の5行目を抽出すると以下のようになっています。
初、戦艦が6回目の戦艦レシピ建造でやって来てくれました。良かった。 おお！おめでとうございます。 ウチも初戦艦は榛名でしたねぇ。燃費もいいし使いやすい艦ですよ。 そして、なにより良い娘。 僕が使う艦は性格キツイ娘が多いので癒されますね・・・。
一見、何の変哲もないツイッターの会話ですが、
この文章の中に「艦これ」というワードがありません・・・。
なんてホラーな話でしょうか・・・。
会話のツイートのURLも記録しているので、実際のツイートを
確認しましたが、やはり「艦これ」の文字はありませんでした。
データも調べましたが、特に問題がありません。
しかし、内容はかなり的を得た内容になっています。
戦艦とか榛名とか、のワードから連想されたとしか思えません。
SQLServerにセマンティクス検索なる機能があるのは知っていましたが、
この検索でも有効になっているのでしょうか。
ちょっと調べてみる必要があります。
むしろこれはとても使えるのではとも思います。
2～3日前の日記で、会話データの学習をし始めたと書きました。
インデックスをどうするかという話で、bigintの限界から、キーをvarcharにしていました。
会社の昼休みに、フルテキストインデックスのマニュアルを読んでいました。
その中で、パフォーマンスに関する記事がありました。
http://msdn.microsoft.com/ja-JP/library/cc879244(v=sql.105).aspx
フルテキスト キー列として、サイズの小さい列を選択します。 900 バイトの列がサポートされていますが、 フルテキスト インデックスでは比較的小さいキー列を使用することをお勧めします。 int および bigint を使用すると、最適なパフォーマンスが得られます。
やっぱりキーは整数型が良いようですね・・・。
まだ最初であり作りなおすのは余裕なので、やっぱりbigintとすることにしました。
最終的な設計としては以下のようなモデルになりました。
今回の会話データ学習機能では、
ツイッターのリプライのツイートを検索し、
それをタネに、芋づる式に前後の会話データを引っ張り、
学習していきます。
まず、最初にヒットしたツイートのIDをキーとします。
最初は、全てのツイートをユニークに管理しようとして、
管理用の番号を後ろに付けようとしていました。
これでは文字にせざるを得ないので・・・。
ピックアップしたツイートのツイートIDをキーとし、
会話内容をDESCTIPTIONフィールドに全ての会話データをぶち込みます。
ここにフルテキストインデックスを貼り、
単語から会話を引っ張れるようにしました。
これが良い設計かどうかは分かりませんが、
回して、試行錯誤していくしかなさそうです。
今まではCassandraにテスト的に会話学習データを格納していましたが、
大量のデータが入るのは良かったのですが、知識としてシステムに
組み込むのは使い勝手が悪く、難しい状態でした。
今回の用途には合わなかったということでしょう。
メインデータベースがSQLServer2014になっているので、
多少大きいデータも格納できるでしょうということで、
SQLServerで本格的に学習を開始しました。
Cassandraのときは自作インデックスを使おうとしていましたが、
SQLServerなのでフルテキストインデックスを有効に使えそうです。
多少データが溜まらないことには知識として使うのは難しそうです。
まずはゲージが貯まるのを待つとしましょうか。
会話データの学習にツイッターデータを使おうとしています。
今までCassandraのデータベースに入れていましたが、使い勝手が悪すぎるので、
見直し中です。
SQLServerにテーブルを作り、データを入れようとしました。
キー値としてTwitterID+サブIDとして、ユニークな値をつくろうとしています。
型をbigintとしたところ、オーバーフロー・・・。
まさかbigintがオーバーフローするとはおもいませんでした。
仕様を確認すると・・・
http://msdn.microsoft.com/ja-jp/library/ms187745.aspx
9223372036854775807(19桁)
ツイッターIDが18桁の数値でしたので、2桁の数値をくっつけたところで、
オーバーフローでした。
あまり良くないですが、varcharにしておきました。
MySQLが文字化けした場合、「/etc/my.cnf」にしかるべき設定を行えば、
解消されます。
ところが、CentOs scl mysq55をインストールした場合は、
「/opt/rh/mysql55/root/etc/my.cnf」の設定が有効となるようです。
「/etc/my.cnf」をひたすら修正していましたが、当然治らず、
全てをアンインストールした後に、この情報に会いました。
下記のページに注意点として書いてありました・・・。
http://qiita.com/wakisuke/items/b42011eaa72ba8a7ce4b
再インストールにとてもハマりましたが、なんとかインストールしなおして、
ようやっと日本語のフルテキスト検索が行える環境が構築出来ました。
しかし、Mecabのフルテキストインデックスはいいなぁ。
SQLServerのハイブリットとかやりたくはないので、やらないですけど、
選択肢の１つとして知っておいて損はない知識だと思いました。
MySQLの文字化けが治らないので、再度インストールすることにしました。
そこで、今あるデータをエキスポートしておく必要が出てきました。
調べたところ、以下のようなコマンドでダンプできるようです。
MySQLのダンプコマンドは・・・。
mysqldump -u testuser -p test_db test_table > db_backup_`date +%Y%m%d-%H%M%S`.sql
出力して中身を確認すると、DDLとともに、データのインサート文が
出力されていました。
そのまま投げればスンナリ入りそうです。
インポートするには・・・。
mysql> source dump.sql
ダンプデータの中身がSQL文でしたので、そのまま実行されるだけですね。
シンプルでいいね！
この仕様はSQLServerやDB2よりもいいかも。
下記サイトを参考にしました。
http://napzak.com/tips/?MySQLのダンプ（エクスポート）、インポート、バックアップ
新DBサーバーにて、突然Cドライブの残り容量が0となってしまいました。
データベース起因かなぁと思いつつ調べましたが、
どうもハイバーネーション(休止設定)が原因ということが分かりました。
実際のファイル容量と残り容量の計算が合わない・・・。
合わない分は、ハイバーネーションの復帰用の保存データに
使われているようでした。
解決には、以下のサイトが参考になりました。
http://posokosi.seesaa.net/article/159543625.html
メモリーは16GB乗っているので、それは、たくさんの領域が
使われていたことでしょう・・・。
ハイバーネーション設定をOFFにし、再起動したところ、
容量は確保されました。
しかし600MB・・・。まだ少ないです。
Windowsアップデートを実行したところ、3GB程度空きができました。
自動ダウンロードのアップデートデータがあったようです。
少ないっちゃ少ないですが、システムが停止するおそれは無くなりました。
いつもであれば、新しい機能の開発に着手しているところですが、
今回は、のばさんより、立ち絵を仕様をもう要求されているため、
そちらの作業を優先させなければならず、着手しています。
例年、コミケの2ヶ月前くらいからの着手となっています。。
立ち絵の完成がいつもギリギリなので、調整時間が少なくて、
問題ではあります・・・。
この問題を改善する意味においても、今から着手、ということです。
良い物ができるようにがんばりたいと思います。
githubでは、コミットの履歴が見られるようになっているのですね。
PukiwikiAdvの更新履歴がgithubのリンクになっていて、知りました。
せっかくOSSとしているので、こういう情報をのこしておくのも
良いかもしれません。
前回の不具合修正が以下のような感じで、参照できます。
https://github.com/LipliStyle/Liplis-Windows/commit/5de1e018012e581a74610ccc6032e19a8ccf71bb
コミケ前までは時間を確保するために、やるべき仕事があっても、
家に帰ってRJバージョンの作業をしていました(爆)。
社畜の風上にもおけない行いですが、その分コミケが終わったら頑張るってことで・・・。
今日は会社の作業をしていました。
ビックデータを研究するようなプロジェクトに参加していますが、
研究だけに、安くやりましょうってことでOSSを使うことになっています。
会社では普段、OracleかDB2を使っていますが、OSSを使うってことで、
CASSANDRAとMYSQLを使うことになっています。
CASSANDRAはちょっと扱いづらいので、僕はMYSQLを使うことにしました。
昔、ムーバブルタイプを使ってブログを書いていた頃は、MYSQLを使っていたりもしたのですが、
それ以来めっきりつかていませんでした。
実行環境もOSSってことでCentOS。
最初は面倒かとも思いましたが、SSHトンネルとWinSCPがあれば、
ほとんどWindowsから操作できるので、ほとんど不自由していません。
さて、本題ですが、
普段Clalisシステムで使っているSQLServerであれば、
全文検索はデフォルトで備わっていて、簡単に使えました。
MYSqlでも全文検索したいと思っていました。
最初は自分で検索インデックスをつくろうともしましたが、
処理が煩雑になるのと、実行速度が遅すぎて、どうにかならなかと・・・。
そこで、調べたところ出来そうでした。
Mroonga(むるんが)というものをMySQLのプラグインとして使えば良いようです。
形態素解析インデックスを作るのに、メカブも使えちゃったり。
まず、当たったのが以下のスライド。わかりやすかったです。
http://www.slideshare.net/yoyamasaki/mysqlmroonga
以下のものをインストールすれば良いようでした。
早速インストール。ちょっとハマりました。
(というか最終的にまだ未解決)
ムルンガとMYSQLのバージョンが一致しないと、ダメみたいでした。
以下のサイトの記事が同じ状況で、とても分かりやすくて捗りました。
http://nob-log.info/2012/03/22/install-mroonga/
最終的にMySQL5.5をインストールし、導入に成功しました。
しかしながら、文字化けが全然解消できない・・・。
MySQL5.1を導入したときもそうだったので、
my.cnfの設定をすれば、解消できるのだろうなと予想しました。
以下のサイト等を参考に、my.cnfを調整するも、解消できず・・・。
http://kennyqi.com/archives/334.html
サーバーとデータベースのキャラクターセットがUTF8にならない！
設定は正しいはずなのに・・・。
テーブルにフルテキストインデックスは付けられたけど、
文字化けするもんで全く役にたたず・・・。どうしたもんかねぇ。
明日、もうちょっとがんばってみます。
会社で開発した、サーバーに保存した図面データをブラウザで
検索、表示できるシステムがあります。
普通に使ってる文には問題なかったのですが、
画像を差し替えたのに、古い画像から変化しないとの連絡が・・・。
キャッシュの問題だろうとすぐに予想がつきましたが、
キャッシュ対策はおこなっていました。
以下のような方法。会社の環境はIEのみ使用可なので。
http://support.microsoft.com/kb/234067/ja
ブラウザの設定を変更して、キャッシュを使わないようにしたところ、
新しいファイルが表示されるようになりました。
暫定対応としては良かったですが、ユーザーみんなにブラウザの
設定変更をお願いするのもどうかと・・・。
ということで、対策が無いか会社のスーパーSEな人に良い方法を教えて頂きました。
以下のページの5番目に書かれている方法です。
http://www.okushin.co.jp/kodanuki_note/2011/05/ie.html
画像URLのケツにランダムで適当なGETパラメーターを付けてやると
参照ごとに違うURLとなり、ブラウザに常に新しいページと認識され、
キャッシュされずに画像が表示されました。
解決できてよかった！
冬コミの申し込み、完了しました。
ペーパーにも書いていたのですが、
冬コミはリリちゃんのリニューアルバージョンを予定しいてます。
Windows版のリリちゃんを出して4年目になります。
リリちゃんにはかなり思い入れがあるので、新しいキャラクターを作るのではなく、
あくまで、パワーアップさせたいと言う思いがあります。
色々なキャラクターを制作してきて、ノウハウが蓄積されてきたので、
さらにかわいくできるのではないかなと思っています。
あとは、新機能に合わせてという意図もあります。
まだまだやるべきこと、やりたいことがたくさんです。
やっと色々落ち着いたので、艦これを再開！
情報が大分出揃っているようですが、苦戦を強いられそうです・・・。
最初は出し惜しみをすべきとの情報を得ていますが、
２軍だと流石にきついです・・・・。
根性でE1突破・・・。春雨ちゃんGET.
情報がなかったら相当厳しかったです。
6/24～28で中国に行ってました。
準備とか色々あり、とても忙しく、Liplisの開発に手が回せませんでした。
7月になって、ようやっと落ち着いたので、
6月の初めに行おうとしていた、Liplisのアップデート作業行うことにしました。
しかし、データベースの調子がいまいち良くない。
この問題をなんとかしない限りは、次に進みたくない感じでした。
Clalisシステムでは、これまで、SQLServer2008R2を使用してきました。
扱っているデータが肥大化してきており、
それにともなってかなりパフォーマンスが悪くなっていました。
チューニングもそれなりに行いましたが、
どうにもデータ量に勝てない・・・。
NoSQLの導入を検討していたのですが、
使い勝手が悪く、期待した性能が得られそうにありませんでした。
今年の４月に、SQLServer2014が出て、
バージョンアップしたらどうなるかと、検証を行っていましたが、
結構いい感じでした。
ということで、まずは、データベースのバージョンアップを行うことにしました。
ちょっと良くなかったのですが、裏っかわで縮退運転に移行させ、
メインデータベースを停止させて、バージョンアップを行っていました。
(このあたりの運用、もうちょっとちゃんとせねば・・・)
2つ分バージョンが一気に上がったのですが、
使い勝手は全く変わらずに、パフォーマンスが一気に良くなりました。
問題なく移行できたので、LiplisAndroidの最新版を公開したところです。
Windows版はあと少し、テストと準備を行います。
GWから6月までで、Liplis4.0の開発を進めてきました。
プログラムの問題やら、データの問題など、色々出ていて、
新しいバージョンとしてリリースするには問題がありました。
色々直してきて、ようやっと安定してきた感じです。
テストもひと通り回しましたので、
そろそろLiplis4.0をリリースしたいと思います。
とは言え、想定していた機能を全て盛り込めたわけではありませんでした。
おしゃべり応答機能やお天気おしゃべり機能等です。
夏コミまでの期間を考えると、このくらいかなと行った具合です。
仕事が忙しくてなかなか手が回らなかったり、
中国に行かなければならなくてガクブルしていたりで、
思ったように進んでいないというのが正直なところでした。
いつも通り？、ゆっくり進めて行きたいと思います。
今回の新作では、龍驤バージョンを開発しています。
初めて手に入れた軽空母で、最初からかなり思い入れがありました。
と言いながらも、実は今の龍驤ちゃんは3人め！？です・・・。
1世代目は、4-3で大破進撃をしてしまい、29lvで轟沈・・・。
この時、始めて1ヶ月くらい？で
トップが赤城36lvで、時点で龍驤29lvだったので、それはもうショックでした。
二度と大破進軍など、愚かなことはしないように心に決めました。
その後、すぐに取り戻そうと、GETを試みましたが、全然出なく、
轟沈した娘は二度と出てこないのではないかと疑いました・・・。
4-3がずっと怖くてクリアできなかったのですが、
ようやっとクリアしたときに、なんと龍驤ちゃんが来ました。
とても感慨深かったです。
2世代目は、5-2でデイリー消化もかねて回している途中で、
画面を見ずにプレイしていたところ、
いつの間にか轟沈していた・・・。90lvで轟沈・・・。
これは本当にひどい・・・。
4/30のGWの中日、会社で昼休みにやっていたときです。
もう放心してしまい、この日午後の仕事はほとんどやっていません(爆
提督を辞めようとまで思いました。
一晩寝て、起きてみたら、レベルソートでレベル1のところに、
龍驤ちゃんがいました。
「こんなところに居たのか！無事だったのだな！良かった！(白目)」
全然良くないですが、この時は本当にそう思わないと、
ダメになりそうでした。大げさですが・・・。
そんな感じで、今居るのがこの娘です・・・。
本当に、改二が来たことにはびっくりでした。
1月にはもう龍驤バージョンを作ると決めていましたが、
こういう流れになるとは思いませんでした。
上記のとおり、元々龍驤に思い入れがあったこと、
ちっちゃかわいくて、関西弁の口調がLiplisにぴったり
だったことから、作ってみたくなりました。
関西弁がうまく表現できたらと思っているのですが、
ネットの評判を見ると、
龍驤の関西弁設定事態謎であること、関西人から言わせたら、
龍驤の関西弁はダメ？
のようなものがあります。
この辺も含めて龍驤の口調が再現できたらと思いっています。
龍驤本とかも参考にして、再現していく予定です。
Liplis Windows4.0では、タッチ機能も追加しています。
こういったネタ的にもマッチしそうです。
ともあれ、おたのしみに！
今年は、ずっと仕事が忙しくて、Liplisの開発作業をほそぼそと進めていました。
2月くらいから、「Liplis感情データベースの見直し」と、「感情評価方法の見直し」
の内容について、作業していました。
感情値の学習もかなりすすんできて、かなり良い物になってきました。
従来はプラスの感情にかなり偏っていた上に、感情付与処理にバグも
あり、マイナスの感情がほとんど付かないという状態でした。
と言いますか、実際は今リリースしているバージョン
(Liplis3.x系,Clalis3.x系)にその問題がそのまま残っています。
4.0がリリースできれば、一気にその問題が解消されます。
ただ、それだけのバージョンアップでは、インパクト？がちょっと少ないので、
GWに色々機能を追加する予定です。
まずは、やるべきことをまとめなくては・・・。
Clalisのデータベースには、SQLサーバーを使っていますが、
SQLServerの管理ツールである、「Sql Management Studio」の動作が
遅い問題が発生していましたが、以下のサイトのおかげで解決しました。
アジャイルプログラマの日常 SQL Server Management Studio が遅いときの Tips
http://d.hatena.ne.jp/fyts/20080408/slow
対処方法を抜粋すると、以下の3つ。
方法 1 (ヘルプをローカルに変更) 方法 2 (Microsoft にエラーを報告しない) 方法 3 (証明書をチェックしない) 推奨しない
全部一気にやったら解決してしまったので、
どれが原因かは分かりませんが、とにかくこの手順を踏んだら
治ってしまいました。
本当に快適になりました。
今まで、クエリーの結果の順序をランダムにするのに、「ORDER BY NEWID()」
を使用していましたが、これのせいで応答がかなり遅くなっていることが分かりました。
Clalis4.0を開発していて、SQLの応答が遅いなーと思っていましたが、
こいつが元凶でした。
今まではそこまで気になるほどのものではありませんでしたが、
データ量が増えてきたことが原因かもしれません。
しかし、時間範囲で絞り込んでからのOrderByなので、
なんでそんなに時間がかかるか解せない・・・。
もっと動作の仕様を調べないと分からなそうです。
とりあえず、対処療法的に外したところ、全然問題ない早さになりました。
一定件数取得して、時間やキーのソートとし、
あとはプログラムで混ぜるという方法に変更しました。
従来の処理も「ORDER BY NEWID()」を多用していて、
かなり応答が遅くなっていることに気づきました・・・。
ですので、本日Clalis3.2の処理も即急に修正した次第です。
使ってみた「word2vec」ですが、かなり良好な結果が得られたので、
.netからどうにか使うことができないかと色々調べてみました。
1.まずはIronPythonをダウンロード。
http://ironpython.net/
公式のダウンロードからしゅとくできました。
適当な場所にインストールしました。
2.setuptoolsのインストール
まずこれを入れなければ始まらないので入れます。
以下のページが参考になりました。
http://ironpython.codeplex.com/wikipage?title=setuptools
「ez_setup.py」をダウンロードして、IronPythonと同じ階層に配置。
以下のコマンドを実行しました。
ipy.exe ez_setup.py
以下のコマンドで、setuptoolsを最新にする。
ipy.exe "C:\IronPython 2.7\Scripts\easy_install" -U setuptools
3.pipをインストール
これまた必須なのでインストール
以下のコマンドを実行
ipy.exe "C:\IronPython 2.7\Scripts\easy_install" pip
一応、ここまでで、基本設定が完了。
ここからgensimをインストールする
4. numpy,scipyをインストール
まず、numpy,scipyが必要なので、インストールします。
以下のサイトが参考になりました。
http://xfra.me/20131020567/
「ironpkg-1.0.0.py 」をダウンロードし、コマンドを実行すれば良いようです。
(ググって、ダウンロードしました。)
以下のコマンドを実行
ipy.exe ironpkg-1.0.0.py --install ironpkg scipy ipy.exe -X:Frames -c "import scipy"
5. いざgensimインストール！
以下のコマンドを実行し、インストール開始
ipy.exe -X:Frames "C:\IronPython 2.7\Scripts\easy_install" -U gensim
しかし！エラーが出て進めず。
原因は「scipy」のバージョンが古いこと。ダウンロードされるが、インストールに失敗する。
C:\IronPython 2.7>ipy.exe "C:\IronPython 2.7\Scripts\easy_install" -U gensim C:\IronPython 2.7\Lib\weakref.py:1: DeprecationWarning: object.__init__() takes no parameters for type KeyedRef """Weak reference support for Python. Searching for gensim Reading https://pypi.python.org/simple/gensim/ Best match: gensim 0.9.0 Processing gensim-0.9.0-py2.7.egg gensim 0.9.0 is already the active version in easy-install.pth Using c:\ironpython 2.7\lib\site-packages\gensim-0.9.0-py2.7.egg Processing dependencies for gensim Searching for scipy>=0.7.0 Reading https://pypi.python.org/simple/scipy/ Best match: scipy 0.13.3 Downloading https://pypi.python.org/packages/source/s/scipy/scipy-0.13.3.zip#md5 =20ff3a867cc5925ef1d654aed2ff7e88 Processing scipy-0.13.3.zip Writing c:\users\浩介\appdata\local\temp\easy_install-m680ae\scipy-0.13.3\setup. cfg Running scipy-0.13.3\setup.py -q bdist_egg --dist-dir c:\users\浩介\appdata\loca l\temp\easy_install-m680ae\scipy-0.13.3\egg-dist-tmp-aidj15 error: The process cannot access the file because it is being used by another pr ocess
権限の問題にも見えましたが、対処方法は見つからず・・・。
うーん、なんとか使いたいところです。
良い方法があればいいのですが。
昨日見つけた記事
http://antibayesian.hateblo.jp/entry/2014/03/10/001532
これを試してみました。
Pythonは使ったことがなかったの結構詰まりましたが、
なんとか書いてあるとおりのことができました。
Mecabは当然のように入っていたので、そのまま使いました。
ちょうどつい最近に辞書を作ったので、精度の良い辞書になっています。
艦むすの名前は大体入っていました。
さて、いざ実行してみると・・・。
収集するタイミング(収集されるデータ)によって大分結果が変わってました。
私が実行した結果としてはいかのような感じでした。
まず加賀
>>> s(['加賀']) 順位 キャラ名 類似度 1 赤城 0.839386 2 北上 0.816816 3 飛鷹 0.786195 4 飛龍 0.777274 5 榛名 0.761724
乳を引いてみる
>>> s(['加賀'],['乳']) 順位 キャラ名 類似度 1 飛鷹 0.592081 2 赤城 0.590115 3 麻耶 0.585689 4 翔鶴 0.585068 5 霧島 0.583345
飛鷹！
一応空母の分類ですし、乳の大きさも差し引きされているように見えます。
記事の最後にも書いてありますが、
結果は前処理やデータに依存するということみたいです。
当然と言えば当然ですが。
しかし、最低限、加賀→赤城と引かれているあたり、
関連語の抽出には使えそうな印象でした。
注目の技術です。
しかし、どうにか.netから使えないものでしょうか。
艦これをずっとやっていますが、色々アップデートがあるということで、
新海域の艦隊編成や、遠征の条件など調べたりしていました。
そんななか、以下のような記事をみつけました。
自然言語処理の最新手法"word2vec"で艦これ加賀さんから乳を引いてみる
http://antibayesian.hateblo.jp/entry/2014/03/10/001532
「word2vec」というもので、"意味"の計算ができるということらしいです。
ちょっと見てみると、ある単語と関連の深い単語を抽出したり、
その結果から、言葉で、引き算してみたり、ということができるようです。
関連語の抽出だけでも、感情学習にとても役立ちそうです。
早速使ってみようと思います。
最近はチマチマと感情辞書を作成していましたが、
ちょっとこれを使うと、色々と覆るものがありそうです。
またまたサーバーが不安定となってしまい、ご迷惑をおかけしました。
申し訳ありません。
今まで合った問題と比べて、とても悪い状態でした。
メインデータベースの調子が悪かったのですが、
レプリケーションしているフロントDBにもその状態が
伝搬しているようでした。
見た目のデータ上は問題なしだったので、単にデータ量が多くなっていた
ことが原因かと考えています。
ユーザータイムラインを保存するようにしてから、
データ量がかなり増えた印象です。
日々相当量のデータが蓄積されているので、
ちょっと対策を考えなければなりません。
最初は、Cassandraの影響かと思っていましたが、
全然関係ありませんでした。
ニュースやツイッターなどの大量の情報はCassandra側に
入れるような設計にした方がいい気がしてきています。
(運用してみると、また問題でるかもしれませんが)
先週から、Cassandraを触っています。
感情学習システムから入ろうと思ったのですが、会話パターンの学習を探求したくなってきて、
まずコチラから作成を始めました。
ツイッターのパブリックタイムラインから、
会話データを収集して、学習させています。
自作の形態素インデックス、センテンスインデックスの設定も良好。
会話データの学習もいい感じです。
しかし、ここまで完成させるまでに、結構ハマりました。
あまりにも基礎を理解していなかったので、ちょっと勉強もしました。
こんな本を買ってきました。
システム関連の本は、いきなり読むと眠くなるのですが、
ちょっと触ってから読むと、そうだったのか！という発見が原動力になるからか、
スラスラ読めます。
使用感や躓いた点をまとめると、以下のような感じです。
・Cassandraのテーブル設計
Cassandraでは、カラムファミリーというのが正しいでしょうか。
(なぜか、普通にCREATE TABLEでカラムファミリーが作れるようになっていますが。)
RDBMSを使って育ってきた私なのですが、普通に正規化して、テーブルを構築していました。
しかし！CassandraはJoinができない！もちろん外部キーもない！
NoSQL全般に言えることで、常識とも言えることですが、
身を持ってこの特性を学ぶことができました。
テーブル設計を大幅に見直しました。
・Like句が無い
ありません。あいまい検索はどないせいっちゅうねん！
普通にLike句を使ってSelectをかけたのですが、全然通らず、調べたところ、
Like句が無いと知りました。
この点に関しては、indexを自作するのが常套手段のようでした。
いやぁ、RDBは偉大だなぁと思いました。
n-gramや形態素解析した結果をインデックス化することで、
全文検索のインデックスとするのが一般的なようでした。
n-gramは精度が悪いので、形態素解析インデックスを作成するようにしました。
それに加えて、今回は会話データを効率よく引きたいので、
センテンス(文章)のインデックス、品詞パターンのインデックスも作成しました。
結果的に汎用のインデックスを使うより、かなり良い設計になったのではないかと思います。
・OrderByができない
OrderByでソートできません。
Cassandraに関して言えば、デフォルトでキーがソートされているようです。
つまることろ、キーでしかソートできないということです。
複合キーで、第一キーで絞り込んだ状態で、第二キーのソートはできました。
ソートを必要とするような実装をしてはいけないということでしょう。
・データの参照がしにくい
これは、プログラムから参照しにくいというわけではなく、
単にツールが無かったり、ODBC接続ができなく、簡単に一覧できないという意味です。
ここは、自分でツールを作っていくしかなさそうです。
ODBCドライバーがあれば大分扱いやすいのですが。
・書き込みと検索が異様に早い
狙い通りですが、とにかく速いです。
(さらにデータがたまった時どうなるかが問題ですが。)
会話データを、1分に500件分くらい書いています。
大したことなさそうですが、インデックスが結構膨大になります。
コンソールを見ていると、SQLServerに比べて大分高速に書けているように見えます。
・スケールアウトしやすい
3つくらいの項目を設定するだけで、複数ノードの動作となります。
全てのノードがいっぺんに壊れなければ、データが失われることはありません。
一般的なRDBのようなリッチなユーティリティは全くありません。
しかし、これくらいシンプルな方が扱いやすいです。
フロント側の処理分散、バックエンド側の処理分散という意味でも、
とても有効に動くデータベースだと思いました。
これからClalisシステムを発展させる上で活用できそうです。
大体こんなところです。
扱いには少し慣れてきた感じです。
引き続き、会話データの精度向上と、感情データベースの再構築を進めます。
もう少し進むと、いよいよLiplisの機能が実装できそうです。
Clalisシステムのデータベースには、SQLServerを使っています。
応答性能に問題がありませんが、ニュースデータが溜まってくると、
パフォーマンス低下したり、止まってしまったりします。
都度クリーンアップして対応していますが、
これから、おしゃべり機能を追加するにあたって、膨大な知識データ、
会話データが必要になります。
こういった大量のデータ処理を得意とするのが、NoSqlというやつらしいですね。
いわゆるビックデータを処理するのに使われたりするようです。
Clalisシステムに使えそうな物がないかと調べてみました。
現在は、色々な物があるようですが、しっくり来たのが「Cassandra」でした。
元々はフェイスブックで開発されたもので、ツイッターでも使われているらしいです。
導入方法等調べてみましたが、意外と結構古い情報ばかり。
最新バージョンは2.0.4でしたが、バージョン2以上の情報はほとんどナシ。
しかし、ありがたいことにかなり最近の記事を発見。
http://blogs.yahoo.co.jp/dk521123/32963992.html
すんなり動きました。
さらに、複数ノード動作を以下のサイトを参考に設定。
http://kaworu.jpn.org/kaworu/2012-05-19-1.php
こちらは古い情報でしたが、修正部分のアタリを付けるには十分。
並列動作もスンナリいきました。
NoSQLは、RDBとは全く違っていて、
また扱い方を覚えなければならないと思っていました。
しかし、新しいCassandraでは、CQLなるものが使えるようです。
さらにさらに、バージョン2以上であれば、トランザクションも
サポートされているとか。
なんかもうRDBと変わらないじゃん、と。
流石にジョインとかは出来ないのでしょうけど、
そこは設計と実装でカバーできると思いますし。
CQLのリファレンス的な情報が以下にありました。ちょっと古いですけど。
http://kaworu.jpn.org/kaworu/2012-05-27-1.php
環境が整ったところで、
データが取れるように、活用できるようにしなければなりません。
Javaの情報が多い印象でした。
C#からアクセスしたかったのですが、ほとんど情報がありませんでした。
以下のサイトが参考になりそうでした。
http://symfoware.blog68.fc2.com/blog-entry-429.html
真似してやってみましたが、うまくいかず、
キースペースにアクセスをかけようとしたところでエラー。
良い資料が無いかとさらに探していたところ、
GitHubにとても良い物がありました。
https://github.com/pchalamet/cassandra-sharp
C#から使えるライブラリで、リードミーに書かれているサンプルが
そのまま動きました。
データの挿入のサンプルはありませんでしたが、
以下のようなコードでデータ挿入できました。(.net4.5でしか動きません)
public static async Task insertTest()
{
XmlConfigurator.Configure();
using (ICluster cluster = ClusterManager.GetCluster("Clalis Cluster"))
{
ICqlCommand cmd = cluster.CreatePocoCommand();
const string cqlKeyspaces = "INSERT INTO clalistest.cf (KEY, col1, col2, col3) VALUES ('b', 'b1', 'b2', 'b3'); ";
await cmd.Execute(cqlKeyspaces).AsFuture();
}
ClusterManager.Shutdown();
}
非同期のメソッドが使える！
こういうコードを見るとワクワクしてきます。
今まで.net4.0で実装していましたが、
そろそろ時代にのりますかね。
CQLがそのまんま使えるので、
RDBを扱うのとホント変わらない感じです。
今日でカサンドラが扱えるようになったので、
明日は早速学習システムを作っていきます。
現在のLiplisの感情の判断ですが、なかなか正確とは言いがたいです。
特定の感情が埋もれてしまい、なかなか出てこない問題があります。
感情データベースの精度が低いことも原因なのですが、
文章に対する感情の評価にも改善の余地があると考えています。
現在の感情の評価方法は以下のような感じで、単語ごとに感情を評価し、
表情やポーズを変えています。
しかしこれだと、特定の感情が出現しても、すぐに他の感情に切り替わってしまい、
せっかくの感情表現ができなくなっています。
例えば以下のような動きです。
ノーマル→かなしい→うれしい→ノーマル
この例の場合は、「かなしい」の表情が一瞬で切り替わってしまいます。
では、どうすれば、うまい具合になるか・・・？
フレーズごとに感情を評価する方法に変更するアイデアがあります。
以下のような感じです。
フレーズで単位で求められた感情をベースにおしゃべりさせます。
このようにすると、感情が崩れにくくなるのではなかと考えています。
さらに、フレーズの感情を算出した上で、単語ごとの
感情も複合的に評価するというのもアリかもしれません。
あとは、品詞レベルでも、感情変化を表現できないかとおもっています。
例えば、「～ない」のような否定系が来た場合には、マイナス評価、
「しかし」のような接続詞が来たら、感情を反転させるなどです。
このあたりのアイデアを実験してみて、しっくり来る形で
改善したいと思います。
年始に、感情の項目整理から始めようと目標を立てていましたが、
このあたりの仕様が固まってきたので、まとめておこうと思います。
元々、プルチックさんの「感情の輪」を元に、Liplisの感情を定義していました。
しかし、これが本当に良いのか？冗長なのでは無いか？あったほうが、かわいくなる
感情があるのではないか？などと思い始めていたので、再考してみることにしました。
そもそも感情とか表情ってどんなパターンがあるのか、
まずはそこからまとめることにしました。
まとまった感情集などで、以下のものを参考にしました。
12表情
http://dic.pixiv.net/a/表情練習
表情35
http://dic.pixiv.net/a/表情35
スピノザの感情
http://nam-students.blogspot.jp/2010/09/blog-post.html
Wikipedia 感情の一覧
http://ja.wikipedia.org/wiki/感情の一覧
感情を割り切る-進化で答える人間行動
http://www004.upp.so-net.ne.jp/kaysaka/draft/1e-qa.htm
全部まとめると、以下のようになります。
結構被っている感情もありますが、流石に多いです。
今ある感情、無い感情を振り分けて、Liplisのおしゃべりの際に
ふさわしい感情かどうかも含めて検討しました。
その結果、以下のようになりました。
何も変わっていない・・・！
どういうことなのか！？
ピックアップした感情に、今ある感情を割り当てていきました。
当然、該当しない感情もあったのですが、結果としてはほとんどが20個の感情で
包含できるのできる印象でした。(これは、私の主観ではありますが・・・。)
となると、無理して追加する意味があまり無いのではないかという結論に至りました。
最後の最後まで、「照れ」と「強がり」を新しく追加するかどうか悩みました。
でも、「焦り」の感情で、包含できるかな・・・、と。
また、別の検討事項として、不安、嫌悪、不快など、似た感情な気がして、
統合しようとも考えました。
しかし、Liplisの表現の幅を狭めてしまうことになるため、統合はやめました。
以上のような葛藤があったところで、結局現状のままとなりました。
ただし、一部感情の呼び名は変えました。
(驚き- → ショック、不安 → 恐怖)
結局のところ、プルチックの感情の輪は結構万能だなと思いました。
もし何か、こういった感情や表情、表現が出来たほうがいいのではないかという
ご意見がありましたら、ぜひ教えて下さい！
次回は、感情の評価方法の変更点について書きたいと思います。
1月中旬から最近まで、Windows版に関して沢山のお問い合わせを頂きました。
ほとんどがバグに関するものでした。
新しいことに執着するあまり、
テストが疎かになる部分が多く、申し訳なく思います。
プログラム、WEB側の処理、色々なところにバグがありましたが、
ほとんど原因が分かり、対処ができました。
不具合のご報告は本当に助かります。
ご連絡頂いた方々、改めてありがとうございます。
これからも、問題への対応は出来る限り迅速に
対応していきたいと思っています。
ClalisForLiplisのツイッターへの投稿が停止していました。
TwitterAPIの仕様変更のようでした。
このあたりのニュースが参考になりました。
http://news.mynavi.jp/news/2014/01/16/459/
httpのアクセスが廃止になり、
httpsでないとアクセスができなくなったとのことでした。
なので、処理の変更としては、
http://api.twitter.com/1.1/statuses/update.json
だったところを
https://api.twitter.com/1.1/statuses/update.json
とすることで動くようになりました。
1年に1回は仕様変更がありますね・・・。
Liplisのツイッターおしゃべりの方は影響なしです。
twitter4jやTweetSharpがうまく動いてくれているようです。
先週はフリーワードおしゃべりの機能に浮気していましたが、
トラブルもあり中断していました。
単純にLiplisを改造して機能を作成しようかと考えていたのですが、
途中で新しいアイデアが浮かんできました。
Liplisに通信インターフェースを作成して、
おしゃべり内容を受信して、おしゃべりできたらいいのではないかと。
その作業にかかろうとしたところで、トラブル発生でした。
このアイデアは改造計画に組み込むとして、
キリがいいので、計画通り、サーバー側の処理の改善を進めています。
以前より、WEBから取得した情報の要約処理が、
うまくいっていない部分があり、とても気になっていました。
まずはこの部分から改善を進めることにしました。
NReadabillityというC#のオープンソースライブラリを使って要約の処理を行っていましたが、
うまく要約できるサイトと、できないサイトがありました。
できないサイトについては、WEBブラウザーコンポーネントに読み込ませて、
Elementを操作して、WEBサイトの内容を抽出するなどという処理を行っています。
ちょっとスマートではないです。
NReadabillityも海外製のライブラリということもあり、
今後このあたりが改善されるかはかなり微妙なところなので、
全て自力で機能を作成することにしました。
さて、どうやろうかねってところで、色々考えています。
以下のサイトのコードを使ってうまくできないかなと考えています。
自由に使って良いと書かれていますので、クラスまるまる取り込んで使っています。
http://d.hatena.ne.jp/siokoshou/20070315
実際にかなりうまくいった感じですが、
まだ1パターンしかまわしてないので、これから検証です。