社内お問い合わせBotの仕組みと学び

Transcript

1. 1 Confidential 社内お問い合わせ Botの仕組みと学び AI/LLM Solution team @nish
2. 2 Confidential • 2013/4：新卒からソフトウェアエンジニア（3年） • 2016/4：業務委託としてソフトウェア開発に従事 （6年） • 2022/4 : メルカリに参画。社内向け⼈事評価システ ムを中⼼に開発（2年） • 2024/1〜 : AI/LLMを使った社内プロダクトにTLと して従事 ⻄村 友⾏
3. 3 Confidential 社内お問い合わせチャットボットの簡単な紹介 今⽇話すこと HiYo-Chanの紹介と仕組み HISASHIの紹介と仕組み 02 03 01 最後に 04
4. 4 Confidential 1. 社内お問い合わせチャットボットの簡 単な紹介 それぞれの社内お問い合わせ Botが何ができるのか？機能と動作イメージ
5. 5 Confidential 社内お問い合わせチャットボットの紹介と開発の歩み 本⽇紹介したい開発範囲 2020年4⽉ HISASHI リリース （社内でよくある質問に答える） 専⽤の機械学習モデルを作成して動作する HiYo-Chanの開発‧リリース （QA Slack Channelごとに検索） ベクトル検索のRAGベースで動作する 2024年1⽉-4⽉ 開発継続 2025年1⽉-7⽉ 開発継続 New HISASHIの開発‧リリース （社内のよくある質問に答える） 専⽤の機械学習モデルとLLMを活⽤して質問に答える
6. 6 Confidential 2.HiYo-Chanの紹介と仕組み HiYo-Chanがどの様に動くのか？どの様な工夫が重要だったのか？
7. 7 Confidential 紹介 - ⽣成AIチャットボット “HiYo-Chan” 解決策
 課題
 • お問い合わせ先：対応工数の肥大化 
 • 問い合わせを読み、理解する 
 • 回答生成のために調査する 
 • 回答を行う
 • 従業員：待ち時間の長時間化 
 • どこにナレッジがある？
 • ナレッジページから必要な箇所を見つける 
 • 解決しない場合は、Slack過去ログを読む 
 • 返事を待つ
 • RAGを活用した生成AIチャットボットを開発 
 • 社内に蓄積された知識データを活用して、従業 員からの問い合わせに対して自動回答する 

8. 8 Confidential 紹介 - ⽣成AIチャットボット “HiYo-Chan” HiYo-Chanとは？ • Slack上での問合せに対して、社内知識に対してベクト ル検索を使ったRagで自動回答する • 導入Slack チャンネル：63チャンネル • 対応言語：日英 • 対応ソース：Confluence、SerivceNow、Slack 対応工数 約６割減!! 問い合わせ担当者の回答時間削減
9. 9 Confidential HiYo-Chanの仕組み LangChainを使い、社内に分散している知識を取り込み、ベクトル検索 のRAGで関連知識を検索するチャットボット
10. 10 Confidential 必要不可欠だった機能実装 • ベクトル検索⽤のデータは 毎⽇⾃動で最新化 • 社内ドキュメントに最適化 • Slackからの回答 • 検索‧回答精度の評価
11. 11 Confidential ベクトル検索用のデータは 毎日自動で最新化 回答の精度が悪い⼀番の理由 回答するために必要な社内知識が資料化されてない事 よって、適宜資料を改善する必要がありますが、定期的な最新化がなけ ればにチャットボットに反映されないので重要 AIによるお問い合わせ対応 
 担当の方による資料の更新 
 
 生成された 回答が期待 はずれ
 
 ベクトルDB の定期的な 最新化

