この記事にある開発を行った経緯から紹介させていただきます。
ユーザーの要望 新しいCRMを入れたいんですけど・・・・
コールセンターを管理する部長が私のところを訪ねてきて、センターで利用しているＣＲＭを他のクラウドのサービスに変更したいとの要望を受けました。当該システムはハードウェアの更改も終わったばかりで償却も進んでない中、なぜそんな要望が今更出てきたんだと焦りながらも理由を聞くことにしました。
それによると、コールセンターの担当や人員構成の最適化やそれによる顧客サービスの向上のため、受電内容の分析を行いたいが、現在のシステムで設定されているオペレータが入力する内容に関するカテゴリーが、その分析を行うのには合わないということと、それを変更しようとしても変更するにはシステム開発せねばならず、かなりな工数が必要となるといわれているとのこと。片や見つけてきたクラウドのシステムはユーザーが柔軟にそのあたりを設定できるらしいのでニーズにマッチするとのこと。コールセンターの改革は待ったなしの重要案件なので相談したいとのことであった。
疑問・・・・
その話を聞いたときに、スタッフのスキルや専門性を考えた場合に、顧客サービスを向上させながら、かつ全体の質の向上と効率化を行うためには、受電内容を分析してどのような質問や相談が多いのか、またそれはクレームなのかそれ以外なのか、季節による違いはないかなどを、カテゴリーにより分析することは非常に大切であると感じました。一方、次のような疑問が出てきました。
１．オペレーターがカテゴリーを即時に判断して入れられるの？
２．今回カテゴリーを変更したら過去のデータはどうなるの？
３．受電内容１つに一個のカテゴリーではないだろう。
４．経営課題により必要なカテゴリーが変わるんじゃないの？
ということで本題に入ります。
提案 受電内容のＡＩによる分類
その部長には上記の疑問をお伝えして、新システムの導入は一度保留にしてもらい、ＡＩで分類してみることにしました。
ここで言うＡＩによる分類とは、過去のコールログを利用して、このような文章であればこの分類という形で分類し直すということです。
この利点は大きく二つあります。、
１．分類のカテゴリーを柔軟に決定できかつ変更や追加が簡単にできること。
たとえば、ある通話を分類する場合、分析の目的に応じて「質問なのか依頼なのか」「手続きに関するものか商品内容に関するものか」「どの商品または手続きに関するもか」「苦情なのかどうか」など、カテゴリーの分け方は様々です。もっと言えば、上記のようなカテゴリーの組み合わせ（例えばなんの商品のなんの手続きか）で分類する場合もあるので、分類方法は無数に出てきます。
２．ログを見ながらどのようなカテゴリーがあるのかを検討してから分類できます。
受電内容には、当初考えたようなカテゴリーでは分類できないものが多数含まれていますので、そういう例外的なものも集めて、いくつかの別のカテゴリーを作ってみるという試行錯誤をして、しっくりくる分類をしたいという欲求も出てきます。これもオペレーターがリアルタイムにすでに決められた分類コードを入れるような仕組みだけではできませんが、ログを見ながらじっくり考えて追加のカテゴリーはないかなどを考えられるメリットがここにはあります。
学習までの手順
上記のような利点を生かすために、次のような手順を踏みました。
１．コールログには、一回の受電に複数の内容が含まれることが多いので、複数ある場合にはデータを分離します。
２．個人情報があるのでマスクします。（名前部分を見つけるなどのツールがあると便利です）
３．学習データを作るときには、ログの内容とそれに対応する教師データ（＝カテゴリー）を、なるべく細かく定義する。すなわち、あまり抽象化することにこだわらず、種類は増えていっても仕方ないというつもりでカテゴリーを決めていきます。これは、一回細かく分けてしまえば、後に複数のカテゴリーを再度まとめてひとつのカテゴリーにしたりできるので、最初に抽象化する必要なないと言うことです。
４．教師データを与えた学習用のデータを作ります。つまり、コールログデータ１件につきカテゴリーコードを１つアサインしてデータに追加します。（３０万件のコールログに対して、２０００～３０００件程度作成しました。）
ここでは、先ほど述べたように、あまり抽象化を考えずにカテゴリーを考えます。ただ、どのようなカテゴリーを作ったか、またどのデータにそのカテゴリーをアサインしたかは、次以降に来るデータに一貫したカテゴリーを振るために重要になってきますので、それらを単語などで検索できるようExcelシートなどで管理すると便利でしょう。
学習
ログデータと上記でできた教師データを使って学習させます。
１．形態素分析
全部の（学習用のみでなく）ログデータを使いmecabというモジュールで受電内容を形態素分析して単語に分割し、かつ出てきた単語を０からの数字（ＩＤ）にします。
２. 文章ベクトル生成
Scikit-learnのTF-IDF Vectorizerというモジュールで、全ログデータを使って、ログ全体および個々の文章中の単語の出現頻度などによって単語ＩＤに重要度を与え、その重要度をその単語のベクトルの長さにして、一つのログデータの文章のベクトルを出します。単純に考えると、１単語がベクトルの１次元ですので、文章ベクトルは単語数が次元数になります。（実際は意味のなさそうな単語を無視したりしますのでちょっと違いますが）
たとえば、たこ(ID=0)、まぐろ(ID=1)、ライオン(ID-2)、車(ID=3) という４つの単語がログにあった全部の単語とします。そして、１番目の文章が、「まぐろ、車」だったとすると、ベクトルは「(0, まぐろの重要度, 0, 車の重要度)」です。重要度は、その文章中の出現頻度なども関係するので、単語ごとに固定ではありません。
このベクトルを用いて、複数の文章が似ているかどうかを判断することができます。このベクトルが近いものが相対的に似ているものとなります。ベクトルが近いかどうかはCosign類似度というものを使います。今回は、近いかどうかではないのでCosign類似度は使いません。
３．ニューラルネットワークによる学習
さて、この文章のベクトルを用いて機械学習を行い、受電内容をカテゴリ－で分類します。
ベクトルが近ければ近い文章であるということで、k-means方などの分類アルゴリズムを使おうとも考えましたが、文章が同じようなものであれば同じようなカテゴリーとも限らないと考え、ニューラルネットワークの分類アルゴリズムであるscikit-learnのMLPClassifierを使うこととしました。
ここでは教師データを割振った学習用のデータを使って、交差検証で精度をみながら、どのように分類されているかも確認します。確認していくとカテゴリーを変更した方がよさそうなものが出てきます。これが最初に固定でカテゴリーを決めなくてよい利点です。ただ、カテゴリーを変更すると、学習用データ上の似たような受電内容のものを探して、そのカテゴリーも変えてやらなければならないのが面倒です。先ほどExcelなどで高度な検査ができるようにしておくと楽だと言ったのはこのためです。
４．学習終了の目処
交差検証においてどれくらいの数値でよしとするかというのが結構難しい課題です。もちろん検証後に全データでカテゴリーのアサイン状況を確認し、パラメータ等を調整したり、カテゴリーを調整した後、再度学習させて検証することの繰り返しになりますが、それでも、このレベルのデータ量と学習量およびこの仕組みでは70%ぐらいの値がせいぜいのようです。
AI学習による分類の効果
70%程度の精度では役に立たない！と思う方が多いと思いますが、検証して期待したカテゴリーになっていないと思うような内容でも、まったく見当外れのカテゴリーになっているということは少なく、このカテゴリーでも次点ぐらいの分類だな、と思うような結果が多いのです。
なぜカテゴリー分けを行うかという目的に立ち返ると、人員構成の最適化やそれによる顧客サービスの向上のためということであり、「お客様はここに興味があるのか」「この製品に関するものはこういうところのクレームが多かったのか」「ここの知識のある人を多くしなければ」など、その後の施策を考えるきっかけにはこの程度の精度で、またはそれ以下でも十分であり、ここから焦点を絞って具他的な分析・施策を行っていけばよいのではないかと考えます。
冒頭で紹介した部長も、この結果を見て、いろんな気づきがあったと満足していました。
分析を進めるだけでなく、早速IVRに自動応答を追加するということでした。
発展
今回はMLPclassifierで実装したが、この場合、単語の出現頻度によって結果が左右されやすい。つまり例えば係り受けや単語の出現順などの要素を含んだ文章としての意味合いを含めることはできていない。
この実験をさらに発展させ、LSTMやAttention機構の追加等を行って出力された隠れベクトルを分類することにより、精度が高められるか検証していきたい。