実験とフィットネス評価

PRX の自己進化システムは、提案された変更が実際にエージェントのパフォーマンスを改善するかどうかを測定するために、制御された実験とフィットネス評価を使用します。L1 を超えるすべての進化提案は、恒久的な採用前に A/B 実験を通じてテストされます。

概要

実験システムは以下を提供します:

• A/B テスト -- コントロールとトリートメントのバリアントを並行して実行
• フィットネススコアリング -- 複合スコアでエージェントパフォーマンスを定量化
• 統計的検証 -- 改善がランダムノイズではなく有意であることを確認
• 自動収束 -- 結果が決定的な場合に勝者を昇格し、敗者を廃止

実験のライフサイクル

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌───────────┐
│  作成    │───►│  実行    │───►│  評価    │───►│  収束     │
│          │    │          │    │          │    │           │
│ バリアント│    │ トラフィック│    │ フィット │    │ 昇格      │
│ 定義     │    │ 分割     │    │ ネス比較 │    │ または棄却│
└──────────┘    └──────────┘    └──────────┘    └───────────┘

1. 作成

進化パイプラインが提案を生成すると、実験が作成されます:

• 現在の設定を表すコントロールバリアント
• 提案された変更を表すトリートメントバリアント
• 実験パラメーター: 期間、サンプルサイズ、トラフィック分割

2. 実行

実験中、セッションがバリアントに割り当てられます:

• セッションはトラフィック分割比率に基づいてランダムに割り当て
• 各セッションは完全に 1 つのバリアント下で実行（セッション中の切り替えなし）
• 両バリアントが同じフィットネスメトリクスセットで監視

3. 評価

最小期間またはサンプルサイズに達した後:

• 両バリアントのフィットネススコアが計算
• 統計的有意性がテスト（デフォルト: 95% 信頼度）
• 実用的有意性を測定するために効果サイズが計算

4. 収束

評価結果に基づいて:

• トリートメント勝利 -- 提案された変更がデフォルト設定に昇格
• コントロール勝利 -- 提案された変更が棄却、コントロールが維持
• 判定不能 -- 実験が延長されるか、変更が延期

設定

[self_evolution.experiments]
enabled = true
default_duration_hours = 168       # デフォルト 1 週間
min_sample_size = 100              # バリアントあたりの最小セッション数
traffic_split = 0.5                # コントロールとトリートメントの 50/50 分割
confidence_level = 0.95            # 95% の統計的信頼度が必要
min_effect_size = 0.02             # 受け入れるために最低 2% の改善

[self_evolution.experiments.auto_converge]
enabled = true
check_interval_hours = 24          # 24 時間ごとに結果を評価
max_duration_hours = 720           # 30 日後に収束を強制

設定リファレンス

フィールド	型	デフォルト	説明
enabled	bool	true	実験システムの有効/無効化
default_duration_hours	u64	168	デフォルト実験期間（時間）（1 週間）
min_sample_size	usize	100	評価前のバリアントあたり最小セッション数
traffic_split	f64	0.5	トリートメントバリアントに割り当てるセッションの割合（0.0〜1.0）
confidence_level	f64	0.95	必要な統計的信頼度レベル
min_effect_size	f64	0.02	トリートメントを受け入れるための最小フィットネス改善（割合）
auto_converge.enabled	bool	true	結果が決定的な場合に自動的に昇格/棄却
auto_converge.check_interval_hours	u64	24	実験結果を確認する頻度
auto_converge.max_duration_hours	u64	720	この期間後に収束を強制（デフォルト 30 日）

実験レコード構造

各実験は構造化レコードとして追跡されます:

フィールド	型	説明
experiment_id	String	一意識別子（UUIDv7）
decision_id	String	元の決定へのリンク
layer	Layer	進化レイヤー: L1、L2、または L3
status	Status	running、evaluating、converged、cancelled
created_at	DateTime<Utc>	実験作成日時
converged_at	Option<DateTime<Utc>>	実験終了日時
control	Variant	コントロールバリアントの説明
treatment	Variant	トリートメントバリアントの説明
control_sessions	usize	コントロールに割り当てられたセッション数
treatment_sessions	usize	トリートメントに割り当てられたセッション数
control_fitness	FitnessScore	コントロールバリアントの集約フィットネス
treatment_fitness	FitnessScore	トリートメントバリアントの集約フィットネス
p_value	Option<f64>	統計的有意性（低いほど有意）
winner	Option<String>	"control"、"treatment"、判定不能の場合は null

フィットネス評価

フィットネススコアリングは、複数のディメンションにわたるエージェントパフォーマンスを定量化します。複合フィットネススコアは、実験バリアントの比較と進化の進捗追跡に使用されます。

フィットネスディメンション

ディメンション	重み	説明	測定方法
response_relevance	0.30	ユーザークエリに対するエージェントレスポンスの関連性	LLM による判定スコアリング
task_completion	0.25	タスクが正常に完了した割合	ツール呼び出し成功率
response_latency	0.15	ユーザーメッセージから最初のレスポンストークンまでの時間	パーセンタイルベース（p50、p95）
token_efficiency	0.10	成功タスクあたりの消費トークン数	低いほど良い
memory_precision	0.10	リコールされたメモリの関連性	リコール関連性スコアリング
user_satisfaction	0.10	明示的なユーザーフィードバックシグナル	サムズアップ/ダウン、修正

