「データを分析する」という仕事を任されたとき、膨大なデータを前に初めにやることは、「データのグルーピング」つまりは”分類”です。
お問い合わせの分析を行うならば、ログを1件1件確認して、
「請求書再発行に関わるグループ」
「新製品の予約に関するグループ」
「返品に関するグループ」などに分けていきます。
データをまとめることで、傾向性を大まかにとらえて分析をしていきます。
この分析作業の一番初めに生じるのは、”分類”ですが、”分類”って得意ですか?
- 私は苦手です。
何を基準に”分類”すればいいか、悩んだ挙句、答えが出ない。そんなことが多くありませんか?
- はい。これはまさに私です。
その結果、『その他』が多すぎたりしていませんか?
コンタクトセンターの現場では、オペレーターや管理者を問わず、常に分類をすることを求められているのではないでしょうか。
オペレーターはお客様からの問い合わせにどの相談分類(問い合わせ内容のカテゴリ選択)を選択するか、
管理者は直近のよくある問い合わせ(FAQ)の更新の際のカテゴリ選択など、私たちは常にカテゴライズを求められています。
特に管理者は、FAQを作るとき、Q&Aをたくさん作ることはこれまでの経験があれば、そこまで難しくないと思います。
ただ、よくある問い合わせのQ&Aを並べているだけでは、“使われないFAQ”になってしまいます。
“使われないFAQ”にしないため、今後の管理のしやすさやお客様とオペレーターの利便性を複合的に考えて、「FAQのカテゴリ分けをしなければ!」と思う反面、、、
「じゃあこの大量の未分類のFAQを、忙しい中で誰がカテゴリ分けするの?」というお悩みを抱えている方も多いのではないでしょうか。
今回はそんなお悩みを軽減してくれるかもしれない、”自然言語処理を用いた文書分類”について、2回に分けてお話しします。
----
冒頭の「じゃあこの大量の未分類のFAQを、忙しい中で誰がカテゴリ分けするの?」問題は、以下の2パターンがあるのではないかと思います。
1.既存の分類に当てはめる(今回)
2.新しい分類基準を作る
それぞれの分類の例や特徴を挙げると次の通りです。
1.既存の分類に当てはめる
(特徴)すでに分類ルールが決まっている。これまでのルールに沿った文書分類がされたデータがある。
(例)「既存のFAQに新しくQ&Aを追加するときの分類先の選択」
2.新しい分類基準を作る
(特徴)分類ルールが決まっていない。大量の文章だけがある。
(例)「既存のFAQの分類を再構築したい」「新しいコンタクトセンターのFAQを作りたい」
私の経験上、1.既存の分類に当てはめる と 2.新しい分類基準を作る、では圧倒的に、新しい分類を作る方が難しいです。その差は、料理に例えると以下くらいのレベル感です。
1.既存の分類に当てはめる ⇒ オムライス (手間:★)
2.新しい分類基準を作る ⇒ コロッケ(手間:★★★★)
ただ、1.既存の分類に当てはめる についても「どうカテゴライズするか」が明文化されておらず、属人化が起こっている場合、分類した担当の人が「既存の分類に当てはめる」のは簡単かもしれませんが、他の人がすることはなかなか難しいと思います。その場合の1の難易度は、「ハンバーグを作る(手間:★★★)」くらいでしょうか。
では、どのように機械を頼るのか。それが自然言語処理を用いた機械学習です。
1.既存の分類に当てはめる ⇒ ”教師あり学習”で文書分類
2.新しい分類基準を作る ⇒ ”教師なし学習”で文書分類
- ・教師あり学習・・・学習用データに対して、正解が与えられていて、その正解をつけて機械学習をすること
- ・教師なし学習・・・学習用データに対して、正解が与えずに機械学習をすること
『“教師あり学習”で文書分類』がどう役立つのか
機械に頼る主な理由は、生産性の向上と質の安定だと思います。
今回の先の例で挙げた「既存のFAQに新しくQ&Aを追加するときの分類先の選択」が自動でできるようになれば、その手間が省けるようになりますし、人がやることによるルールの曖昧さ(質の不安定)も解消できます。
また、「忙しくて未分類のまま手を付けていなかったQ&A」や「とりあえず『その他』に入れているQ&A」といった今まで手のつかなかった領域にも手を伸ばすことを考えることができ、今まで以上の質の向上も見込むことができます。
とはいっても、本当にそんなに精度がいいの?と思われている方もいらっしゃるでしょう。
それでは、実際に教師あり学習を使った文書分類はどれくらいの精度が出るのかを見ていきましょう。
今回使うデータについて
今回使うデータは、『livedoor ニュースコーパス』です。その概要を以下に説明します。
livedoor ニュースコーパスは、複数のwebメディアの記事を集めた日本語テキスト群です。
全9メディア、7,369記事もあり、自然言語処理界隈ではよく使われています。
各webメディアの記事内容は以下のリンクから確認できます。※2012年9月上旬の記事のため、一部リンク切れしています。
- トピックニュース(http://news.livedoor.com/category/vender/news/)
- Sports Watch(http://news.livedoor.com/category/vender/208/)
- ITライフハック(http://news.livedoor.com/category/vender/223/)
- 家電チャンネル(http://news.livedoor.com/category/vender/kadench/)
- MOVIE ENTER(http://news.livedoor.com/category/vender/movie_enter/)
- 独女通信(http://news.livedoor.com/category/vender/90/ ※リンク切れ)
- エスマックス(http://news.livedoor.com/category/vender/smax/)
- livedoor HOMME(http://news.livedoor.com/category/vender/homme/ ※リンク切れ)
- Peachy(http://news.livedoor.com/category/vender/ldgirls/)
各webメディアの記事数は以下の通りです。
データをダウンロードすると以下のような、webメディアごとにフォルダ分けされています。
また、各記事は1つのテキストにまとまっており、以下のような構成になっています。
このデータを使ってどのような教師あり学習を行うのか
今回のデータを使ってやるのは、以下のイメージのように、“記事本文とそのwebメディア名を元に、webメディア名を当てる機械学習モデルを作る”ことをやっていきます。
このモデルを作ることによって、今回のデータにない未知の記事に対しても、webメディア名を予測して、当てることができるようになります。
さて、詳細を見ていきましょう。
・教師あり学習
それでは実際に教師あり学習をした簡単な工程を説明します。
今回は以下のフローで、記事のwebメディア名分類を行いました。
(①.データ分割)
はじめに、『学習用データ』と『検証用データ』に分割をします。
各webメディアの学習用データ数と検証用データ数は下表の通りです。
『学習用データ』で教師あり学習のモデルを作り、作ったモデルの正しさを『検証用データ』を使って評価します。
(②.前処理について)
次に、分類に必要そうな単語だけを抽出する、前処理を行います。
今回は記事内の「名詞、動詞、副詞、形容詞、形容動詞」だけを抽出しています。
(③.記事のベクトル化について)
“記事のベクトル化”(数値化)については、以前お話をさせて頂いた『VOC分析は、名著を読み解くが如く』の単語ベクトルの文書バージョンを行います。
![]()
VOC分析は、名著を読み解くが如く | DIGITAL | オペレーションを進化させる現場のWebマガジン 現場ドリブン
現場ドリブン
さて、前回はVOCアナリティクスのセクシーじゃない作業と分析の流れを料理に例えながら紹介を致しました。今回は、データ分析のセクシーじゃない作業、テキストマイニングの「前処理」、特に...
1つの記事の中にはたくさんの単語が含まれますが、それらを機械学習で1つの数字の羅列にしているとお考えいただければと思います。また、文書ベクトルの作成方法については様々な方法が提案されていますが、今回使ったのはSCDVという方法を使っています。
(④.分類器の学習・モデルの作成)
今回の学習では、“LightGBM”を使って学習をさせ、モデルを作成しています。
(⑤.検証データを使ったモデルの評価)
さて、検証結果についてです。下表のようになりました。
あまり見慣れないかもしれませんが、教師あり分類モデルの評価にはオレンジ色のf1値というものをみて評価をします。この値は1に近ければ近いほど良いモデルと判断できます。
そのため、今回のモデルであれば、f1値:0.89となかなか高い数値が出ているため、比較的良いモデルと考えます。今回はかなりざっくりとモデルを作りましたが、大量の文書とその分類があれば、それなりに高性能な文書分類するモデルが作ることができました。
――
今回は『1.既存の分類に当てはめる』のに役に立つかもしれない、教師あり学習を用いた文書分類についてでした。
分類をするというと、FAQや入電のカテゴリ分けなどに目が行きがちですが、例えば、「商品・サービスの改善に役立つお客様の声かどうか」という問いに対して
・ある お問い合わせは、「商品・サービスの改善に役立つお客様の声である」
・ある お問い合わせは、「商品・サービスの改善に役立つお客様の声でない」 という2分類の問題として考えることもできます。
今まで『商品・サービスの改善に役立つお客様の声』をきちんとデータとして残していたり、音声認識されたテキストがあれば、そのデータから『商品・サービスの改善に役立つお客様の声』の特徴を見つけ出すことができるかもしれません。
次回は、『2.新しい分類基準を作る』手助けになるかもしれない、教師なし学習を用いた文書分類についてお話しできればと思います。
Omnia LINK(オムニアリンク)は、クラウド型IP-PBXを基盤としたコールセンター向けトータルテレフォニーソリューションです。基本の通話・管理機能はもちろん、AIを利用した通話音声のリアルタイムテキスト化や、FAQリコメンデーションなど次世代機能を提供します。在宅コールセンターにも対応しています。
以下のようなお客様にお勧めです。
・オンプレ型のPBXからクラウド型に移行したい
・通信費や保守費用などのコストを削減したい
・毎月使う分だけライセンスフィーを支払いたい
・場所にとらわれず、電話が取れる環境を整えたい
詳しい資料は、以下からご覧いただけます。
https://www.bewith.net/gemba-driven/download/entry-126.html