long forgotten now…

統計学的にモデル評価を行いながら、ヒルクライミングプロセスで性能改善する手法の紹介。カッパ係数、統計学の授業で触れた気がするがまったく覚えてなかった。

カッパ係数

Improve your prompts by hill-climbing with Evaluations

---

0:00 – Introduction

• ヒルクライミングの定義
  • 評価スコアをガイドに知能機能を反復改善するアプローチ
  • サイクル：開発 → 実行 → 分析
• AI 機能の改善に科学的思考を持ち込む考え方

2:42 – BookTracker’s tagging problem

• Book Tracker のタグジェネレーターが抱える問題
  • 重要なテーマを見逃す
  • 本の内容ではなく読者の感想やレビューからの引用をタグとして生成してしまう

5:27 – Analyzing the evaluation results

• データセットにレビューを 2 件追加して評価を実行
• Xcode の評価レポートで生成タグと期待タグを比較
• レポートの活用
  • サンプルごとのスコアとジャッジの rationale を確認
  • 期待するタグを欠いていてもモデルは高いジャッジスコアを付けており、人間評価と乖離があることが判明

8:26 – Drift between judge and human

• モデルジャッジの評価と人間の専門家評価の乖離：「ドリフト」
• 複数サンプルに対しモデル・人間で評価、それぞれの平均値の乖離がドリフト
• ドリフトが存在すると評価スコアを信頼できなくなるため、ジャッジを人間の判断に揃える必要がある
• 評価の乖離を測定する方法：
  • 両者合致する評価の割合をパーセンテージで表記（accuracy)
    • 分布が偏るケースに不適合（e.g. データセットの品質が高く人間がすべてを高く評価しがちな場合、モデルの評価と乖離が生じない）
  • accuracy とは異なる評価方法が必要

9:37 – Measuring drift with Cohen’s kappa

• カッパ係数（Cohen’s kappa）によるアライメント計測で一致度（alignment）を測定
  • 偶然の一致（coincidence）の確率を差し引いた上で正確度を正規化 alignment = (accuracy –  coincidence) / (1 – coincidence)
  • 単純な一致率よりも真のアライメントを反映
• Evaluations の記述に必要な4つの要素：データセット、Evaluation の対象、Evaluation の定義、結果の集計

12:26 – Building a judge alignment evaluation

• BookTagJudgmentCalibration：ジャッジと評者の評価を比較するための専用評価
  • 同じデータセットに対して人間の手動評価とモデルのジャッジの両方のスコアを収集
  • aggregateMetrics でカッパ係数を集計
• ジャッジアライメントのテスト
  • カッパ係数に加えて、平均値と各 dimension ごとの標準偏差も取っておくと、ジャッジスコアの増減を把握するのに役立つ
  • 閾値の目安：0.6 以上が望ましい（統計学的に意義のある一致水準を表すため）
    • #expect(result.aggregateValue(.custom(label: "Relevance: Judge vs Expert")) > 0.6)

15:16 – Analyzing alignment failures

• Evaluate を再実行するとテストに失敗：Assistant Editorでレポートを深掘りするとジャッジが過剰に特定的なタグや的外れなタグを高く評価していると判明
• 原因：良いタグ／悪いタグを分別するためのアプリに関するコンテキストがプロンプトに不足している

17:16 – Comparative evaluation: control vs experimental

• Xcode 27 の比較評価機能
  • 2 つの評価を対照実験として比較し、変更の効果を客観的に検証
  • Control group：ベースとなるプロンプト vs Experimental group：実験的に変更を加えたプロンプト

19:12 – Refining the scoring dimensions

• ScoreDimension の説明文を精緻化
  • Relevance：読者の反応・メタコメンタリー・著者情報をタグにしてはいけないことを明示
  • Usefulness：標準的なジャンル・テーマタグが機能する一方で、造語・キャラクター名・過度に一般的な語は不適と明示
• 説明の改善で両次元のスコアが向上

21:23 – Adding few-shot examples to the judge

• ModelJudgePrompt でジャッジに文脈と worked examples を提供
  • アプリの目的（Shelf：個人書籍管理アプリのタグ生成）を説明
  • Worked examples でレーティングの基準を示す
    • 例 A（Pride and Prejudice）：タグが適切
    • 例 E（Frankenstein）：ジャンル矛盾あり
• Few-shot examples でジャッジの評価を専門家の感覚に近づける

23:38 – Going beyond prompts: adding a tool

• ヒルクライミングの対象はプロンプトだけではない
• BookLookupTool の追加し機能の品質を段階的に高める試み
  • レビューから本のタイトルと著者を検索するツール
  • 登場人物名・舞台設定・引用フレーズなどの手がかりからサンプルブックを特定
• タグ生成サービスにツールを渡すだけで追加文脈を提供
  • BookTaggingService.generateTags(for:tools:) でツールを注入
• 評価スイートでツールなし vs ツールありを同時に比較

27:17 – Next steps

• 科学者のように考える：仮説を立て、変数を制御し、結果を測定する
• 投資する価値のあるプロセス
• 変数の創造性を持つ（プロンプトだけでなくツール・モデル・指示の構造なども対象）
• ドリフトに注意し続ける（ジャッジのアライメントを定期的に確認）

非決定的出力を評価するためのデータセットを大量生成する方法。とにかく数打ちながら期待値を満たすデータをふるいにかけながら集めると言う泥臭い方法だが、Evaluation フレームワークの機能として提供されているのがありがたい。

