Amazon Bedrockで行うモデル評価入門 / Introduction to Model Evaluation in Amazon Bedrock

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 ● r-kagaya(@ry0_kaga) ● 株式会社ログラス ● 生成AI/LLMアプリケーションエンジニア ● 最近の趣味・興味 ○ ダーツ(SaaSカップとか開催したい) ○ AIエージェント(特に音声絡む) 2022年に株式会社ログラスに入社マスタ管理機能等の開発、開発生産性向上に取り組んだのち、生成AI/LLMチームを立ち上げ自己紹介

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 ©2024 Loglass Inc. 品質保証‧評価の難しさ常に同じ予測可能な結果が得られるとは限らない出力を変化させうる変数が多い。Agenticなフローを組んだらさらに大変確率的パラメーター次第でも変動評価指標の定義がケースバイケース一つの正解がない可能性。複数のパターン・要素・観点がある完全一致の検証が必ずしもできるわけではない「唯一絶対の正解」がないことも等式アサーションの限界(UT) 一般的な項目はあれど、より具体はアプリケーション・ユースケース・プロンプトによって千差万別

Slide 9

Slide 9 text

9 ©2024 Loglass Inc. 品質保証‧評価の難しさ ~評価指標の定義がケースバイケース~ ● 一般的な項目はあれど、より具体はユースケース・アプリケーションによって千差万別 ● ドメイン・ユースケース毎に評価基準とデータセットがあることが評価の上で肝要有⽤性（helpfulness）どれだけ有用な回答をしたか（= 課題を解決できたか）事実性（factuality）正しい回答ができるか (事実でない内容を回答しないか) 有害性（harmlessness）望ましくない回答をする

Slide 10

Slide 10 text

10 ©2024 Loglass Inc. オフライン評価とオンライン評価 ● オフライン評価だけでは限界がある ○ 究極ユーザーが見た出力が全て。網羅性は大事だが事前に全て想定しきれない ● オンライン評価・代替指標を組み合わせる ● 代替指標 ○ 回答精度を直接評価しない。影響を与えると考えられるビジネス指標・ KPIを参照 ● e.g.) Github Copillot i. Acceptance Rate (生成したコードの受け入れ率) ii. Retension Rate (生成したコードをどの程度で編集するか ) オフライン評価事前にデータセットを用いて出力を評価オンライン評価ユーザーの実利用を元にしたFBや分析

Slide 11

Slide 11 text

Slide 12

Slide 12 text

12 ©2024 Loglass Inc. LLM出⼒の定性評価 ● 定量的指標に基づく評価は重要   ● 一方で、文章が自然な印象を人間に与えるかどうか等の評価は自動化しにくく、人間の主観的な判断が求められる場面も  ● 例えばtoB SaaSの場合、ドメイン知識がないといまいち判断つかないケースもそれなりにある     一方で全て人間を介在させるのはスケーラビリティやリソースの都合もあり現実的ではない？

Slide 13

Slide 13 text

13 ©2024 Loglass Inc. LLM as a Judge LLMがLLMの出力を評価する手法 -> LLM as a Judge ● 特定のドメイン・ユースケースに特化すればするほど、ドメイン・ユースケース固有の表現やニュアンスが増加するが、人間を全ての評価に介在させるのはコストがかかる ● スコアベースやペアワイズ評価、複数 LLMを使ったりとやり方は色々 ● （プールの監視員を監視する人を監視する世界 ...）人間による評価のコスト削減評価の揺らぎ解消人間の感覚や好みに近い評価

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

16 ©2024 Loglass Inc. モデル評価とは ● 出力を評価することで、モデルがユースケースに適しているかを判断 ● 事前定義されたメトリクス・データセットのほか、独自プロンプト/データセットを利用した自動評価も可能 ● 人間による評価ワークフローも ● 米国の一部リージョンではAWS マネージドチームによる評価も利用可能出典：https://aws.amazon.com/jp/blogs/news/evaluate-compare-and-select-the-best-foundation-models-for-your-use-case-in-amazon-bedrock-preview/ 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 ©2024 Loglass Inc. 所感 ● 現状は名前の通り、LLMモデルの性能評価・オフライン評価のためのもの ○ e.g.) 特定のタスクにおいて、モデルが目標とする精度を満たしているかを確認 ○ e.g.) 特定のタスクにおいて、複数のモデルを比較 ● オンライン評価全般は対象外。 LLM as a Judgeも他の仕組みの方が良さそう ● ドメインエキスパートと共に主観的な評価を行いたい時の、ワークフロープラットフォームとしては期待したい気持ち ● 複数パターンのKnowledge Base / Agentと繋げた状態で評価ができると嬉しそう ○ ナレッジベースA or B or Cの組み合わせでどれが一番良さそうか？を確認する

Slide 26

Slide 26 text

26 ©2024 Loglass Inc. まとめ ● AWS利用企業として、AWS内ネットワークで完結するBedrockは魅力的 ● モデル評価やガードレール機能も出てきて、プロダクション運用の基盤として整ってきていると感じる ● 一方、BedrockもこれだけでOK！というものではない。他サービス含めたアーキテクチャ等の Tipsがこれから充実・洗練されていくはずなので、自身も頑張りたい ○ e.g) プロンプト管理やら自動チューニングからオンライン評価、 etc… ● Bedrock情報を追い切れてるわけでも、使いこなせてるわけでもないので、良いやり方等があればぜひ議論させてください...！