PyCon JP 2014に参加した

データ解析や機械学習の話が気になったので、PyCon JP 2014に参加した。
PyCon JP 2014 - connpass


会場に電源とれる場所が少なく、あまりメモ取れてなかったので、記憶をたどりながら書いてるけどあんまり覚えてない。

http://www.slideshare.net/atelierhide/py-conjp2014-slideshare
画像認識にDeep Learningを使ってKaggleであった犬の画像か猫の画像かを識別するコンテキストに参加した話で、Deep Learning(PythonのDeCAF)使ったら精度95%以上になったらしい。

http://www.slideshare.net/hamukazu/effective-numerical-computation-in-num-py-and-scipy
numpyとscipyにおける効率的な数値計算について。broadcastやindexを使うとか。

Introduction to scientific programming in python // Speaker Deck
numpy, scipy, matplotlib, scikit-learn, pandasの説明とデモ。ipython使おうというのとnumpyはjuliaよりそんなに遅くないという話をしていた気がする。

ツイートを感情分析する話。公開されているコーパスと感情語辞書を利用してNaive Bayesを使ってポジネガ判定する。精度は49%らしい。厳しい...。
最先端だと70%くらいだろうけど、せめて60%くらいは出ていて欲しいな...、英語だとコーパスとか辞書が整備されているのでうらやましい。

http://nbviewer.ipython.org/github/payashim/tutorial-opencv-python-pyconjp2014/blob/master/pyconjp2014_payashim.ipynb
OpenCVを使った画像/動画処理。OpenCVではBGRで、matplotlib, scikit-imageなどではRGBで色を保持しているので注意が必要らしい。画像処理詳しくないので背景差分とかあんまり知らない話が聞けて楽しかった。

スパム分類を機械学習(Naive Bayes)でやる話で、学習を約10行、テストを約5行でかけて簡単。関係ないけど、テキスト分類軽くしましたという話しを聞くとだいたいNaive Bayesなのはなんでなんだろう、SVMの方が精度高くでるだろうからSVM使えばいいのにとか思ってしまう。

大きい会議になると聴講者のレベルがわからないから話すの難しいそうだなと感じた。全員に分かってもらおうとして初心者でも分かる内容にすると中級者、上級者には少しもの足りなく感じてしまう。一応スピーカーが対象レベルとして初級と中級みたいに選んではいるけど、結局広く知ってもらおうとするとどうしても初心者よりになってしまいそうで、もう少し突っ込んだ話を聞きたいと思うことが何度かあった。

セッションの1つにJob Fairというのがあって、何社かが自社の開発環境とかについて話していた。結構、SlackとJIRAを使っているところが多くて、流行ってるんだなーと思った。JIRAは使ったことないけど、便利そう。

企業ブースみたいなところで、キュレーションサービスのカメリオを作っている方と少しお話をさせてもらった。テーマをどうやって選んでいるか、他のキュレーションサービスとの違い、今後どのように収益化するのかなど色々聞かせてもらっておもしろかった。

懇親会ではエンジニアのイベントに来ているのに気づいたら周りはみんな研究者や研究関係の仕事をしている方になっていておもしろかった。Web系のエンジニアとまったく話してない気がする。これもpythonが科学技術系でよく使われてるからなんだろう。それでもおもしろかったので良かった。

テキストマイニングシンポジウムに参加した

テキストマイニングシンポジウムに参加した。
第5回 テキストマイニング・シンポジウム:参加募集 - 言語理解とコミュニケーション研究会


1日目は企業の方の話が多めで公にできないことも結構あるみたいだった。

  • Twitterから抽出したプロファイルデータと購買データを組み合わせた次世代型ハイブリッド・ターゲティング

楽天NTTデータの人の話。
最初は楽天の人の話で、既存のマーケティング手法には限界があるので、Twitterなどのソーシャルなデータを活用するというもの。リコメンドで問題になる購入履歴のないユーザへの問題(コールドスタート)をTwitterのデータが活用すると緩和ができる。メールの開封率やコンバージョンを購入履歴に基づいたものとTwitterデータを活用したものなどで比較していたのがおもしろかった。
次にNTTデータの人の話。ツイートに対して、キーワード抽出やカテゴリ分類、ポジネガ判定を行っていた。なんかとにかくすごい。NTTデータというかNTT研究所がこれまで10年、20年と作ってきた辞書のなせる業(アルゴリズムもすごいだろうけど)という感じで、真似できる感じは全くしなかった。

