Evaluationsフレームワークについて

こんにちは Yadaです。 そしてRobです。 Evaluationフレームワークを ご紹介します。 アプリのインテリジェント機能の品質を 測定する新しいフレームワークです 自信を持ってアプリを リリースできます。 昨年 Foundation Modelフレームワークを ご紹介しました。 デバイス上のモデルを使って アプリにインテリジェント機能を追加できます。 Apple Intelligenceを 駆動するモデルです。 生成AIでアプリ機能を構築すると 新たなテストの課題が生じます 同じ入力が異なる出力を 生成するからです。 これらのモデルはソフトウェアテストの 基本的な前提を崩します。

従来のソフトウェアを考えると 特定の入力は常に 特定の出力を生成します。 この動作はユニットテストで 簡単に検証できます。

同じ入力は必ず 同じ出力を生成します ユーザーのデバイスを含む どのデバイスでも同様です。

インテリジェントソフトウェアでは 動作を検証するために 機能の一貫性に頼れません。 つまりユニットテストだけでは 不十分です。 未検証の動作はユーザーの 信頼を損ないます。 ユーザーはアプリのインテリジェント機能に 期待しています あらゆる機能が安全で 信頼性の高いものであることを求めます。

予測不能な動作をする機能を リリースすると アプリの評判に 悪影響を及ぼします。

インテリジェント機能を測定し 異なる入力に対してどう応答するかを 理解することが重要です。 機能テストでは確率的な動作を 検証できないため より堅牢な新しいテスト形式が 必要です。

アプリが予期しない結果を生成する 頻度を把握する必要があります。 エージェントが予期しないパスで 回答を生成する頻度はどのくらいか？ どのような状況で 安全でない結果が生成されますか？ インテリジェント機能のテストの 課題があります 生成AIで動作する機能の Evaluationフレームワークを 構築した理由です。

Evaluationフレームワークは 柔軟なシステムです 型とプロトコルで 構成されています。 このビデオではインテリジェント機能の 評価に焦点を当て 言語モデルで動作する 機能を対象とします。 しかし確率的なシステムであれば 何でも評価できます 分類器や線形回帰モデルも 含みます。

YadaとRobがフレームワークの いくつかの型をご紹介します。

データの読み込みと 多様なデータセットの構築を説明します。

EvaluatorとMetricを使った 定量的メトリクスの構築 モデルジャッジとスコアディメンションを使った 測定の改良 定性的メトリクスの 作成方法も説明します。

このビデオでは Evaluationを使い始めます。 最初の評価を構築した後 その評価をスケールさせる 方法をご紹介します データと測定を 増やしていきます。 シンプルなAPIを使った 強力なモデルジャッジを構築する方法も学びます。 Evaluationを始めましょう。

YadaとRobはBook Trackerという アプリを構築しています。 2人とも本が好きで ライブラリを管理するアプリを作りたかったのです。 YadaがBookTaggingServiceという 新機能を追加しました。 Book Trackerに書いたレビューに基づいて 書籍を自動タグ付けします。

Xcodeで早速 試してみましょう。

BookTaggingService.swiftに #Playgroundマクロを追加します。

YadaがBook Trackerに追加した 「Pride & Prejudice」のレビューです。 私も大ファンです。 どんなタグが返ってくるか 見てみましょう。

良いスタートですが いくつかのタグを読むと サービスにはまだ 改善が必要なようです。

タグが9つとは 予想以上です。

また書籍名を タグとして入れてほしくありません。

複数単語のタグは UIで問題になります そちらも避けるべきです。

別のレビュー「Dracula」で 試してみましょう。

タグ7つは 期待どおりの数です。 詳しく見てみましょう。

もっと増やしたい動作が いくつかあります。

文学ジャンルを特定し

より大きなライブラリを閲覧するための カテゴリも含まれています。

これでサービスの最初の評価が 完了しました。 期待値のリストを作成し 人間の判断でサービスの パフォーマンスを測定しました。 あらゆる評価はインテリジェント機能が どれだけうまく 期待に応えているかを 測定します。

残念ながら人間の判断は スケールしません。

しかし評価を自動化し スケールさせる方法を開発しました。 import Evaluationsを追加するだけで Evaluationプロトコルを 実装できます。

コードで評価を 構築しましょう。

最初の期待値から 始めましょう サービスが正しい数のタグを 生成することを測定します。

評価を構築・実行するには 5つのステップがあります。 測定するコードを定義します。

