【要約】LLMに数理最適化をやらせて採点する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
バス運行事業者が、コスト最小化と制約遵守を両立する充電計画を立てる際、複雑な変数が絡み合い、手動での最適化が困難であるという課題に直面している。具体的には以下の問題が含まれる。
- ・充電器の台数制限や時間帯別の電気料金変動への対応。
- ・バスの電池残量（SOC）を常に一定以上に保つ運用管理。
- ・便のスケジュールと充電タイミングの同時決定。
- ・手動では不可能な、膨大な組み合わせの探索。
// Approach
筆者は、LLMが数理最適化においてどの程度実用的かを判断するため、以下の2つの手法を比較検証した。
- ・直接解かせる手法: 問題文と時刻表をLLM（Opus）に渡し、スケジュールをJSON形式で直接出力させる。
- ・コードを書かせる手法: 問題文からPySCIPOptを用いた混合整数計画（MIP）の定式化コードを生成させる。
- ・検証プロセス: 生成された解に対し、独立した検証スクリプトを用いて制約違反の有無を厳格に採点する。
// Result
実験の結果、LLMのモデルと手法によって、解の精度と信頼性に顕著な差が出ることが判明した。
- ・直接解き: Opusは最適解を出すこともあるが、実行不可能な計画を混ぜるリスクがある。
- ・コード生成（Sonnet/Opus）: 非常に高い精度で、対称性除去を含む高度な定式化コードを生成した。
- ・コード生成（Haiku）: 制約を欠落させるミスを犯すが、検証結果をフィードバックすれば修正可能である。
- ・結論: LLM単体での利用は不可だが、検証と組み合わせたワークフローには高い可能性がある。
Senior Engineer Insight
> 現場の視点では、LLMを単体でソルバーの代替と見なすのは論外である。特に、制約を欠落させながらも「最適」と偽る挙動は、システムに致命的なバグを混入させる。実用化の鍵は、LLMに「実装」をさせ、独立した検証ロジックで「自動採点」を行う、評価ループを組み込んだワークフローの設計にある。定式化の自動生成と検証の分離こそが、次世代の最適化エンジニアの主戦場となるだろう。