Watsonで培った技術を基に構築したIBM Watson Content Analyticsというテキストマイニングのシステムについての話。コールセンターのデータを使ってデモをしていて、「画面がでない」がどのくらい問い合わせられてるかを簡単に可視化できる。構文解析や固有表現抽出、評判分析など深い言語処理もしているようだった。

見える化エンジン」というテキストマイニングシステムの話。ポジネガ判定の結果をアバターを使ってビジュアライズしているのがおもしろかった。それと、消費がモノからコトへ変化しているという話で、キットカットの例をあげて、メッセージをつけてキットカットをプレゼントしたというツイートをきっかけに、キットカットにメッセージなどを書けるようにして、食べるシーンを含めて売るようになったというのはなるほどなと思った。


2日目は学術よりな話。

  • ヤフージャパンのリアルタイム検索における感情分析

一番聞きたかった話。というか、元々は「ニュース記事へのユーザコメントに対する感情分析」という内容だったのでそっちの方が聞きたかったんだけど、途中で内容が変わってしまっていた。
内容はツイートの感情分析。ポジティブ、ネガティブ、ニュートラルの3種類の分類器(SVM)を作って、それを使ってツイートを分類する。素性には単語unigram, bigramと文字trigram、感情語の語彙リスト、顔文字リストを利用。ツイートみたいな文章だと形態素解析に失敗する可能性が高いから文字trigram入れてるのかな。あと、語彙リスト、顔文字リストをシードにしてラベルなしデータとの間で情報伝播して新たな感情語を取得していて参考になった。

ニコニコ動画のコメントが動画全体に対するコメントか動画の一部に対するコメントかユーザに対するコメントかを識別する。ユーザの中でも視聴者同士のコメントのやりとりを識別できるとおもしろそうだなーと思った。ブコメでも同じようなことできるとおもしろそうだ。

8月末あたりに開催されたCOLING2014に参加した方がおもしろそうな論文をピックアップして紹介。
感情分析に関する論文を取り上げてもらったので良かった。特にBest Paperの「A context-based model for Sentiment Analysis in Twitter」はどういう話か気になっていたので良かった。ツイートの感情分析でコンテキスト(前後のツイートや同ハッシュタグ)を利用した話で、結論としては単に前後のツイートを使うだけではあまり効果はなくて、ハッシュタグのように内容のあるコンテキストは効果があるらしい。余裕があったら今度読んでみよう。


久しぶりに研究会に参加した。もっとこじんまりとした研究会かと思ってたけど、200人くらい参加していて驚いた。感情分析とかテキストマイニングとかやりたくて、ちょっと来てみたけど、こういう場にくると研究したくなる。やっぱりエンジニア系のConferenceとは少し雰囲気が違う気がする。

Scala Matsuri 2014に参加した

もう1週間くらい前になるけど、Scala Matsuri 2014に参加した。
ScalaMatsuri 2014 - Scala Matsuri 2014 | Doorkeeper


今年は?Scalaを作ったOdersky先生がいらっしゃていて基調講演などをされていた。

メモ程度に気になった発表を残しておく。

http://www.slideshare.net/brikis98/nodejs-vs-play-framework-with-japanese-subtitles
node.js と play を10の視点からそれぞれを10点満点で比較していて、合計点はなんとnode.jsの勝ちだった。それでいいのかという感じだけどおもしろかった。

Code Generatorの話。言語によって実装が変わらない部分は自動化しようというもの。自動化によってコードの品質が底上げされる?みたいな話だった気がするけど、よくわからなかった。

Twitterで使われているScalding, Storm, Summingbirdの話。Summingbirdは環境構築が大変らしい。Sparkもそうなんだろうけど、こういうデータ処理系のものがローカル環境で気軽に(セットアップすれば)動かせるのはよさそうだなと思う。

