OptaPlanner VRP Web の例を取り上げて、自分のニーズに合わせてカスタマイズしました。以下のシナリオを除いて、正常に動作しています。
利用可能な車両の数: 2.
各車両の定員は 6 です.
そして、顧客の需要は 7.
上記のシナリオでは、OptaPlanner は問題を解決できません。同じ顧客の場所に 2 台の車両を配置する必要があると思いますが、期待どおりに機能していません。
OptaPlanner ルールを構成して機能させる方法がわかりません。
OptaPlanner VRP Web の例を取り上げて、自分のニーズに合わせてカスタマイズしました。以下のシナリオを除いて、正常に動作しています。
利用可能な車両の数: 2.
各車両の定員は 6 です.
そして、顧客の需要は 7.
上記のシナリオでは、OptaPlanner は問題を解決できません。同じ顧客の場所に 2 台の車両を配置する必要があると思いますが、期待どおりに機能していません。
OptaPlanner ルールを構成して機能させる方法がわかりません。
修正する 1 つの方法は、顧客を需要 7 で分割することです。
可能な限り、同じ車両が同じ場所のすべての顧客を訪問することがわかります。より優れた設計のために、 (場所ごとに 1 つだけ) と(顧客の個別の要求ごとに 1 つ) にリファクタリングCustomer
することもできます。Customer
CustomerPart
元の要件では、デマンドを 2 台の車両に分割できないことに注意してください (制約ルールのためではなく、ドメイン設計のため)。そのため、要件を解決するために元の実装を使用すると、実行可能で潜在的に最適な多くのソリューションが自然に除外されます。
分割が多ければ多いほど、新しい実現可能で潜在的に新しい最適なソリューションが開かれます。もちろん、顧客ごとの需要を分割すればするほど、検索スペースが増えます。そして、それは大幅に増加します。その顧客を需要 1 の 7 人の顧客に置き換える (そしてすべての顧客に対してそれを行う) ことは完璧ですが、大きなスケーラビリティの問題に悩まされます。
実際には、最小の車両の容量の半分 (またはその容量の 3 分の 1) を超えるすべての需要を分割しますが、それ以上は分割しません。OptaPlanner Benchmarker を使用して、(推測ではなく) 分割制限パラメーターが変更されたときの結果の品質とデータセットのスケーラビリティを測定して、微調整できるようにします。(ああ、これらのベンチマークを行うことになった場合は、ここで最高のパラメーター値を共有してください。)