OMMXとは？#
OMMX（Open Mathematical prograMming eXchange、オミキス）を使うと、何を解きたいかとどう解くかを分けて扱えます。ソルバーに渡す定式化を変えても、得られた候補は元の問題の制約と目的関数に照らして評価できます。結果を元の条件に結びつけて理解することが、要求や入力データの見直しにつながります。 共通の意味と責務を保ちながら、扱える宣言・解析・変換を随時追加していく体系です。
モデラー・OMMX・Adapterの責務#
モデラーは利用者の要件を問題として記述します。OMMXは共通のデータ形式とPython・RustのSDKを提供し、問題の変換と候補の評価を担います。Adapterの責務は、この共通表現をソルバーやサンプラーへ意味を保って接続し、候補や終了報告を実際に解いた問題に結びつけて解釈することです。共通表現に対して実装した変換は、複数のモデラーや解法から再利用できます。
この責務の分担は、OMMXとしての契約です。個々の実装の対応範囲にかかわらず、Adapterにはこの契約を求めます。利用できる機能や対応状況は機能・Adapterごとに異なるため、詳細はAPI Referenceで確認してください。
OMMXを使う理由#
共通の問題表現を使うことで、次のように処理を分担できます。
利用者の目的 |
OMMXが担う処理 |
利用者が決めること |
|---|---|---|
定式化やソルバーを変えて試す |
対応する特殊制約の変換や整数の符号化、Adapterを介した受け渡し |
使う解法、許可する変換、求解の設定 |
手元の候補が使えるか確かめる |
問題の定義域・制約・目的関数に基づく評価。対応する変換では、保持した情報による元の変数値の復元 |
業務上必要な条件のモデル化と、得られた候補を採用する判断 |
結果から要求や入力データを見直す |
ラベルによる対象の識別と、特殊制約から生成した通常制約の来歴の保持 |
元の宣言・データとの対応をモデラーやアプリケーションで管理し、何を見直すか決める |
問題や結果を別の処理へ渡す |
共通形式での読み書き、Artifactによる保存・共有、Experimentによる条件と結果の記録 |
何を記録し、何と比較するか |
問題はモデラーや保存済みファイルから受け取ることも、SDKで作ることもできます。同じモデル構造に異なる入力値を当てはめる場合は、ParametricInstanceでケースごとにパラメータを指定できます。
モデルが満たすべき要件は、AIをモデル作成に使う場合も利用者が決めます。自作アルゴリズムの候補を確かめたいときは、SDKの評価機能だけでも使えます。
手元の候補を評価する#
ある生産ラインは通常運転では毎時100個まで、低速運転では毎時60個まで生産できます。低速運転で毎時65個を生産する計画は、ソルバーが返した候補でも、担当者が作った計画でも、この上限に違反します。OMMXはどちらも同じ問題に照らして評価できます。候補を評価して結果を判断するでは、この条件を満たすこと、モデル全体で実行可能なこと、最適性が示されることを区別します。さらに、候補が返らない場合の結論を読み、結果を元の条件やデータへ対応づけて見直す考え方を説明します。候補を評価して結果を取り出す実行例はSolutionのReferenceにあります。
問題の意味と、解くための表現を分ける#
低速運転時の上限は、二値変数が指定された値のときに条件を課す Indicator制約 で表せます。この線形のIndicator制約をPySCIPOpt AdapterからSCIPに直接渡すことも、生産量の既知の上限を使って通常の不等式に変換し、同じSCIPで試すこともできます。どちらを選んでも、生産条件は一度記述すれば済みます。問題を変換して解法へ渡すでは、この不等式を導き、別の変換を選ぶときに確認すべき保証を説明します。
この体系では、扱う宣言や処理を固定せず、共通の意味と責務の上に新しい構成要素を追加します。条件を表す特殊制約に加え、割当費用や巡回路の長さのような評価、複数の評価軸を組み合わせる目的も、構造を保持してから解法向けに具体化するという考え方で扱います。例えば費用・遅延・欠品数を目的として扱うなら、個々の評価軸と、重み付き和や辞書式の優先順位を選ぶ方針を分けます。顧客が指定した優先条件は、その具体化が満たすべき要求です。
この分担では、自然言語の意図を利用者・AI・モデラーが確認し、確定した宣言から数式へ展開する処理をOMMXの共通処理が担います。JijModelingなどのモデラーから使える宣言と、それを具体化する変換を揃えて追加することで、案件ごとに展開方法を組み立て直す負担を減らしていきます。
共通の表現の上に、解析と変換の技術を蓄積する#
前処理や変換の技術を共通の表現に対して実装すれば、モデラーや解法ごとに同じ処理を作り直さずに活用できます。新しい解法も、問題の受け取り方と結果の返し方を接続することで、蓄積された共通処理を利用できます。このため、OMMXではデータの交換と、それに対する共通処理の両方を整備します。
問題の性質を調べる解析と、問題を書き換える変換を分け、それぞれの適用条件、情報の依存関係、保存する保証を明らかにすることが、この体系を拡張する基礎です。新しい処理も同じ契約に沿って加え、既存の処理と組み合わせて使えるようにします。利用者が必要な保証を選び、その保証に沿った処理の組合せを共通基盤に任せることで、人が組合せの正しさを個別に追う負担を減らす設計です。詳しくは解析・変換・保証の関係を参照してください。
具体的な宣言や処理の対応範囲は、この体系の中で随時広がります。利用できる機能とその条件はAPI Referenceで確認してください。
目的に合わせて読み始める#
この導入ではOMMXを採用する理由を説明しました。Bookの残りの3章は、それぞれの章から直接読み始められます。
判断したいこと |
Bookの章 |
|---|---|
このモデルをソルバーに直接渡せるか。定式化を変えるなら、どの性質を保つ必要があるか |
|
候補の有無やソルバーの報告から何が言えるか。結果を元の要求やデータへどう戻すか |
|
別の人が結果を調べたり、試行を再実行したりするには、何を残す必要があるか |
実行環境を用意するには、SDKと必要なAdapterのインストールから始めます。題材を通して試したい場合は、巡回セールスマン問題の経路をサンプリングして描画する例があります。
個々の操作や対応範囲はPython API Referenceから調べられます。3.0.0 stable releaseまでは、API Referenceはmainを説明します。インストール手順には、最新の公開prereleaseとmainからの導入方法を併記しています。例えば、候補の値と制約の違反を調べる例はSolution、ファイルから候補を読む例はload_solution()にあります。Adapterの一覧から、各ソルバーの入力条件と求解例に進めます。自分の解法を接続する場合はSolverAdapterまたはSamplerAdapterを参照してください。
探索の進捗や終了理由を調べる手順は、SCIPとHiGHSの診断情報のReferenceにあります。
保存したデータを扱うには、手元のArtifactを調べる手順やレジストリで共有する手順に進みます。外部ツールを接続するには、エージェントプラグインの導入やOpenTelemetryコレクターへの送信設定を参照してください。
データの交換と共有を支える仕組み#
問題や解に共通の意味を与えることで、ソフトウェア間だけでなく、担当者間でも同じ問題と結果を扱えます。OMMXは次の要素でその受け渡しを支えます。
要素 |
役割 |
|---|---|
OMMX Message |
問題や解を表す、言語・OSに依存しないデータ形式 |
OMMX SDK |
問題と結果の構築・評価・変換・読み書き |
OMMX Adapter |
OMMXと個々のソルバーの入力・出力の接続と、解いた問題に対する報告の解釈 |
OMMX Artifact |
問題・結果・添付データをメタデータ付きで保存・共有するパッケージ |
MessageのスキーマはProtocol Buffersで定義され、PythonとRustのSDKを提供しています。Pythonのユーザーコードでは from ommx import Instance のように公開APIを使います。現行のwire formatの定義はスキーマのソース、v1の生成済み一覧はOMMX v1 Message Schemaを参照してください。
共通の問題・結果表現を介して、ソフトウェアを接続する。#
Artifactには、問題と結果に加えて「何を、どの設定で解いたか」を記録できます。OCI Artifactを利用しているため、GitHub Container Registryなど既存のregistryで配布することもできます。OMMXはこの仕組みでMIPLIBやQPLIBの問題を公開しています。形式を直接読み書きするツール向けのmanifest・layer・media typeの定義は、Artifact形式仕様を参照してください。