Dwango mobileで大相撲アプリをScalaで作ったという話。phpつらいし、Javaもいやで、Scalaにしたという感じだった。サービスの構成やNon-Stop Deployingなど結構Mackerelと似ているところもあって参考になった。Scalaをどう学んだかという話もあって、毎朝1時間、チームのみんなでコップ本(Scalaスケーラブルプログラミング)を読んでいたらしい。業務の中で勉強の時間をとっているのは良いなーと思った。

聞いてないけど、TLではすごい盛り上がってた。Databricks - The next generation of Big Data の話で、発表中にグラフ描画してたりしたらしい。



Scala使い始めてまだ半年だし、ちゃんとScala使いこなせている感じはあまりしていないのでどうなるかと思ったけど、割と楽しめた。とはいえ、言語仕様とかちゃんと理解してないところもあるのでよくわからないところもあったし、マクロの話もあったけどなんか怖かったので聞いてない。
LL系からScalaに変えたという話がいくつかあったけど、結構Javaを書いてる人も多いのかなという感じだった。
これまで学術的な学会にしか参加したことなくて、エンジニアの大きめのConferenceに始めて参加した。やっぱり少し違うなーという感じがした。

「ビジネス活用事例で学ぶデータサイエンス入門」を読んだ

最近、データ分析に興味があるので、「ビジネス活用事例で学ぶデータサイエンス入門」を読んでみた。

ビジネス活用事例で学ぶ データサイエンス入門

ビジネス活用事例で学ぶ データサイエンス入門

1章でデータ分析について簡単に説明して、2章で以下のデータ分析のフローを紹介、
1. 現状とあるべき姿
2. 問題発見
3. データの収集と加工
4. データ分析
5. アクション
それ以降はこのフローに則って、3~6章に基礎的な内容、7~10章に応用的な内容が書かれている。


内容としては、ソーシャルゲーム会社のゲームアプリの諸問題を改善するのにデータ分析を利用するというシナリオになっていて、具体例をあげながら、フローに沿って説明されるのでわかりやすい。
書面の都合上、2の問題発見の部分が結構さらっと書かれていたりするけど、実際には1度で正解が導けることはないだろうから、色々思考錯誤するんだろう。
前に少しグロースハック的なことをしたときには、問題をどこまで細分化するかとか、この部分で結構色々悩んだ気がする。
このあたりは実際に業務とかでやって、経験的にしか学べないことも結構多いんだろうなと思うとなかなか難しい。
とはいえ、ざっくりと分析のフローが知れるので読んでみてよかった。


本には分析で利用しているRのコードが載っているので、実際に動かすといいんだけどまだやれてない。
というか、Rのコードあんまり書く気になれないので、pythonで書き直してみるか、julia触ってみたいのでjuliaで書いてみようかな。


本とは少し関係ないけど、気になるのはこういうデータ分析みたいなのはどの程度の規模のサービス、製品に対してなら有効かということ。始まったばかりのサービスに対しては、データ分析をしてもあんまり意味ないというか、データ分析より機能追加とかやるべきことがたくさんある。なので、ある程度成熟したサービスでやることが最も効果的なんだろうと思うんだけど、その境界がどのへんにあって、どういう感じで決めるものなのかなと思った。まあ、もちろん規模だけじゃなくて、ソーシャルゲームみたいなお金に直結するサービスでは必要性が高いとかサービスの性質も関係あるだろうけど。


そういえば、DATA SCIENCE FESTIVAL RECOMMEND CONTESTとかやってるみたいだから余裕があったらやってみたい

CabochaとComainuをDockerで動かす

下の記事を見て、研究とかで使われるツールでちょっとインストールとかが複雑なものはもうDockerで配布したほうがいいのかなと思った。
専門用語を自動抽出するTermExtractをDockerで簡単に使えるようにしました - CreateField Blog

なので、試しにCabochaとComainuをDockerで動かせるようにしてみた。

Cabocha(日本語構文解析器)

Cabochaのインストールはそんなに複雑じゃないけど、--enable-utf8-only(CabochaというかMeCabだけど) みたいなの毎回気にしなくて良くなくなる。
今回は辞書にはUnidicを利用

