2013-01-22 に AI ツール入門講座というものがありましたので受講してきました。IBM Content Analytics (以後 ICA) という有償ツールを使っての講座だったので、最初はあまり参加する気はなかったのですが、テキストマイニングの定石といった基本は学べるだろうと思い直し参加することにしました。
テキストマイニングの基礎
午前中は座学で、テーマは『テキストマイニングの基礎』でした。基本的には知っていることが多かったので、重要または印象に残った部分だけ軽く紹介します。
最初にテキストマイニングの長所、短所です。改めて書くまでもないかもしれませんが重要ですので書いておきます。長所としては『膨大な量のデータを対象にし、データの全体的な傾向や変化を捉えることが出来る』ということで、短所は『機械処理のノイズに対する理解など使いこなすには工夫が必要』ということです。目的と手段を混同している事例はよく見られます。当たり前のことですが、何でもかんでもテキストマイニングというのではなく、長所・短所を踏まえた上で目的に合う場合にテキストマイニングを使うということを忘れないようにしなければいけませんね。
次に検索ベースの分析との比較が行われたのですが、この説明はわかり易かったです。
テキストマイニングの前は検索ベースの分析を行なっていました。検索ベースの分析では仮説を立ててから仮説に関連するキーワードを元に対象文書群を検索・分析します。これだと仮説が立てられないような思いもよらないものについては漏れが発生する可能性が高いです。テキストマイニングでは全体から特徴や傾向をつかむことから始めるため、このようなリスクを下げることができます。
テキストマイニングの具体的な活用例の紹介
IBM 社では1週間あたり約 1万件の問い合わせがあるそうです。これら全部に目を通して傾向を把握するというのは事実上不可能です。こういった場合にテキストマイニングは有用です。テキストマイニングの定石はいくつかあります。紹介された手法を紹介します。
最初は、係り受け解析をしてフレーズ分析で問題を分析するという手法です。問題を表現する場合は否定形になることが多いので、例えば『電源…入る…ない』というようなフレーズ分析をするというものです。
次に時系列分析です。年、月、日単位で集計し、異常値を探してそこから掘り下げるという手法です。ICA では、問題発生はポアソン分布に基づくという仮定をおいているそうで、外れ値はハイライト表示されていたのでなかなか見やすかったです。
単語同士の相関をみるというのもあります。相関の高い単語の組み合わせを見て、そこから当たり前のものを除いて、残った組み合わせを掘り下げるという手法です。
コールセンターのオペレータ教育の改善という事例もありました。コールセンターのオペレータは教育が大変で、約 1年間の育成期間が必要だそうです。この改善に取り組むにあたり、ベテランのオペレータに回答を回されている問い合わせに絞って分析し、研修内容を改善したとのことでした。
その他にもいくつか事例紹介はありましたが、それぞれ切り口が違い興味深かったです。ただ、定石というものはあり、そこを足がかりとして進めていくという点では変わらないと感じました。
その他面白かったトピックをいくつか要点レベルで紹介します。
- 音声認識ではノイズ (誤認識など) が入るが、テキストマイニングで傾向は見える
- たとえ外国語のテキストマイニングであっても形態素解析して単語を翻訳すれば、ある程度の分析は可能
- 外国語に翻訳する際に辞書にない単語でも、共起する単語をみることで正しく翻訳できる可能性がある
日本語の (車の) ハンドルは英語では handle ではなく steering wheel だが、共起する単語 shake, vibration などを手がかりに正しく翻訳できる可能性がある - 語尾が丁寧か、口語体か、乱暴かに注目することで面白い分析が出来ることがある
乱暴な口調の場合はクレームの確率が高い、twitter では時間帯によって使われる語尾の傾向に違いがあるなど
最後に
この講座を通して伝えたかったのは以下のようなことだと受け取りました。
テキストマイニングも、他の分析などと同様に定石はあるものの、こうすれば良いという絶対的なものはない。かと言って、行き当りばったりで試行錯誤するのは非効率なので、定石にしたがってデータを眺めると良い。そして、このあたりのコツをつかむにはやはり実際に自分で試行錯誤しないと身につかない。何も見えずに苦しい時もあるが、あきらめずにデータを眺め続けると大抵の場合何かしらの知見は得られる。
分析の大きな流れとしては以下のような感じである。
- データの全体像を理解する
- 偏りや変化を発見する
- 活用シナリオを検討する
上記の、3 については「アクションが取れないことがわかっても仕方がない」という言葉が印象的でした。当たり前のことなんですが、分析した結果こういうことがわかりましたといくらドヤ顔で伝えても、わかったところでどうしようもない内容だとダメだという事です。これはアプリケーションエンジニアとユーザの間でもよくあるスレ違いに構図が少し似ているように感じます。
エンジニア: この機能のこの部分ではこういうところにこだわってみました。どうですか? (ｷﾘｯ
ユーザ: いやいや、そんなんどうでもええねん。それよりもこっちをどうにかしてよ。
アプリケーションはユーザが利用し効果が出て意味があります。分析も分析をして終わりではなく、分析結果を使って効果が出て、初めて意味があるという点では変わりません。
