はじめに
AWS re:Invent2024でも多くの生成AIの話題があがりましたが、やはりアップデート内容的にも、徐々にAIを試してみるフェーズから、AIを本番活用するフェーズに移りつつあることが見受けられますね。
その中でもAmazon Bedrock関連のアップデートもたくさんありました。re:Invent開催事前のアップデートも含めると30件ほどあったとか…
そんな今回の記事は、Retrieval-Augmented Generation(以下RAG)機能付きAIチャットボットを約半年運用して得た知見をもとに、AIサービスを利用したプロジェクトのリリース後の運用に際して実施した取り組みや、精度向上に向けた検討ポイントについて解説します。
AIを活用したビジネスや業務改善への関心がある方の中でも、これからAIシステムを運用する人、運用を見据えてこれからシステム構築する人 に向けて刺さればよいなと思っています。
ナレッジベースによる独自のRAGを構成した環境を構築
構築したAIチャットボットは、API経由で使用可能なRAGを利用しました。
前述の通り、Amazon Bedrock（Bedrock）のナレッジベースを活用しています。今回は、私が所属するチームのサービスに関する過去の問い合わせ応答履歴や、サービス仕様書・環境設計書などを検索対象として登録学習させることで、サービスの問い合わせに特化した、AIチャットボットの応答の質と適合性を高めることを目指しています。
構成としては、よくあるWebシステムの構成となっていますが、今回のAIチャットボットのポイントは大きく3つあります。
①REST APIとWebSocket APIを併用
1つ目は、API GatewayのREST APIとWebSocket APIを併用している点です。
REST APIでは、QA履歴を管理する「チャット履歴DB」から、ユーザーに紐づく過去のスレッド一覧の取得やスレッドタイトルの更新、スレッド削除のAPIを実装しています。一方、WebSocket APIはナレッジベースを利用したRAGの実行プロセスを実装しています。
②ナレッジベースを採用
2つ目は、AWSのAIサービスとしてナレッジベースを採用している点です。
本システムでは、RetrieveはナレッジベースのAPIを使用し、GeneratorはBedrockを直接利用するように設定しています。re:Invent2024のアップデートで、Amazon Bedrock knowledge base with an Amazon Kendra GenAI indexという、Amazon Kendra knowledge base with Vector IndexとAmazon Q Businessの中間にあたるようなサービスも出ていますが、チューニングの余地がある利点などを踏まえ、ナレッジベースの方があるかと思います。
③わりとしっかりマスク処理を実装
3つ目は、マスク処理を実施している点です。
今回、RAGを構成するにあたってインプットとしているデータは、利用者の個人情報などが記載されている問い合わせ履歴などが対象となっています。昨今のAIシステム構築にあたって、利用する学習データの個人情報保護は必須となっている上、いずれは社外展開を目論んだシステムとしたかったため、Bedrockの機能にあるマスク処理機能の他に、Ginzaを利用したマスク処理をしています。S3イベントからAWS Lambda（Lambda）を起動し、LambdaからAWS Glue Jobを起動して、インプットデータについては自動的にマスク処理するよう実装しました。
RAGシステムの精度向上と利用促進戦略
ここからが今回の本題です。せっかくAIチャットボットを作ったので、継続的に使ってもらえるために、実施したことを解説します。
大別すると、以下2つの観点になります。
- RAGの精度を向上させるための方法
- RAGシステムの利用促進戦略
上記の観点で実施したことをそれぞれ説明していきます。また、これらを見据えて実装したポイントについても解説します。
1. RAGの精度を向上させるための方法
精度向上に向けては、運用後に評価できる仕組みが必要になります。AWSのサービスアップデートやインプットデータ更新時の影響なども、数値的な根拠やユーザー利用状況を可視化できるような状態にしておくと、直感的な判断に頼ることなく、継続的な改善につながりやすくなります。
これを実現するために実施したことは以下です。
①評価用データセットの作成
開発段階で、数十個の質問と期待する回答のペアを準備しました。質問を準備する際に気を付けた観点は以下です。
- よくある質問（基本的なFAQ）
- 業務上重要な判断が必要となりうる質問（潜在顧客が気にかけそうな質問）
- エッジケースとなる複雑な質問
- 複数のドキュメントを参照する必要がある質問
これらの観点で作成した質問と回答を用いて、今回はRAGASという評価ツールを用いた定量的な精度測定を実施しました。現在は、Amazon Bedrock Knowledge Bases supports RAG evaluationというRAG評価機能もプレビューされているので、もっと簡単に評価することもできるかもしれませんが、私はRAGASの評価機能を用いて以下の数値的評価を実施しています。
- 回答の正確性：模範回答との一致度
- 関連性：回答の適切性
- 情報源の信頼性：参照ドキュメントの妥当性
なお、RAGASはJupyter Notebookが使用できるAmazon SageMakerのNotebook Instanceを用いて実装しています。これを利用して、明確な評価基準を設定することで、改修の妥当性が評価しやすくなりました。
②先進的なRAG手法の活用
何度も述べていますが、Bedrockを始めとしたAI系のサービスはアップデートが激しく行われています。その中の1つとして、Advanced RAGという回答精度を向上させる手法などもAWSから紹介されるようになりました。
とはいえ、周知の如く、必ずしもアップデートをすべて取り込めば精度があがるのかといえばそういう訳ではなく、システムにあった改修というのは実際に適用してみて試してみないと分からないものです。
また、ひとえにAI利用といっても、どの場面で活用するかの検討も事前に必要です。例えば、チャットボットで考えてみると、質問分析・情報検索・回答生成・インプットデータ整備…など、適用できる箇所が多くあります。そのことを踏まえ、実装段階からLLMを効果的に活用できるよう、多段階処理の実装にすることが望ましいかと考えられます。
もちろん、AWSでリリースされる新モデルは定期的に変更して利用していますが、ここでは実際にアップデートとして採用した2例を紹介します。
採用①：デフォルトチャンキングから階層型チャンキングへの変更
各チャンキング戦略については、以下を参考にしてください。
階層型チャンキングに変更したことで、設定するトークン数値によって異なるものの、大概はinputトークンが増えることによる料金増加もあります。今回は料金増加と天秤にかけたうえで、精度向上が見られたため採用しています。
採用②：ベクトル検索からハイブリッド検索への変更
質問に対する情報検索の箇所で、キーワード検索とベクトル検索のそれぞれの長所を組み合わせたハイブリッド検索に変更しました。定量的な大きな精度向上は見られなかったものの、回答生成スピードが改善されたうえ、ここだけは実際に作成される回答内容の記載のされ方という定性的な評価から採用を決めました。
③インプットデータの整形
上記で紹介した改善アプローチの他に実施した、インプットとするデータに対する施策をご紹介します。Advanced RAGで紹介されている、PDFの読み込みなどを改善するAdvanced parsingも非常に有用でしたが、ここでは自身で取り込んだインプットデータの整形例について紹介します。
人間でも人によって情報の捉え方は異なりますが、同様のことは生成AIでもいえて、インプットデータを処理する際には、もちろん揺らぎが発生します。回答品質管理という面で、プロンプトの工夫などといった生成AIの仕組み自体を改善すると同時に、いかに誤解を招かないような読み取らせ方をするのがよいかといった検討も重要でした。
ここでは、インプットとした問い合わせ応答履歴の知識ソースとするまでの仕組みの変更例をご紹介します。
改善前は、応答履歴に対してそのままマスク処理を実施するだけに留めていました。
そのため、多発するようなケースではなかったものの、応答の背景などを考慮した検索はできていませんでした。
そこで、下記のように、応答履歴からFAQのような形でインプットとするデータを再形成するようなLLMの仕組みを導入しました。仕組みといってもただ単に、QuestionとAnswerを一旦整理させるように指示を与えるLLMを挟んだのみです。
このようなインプットデータに変えたことで、応答履歴から参考にしたいデータが限定されるようになったため、余計な情報の引用や表示も減らすことができ、回答精度の改善が見られました。
2. RAGシステムの利用促進戦略
ここからは、RAGの回答精度改善とは少々離れて、利用促進に向けて実施した取り組みをご紹介します。
ボトムアップ的なアプローチのご紹介などにもなるので、技術要素は薄れます！
① 使いやすさ向上のためにUX改善
言わずもがな、ユーザーインターフェースの最適化は定常的に必要となります。
特に、AIシステムに関しては、機能ベースでまずは検討・リリースまでされることが多いと思いますので、直感的な操作性の実現・応答速度の最適化なども検討する必要があります。ちなみに、私は以下の本をよく参考にデザインしています。
② RAG回答精度以外の数値的指標の観測
定期的なユーザーインタビューを実施し、改善への要望の迅速な対応を常に実現できればよいですが、そうはいかない現場も多々あることでしょう。
そこで、QuickSightを用いて、主に以下の指標を見られるような環境を整備しています。
- 利用頻度
- 「回答できなかった」件数
特に初期段階では、上記の数値評価に加えて、実際のチャット履歴を確認し、開発者側の想定と実際に利用される質問内容のFit&Gapを埋めることが、ニーズを考えるにあたって必要となる過程でした。
これらから得られた情報をもとに、「ユーザートレーニングの実施」が必要なのか、または「小規模なパイロット部門での検証」に進んでよいのかの判断がつきやすくなります。
利用促進に繋がった取り組みとして、1つ挙げるのであれば、「成功事例と失敗事例の共有」になります。
簡単に説明すると、「うまく質問している人の問い合わせ方」と「回答が得られない人の問い合わせ方」を数例見えるところに表示したというものです。
イメージとしては、AWSのお問い合わせガイドラインに記載されている以下のような案内を記載するようにしました。
このように、こちらが期待するような問い合わせ文章に誘導することで、「回答できなかった件数」は減少させられました。
さいごに
いかがでしたでしょうか。今回はテックな話というより、実際にRAGシステムを運用してみてうまくいった例を中心にご紹介しました。
本文中でも触れましたが、手組で作成した機能の代替となるマネージドなサービスも数多く出てきているので、「楽な運用」にたおせるように評価しながら採用していきたいなと考えてます。