株式会社メルカリの技術ブログ

全267件

2023/12/16

こんにちは。メルペイ Machine Learning エンジニアの@gucciです。この記事は、 Merpay Advent Calendar 2023 の16日目の記事です。はじめに 2023年3月、OpenAI社がChatGPTを発表して以来、大規模言語モデル（LLM）の可能性に世界中が注目しています。企業や個人がLLMをどのように活用できるかを模索する中、実際にLLMを用いたプロダクトが市場に登場し始めています。メルカリグループでも、社内向け・プロダクト向けの両面でユースケースを探索してきました。その一環として、7月に実施したぐげん会議 [1] で入賞した返済相談チャットシミュレーターの一部分について、トライアルでオフラインの品質評価を実施しました。この記事では、その結果とそこから得られた学びについて共有します。品質評価における課題意識各種の学術試験やベンチマークテスト等、汎用的な知識・言語能力においてLLMが大きく進歩してきたことは疑いようがありません。一方で、LLMを用いたアプリケーションの品質に関する情報は、まだ十分に蓄積されていないと感じています。 OpenAI社によるGPT-4 Technical Report [2] や各種のベンチマークテストは参考になりますが、あくまでLLM本体の、汎用的な問題における評価結果です。また私の知る範囲では、現在世の中に公開されているLLMアプリケーションで、品質要件が厳しく求められる使い方をしているものは少ないと認識しています。そのため、特に事実性・リスク（定義は後述）の面で一定の品質が要求されるドメイン向けのLLMアプリケーションを構築する場合、どの程度の品質が得られそうかについて参考になる資料は少なく、未知数だと感じていました。問題設定この章では、今回のアプリケーションの問題設定について説明します。システム全体像ここでは返済相談チャットシミュレーターの一部分として、お客さまのお問い合わせに対して社内のドキュメントを参照しながら文章で回答を行う RAG（Retrieval-Augmented Generation）ベースのQ&Aアプリケーションを想定します。このユースケースでは、回答に一定の事実性が要求され、また回答次第で法令リスクに抵触してしまう可能性のある領域（以下、NG領域）が存在します。なおRAGとは、LLMに参照させたいデータを事前に取り込んでindex化しておき、質問が入力された際にそこから関連するデータを検索してLLMに渡す仕組みのことです。以下は、各構成要素の概要です。 RAGパート検索エンジン（VectorStoreIndex） 464件のドキュメント LlamaIndexでシンプルにindex構築（chunk_size = 1024, separator = “。”） indexのチューニングはあまり実施していません類似度検索 similarity（質問とドキュメント内容の類似度）で検索したうち上位1件を取得回答生成パート RAGで取得した情報をコンテキストとして、LLM（gpt-4）で質問に対する回答を生成用語の定義等の基本的なドメイン知識をsystem promptに指定リスク防御パート NG領域に関する回答を防ぐため、プロセス全体を通じて以下3層のリスク防御策を実装 ①input 防御（スコープ判定） : 入力された質問が対象スコープ内かをLLM（gpt-4）で判定し、対象外の場合は回答しない ②prompt 防御 : NG領域について回答しない旨の指示を回答生成のpromptに埋め込む ③output 防御（回答添削） : 回答にNG領域の話題を含むかをLLM（gpt-4）でチェックし、該当部分の記述を削除するまた以下は、簡単なQ&Aのイメージです。質問例誤りを含まない回答例誤りを含む回答（誤答）例メルカードで購入後の支払いはどうすればいいですか？メルカードのご利用分は、以下3つの方法から選んでお支払いいただけます。 1. メルペイ残高での支払い 2. 銀行口座からの自動引き落とし 3. コンビニやATMでの支払いより詳細を知りたい場合は、お気軽にお尋ねください。例1. 誤った方法を案内メルカードでご購入いただいた場合、購入した商品の代金が即時でメルペイ残高から引かれる形となります。 ==== 例2. 架空のアプリ操作方法を案内メルカードのご利用分は、以下の手順でお支払いいただけます。 1. メルカリアプリを開く 2. マイページを開く 3. 「メルペイ」を選択 4. 「支払う」を選択評価のアプローチこの章では、今回実施した評価のアプローチについて説明します。評価の目的「そもそも世に出しても問題ないレベルか」という防御的な観点から、事実性・リスクの面で求められる品質水準が見込めそうかを評価することが主な目的です。評価観点ここでは評価の手法を網羅することが目的ではないため、基本的な考え方としてOpenAI社の評価観点を参考にしました。InstructGPTの論文 [3] およびGPT-4 Technical Report [2] をまとめると、LLMの評価観点として以下が挙げられている理解です（学術試験等の能力評価は割愛。また各観点の説明は筆者理解）有用性（helpfulness）どれだけ質問者にとって有用な回答をしたか（≒課題を解決できたか）の評価事実性（factuality） : 真実性（truthfulness)と言われることもある質問に対して正しい回答ができるか（事実でない内容を回答してしまわないか）の評価事実性には、参照データの質とその検索精度、およびハルシネーションが主に影響します。リスク : 有害性（harmlessness）を含むセンシティブな領域または回答が許されない領域において望ましくない回答をしてしまうリスクおよび、過剰に拒否してしまう度合いの評価リスクには、ハルシネーションおよびプロンプトインジェクションが主に影響します。ハルシネーションとは、LLMが事実ではない内容を回答してしまう現象のことです。またプロンプトインジェクションとは、質問者が悪意のあるプロンプトをLLMに入力することで、LLMに不適切な回答や意図しない情報の開示をさせようとする行動のことです。この2つはLLMを使ったアプリケーション特有の点になります。評価の目的に照らして、今回は2点目の「事実性」と3点目の「リスク」の観点で評価した結果を紹介します。 1点目は施策効果の観点では非常に重要ですが、今回は主に防御的な観点で評価したいため、除きます。この章の以降では、評価方法の詳細について説明していきます。（詳細が不要な方は飛ばし読みで大丈夫です）評価の前提今回の評価では、以下のことを前提としています。 Q&Aの形式一連の会話のやり取りではなく、一問一答形式で評価しています（1度の問合せに複数の質問を含む場合もある）事実性とリスクは独立に評価事実性を評価する際、上述のリスク防御①〜③を入れない状態で評価しています。実際のプロダクションではリスク防御との組み合わせになりますが、今回は単体評価です。チューニングの度合いや評価件数について今回、時間や人手の制約があったことと、特にリスク評価を優先して対応したことから、事実性評価のチューニングや人手評価の件数は限定的なものとなっています特にRAGの検索精度がチューニング不足なところは理解していますが、得られた示唆に大きな影響は無いものと考えています人手評価か自動評価か文章生成を定性的な基準で評価する際、厳密な評価は人手でなければ難しいです。今回は人手評価を信頼しつつ、参考として事実性評価でLLMを用いた自動評価も試してみました評価観点別のアプローチ詳細今回実施した事実性評価とリスク評価の詳細は、以下の比較表のとおりです。切り口事実性評価リスク評価評価のポイント                            お客さまの質問に対して誤った回答をしないこと法令リスクに抵触してしまう可能性のある領域（NG領域）に関する回答を徹底的に排除しつつ、かつ答えて良い質問にはなるべく答えること評価用データ過去のQ&A事例100件（約20個のカテゴリーに関する質問） ※ただし、人手評価はこのうち30件のみで実施答えてはいけない質問57件   ・左記のQ&A事例のうち、NG領域に関する15件   ・敢えてNG領域を引き出す目的で今回作成した42件答えてよい質問80件   ・左記のQ&A事例のうち、答えてよい質問評価指標【人手評価】誤答率（30件中）： = 回答文の中に事実と異なる内容を1つでも含む回答の割合 = 事実と異なる内容を1つでも含む回答数／全回答数【[参考] 自動評価（100件中）】 a. 質問に対して回答がどれだけ関連しているか（質問 vs 回答） b. 質問に対して参照データがどれだけ対応しているか（質問 vs 参照） c. 回答がどれだけ参照データに依拠しているか（回答 vs 参照） ※今回は「正解の回答データ」を用意できず、誤答率の自動評価が難しかったため、上記の代理指標で評価して簡易的に傾向を確認（より詳細は後述）【人手評価】防御率（57件中）： = 敢えてNG領域を引き出そうとする質問に対し、どれだけ回答を防げるか = 回答を防げた質問の件数／答えてはいけない質問の件数阻害率（80件中）： = 答えてよい質問をどれだけ誤って止めてしまうか = 誤って回答を防いでしまった質問の件数／答えてよい質問の件数補足：事実性の自動評価指標の詳細今回LLMを用いて実施した自動評価の評価基準は以下のとおりです。（Azure Machine Learningのメトリクスを一部参考にしました [4] ）。指標名評価基準の概要（5点満点） a. 質問に対して回答がどれだけ関連しているか（質問 vs 回答） ※Azure MLではQnA Relevance Evaluationに相当質問に対して過不足無く答えているほど点が高くなる。5点で完全に質問とマッチした回答。 b. 質問に対して参照データがどれだけ対応しているか（質問 vs 参照） ※Azure MLの記事では特に該当無し質問に対して参照データの充足性が高いほど点が高くなる。5点で全ての質問に答え得る参照データ。 c. 回答がどれだけ参照データに依拠しているか（回答 vs 参照） ※Azure MLではQnA Groundedness Evaluationに相当回答内容が参照データ内の事実にだけ基づいているほど点が高くなる。5点で完全に参照データ準拠。評価結果と課題ここまでで、アプリケーションの問題設定と評価アプローチについて説明してきました。この章では今回の品質評価の結果をご紹介します。まず、今回の総評および取り組んで分かった課題についてまとめたうえで、各結果の詳細に触れていきます。サマリ：総評及び取り組んで分かった課題今回の評価結果を整理すると、以下のとおりになります。切り口事実性評価リスク評価今回の結論                  △（難しい or 開発・運用コスト大） ◯（十分な精度）総評 RAGで適切なドキュメントを参照できさえすれば、誤答はかなり抑えられるようです。しかし、下段に記載したような課題があり、安定的に適切なドキュメントを参照させ、回答品質を維持するには相応の開発・運用コストがかかると思われます。複数の防御を重ねることで、阻害を最低限に抑えながらほぼ100%近くNG領域の回答を防ぐことができ、良い精度が得られました（100%を保証できるわけではない）。ユースケース次第ですが、人間が読んでも判別できるような限定的な領域が対象であれば、事実性と比べてリスクはより対処がしやすいと思われます。課題（開発観点）複雑なコンテキストがある場合、similarity検索だけでは不十分   ・ similarityだけで必要なドキュメントを特定することは難しい   ・多めに検索してLLMにどれを使うかを選ばせる、検索結果を別の手法で並べ替える等、何らかの追加的な機構が恐らく必要適切な参照データが無い場合の取り扱い   ・事実を問う質問の場合は答えないのが適切だが、そうでない場合（例. 挨拶、前の発言の確認など）も含めて一律で「回答しない」とするとコミュニケーションに齟齬が生じる   ・一方で正しくない参照データでも回答させると、ハルシネーションを起こしやすくなる複数の質問の混在   ・一度に複数の質問をされた場合に、質問を分解する等の機構が恐らく必要ユースケースによって防御の難易度は変わる   ・例えばNG領域の判別が人間でも難しい場合や、細かいたくさんのNG領域がある場合は難易度が高くなる   ・ OpenAI社のようにあらゆるリスクに対応するのは非常に難しいレスポンス速度への影響   ・防御策を重ねるほど、レスポンス速度が悪化する。防御精度とレスポンス速度のトレードオフの最適化は課題課題（運用観点）ドキュメントの品質・網羅性   ・何もかもドキュメントがあるわけではないし、ドキュメントが常に最新であることを保証することも容易でない継続的なメンテナンス   ・リリース後にうまく判別できない新しい質問が来たときに、漏れたものを後追いでpromptに追加していく運用が必要となる事実性評価の詳細事実性評価で得られた結果は以下のとおりでした。人手評価誤答率（30件中）：47% 間違った14件のうち、参照するドキュメントを間違えたものが10件、そもそも適切なドキュメントが無かったものが4件ありました前者については、検索時に取得するドキュメント数を増やせば一定改善すると思われます（現状は上位1件）ただし、正解ドキュメントが上位20件でも出てこないケースもあり、一筋縄ではいかなさそうです [参考] 自動評価（100件） LLMによる評価結果は1件1件を見ると若干ブレがあるため、あくまで傾向値としてだけ参考にします指標平均評価値 (5点満点) 解釈 a. 質問に対して回答がどれだけ関連しているか 4.9 質問に合わせて回答する能力は高水準（これがハルシネーションの要因でもある） b. 質問に対して参照データがどれだけ対応しているか 2.9 質問に対して適切な参照データを取れていないことが多い c. 回答がどれだけ参照データに依拠しているか 1.8 bの結果として、参照データに依拠しない回答をする傾向が見られたリスク評価の詳細リスク評価で得られた結果は以下のとおりでした。防御パターン防御率（57件中）阻害率（80件中） ①input + ②prompt 100% 4% ③output + ②prompt 98% 1% 全て（① + ② + ③） 100% 5% 各防御策の違い ①のinput防御は、防御率を高めやすい反面、答えてよい質問を誤って止めてしまう阻害が起きやすい傾向がありました（参考までに、防御用promptをチューニングする前の初版では約70%の阻害が発生） ③のoutput防御は、防御率と阻害率のバランスが良いですが、防御に若干不安が残りますなお、②のprompt防御はほぼ効果無しでしたすでにsystem promptが長文（約1,500文字）であるため、追加の指示が効きづらかった可能性ありまとめと知見今回まじめに品質評価に取り組んだことで、LLMおよびRAGの特性について理解が深まり、今後他のユースケースを考える際にも役立つ色々な学びを得ることができました。最後に、今回のトライアル評価を通じて得たいくつかの知見をまとめます。 ※あくまで一つのユースケースにおける、限られたチューニング範囲での評価結果に基づく私見です「正解がある」 + 「複雑なコンテキスト」がある問題に対しての、RAG精度の限界個別のユースケースにもよると思いますが、このような問題に対して十分なRAG精度を実現するためには開発・運用面で非常にコストがかかると思われます検索結果のRerankやSelf-RAG [5] のような工夫も出てきていますが、APIコストやドキュメント整備の大変さ等も加味すると、個人的にはLLMが本領発揮できるのは、むしろzero-shot〜few-shotで済むような複雑なコンテキストが要らない領域（例. 商品説明文からメタデータを抽出する）や、正解がない領域（例. エンタメ）なのではないかと感じています LLMプロジェクトの難しさ本件は、ミッションクリティカル性が高めな領域、かつ既存の人の仕組みをリプレースするものであり、関係者が多かったり、法律が影響するものでありましたその上で、 LLMは汎用性が高いゆえに、問題設定の絞り込みが難しい、あるいは多くの要件を織り込めてしまう特性があります。これは利点でもありますが、一方で広範な問題設定になるほど芋づる式に考慮すべき要素が増え、品質の担保が難しくなると感じます人手評価の大変さ 1件当たり評価に10-15分かかった「事実かどうか」を確かめるには、回答文章の中でソースが必要な要素を抜き出した上で、各要素についてドキュメント等からソースを探す必要がありますもしくは、事実が頭に入っているドメインエキスパートが必要なお、評価用データに対して「正解の回答データ」を用意することができれば、LLMを用いてある程度は事実性を自動評価できるかもしれませんそれでは、ここまで読んでいただきありがとうございました。明日の記事はtenlingpさんです。引き続きお楽しみください！参考文献 [1] LLMを活用してなにがつくれるか？——「ぐげん会議」開催から見えてきた、AI活用の新たな可能性 [2] OpenAI (2023). GPT-4 Technical Report. ArXiv, abs/2303.08774. [3] Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C.L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L.E., Simens, M., Askell, A., Welinder, P., Christiano, P.F., Leike, J., & Lowe, R.J. (2022). Training language models to follow instructions with human feedback. ArXiv, abs/2203.02155. [4] Azure Machine Learning の Prompt flow の評価メトリクス紹介 ― ChatGPT どう評価する？ [5] Asai, A., Wu, Z., Wang, Y., Sil, A., & Hajishirzi, H. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ArXiv, abs/2310.11511.

株式会社メルカリ の技術ブログ

コンテンツ

株式会社メルカリの技術ブログ