次にコードに送る データを定義します。 次に行う測定の内容と 方法を定義します。

測定結果を集計します。 最後に評価を実行する テストを作成します。

まずBookTaggingServiceへの 呼び出しを追加し subject(from:)メソッドの中で 出力を返します。

生成されたタグが 評価の対象です。

次に測定するコードに渡す 入力サンプルを定義します。

ModelSampleを使って 同じレビューをラップします 先ほど#Playgroundで テストしたものです 「Pride & Prejudice」と 「Dracula」です。 期待タグも定義している 点に注目してください。 サービスに求める 理想的なタグです。

Metric型を使って 測定を定義しましょう。 「TagCount」というMetricを追加し サービスが返す生成タグの 数を追跡します。

生成タグを測定するものが 必要です。 Evaluatorはクロージャを受け取り 特定のサンプルに対する サービスの出力が渡されます。 tagsプロパティのcountを使って 生成タグの数を確認できます。

tagsの配列の長さが 3から8の場合 Evaluatorから 合格のMetricを返します。

そうでなければ不合格のMetricを返します。

Evaluatorは1度に 1つのサンプルを処理します。 しかし傾向を測定して パターンを見つけることができます aggregateMetrics(using:)メソッドで 全サンプルにわたって測定できます。

平均回数を 計算しましょう サービスが正しい数のタグを 生成する割合を求めます。 サービスが正しく動作する頻度の 比率が得られます。

最初の評価を作成できました。 次に実行するコードを 書きましょう。

EvaluationはSwift Testingと 統合しています アプリのテストターゲットで 評価を実行できます。 ここでBookTaggingEvaluationを インスタンス化します テストスイートの中で。

評価実行にいくつかのメモを追加し 評価する設定を 追跡できるようにします。 これは後で役立ちます 異なる評価実行を 比較するときに。

次に@Testマクロを使って テスト関数を追加し 新しい@Testトレイト.evaluatesも 追加します。 このトレイトは評価と メモのディクショナリを受け取り @Suiteで先ほど作成したものと 同じように使います。

@Testの中で評価結果バンドルに アクセスできます。 これには全メトリクスが含まれます 評価実行の集計メトリクスも 含まれています。 結果からtagCountメトリクスを 全て取得しましょう その平均値をアサートします。 結果バンドルの aggregateValueメソッドを使います。 #expectマクロで平均値を アサートします。 サービスが80%の確率で 正しい数のタグを生成することを期待します。 なぜ80%なのか？ サービスのパフォーマンスが 80%を下回ったら知りたいからです テストの失敗は 良いシグナルになります。 でも評価中に何が起きたか より深く知りたい場合は？

評価用の新しいテストレポートがあります。 評価の詳細を深く掘り下げて さらに分析できます。

テストを実行して レポートをご説明します。 先ほど#Playgroundで サービスが返した結果から 特に「Pride & Prejudice」で 生成されたタグ数から テストが合格するとは 思えません。

テストは合格しませんでした。 レポートに移動して 何が起きたか確認しましょう。 レポートナビゲータを クリックし テストレポートでEvaluationsを 選択します。 テストスイートの 評価レポートです。 行をダブルクリックして 詳細を確認しましょう。 TagCountメトリクスの合格率が 50%にとどまっています。 全結果テーブルを見ると 「Pride & Prejudice」サンプルが 失敗していることがわかります。 「Dracula」サンプルは 正しい数のタグを生成しています。

テーブルの各行を選択して 詳細を確認できます Xcodeのアシスタントエディタを 使います。 詳細パネルにプロンプトと ModelSampleの各測定値が表示されます。 下部にはモデルからの 完全なレスポンスが表示されます。

少し振り返ってみましょう。 BookTaggingServiceの 評価を構築しました。 評価を実行しましたが 最適化目標を達成できませんでした。

テスト定義を振り返ってみてください。 ここで最適化目標を 定義しました。 機能が期待どおりに 動作するとは 正しい数のタグが80%の確率で 生成された場合を指します。

最適化目標の自動チェックだけでなく 結果をより深く分析して インサイトを収集する必要があります。 具体的には変更点について 考えます 機能のパフォーマンスを 改善できる変更について。

直感があったのでBookTagsという @Generable型を確認しました サービスが生成している型です。 @Guideマクロですでに モデルに追加の指示を与えており tagsプロパティ向けの指示です。

