はじめに

KAG(KDDIアジャイル開発センター)/KDDIの三宅 @jnymykです。

オールAzureなRAGアーキテクチャで、生成AIチャットボット「デバサポAIチャット」を企画・開発しました。 また、この生成AIチャットボットを使って、社内文章・ナレッジデータを取り込んで法人のお客さま向けのデバイスサポート業務への活用ができるかPoCを実施しました。

今回はその中で私がプロダクトオーナー・スクラムマスター・開発者として3つのロールでプロジェクトに携わった中で得た知見、苦労したことなどを共有します。

RAGとは？

RAG(Retrieval Augmented Generation)とはLLM(大規模言語モデル)の機能を拡張しAIからの回答精度を向上させるための手法です。 AIは質問に対する回答を生成する前に、インターネットや特定のデータベースから関連する情報を検索します。この検索により得られた情報を質問内容に文脈として付加することで、AIが学習していない情報(社内情報等)を元に回答が出来るようになります。また、AIが事前に学習済みの一般的な情報から回答する場合よりも、正確で詳細な内容を回答できます。

結論

• 生成AIを用いたプロダクト開発やチューニングは、より探索的な側面が強く、小さくフィードバックループを回して価値を生み出そうとするアジャイル開発との親和性が非常に高いと感じました。
• RAGによる生成AIチャットボットで社内文章・ナレッジデータを考慮した回答が得られました。ただし、それぞれのユースケースに即した回答内容の精度を求めていくとチューニングがほとんどの場合において必須となることが分かりました。
• RAGチューニングに近道はなく地道に改善施策を実行して検証するというサイクルを回す必要があると分かりました。
• 今回、初めてAzureのみで設計・開発してみました。チームがAWSなど他のパブリッククラウドに精通していれば共通の概念や差分を理解しやすいため、Azure上で想定していたものが実現できました。

プロダクト概要

デバサポAIチャットはKDDI株式会社ビジネスデザイン本部デジタルチャネル営業部デバイスサポートG(以下デバサポG)向けに開発された、セキュアに社内文章データを活用できるAIチャットです。

デバサポAIチャットはスマートフォンやモバイルWiFiルータなどのデバイスの仕様や、過去のトラブルシュートを取り込んだAIチャットボットとなっており、トラブル内容をチャットに入力すると過去のナレッジデータから解決につながる情報をAIが回答します。

プロダクトの背景

法人のお客さま向けスマートデバイスや提供サービスのラインナップ増加により、お客さま申告受付数は年々増加しており、これらをサポートするデバサポGチームの対応負荷の増大が課題となっていました。 また、年間数百件の申告のうち、申告受付時点で約38%が原因箇所不明か調査依頼先の誤りとなっており、初期対応の工夫によりサポート対応を効率化できる可能性がありました。

作ったもの・やったこと

アーキテクチャについて

デバサポAIチャットは全てAzureでアーキテクチャを設計しました。 セキュアに社内文章やナレッジデータを取り扱うためにPrivate Endpointを用いて閉域化されたネットワーク上に構成されています。 RAGを実現するための外部のベクトルストアとしてAzure AI Search(旧Azure Cognitive Search)を利用しています。 また、フロントエンドのホスティング、AIチャット・社内文章取り込みのバックエンドアプリをContainer Apps上で実行しています。 今回は短期集中で企画、開発、効果検証をやり切るPoCということで、あえてファイルのアップロード画面はオミットしました。Azureポータルから直接社内文書をアップロードすることにしています。

PoCでは以下2種類の社内文書・ナレッジデータAIチャットボットに取り込みました。

1. 法人向けスマートフォンおよびモバイルWiFiルーターの取り扱い説明書(PDF): 9機種分の取り扱い説明書ファイルを取り込みました。それぞれ数百ページほどのボリュームのPDF形式のファイルです。

2. 法人のお客様からの不具合申告の過去対応履歴(CSV): 過去に不具合申告が多かった上位10機種分を対象に過去に対応した不具合申告情報を約1000件ほど取り込みました。過去に対応した案件のサマリの情報や対応履歴・営業担当とデバサポG間のチャット履歴が含まれています。

