概要
背景と課題
今回、2023年度異分野融合型データサイエンティスト育成プログラムに参加し、関彰商事株式会社様（以下、「関彰商事株式会社」）とパートナーを組み、問題解決に取り組んだ。
関彰商事株式会社では、自社開発の勤怠管理システムを運用しており、サポートデスクを設置している。サポートデスクには、日々、ユーザーからシステムのエラー対応や利用方法について、問い合わせが寄せられる。
現在、サポートデスクにおいて、「担当者によって対応の質と時間に差がある」という問題が発生している。この問題の要因として、以下の2つが考えられる。
- 日々の問い合わせが多く、新しい担当者を教える時間がない。
- 対応者の属人化が進み、担当メンバーのスキル差が埋まらない。
そこで、対応品質の向上、対応時間の削減を目的とした過去の問い合わせデータを活用したサポートデスク支援システムの作成に取り組んだ。
提案システム
提案システムの全体図を図1に示す。
システムへユーザーからの問い合わせ内容が入力されると、問い合わせ内容がどういった機能を対象としているか分類した結果と、分類結果と同じラベルの過去の問い合わせデータの中から一番類似度が高い問い合わせ文章がサポートデスク担当者へ出力される。
分類
分類モデルの作成には、関彰商事株式会社から共有していただいた過去の問い合わせデータを用いた。各データは、項目ごとに情報が整理されている。全77項目のうち、以下にその一部を示す。
- 件名：問い合わせのタイトル
- 対象機能：問い合わせで対象となっている機能
- 受付内容：問い合わせ内容の詳細
- 調査内容：受付内容を基に調査した内容
- 対処内容：調査内容を基に対処した内容
件名、受付内容は、メールでの問い合わせであればメールの件名を件名に、メールの本文を受付内容とし、電話での問い合わせであれば問い合わせ内容からサポートデスク担当者がそれぞれ手動で入力を行う。対象機能、調査内容、対処内容は、問い合わせ内容からサポートデスク担当者が手動で入力を行う情報である。そこで、今回は対象機能に注目し、新しい問い合わせが入力されると対象機能が分類結果として出力される分類モデルを作成した。分類により、サポートデスク担当者が問い合わせの割り当てを行う際の時間を削減することが狙いである。
分類モデルの説明変数は、件名と受付内容を合わせた文章データを設定した。目的変数は対象機能である。対象機能は36種類あり、その中からデータ数が多いものや分類により時間削減の効果が期待できる16種類と、残り20種類をまとめて「その他」とする17個のラベルに分類を行った。
分類に用いた手法は以下の2つである。
- ナイーブベイズ：ベイズの定理を用いて分類を行う手法
- SVM(サポートベクターマシーン)：境界線を用いて分類を行う手法
類似した過去の問い合わせ文章の提案
分類モデルにより分類されたラベルと、同じラベルを持つ過去の問い合わせの件名と受付内容を合わせた文章と、入力された問い合わせの件名と受付内容を合わせた文章の類似度を計算し、その中から一番類似度が高い過去の問い合わせの件名、受付内容、調査内容、対処内容を提案する。この提案により、過去の類似した問い合わせを参照することで対応品質の差を減少すること、ユーザーへの応答文章の作成時間の削減を狙いとしている。
また、「その他」に分類された場合は、過去の問い合わせ文章を提案せず、「担当者に確認してください」という文章を出力した。
分類手法は、問い合わせ内容と過去の問い合わせ内容をEmbeddingによりベクトル化し、cos類似度を用いて、類似度を算出した。
システムの評価
分類
分類モデルの正解率を表1に示す。正解率とは、「テストデータの中でモデルが正解した数」を「テストデータの総数」で割ったものである。
| 学習データ：テストデータ | ナイーブベイズ | SVM |
| 10：0 | 91.63% | 89.15% |
| 8：2 | 88.00% | 84.33% |
表1より、SVMよりもナイーブベイズの方が正解率が高いことがわかった。
また、ナイーブベイズにおいて学習データとテストデータを8：2にしたときの、各ラベルごとの精度を適合率、再現率を用いて測定した。測定結果を表2に示す。適合率とは、「各ラベルにおいてモデルが真と予測し正解した数」を「各ラベルにおいてモデルが真と予測した総数」で割ったものである。再現率とは、「各ラベルにおけるテストデータの真の数の中でモデルが正解した数」を「各ラベルにおけるテストデータの真の総数」で割ったものである。
| ラベル | 適合率 | 再現率 | f1スコア |
| 機能A | 90.86% | 95.86% | 93.20% |
| 機能B | 87.34% | 94.73% | 90.87% |
| 機能C | 90.72% | 89.82% | 90.22% |
| 機能D | 93.37% | 96.98% | 95.10% |
| 機能E | 89.61% | 90.73% | 90.00% |
| 機能F | 16.00% | 1.54% | 2.70% |
| 機能G | 89.36% | 84.81% | 93.20% |
| 機能H | 60.54% | 94.62% | 73.31% |
| 機能I | 96.60% | 84.68% | 89.88% |
| 機能J | 89.29% | 88.08% | 88.20% |
| 機能K | 30.00% | 22.19% | 25.42% |
| 機能L | 55.33% | 6.38% | 11.23% |
| 機能M | 0.00% | 0.00% | 0.00% |
| 機能N | 0.00% | 0.00% | 0.00% |
| 機能O | 0.00% | 0.00% | 0.00% |
| 機能P | 0.00% | 0.00% | 0.00% |
| その他 | 81.63% | 73.61% | 77.29% |
テストデータには、正解ラベルがすべて割り当てられているため、再現率の指標を用いて分類モデルを評価する。表2を見ると、データ数が多いほとんどのラベルで80%以上の再現率を確認することができた。一方、機能K～Pのデータ数が少ないものについては再現率が低い結果となった。したがって、高い再現率を保つためには、データ数を確保する必要があることがわかった。
また、機能Fにおいては、データ数が少なくないにもかかわらず、再現率が低い値となった。機能Fに割り当てられている学習データを目視で確認すると、他のラベルで散見されるようなテーマについての問い合わせが多いことがわかった。しかし、各ラベルの学習データの頻出単語を調査すると、機能Fにしか見られないような単語もあったため、ベクトル化手法を工夫することで、再現率を上げられるのではないかと考える。
類似した過去の問い合わせ文章の提案
学習データに使われていない過去の問い合わせデータを用いて、提案された文章が入力された問い合わせの応答に適しているかを関彰商事株式会社と共に確認した。
確認した結果、同じラベルから出力されるものの、過去の問い合わせデータに必ずしも適した応答となる問い合わせデータが存在するとは限らないことから、現時点では効率化に適した提案はできない結果となった。
成果と今後の提案
分類においては、ほとんどのラベルにおいて高い再現率を確認することができた。また、データ数が今後増えることで、再現率が低いラベルにおいても精度が上がることが予想できる。
以上のことから、分類システムを用いることで、対象機能を担当者が割り当てる際に分類結果と照合することで、誤った割り当てを防ぐことができると考える。誤った割り当てによる時間の削減につながる結果が得られたといえる。
一方、類似した過去の問い合わせ文章の提案では、適した提案を確認することができなかった。類似度の計算方法やベクトル化手法を工夫することで、解決することができると考える。類似した過去の問い合わせ文章の提案が困難な場合、さらに細かく分類を行うことができれば、用意しておいた定型応答文を提案するなどの方法も考えられる。
また、システム考案時はユーザーからの問い合わせが入力されると、自動的にユーザーへの応答文章が出力されるシステムを目指していたが、今回の授業では自動化を行うことはできなかった。LLM(大規模言語モデル)を用いた応答システムを作成することができれば、システム考案時の自動化の実装に大きく近づくと考える。
まとめ
サポートデスクの「担当者によって対応の質と時間に差がある」という課題を解決するために、対応品質の向上、対応時間の削減を目的とした過去の問い合わせデータを活用したサポートデスク支援システムの作成に取り組んだ。
作成したシステムでは、過去の問い合わせデータから作成した分類モデルにより、入力された問い合わせを対象機能の17種類に分類を行い、分類結果と入力された問い合わせから類似した過去の問い合わせ文章の提案を行った。
結果として、分類においては、ほとんどのラベルで高い再現率を確認することができた。目的であった対応時間の削減につながる結果が得られた。一方、類似した過去の問い合わせの提案では、適した提案を行うことはできなかった。適した提案を実装することができれば、対応品質の向上、応答文章の作成時間の減少も期待できるシステムになると考えられる。
後記
初めに、この場をお借りして本プログラムでサポートしていただいたすべての方々に御礼申し上げます。特に、データの共有やシステムへの意見などご協力いただいた関彰商事株式会社の皆様、データ分析やシステム作成についてご指導いただいた塩崎潤一様、他学位プログラムからの参加によりわからない点も多くある中でサポートしていただいた讃井知様、鈴木佳苗様、吉田智美様、チームメンバーとして異分野からの意見をいただいた秦涼太さんに心より感謝申し上げます。
以下では、本プログラムに参加し学んだ点と、システムの作成に平行して調査・実装していたLLMについて述べる。
学んだ点
- データを成形したり、データを目視で確認したりと実データならではの分析を経験できた。今まで取り組んだ授業では、整っている用意されたデータを使っていたことを改めて強く感じた。
- 企業や学外の方と連携しながらチームのリーダーとして、開発やミーティングを進めるという貴重な経験が得られた。
LLM（大規模言語モデル）の調査・実装
今回、分類や提案システムの作成と並行して、LLMを用いた応答システムも調査・実装を行っていた。調査・実装を進める中で、今回の問い合わせデータには機密情報が含まれていることから、LLMへ問い合わせデータを入力することがセキュリティ上の観点から難しく、断念する形となった。
応答システムとして、
- プロンプトエンジニアリング
- RAG
- ファインチューニング
の3つの手法について調査・実装を行った。それぞれの手法について、断念した理由も含め下記にまとめる。
プロンプトエンジニアリング
プロンプトエンジニアリングとは、LLMのプロンプトに直接データを与えることで、与えたデータに基づいた応答をさせる手法である。
今回のデータは、過去の問い合わせデータが大量にあるため、プロンプトにすべて与えることは困難である。また、セキュリティ上の観点からは、プロンプトにデータを直接与える必要があるため、プロンプトからデータが流出する可能性がある。したがって、今回は過去の問い合わせデータを用いたプロンプトエンジニアリングの実装は断念した。
RAG
RAGとは、
- データをEmbeddingによりベクトル化し、ベクトルデータをデータベースに保存する。
- LLMへのプロンプトに与える入力文章もベクトル化し、データベースから類似したデータを抽出する。
- 入力文章と一緒に抽出した文章もプロンプトに与えることで、抽出したデータに基づいた応答を行う。
手法である。
プロンプトエンジニアリングでのデータ数が多い問題は、RAGにより解消できたが、プロンプトからデータが流出する懸念があるという問題はRAGでも発生するため、過去の問い合わせデータを用いた実装は断念した。今回は、[1]を参考に公開されているデータを用いてRAGの実装を行い、通常のLLMでは誤った応答が出力される入力文章に対しても、RAGでは正確な応答を行えることを確認できた。また今回は時間が足りず、実装はできなかったが、T5というLLMのモデルをローカル上にダウンロードすることで、データの流出を防ぐことは可能であると考えている。ただ、T5はGPT-4等の他LLMと比べると、性能が良いとは言えないため、どれほどの応答精度が得られるかは注意したい。
ファインチューニング
ファインチューニングとは、LLMのモデルにデータを追加で学習させる手法である。
ファインチューニングを行うには、計算機資源が必要である。また、学習を行う際に、データやモデルをアップロードする必要があり、アップロード先でデータが流出する懸念があるため、実装を断念した。
以上の3手法のうち、今回の類似した過去の問い合わせ文章の提案では、RAGが一番適していると考える。RAGでは、データが増えたとしても、増えたデータをデータベースに保存する作業を行うだけで良いため、運用も簡単である。また、今回のような機密情報を含んだデータを用いたRAGの実装を行う場合、データ内の機密情報を削除する作業を行い、データベースに保存することで、機密情報の流出を防ぐことができるかもしれない。
参考文献
[1] ローカル環境でRAGを用いた文書生成とCTranslate2を用いた高速化. https://note.com/sharp_engineer/n/n10da2a8b9392. 2024年2月17日.