その@Guideに countプロパティを指定できます 範囲を設定できます。 モデルに3から8個のタグのみを 生成するよう指示できます。

興味深い理論です。 変更してみましょう。

評価を再実行して 正しいかどうか確認します。 このプロセスを ヒルクライミングと呼びます。

変更を加えて 評価を再実行しました。 テストは合格し TagCountは 100%合格するようになりました。 しかし気になる点があります 変更後 サービスが常に 8つのタグを生成します。 ふーむ。

Evaluationを設定できたので より多くのサンプルで 測定を増やしていき その奇妙な動作が続くかどうか 確認しましょう。 評価はデータサンプル 2つから始めました。 それでは2つの測定値しか得られず 傾向を抽出するには不十分です。 良い評価では傾向を抽出するために 数千のサンプルが必要です さまざまな方法で機能を 検証するためにも必要です。 データセットの多様性を 考慮すべきです。 例えば サービスに異なるジャンルを 認識させたいです。 すべてのユーザーが詳細なレビューを 書くとは限りません レビューの長さを 変えるべきです。 フィクションとノンフィクションは 異なるカテゴリで閲覧します サンプルはその多様性を 反映すべきです。 最後に異なる形式も 考慮すべきです 小説、短編小説、エッセイなど。

モデルにも難題を 与えてみましょう。 個人的な意見を 混ぜてみてください サービスがレビュー内の個人的意見を どれだけ無視するか測定できます。

機能に自分らしいタグの 書き方を学ばせたい場合は 自分のスタイルを より多く含めることから始めてください サンプルの期待値に 含めましょう。

コードでいくつかの 例を見てみましょう。 「The Secret Garden」のレビューは 最初のレビューとは 大きく異なります 熱心なガーデナーとして 書いたからです。 ここではモデルに 挑戦させます 息子に「Treasure Island」を 読み聞かせる母親の個人的なレビューです。 このレビューには個人的な意見が たくさん含まれています。

このボードゲーム愛好者は 複数の段落が必要でした 中国の古典「Romance of the Three Kingdoms」の レビューを書くために。

このカジュアルな読者は有名な英国の探偵の 相棒について 1文で描写しました。

モデルがこれを解読しようとすれば なかなかの難題になるでしょう。

これらの例を考えるのは 楽しいですが 人間によるデータ作成も スケールしません。 この文章補完ペアを 考えてみてください 機能の出力が 期待される答えと 直接比較されます。 評価を効果的にするには 数千の例が必要です。

Evaluationフレームワークには SampleGeneratorが含まれています。 ModelSamplesの配列を使って 直接呼び出すことができます 選択したモデルを使って 追加のサンプルを合成的に生成します。

より大きなデータセットの 合成方法について詳しくは ModelSampleの高度な 使い方を学ぶには こちらのビデオをご覧ください 「Create robust evaluations for agentic apps」

BookTaggingに戻りましょう。 datasetプロパティを更新して ライブラリのすべての 書籍レビューを含めます 先ほど紹介した4件も含めて。

拡張したデータセットで 評価を再実行すると テストは合格し TagCountの 平均はまだ100%です すべての書籍で 8つのタグが生成されました。 サービスに奇妙な動作があることが わかりました。

期待値を振り返ってみると タグの数が範囲内かどうかを 追跡するEvaluatorを構築しました。 もう少し 改良が必要だと思います。 現在のMetricと Evaluatorsの設定です。 まず「TagTotal」という 新しいMetricを定義し 生成されたタグの 数を記録します。 次にシンプルなEvaluatorを構築し 生成されたtagsの配列の 長さを記録します。 次にスコアリング値を使って 測定を記録します 合格/不合格の値ではなく。

「TagTotal」と「TagCount」メトリクスを使って 範囲への準拠を評価し 生成されたタグの 分布も評価します。 タグ内の単語数をチェックするためにも 同様のパターンを使えます。 ここでは各タグにスペースがあるか確認し あれば不合格のMetricを返します。 文学ジャンルの特定も 同様に簡単です 既知のジャンルセットを 対象とする場合は。 BookTaggingServiceの knownGenresを確認します。 次に生成された各タグと 照合します。

評価がかなり充実してきました。 最初の5つの期待値のうち3つを すでに測定できています。 評価レポートは タグ付けサービスのパフォーマンスを 詳しく示しています。 3つの期待値を 5つの集計メトリクスで追跡します。 タグの分布が確認でき 範囲への準拠と ジャンルタグも確認できます。

