候補を評価して結果を判断する

ソルバーやサンプラーの出力、あるいは人が用意した計画など、すでに候補が手元にある場合にもOMMXを使えます。共通の問題表現に照らして、どの条件を満たすか、目的値はいくつか、ほかの指標はどうなるかを評価できます。OMMX Adapterで求解することは前提ではありません。

結果を比較する前に、どの問題に対する評価かを揃えます。 ソルバーに渡した問題では許される候補でも、準備の途中で外した条件には違反することがあります。変数の値を復元すること、実行可能性を確認すること、最適性を示すことは、それぞれ別の問いです。

求解しても候補が返らない場合には、終了理由から何が分かったかを読みます。候補や診断が指す条件を元の要求・入力データへ対応づけることで、次に計画、要件、データのどこを見直すか判断できます。

解く問題と、検査する条件を分ける

ある生産ラインは通常運転では毎時100個まで、低速運転では毎時60個まで生産できます。担当者が毎時65個の計画を提案したとします。通常運転ならこの生産上限を満たし、低速運転なら上限を5個超えます。探索時にソルバーが低速運転の上限を無視できたとしても、元の要件での判定は同じです。候補を判断するには生産量と運転モードの両方が必要です。

ソルバーの出力にも担当者が作った計画にも、同じ検査を使えます。この上限を満たしたら、ほかの制約と変数の定義域も確認します。すべてを満たす実行可能な計画でも、別の計画のほうがよい目的値を達成する可能性があります。

OMMXは、ソルバーに課す条件から外した制約も保持できます。現在課している制約を active、外したあとも保持する制約を removed と呼びます。そのため、activeな条件を満たすかと、保持した条件をすべて満たすかを区別して評価できます。整数性やboundといった変数の定義域は、どちらの判定でも考慮します。

特殊制約を同じ条件を表す通常制約へ置き換えた場合や、制約を目的関数のpenalty項へ変えた場合にも、元の制約をremovedとして保持します。removedは変更の記録であり、それがあることだけでは元の問題を保存する変換かどうかは分かりません。特に有限のpenalty weightでは、元の条件に違反する候補が選ばれる可能性があります。

返された値と保持された条件を解釈するには、その求解で使った問題を表す変換済みInstanceを使います。ただし、その評価を元の問題についての判定とみなす前に、変換の保証を確認してください。情報が保持されていること自体は、すべての変更が元の実行可能領域や最適解を保存した証明にはなりません。

実行可能性の判定と違反の調べ方はSolutionのReference、保持するデータとactiveな制約との関係はremoved constraintsのReferenceにまとめています。

復元した値と、補った値を区別する

準備の途中で変数を固定したり、別の変数の式で表したりすると、ソルバーが選ぶ値を減らせます。OMMXは記録された固定値や式を使って、省略された値を復元します。例えば変換によって \(y=2z\) が記録されていれば、返された \(z=1\) から \(y=2\) を得られます。ただし、この計算ができることだけでは、元の条件をすべて満たすことや、元の候補をすべて表現できることは分かりません。

現在の問題に無関係な変数は、これとは異なります。値を省略した場合、OMMXは既定値で補うことができます。その値はソルバーが選んだ値でも、元の候補から復元した値でもありません。保持した制約や報告用指標には影響する場合があるため、特定の候補について判断したいときは、その候補の値を渡します。

現在の問題に必要な値が欠けている場合に、任意の既定値で埋めることはありません。役割の分類、既定値の規則、整合性の検査、実行できる例は値の復元・補完のReferenceにあります。

報告目的値とソルバーの状態を、その文脈で読む

ソルバー向けの目的関数と、利用者へ報告する目的関数は異なることがあります。\(3x\) の最大化は \(-3x\) の最小化で表せるため、同じ \(x=1\) に対してソルバー向けの値は \(-3\)、元の値は \(3\) です。出力用の目的関数を保持している場合、OMMXは結果にその目的値を返します。正確な動作は出力目的関数のReferenceを参照してください。

Penalty化した問題でも、報告目的値にはソルバーが使うpenaltyが含まれない場合があります。報告目的値がよいことだけでは、実行可能性は分かりません。条件を満たすかは別に確認します。

例えば、Binary変数 \(x\) を最小化する問題の制約 \(x=1\) を、penalty項 \(0.5(x-1)^2\) に置き換えます。\(x=0\) ではソルバー向けの目的値が \(0.5\)、元の目的値が \(0\) になり、\(x=1\) ではどちらも \(1\) です。Penalty化した問題は、元の制約に違反する候補を選びます。報告目的値だけの比較や、それをソルバーのpenalty込みの値とみなす読み方では、この違いを捉えられません。

候補の評価だけでは最適性も分かりません。時間制限で終了したソルバーが実行可能な候補を返すことも、多数のサンプルから選んだ候補が観測した範囲で最良でも大域的には最適でないこともあります。ソルバーの最適性の主張は実際に解いた問題に対するものであり、別の表現へ引き継ぐには変換の保証が必要です。最適性の引継ぎのReferenceで扱います。

Backendの診断情報は、なぜ終了したか、探索がどこまで進んだかを読むためのものです。boundはソルバーが解いた問題の最適値の範囲を限定し、gapはbackendの定義に従った隔たりを示します。符号・スケール・penaltyが変わる場合、どちらも報告目的値と同じ尺度とは限りません。

