EvoX のオープンで疎結合な基盤では、一連の進化プロセスが交換可能な2つの「ブロック」に分解されます:アルゴリズムモジュールは「どのように探索するか」を担い、問題モジュールは「何を評価し、環境がどうフィードバックするか」を担います。両者は明確なインターフェース契約を介して接続され、再利用・交換・移行が可能な進化プロセスを組み上げます。
アルゴリズムモジュール:「どのように探索するか」をカプセル化
- 候補解の生成と個体群の更新:初期化、突然変異、交叉、選択、エリート保持などの進化ロジックは、アルゴリズムモジュールが一括して実装します。
- 探索制御:反復回数、個体群規模、再起動と収束判定基準、オペレータのパラメータ調整は、いずれもアルゴリズム側の決定事項です。
- アルゴリズムモジュールは「候補解が評価される」という抽象的な前提のみに依存し、目的関数の物理的意味や具体的な形式には関知しません。
問題モジュール:「何を評価し、環境がどうフィードバックするか」を定義
- 候補解を比較可能なフィードバックに変換:目的値、適応度、制約違反量、あるいは1回の環境との相互作用の結果。
- 問題の境界と制約を宣言:変数の次元、値の範囲、実行可能領域のルールを示し、アルゴリズムがどこで候補解を生成できるかを知らせます。
- 同一の候補解群に対して一貫した評価を返すことで、異なる個体、異なる世代、異なるアルゴリズム間の横断的な比較が可能になります。
インターフェース契約:候補解バッチ ⇄ 評価結果
アルゴリズムモジュールは問題モジュールに候補解のバッチを提出し、問題モジュールは構造化された評価結果を返します(目的ベクトル、制約違反量、および任意の付加的な診断情報)。アルゴリズムモジュールはこれに基づいて個体群を更新し、次世代へ進みます。この「提出—返却」の1往復が、1世代の進化を構成します。
疎結合がもたらす利点
- 独立した拡張:アルゴリズムの追加や交換は問題定義に影響せず、問題の変更や追加もアルゴリズムモジュールの書き換えを必要としません。
- 組み合わせ可能:同一の問題モジュールに異なる進化アルゴリズムを接続でき、同一のアルゴリズムモジュールを別の問題モジュールに切り替えることもできます。
- 移行可能:インターフェース契約が安定していれば、アルゴリズムと問題はタスクをまたいで再利用・交換・移行できます。
本課のシナリオで特に重要な理由:多目的トレードオフと高コストなフィードバック
本課が扱うのは実世界の工学的問題です——たとえば COMAC の超臨界翼型設計。こうした問題は通常、3つの特徴を同時に備えています:互いにせめぎ合う複数の目的(揚力を高めると抵抗が増え、安定性が低下するなど)、互いに入れ子になった制約(臨界バフェット揚力係数、最大応力が材料の許容値を超えないことなど)、そして高コストで疎なフィードバック(高精度シミュレーション1回の評価コストが非常に高い)です。モジュール分割は、まさにこの3点に対処するために生まれました。
問題モジュール側では、多目的と制約が比較可能な評価結果へ統一的に換算されます:目的ベクトルが各指標を表し、制約違反量が逸脱の度合いを表し、必要に応じて代理モデルを用いて低コストで近似評価を行い、高精度シミュレーションによるフィードバックのボトルネックを緩和します。アルゴリズムモジュール側では、探索は唯一の「最適解」への早期収束を目指すのではなく、多様な候補案の集合を維持し、専門家が揚力・抵抗・安全余量の間で選好に基づく最適化と取捨選択を行えるようにします。
したがって、「候補解バッチ ⇄ 評価結果」という契約は、単一のスカラー適応度だけでなく、目的ベクトルと制約違反量も伝えられるものでなければなりません:多目的トレードオフにはアルゴリズムが非支配比較を行えることが求められ、制約処理にはアルゴリズムが実行可能と実行不可能を区別できることが求められます。契約が不完全であれば、多目的と制約の情報はインターフェースの時点で永続的に失われ、疎結合がもたらす再利用と移行の能力も失われてしまいます。