複合スコア

複合フィットネススコアは重み付き和です:

fitness = sum(dimension_score * dimension_weight)

各ディメンションは重み付け前に 0.0〜1.0 の範囲に正規化されます。複合スコアも 0.0〜1.0 の範囲で、高いほど良いです。

フィットネス設定

[self_evolution.fitness]
evaluation_window_hours = 24       # このウィンドウでメトリクスを集約
min_sessions_for_score = 10        # 有効なスコアには最低 10 セッション必要

[self_evolution.fitness.weights]
response_relevance = 0.30
task_completion = 0.25
response_latency = 0.15
token_efficiency = 0.10
memory_precision = 0.10
user_satisfaction = 0.10

[self_evolution.fitness.thresholds]
minimum_acceptable = 0.50          # これ以下のフィットネスでアラートをトリガー
regression_delta = 0.05            # 5% 以上のフィットネス低下でロールバック

フィットネス設定リファレンス

フィールド	型	デフォルト	説明
evaluation_window_hours	u64	24	フィットネスメトリクスを集約する時間ウィンドウ
min_sessions_for_score	usize	10	有効なスコアを計算するために必要な最小セッション数
weights.*	f64	（上表参照）	各フィットネスディメンションの重み（合計 1.0）
thresholds.minimum_acceptable	f64	0.50	低フィットネスのアラートしきい値
thresholds.regression_delta	f64	0.05	自動ロールバック前の最大フィットネス低下

CLI コマンド

# アクティブな実験を一覧表示
prx evolution experiments --status running

# 特定の実験を表示
prx evolution experiments --id <experiment_id>

# フィットネスの内訳付きで実験結果を表示
prx evolution experiments --id <experiment_id> --details

# 実行中の実験をキャンセル（コントロールに戻す）
prx evolution experiments cancel <experiment_id>

# 現在のフィットネススコアを表示
prx evolution fitness

# 時間経過のフィットネス履歴を表示
prx evolution fitness --history --last 30d

# ディメンション別フィットネスの内訳を表示
prx evolution fitness --breakdown

フィットネス出力の例

Current Fitness Score: 0.74

Dimension            Score   Weight  Contribution
response_relevance   0.82    0.30    0.246
task_completion      0.78    0.25    0.195
response_latency     0.69    0.15    0.104
token_efficiency     0.65    0.10    0.065
memory_precision     0.71    0.10    0.071
user_satisfaction    0.60    0.10    0.060

Trend (last 7 days): +0.03 (improving)

実験の例

L2 プロンプト最適化

典型的な L2 実験はシステムプロンプトの変更をテストします:

• コントロール: 現在のシステムプロンプト（320 トークン）
• トリートメント: 改良されたシステムプロンプト（272 トークン、15% 短縮）
• 仮説: 短いプロンプトがコンテキストウィンドウを解放し、レスポンスの関連性を改善
• 期間: 7 日間、バリアントあたり 100 セッション
• 結果: トリートメントのフィットネス 0.75 vs コントロール 0.72（p = 0.03）、トリートメントが昇格

L3 戦略変更

L3 実験はルーティングポリシーの変更をテストします:

• コントロール: すべてのコーディングタスクを Claude Opus にルーティング
• トリートメント: シンプルなコーディングタスクを Claude Sonnet に、複雑なものを Opus にルーティング
• 仮説: 品質を損なわないコスト効率の良いルーティング
• 期間: 14 日間、バリアントあたり 200 セッション
• 結果: トリートメントのフィットネス 0.73 vs コントロール 0.74（p = 0.42）、判定不能 -- 実験を延長

統計手法

実験システムは以下の統計手法を使用します:

• 二標本 t 検定 -- バリアント間の平均フィットネススコアの比較
• マン・ホイットニー U 検定 -- フィットネス分布が歪んでいる場合のノンパラメトリック代替
• ボンフェローニ補正 -- 複数のフィットネスディメンションが同時に比較される場合
• 逐次分析 -- 結果が明確に有意な場合の早期停止を許可するアルファ消費

制限事項

• 実験には十分なセッション量が必要。低トラフィックのデプロイメントでは有意に達するまで数週間かかる場合があります
• ユーザー満足度シグナルは明示的なフィードバックに依存しており、まばらになる可能性があります
• レスポンス関連性の LLM による判定スコアリングは評価パイプラインにレイテンシとコストを追加します
• 交絡を避けるため、進化レイヤーあたり同時に実行できる実験は 1 つのみ
• フィットネススコアは特定のデプロイメントに対する相対値です。異なる PRX インスタンス間での比較はできません

関連ページ

• 自己進化概要
• 決定ログ -- 実験をトリガーする決定
• 進化パイプライン -- 提案を生成するパイプライン
• 安全性とロールバック -- リグレッション時の自動ロールバック