中でも、データセットにとどまらずツール呼び出しの検証が含まれているのは興味深かった。Foundation Models を使って開発する中でも、特に tool calling には泣かされた。以下の記事のようにツール呼び出しがされているかをログベースで検証したりしていたが、バージョンがあがると期待通りに呼び出されなくなり、プロンプトをどう工夫してもこの問題はついに解決されなかった。

• Foundation Models：Tool calling の複数同時呼び出しができればいいのに
• Foundation Models：ツール呼び出しを並列／直列に反復させる
• Foundation Models：同じツールの呼び出しを反復させる

今年こそは検証に足る挙動が実現していると期待しつつ、こうした評価のしがいがある高度な実装に挑戦してみたい。

Create robust evaluations for agentic apps

---

0:00 – Introduction

• Evaluations フレームワーク（Xcode 27 新機能）の高度な機能を紹介
  • 合成データでデータセットを拡張する
  • ツールコーリングを伴うエージェンティックなワークフローの堅牢な評価構築
• Hill-climbing プロセスにおける、”Develop” と “Evaluate” ステップに着目

2:21 – The dataset problem in BookTracker

• Book Tracker のタグ自動生成機能が抱えるデータセット問題
  • 実際のレビューは書籍・ジャンル・長さ・文体で無限に多様
  • 手作業で書いた 13 サンプルではすべてを捉えられない

3:46 – Generating synthetic data with makeSamples

• makeSamples API でデータセットを合成拡張
  • プロンプト・データセット（ModelSample の配列）・targetCount（シード含む合計サイズ、e.g. 100）を渡す
  • 合成データの生成は反復的なプロセスの中で行われる（データが代表的か確証が得られるまで検証される）
  • 妥当なサンプル数はケースバイケース：量より網羅性

6:27 – Customizing generation with SampleGenerator

• SampleGenerator で、prompt, dataset, targetCount を超えたより細かい設定
  • sessionProvider クロージャでモデルを選択（例：Private Cloud Compute）
  • sessionProvider は実行開始時1度実行され、バッチ間で再利用されるが、コンテキストウィンドウを使い切ると再度呼び出される
    • コンテクストは共有されないので、サンプル生成の期待を指示する sessionProvider へのカスタムインストラクションは、自己完結型にする（前のバッチの状態に依存させない）

8:38 – Sampling strategies

• samplingStrategy でシードサンプルの提示方法を制御
  • .random（デフォルト）：ランダムなサブセット。多様性重視のデータセットに適する
  • .slidingWindow：連続したシードを提示。順序に意味があるデータセットに適する

10:11 – Validating synthetic samples

• validator クロージャで各サンプルを個別に検証
  • レビュー長 ≥ 100 文字
  • タグ数 3〜8 個
  • タグはすべて小文字
• 有効なサンプルは samples、不合格は invalidSamples に分類

13:04 – Comparing evaluation results

• Xcode 27 の Evaluations Report で 2 つの実行結果を比較
  • 13 サンプルと 100 サンプルの結果を比較
  • サンプルが増えたことで、品質スコアが低下し、小さなデータセットではよく見えていた機能の限界が露呈
    • プロンプトやインストラクションによって改善しうる
    • 評価を調整し、実際に何が評価されているかを理解できる
    • データセットがまだ代表的でないかもしれない（増やしたり、エッジケースを網羅）

15:09 – Tool calling and tool evaluations

• ツール評価は「何が返ってきたか」ではなく「どうやって取得したか」を検証
  • 正しいツールを、正しい引数で、正しい順序で呼んでいるか
  • 想定外のツール呼び出しがないか
• デモアプリのツール例
  • searchBooks・getBookDetails・findSimilarBooks

18:54 – Trajectory expectations

• TrajectoryExpectation でセッションのトランスクリプト上のツール呼び出しの種類と順序を検証
• 引数マッチャーの種類
  • .exact：厳密な値の一致
  • .naturalLanguage：意図ベースのファジーマッチング（基準を自然言語で記述）
  • .contains・.hasPrefix・.hasSuffix：部分文字列マッチング
  • .oneOf・.pattern：列挙値・正規表現マッチング
  • .range：数値の範囲チェック
  • .keyOnly：キー名だけ確認（値は問わない）
• 順序付き期待（ordered）と順不同期待（unordered）を組み合わせ可能
• disallowed で呼び出してはいけないツールを指定

21:26 – Building a tool call evaluation

• データセットをそれぞれに対するプロンプト、インストラクション、TrajectoryExpectation  をもって、ToolCallEvaluator でスコア付けをする
  • LanguageModelSession にツールを渡し、構造化されたトランスクリプトをキャプチャ
  • allPass と percentagePass の 2 つのメトリクスを自動計算

22:02 – Synthetic data for tool evaluations

• ModelSample と TrajectoryExpectation はいずれも @Generable のため SampleGenerator を用いて合成生成が可能
• 合成プロンプトの設計ポイント
  • 利用可能なツールの説明（名前・引数）
  • 順序要件（ordered vs unordered の使い分け）
  • 使用すべき引数マッチャーの説明
• バリデーターで品質を担保
  • expectations が定義されているか
  • 少なくとも 1 つのツール期待が含まれているか
  • すべてのツール名が有効なセットに含まれているか