また、デバサポAIチャット実装にあたり利用したライブラリを紹介します。

• LangChain(Python)

　RAGを実現するにあたり必要な下記の処理に利用しており、自前で実装するよりも簡易に実装できました。

* アップロードした社内文章・ナレッジデータの読み込み
* ベクトル化してベクトルストアとして利用しているAI Searchへの保存
* 質問内容から関連するデータの検索
* Azure OpenAI ServiceとのQA

• chatbot-ui

　チャットボットUIのOSSであるchatbot-ui を利用してチャットボットのUIを実装しました。そのままだと背景が黒でユーザーに使い辛そうな印象を与えていたため、KAGのコーポレートカラーに合わせて青と白をベースのUIに変更しました。利用しないメニューや設定などは削除して、必要最低限のものだけ残しました。 また、今回ターゲットにしたユースケースではまず対象の機種名や過去の不具合申告案件番号を質問に入力する必要がありました。少し複雑なフォーマットだったため、入力方法や例をTOP画面に表示しました。

得られた知見

• 生成AIを活用したプロダクトの開発には、アジャイル開発の親和性が高く、価値を出しやすいと改めて感じました。

　　* 試行錯誤しながら探索していくのでアジャイル開発との相性が良かったです。 　　* AIチャットにどのような機能を持たせるか、もしくはチューニングとして想定される多くの案のうちどれを進めるか、やれることの選択肢が非常多い中で、より価値が高いチューニングや改善策は何か？を常にPO・SM・Dev・UX/UIデザイナーで議論しながら進めていきました。 　　* 実際にやってみて効果があったもの、価値があったものはより深く進めていき、思ったより価値が出なかったものはやめたりと短くフィードバックのサイクルを回しながら進めていきました。

• チューニングについて

　　* データの取り込み・検索について 　　　　* 対象機種名、不具合の管理番号など業務上キーとなる情報をデータ取り込み時に埋めこんでおきます。 　　　　* 情報の検索時にはこれらの情報でフィルタして検索することで関連する情報のみを考慮でき、回答精度の向上につながりました。 * AIのAPI呼び出し制限、トークン上限超過を回避するために以下の対応をしました。 　　　　* 読み込み対象ファイルを分割する * データ読み込み時に各種制限・上限を回避するためリクエスト数を制御する(Azure OpenAI ServiceのRateLimit回避など) * AIのトークン上限回避のためチャンク分割する 　　* チャンク分割時のパラメータはchunk_sizeの値の20%程度の値を目安にchunk_overlapに指定すると他のsizeと比較して良い回答が得られていました。

苦労したこと

• RAGやAI回答精度向上のためのチューニングは明確な正解がなく、見積もりが難しかったこと。
• 定量的な評価だけでは業務活用できるかどうかの見極めが難しく、現場の人に使ってもらって定性的に価値を検証する必要があること。

まとめ

今回のPoCでは、AzureとRAGを利用して生成AIチャットボットを開発して業務活用の可能性を検証しました。 実際に経験してみるまではRAGで社内情報・ナレッジデータを取り込むことですぐに素晴らしいものが出来ると考えていましたが、PoCの中で実現できたこと・出来なかったこと、時間をかければ実現できそうなことなど様々な発見がありました。 今後、同様のプロダクトを検討されているお客様の力になれる知見が溜まってきているので、ぜひ我々KAGにお声がけください。

弊社ではKAG Generative AI Labを立ち上げて生成AIに関するさまざまな取り組みを進めています。

参考プレスリリース

• KDDIアジャイル開発センター、Azure OpenAI ServiceとAmazon Bedrockを用いて生成AIを活用したプロダクトを複数開発

RAGによる社内文書検索のチューニング知見も強化 https://prtimes.jp/main/html/rd/p/000000009.000115171.html

• KAG Generative AI Labにより生成AIを活用しコーディング業務を約38％ 短縮

https://prtimes.jp/main/html/rd/p/000000007.000115171.html

• 【Microsoft Teamsなどの既存プロダクトに生成AIを導入】KDDI社員1万人が利用できるKDDI AI-Chat for Teams を開発

https://prtimes.jp/main/html/rd/p/000000008.000115171.html