Microsoft LUIS でユーザーボイスを分類した話

## はじめに

[NAVITIME JAPAN Advent Calendar 2019](https://qiita.com/advent-calendar/2019/navitime_japan) 5日目を担当いたします、ユーザーボイス分析プロジェクトのひよこです。

### ユーザーボイスについて

NAVITIME ではユーザーから様々な「声」をいただきます。
サービスの使い方や質問など様々な声が寄せられますが、それらのユーザーボイスの中でも今回は経路に関するご指摘の分析についてお話しさせていただきます。
なお、本記事で取り上げるユーザーボイスはすべて実際のユーザボイスを参考に作成した架空のものです。

経路に関するご指摘は NAVITIME の各アプリの経路探索結果画面からお送りいただけます。
私たちのチームでは寄せられたご指摘を日々一件一件調査しています。

### 目指したもの

ご指摘の調査には長年課題がありました。

* 調査対象が多岐に渡るため、新規参画者の学習コストが高い。少しでも学習コストを下げたい。
* 未調査のご指摘の傾向がわからない。傾向がわかれば不具合検知の一助にしたり、メンバーごとの調査対象の割り当てにも利用できるかもしれない。

ご指摘の調査では、調査完了後に原因のラベル付けを行なっています。
ラベル付けはあらかじめ用意された選択肢から選ぶようにしているものの、種類が多いため慣れないうちは付け間違いが発生しがちです。
調査結果のレビューでラベルの付け間違いを直していますが、間違いが多ければレビューもより時間がかかってしまいます。
原因ラベルの予測があれば、調査メンバーがラベル付けを行う際のヒントとなり、学習コストを下げられるのではないかと考えました。

また、未調査のご指摘の内容がわからないことも課題でした。
どのサービスからのご指摘なのかといった調査せずに集計できる項目もありますが、調査で必要な切り口とやや異なります。
この問題についても原因ラベルを予測することにより調査前にご指摘の傾向を把握できそうでした。

### 使用したツールについて

ご指摘の文章から原因ラベルを推定したいということで、文章を解析する必要がありました。
この課題に対して、社内で実績のあった Microsoft LUIS を試してみました。

なお、昨年社内の別チームのメンバーも LUIS の記事を執筆しておりますので、LUIS にご興味を持たれた方はこちらもご覧ください。
https://qiita.com/navitime_tech/items/22bd507be04dae4f8b36


## やったこと

最初はご指摘すべてを単純に期間と件数で絞って学習に使用してみました。
LUIS は json ファイルをインポートすることで教師データを投入できるので、ご指摘と原因ラベルから json を生成し、簡単に多数のご指摘を LUIS に取り込むことができました。
しかし原因ラベルが多様なためかこの結果は散々なものでした。

そこで、まずは不具合が原因だったご指摘のみを教師データとして学習を行うことにしました。
ご要望等他の原因の場合は学習結果で判別できませんが、最終的にすべてのご指摘を人間が調査しているため今回はスコープ外としました。

さらに経路探索の種類で原因ラベルの種類が一部違うことから、経路探索の種類ごとに分類を試みました。

1. 電車やバスを使った経路探索
2. 車やバイク、自転車を使った経路探索

### 1. 電車やバスを使った経路探索に対するユーザボイスの分類

ご指摘とそれが不具合だった場合の原因ラベルの例は以下の通りです。

* 建物の入口は反対側です → 地点データの緯度経度
* ○○線の△△の時刻は 12:05 発ではなく 12:10 発です → 時刻データ

不具合かつ電車やバスの経路探索に絞ることで、最初の学習結果に比べ予測の正解率はいくらか改善されました。

学習結果を見ていくと、似たような原因ラベルが混同されているように見受けられる箇所がありました。
LUIS は違いが微妙な文言を別の分類として学習すると判定に混乱して精度が下がってしまうため、原因ラベル同士を似ないようにする必要がありました。

例えば「表参道駅までの運賃は200円でした」という指摘があったとします。
調査で問題があった場合の原因ラベルは、鉄道なら「鉄道の運賃データ」、バスなら「バスの運賃データ」を付与していました。
鉄道とバスを分けることは不具合の傾向を細かく集計するという観点では良い分類でした。しかし、そのまま学習させたところ鉄道とバスの区別がつかない学習結果となってしまいました。
文章だけでは鉄道とバスの区別を行うことは困難であること、不具合検知のスピードアップの観点では鉄道とバスの区別は重要でないことから、「鉄道の運賃データ」「バスの運賃データ」の2つの原因ラベルをまとめて「運賃データ」として扱うようにしました。他にもまとめて問題ない原因ラベルはまとめるように加工して LUIS に学習させました。

ご指摘と学習結果を見比べるうちに、いくつかのパターンは機械学習でなくてもルールベースで予想がつきそうなことに気付きました。
アプリごとに差異はありますが、ご指摘の受付画面には、ご指摘の概要を複数の選択肢から選択する箇所があります。
原因ラベルによってはこの選択項目から予測される原因を断定して良さそうなものが存在しました。
例えば「乗換時間が不適切だった」という選択肢を選ばれた場合、不具合であればほとんどが「乗換時間」の原因ラベルだったため、そのようなパターンは LUIS で処理せず、ルールベースで原因の予測を付与するようにしました。

3ヶ月ほど運用を行い、調査の結果不具合だったご指摘を対象に原因の予測と調査結果で答え合わせをしたところ、7〜8割程度の正解率となっていました。
当初はまず LUIS を用いて予測を行い不具合だった場合の検知と調査の迅速化に役立てるということを主眼に、不具合以外のご指摘調査結果を学習に用いていませんでしたが、今後は不具合以外のご要望なども学習に組み入れたいと考えています。


### 2. 車系の指摘の分類

指摘と不具合だった場合の原因箇所の例は以下の通りです。

* 遠回りのルートが表示されます
* △△通りは大型車は通れません

鉄道やバスを使った経路探索に対するユーザーボイスの分類後、同様に車やバイク、自転車の経路探索に対するご指摘の学習に着手しました。
しかし、鉄道とバスの運賃データの分類をまとめたように、LUIS が混乱する分類をまとめようとしたところうまくいきませんでした。

例えば「遠回りのルートが表示されます」という指摘があったとします。
不具合だった場合、この指摘は複数の原因がありえます。

* 目的地の緯度経度データ
* 道路データ
* 経路探索処理

車やバイク、自転車の経路探索に対する指摘は、指摘の文と原因の対応が電車やバスの指摘より複雑でした。
LUIS が分類に混乱する都度、原因ラベルをまとめていったところ最終的に原因ラベルが2〜3種類になってしまいました。
2〜3種類では不具合の早期検知や調査の参考には繋がりません。

この段階でようやく、LUIS は指摘の調査ができないので、LUIS が分類できるのは与えられた文章から直接読み取れることだけだということに気付きました。

文章から直接読み取れることで、例えば「回り道させられます」「裏口に案内されてしまいました」といった文章を「遠回り」と分類することはできそうでした。
このように不具合だった場合の原因ではなく、表面的な要旨でも特定の種類が急増したとなれば異常の検知には繋げられます。
今後は指摘の要旨のラベルを人間にも LUIS にもわかりやすい形で整備し、調査済みの指摘に付与して蓄積した上で、車・バイク・自転車の分類に再挑戦しようと考えています。


## まとめ

この記事では触れられませんでしたが、LUIS での機械学習自体は GUI の操作で簡単に始めることができます。
LUIS がとっつきやすいものだったこともあり、本件に取り組み始めた当初は教師データが用意できているのだから正解率を高めるのも簡単だろうと軽く考えていました。
しかし、教師データのような体裁のデータに対して、それが本当に機械学習で扱えるものなのか、扱いやすいデータとはどのようなものなのか、という問題は難しいものでした。

サービスに新たな機能が増えれば、その機能に対するご指摘を新たにいただくことがあります。
一度作って終わりではなく、サービスと同様にそれを支えるご指摘の調査も引き続き改善を進めていきます。
そして、いただいたご指摘、ご意見、ご要望といったユーザーボイスをナビタイムの各サービスに活かしてまいります。