追記（Twitterにおける日本語投稿の一傾向分析）

昨日の記事『Twitterにおける日本語投稿の一傾向分析』の補足

追記1

午前4時にその前後に比べて突出したつぶやきが数が発生している。
これは、次の記事によると午前4時につぶやくサービスがあるらしい。

午前4時に「なるほど四時じゃねーの」とつぶやくサービスが人気

グラフ化することで、そのサービスによるつぶやき群が特異点になっているのが見えてきた。
ただし、類似のサービスやボットは他にもあるので、特に排除の対象とは考えない。

追記2

上記のように、あるデータが特異な状況であると判断できるということは、基準値からの乖離具合から何らかのイベントの発生を判断することも可能だろうと推測できる。
例えば「バルス」とか「本田△」とかのつぶやき頻度をイベント発生ととらえると言うことである。
しかし、残念ながらデータがない…

と思ったのだが、今日の「龍馬伝　最終回」関連のつぶやきがかなり盛り上がったらしい。もしかしたら、なにか抽出できるかもしれない。これについては、後日分析して、なにか有意な結果が見られるようなら報告予定。

追記3

この分析は、除外した(日本語でないと判定した)データの影響をうけないことを前提としている。
他のtweetあるいはtwitterシステム的に影響があるのかどうかの確認は取れていない。

追記4

収集にはTwitterStreamingAPIを使用
現時点では、BASIC認証で使えるので、Twitterのアカウントさえあれば収集は誰でもできる。
使用に際しては、以下のサイトの情報を参考にした。

Streaming API Documentation
Twitter の Streaming API について
Twitter Streaming APIから日本語のつぶやきをPHPで取得する

Twitterにおける日本語投稿の一傾向分析：休日vs平日

［2010年10月における休日（土曜日、日曜日、祝日）と平日の日本語Tweet数の比較］

---

自然言語処理を行うにあたって、現在は大量のコーパスを利用することが多くなってきた。
インターネットが普及するにつれて、各ホームページ（およびその下位のウェブページ）、その次には、ブログデータの収集が主流だった。
ここ最近は、急速にユーザが増えているTwitterということになる。
ある調査では、日本語は英語に次いでTweet数が多いらしい。

Twitterのデータを使う利点は、その量とともに、即時性（リアルタイム性）にある。
最近では、Twitterデータを利用した様々なサイトやアプリが存在する。

この状況の中で、あえてTwitterと自然言語処理を結びつけて何かやるかどうかはもう少し考える必要がある。
しかし、いずれにせよ、状況分析くらいは行わないことには、お話にならない。
今回は、一般的な（突発事象のおこらない）状況において、時系列としてTweet数にどのような変動があるかについて、傾向を見てみた。

冒頭のグラフは、2010年10月における休日（土曜日、日曜日、祝日）と平日の日本語Tweet数の比較である。（次の収集条件で、ざっくりと傾向を見た）

• TwitterStreamingAPIによって収集。（全Tweetの約1%が流れてくる）
• 時間は日本時間の0時から24時に変換してある。（オリジナルはUTC）
• Tweet数は10分単位で集計。
• ひらがなかカタカナが含まれる文を日本語のTweetと判定。UserIDはみていない。
• 1ヶ月分のデータから、通信障害やシステム障害（受信側、Twitter側含む）による明らかな異常値を排除。
• それ以外の恣意的な操作は行わず。（Tweet内容はみていない）

時間表示が見づらいが、6時～18時に有意な違いがみられる。
休日は、朝から夜にかけて緩やかな上昇になっているのに対して、
平日には、8時（おそらく起床～通勤時）と13時（昼休み）にピークが出ている。
おそらくは、勤務時にはつぶやくことができないサラリーマンが、これに該当しているのだろう。

このグラフを見ての第一印象は

「日本人まじめじゃん」

というもの。サラリーマンの皆さんは仕事に集中している様子。（学生とか主婦とか、自宅警備員？の人たちもいるので、Tweet数がゼロになることはない。もちろん、その比率は不明なので、正確なところはわからないが。）

さて、これに自然言語処理を施すことで、どのように有意な構造を抽出していくかが悩みどころ

日記：自然言語処理のはずだが実は統計処理、と思っていたらGUIまでやらされている

　上司があるプログラムをクライアントにレビューしている。

　プログラムは、テキスト検索にちょっとした統計処理を加味することでテキストマイニングっぽい機能を追加したもの。自然言語処理といえなくもない。

