「最初の原則から旅行セールスマン問題をモデリングする」
「旅行セールスマン問題をモデリングするための最初の原則」
オペレーションズリサーチで最もよく知られた経路問題のモデリングにおけるコンセプト第一、数学第二のアプローチ
👁️これは「Pythonにおける観光のためのインテリジェントな意思決定支援システム」プロジェクトのシリーズの2番目の記事です。プロジェクト全体の概要を把握するために、チェックしてみることをお勧めします。TSPのモデリングにのみ興味がある場合でも、この記事は完全な内容です。問題を解決することにも興味がある場合、このシリーズの次の5つの記事はとても役立つものになるでしょう。必要なものと、自分が必要だと思っていなかったものを提供します😉
目次
1. モチベーションと目的
2. データの理解
3. 問題の記述から概念モデルの定義
4. 概念モデルから数学モデルの構築
- 4.1. データをセットとパラメータに配置する
- 4.2. 変数による意思決定のエンコード
- 4.3. 目的の定義
- 4.4. 制約の作成
1. モチベーションと目的
この記事は、スプリント1の記事から続きます。前の記事を読んでいなくても、ここで行うことを理解するためには必要ありませんが、前の記事を読んだ場合はセクション2にジャンプしてください。要するに、旅行計画時に観光客が直面する一般的な問題を整理し、効果的な旅行計画を支援するシステムを構築することに取り組みました。意思決定を迅速化するか、特定の旅行のスケジュールを完全に自動化することができます。このように述べられると、問題は複雑すぎるため、それを分解し、その本質的なバージョンにたどり着き、それを「最小有用問題」と呼びました。最終的に、それは巡回セールスマン問題（TSP）の形になることが分かりました。ここで、たとえば、ことわざのセールスマンが訪れる必要がある「都市」は、私たちのバージョンでは、観光客が訪れたい都市の「興味のある場所」に対応しています。
したがって、キックスタートとして、まずTSPを定義して解決する必要があります。それが終わったら、旅行計画の問題に対するより洗練された一般的な解決策に進むための堅い基盤を持つことになります。このアプローチを選んだのは、この記事シリーズがオペレーションズリサーチ（OR）でのモデリングに対するアジャイルなアプローチも教えるためであり、ここで見つける多くのレッスン、ヒント、トリックは、一般的にORで直面する可能性のあるどのような問題にも適用できるからです。
ビジネスに戻ると、TSPの問題記述があります:
- オートフォーマリゼーションは、非公式と公式の言語のギャップを埋めることができるのでしょうか？MMAと出会ってください：フィールドを革新している多言語および多ドメインのデータセット
- 「大型言語モデルを使用して開発するために知っておくべきすべて」
- 最も困難な部分：分類の目標を定義すること
- 目標: できるだけ少ない距離を歩く
- 要件: 各サイトを1回だけ訪れ、元の出発地点（私たちの場合、ホテル）に戻る
この問題が実際の問題ではなく、それに対する単純な近似であることを知っているので、問題のモデルを構築したいと思います。モデルは洗練されたり、拡張されたり、微調整されたりすることができるため、実際の問題への解決策に到達するためにはそれが必要です。したがって、私たちの目標は、直接的な解決策を見つけるのではなく、何らかのヒューリスティックアルゴリズムを考案するのではなく、問題のモデルを構築することです。このモデルへの理論的な進め方を学ぶと、Pythonでの実装をするために次のスプリントの記事を読む準備が整いました。
2. データの理解
前回のスプリントからおぼえているかたもいらっしゃると思いますが、TSPの基本的な入力は、1日に訪れたいサイトのリストです。このポコンセプトでは、パリを使用するため、次の8つの有名で必見の場所を選びました：
- サクレクール寺院
- ルーブル美術館
- モンマルトル
- ポートドゥスフラン
- 凱旋門
- シャンゼリゼ通り
- ノートルダム大聖堂
- エッフェル塔
問題は最小距離のツアーを見つけることから構成されているため、実際に必要なデータは距離データです。距離データは、サイトとその相対的な地理的位置に依存します。地理的位置から距離データを計算する方法は、このスプリント4で説明します。ただし、今のところモデルの構築が中心なので、それを説明することは本来の焦点から外れるため、それによって逸脱することでしょう。
それでは、今はすべての可能な組み合わせの間の距離が与えられたと仮定してください。これらは次のスプリントでPythonでモデルを実装する際に、CSVファイルとして提供されます。データは次のようになります：
この表を 距離行列 と呼びます。ホテルも行列に含まれていますが、特にポストカードにふさわしいものではありません。ホテルは最終的なツアーに含まれる必要のある別のサイトとしてカウントされます。このMVPでは、事物を単純に保つために対称な距離行列を使用しています。これは、AからBまでの距離がBからAまでの距離と同じであることを意味します。より高度な状況では、これが必ずしも関連度のある程度でない場合があり、この近似は効果的ではありません。
3. 問題の説明から概念モデルを定義する
ここでは、以下のフローチャートで表されるステージにいます：
概念モデルの目的は、問題を単語で述べることですが、標準化された形式で述べることで、「文」と「数学的オブジェクト」のマッピングが明確になるようにすることです。これにより、後の段階（数学的モデルの形成）で問題を明確に理解することができます。次のような概念モデルを仮定することができます：
(知っている)
データ（セットとパラメータ）：
- 訪れるサイトのリスト
- サイト間の距離
(決める必要があるもの)
決定：サイトをどの順序で訪れるか
(以下のように)
目的：総移動距離を最小化する
(以下の条件を満たす)
制約条件：
- すべてのサイトが訪れる
- 各サイトは一度だけ訪れる
- 最後に訪れるサイトは出発地点のサイトである（閉じたツアーを行う）
👁️ 良い実践を追い求め、実際には善行があなたについてくるでしょう
概念モデルは非常にトリビアルで、記事の最初に始めた「単純な」問題文とはあまり変わらないように見えると思ったかもしれません。そして、あなたは正しいです。このような小さな問題では、繰り返しのステップになることがあります。しかし、より大きな問題に対しては、このステージは不可欠であり、概念モデルなしで数学モデルを構築しようとすると、混乱を招くことになります（明確で明確でない要件、悪い定式化、バグのあるコード、実行不可能なモデルなど）。したがって、このステージも今すぐに学び、進む必要があります。簡単なケースでは、マージンの値は非常に低いかもしれませんが、良い習慣に集中し、良い結果が得られるようにしましょう。
4. 概念モデルから数学モデルを構築する
下のグリーン色のワークフローの「ステージ3」に到達しました。「数学モデルステージ」は、おそらくすべてのステージの中で最も難しいステージであり、自然言語が数学に変わる場所です。
この段階では、曖昧さの少しも許されない場所です。
明確に定義された数学モデルは、100回の明確化に値します
ワークフローのこの段階では、TSPの純粋なモデルを構築し、次のフェーズ（「sprint 3」で説明したCSVデータセットからモデルインスタンスを構築します。これにはPythonのヘルプが必要です。
📝 理論復習：「抽象モデル」と「モデルインスタンス」
数学モデル（ORで）は「コンポーネント」で構成されています。これらは、問題の特定の構造を代表するすべての要素（方程式、データなど）です。モデルの真の定義は、これらのコンポーネントがどのように関連しているか、つまり、特定の例ではこれらのコンポーネントがどのような数値を取るかに関係なく、構造にあります。
モデルインスタンスは、「具体的なデータ」を持つ「抽象モデル」の具体的な「具現化」として定義されます。したがって、通常は抽象モデルを定義し、それらを特定のシナリオのデータで補完することで、モデルインスタンスが生成されます。それらのモデルインスタンスを最適化して具体的な結果が得られます。
以下のサブセクションでは、モデルを構成するコンポーネントとそれらの目的について簡単に触れながら、それらを定義します。モデルのコンポーネントの機能を既に知っており、初心者ではない場合は、これらの説明をスキップして直接数学的な定義に移動してもかまいません。
4.1. データをセットとパラメータに格納する
必要なすべてのデータは、図2.1に表示されたデータフレームに存在します。データを制約の作成や目的の作成時にデータフレームから取得するだけの場合、データをそこだけに保持することもできます。実際、多くの人々がそうしていますが、モデルのサイズとともにスケーリングされない悪い習慣です。モデルの複雑さが増すにつれて、このアプローチはますます成長し続けるグルーコード（データフレーム操作に対処するため）を必要とし、最適化モデルの構築により適した他のデータ構造でデータを整理しておくべきです。これらのデータ構造は、モデルの最適化のために使用する「セット」と「パラメータ」です。
💡 異なるニーズを満たすための異なるデータ構造
もしも疑問に思っていたならば、「なぜテーブルに必要なデータがすでにあるのに、なぜセットとパラメータを作成するのか」という短い回答は：それを行うことで、モデルの構築が容易になり、より一般的でエラーの少ないものになります。
「セット」は、問題の主要な「エンティティ」または「要素」を格納するためのモデルコンポーネントであり、「パラメータ」は、それらのエンティティまたはそれらの関係の「数値的なプロパティ」を格納するために使用されます。この例では、サイトが主要な「エンティティ」ですので、それらは「セット」に保存され、サイトの間の距離は関係の「数値的なプロパティ」なので、「パラメータ」として保存されます。実装レベルでは、この分類を行うことは非常に役立ちます。なぜなら、各コンポーネントが異なる機能を果たすためです。これにより、モデルの構築が容易になります：
•集合の機能は、インデックスの便利な格納と操作です。これらのインデックスは、問題の異なる「エンティティ」を表すIDまたは名前であり、制約や目的の作成に便利な方法でパラメータをインデックスするために使用されます。
•パラメータの機能は、「エンティティ」がインデックスされた数値プロパティを便利に格納および操作することです。これらは、制約や目的に実際に表示される数値です。
私たちの概念モデルから、次のようなものがあります：
- 訪れるべきサイトのリスト、これを集合𝕊と定義します：
“𝑖、𝑗でインデックス付けられた”というフレーズは、インデックス𝑖または𝑗がモデルで使用される際に、それらが𝕊のメンバーを表すことを示すために、セットの定義の隣に配置されます。これにより、複数のセットがある場合、そしてしたがって複数のインデックスが使用される場合でも、それぞれのインデックスが何を意味するかを覚えるのが簡単になります。
- 任意の2つのサイト間の距離、これをインデックス付きパラメータ𝐷ᵢⱼと定義します：
このパラメータは単なる「インデックス付き」と呼ばれるだけで、スカラーパラメータ（すなわち、単一の数値）ではなく、数値の2次元行列です。このインデックス付きパラメータから数値を取得するには、𝑖と𝑗の2つのインデックスを指定する必要がありますが、これらのインデックスはセット𝕊から取られます。
𝕊と𝐷ᵢⱼは概念的なモデルに存在する唯一の「データコンポーネント」です。しかし、それはモデルを構築する際に便利な他のセットやパラメータを考え出す能力を制限するべきではありません。
例として、𝐷ᵢⱼのインデックスである𝑖と𝑗が𝕊のメンバーであるが重複することはありません。もし重複している場合、距離はゼロになり、それは自明なデータです。さらに、自分自身から移動することはないので、ペア（𝑖、𝑖）を考慮する必要はありません。そのため、ペア（𝑖、𝑗）が取りうる組み合わせを制限することは有用です。そうすればモデリングが容易になり（エラーも起こりにくくなります）。
そのために、今度は𝕊から派生したもう一つのセット、𝔸を作成します。このセットは異なるサイトのすべてのペア（𝑖、𝑗）を含んでいます。各ペアはサイト𝑖からサイト𝑗への弧を表します。したがって、シンボル𝔸を使用します。
📝 弧は「ネットワーク」の2つのノード間の「直接のリンク」です。弧（𝑖、𝑗）は𝑖から始まり、𝑗で終わるベクトルと考えてください。「リンク」の方向が重要でない（つまり、方向性が関係ない）場合、「エッジ」という言葉が使われます。いつも「無向の弧」と言うのは冗長になります。グラフ理論の人々も効率的であることが好きです。
𝔸の良い特性は、それが𝐷ᵢⱼが定義されるドメインであることです。そして、このようなドメインを明示的に定義することで、Pythonでモデルを実装する際に再利用できるようになります。これは便利です。
- 異なるサイト間の可能な弧のセット：
4.2. 変数による決定のエンコード
モデルを構築して私たちにどの行動を取るべきか教えるために、そしてこの指示された行動はモデルが最適化される前にはわからないため、私たちは取る可能性のあるすべての行動を変数にエンコードする必要があります。
しかし、どのようにそのような潜在的なアクションを定義するのでしょうか？概念モデルから、私たちが必要とする一般的な「決定」とは「サイトを訪れる順番」を意味します。この「順序」とは、ツアーを行う際に私たちがたどる可能なパスのうちの1つを指します。重要な考え方は、パスが個々のノード（すなわちサイト）を結ぶ連続的なアークのシーケンスで構成されることです。したがって、「特定のパスを行うことを決定する」とは、実際には特定のアークのシーケンスを通過することを決定することです。特定のアークを通過するかどうかに関するこれらの「アトミックな決定」は、変数としてエンコードしたい決定です。
「サイトAからサイトBに移動するかどうか」というのは、明らかに「2値の決定」です：移動するか移動しないかのいずれかです。その性質のため、決定変数は2値（つまり、0または1の値を取る）でなければならず、有効なアークに対してのみ定義されます（求められる𝔸が便利です）。数学的な観点からは次のように表されます：
右側の合計が、𝔸の使用によって（𝐷ᵢⱼおよび𝛿ᵢⱼの両方のインデックスのドメイン（インデックスの集合）を表すために）読みやすく（および実装しやすく）なったことに注目してください。
また、目的は善の定義です。最小化したいので、高い値よりも低い値が良いことは明らかです。したがって、最小値が最良の値であることは明らかです。この「最良」の目的に対応する決定変数𝛿ᵢⱼの値は、問題の（最適）解を構成し、最適化プロセスによって見つけられます。
4.4. 制約の作成
概念モデルから以下の要件があることがわかります：
- すべてのサイトを訪れる。
- 各サイトは一度だけ訪れる。
- 最後に訪れるサイトは出発地点となる（閉じたトー）。
要件（1）はすでに要件（2）に含まれていることに気づきます。すなわち、各サイトが一度だけ訪れるため、各サイトが訪れることが含まれ、したがってすべてのサイトが訪れます。したがって、要件（1）のための別個の制約は不要であり、要件（2）をどのように制約としてモデル化するかに焦点を当てます。
「各サイトは一度だけ訪れる」と言うことは、「各サイトに一度だけ入る」「各サイトに一度だけ出る」と言うことと同等です。そして、そのフレーズは次の2つのフレーズを同時に組み合わせることと等しいです：「各サイトに一度だけ入る」かつ「各サイトに一度だけ出る」。それぞれの「フレーズ」を個別にモデル化しましょう：
- 各サイトに一度だけ入る：
全体の式を右から左に読むと便利です。制約がどのようなインデックスの上で定義されているか最初に見ることで、左側の制約定義の意味を解釈することが容易になります。この制約は次のように読み上げます：
すべてのサイト𝑗（すべてのサイト𝕊の集合に属する）に対して、すべての可能なアーク𝛿ᵢⱼ が𝑗に到着する場合、それらの合計は1に等しくなければなりません。つまり、𝑗でただ1つの入力アークのみが発生する必要があります。あるいは、より口語的には：各サイトは他のサイトから1つだけ訪れる必要があります。
- 各サイトに一度だけ出る：
この制約は次のように読みます：
すべてのサイト𝑖（すべてのサイト𝕊の集合に属する）に対して、すべての可能なアーク𝛿ᵢⱼ が𝑖から出発する場合、それらの合計は1に等しくなければなりません。つまり、𝑖でただ1つの出力アークのみが発生する必要があります。あるいは、より口語的には：各サイトは他のサイトに向かって一度だけ出発する必要があります。
最後に、要件（3）だけが残ります。最適なパスが開始地点と同じサイトで終了する必要があること、または同等に、パスが閉じたループである必要があると述べています。最初の一見では、以下のような推論をすることができます：“各サイトが入力および出力が1回ずつになるように制約を作成したため、この結果のパスが閉じる必要があることが理解できます。なぜなら、いかなるサイトも「シンク」（つまり、入力アークが1本しかなく出力アークがないサイト）になることができないため、または「ソース」（つまり、出力アークが1本しかなく入力アークがないサイト）になることができないためです。したがって、前述の2つの制約が、おそらく、終盤の軌跡が閉じたループになるように強制するでしょう。”
その推論は正しいのでしょうか？実験的なアプローチを取りましょう。この推論が正しいと仮定して、現状のモデルを解決しようとしてみましょう。解決策を見ると、それが正しく見えるかどうか、また何かが間違っているかどうかがわかります。結果が間違っている場合（または何らかの意味をなさない場合）、常にロジックを見直すことができます（実生活のプロジェクトではいつも起こります）。実装、解決策、および「実験的検証」は、「次のスプリント」で取り上げられる内容です。そこでは、Pythonモデルが作成され、解決され、検査され、得られた結果に基づいて再構築されます。
したがって、ここで「数学モデルの構成」の段階を仮結論としましょう。次は「コンピューターモデルの実装」です。Pythonを使って旅行セールスマン問題の実装、解決、可視化を行います。
他にも「スプリント」が出てくるので、この旅の仲間になりたいと思う方は、チューニングしてください。そして、1番目の記事の3番目のセクションでプロジェクトのタイムラインを確認して、お好みのスプリントに移動し、そこで行われている作業をフォローしてください。また、コメントで質問したり、フィードバックをいただいたり、LinkedInで連絡したりしても構いません。
お読みいただきありがとうございます。次にお会いしましょう！📈😊
参考文献：
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