ヒルクライミング手法を使って サービスへの指示を 繰り返し改良してきました。 最初の状態はこちらです。

評価を何度か更新して ループを複数回実行した後

指示の各変更を追跡でき 変更を検証するために評価に 追加した期待値で確認できます。

ヒルクライミングの フィードバックループを取り入れ 開発プロセスの中心に 置いたとき それを評価駆動開発と呼びます。

しかしサービスを仕様に合わせる 作業はまだ終わっていません。 タグが有益であることを まだ求めています 書籍に関連しライブラリの 閲覧に役立つことを。

モデルジャッジについて Yadaがご説明します 評価を次のレベルに 引き上げる方法について。 ありがとうRob。 モデルジャッジは定性的メトリクスを スケールして測定する方法です。 構築と改良の方法を ご紹介します。 具体的な例を 見てみましょう。 RobがBook Trackerに書いた 「Alice in Wonderland」のレビューです。

サービスが生成した タグです。

6つのタグで 1語またはハイフン付き ジャンルを特定するタグを含みます。 Robと一緒に構築した すべての定量的メトリクスが合格しました。

でも詳しく見てみましょう。 「Overrated」と「Pretentious」は 本を説明していません 読者がどう感じたかを 表しています。 「Whodunit」は 正しいジャンルでもありません。 「彼が決して答えない謎」から モデルが拾ったのです。 本を理解せずにレビューの 言葉に引きずられたのです。 メトリクスは合格していますが 正しいシグナルが返ってきていません。

しかしここではモデルに 助けを求められると思います。 人間がこれらのタグを読んで どれが機能するか判断できるなら モデルにも同じことが できるかもしれません。

いいですね！ モデルが実際に一部のタグが 役立たないことを把握しました。

モデルに機能が生成した すべてのタグを評価させられると思います 機能が生成したものを！ それがまさにモデルジャッジです。 モデルジャッジは機能の出力を スコアリングするために使う言語モデルです。 主観的な評価を提供し 人間が行うような 判断をしてくれます データセット全体に 一貫して適用されます。 どのように機能するか 説明しましょう。 インテリジェント機能を 動かすモデルです。

BookTaggingServiceは オンデバイスで動作します すべてのユーザー操作で 高速かつローカルである必要があるからです。 機能を評価するジャッジとして 2番目のモデルを使えます。 ジャッジは評価対象のモデルと 少なくとも同等の能力が必要です。 この場合 Private Cloud Computeの より高性能なモデルを使えます。 モデルジャッジには いくつかの重要なコンポーネントがあります。 指示はモデルに書籍レビューが 与えられることを伝え どのように評価するかを示します。 機能入力は評価対象の機能に 与えられるプロンプトで この場合は書籍レビューです。

機能出力は サービスが生成したタグです。 最後にスコアリングガイドが モデルに評価方法を伝え 機能をスコアリングする方法を示します。 Evaluationフレームワークが ほとんどの処理を担当します スコアリングガイドに 集中できます。

まとめると シンプルなモデルジャッジです。 1から4のスケールで 「TagQuality」メトリクスを定義し 各レベルがスコアの 意味を説明します。 偶数の選択肢を設けることで ジャッジがデフォルトで選ぶのを防ぎます 中立的な中間スコアに。 4つのレベルは 十分な区別を提供します 各評価の意味を 薄めることなく。

最後にジャッジモデルとして Private Cloud Computeを指定しました より高性能なEvaluatorが得られます 評価対象のオンデバイスモデルより 優れています。

Evaluationフレームワークでは モデルジャッジは別のEvaluatorです。 定量的Evaluatorと 同じプロトコルに準拠し 同じMetric型を生成します。 1つの評価内で 自由に組み合わせることができます。 では実行してみましょう！

すべてのサンプルが 品質スコア3または4を獲得しました。 「Alice in Wonderland」サンプルに 戻りましょう。 モデルジャッジはこれに 品質スコア3を付けました。

根拠を見ると モデルが「Whodunit」に フラグを立てたことがわかります 「Detective-fiction」が 本に関連しないとして。 しかし他のタグすべてにも フラグを立てることを期待していました 読者の意見を反映しているか 閲覧に役立たないものについて。 モデルジャッジでは 根拠が不可欠です。 ジャッジがそのスコアを付けた理由を 把握できます。 そしてここが重要です 私たちが書いたスケールによれば ジャッジは実際に正しいのです。

