生成AIでサポートチームをサポート 〜 チャットボットで業務効率化へ 〜
はじめに
2024年4月26日に株式会社ヌーラボで開催された､"Geeks Who Drink in Fukuoka - 私の業務効率化editon -"に登壇しました｡
この場では､｢生成AIでサポートチームをサポート 〜 チャットボットで業務効率化へ 〜｣と題し､生成AIと組み合わせたチャットボットを社内のチャットに導入しようと考えたきっかけや､実際に導入してみた結果､その考察を発表しました｡発表した内容をnoteでも紹介します｡
発表資料
なぜサポートチーム向けチャットボットを作ったのか
チャットボット試作のきっかけ
BacklogのWebサイトにはお問い合わせフォームがあり､現在Backlogを利用中のユーザーや導入を検討中の方からの問い合わせを受け付けています｡このお問い合わせフォームがあるページにはヘルプヘージの検索窓もついていて､お問い合わせ前にキーワード検索でヘルプページを検索できる仕組みになっています｡
この検索窓の設置によって､ヘルプページの検索で疑問点が解消し問い合わせ件数が減少するという効果がありました｡加えて､キーワードではなく自然言語での問い合わせに回答するチャットボットがあれば､サポートチームの業務負担が減少し､問い合わせる側も素早く回答が得ら双方にメリットがあるのではと考えました｡
たとえば､この図のようにチャットボットの利用者が｢孫課題をつくりたいんだけど､どうやったらいい?｣と尋ねるとゴリット君が博多弁で答えてくれる､そんなイメージです｡
ちなみに､この回答文は開発したチャットボットから得たものです｡元の質問文に"博多弁で答えて"と付け加えるとこのような回答が得られました｡博多弁が合っているかどうかはともかく､回答の内容は期待したものが得られました｡
アイデアは良さそうだけど､不正確な情報を回答した場合のリスクが高い
こんなチャットボットがWebサイトに設置されていたら､ヘルプページをキーワード検索するよりも手軽に必要な情報が得られそうです｡ただ､気になるのはチャットボットが不正確な情報を回答した場合です｡
この図のように､利用者の｢音声で課題を登録できる?｣という質問に対し､ゴリット君が実際には存在しない機能について自信満々に説明したとします｡その結果､利用者は混乱し､サポートへの問い合わせが増えることになるでしょう｡
この回答文もチャットボットから得たものです｡｢音声で課題を登録できる?｣という質問文に"わざと間違った内容を回答して"と付け加えるとこのような回答が得られました｡
そこで､違う視点で仮設をたててみた
"お客様からの問い合わせに対する回答文章"と"関連するヘルプページのリンク"を生成できれば､サポートチームの業務負荷を減らせるのでは?
つまり､サポートチーム向けのチャットボットとして社内に設置しようという考えです｡サポートチームが利用するのであれば､多少不正確な回答があったとしてもそれが誤りだと気づくことができます｡あらかじめ回答文の文体や体裁を定めたプロンプトを用意することで､一定のルールに沿った回答文案を生成することができそうです｡
併せて関連するヘルプページのリンクを生成できれば､ページを探す手間も省けます｡
開発中に出会った本
考えがまとまったところで､チャットボットの試作を始めました｡そんなかで､ある1冊の本に出会いました｡
この本に､とても参考になることが書かれていました｡ここでの文脈は､カスタマーサポートの部署に顧客の問い合わせ内容に回答するチャットボットを導入した際の効果に関するものです｡3つ目の引用にある"エージェント"はカスタマーサポート担当者を指します｡
カスタマーサポート分野は現時点で生成AIが最も威力を発揮するとされている分野
サービスの質を落とさず､場合によっては高い顧客満足度と高速化を達成しつつ､顧客とのやりとりを半自動化できる
不適切な出力を顧客に返すリスクを回避しつつ､エージェントの作業を効率化できる
生成AIの導入によりカスタマーサポートの質･生産性･満足度が向上する
どのようなものをつくったのか
実際にどのようなものを作ったのかを簡単な図にしました｡以下のスライドのページと次のページです｡
Backlogヘルプセンターに公開されているヘルプページは､大きく分けて､"説明本文"､"左側のメニュー"､"最近表示した記事や関連記事などを表示するフッター"で構成されています｡PythonでWebページをスクレイピングするプログラムを作成し､不要な部分を削った約300ページのHTMLファイルを取得しました｡
これをKnowledge Base for AWS Bedrockを使ってOpenSearch Serverlessに登録してRAG(Retrieval-Augmented Generation)を構築し､問い合わせのリクエストに回答できるようにしました｡
導入してみたものの…
ヘルプページのテキスト情報量が少ないことや､Knowledge baseを構築する際のチャンクの分け方､検索タイプ(ハイブリッド検索やセマンティック検索)の違い､プロンプトの調整の難しさなどがあり､導入当初は思うような精度には届きませんでした｡
改善してみた結果
生成AIチームと話をしながら試行錯誤を続けた結果､チャットボットの回答をそのままユーザー向けに使えそうな精度の文章が生成されるようになりました｡関連ページへのリンクも正しいURLが提示されました｡スライドでは､3つの例を紹介しています｡それぞれ､簡単な質問に対して､チャットボットが詳細な回答を示しています｡
考察
導入当初の段階ではなぜ思うような回答精度が得られなかったのかを整理してみました｡今回の試作では､Backlogヘルプセンター内のページにある画像は解析対象外でした｡そのため､人間にとっては情報として存在しているものの生成AIにとっては情報として扱えず､回答精度の低下の一因となったと考えられます｡また､生成AIが正しい情報を取得しているにもかかわらず､ハルシネーションが発生することもありました｡
チャットボットを業務効率化に結びつけるためには
画像内の情報はサイト内検索でもヒットせず､AIの解析対象にもならないため､ヘルプページのテキスト情報量を増やすことが大切です｡その結果､人にもAIにも優しく､満足度の高いコンテンツとなるはずです｡
ハルシネーションについては､その対策に様々な研究が行われていますが00％の正確性を求めることは困難とされているようです｡たとえば､このような例があります｡
できることとして､プロンプトの工夫や類似度の高いドキュメントを抽出し推論につなげるなど､実装の工夫により精度を高めるといった対策が考えられます｡
そして､もっとも大事なことは"もととなるドキュメントを定期的にメンテナンスする"ことです｡もとの情報が古いままだったり誤っていると回答精度を上げることはできません｡
まとめ
生成AIと連携したチャットボットはカスタマーサポートの業務効率化と相性が良い｡
前述の本に､論文を引用したデータとともに分かりやすい解説が載っているので､気になる方は参考にしてください｡
ドキュメントの継続的なメンテナンスが大事
これは生成AIを導入するしないに関わらず大切なことです｡
宣伝
Qiitaに生成AI関連の記事を投稿しています｡Slackと生成AIを組み合わせたチャットボットをいろいろ試しています｡
おまけ
なぜ､OpenSearch Serverless?
今回試作したチャットボットは､Knowledge base for AWS BedrockでRAGを構築し､そのベクトルデータストアにはOpenSearch Serverlessを利用しています｡その理由は2つ｡
社内手続きがいろいろ大変
取り込むデータ量や規模､費用の観点からOpenSearch ServerlessよりもPineconeが適しているのですが､AWS外のサービスを新たに利用するには社内手続きがいろいろ大変なので､スピード重視でOpenSearch Serverlessを選択しました｡
AWS Marketplace経由でPineconeを利用できるのですが､それを知ったのはずいぶん後になってからでした｡しかし､AWS Marketplace経由であってもPineconeにアカウントを作成する必要があるので､やはりそれはそれで社内手続きを経る必要があり､結局OpenSearch Serverless一択だと思います｡
ハイブリッド検索が使える
OpenSearch Serverlessは､通常の検索に加えて"セマンティック検索"や"ハイブリッド検索"をサポートしています｡これらの検索タイプがAIの回答精度に影響するため､OpenSearch Serverlessを使い続けています｡
もし､Pineconeでハイブリッド検索やセマンティック検索がサポートされたたら乗り換えるかもしれません｡
この記事が気に入ったらサポートをしてみませんか？