例えば最小化問題で、見つかった最良の実行可能な候補の目的値が120、証明された下界が100なら、最適値は100から120の間にあります。前者がprimal bound、後者がdual boundで、最大化では上下の役割が逆になります。進捗グラフでは、探索によってこの範囲がどう狭まるかを読みます。両者が一致する前に探索が終了することも、候補が見つかるまで有限なboundが得られないこともあります。報告される相対gapはbackendの定義に従うため、単なる区間の幅とは異なります。

収集方法、各fieldの意味、実行例はSCIPとHiGHSの診断情報のReferenceにあります。SCIPのReferenceには、実際の求解で上下界が近づき、gapが縮まる様子を示す図があります。途中の記録は観測値なので、最終的な結果は終了報告で確認します。

候補が返らない場合に、何が分かったかを読む

時間制限まで候補が見つからなかった場合と、条件を満たす候補が存在しないと結論された場合では、次の判断が異なります。まず、ソルバーが実際に解いた問題と終了報告を確認します。

報告	その問題について読み取れること
候補が返らなかった	候補を取得できなかった。実行不能の証明ではない
実行不能	実行可能解が存在しないと結論された
非有界	実行可能な範囲で目的値を限りなく改善できると結論された
実行不能または非有界	いずれかであると報告されたが、両者を区別できていない

unknownや時間制限は、それだけでは実行不能・非有界という数学的な結論になりません。時間制限で候補が得られる場合もあります。入力の変換やソルバー実行の失敗も、問題の実行不能性とは区別します。例外の意味はNoSolutionReturned、InfeasibleDetected、UnboundedDetected、InfeasibleOrUnboundedDetectedのReferenceにあります。

OMMXでは、Adapterに、backendの報告を実際に解いた入力に結びつけて解釈する責務を求めます。候補の値の対応づけと評価も同じ問題に基づき、評価だけから最適性を主張してはなりません。これらはAdapterが守る契約です。報告をOMMXの結果へ対応づけること自体は、証明書を独立に検証することではありません。対応する終了報告や診断情報の範囲はAdapterごとに異なるため、詳細は各AdapterのAPI Referenceを参照してください。

元の問題へ結論を引き継げるかは、変換が何を保つかで決まります。例えば、生産量を65個に固定し、低速運転を指定した部分問題は、上限60個という条件と両立しません。それでも、生産量や運転モードを選べる元の問題まで実行不能とは言えません。同様に「費用を一定値以下にする」という条件を追加した問題の実行不能は、その条件を追加する前の問題の実行不能を意味しません。

同じ基準で候補を比較する

共通の評価によって異なる解法の結果を比較しやすくなりますが、比較する基準を揃える必要があります。

• 問題の版と数値条件、および候補の値と変数の対応。

• 実行可能性を判定する制約・変数の定義域・数値的な許容誤差。

• 順位付けに使う目的関数、最大化・最小化の向き、penaltyの扱い。

SampleSetは、与えた候補の評価と選択を支援します。その最良候補は、選んだ基準でその候補集合の中で最良という意味です。解法自体を比較する場合は、時間制限などの実行条件も別に考慮します。Adapter比較のReferenceには、同じモデルをHiGHSとSCIPで解き、結果を比較して変数値を図示する完全な使用例があります。

業務上の判断には、目的値以外のコストや距離などが必要なこともあります。名前付き関数なら、最適化する対象を変えずに指標を評価できます。名前による結果抽出では、業務上のラベルを使って値を取り出せます。結果をアプリケーションへ戻すための機能であり、実行可能性や最適性の保証を追加するものではありません。

結果を元の要求と入力データへ戻す

低速運転時の上限を通常の不等式へ変換したとします。生産量を \(q\)、低速運転なら1となる変数を \(r\) とすると、通常時の上限100個を使って \(q\leq100-40r\) と表せます。候補 \(q=65, r=1\) はこの不等式に違反します。生成された制約の来歴をたどると、元の「低速運転時は60個まで」というIndicator制約に対応することが分かります。

OMMXでは、ラベルで数学的対象を識別し、来歴（Provenance）で生成された通常制約から元の特殊制約へたどれます。Solutionの制約行にはラベル、来歴、除去理由、評価情報が保持されます。生成元と生成先の調べ方は、特殊制約の変換と来歴参照の例にあります。

業務のどの宣言や入力データに対応するかは、JijModelingなどのモデラーやアプリケーションが管理する対応と組み合わせて読みます。例えば、制約のラベルから対象の生産ラインや時間帯を特定し、計画の数量・運転モード、設備能力の入力値、要求した納期などを確認します。そのうえで、計画を変えるのか、入力の誤りを直すのか、要求を見直すのかを利用者が判断します。

由来をたどれること、その候補の違反を確認すること、要求全体が両立しないと判定することは別です。この候補の上限違反と来歴だけでは、モデル全体の実行不能性や競合原因は分かりません。利用できる来歴情報や変換ごとの保持範囲は、各操作のAPI Referenceで確認してください。

新しい宣言や変換を追加するときも、結果を元の要求へ戻す責務は変わりません。OMMXが担う数学的対象・変換の対応と、モデラーやアプリケーションが担う業務上の宣言・データの対応をつなげられるように設計します。複数の変換を組み合わせる場合にも、この対応を引き継ぐことが、結果の意味を保ちながら体系を広げるための契約です。