LLMize: LLM-Based Numerical Optimization Framework

LLMize: A Framework for Large Language Model-Based Numerical Optimization

M. Rizki Oktavian — Blue Wave AI Labs / Purdue University | arXiv:2601.00874 | Dec 2025 | OSS (MIT)

🎯 自然言語でドメイン知識を注入できるLLMブラックボックス最適化FWで創薬分子設計を自動化

① なぜLLMベース最適化か

手法	ドメイン知識注入	数式化不要	ブラックボックス対応
勾配法	制約関数	❌	❌ 勾配必要
ベイズ最適化	事前分布設計	⚠️	✓
GA/SA	カスタム演算子	⚠️	✓
LLMize	自然言語のまま	✅	✅

SAR知見・合成可能性ルール・Lipinskiルールを自然言語でそのまま最適化ループに注入

② 3つの最適化戦略

OPRO (Optimization by PROmpting)

プロンプト = 問題記述 + ドメイン知識 + 評価履歴 H_t
→ LLM → 候補解 × B件 → f(x) 評価
→ H_{t+1} 更新 → 次反復 (T回)

HLMEA (Hybrid LLM-EA)
LLMに「進化的アルゴリズムとして動作」を指示。エリート上位K件をプロンプト履歴で保持。crossover/mutation率を自然言語で指定 → LLMがハイパーヒューリスティックとして機能

HLMSA (Hybrid LLM-SA): 温度T_currentをプロンプトに記述「高温=多様性、低温=精錬」→ LLMが探索-活用バランスを自律調整。局所最適脱出に有効

③ フレームワーク設計

pip install llmize

Optimizer(model=..., problem_description=..., objective_fn=...)
↓
optimizer.run(strategy="opro" | "hlmea" | "hlmsa")
↓
result.best_solution, result.history

モデル非依存（GPT-4, Claude, Ollama等）
バッチ評価・コールバック終了条件サポート
適応的パラメータ制御
MIT ライセンス / OSS

④ 評価ベンチマーク

問題	LLMize	古典ソルバー
凸最適化	△ 収束遅	✅ 最速
線形計画	△	✅ 厳密解
TSP	○ 近似	✅ 厳密法
NNハイパーパラメータ	○	○ BO等
核燃料格子設計	✅ GA同等	—

ドメイン知識注入が有効な複雑問題でGAと同等 → 創薬最適化に期待

⑤ 自然言語制約の威力

分子設計への適用例（プロンプト断片）:

        "Optimize SMILES for binding to target.

        - MW 300-500 Da (Lipinski)

        - Prefer H-bond donors near Asp123

        - Avoid Michael acceptors

        - Max 5 rotatable bonds

        - SA score < 3.0 for synthesizability"

→ これだけでSAR知見を反映した分子候補を生成

⑥ ケムインフォパイプラインへの統合（lib/molgen, lib/docking）

🧪 自然言語誘導型分子最適化
UniDockRunner + QED/SA を objective_fn に。LipinskiルールやSAR知見をプロンプトで直接注入。MolgenYamlのscorerをwrapするだけで統合完了。実装コスト：極めて低。

⚙️ ドッキングパラメータ自動チューニング
UniDockRunnerの格子サイズ・exhaust等のパラメータをLLMizeで最適化。既知活性リガンドのenrichment率をobjective_fnとしてHLMEAで探索。タンパク質クラスのヒューリスティックを自然言語で補完。

📊 MMGBSA設定最適化
MMGBSAEngineの計算設定をHLMEAで最適化。実験IC50との相関(Spearman r)を目的関数に。「非極性系はSA項を重視せよ」等の知見をプロンプトで伝達。

🔄 既存パイプラインとの統合容易性
objective_fn を定義するだけ。GAやベイズ最適化に比べてコード量が大幅に少ない。LLMモデルの変更（GPT→Claude）がパラメータ1つで可能。

⑦ 限界・注意点

勾配利用可能な単純問題では古典ソルバーに明確に劣る

API コスト：評価関数が安価な問題ではコスト非効率

小規模LLMでは性能が大幅低下（GPT-4o/Claude Sonnet以上推奨）

temperature=0推奨だが多様性が犠牲になるトレードオフ

💡 評価関数がMD/FEP等の高コスト計算の場合はAPI費用対効果が高い。
🚀 github.com/rizkiokt/llmize | pip install llmize