[登壇レポート]「生成AI時代の必須スキル!RAGの回答精度向上のコツ全部教えます」で登壇しました
新規事業部 生成AIチームの山本です。
2024/04/24にオンラインで開催した弊社セミナー「生成AI時代の必須スキル!RAGの回答精度向上のコツ全部教えます」にて登壇をしましたので、自分の発表資料を共有いたします。
資料
資料に関する補足
- 今回は、RAGを始めたい方や始めてすぐな方に向けて登壇を行いました
- メインの内容は、1~73ページです。
- また補足として、既にRAGを導入し進めている方向けに、補足情報を74ページ以降に記載しました。
Q&A
以下、いただいた質問と、差し上げた回答の内容です。山本がメインで回答していますが、一部は(同じく登壇した)熊谷が回答しました。一部、本記事の記載に伴い補足を追加しました。
Q: LLMとragを活用し、毎日の1000人規模全社のeメール(参考ドキュメント)から、トラブルや不正予兆のあるメールを抽出することはできますか。なお、教師データ(メール)は十分あります。
A: トラブルや不正予兆の特徴をもつキーワードや文章の傾向が分かれば、該当メールを抽出することは可能です。弊社では、同じ原理で、問い合わせの内容に応じて担当部署の割り振りを行っている実績がございます。
Q: 一般的な質問か、社内文書の質問か?の判断精度をあげる方法があれば教えてください。
A: 質問する前に、ユーザー自身で一般か文書かどっちの質問か明示させるのが現実的な方法になります。AIに判断させるときに精度を100%担保するのが厳しいのが現状です。
※ 補足:(精度が100%である必要がなければ)生成AIに判断させることも可能です。前処理として、プロンプトを用いてLLMに判断させる、ということが可能かと思われます。
Q: Amazon KendraはGoogle Cloudだと何のサービスに該当しますか?Google Cloudで構築したいので対応するGoogle サービスあれば教えてください。
A: GCPだと、Vertex AI Search が相当します。但し、Kendraと機能が完全互換ではないので、Vertex AI Searchで実装するときは機能の補完が必要になります。
※ 補足:基本的な検索機能は(もちろん)Vertex AI Searchでも対応可能ですので、Google Cloud上で構築可能です。
Q: 検索エンジンの精度がボトルネックになりうると考えていますが、Kendraの精度について気になる点はないでしょうか?「日本語だと弱い」「専門用語に弱い」など、使用感を教えていただければ幸いです。
A: お考えの通り、検索エンジンの検索精度は、回答品質を高めるうえで重要です。ただ、Kendraの検索精度が、日本語だと弱かったり、専門用語に弱い、という印象はあまりありません。むしろ、専門用語で検索しても目的のドキュメントがヒットしたり、検索クエリの内容に近いドキュメントが取り出せれやすい印象です。
Q: RAGでは検索結果でヒットした周辺のテキストのみを参照し、参考ドキュメント全体を参照するものではないと理解しています。この点で回答精度には限界があるのではないかと考えていますが、実際に活用されてみた印象をお伺いしたいです。
A: ご理解の通り、ベーシックな方法では、検索結果でヒットした周辺(チャンク = ドキュメントを分割した一部)を回答に使用します。このような方法では、回答できる内容に限界があるという認識で合っているかと思います(ドキュメントをすべて読まないと回答できない質問、のようなケースに対応できない)。この方法を改良し、検索でヒットしたドキュメント全体を取り出して、読み込ませるという方法も採用されるケースがあり、上記のような質問に対応できるようにしています(ただし、入力トークンが増えてコストが上がってしまう、というトレードオフがあります)山本が試してみた例ですと、こちらの記事をご覧いただければと思います。
Q: スクラッチRAGとSaaSの使い分けとしての判断基準をどのように持つべきと考えているでしょうか。
A: 取り急ぎ思いつくところですが、
- データの対応形式の制限
-
読み込ませるファイル数の制限
-
運用の制限(更新頻度が選べない、自分たちでできない)
-
チューニングの制限
これらの要件によって判断するのがよろしいかと存じます。
Q: ドキュメントごと(コンテンツ内容、ページ跨ぎ問題など)の特徴があるのでなかなか精度が向上しない場合どのような対処が必要と考えているでしょうか。
A: ページ跨ぎに関しては、今回の資料の補足の89ページのような手法が利用できるかと思います。Claude3やGPT4では、複数の画像を渡して読み込ませることができます。ページをまたいで文字起こしすることができている様子が見て取れるかと思います。「コンテンツ内容」だけだと、少し状況がわかりかねるため、正確な回答でないかもしれませんが、コンテンツの内容・特徴に応じて、適切な方法を選択する、という考え方になると思います。個別の話になってしまうため、一概な回答が難しいです、申し訳ございません。
Q: 役に立った・なかったのログを保存する、おすすめのインフラの環境はありますか?
A: 会話や回答に対する評価を保存することになるので、会話IDや回答IDと対応付けて保存できる、キーバリューストアが適していると思います。AWSではDynamoDBが良いかと思います。こちらのサンプルリポジトリでもDynamoDBに会話履歴や評価を保存する構成がとられています。
https://github.com/aws-samples/generative-ai-use-cases-jp/blob/main/imgs/arch.drawio.png
Q: 証明書認証を使ったシャドーIT対策がされている、社内文書参照AIサービスを探しています。この機能は今回紹介されたサービーに入っておりますでしょうか?
A: 弊社が提供しているサービスの中には、シングルサインオンによって既存の認証情報でログインして利用させる社内文書参照AIサービスもございますので、シャドーIT対策は可能です。
Q: パワポなど画像や表が含まれている資料のベクトル化に苦戦しています。こういった問題に対処した例があれば教えてください。
A: 今回の資料の58~63ページでご説明したように、マルチモーダルなモデルで、一度文字起こしを行うと良いかと思います。テキストファイルに変換しベクトル化することで、他のファイルと同様に検索にかけられる状態にできるかと思います。詳細は以下の記事をご覧いただければ幸いです
https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3/
https://dev.classmethod.jp/articles/read-powerpoint-document-with-claude-3-on-lambda-funcion/
https://dev.classmethod.jp/articles/simple-examination-on-recognizable-char-size-with-claude-3/
Q: 検索精度と回答品質は、どちらの比重が大きいと感じられるでしょうか?
A: 検索精度の方が、比重が大きい、つまり、良い回答を得て業務を効率化するための効果が大きいと感じています。データ周りの改善 > 検索周りの改善 > 回答生成周りの改善 の順で大きいという印象です。違う言い方をすると、以下のような考えです
- 多くのミスの原因は、データが足りない・読み込まれ方が意図しない形になっている・検索の取り出せれ方が意図しない形であること
-
データが揃いうまく検索できている状態であれば、回答生成でおかしな出力がされることは少ない
Q: LLMにRAGに使用する検索クエリを作るフェーズは単にGPT等に考えさせるのでしょうか?
A: おっしゃるとおり、(GPTを始めとした)LLMに検索クエリを考えさせます。入力としては、会話履歴と質問を加えたプロンプトを使用します。プロンプトのテンプレートや、処理の方法については、こちらが参考になるかと思います
Q: CSVを分けるというお話がありましたが、分けたCSVをそれぞれチャンク切りしてベクトル化するのでしょうか?それとも1チャンクにヘッダー込みのデータが入るから精度が上がるというロジックでしょうか?
A: ロジックとしては、1つのチャンクの中に、ヘッダと各行の内容が入るため、誤解がないように回答生成のLLMにわたすことができ、回答ができるようになる、という意図でした
Q: RAGにおけるユーザの権限に応じたアクセス制御をどうするか悩んでいます。たとえばOnedriveなどの元ファイルではマネージャーのみ見れるアクセス制御ができますが、RAGでもその権限を継承したいです。
A: 方法としては、エンタープライズ検索のアクセス制御機能を使うことが挙げられます。KendraとSharePointの接続の例ですが、ユーザに応じて、SharePointの閲覧権限と同様に、検索時の対象を制限することができます。
https://dev.classmethod.jp/articles/kendra-sharepoint-usercontextfilter/
概要としては、以下のとおりです
- KendraとEntraIDを連携するように設定しておく
-
ユーザがEntraIDで認証を行い、認証されたユーザのトークンをKendraにわたす
-
KendraがEntraIDを使って検証を行い、ユーザの権限に応じた検索を行う
KendraとOneDriveの場合ですが、以下のページに該当機能である、User Context Filteringに対応している旨が記載されているので、同様の方式が可能かと思います。
https://docs.aws.amazon.com/ja_jp/kendra/latest/dg/data-source-onedrive.html
Q: マルチモーダルでClaude3等を使ったとして、仮に複雑な分岐のあるフロー図等についても正常にデータ化できますか?
A: おっしゃるとおり、難しいポイントかと思います。まず、複雑な図をデータ化(文字起こし)できるか、ですが、まだ難しいかな、というのが正直なところです。項目が数個(~10個)のような簡単なフロー図であれば、Mermaid形式に起こさせることはできていますが、それ以上となると難しい印象です(ただ、まだプロンプトの指示を改良することにより、より適切な文字起こしが可能な余地はあると思っています)
また、前後関係や文脈に応じて、文字起こしさせるべき観点も異なる、というのもおっしゃるとおりかと思います。そういった点への対応は、現状のレベルだと難しいと判断するのも、一つの選択肢かと思います。暫定的な対処としては、場所を答えさせ、図に関してはユーザに読んでもらう(「このページに、処理フロー図が書いてあるから、そこを見てね」と答えさせる)というのが良いかと思います
Q: パワポや画像をについてClaude3で文字起こししている説明がありましたが、Kendraで外部データソースを検索させる場合、前処理はどのように実施するのが良いのでしょうか?
A: KendraのCustom Document Enrichmentという機能を使用するとよいかと思います。これは、ドキュメントを読み込む際の前処理を、途中に挟むための設定が可能な機能です。Lambda関数にClaude3を呼び出す処理を実装し、Custom Document Enrichmentから呼び出すように設定する、という形で実施できるかと思います
https://docs.aws.amazon.com/kendra/latest/dg/custom-document-enrichment.html
Q: 欲しい情報が別ファイルに散らばっていて、それぞれのファイルが参考文献として参照している場合(参考文献として記載など)、そのままでは情報を抽出することは難しく、プロンプトや検索システムの工夫が必要ですか?改善アイディアのイメージがありましたら、共有いただけると嬉しいです。
A: おっしゃるとおり、検索でヒットしたドキュメントが、別のドキュメントを参照していて、そこに必要な情報が書かれている、というケースは多いです。ベーシックな方法だと、こういったケースでは、生成される回答が不十分なるため、工夫が必要になります。一つの解決策としては、メタデータを使い、後処理で抽出範囲を拡大する方法が考えられます。あらかじめ、参照関係を分析して「参照ドキュメント」の属性をメタデータに埋め込み、ヒットしたドキュメントのドキュメントを別途取り出すという処理を追加する、という方法です。もっと高度な解決策としては、Agent(のような)機構を入れる方法です。Toolとして、検索・抽出を渡し、必要に応じて自動で実行させます。ただし、制御や分析が難しいので、使用する際は少し難易度が高いかもしれません
https://dev.classmethod.jp/articles/revise-retrieval-augmented-generation/#toc-6
Q: P66はRAGではなくLLMに学習させるのでしょうか?
A: LLMを学習させているのではなく、LLMを使い用語を抽出させるタスクを実行しています
Q: 人間が読める資料をAIが読み込める形にするアノテーション技術についてクラスメソッド様ではどのような対応をされてますでしょうか?
A: アノテーションという言葉の指すところがわかりかねているのですが、マルチモーダルなモデルにOCR AIと組み合わせた例がありますので、こちらが参考になれば幸いです
Q: RAGに投入するデータの精査を進めています。材料は多いですが書き方が異なったり抜け漏れなどで、整備に時間がかかっています。データ整備のコツやおすすめのツールなどありますでしょうか。
A: おっしゃるとおり、苦労する点かと思います。なかなか書かれ方や形式が異なっていたり、情報の抜け漏れをチェックするのは難しいです。根本的に難しい問題で、あまり、コツやツールなどの情報の持ち合わせがありません、申し訳ありません。
以下は、現状でのアイディアレベルです、ご参考になれば幸いです。書かれ方や形式に関して、もし目標とする統一的な書き方があるならば、ドキュメントと書き方の指示をLLMにわたし、ドキュメントを書き直させることが可能かもしれません。抜け漏れに関しては、フィードバックを行いながら、改善していくというのが考えられます。ユーザが「役に立たなかった」回答を集め、ドキュメントの情報不足に起因してる箇所を抽出し、担当者に修正するように依頼する、という仕組みです。弊社内での検証でも、バックオフィスを業務に関するドキュメントを参照させている中で、不足情報があるということがあり、総務メンバーに依頼してアップデートしていただくことがありました。また、逆に総務メンバーからは、フィードバックを自分たちでみて、改善を行っていきたい、という意見もありました。こうした担当者の方も巻き込んでみる、というのが一つ方法かもしれません
Q: 社内用語集を回答に活用するイメージが湧かないのですが、どのように活用するイメージでしょうか?
A: 以下のような方式をイメージしています ・あらかじめ用語集を作成する ・質問に含まれる社内用語を取り出す ・用語集から該当する説明を取り出す ・用語と関連ドキュメントを質問とともにLLMに渡し、回答を生成させる
Q: 複数のHTMLファイルをRAGの参照先にしたいのですが、タグ等がゴミデータになってしまうと思います。このあたりの前処理の解決策を教えていただきたいです。
A: HTML用のパーサを使い、本文部分のみを抽出すると良いかと思います 自分で処理を実装したい場合は、PythonのBeautifulSoupライブラリが使えるかと思います また、LlamaIndexですと以下のようなHTML用のローダがあるようです。使用したことはないのですが、おそらくお抱えの問題を解決できるのでは、と思います
https://dev.classmethod.jp/articles/python-parse-html/#toc-3
https://docs.llamaindex.ai/en/stable/examples/data_connectors/WebPageDemo/
https://docs.llamaindex.ai/en/stable/api_reference/node_parsers/html/
Q: 単語しか書いていない質問に回答できるようにするにはどのような改善案があるのでしょうか?
A: 社内検証やお客様との取り組みでは、システム側で解決するよりも、ユーザに使い方をアナウンスして、質問のように入力してもらう、という形で解決しました
Q: 社内用語の用語集を作ったとしても、その情報をそのままベクトルDBに入れたとしても意味がないと思います。どのようにAIに用語集を認識・把握させるのでしょうか?
A: 質問22の回答をご覧ください。そのままベクトルDBいれるのではなく、辞書形式のデータベースや検索処理を利用することになるかと思います。
Q: LangChainを利用したRAGシステムを以前開発したことがあるのですが、その際数百ファイルを取り込んだ際に、検索精度が悪化したことがあります。BedrockのKnowledge baseでは、上記の様なドキュメント数の増加に伴う精度の低下はございましたか?
A: Knowledge baseで、数役のファイルを試したことがなく、正確な回答が難しいです、申し訳ございません。原理的な話をすると、ファイル数が増加すると検索精度は落ちます。十分な精度を保てるファイル数がどれくらいかは、現状情報を持ち合わせておりません。
Q: RAGASで精度評価をしようと考えているのですが、注意点や他にお勧めの方法があればご教示頂けますか。
A: RAGそのものの評価としては、良い選択肢かと思います。ただ、強いてあげるとすれば、今回のお伝えしたテーマでもあるように、体験全体やプロジェクト全体としての評価は、別途行う必要があるかと思いますので、この点はご注意いただけると良いと思います
Q: 海外リージョンのLLMを使用する場合、AWSのBedrockを使用すれば、特段、日本の輸出規制に該当しない(該非判定)の必要は無いという認識で良いでしょうか??
A: ご認識のとおり、Amazon Bedrock は、プロンプトと継続を使用して AWS モデルのトレーニングやサードパーティーへの配布を行いませんとポリシーが明記されています。(https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/data-protection.html)
また、Bedrock内のLLMには日本リージョンで提供されているものもございますので、そちらのご利用もご検討ください。
Q: 海外リージョンのLLMを使用する場合、AWSのBedrockを使用すれば、特段、日本の輸出規制に該当しない(該非判定の必要は無い)という認識で良いでしょうか??
A: ご認識のとおり、Amazon Bedrock は、プロンプトと継続を使用して AWS モデルのトレーニングやサードパーティーへの配布を行いませんとポリシーが明記されています。(https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/data-protection.html)
また、Bedrock内のLLMには日本リージョンで提供されているものもございますので、そちらのご利用もご検討ください。
Q: ユーザからの検索クエリを変換(Query Transformation)することで、精度向上されたというお話を聞いたことがありますが、御社でも検証されたことはございますか?
A: 社内の検証ボットで該当機能を使用しています。""精度""という評価はしたことはありませんが、検索クエリを見てみると、ユーザの質問が抽象的な場合でも、適切なクエリに変換にされています。また、会話履歴を持たせてやり取りを続けられるようにする場合、こうしたクエリの変換はほぼ必須です、例えば「それについて詳しく」や「2つ目の内容をおしえて」のように、指示語が入るケースがあります。これをそのまま検索してもほしいドキュメントがヒットしないため、LLMにクエリを考えさせる(「それ」を変換する)必要があります。
Q: 情報のソースへのリンクが表示されるとのことですが、フリー版chatGPTではわりとリンク先にそのような情報がないことがあります。これは学習の精度のようなものが違うのでしょうか?
A: 情報ソースへのリンクは、LLMに出力させているのではなく、別処理で加えています。LLMには参考とした文章の番号を出力するようにプロンプトで指示をしておき、後処理で出力したテキストをパースして、使用された番号のドキュメントのリンクを別途出力しています。(学習によるものではありません)
Q: この導入パックはCloudFormationではできないのでしょうか?
A: 本導入パックはCDKで書かれているので、CloudFormation経由でデプロイいたします。 CloudFormationのテンプレートそのものが必要という場合は、ご相談ください。
Q: Azure OpenAI Service(+その他のAzureサービス)を用いてRAGアプリケーションを開発しようとしていますが、Advanced RAGへの発展に向けたコンサルテーションや開発支援といったご相談は可能なのでしょうか?
A: 可能です。コンサルも開発支援も両方承っておりますので、ぜひご相談ください。
Q: RAGの仕組みを考えると、前段階の文書検索の精度を上げづらい(ある程度慣れている人が検索キーワードを考えても、適切な情報が見つからない)状況においては、RAGにおいても精度は上がりづらいのかなと思っていますが、その点について何か知見はありますか?
A: おっしゃるとおり、検索での精度が上がらないと、全体としての効果(回答の品質向上や、業務効率化)には結びつきにくいです。
Q: マルチモーダルに資料を文章化するときのプロンプトを教えてください。
A: こちらの記事をご覧ください
Q: fine-turningを簡単に実施してみたのですが、RAGよりも精度が低い結果になりました。精度の高いfine-turningを実施するには、多量の形式が揃ったデータが必要なのでしょうか?
A: P15・16のスライドでお伝えしたとおり、fine-tuningで知識を覚えさせ、回答を行わせるのは難しい印象です。 形式としても、どういった形式であれば良いのか(Q&Aのようなクイズ形式か・文章のような形式か)、どれくらいの量を用意すれば良いのかといったところが難しく、世の中にもあまり情報がない印象です。自分でも試してみたことがあるのですが、やはり難しかったです。そのため、ご質問いただいた内容にお答えするのが難しいです、申し訳ございません。
Q: 構築210万、運用が月10万ということですが、運用の10万というのはどのようなサポートをしていただけるのでしょうか?
A: 利用ライブラリなどに対するセキュリティの維持、APIの仕様変更に対する対応、プログラムに問題が発生した際の修正、問い合わせ対応などを行います。 RAG品質改善は作業工数・難易度によっては、別途お見積もりになる場合がございます。
Q: 会話履歴も参考に回答を生成する仕組みを作る場合、Kndora検索クエリをLLMに作成する際に会話履歴も参照させるほうが良いのか、回答生成時に会話履歴でさんしょうするほうが良いのか、ご教授ください。参考となるプロンプトもあればお願いします。
A: 検索クエリを作成するLLMと、回答生成するLLMのどちらにも会話履歴を含める必要があります 検索クエリを作成するプロンプトとしては、こちらが参考になるかと思います
回答生成するプロンプトはこちらです。補足すると、このプロンプトはシステムプロンプトで、それ以降に会話履歴をmessages(user・assisitantからのメッセージ)として含める、という形で使用します
Q: Llama3に対する評価や取り組み、適所、対応についてどのようにお考えかお聞かせください。
A: 漠然とした回答となりますが、オープンソースとして利用でき、自社で学習やチューニングできる点が良いかと思います。自社や業界用のことを理解したLLMを作成する際には利用できそうです。
Q: 文書をベクトル化して検索するパターンと、文書を形態素解析してベクトル化して検索したパターンの精度の違いについて知見があれば教えてください。
A: 両者の違いがわかりかねているのですが、ベクトル化の前に区切り方を工夫する(一定文字数ではなく、章ごとや見出しごとに区切る)前処理を挟む方が、取り出せるチャンクの意味が崩れにくく、回答が良くなるケースが多いです。
補足
セミナーのイベントページはこちらです