　処理自体は単純だが、統計処理で時間がかかるので、データの持ち方と、計算のさせ方に工夫がある。といっても、文字列検索をTRIEにして、共起関係をHarwell-Boeing形式にしただけで、大したことはやっていない。
　でも、このあたりを、通常のアプリケーションプログラマーに任せると、そのまんま配列に格納して、とてもじゃないが、実時間に結果が帰ってこないので、こちらにおはちが回ってきた。

　そして、なぜかGUIまでも書くことになった。はい、データ構造とのすりあわせが必要という意図ですね。自分の専門外でも業務命令ならやるけど、実際うんざりしている。
　こういう些末の作業はは他のやつにやらせて、自然言語処理とかデータ構造周りを自分に集中的にやらせた方が効率がよいのに。とか考えているけど、上司には内緒である。

　そうこうしてできたプログラムを何度かレビューして、そのたびに手直し。先方も自然言語処理のことはわからないから、焦点はそこではなく、使い勝手＝GUIになってしまい、その修正指示がくる。文句を腹にしまい込んで、対応するが。

　レビューを何回か繰り返しているが、修正は結局GUIがメインで、アルゴリズム的な部分は表示条件の設定調整程度。
　でも、今回は、速度優先というリクエストだったので、精度的にはそんなによくないけど、それでいいのか？
　まだ、デモ段階らしいからいいんだけど、現実に適用しようとすると、データ量とか、いろいろな問題が出てきて、計算アルゴリズムとかも変えないといけないんだけど、今言っても「まず動くものを見せるのが先決」ということで、聞く耳を持ってくれないので、後々やることになるだろう作業を考えて戦々恐々としている。

　まあ、仕事とは、往々にしてこんなもんである。こちらの思惑とは違うところで進んでいく。

自然言語処理とプログラミングと設計

ちょっと前の記事ですが、最近知って読みました。

プログラミングと設計は本来切り離せないものなのでは（達人プログラマーを目指して）

プログラミングという世界全体を見ると、完全に同意です。
そして更に、自然言語処理という世界から見ると、より厳しくなっていきます。

>> そういった設計は事前に設計図上で時間をかけて検討するということは可能であり、

自然言語処理においては、昔も今も、事前設計が可能だとは限りません。
なぜなら、自然言語処理プログラムおいては要求仕様（ユーザが期待する機能・性能）を100%実現することは出来ないからです。

たとえば、電卓プログラムを例にとって考えてみましょう。
人間は、時間をかければ計算できます。でも、省力化したい。そこで電卓が活躍します。
これは、100%実現可能です。事前設計も100％可能です。（GUIの調整などは除く、機能の話です）

それでは、たとえば、仮名漢字変換を例にとってみましょう。
人間は、辞書を引きさえすれば漢字にすることは可能です。でも省力化したい。そこで仮名漢字変換システムが活躍します。
これは、100%実現することは不可能です。なぜなら、実は人間でさえ間違えることがあるから。
「かのう」を漢字にしてみましょう。ここまでの文の流れから「可能」を思いつくと思います。
しかし、本当は「叶」「化膿」「加納」…どれが正しいのでしょうか？
ユーザに取ってみれば、その中の一つであることは自明なのですが、単純に辞書引きでは決定できません。これを改善するために様々な技術開発がなされていますが、未だ完璧ではありません。

物事が出来ないというとき、いくつかの段階があると考えています。

　(0) 社員のやる気がない
　(1) 社内のリソース不足（人手／時間／技術力・能力）
　(2) 世の中に、実現するための技術が、（現在）存在しない
　　　ただし、近似的に実現する技術は存在する
　(3) それを実現することは、未来永劫不可能である

0番は論外ですが、自然言語処理関係のプログラムでは、1番か2番あるいはその狭間で悩んでいるのが現実ではないでしょうか。
しかし、自然言語処理が何たるかを正しく理解しない、管理職や経営者は、簡単に製品化が実現するものと思い込んでしまいます。
もちろん、彼らも、過去においては、同じような問題に直面していたのかもしれませんが、それを解決したと勘違いしているに過ぎません。それは、上記の2番での「近似的に実現する技術」を用いることによってです。
それまで、0点だったものを80点、90点にしたことによるインパクトは大きいです。
ところが、90点から95点に引き上げるためには別の技術が必要で、95点から99点にするためには更に別の技術が必要です。

話が少しずれてしまいました。
自然言語のおける技術は、本質的には近似解を求める技術の固まりであると考えられます。
問題は、どの技術／方法が、その時点での解決法として最適であるかと言うことです。
自然言語では同じ意図を表すのに無数の表現が存在します。
そして、その境界を決めることはきわめて困難です。

