LLMOps : ΔMLOps

v1.0 (2024/10/21)
LLM と従来 ML との差異 (delta, Δ) に基づく MLOps の修正

伊藤駿汰 (Cloud Solution Architect)
栗田宗平(Cloud Solution Architect)

Transcript

1. LLMOps : ΔMLOps LLM と従来 ML との差異 (delta, Δ) に基づく MLOps の修正 伊藤駿汰 (Cloud Solution Architect) 栗田宗平(Cloud Solution Architect) v1.0 2024/10/21 General
2. Agenda 1. LLMOps 概要 2. 評価 3. アセットとしてのプロンプト
3. LLMOps 概要 LLM 固有の事情に配慮した MLOps に対する修正
4. LLM システム開発の課題 初回の開発とデプロイ以後、開発が迷走もしくは停止することが多い 原因 具体的にシステムが解決すべき課題や目指すべき価値を定義できていないため、改善の方向性が明確になってい ない 開発がゴールとなっていて運用のための人員が割かれていない アセット管理や評価の困難さなどに起因する開発上のボトルネックがあり、初回デプロイ以後の更新を成し遂げられ ていない 課題を放置すると発生する問題 • LLM の API など主要コンポーネントの更新が頻繁であるにも関わらず、更新に追随できなくなりアプリケーションの 機能が低下する • 満足行く性能を持つ外部サービス (ChatGPT web 版など) にユーザーが流れ、シャドーIT問題や機密情報流出が 発生する • 性能が改善されず不十分であるためにユーザーが離れ、アプリケーションホストのための無駄なコストを支払い続ける 状態が継続する
5. LLMOps の定義 • LLMOps という言葉は新しく、その意味するところについてコンセンサスは固まりきってない • ここでは「LLM および LLM を組み入れたアプリケーションについて、継続的に性能を計測し改善するた めの各種取り組み」とし、MLOps のサブセットとして位置付ける • LLMOps の目的はターゲットとなる LLM システムの継続的な開発を妨げる要素を可能な限り除去・ 低減・円滑化し、エンドユーザーに届ける価値を最大化すること
6. 参考: 機械学習プロジェクトにおける課題
7. 参考: 課題に対する技術的アプローチ 自動化/ 可観測性 • コード駆動のアセット生成とデプロイ • 再現性と検証可能性を持ったパイプライ ン • アセット間の依存関係が明示され、集 中管理された管理体制 検証 • SWE で培われた品質管理のベストプラ クティス適用 • オフラインでのモデル品質検証、バイアス の最小化と説明性の確保 • メトリックに基づく検証 再現性/監査可能性 • 制御されたロールアウト機能 • 予測性能と期待性能のライブ比較 • ドリフトの監視とモデル改善に使用できる フィードバック
8. 参考: MLOps を実現するための要素 People • チームで共同で開発を進め、他人が引 き継ぐことを前提とした品質確保を継 続的に行う体制構築と文化醸成 • 無駄なくスキルをビジネス価値へと転 換するために必要な体制・技術への 金銭的/人的投資 Process • 学習やデプロイプロセス等、機械学習 の一連のプロセスに含まれる定型的処 理の自動化 • アセットの集中管理と共有による作業 効率の向上 • 再現性確保 Platform • アセットを集中管理し共有するための ハブ • 運用中のパイプライン、インフラ、製品 を監視し、期待通りの動作をしていな いことを検知することが可能な仕組み • 必要に応じて可及的速やかかつ安全 に本番への機能投入を可能とするシ ステム
9. 参考: ML プロジェクトのループ構造 • Inner Loop • モデルの探索と仮説検証 • 人間によるインタラクティブな試行 • Middle Loop • 本番投入可能なモデルの探索 • 再実行可能なパイプライン • Outer Loop • モデルの継続的監視と メンテナンス  「MLOps」は各要素およびループの間をつなぎ、円滑化を目指す モニタリング 自動学習 本番デプロイ 推論 学習パイプ ライン パラメーター チューニング モデルQA 学習 評価 モデル選定
10. 参考: MLOps 成熟度モデル https://docs.microsoft.com/ja-JP/azure/architecture/example-scenario/mlops/mlops-maturity-model https://techcommunity.microsoft.com/t5/ai-machine-learning-blog/mlops-maturity-model-with-azure-machine-learning/ba-p/3520625 Level 概要 技術 文化 Level 0 No MLOps • 機械学習モデルのライフサイクル全体を管理する ことは困難 • チームは別々で、リリースは困難 • ほとんどのシステムは "ブラック ボックス" として存 在し、デプロイ時およびデプロイ後のフィードバック はほとんどなし • 手動によるビルドとデプロイ • モデルおよびアプリケーションの手動に よるテスト • モデルのパフォーマンスの一元的追跡なしモデル学 習は手動 • まず動くものを作り上げ、スモールスタートでプロ ジェクトを推進する Level 1 DevOps no MLOps • Level 0 よりもリリースの苦労は少ないが、新しい モデルごとにデータ チームに依存 • 運用段階でのモデルのパフォーマンスに関する フィードバックは依然として限られる • 結果の追跡および再現が困難 • 自動ビルド • アプリケーション コードの自動テスト • チーム内でのコード共有とレビューを行う • パイプラインなどの自動化技術を活用して、低摩 擦に継続的に本番投入する • テストなどによりコード品質に配慮する Level 2 Automated Training • トレーニング環境は完全に管理され、追跡可能 • モデルの再現が容易 • リリースは手動であるが、摩擦は少ない • 自動化されたモデルの学習 • モデル学習のパフォーマンスを一元的に追跡 • モデル管理 • 機械学習固有の性質に配慮した自動化を行う • 機械学習実験の再現性確保に注意を払う Level 3 Automated Model Deployment • リリースは低摩擦で自動 • デプロイから元のデータまで完全に追跡可能 • 環境全体 (学習 > テスト > 運用) を管理 • デプロイするモデルのパフォーマンスに関する A/B テストを統合 • すべてのコードのテストを自動化 • モデルの学習性能を一元化 • 機械学習モデルの品質に配慮する • 投入先ソフトウェア開発チームと連携した継続的 モデルデプロイとその自動化を推進する Level 4 Full MLOps Automated Retraining • システムを完全自動化し、監視を容易化 • 運用システムは、改善方法に関する情報を提供。 場合によっては、新しいモデルで自動的に改善 • ゼロ ダウンタイム システムに近づく • モデル学習とテストを自動化 • デプロイされたモデルからの詳細で一元化されたメ トリック • 機械学習モデルの経時的な劣化を前提とした監 視体制を整備する • 手動で実行する必要が無い部分について自動 化を進め、「最大効率で機械学習モデルを運用 できる体制」を目指す
11. 参考: Level 4 – Full MLOps Automated Retraining データパイプライン 学習パイプライン デプロイ パイプライン データ準備 良いモデル の発見 アルゴリズム 選定 データセット /特徴量 モデル テスト・検証 ML エンジニア データサイエン ティスト データ エンジニア QAエンジニア MLOps エンジニア 検証 ML API ログ データ変動 再学習トリガー アプリ Kubernetes インフラ エンジニア ソフトウェア エンジニア ログ モニタリング ML エンジニア データサイエン ティスト QAエンジニア MLOps エンジニア
12. LLMOps と MLOps の差異 • 出力に対する正解が一意に定まらないため、LLMOps では MLOps 以上に評価が難しい • 自然文を出力とするシステムの「性能」とはどのように定義されるか • その「性能」をどのように計測するか • 計測に使用する道具は信用できるか • 入力も自然文であるため、MLOps で性能劣化を検知するための典型手法であったデータドリフトの計算が難しい • 自然文の分布変化を定義する典型的な方法がいまだ未確立 • Zipfの法則の自然文への適用、Semantic Shift Stability (S. Ishihara, 2022) など応用できそうな研究は少しずつ増えてきている • 分布変化を定義してもその分布変化が LLM およびシステムの性能劣化に繋がるかが不明 • LLM の学習および推論環境の準備にかかるコストが莫大であることから、MLOps で性能回復の典型手法であった再 学習では性能回復にかかるコストを正当化できない可能性がある • 低コストな性能改善手法の検討 • SLM (Small Language Model) + LoRA (Low Rank Adaptation) による軽量なモデルおよび学習手法の利用 • API で提供されている LLM を利用している場合、fine-tuning API 利用も選択肢となるが一般に非常に高額、プロンプトエンジニアリングによる 改善 • システム全体からよりコストパフォーマンスに優れる改善対象の特定 • 性能に影響を与える固有のアセットとして「プロンプト」が存在するが、現状プロンプト管理のベストプラクティスは未確 立
13. LLMOps のための MLOps の修正 評価 • LLM-as-a-Judge と Human-in-the- loop に基づくオフライン評価 • オンライン評価と LLM 評価の信頼性向上を 目的とした Human-in-the-loop の導入 • 人手評価と LLM 評価を近づけるためのプロン プトチューニング、もしくはモデルの学習によるオ フライン評価の信頼性向上 • 低コストに計測できるオンライン評価指標 の選定 データドリフト (資料化未定) • 性能低下と相関するドリフトを見出すため のデータ収集および分析環境の準備 • 当面はデータドリフトは使用せず、オンライン評 価の結果および LLM-as-a-Judge と Human-in-the-loop で確立したオフライン評 価による性能低下検知によって性能改善策を トリガーする • ポストアナリティクスによって性能低下の先行 指標を見出すことを目指し、最終的にはデータ ドリフトによる性能改善策のトリガーに移行 性能改善 (資料化未定) • システムを構成する要素のうち、性能に悪 影響を及ぼしている LLM 以外の箇所 (検 索エンジンなど) を特定し改善を試みる • 特に LLM 周辺については、まずプロンプト の改善、次点で SLM 等軽量モデルの fine-tuning や特化モデルの作成を検討 • モデルの評価指標を改善する方向に進むプロ ンプトの自動生成は困難、当面は LLM-as- a-Judge によるオフライン評価を併用しつつ得 られたデータを few-shot でプロンプトに取り込 みつつ「良いプロンプト」を得るための試行錯誤 • fine-tuning 済みの LLM のホスティングコスト を正当化することは多くのユースケースでは困難、 軽量な SLM のチューニングや特化モデルの作 成を検討 • 最後の手段として LLM 本体に対する fine- tuning を検討
14. LLMOps のための MLOps の修正 アセットとしてのプロンプト • プロンプトを管理する機構、「プロンプトスト ア」の実装を検討 • 用途に応じて仕組みの実装が必要かアプリ ケーションコードにハードコードして git 管理する か検討
15. 評価 Human-in-the-loop を取り入れた LLM-as-a-Judge
16. オフライン評価とオンライン評価 オフライン評価 • リアルタイムのユーザーフィードバックに依らず計測可能な評価指 標を用いた事前評価 • 機械学習モデルの場合、何らかの正解ラベル付きデータセットを 用意してターゲットシステムに推論させ、その推論結果を評価する ことで行われる • 通常のプログラムの場合、単体テストやE2Eテストなどの自動テス トによって行われる • 本番投入の前にシステムに潜在的に含まれる問題点を特定する ために用いられる • 一般に実行コストが小さい (データに対するアノテーションの要否 などに応じて大きく増減する) オンライン評価 • ユーザーフィードバックやユーザーの利用状況など、本番投入後に 計測可能な評価指標を用いた、システムの最も直接的な評価 • 実環境由来のノイズが結果に乗るため、異なるシチュエーションに おけるオンライン評価は互いに比較することが難しい A/Bテストやバンディットアルゴリズムによって複数の候補を本番 環境で走らせ相互に指標を比較することを通じて良し悪しを評 価する ただしユーザ都合で業務フローをA群/B群分けられないことも • 実行コストが大きい
17. 評価の流れ オフライン評価 • プログラムレベルの単体テストやE2Eテストなどの自動テスト、機械 学習モデルに対する評価用データセットを用いた性能確認などを 行う • バグや問題を含む候補モデルを弾き、本番投入候補を絞り込む フィルターとして機能する オンライン評価 • 本番モデルと候補モデルを A/B テストやバンディットアルゴリズム を通じて比較し、KPI を改善するより良いモデルを見出す • KPI を直接測定できる場合は KPI を、難しい場合は相関する別 の評価指標を用いて性能を測る VS VS Win Win 本番 本番 本番 本番
18. 低コストかつ安定したオフライン評価のための LLM-as-a-Judge • LLM 登場以前、自動評価指標 (BLEU など) の限界が指摘されはじめ、生成文評価は人手評価に 頼っていたが、人手評価は高コストでスコアの揺らぎが大きい • LLM を利用して自動評価を行う仕組み (LLM-as-a-Judge) が台頭 • GPT-4 で一致評価を行う場合、人手評価と80%程度一致 (Zheng et. al, 2023) • 翻訳タスクにおいて GPT-4 の人手評価との一致率が BLEU を上回る (Kocmi and Federmann, 2023) 十分に低コストであるため、改善試行の回数を大幅に増やすことができる 改善試行を増やすことでアプリケーションの性能をより引き上げることが可能になる • 主流はスコアベース評価 • プロンプトによってスコアの出力を指示する評価方法 • 簡単に実装可能、改善も比較的簡単 • LLM 固有のバイアスが存在する https://arxiv.org/abs/2306.05685 https://arxiv.org/abs/2306.05685
19. 参考: 開発速度と品質のトレードオフの誤謬 • 開発速度と品質はトレードオフの関係ではない • デプロイ頻度が高い「エリート」集団はデプロイ頻度が低いそれ以外の集団と比べて高い品質を実現す る傾向 https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition?slide=61, 2024/09/02 閲覧 エリート ハイパフォーマー ミディアムパフォーマー ローパフォーマー リードタイム 1時間未満 1日から1週間 1か月から半年 半年以上 デプロイ頻度 オンデマンド (1日複 数回) 週1回から月1回 月1回から半年に1 回 半年に1回未満 MTTR 1時間未満 1日未満 1日から1週間 半年以上 変更失敗率 0-15% 16-30% 16-30% 16-30%
20. LLM-as-a-Judge の問題点と解決策 • LLM が出力するスコアに対する信頼性 • 人手評価と比較的よく一致すると言っても80％程度 • LLM 固有のバイアスが存在する • スコアの揺らぎは LLM 推論実行時に確率的振る舞いを抑制できるかどうかに依存する 人間による評価を正解とし、人間による評価と LLM による評価の結果を近づけることを目指す • プロンプトやモデルなど異なる前提条件の下に得られた評価指標どうしは比較できない (比較は適切で はない) テスト全体を再実行する必要があり、その分コストがかかる 軽量なテスト用モデルを作成しテストの実行コストを下げる
21. 実験 JGLUE の JSTS (Japanese Semantic Textual Similarity) データセットを使用する 付与された類似度を人手評価結果として扱い、LLM を使用して推定した類似度と以下4つの実験設 定で比較する A) 人と LLM の評価傾向の違いを評価する B) 人間による評価に近づける施策として最も低コストな few-shot learning がどの程度有効か評価す る C) 1GPUでも動作可能な小規模モデルの fine-tuning でどの程度人間による評価に近づけるか評価 する D) Human-in-the-loop を想定し、fine-tuning を行う場合学習データ件数によってどのような傾向が 生じるか評価する 注意 1. 2と3は厳密に比較可能な対照実験になっていない (2,3の実験間で同じモデルを使用していない) 2. ハイパーパラメーターやプロンプトを詰めて精度を高める努力はしていない (追加の精度を高める努力 によって実験結果が覆る可能性は否定できない) 3. 方向性に強い誤りがないことを確認する目的の実験、厳密な実験は2024/10現在実施中、結果 公開未定 https://techblog.yahoo.co.jp/entry/2022122030379907/ https://github.com/yahoojapan/JGLUE
22. 参考: 分布間距離 • 2つの確率分布間の距離を表現する指標 • 分布間距離が大きいということは2つの分布がより異なっていることを意味し、分布間距離が小さいこと は2つの分布がより似ていることを意味する • 機械学習の本質は推定値の分布と真の値の分布間距離の最小化 • 分布間距離の一例 • Jensen-Shannon 距離 • 情報量を事象の不確かさを測る尺度として解釈した場合、あるデータ (分布) が別のデータ (分布) の不確かさが減少する。この減少 幅をデータセット全体に対して平均すれば Kullback–Leibler divergence となるが、距離の公理を満たさないため、これを平滑化して 距離の公理を満たすようにしたものが Jensen-Shannon 距離。0~1の値をとる。 • Wasserstein 距離 • ある分布から対象となる分布に移動する場合にかかる最小のコスト。最適輸送問題の枠組みでよく用いられる。山盛りの土 (基準 分布) を別の形 (対象分布) に作り替える時どれだけの回数バケツで運べば良いか、のイメージ。0~∞の値をとる。
23. A) 人手評価と LLM 評価の差異① • JGLUE Semantic Text Similarity の評価スコア (人手評価) と LLM (GPT-4 (0613), GPT-4o)による評価スコアの比較 • 分布は傾向こそ似通るもののそれぞれやや異なる • LLM は5段階評価を行う傾向が強い • GPT-4 (0613) と GPT-4o を比較すると、相関係数や誤差はやや GPT-4 (0613) の方が良好であるものの、Jensen-Shannon 距離は GPT-4o の 方が良好 人手評価はスコアの平均値であるため半端な値が出てしかるべき、 スコアを丸めた場合はどうか？ モデル Pearson R Spearman R RMSE JS Divergence gpt-4(0613) 0.909 0.883 0.726 0.390 gpt-4o 0.870 0.882 0.770 0.340 データセット全体の評価 スコア頻度分布 X軸: スコア, Y軸: 件数 上: 人間 中: gpt-4(0613) 下: gpt-4o
24. A) 人手評価と LLM 評価の差異② • 比較的分布の見た目が近い GPT-4 (0613) について、0.5 刻みでラウンド • それでも分布傾向が異なる データセット全体の評価 スコア頻度分布 X軸: スコア, Y軸: 件数 上: 人間 下: gpt-4(0613)
25. 参考: 評価に使用したプロンプト # Your Role あなたはテキストの類似性を評価することができます。2つの日本語の文章を入力として受け入れ、 0 から 5 までの間の数値 (小数第1位までの値) で評価します。文章の類似性が高い場合に大きい数値をとり、類似性が低い場合は小 さい値をとります。 例えば同じ文章や完全に意味が一致している場合は5となります。 # Constraints 出力結果は0から5までの数値である必要があります。数値は小数第1位までの値である必要があります。 出力は数値のみにしてください。「評価: 」のように数値以外の文字列を含めないでください。 # Evaluation Criteria - 0: 文章が全く異なる。 - 1: 意味がかなり異なる。2つの文は一部の単語やフレーズが共有されているかもしれませんが、全体的な意味は大きく異なります。 - 2: 意味がやや異なる。2つの文は一部の重要な情報を共有していますが、他の重要な部分では異なる情報を提供しています。 - 3: 意味が部分的に一致する。2つの文は主要な情報を共有していますが、一部の詳細が異なるか、一部の情報が欠落しています。 - 4: 意味がほぼ一致する。2つの文はほぼ同じ情報を提供していますが、微妙な違いや表現の違いが存在します。 - 5: 文章が等価。2つの文は完全に同じ情報を提供しています。
26. プロンプトチューニングによる評価差異の縮小 • few-shot learning として評価サンプルをプロンプトに含めることで、人手評価と LLM 評価の差が縮 小することが期待できる • プロンプト作成は低コストな取り組みであり、後述する fine-tuning より実行しやすい • プロンプトの変更は容易であるが、分布間距離を縮小させる方向のプロンプトを自動生成することは現 時点ではまだ現実的ではない 人手による試行錯誤が必要、プロンプトを試作しテストデータを用いた評価と分布間距離の算出を都 度行ってイテレーティブに改善していく 複数回の評価実行コストがかかる、プロンプトエンジニアの手腕に依存する
27. B) few-shot learning による分布間距離の縮小 • JGLUE Semantic Text Similarity の評価スコア (人手評価) と LLM GPT-4 (0613)、GPT-4 (0613) + few-shot learning による 評価スコアの比較 • few-shot learning によってプロンプトにテキストとそれに対する人 手評価の値を与えることで、相関係数や RMSE の値はやや悪化し たが Jensen-Shannon 距離は大幅に改善した モデル Pearson R Spearman R RMSE JS Divergence gpt-4(0613) few-shot なし 0.909 0.883 0.726 0.390 gpt-4(0613) few-shot あり 0.908 0.878 0.819 0.133 上: 人間 中: gpt-4(0613) 下: gpt-4(0613) + few-shot
28. 参考: few-shot learning に使用したプロンプト # Your Role 省略 # Constraints 省略 # Evaluation Criteria 省略 # Example "sentence1": "川べりでサーフボードを持った人たちがいます。", "sentence2": "トイレの壁に黒いタオルがかけられています。", "label": 0.0 "sentence1": "男性が子供を抱き上げて立っています。", "sentence2": "テーブルを囲みワインの品評会が行われています。", "label": 0.2 "sentence1": "部屋の中でテレビゲームをしている人がいます。", "sentence2": "画像の写し出された携帯電話があります。", "label": 0.4 "sentence1": "まばらに草が生えている所にシマウマが１頭いて草を食んでいます。", "sentence2": "クマたちが草むらで横たわっています。", "label": 0.6 "sentence1": "ソファーに座っている女の子の前で、犬が座っています。", "sentence2": "ソファーに立っている。", "label": 0.8 "sentence1": "男性が2名、手にコントローラーを持ってゲームを楽しんでいます。", "sentence2": "2人の人物がソファに座っています。", "label": 1.0 "sentence1": "ピッツァが４等分されて置いてあります。", "sentence2": "ピッツァが飛んでいます。", "label": 1.2 ・ ・ ・ "sentence1": "林の中を1台の自転車が走行しています。", "sentence2": "林の中で1台の自転車が走行しています。", "label": 4.8 "sentence1": "真っ赤な二階建てのバスが、停まっています。", "sentence2": "赤い二階建てバスが止まっています", "label": 5.0
29. fine-tuning による分布間距離の縮小 • 人手評価のデータを学習データとして使用し、既存の文分類モデル (BERT など) もしくは文生成モデル (phi-3, llama など) を fine-tuning する • プロンプトチューニングによる分布間距離縮小の取り組みと異なり、確率的勾配降下法によるある程度 の論理的裏付けの下に評価モデルのスコアを人手評価に直接近づけることができる • 実装コストが重く、評価モデルに使用するベースモデルのサイズ次第では fine-tuning コストおよび評価 モデルのホスティングコストが重い
30. C) fine-tuning による分布間距離の縮小 • 600件のデータセットで phi-3-mini-4k-instsuct を fine-tuning • スコアの頻度分布は人手評価と最も近い • JS距離もより大規模 (と推測される) GPT-4 を few-shot learning でチューニ ングする場合より低い値を示す • 見た目も明らかに人手評価と近い • スコア分布はより人手評価に近い一方 RMSE などの値は few-shot learning より悪化傾向 • 同じモデル間の比較ではない点に注意 モデル Pearson R Spearman R RMSE JS Divergence Phi-3-mini-4k- instruct(n=600) 0.796 0.751 0.902 0.058 上: 人間 下: fine-tuning phi-3-mini-4k
31. 参考: Human-in-the-loop 機械学習モデルの継続的な開発と運用のプロセス中に人間を組み込み、人間からのフィードバックをモデ ルに反映する取り組み 機械学習モデル 入力 推論結果 サンプリング システム 学習 ラベル付き データセット 正解ラベル 人間
32. Human-in-the-loop による LLM-as-a-Judge の信頼性向上 • サンプリングされた少数のデータに対する正解ラベルを人手で行ってデータセットを作成し、評価用 LLM をチューニングすることで評価用 LLM が出力するスコアの信頼性を継続的に担保する 評価用モデル (LLM + プロンプト) ABCabc~ ABCabc~ ABCabc~ 4点 3点 5点 入力 ABCabc~ サンプリング システム 5点 プロンプト チューニング or fine-tuning ラベル付き データセット 正解ラベル 人間 開発を通じた フィードバック データ収集
33. Human-in-the-loop における人手評価 ユーザーフィードバック システムにユーザーが応答の良し悪しを評価するフィードバック機構 を設ける • ボタン • おすすめする度合を示す5段階もしくは10段階の評価ポップアップ システムの利用規模次第では大量のデータを集めることができる 低コストにデータを収集できる バイアスとノイズが乗りやすいため、慎重な取り扱いが必要 QA システムのQAプロセス内でサンプリングした入力に対し人手評価を 付与する 比較的信頼性が高いデータを期待できる 複数のアノテーターを継続的に雇用する必要があり高コスト 評価基準を徹底するためのピープルマネジメントが必要 集められるデータ量は少ないが安定的
34. Human-in-the-loop の初手 1. 評価する観点を決定する 2. システムからログをサンプリングする 3. 人間の手によって同様の評価観点に従って評価 を行う  作成したデータセットは今時点でのシステムの評価であ ると同時に、以後評価モデルの妥当性評価と few- shot learning や fine-tuning による評価モデル改善 に利用できる 4. 評価観点に従うプロンプトを記述して評価モデル を用意する 5. 評価モデルで評価を行う 6. 両者の分布を比較し、チューニングを検討する ※①評価指標の策定 ② ③ ⑤ ⑥ ④
35. 人間の意図をシステムに反映する取り組み 評価観点の策定 定量的にシステムの良し悪しを決める基準を確定させる値 = 評 価指標を通じて、システムにとってどのような振る舞いが好ましく、ま た好ましくないかを決定する 評価指標の改善を目指してシステム開発を継続することで、大 局的にシステムは評価指標が規定する姿に近づいていく システムが目指すべき姿やシステム開発の根拠となった課題と密 接に結びつく もしまだシステムが目指すべき姿や大元の課題感があいまいな場 合、最優先で具体化する必要がある サンプリング 入力データとそのときのシステムの出力のペアを何らかの基準に基 づいて選抜することで、システムの出力の代表値 (複数) を決定す る サンプリングの方法によって評価指標とセットでシステムの評価に 影響が及び、間接的にシステムの方向性に影響を与える 評価観点を明確に決定できなくても「良い」とされる入出力ログ と「悪い」とされる入出力ログを人間の手で選ぶだけでも十分な 「人間による評価」となる 「良い」と「悪い」の境界に近いログをサンプリングすることでシステ ムの細かい挙動の良し悪しを定義し、またより広範なデータをサン プリングすることでシステムの挙動の網羅性を引き上げることがで きる (能動学習)
36. 参考: 能動学習 • モデルの性能を引き上げる上で、新たに人間が評価すべきデータ をサンプリングする一連の技術を指す • 決定境界近辺の推論結果が不確実であるような領域のデータを サンプリングする不確実性サンプリングと、モデルにとって未知の データを取り扱えるようにするために有用なデータをサンプリングす る多様性サンプリングが代表的な方法 ロバート・モナーク 著, 上田隼也, 角野為耶, 伊藤寛祥 訳. Human-in-the-loop 機械学習 人間参加型AIのための能動学習とアノテーション. 共立出版, 2023, 85p-124p. 不確実性サンプリングでサンプリングするデータ 多様性サンプリングでサンプリングするデータ ラベルなし ラベル済み 決定境界
37. D) HITL を想定した fine-tuning 時の分布間距離の推移 • 600件ずつ600～2400件の件数で phi-3-mini-4k- instsuct を fine-tuning • 件数を増やすほどすべてのスコアがおおむね改善傾向を示す • RMSE は2400件になってようやく縮小した • JS 距離は1800件程度で改善が見られなくなった • おおむね HITL を想定して徐々にデータセットを増やしていけ ばその分性能改善はみられるが、単純にデータセットを増やし て効果が得られる限界値が存在しそう (今回のデータセットお よび phi-3-mini の場合は10^3オーダー) 無限にデータを増やす必要は無さそう あるタイミングまでは単純にデータを増やすことを目的とした多 様性サンプリングが有効そう、その後は分離境界近辺のデー タを選ぶ不確実性サンプリングが有効か？ モデル Pearson R Spearman R RMSE JS Divergence Phi-3-mini-4k- instruct(n=600) 0.796 0.751 0.902 0.058 Phi-3-mini-4k- instruct(n=1200) 0.809 0.752 0.900 0.032 Phi-3-mini-4k- instruct(n=1800) 0.807 0.754 0.907 0.026 Phi-3-mini-4k- instruct(n=2400) 0.826 0.765 0.841 0.026
38. 無思慮な Human-in-the-loop 実施の戒め • HITLによって人間評価との乖離を抑制できる期待があるが、コストが重い • タスクによってはLLMと人手評価でそもそも大きな乖離が生じないケースもある Human-in-the-loop をいつもフルセットで適用することが必ずしも正しいとは限らない ただし精度が十分でなければ「やらない方がマシ」 (有害) という評価もあり得る
39. 評価モデルに対する Human-in-the-loop の検討手順の提案 1. アプリケーションの本質的な価値に関わる評価観点 (重要評価) と相対的に優先度が低い評価観 点 (参考評価) に分ける 2. 重要評価については、まず試験的に少数 (20～40件程度) のデータに対して LLM による評価を行 い、人間の感覚と大きく乖離していないか確認する • 感覚的に乖離が小さいようであればそのまま LLM-as-a-Judge を実行し、十分なデータと評価者を確保できるまで の繋ぎとして使用する、この段階では評価値の少々の変動にフィッティングさせないように注意 • 乖離が大きい場合はそのままでは評価として有害な可能性が高いため Human-in-the-loop を最初から実施する 3. 参考評価についてそのまま LLM-as-a-Judge を実行する • 参考評価の評価値変動幅を確認し、少々の変動については無視する • 著しいスコア変動が発生した場合に実際の評価傾向を確認した上で対処を検討する
40. LLM-as-a-Judge を利用した LLM システム改善の発展 レベル 概要 評価モデルの改善 ターゲットシステムの改善 Lv.0 No evaluation LLM システムに対する評価を行っていない - 感覚に頼ったプロンプトエンジニアリング Lv.1 Human evaluation 人間の手によって LLM システムに対する評価を 実施 - 感覚に頼ったプロンプトエンジニアリング Lv.2 First automated evaluation 既存 LLM を使用してプロンプトエンジニアリングに よって人手評価に近い評価用モデルを作成 プロンプトエンジニアリング 評価モデルの出力値を最適化する方向 へのプロンプトエンジニアリング Lv.3 Human-in-the-loop evaluation 定期的に人間によるラベル付けを行ってデータセッ トを拡充し、その結果に基づいて評価モデルを継続 的に改善 • プロンプトエンジニアリング • fine-tuning 評価モデルの出力値を最適化する方向へ のプロンプトエンジニアリング 評価モデルのオンライン評価への応用 Lv.4 Direct tuning 評価用モデルが出力するスコアを使用して直接的 にシステムを構成するモデルを改善 • プロンプトエンジニアリング • fine-tuning 評価モデルの出力値を最適化する方向 へモデルを学習 評価モデルのオンライン評価への応用
41. 参考: RLHF①ベースモデル作成 プロンプト データセット プロンプト: Azureを提供している会社は？ 応答: Microsoftです。 人間 プロンプトと好ましい応答がペ アになったデータセット GPT-3 GPT-3 ベースモデル fine-tuning
42. 参考: RLHF②報酬モデル作成 GPT-3 ベースモデル プロンプト データセット プロンプト: Azureを提供している会社は？ 応答1: Microsoftです。 応答2: 知らねぇよカス。 応答3: そこら辺の会社 応答4: 米国ソフトウェア企業であるMicrosoftです。 人間 応答4>応答1>応答3>応答2 プロンプトとベースモデルが出力した応答候補 順位 小規模な GPT-3 報酬モデル
43. 参考: RLHF③チューニング GPT-3 ベースモデル 報酬モデル プロンプト データセット プロンプト 応答 報酬 PPO InstructGPT
44. 持続可能な Human-in-the-loop • Human-in-the-loop が自然に持続するようなケースはある程度限定的 • フローそのものに前提として人間が組み込まれている≒機械学習モデルの結果を使用して人間が対応するようなフ ローを採用しているケース • ユーザーフィードバックをベースとした評価が確立しているケース • 機械学習モデルのアノテーションにおいて特別なドメイン知識が不要か、ドメイン知識を持つ人材を無制限に調達で きるケース アノテーションを実施すること自体に業務ドメイン知識が必要な場合かつ対象機械学習モデルを組み 込んだシステムが業務担当者を置き換える性質を持つ場合、アノテーションを行える人材の数が漸減し、 やがて Human-in-the-loop が破綻する • アノテーションに上級者クラスの知見が必要な場合、システムによって初級者、中級者が不要になっているため上級 者は育たず数を減らす一方となるため 十分に業務ドメイン知識を持つ人材を維持するため、一定程度の人員を維持して業務を担当させ続 けるか別途知見を継承するための方策を構築するなどの組織的な方策を練らなければならない
45. オンライン評価指標の策定 • オンライン評価の評価指標にはビジネス上の KPI もしくは KPI と相関する何らかの評価指標を用いる • KGI を導くモデル式の構成要素が KPI となる • 例: オンラインカウンセリングツールの KGI とそのモデル • 年間売上 (KGI) = カウンセリング回数 × 平均カウンセリング価格 × プラットフォーム取分 (定数) • カウンセリング回数 = 新規顧客数 + リピート顧客数 × 年間平均カウンセリング回数 • 新規顧客数 = 初回カウンセリング実行率 × 新規作成アカウント数 • リピート顧客数 = 新規顧客数 × リピート率 KPI: カウンセリング実行率, 新規作成アカウント数, リピート率, 年間平均カウンセリング回数, 平均カウンセリング価格 • KGI、KPI は計測が難しいもの、遅延して計測できるもの、ほぼリアルタイムに計測できるもの、ノイズが 多く使用困難なものなどが存在する 対象指標と相関する (と考えられる) 代理指標によって計測する
46. オンライン評価指標とオフライン評価指標 • オンライン環境でシステムに対してユーザーが感じる価値や問題点のフィードバックを多角的に得られるこ とは稀 • 5段階の満足度評価や ボタンなどが限界 • 満足度や には様々なユーザーの感覚が内包されているが、そこからユーザーの感覚を分離することは困難 (改 善の方向性を直接得ることは難しい) ログを加工して得られるユーザーの特定の挙動を指標化したものをオンライン評価指標として用いる オフライン評価とオンライン評価の乖離を生む原因になる
47. 参考: オフライン評価とオンライン評価の相関 • 必ずしもオフライン評価による性能改善がオンライン評価の改善につ ながるとは限らない • 例: Booking.com におけるビジネス指標 (コンバージョン率) とオフライン評価 の指標改善の関係グラフ、相関らしい相関がみられない • 収穫逓減によるパフォーマンスの飽和、セグメントの飽和、不気味の谷効果、 代理目的変数の過剰最適化など オフライン評価の主要な役割は動作の傾向と改善点を探るための フィルタリング オンライン評価を通じてより良いオフライン評価を得る取り組みは重 要 https://dl.acm.org/doi/10.1145/3292500.3330744 高柳慎一, 長田怜士. 評価指標入門. 技術評論社, 2023, 35p-38p.
48. Human-in-the-loop を通じたオフライン評価とオンライン評価の連携 • LLM システムからサンプリングしたデータに対する人間の手による評価値の付与を定期的に行うことは、 データセットを得ると同時にそのタイミングでのシステムに対する評価とみなすことができ、オンライン評価 の値として取り扱うことができる • 十分に人手評価に近い評価用モデルが完成し、また継続的に人手評価に近づける取り組みを行って いる場合、評価用モデルをオンライン評価に用いることが視野に入る ログを加工して得られた指標とは異なる観点で、本番システムの性能をニアリアルタイムに計測できる セマンティックなデグレ検知を実現できる ログから得られるオンライン評価指標を否定するものではない、多角的な評価のために併用が望ましい
49. アセットとしてのプロンプト プロンプトストアの実装検討
50. 機械学習モデルに関連するアセット • 従来 ML と共通する部分は ML 向けの仕組みを流用 アセット 形式 保管場所 学習用データセット csv, parquet などのファイル DB もしくは特徴量ストア内のデータ データレイク 特徴量ストア 評価用データセット csv, parquet など DB もしくは特徴量ストア内のデータ データレイク 特徴量ストア 学習を行うプログラム Python スクリプト Jupyter Notebook ソースコード管理ツール 実行環境の定義 pip: requirements.txt conda: environment.yaml poetry: pyproject.toml コンテナ: Dockefile ソースコード管理ツール ビルドを伴う場合はコンテナレジストリー、 VM イメージレジストリーなど形式に応じたレ ジストリーを併用 学習済みモデル 使用したフレームワークに応じたファイル モデルレジストリー パイプラインの定義 yaml SDK を使用したスクリプト ソースコード管理ツール
51. 新たなアセットとしてのプロンプト • LLM においては学習済みモデルのみならず併用するプロンプトによっても 大幅に出力傾向が変化する 学習済みモデルに加えてプロンプトを管理する仕組みが必要 上: gpt-4(0613) 下: gpt-4(0613) + few-shot
52. プロンプト管理の方法 プログラムの一部として管理 • git などバージョン管理ソフトでソースコードと共に管理する シンプルな管理体制 全体として完全に動作する形式で保持できる プロンプトだけを変更する場合でもソフトウェア全体のレビュープロ セスを通る必要がある モデルやプログラムとは独立して管理 • プロンプトに ID を振り取得できる DB で管理する プロンプト単体での変更が容易 専用の仕組み (プロンプトストア) を作る必要がある
53. プロンプト供給の仕組み ビルド時にプログラムの内側に組み込むことで静的に供給 • アプリケーション本体のビルド時にプロンプトストア内のプロンプトを 組み込む アプリ構造とプロンプトが密接に結びつく場合にはコードとプロンプ トの完全性を保てる プロンプトの繁栄にはリビルド・デプロイが必要 プロンプトを供給する専用の仕組みから動的に供給 • アプリケーションにはプロンプトの識別子とプロンプトストアへの接 続手段を組み込み、動作時に動的にプロンプトを取得する 動作環境に手を加えずプロンプトのみ更新していくことが可能 アプリ構造とプロンプトが密接に結びついている場合アプリケー ションにエラーが生じる可能性がある プロンプト ストア アプリ ID プロンプト 人間 コード アプリ 人間 プロンプト ストア ビルド
54. MLflow • 機械学習のライフサイクル管理をサポートする OSS • LLM 支援機能が大幅強化、LangChain など LLM 関連フレームワークをサポート • 実質的にはプロンプト + モデル (ローカル LLM もしくは特定の API) をまとめてビルドした単位で「モデル」 として管理する コードの一部としての管理に相当する
55. プロンプトストアに求められる特性 • name + version および alias によるプロンプト識別が可能であること • version は latest の指定を可能とすることで、新しいプロンプトが追加されたとき自動で新しいものを参照する • alias は指定した複数プロンプトを指定した確率に基づいて返すための仕組み、主に A/B テストで用いる • テンプレートとその子要素を紐づけるためのプロパティを持つこと • なるべく高速に応答すること • LLM アプリケーションに動的にプロンプトを提供する性質上、プロンプトストアの応答時間はユーザーに対する LLM ア プリケーションの応答時間にそのまま足される • 現状 LLM の応答の方が圧倒的に遅いため、プロンプトストアのの応答速度は当面は100ms程度で実用十分 • 十分に冗長化されていること • プロンプトストアがダウンする = LLM アプリケーションがダウンとなるためプロンプトストアはできるだけ落ちないことが望 ましい • アプリ側でプロンプトをキャッシュすることで緩和可、プロンプトストアを呼び出す SDK 側で対応
56. 構造化されたプロンプトによる動的プロンプト変更 • テンプレート構造とテンプレートを埋める個別のプロンプトを別に管理することで、より細やかなプロンプトエ ンジニアリングが可能になる • テンプレートはビルド単位で静的に埋め込むかIDを固定してストアから供給し、個別のプロンプトパーツは ストアから実行ごとに動的に供給することで、アプリケーションの完全性とフレキシビリティを両立 プロンプトテンプレート プロンプトパーツ プロンプトパーツ プロンプトパーツ プロンプト ストア ID プロンプト
57. 参考: Feature toggle • アプリケーションの機能のオンオフを切り替えるフラグ情報を供給する仕組み • 小さい JSON などを取得する • セグメント別の供給ができる • サブスクリプションのプラン別機能切り替えや、A/B テストなどで利用する
58.  本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならない ため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性については保証できません。  本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。  すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの 格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、その他）、および目的であっても禁じられています。 これらは著作権保護された権利を制限するものではありません。  Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライ センス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。 © 2024 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。