docker pullして

$ docker pull skozawa/cabocha-unidic

docker runすればCabochaが使えるようになる。

$ echo "太郎は花子が読んでいる本を次郎に渡した" | docker run -i skozawa/cabocha-unidic cabocha
    太郎は---------D
      花子が-D     |
    読んでいる-D   |
            本を---D
            次郎に-D
              渡した
EOS

MeCabも入ってるからMeCabも使える

$ echo "太郎は花子が読んでいる本を次郎に渡した" | sudo docker run -i skozawa/cabocha-unidic mecab   
太郎	タロー	タロウ	タロウ	名詞-固有名詞-人名-名		
は	ワ	ハ	は	助詞-係助詞		
花子	ハナコ	ハナコ	ハナコ	名詞-固有名詞-人名-名		
が	ガ	ガ	が	助詞-格助詞		
読ん	ヨン	ヨム	読む	動詞-一般	五段-マ行	連用形-撥音便
で	デ	テ	て	助詞-接続助詞		
いる	イル	イル	居る	動詞-非自立可能	上一段-ア行	連体形-一般
本	ホン	ホン	本	名詞-普通名詞-一般		
を	オ	ヲ	を	助詞-格助詞		
次郎	ジロー	ジロウ	ジロウ	名詞-固有名詞-人名-名		
に	ニ	ニ	に	助詞-格助詞		
渡し	ワタシ	ワタス	渡す	動詞-一般	五段-サ行	連用形-一般
た	タ	タ	た	助動詞	助動詞-タ	終止形-一般
EOS

https://registry.hub.docker.com/u/skozawa/cabocha-unidic/

Comainu(中・長単位解析器)

Comainuは依存ツールが結構あってインストールするの面倒なので、Dockerで使えると便利な気がする。

こっちもdocker pullしてrunすれば使える。

$ docker pull skozawa/comainu

XML版のUnidic2がまだ公開されてない影響で標準エラーにメッセージだしてるので、-a stdin -a stdout だけ指定して、stderrは出力しないようにしてる。

$ echo "固有名詞に関する論文を執筆した" | docker run -i -a stdin -a stdout skozawa/comainu comainu plain2longout
B    固有    コユー     コユウ  固有    名詞-普通名詞-形状詞可能                        名詞-普通名詞-一般      *       *       コユウメイシ    固有名詞        固有名詞
        名詞    メーシ  メイシ  名詞    名詞-普通名詞-一般                      *       *       *       *       *       *
        に      ニ      ニ      に      助詞-格助詞                     助詞-格助詞     *       *       ニカンスル      に関する        に関する
        関する  カンスル        カンスル        関する  動詞-一般       サ行変格        連体形-一般     *       *       *       *       *       *
        論文    ロンブン        ロンブン        論文    名詞-普通名詞-一般                      名詞-普通名詞-一般      *       *       ロンブン        論文    論文
        を      オ      ヲ      を      助詞-格助詞                     助詞-格助詞     *       *       ヲ      を      を
        執筆    シッピツ        シッピツ        執筆    名詞-普通名詞-サ変可能                  動詞-一般       サ行変格        連用形-一般     シッピツスル    執筆する        執筆し
        し      シ      スル    為る    動詞-非自立可能 サ行変格        連用形-一般     *       *       *       *       *       *
        た      タ      タ      た      助動詞  助動詞-タ       終止形-一般     助動詞  助動詞-タ       終止形-一般     タ      た      た
EOS

https://registry.hub.docker.com/u/skozawa/comainu/


ちょっとインストールとか設定が面倒なツールとかはDockerにして配ればちょっと試したいくらいのときにも気軽に使えるしよさそう。ツール使いたいだけなのに、インストールに手間取って時間とられるのは不毛だし、どんどんDockerでも配布されるようになればいいんじゃないかと思った。まあ、ディスクサイズとられるのがちょっと辛いけど。

「ITビジネスの原理」を読んだ

「ITビジネスの原理」を読んだけど、個人的にはそんなに面白くなかった。