従って、現実的な対応としたら、やってみて、文句が出たら修正する。ということになりましょうか。
もう少し、堅い言い回しをすれば、「アジャイル開発的手法を用いて、ユーザの要求の変化に対して柔軟に対処する」ということです。

※もちろん、自然言語処理を冠したプログラムでも、確定的に対応できる問題を対象としている場合もあります。ここで述べているのはあくまで一般論です。

コーパス収集の必要性を説いてみたが・・・

　昔は、コーパスの作成／収集というと多大な労力と時間を要するものなので、その必要性は理解していても、なかなか手を出すことができない状態だった（らしい）。大学では、いろいろな方法でそれを作成することができたので、あまり気にしたことはなかった。
　インターネットの時代になって、ある程度の規模の文書を収集することが、容易になった。それは、企業にとっては、費用がかからないということであり、研究者にとっては、個人の経験則に頼って作成していた様々な方法論を検証したり、あるいは、それ自身から新しいものを生み出す力を持っている。

　しかし、現実にウェブからコーパス収集しようとすると、コストがゼロというわけにはいかない。それ故に、なかなか手を出そうとしてくれない。

　以前に某社での話だが、形態素解析システムのコスト計算を手計算でやっていたので、コーパスからの学習に切り替えることを提案した。いや、提案しようとした。まずは、直属の上司に相談してみると、「コーパスないでしょ」と一蹴された。いや、だから、収集の必要性があると粘ったが、「まず、今やっている改善をこつこつとやっていこう」と、完全に議論がかみ合っていなかった。
　別の先輩にも相談したが、だいたい似たような話に落ち着いてしまう。

　企業というものは、短期的な成果を追い求めるもので、長期的な成果のために、多大なコストをかけるという選択は市内ものであると痛感した。

　仕方がないので、自分で(自宅で)収集することにした。アクセス量が多いと、プロバイダから文句がくる時代だったので、cronで1時間おきにあるブログのRSS経由で、ブログ本文を収集することにした。
　（余談だが、光どころかADSLでもなくISDNでの通信で、これがほんの数年前の話である。）

　さて、ある程度のコーパスが収集し、分析し、報告した。
　彼らは、特段の反応を示すこともなく、「じゃせっかくだから使ってやろうか、でも、あれとあれが足りないから、それも収集・分析して」と注文をつけてくる始末。

　自然言語処理に限った話ではないだろうが、まじめな人間が報われない状況が存在するということを実感した瞬間だった。

　というか、むしろ、会社に夢を見すぎていたのかもしれない。
　会社は何もしてくれない。だから、自分でやらないといけない。
　やるべきは、「コーパスの収集」を説くことではなくて、コスト削減にどれだけ貢献できるかということだったのだろうと、今となっては考えている。
　そして、そのための様々な過程で得られたノウハウについては、要求されれば公開すればいいし、要求されなければ、自分で抱えていればいいだろう。それが本当に役に立つ知識であるならば、そのノウハウを持っていることによって、会社内における強みとして生かすことができるだろう。

社員として食っていけるか

　一昔前の様に「技術が優れている」ということが売りにならない時代になりました。ユーザーにとって「いかに便利であるか」を明確に示さないと使ってもらえません。
　その意味では、「自然言語処理」は表舞台に立つことはないのかもしれません。

　社員として会社に所属するということはいろいろな意味を持ちます。一定の収入が保証されているということもあります。また、会社が自然言語処理関連の製品を作る限り、何らかの形で、「自然言語処理」との関連を持ちつつ仕事をしていくことはできます。
　しかし、その代償として、必ずしも自分の望む研究分野の仕事ができるというわけではありません。

　会社の仕事をこなすということは、単純なことではなく、夜遅くまで残業する現状があり、自分で何かをする余裕などはありません。時には休日出勤もあり、体を休めるのもままならない状況です。

　わずかな休日や偶然できた隙間時間を使って、自分なりの調査・研究を行っています。
　会社員にとっての研究というのは、ある意味で、趣味の様なものかもしれません。
　しかし、現実に目を向けてみると、ほかの人とは違う技術を手につけておく、すなわち、差別化をしておくことで、会社にとって必要な人材とされることを期待しています。（さらにいえば、それによって、自分のやりたいことに近づくことができるかもしれません）

形態素解析システム