12. 12 Confidential 定期的な最新化の設計で良かったポイント Cash Store 増分⽅式ではなく、毎⽇ゼロからIndexを再構築する。⾼負荷‧⾼コス トな処理の結果はキャッシュして再利⽤する。 • =>処理がシンプルになった。 • =>機能追加‧データ構造の変更などが容易に。 • =>簡易的なバックアップ Daily Cron Job Embedding Model Data Source Azure AI Search Alias 処理が成功したindexのみに紐づく Index 新/旧のIndexが作成されます。
13. 13 Confidential 社内ドキュメントに最適化 ベクトル検索では、どのようにチャンクを作成するのかが重要だと思いま す。初期段階から社内の知識データに合わせて最適化できたことは、⼤きな 成功要因だったと思います。 実施した最適化の１部 - ヘッダー要素ごとにチャンクを作る - ページタイトルなどのデータを各チャンクに追加 - ⽬次要素の削除 - マークダウン形式に変換 - 不要な改⾏‧スペースを削除 - ⼩さすぎるChunkは、マージを試みる - metaデータによるフィルター - テーブルデータは、⾏ごとにチャンクを作る（WIP）
14. 14 Confidential Slackからの回答 Slackからの回答とは？ 類似する過去のお問い合わせ履歴を検索し、要約が表⽰される 様になっています。質問する⼈‧返答する⼈ともに類似ケース を⾒える事で、対応⼯数を下げる狙い。 機能としてはまだ不⼗分ですが、何らか回答精度が⾃動的に向 上する要素を追加したいと考え考え出しました。担当者が Slack上でお問い合わせ対応を⾏うことでデータが蓄積され、 結果として HiYo-Chanの回答精度が⾃動的に向上することを 狙っています。 制限 ⼀⽅で、最初は回答⾃体が作れる様にしたかったのです。ただ 回答⾃体を作るためには、データの質が悪く、データを加⼯す る新しい⼯夫が必要と判断し、今の回答の形式になりました。
15. 15 Confidential 検索‧回答精度のデータセットを使ったEvaluation データセットを使ったEvaluationの課題 • 評価したい機能によって、評価の指標が変わるので、実装の抽象化が難しい。 解決策 LangSmithにデータを集約し、Traceデータから都度必要な評価データセットを作成でき る環境を整備する事で少ない⼿間で評価できる様にした。
16. 16 Confidential 実例 - 開発した機能がむしろ悪影響である事が判明 開発した機能 お問い合わせに含まれる「枕⾔葉やクッション⾔葉、不要な定型⽂、中⾝のない⽂ 章」を排除する事で、ベクトル検索の精度が向上すると考え、１つ機能を開発した。 当時の振り返り この機能のリリース前後を⽐較すると、簡易的な評価においてスコアが微妙に下がっ てたのですが、お問い合わせ内容の違いと考え、HiYo-Chanの回答⽣成⾃体は良く なっているとチームでは考えていました。
17. 17 Confidential 振り返り - 必要不可欠だった機能実装 • ベクトル検索⽤のデータは 毎⽇⾃動で最新化 • 社内ドキュメントに最適化 • Slackからの回答 • 検索‧回答精度の評価
18. 18 Confidential HiYo-Chanの今後のロードマップ • コンテキストに、社内知識だけではなく、ユーザ属性や状況など 様々な情報を追加する • 例えば、経費精算や稟議申請などのためのツールを追加し、処理 できるタスクを増やす • 明⽂化されてない社内知識を、より簡単に明⽂化できる仕組みの構 築
19. 19 Confidential 3.HISASHIの紹介と仕組み HISASHIがどの様に動くのか？どの様な工夫が重要だったのか？
20. 20 Confidential 紹介：社内チャットボット “HISASHI” HISASHIとは？ • Slack上で、社内のよくある質問に答える⻑ 年愛されているチャットボット • 2020年から社内で稼働 • 対応言語：日英 New HISASHIとは？ 次の問題に対処するためにアップデート • 少数チームで、２つチャットボットを開発するリ ソースがない。 • 社内にどんなAI Agentがあるのか分からな い？
21. 21 Confidential アップデート前の HISASHIの仕組み HISASHI (Slack) Backend  専⽤機械学習モデル （事前にトレーニング済み） 事前に専⽤機械学習モデルを⽣成し、ユーザの投稿に最もマッチするインテント の回答が返却される。社員なら、誰でもHISASHIの知識を追加‧編集できる。 • インテント数：２０００以上 • トレーニングフレーズ：合計約２万 インテント1 • Training Phase • Answer インテント2 • Training Phase：フロアマップ‧地図‧オフィスマップ • Answer：フロアマップへのURL インテント3 • Training Phase • Answer
22. 22 Confidential ”New HISASHI”のアップデート内容 • 社内で増えていくAI Agentを、 HISASHIのホーム画⾯で⼀覧表⽰ • HISASHIに質問を⾏うと、HISASHI が回答すると同時に最適なAI Agent を検索し、存在すれば紹介 • 少ないリソースで開発出来る体制を 整えるために、バックエンドを HiYo-Chanと完全に統合。HISASHI の内部的な仕組みを完全に作り替え る
23. 23 Confidential ”New HISASHI”の回答生成のアップデート HISASHI (Slack) HISASHI Backend 専用機械学習モデ ル Yes confidence score 0.99以上？ 回答する Fallback RAGによる回答を生成 30% 60% 10% 上位15個 No 回答する インテント1 • Training Phase • Answer • Condition インテント2 • Training Phase：フロアマップ‧地図‧オフィスマップ • Answer：フロアマップへのURL • Condition：trigger this intent when user want floor map インテント3 • Training Phase • Answer • Condition LLMによる判断 • 事前にそのインテントが使われる条件をLLMで⾃動⽣成（Condition値） • 回答⽣成のワークフローに、LLMで相応しい回答を判断するステップを追加。
24. 24 Confidential なぜベクトル検索による RAGに切り替えなかったか？ • ⻑年積み重ねられた社内知識の⼀部を放棄する事に⼤きな損失になると考えた • RAGに置き換えると失われる特性が存在した • お決まりのキーワード‧‧誤⽤のキーワード‧スラングを使った問い合わせ にも対応できる柔軟性を獲得 • お決まりキーワードを使った低いレイテンシーの回答⽣成 • ２千以上の選択肢からある程度最適な回答を推測できているので、将来的に マルチエージェントの仕組みがなくても、最適なツールの選択に応⽤出来る 可能性がある 従業員 Query：地図 HISASHI Answer：フロアマップ ⽇本語として、地図とフロアマップは違う意味なので、LLMでは紐付けずらい。
25. 25 Confidential 学び 注力する開発機能のバランスが悪かった。 • 結果として解決するべき課題へのソリューションはスケジュール通り開発 できましたが、HISASHIの完全リプレースに多くの時間を使ってしまい、 ユーザが真に求めている機能のリリースは少なくなってしまった。 真に求めている機能の例 • 明文化されている知識の効率的な追加・更新・削除の仕組みの提供 • マルチエージェントの実現
26. 26 Confidential 最後に 最初にナレッジシェアに注力出来た事 は、大きな成果を繋がった