すべてのタグがユーザーが 書いた内容に関連しています。 ジャッジは私たちが提供した スコアリングガイドに忠実に従っています。 「関連性があり閲覧に役立つ」には 具体的な意味があったのですが ジャッジは私たちとは 異なる解釈をしました。

自分の代わりに機能の判断を モデルに求める場合 私と同様のスコアを 提供することを期待しました これらのタグをどのように スコアリングするかについて。 モデルジャッジと私たちの間に 不一致がある場合 モデルジャッジを改良できます 私たち自身の判断の代わりに なるまで。

振り返ると最初のモデルジャッジの 問題は 範囲が広すぎたことでした。 2つの異なる質問を していました。 スコアに同意できない場合は 質問を分割できるか 試してみてください。 この場合 関連性と有用性は 実際には2つの異なるメトリクスです。 ScoreDimensionとして 「Relevance」を定義する方法を見てみましょう。

タグが関連性があると言うとき 各タグが書籍の品質を説明することを意味します テーマやトーンを表します 細かい詳細や読者の 個人的な感想ではなく。

それをScoreDimensionの説明として 書くことができます。

これらのタグをスコアリングするには 各タグを確認します。 どのタグが良くてどのタグが 悪いかを特定し 本を意味深く説明しているかどうかに 基づいて。 これをすべてのタグで繰り返します。 この場合 すべてのタグは良好で 1から4のスケールで 4のスコアが得られます。 同じプロセスを繰り返して スコアリングガイドの各スケールを定義します。 これが「Relevance」メトリクスです メトリクス名と説明 そしてモデルジャッジが 使えるスケールです。 同じプロセスで「Usefulness」も 定義できます。 両方のディメンションを ModelJudgeEvaluatorに追加できます。

しかしディメンションだけでは 十分ではありません。 測定対象は伝えますが アプリについての考え方は伝えません。 そのコンテキストがないと Book Trackerのタグを評価するジャッジが 読者の批評を有効な書籍の 説明として扱うかもしれません。

Book Trackerが個人のライブラリであることを 知る方法がありません レビュープラットフォームではなく。 そこでModelJudgePromptが 役立ちます。

これはModelJudgePromptの例です。 ジャッジにタグを評価していることを 伝えられます 指示でパーソナルライブラリアプリ向けの 評価だと伝えます。 evaluationTargetで レスポンスの形式を指定し モデルが比較するための参照として expectedTagsを渡します。

ModelJudgePromptの詳細については ドキュメントをご覧ください。 モデルジャッジが必要なコンテキストを 得たので 評価を再実行しましょう。

Qualityの代わりに 関連性と有用性のスコアが表示されます。 「Alice in Wonderland」書籍サンプルの 評価結果です。

2つの根拠が診断を 分離していることに注目してください。 Relevanceはどの種類のタグが 間違っているかを示します。 Usefulnessは間違ったタグが 閲覧でどう失敗するかを示します。

これらの結果で 明確な改善方針ができました。 BookTaggingServiceの 指示を更新し 評価を再実行して スコアの変化を確認します。 それがRobが説明した フィードバックループです 今度は定性的メトリクスで 動かしています。 いつTestFlightにアップロードするの？ Robちょっと忙しかったんですよ！

アプリの評価に関する いくつかのベストプラクティスをまとめます。 小さく始めましょう。 20から30サンプルの 集中したデータセットが最適です。 モデルにどのように動作してほしいかを考えて アプリの仕様を作ります。 ヒューリスティクスを使って 定量化できる特性を測定します。 経験則のメトリクスは機能を 理解し始めるのに最適です。 経験則として コードで測定できれば 定量的です。

言葉でしか説明できない場合は 定性的メトリクスが必要です ModelJudgeEvaluatorを使います。 モデルジャッジは シンプルから始めましょう。 スコアリングディメンションを定義し 実行して根拠を読みます。 慎重に計画する何時間よりも 1回の実行から多くを学べます。 根拠を使って 次の変更を導きましょう。 スコアがすべて同じなら 質問が広すぎます。 問題を切り分けられない場合は ディメンションを分割します。 ジャッジがアプリを理解しない場合は コンテキストを追加します。 では作業に戻りましょう。 ドキュメントもぜひご確認ください。 サンプルコードもご覧ください。 Evaluationフレームワークを取り上げた 他のビデオもご覧ください 「Improve your prompts by hill climbing with Evaluations」 「Create robust evaluations for agentic apps」 またね！ バイ！