カスタマーサポートAIの失敗と教訓

こんにちは。以前、エンジニアからマネージャーになって変わったこと・変わらないことというエントリを投稿したCREグループの豊川です。

SNS「mixi」における取り組みとして、機械学習による不適切コンテンツ検出について岩瀬からご紹介させていただきましたが、私たちCREグループでも、お客様への素早い返信と対応品質向上のために、問い合わせの分類を目的としたカスタマーサポート(CS)AIの開発に取り組んでいます。

しかしタイトルにもあるとおり、私たちは一度失敗しました。

AIや機械学習といったワードが持て囃されるようになって久しく、成功事例は数多く見られるようになってきた一方で、失敗事例が語られることはあまり多くありません。

そこでこのエントリでは、カスタマーサポートAIの開発に至った背景と、なぜ失敗し、失敗から何を学んだのかをお話しします。

なお、下記のことには触れないのであらかじめご了承ください。

  • 機械学習の具体的な手法
  • データの分析結果
  • システム構成

背景

CREグループは、技術を駆使してCSスタッフをサポートすることで、お客様のサービスに対する信頼を最大化することをミッションとし、2017年12月に設立しました

現在は6名のエンジニアが在籍し、これまで一括データ復旧システムや不正対策システムなど、CS業務の品質向上のためのシステムを数多く開発してきました。これらのシステムはどれもAIを使わない仕組みで、大きな成果を上げています。

仕事ではじめる機械学習には、AI・機械学習プロジェクトを開始する上で考慮すべきことが網羅されています。機械学習を使わずに達成できるのなら機械学習を導入すべきではないというのもその1つです。

私たちは当初から、AIの導入に対しては慎重な姿勢でしたし、今でもAIを過信していません。

AIを使わずにできることはやり尽くしたということで導入に踏み切ったとき、私たちの中に機械学習の専門家はおろか、かじった程度の人もいなかったので、ゼロから知識を取り入れながらフラットに評価したためです。

毎日、問い合わせ窓口には多くのメールが寄せられ、CSスタッフがそれらに対応します。

対応とはメールを書くことだけではありません。内容によってメールを分類し、分類ごとに専門のチームが調査・返信しています。

現状は1件1件人手で対応していますが、もし、メールの分類だけでも自動化できれば「返信がこんなに早いと思わなかった!」というように、お客様の期待を超えることができるかもしれません。

そんな希望を胸に、かといってAIに過度な期待を持つことなく、控えめに出発した私たちがなぜ失敗したのか、理由を次にお話しします。

なぜ失敗したのか

メールは、届くとまずCSスタッフによって事前に用意したカテゴリに分類されます。

メールの自動分類システムは、CSスタッフの過去の分類結果を教師データとしてAIに学習させ、未知のメールのカテゴリを決定させようというものです(図1)。

システムの入力はメールの本文に前処理を施しベクトル化したもので、出力は該当カテゴリである確率です。評価指標は再現率と適合率を用いています。

ゼロからスタートしたこと、定常業務の合間を縫って少しずつ進めたことから、システムの構築には8ヶ月かかりましたが、学習結果は良好でした。

そこで本番環境に試験導入し、AIとCSスタッフの分類結果を比較してみました。

結果は散々で、とても実運用に耐えるレベルではありませんでした。

「分類器の評価に検証データを用いていないのでは?」

だとすればわかりやすくて良かったのですが、良好な学習結果というのは検証データにおける結果でした。ではいったいなぜ?

その謎を探るべく、我々はジャングルの奥地へと向かった…わけではなく、AIが間違えたデータを1つ1つ見てみることにしました。

データを見始めてすぐに、あることに気が付きました。メールの内容からカテゴリを当てるのが難しいのです。カテゴリAだと思ったらカテゴリBで、カテゴリBだと思ったら今度はカテゴリAという具合に。

はじめは私がエンジニアで、CSスタッフのように熟練していないからだと思いました。

しかし私だって日本語は読めますし、どちらかというと国語は得意な方だったので、だんだん「実はCSスタッフにも明確な基準がないのでは?」と考えるようになりました。

この仮説をはっきりさせるために、AIが間違えたデータを集め、複数のCSスタッフにアンケート形式で実際にカテゴリを割り振ってもらうことにしました。

結果にばらつきがあれば仮説は正しいということになり、ちょっと意地悪ですが、「人間が一意に判別できないならAIもできないよね」ということになります。

結果は仮説の通りでした。つまり、CSスタッフもカテゴリを一意に判別できるわけではなかったのです(図2)。

さらに調査を進めていくと、1つのメールに対して複数の要素が含まれることがあり、その際の明確な分類基準が定められていないということまでわかってきました。1つのことを訊いているつもりで、実はAとBの要素を含んでいるというわけです(図3)。

カテゴリAやBというのは私たちの都合で決めた分類なので、当然と言えば当然です。

ここまでの話をまとめましょう。

なぜ失敗したのか、それは端的に言えば、そもそもの教師データに信頼性がなかったためです。そしてそれを見抜けなかったのは、AIを導入しようとした私たちエンジニアのドメイン知識とデータ分析が不足していたからです。

最後に、私たちがこの失敗から学んだ教訓をお話ししましょう。

失敗から学んだ教訓

私たちが失敗から学んだ教訓は2つあります。1つはデータを見ることの重要性、もう1つはドメイン知識についてです。

通常、AIが扱うデータは膨大です。その多さゆえに、データの1つ1つに焦点を当てることにあまり意味を見出せないかもしれません。

しかし忘れてはいけないのは、AIは教師データの正しさは保証してくれないということです。データの正しさは人間が保証しなければならないのです。

ドメイン知識があれば、データを見たとき異変に気付くことができるはずです。

AIプロジェクトにおいてドメイン知識が不可欠であるというのは、実は仕事ではじめる機械学習にもはっきりと書かれています。

ドメイン知識は、今回のケースではCSの現場知識ですが、私たちは半分わかっているつもりで、もう半分はCSスタッフ任せでした。

すでに回っているオペレーションを壊すべきではないという過度な配慮が、目の前の問題を覆い隠してしまっていたのです。

エンジニアはエンジニアリングが主戦場なので、ビジネスにAIを導入するときドメイン知識の不足は避けられません。

そんなとき、ドメイン知識がないからといって現状を最善と思うのではなく、ドメイン知識がないからこそゼロベースで考えることが重要です。

おわりに

私たちCREグループは、今回の失敗を糧にすでに新たなアプローチを取っていますし、今度こそ上手くいくと信じて今からワクワクしています。結果が出たら、またなんらかの形で報告したいと思います。

採用も行なっているので、興味のある方はぜひご検討ください。

最後まで読んでくださりありがとうございました。