AlphaGoアーキテクチャスキル
決定ポイント
単一評価器 vs カスケード評価器の使い分け
問題の特性:
├── 探索空間が扱いやすい (b^d < 10^9)
│ └── 単一の最良評価器を使用 → 標準最適化
└── 探索空間が扱いにくい (b^d > 10^12)
├── 均一な評価予算が利用可能
│ └── カスケード近似を使用:
│ 1. 高速枝刈り (ポリシーネットワーク) → 狭いビーム
│ 2. 中程度の評価 (バリューネットワーク) → 品質推定
│ 3. 安価な探索 (ロールアウト) → 幅広いカバレッジ
└── 不均一な評価予算
└── 適応的割り当て:
├── 重要な局面 → 高コスト評価
└── ルーチン的な局面 → 安価なヒューリスティック
精度 vs レイテンシ要件の決定木
システム要件:
├── レイテンシ重要 (<1ms応答)
│ ├── 許容誤差大 (>10% エラー許容)
│ │ └── 高速ロールアウトのみ (2µs/評価)
│ └── 許容誤差小 (<5% エラー)
│ └── キャッシュされたポリシーネットワーク + ヒューリスティックによるフォールバック
├── レイテンシ中程度 (1-100ms応答)
│ ├── 高精度が必要
│ │ └── バリューネットワーク (3ms) + ポリシーネットワークによるガイダンス
│ └── 精度と速度のバランス
│ └── 混合評価: λ=0.5 バリュー + ロールアウト
└── レイテンシ許容 (>100ms)
└── 完全カスケード: ポリシー → バリュー → MCTSによるロールアウト
エラーモードの多様性評価
複数の評価器を選択する場合:
├── すべての評価器が類似した障害モードを持つ
│ └── 単一の最良評価器を使用 (多様性の利点なし)
├── 評価器に相補的なエラーがある
│ ├── 高速/ノイズあり + 低速/高精度のペア
│ │ └── λ=0.3-0.7 で混合 (高精度にバイアス)
│ ├── 保守的 + 探索的なペア
│ │ └── λ=0.5 で混合 (均等重み付け)
│ └── 学習済み + 手作りのペア
│ └── 信頼度スコアに基づく動的混合
└── エラー相関が不明
└── 経験的テスト: ホールドアウトセットで性能を測定
障害モード
スキーマ肥大化 (検出: 5層以上の近似層)
症状: 近似層を追加しても効果が逓減する 根本原因: 各層がオーバーヘッドを追加するが、精度向上は比例しない 修正: 計算コストと精度向上をプロファイリングし、ROIの低い層を削除する 検出ルール: 層Nの追加で精度向上が5%未満、かつレイテンシ増加が20%超の場合、スキーマ肥大化が発生している
同期結合 (検出: 高速コンポーネントが待機中)
症状: GPU評価を待機している間、CPU使用率が低下する 根本原因: 高速探索と低速ニューラルネットワーク評価の密結合 修正: 古い値の許容を伴う非同期キューイングを実装する 検出ルール: 高速コンポーネント（探索、ロールアウト）のアイドル時間が50%を超える場合、同期結合が発生している
代理指標への固執 (検出: 指標は改善するが性能は低下)
症状: 手の予測精度は向上するが、勝率は低下する 根本原因: 客観的な成功ではなく、人間の模倣を最適化している 修正: 教師あり学習から、真の目的関数を持つ強化学習へ切り替える 検出ルール: 代理指標と成果指標が10評価以上にわたって逆方向にトレンドしている場合、代理指標への固執が発生している
単一評価器の誤謬 (検出: 「劣る」個別コンポーネントを却下)
症状: バリューネットワークの個別精度が高いため、ロールアウトを破棄する 根本原因: 最良の個別コンポーネントが最良のシステムコンポーネントになると仮定する 修正: 混合性能を経験的にテストする。多様性はしばしば個別の品質に勝る 検出ルール: 組み合わせをテストせずに個別性能でコンポーネントを選択している場合、単一評価器の誤謬が発生している
均一な予算配分 (検出: すべての決定に同じ計算量)
症状: 明らかな手と重要な局面に同じ評価時間を費やす 根本原因: 計算予算を決定の重要度に適応させていない 修正: 局面の不確実性と結果の感度に基づいて適応的割り当てを実装する 検出ルール: 局面間の評価時間の分散が平均の20%未満の場合、均一な配分が発生している
実践例
コードレビューへのカスケード近似の実装
シナリオ: 50～500行の変更があるプルリクエストをレビューするAIシステムを設計。10秒未満の応答時間が必要で、バグの95%を捕捉する必要がある。
ステップ1: 計算制約の分析
- 静的解析: ファイルあたり10ms
- MLバグ検出器: ファイルあたり2s
- 深層意味解析: ファイルあたり30s
- 利用可能な予算: 合計10s
ステップ2: カスケード決定木の適用 網羅的な分析は予算を超えるため、「探索空間が扱いにくい」パスに従う:
- 高速枝刈り層 (静的解析): 複雑性の変更がないファイルを排除
- 中程度評価層 (ML検出器): 残りのファイルのバグ尤度をスコアリング
- 高コスト解析層 (意味解析): 最高スコアのファイルのみを深掘り
ステップ3: 予算配分戦略
- 残りすべてのファイルのML評価に2sを確保
- MLスコアに基づき、残りの8sを意味解析に割り当て
- スコア >0.8のファイル: 各4s (最大2ファイル)
- スコア 0.5-0.8のファイル: 各2s
- スコア <0.5のファイル: MLスコアのみ
ステップ4: 混合評価の実装 「最良」の評価器（意味解析）のみを使う代わりに、ML + 意味スコアを混合:
- ML検出器: 高速、パターンマッチングに優れるが、新種のバグを見逃す
- 意味解析: 低速、複雑な論理エラーを捕捉するが、偽陽性率が高い
- λ=0.6での混合:
final_score = 0.6 * semantic + 0.4 * ml
初心者的アプローチ: すべてに意味解析を実行 → 最初の数ファイルでタイムアウト エキスパートの洞察: カスケードにより、高コストな計算を最も必要な場所にのみ費やし、すべてのファイルが何らかの評価を受けることを保証できる
品質ゲート
[ ] N個の評価器がテスト済み: 異なる速度/精度プロファイルを持つ最低3つの評価器が実装され、ベンチマークされている [ ] エラー相関が測定済み: 評価器がテストセットで <0.7 の相関を持つことを示すペアワイズ相関行列が計算されている [ ] 混合 vs 単一が評価済み: 混合が最良の個別コンポーネントを5%以上上回ることを示す経験的比較が行われている [ ] レイテンシ要件を満たしている: 完全カスケードでの95パーセンタイル応答時間が指定されたしきい値未満 [ ] 精度要件を満たしている: ホールドアウトセットでのエラー率が指定されたしきい値（例: 偽陰性率 <5%）を満たしている [ ] 予算配分がプロファイリング済み: 計算コストの内訳が、予算が決定の重要度に応じて配分されていることを示している [ ] 障害モードのテスト済み: システムが敵対的条件（分布シフト、リソース制約、エッジケース）下でテストされている [ ] 非同期連携が検証済み: 低速コンポーネントが飽和状態でも、高速コンポーネントが80%以上の使用率を維持する [ ] スケーラビリティが検証済み: 公称容量の10倍の負荷をかけた場合でも、性能が緩やかに低下する [ ] 監視計装が完了: メトリクスが代理指標と成果指標の一致、コンポーネント使用率、カスケード効果を追跡する
対象外の境界
このスキルを使用しない場合:
- 探索空間が扱いやすい単純な最適化問題 → 標準最適化を使用
- 単一モデルのトレーニングやチューニング → 深層学習トレーニングを使用
- 1ms未満のレイテンシが必要なリアルタイムシステム → 低レイテンシシステムを使用
- 1つの評価器が明らかに優れており、他の評価器が価値を追加しない問題 → 単一モデルデプロイを使用
- 探索木構造を持たない逐次決定プロセス → 強化学習の基礎を使用
以下の場合、他のスキルに委譲:
- 特定のニューラルネットワークアーキテクチャを実装する必要がある場合 → 深層学習アーキテクチャ
- 分散システムインフラストラクチャを設計する場合 → 分散システム設計
- 個々のコンポーネントの性能を最適化する場合 → 性能最適化
- トレーニングデータの収集とラベル付けを扱う場合 → データエンジニアリング
- 特定の探索アルゴリズムを実装する場合 → 探索アルゴリズム
このスキルが特に焦点を当てるもの: 計算制約下で複数の不完全な評価器を調整するためのアーキテクチャパターン。個々のコンポーネントの実装詳細には焦点を当てない。