こんにちは。AWS CLIが好きな福島です。
はじめに
前回のブログでは、RAGシステムの必要性やアーキテクチャの要素の考慮事項について私の考えを書いてみましたが、 今回はRAGシステムを実装する上で必要な機能について、私の考えを書いてみます。
重要度ごとに書いていますが、実際の要件によって重要度は変わると考えておりますので、 重要度は参考程度にしていただければ幸いです。
重要度: ★★★
ストリーミング出力機能
まずは、ストリーミング出力機能になります。
これはChatGPTなどを使っていると想像が付くかと思いますが、文字が断続的に表示される機能のことを指しています。
RAGシステムでは、LLMが回答を生成するまでに少し時間がかかるため、 全ての回答が生成されてから表示されるのは、待ち時間が長くなり、ユーザーにとってもストレスになります。
そのストレスを緩和するためにこのストリーミング出力機能は非常に重要な機能であると考えております。
少し文字だけだと寂しいので、ストリーミングのイメージ動画を載せておきます。
- 補足
このストリーミング出力機能は非常に重要な機能であるものの、 フロントとバックエンドを分離する構成では、実装が中々難しいと感じます。
実装の詳細については、また別のブログにでまとめたいと思います。
参考URLの表示
続いて参考URLの表示になります。
まず前提として、LLMはハルシネーションと言い、間違った回答を生成することがあります。 そのため、LLMの回答は参考程度にとどめ、一次ソースを確認するのが重要と考えております。
そこで一次ソースの参考URLを表示する機能が必要になります。
またここで重要になるのが検索システム(ベクターストアなど)には一次ソースのURLを保持しておくことです。
例えば、Knowledge base for Amazon Bedrock(以降、Knowledge base)を利用する場合、 一次ソースのデータをAmazon S3にアップロードする必要があります。
そのため、Knowledge baseは一次ソースのURLの情報を把握していなく、S3のパスしか情報を保持していません。 また、S3のパスにアクセスできるのは基本的にAWSアカウントへのアクセス権があるユーザーだけになるため、 基本的にはRAGシステムの利用者は回答の参考になったデータを確認することができません。
これを防ぐために検索システム(ベクターストアなど)には一次ソースのURLを保持しておくことが重要です。
- 補足
参考URLを表示するのが難しい場合は、代替案として、 一次ソースのURLではなく、LLMが回答の参考にしたチャンクを表示させる方法が考えられます。
ただし、この際にチャンクの量が多いと、利用者は見づらいと感じる可能性があるため、 UIの設計を合わせて考える必要があると思います。
会話履歴を踏まえたやりとり
次に会話履歴を踏まえたやりとりができる機能になります。 以下にイメージを載せておりますが、はじめに都道府県を1つ教えてと質問した後にそれ以外は？と質問した際に正しく過去のやりとりを理解して回答を生成していることが分かります。
ChatGPTなどを使っていると会話履歴を踏まえてやりとりができるのは当たり前に感じますが、 LLMを使ったシステムを実装する上では、この点を考慮する必要があります。
具体的には、LLMは過去のやりとりを覚えている訳ではないため、 ユーザーとLLMの会話履歴をデータベースなどに保持しておき、ユーザーからの質問があった場合、 会話履歴を踏まえてLLMに回答してもらうように実装します。
もしこの機能がなかった場合、ユーザーは質問の度に背景を伝える必要となり 利便性が下がると思うため、この機能も重要と考えます。
文章検索機能
RAGはLLMが知らないことを回答させるためにユーザーの質問に合わせ、検索システムから参考情報を検索します。
例えば、ユーザーがRAGシステムに質問をした際に正しい回答が得られなかった場合、 そもそも、検索システムに必要なデータが保持されているのか、もしくはLLMの回答が悪かったのか、 調査したくなるケースがあると考えます。
もちろん、システム管理者に問い合わせして管理者が調査することも可能ですが、 ユーザー側で確認できる範囲を増やすことで運用負荷の軽減やRAGシステムの活用を推進できると考えます。
フィードバック機能
RAGシステムは精度を評価したくなるかと思います。
しかし、ユーザーが質問した際に正しい検索結果を取得できているのか、 LLMが正しい回答を生成できているのかなどを確認する必要があり大変です。
この評価を自動化する仕組みもあるようですが、 (私が知らないだけかもしれませんが)その仕組みを実装するのは中々大変と感じます。
ただRAGの評価をしたいと考えた際に手軽にできるのが、フィードバック機能と考えています。 これはユーザーの協力も必要になりますが、比較的簡単に評価できるのでは？と考えます。
ログの取得
RAGシステムを改善するためにもログの取得は大切かと思います。
ユーザーがどういう質問をしたか、LLMによって会話履歴を踏まえた質問がどのように言い換えられたか、 どういうデータを検索システムから取得したか、LLMがどういう回答をしたかなどのログを取得することで 改善に活かすことができるかと思います。
私自身、実際にログを基に改善するところまではできていないのですが、そもそも改善するためにこういったデータがなければ何もできないため、 まずはログを取得することが大切かと思います。
参考ドキュメントごとの権限制御(要件に応じて)
上述した通り、RAGはLLMが知らないことを回答させるためにユーザーの質問に合わせ、検索システムから参考情報を検索します。
この検索の際に、ユーザーごとに閲覧できるドキュメントが違うケースもあります。 その場合、どのようにドキュメントの権限分離をするか検討する必要があります。
重要度: ★★
過去の会話履歴の表示
過去の会話履歴の表示です。
直近の会話履歴の表示は必要と考えておりますが、 個人的には、過去の会話履歴について振り返ることはないため、 この機能はそこまで重要ではないと感じ、重要度を1つ下げました。
重要度: ★
モデルの切替/パラメーターの変更/プロンプトの変更機能
このような機能は、RAGシステムを評価するためにシステム管理者にとっては必要と考えますが、 利用者にとっては利用する上での判断を増やすことになるため、特に不要なのかなと考え、重要度を1つにしました。
もちろん、このような機能が欲しい利用者が多い場合は、実装するべきだと考えます。
終わり
今回は私が考えるRAGシステムに必要な機能について、重要度別に書いてみました。 どなたかのお役に立てれば幸いです。
福島 和弥 (記事一覧)
2019/10 入社
AWS CLIが好きです。
AWS資格12冠。2023 Japan AWS Partner Ambassador/APN ALL AWS Certifications Engineer。
