AWSサービスによるQAボットの構築から見えたAI活用のポイント

平井周 - Nomura Research Institute, Ltd.

はじめに

こんにちは。NRIでAWS・Azureの技術支援を担当している平井です。
この1年で、パブリッククラウドのAIサービスに多くのアップデートがあり、AIを活用したビジネスや業務改善への関心がより高まっていると思われます。
しかし、「AIサービスをどのように適用すればいいのか」、「実際の推進方法が分からない」といった悩みを抱えている方も多いのではないでしょうか。
筆者自身、AI分野の知識はあまりないのですが、NRIが提供するパブリッククラウド支援サービスQUMOA^１のサービスデスクの負荷軽減を目的に、AWSのAI系サービスを取り入れたQAボットの構築に、挑戦しました。
本記事では、AWSのAIサービスを用いてQAボットを構築したプロジェクトから得た知見をもとに、同様の悩みを抱えている方々に向けて、AIサービスを利用したプロジェクトの進め方や精度向上に向けた検討ポイントについて解説します。

※1) QUMOA（クモア）とは

NRIが提供するパブリッククラウド運用サービスです。最大の特徴は、NRIがクラウド黎明期から多数のお客様のクラウド導入・運用を支援してきた「ノウハウと人材」です。それらを新しいナレッジやテクノロジーと掛け合わせ多彩なサービスとしてご提供しています。

AWSサービスによる独自のRAGを構成した環境を構築

今回構築したQAボットは、API経由で使用可能なRetrieval-Augmented Generation(以下RAG)を利用しました。

AI機能は、Amazon Bedrock（Bedrock）のナレッジベース^２を活用しています。RAGは、大量のテキストデータから関連する情報を検索・抽出し、それを基に自然な応答を生成する手法です。今回は、筆者が所属するQUMOA運営チームのサービスに関する過去の問い合わせ応答履歴や、サービス仕様書・環境設計書などを検索対象として登録させることで、QUMOAサービスの問い合わせに特化した、QAボットの応答の質と適合性を高めることを目指しました。

※2) ナレッジベースとは

AWS のナレッジベースとは、Bedrockの機能の一つであり、Amazon S3などに格納されたデータをベクター検索技術により高速に検索できる知識ベースサービスです。これにより、大量の非構造化データから必要な情報を素早く見つけ出し、チャットボットなどのアプリケーションに提供することができます。

構成としては、よくあるWebシステムの構成となっていますが、今回のQAボットのポイントは大きく3つあります。

1つ目は、API GatewayのREST APIとWebSocket APIを併用している点です。REST APIでは、QA履歴を管理する「チャット履歴DB」から、ユーザーに紐づく過去のスレッド一覧の取得やスレッドタイトルの更新、スレッド削除のAPIを実装しています。一方、WebSocket APIはナレッジベースを利用したRAGの実行プロセスを実装しています。

2つ目は、AWSのAIサービスとしてナレッジベースを採用している点です。本システムでは、RetrieveはナレッジベースのAPIを使用し、GeneratorはBedrockを直接利用するように設定しています。チューニングの余地がある点や、あるいはAmazon Kendraへの切り替えのしやすさなどの利点があり、今後の回答精度向上に向けた検討もしやすくなっています。また、ナレッジベースはベクターストアとしてAmazon OpenSearch Serverlessを自動的に新規で作成することができます。（作成済ベクターストアがある場合、そちらを選択することも可能です。）

3つ目は、マスク処理を実施している点です。今回、RAGを構成するにあたってインプットとしているデータは、利用者の個人情報などが記載されている問い合わせ履歴などが対象となっています。昨今のAIシステム構築にあたって、利用するデータの個人情報保護は必須となっています。そこで、S3イベントからAWS Lambda（Lambda）を起動し、LambdaからAWS Glue Jobを起動してマスク処理するよう実装しました。

以上の構成を踏まえて、作成された画面は以下となります。

「質問と回答」に加えて、参照ドキュメントとして出典元（サービス仕様書や問い合わせ履歴など）、ユーザー別の本システムを利用したQA履歴を左ペインに表示されるようにしました。

AIサービスを用いる際のプロジェクトの進め方

パブリッククラウドのAIサービスを活用したQAボットを構築については、2-3ヶ月かけて、以下のようなスプリントを実施するアジャイル的な進め方で開発を進めました。

1. ワイヤフレーム検討・PIIマスク方針策定（Miroを使用したアイデアだし）
2. サンプルページ実装・API仕様策定
3. チャットUIでの質疑応答の実装（バックエンド等の整備）
4. Retriever・Generator・ナレッジベースの実装・サンプル質問の準備
5. Retriever結果の表示・履歴保存の仕様策定
6. ユーザーテストの実施
7. 履歴周りの実装・プロンプトエンジニアリング
8. ナレッジベースの精度向上に向けた対応・ユーザーテスト結果の取り込み

今回のプロジェクトは、AWSのプロフェッショナルサービス担当者と一緒に推進しました。プロジェクト開始当初は、必要となる機能や実際のAIサービスの精度、開発規模がはっきり見えていませんでしたが、まずは簡易的に動くシステムを準備・共有し、一緒に繰り返しトライ＆エラーを行うことで、徐々に勘所やコツをつかむことができます。
また、実際の想定される利用者に向けて、一早いユーザーテストを実施することも重要なステップです。開発メンバーだけでは、定性的な評価が難しい回答精度の改善に囚われがちですが、必要最低限の機能を取り込んだ段階からテストを実施し、実際の利用者からの回答精度について高い評価が得られたことで、回答精度に固執せずに全体的な機能拡充に力を入れることができました。

QAボットの今後の精度向上に向けた検討

今回、QAボットで採用したようなRAGのシステムは、一般的には以下のような遷移するようになっています。その中から、AIに詳しくない筆者の観点でも取り組みやすい、今後の改善点について数点候補を挙げてみます。

①知識データ（生ファイル）

学習元となるデータについては、文書の本文のみ読み取れるような状態を目指すことが求められます。特に、PDFで作成されている設計書などは、ドキュメントフォーマットの考慮や図表の分離などを実施する、Lambda等を使用した前処理の仕組みの導入を検討しています。

②インデックス化

生ファイルを検索可能な状態になるように、知識ソースにインデックス化する際の戦略として、chunkの最適化を候補として検討しています。ナレッジベースに実装されているchunking戦略は、2024年5月時点では日本語に対して自動でchunkサイズを決定するような機能はありません。そのため、文字列を固定の長さを指定した値で機械的に区切ってインデックス化することが求められるため、文書構造を考慮して、chunkサイズを今後見定める必要があります。

③プロンプトエンジニアリング

定量評価可能なメカニズムを使用しつつ、モデル選択だけでなくプロンプトエンジニアリングが、回答精度向上の策として期待されます。対策案としては、生成プロンプト実施する際のテンプレートのアップデートを検討することや、LLMにプロンプトを記述させるプロンプトジェネレーターという手法なども候補に挙げられます。

さいごに

いかがでしたでしょうか。
今回は、AWS Bedrockのナレッジベースというサービスを用いた、ＱＡボット構築プロジェクトを題材に、実際に構築したシステムやプロジェクトの進め方、精度向上に向けた今後の施策案などについてまとめてみました。
このようなAIサービスを実際に業務に活用してもらうためには、どのようなシステムにするべきかといった正解はなく、利用者のニーズに合わせて要件決め・サービス構築する必要があると思います。
AIサービスの活用に悩んでいる方々にとって、本記事が参考になれば幸いです。