章構成は以下の通り。

  1. ITビジネスは何で稼いできたのか
  2. ネットが世界を細分化する
  3. ネットワークとコミュニケーション
  4. 消費されるコミュニケーション
  5. ITの目指すもの、向かう場所


1~4章は基本的なことが書いてある印象で、これまでのWebの流れやその中でどういう風にビジネスが行われてきたかが書かれてある。
Web業界あまり知らない人には面白いのかもしれない。

4章の終わりから5章ではハイコンテキストというキーワードを使って著者が一番言いたかったと思われることが書かれている。
商品やサービスの売り方として、アメリカ的なフォーマットが決まっていて必要な情報がきっちり書かれているローコンテキストなモノの売り方ではなく、商品とその商品にまつわる物語や売っている人との関係性を売るようなハイコンテキストなモノの売り方が重要となるというもので、前者がAmazon、後者が楽天らしい。あと、非言語コミュニケーションの話やウェアラブルデバイスの話も少し書いてあった。

5章のなかで、

  • コミュニケーションは共通語から多言語へ
  • 多言語から、さらに非言語へ

のような節があって、多言語化も非言語化もどっちも今後起きると思うので、それぞれはいいんだけど、多言語化はよりローカルへ、非言語化はよりグローバルへと方向性としては逆な気がするのでこの2つが連続して起きるような構成だったのはちょっと気になった。

主張としてはハイコンテキストなコミュニケーションが今後重要となるという話で、その点はそうだと思った。


ITビジネスの原理

ITビジネスの原理

文節境界解析のラベルと性能

文節境界解析で使うラベルで、BIとBILUの2種類でどちらが性能がよいかを検証してみた。結果的にはBIだけのほうが性能が高かった。


前回の輪読会で紹介した固有表現抽出に関する論文の中で印象に残ったことのひとつとして、系列ラベリングに使うラベルで最近はBIOよりもBILOUを使ったほう性能が高いというものがあった。
BIO(Begin, Inside, Outside)とBILOU(Begin, Inside, Last, Outside, Unit(Begin and Last))の違いは固有表現の末尾を考慮するかどうかで、末尾を考慮したほうが性能がよいというもの。
社内輪読会で「Joint Inference of Named Entity Recognition and Normalization for Tweets」を紹介した - skozawa's blog


Comainuでは、同じ系列ラベリングの問題である文節境界解析を行っていて、そこではラベルとしてBIを利用している。文節境界解析の場合、Oはないので、BかIを付与することになる。それで、文節境界解析でも固有表現抽出と同様にラベルとしてBILUを利用することで性能が向上するかを試してみた。


データはBCCWJの一部を学習データのサイズを変えながら試してみる。
学習のモデルはSVMで、素性は形態素情報(書字形、語彙素読み、語彙素、品詞、活用型、活用形、語種情報)と形態素が括弧内かどうかを表すラベル(BIO)。

テストデータ 学習データ1 学習データ2 学習データ3 学習データ4
文数 4534 4534 13602 22670 31738


結果としては、データサイズに関わらずBIの方がよかった。

- 学習データ1 学習データ2 学習データ3 学習データ4
BI 95.96 96.87 97.29 97.57
BILU 95.81 96.81 97.28 97.52


BIとBILUでの誤りを軽く調べてみたけど(「/」が文節境界)、BIのモデルでは形態素間をくっつける傾向にあって、BILUのモデルだと分割する傾向があった。BILUのほうは「ガッカリ/する」とか、それを分割してしまうのかというのもちらほらあって、分割しすぎて性能が下がっていそうだった。

モデル
BI 反論して / きています。 反論してきています。
BI 滞在費 / 全て 滞在費全て
BILU つくっていった。 つくって / いった。
BILU ガッカリする。 ガッカリ / する。

文節境界解析だと、Lを求めるのはほぼBを求めることと同じなので、Lを導入してもあまり性能はよくならなかったのかな。それに、BIだけのOがないタスクだと2値分類なので、BILUで多値分類にすることで問題が複雑になったのかもしれない。

関係ないけど、実験中にComainuのバグを見つけてしまったので、とりあえずやってよかった。
モデルの再学習しないといけないので、今度やってアップデートしよう...