　昔、自然言語処理で実用になったものといえば、「仮名漢字変換システム」や「形態素解析システム」といったところでした。
　当時は、「仮名漢字変換システム」が多くあり、その変換精度を比較する記事が雑誌などを賑わしていたものですが、今はすっかりその陰もなく、「仮名漢字変換システム」を意識して使うという人すら少ないのではないでしょうか。

　自然言語処理だけではなく、あらゆる技術について同じことがいえるのではないでしょうか。
　少し違う話ですが、昔の「電子レンジ」は機能の追加競争状態になっていて、ある段階で機能の飽和状態になり、『機能』より『使い安さ』というようになり、現在では、機能そのものを売りにすることはほとんどなくなってきました。（時折、新しい技術開発により、新機能が追加されることはありますが、以前ほど大騒ぎすることはありません。）
　「仮名漢字変換システム」も同じようです。あれほど、PC関係雑誌を賑わしていた記事を目にすることはほとんどありません。大部分の企業は撤退し、ある意味、勝ち組の企業だけが生き残っていると観ることもできるでしょうか。

　「仮名漢字変換」は、かな文字で入力された文を、漢字に変換するもので、ユーザが直接触れる機能です。
　一方、「形態素解析システム」は、新聞記事や書籍やユーザ入力文などの、いわゆる「かな漢字混じり文」を解析し、それを、「名詞」や「動詞」などごとに区切るものです。これは、一般ユーザにとっては直接的には、何の意味もありません。
　しかし、実はすでに「検索システム」や「会話システム」などに利用されていて、実用に供されている技術です。

　形態素解析システムの開発は、企業よりは、むしろ大学での研究が進んでいるようで、「ChaSen」や「MeCab」など、ほぼ自由に利用できるシステムが存在します。（正確には、各ライセンスを確認してください）
　基礎技術も、ほぼ固まっており、それらの情報はほとんど公開されています。

　さて、自然言語処理を会社としての旗頭として掲げている会社が、独自の形態素解析システム程度が用意できていないというのでは話になりません。
　それは、プライドの問題というのではなく、出来合のシステムでは、応用技術開発の際に小回りが利かなくなる場合があるからです。使い方によっては、システム自体の性能を引き出せずに、逆に非効率になってしまうこともあります。
　前述のように、形態素解析システムにおける技術はすでに固まっているし、ほとんど情報は公開されている訳ですから、それを用いて開発することは可能です。

　ところがその一方で、「自然言語処理をやってます」という会社の中で、本当に自然言語処理の開発をやっている／できる（能力がある）人はそれほど多くありません。
　実際の製品開発においては、UIであったりデザインであったり、どういう使い方を提案するとか、様々な課題が存在します。プログラム開発はその一部であり、その中核技術であるはずの自然言語処理開発は、さらにその一部にしか過ぎないのが現実です。
　その結果として、形態素解析システムの開発にすら手をつけることができないので、期待する性能が出せないという、本末転倒な状態が存在しています。

　その会社では、形態素解析システム「Juman」を使い続けていました。これは、「ChaSen」よりさらに古いシステムですが、ある機能を必要としていたために、別の形態素解析システムへの移行ができませんでした。
　そこで、新規開発を提案したのですが、最初は、話すら聞いてもらえませんでした。すでに動いているものを差し替えるメリットが理解してもらえなかったのです。そこで、速度・精度・メンテナンス性についての説明を粘り強く行い、結局2ヶ月たって受け入れてもらうことができました。

　その後、プログラム開発は・辞書開発をあわせて2ヶ月で仕上げ、ほぼ同じ精度で速度を約10倍近くに上げることができました。精度向上のためのメンテナンス法も改善したため、それまでのメンテナンスより遙かに短い期間で精度を大幅に向上させることができました。
　今度は、それに味をしめたのか、形態素解析システムとは関係ない機能までも詰め込もうとしたので、その開発からは手を引きました。

　要素技術・応用技術として何を作り上げるのか、そして製品としてユーザに何を提供していくのか。
　その目標を明確にしていきたいものです。

はじめました

　自然言語処理とは、人間の話す言葉を理解し、応答したり行動したりできるシステム全般を指しています。
　この技術を中心に仕事をすることを期待して入社した会社では、なかなか、期待するようなことはできそうにありません。
　そこで、業務の隙間時間やプライベートな時間を利用して、自然言語処理のシステムを考えたり、試作したりしています。
　会社の中でそれを有効に活用できるなら、それもよし。そうでなければ、別の方法もあるでしょう。

　そんなことを考えながら、生活している会社員の日記です。
　会社での出来事や、調べていること、考えていることなどを、思いつくままに綴っていくことにします。