Dua tahun terakhir, LLM telah mengalami kemajuan pesat dalam bidang 'bahasa alami ke model matematika' dan 'bahasa alami ke kode solver'. Model dapat memahami soal, menulis formula MIP, memanggil Gurobi atau solver lainnya, dan tampaknya telah memiliki kemampuan pemodelan optimasi awal. Namun, pada masalah berskala industri yang sebenarnya, ini masih jauh dari cukup.
Masalah sesungguhnya bukanlah menerjemahkan setiap kendala ke dalam ekspresi matematika, tetapi merancang seperangkat algoritma yang dapat berjalan, akurat, dan cepat pada instance besar. Bahkan jika sebuah model MIP sepenuhnya benar, saat diberikan ke solver umum, mungkin tidak dapat menghasilkan solusi berkualitas tinggi yang terbukti dalam waktu satu jam. Inilah sebabnya mengapa insinyur OR di dunia nyata masih perlu menulis algoritma dekomposisi, column generation, Benders, local search, metaheuristik, dan algoritma hibrida perencanaan matematika-heuristik.
Baru-baru ini, peneliti dari MIT dan lembaga lainnya mengusulkan FrontierOR: sebuah benchmark evaluasi LLM yang berfokus pada kemampuan desain algoritma optimasi skala besar.
Berbeda dengan benchmark tradisional yang hanya menguji 'kemampuan pemodelan' atau 'kemampuan memanggil solver', FrontierOR berfokus pada apakah LLM dapat, seperti peneliti dan insinyur OR sejati, merancang algoritma yang dapat diskalakan, berkualitas tinggi, dan efisien berdasarkan struktur masalah yang kompleks.

Tautan makalah: arxiv.org/abs/2605.25246
Halaman proyek: frontieror.vercel.app
Tautan kode: github.com/Minw913/FrontierOR
Tautan dataset: SmartOR/FrontierOR
Pertanyaan inti FrontierOR adalah: Apakah model besar terkuat saat ini, benar-benar dapat mulai dari masalah nyata, dan merancang secara mandiri algoritma yang efisien dan kompetitif? Dapatkah ia tidak hanya 'memanggil solver', tetapi seperti pakar OR, memilih strategi dekomposisi, heuristik, pencarian, dan hibrida berdasarkan struktur masalah?
Signifikansi pekerjaan ini terletak pada pergeseran fokus evaluasi LLM-for-OR dari 'bisa menulis model' ke 'bisa merancang algoritma'. Ini juga merupakan ambang batas yang harus dilalui model besar untuk menuju sistem pengambilan keputusan industri nyata.
Latar Belakang Penelitian
Sudah ada beberapa benchmark yang fokus pada kemampuan pemodelan LLM dalam masalah optimasi, misalnya membuat model menghasilkan perencanaan matematika berdasarkan deskripsi masalah dalam bahasa alami, memanggil solver, atau memverifikasi jawaban pada instance skala kecil. Tugas-tugas ini sangat penting, tetapi seringkali sulit untuk menjawab pertanyaan yang lebih dekat dengan penerapan industri: Dapatkah model secara aktif menciptakan jalur algoritma yang lebih efektif pada instance besar di mana kinerja solver sudah jenuh?
Dalam praktik riset operasi dan optimasi, solver umum hanyalah titik awal, bukan akhir. Masalah nyata sering kali memiliki struktur khusus: struktur aliran jaringan, struktur dekomposisi waktu, struktur rute kendaraan, penggabungan persediaan dan rute, penggabungan mesin dan proses dalam penjadwalan, penggabungan kapasitas dan cakupan dalam pemilihan lokasi, dll. Insinyur algoritma yang baik akan memanfaatkan struktur ini, membongkar masalah awal, mengaproksimasi, melonggarkan, menyusun ulang, dan kemudian menyelesaikannya dengan metode campuran heuristik atau eksak.
Oleh karena itu, sebuah benchmark LLM yang benar-benar berorientasi pada OR perlu memenuhi tiga kondisi sekaligus: sumber soal yang cukup nyata, instance yang cukup besar, dan evaluasi yang cukup ketat. FrontierOR diusulkan dalam konteks ini: Ia bukan memberi model besar seperangkat 'latihan optimasi', melainkan mengubah masalah kompleks dari literatur OR selama lebih dari tiga puluh tahun yang telah melalui tinjauan sejawat, menjadi tugas desain algoritma yang dapat dievaluasi secara otomatis.

Tabel 1 Perbandingan multidimensi FrontierOR dengan benchmark perwakilan OR/LLM-for-optimization
Metode Penelitian
Alur konstruksi FrontierOR dapat diringkas dalam empat langkah: memilih topik dari literatur, mengubah masalah makalah menjadi komponen tugas standar, melalui pemeriksaan kualitas ganda otomatis dan ahli, lalu menyaring subset Hard yang lebih menantang.
- Langkah pertama, pemilihan topik dari literatur nyata. Sumber data mencakup 180 makalah dari lebih dari 20 jurnal OR antara tahun 1992–2025. Tugas yang dipilih harus memiliki definisi masalah yang jelas, dan makalah asli telah menunjukkan nilai rekayasa algoritma khusus relatif terhadap solver umum.
- Langkah kedua, komponen tugas standar. Setiap makalah diubah menjadi deskripsi masalah bahasa alami, model matematika, implementasi referensi Gurobi, solusi referensi, dan pemeriksa kelayakan independen.
- Langkah ketiga, verifikasi kualitas dua lapis. Pertama, verifikasi silang otomatis memeriksa konsistensi antara solusi referensi Gurobi dan pemeriksa kelayakan; kemudian dilakukan audit multiputaran oleh 15 ahli OR untuk memeriksa konsistensi model, deskripsi, kode, dan pemeriksa.
- Langkah keempat, penyaringan subset Hard. Dari 180 tugas, dipilih 50 tugas yang lebih sulit, berfokus pada ledakan kombinatorial, skala lebih besar, kendala lebih terhubung, dan di mana Gurobi tidak dapat membuktikan optimalitas dalam anggaran waktu 1 jam.

Gambar 1 Gambaran lengkap benchmark FrontierOR: kategori masalah, bidang aplikasi, skala instance, dan alur konstruksi
Protokol Evaluasi
Alur evaluasi juga menekankan kemampuan end-to-end. Model pertama-tama menghasilkan program algoritma lengkap berdasarkan deskripsi tugas bahasa alami. Program ini terlebih dahulu melalui pra-penyaringan kelayakan eksekusi, kelayakan, dan kualitas pada instance kecil: jika waktu habis, tidak layak, atau gap dengan Gurobi pada instance kecil melebihi 10%, maka tidak akan memasuki evaluasi instance besar.
Setelah lolos pra-penyaringan, program akan dijalankan pada beberapa instance skala besar dari setiap tugas, dan dibandingkan dengan solusi referensi Gurobi yang telah diaudit oleh ahli. FrontierOR menggunakan empat metrik: Execution rate (tingkat keterjalan), Feasibility (kelayakan), Solution quality (kualitas solusi), dan Quality-Time Efficiency (QTE, efisiensi kualitas-waktu). Di antaranya, QTE paling ketat: hanya jika selisih relatif nilai tujuan dengan solusi referensi Gurobi tidak lebih dari 1% atau melebihi solusi Gurobi, barulah dianggap berhasil.

Gambar 2 Alur evaluasi dua tahap FrontierOR: pra-penyaringan instance kecil, evaluasi kualitas dan kecepatan instance besar
Hasil Eksperimen
One-shot: Keterjalan Mendekati Batas Atas
Dalam pengaturan one-shot, model perlu menghasilkan program algoritma lengkap dari nol, dapat melakukan debugging mandiri terbatas berdasarkan kesalahan eksekusi, tetapi tidak dapat menulis ulang algoritma berulang kali berdasarkan umpan balik evaluasi. Pengaturan ini menguji kemampuan komprehensif model dalam membaca soal, pemodelan, desain algoritma, dan pengkodean dalam satu kali.
Hasil menunjukkan, keterjalan model terkuat sudah sangat tinggi. Misalnya, GPT-5.3-Codex pada set lengkap Full mencapai Execution rate 0,98, Gemini 3.1 Pro dan Claude Opus 4.6 juga mencapai 0,93. Ini menunjukkan bahwa bagi model mutakhir, 'apakah kode dapat berjalan' sudah bukan lagi hambatan utama.
Namun, keterjalan tidak sama dengan mampu menyelesaikan. Feasibility, Solution quality, dan QTE masih jauh lebih rendah daripada Execution rate. Dengan kata lain, model besar sudah dapat menulis program optimasi yang secara formal lengkap, tetapi untuk menjaga program ini tetap layak, mendekati optimal, dan lebih cepat daripada Gurobi pada skala industri, masih sulit.
Dari segi stratifikasi keseluruhan, model frontier pada set lengkap Full dan subset Hard secara signifikan lebih unggul daripada model arus utama lainnya. Pada set lengkap FrontierOR, Feasibility model frontier terkonsentrasi pada 0,60–0,62, sedangkan model arus utama lainnya sekitar 0,18–0,42. Pada subset Hard, kesenjangan masih ada: model frontier 0,49–0,64, model arus utama lainnya turun menjadi 0,13–0,37.
Subset Hard semakin memperlebar kesenjangan kemampuan algoritma antar model frontier. Pada set lengkap, QTE dari tiga model frontier berada dalam interval sempit 0,25–0,31, tampaknya mendekati; tetapi pada subset Hard, QTE Claude Opus 4.6 masih mencapai 0,32, sedangkan GPT-5.3-Codex turun menjadi 0,18, perbedaannya hampir 2 kali lipat. Oleh karena itu, subset Hard menjadi 'garis pemisah kemampuan rekayasa algoritma' yang sesungguhnya.

Tabel 2 Hasil evaluasi one-shot FrontierOR: Execution rate, Feasibility, Solution quality, dan QTE pada set lengkap Full dan subset Hard
Pilihan Algoritma Mengalami Diferensiasi
Tim penelitian selanjutnya menganalisis metode penyelesaian yang digunakan oleh program yang dihasilkan model, membaginya menjadi lima kategori: pemanggilan solver murni, dekomposisi, heuristik konstruktif, local search/metaheuristik, serta metode hibrida perencanaan matematika-heuristik. Analisis ini sangat krusial karena langsung mengungkap apakah model benar-benar memiliki kesadaran desain algoritma.
Hasil menunjukkan, model yang lebih lemah sangat bergantung pada pemanggilan solver murni. Misalnya, sekitar 99% program dari LLaMA-4-Maverick adalah pemanggilan solver monolitik, yang pada dasarnya melemparkan masalah ke solver umum. Sebaliknya, distribusi metode Claude Opus 4.6 paling seimbang: sekitar 37% adalah solver murni, 27% local search/metaheuristik, 27% hibrida perencanaan matematika-heuristik.
Yang lebih penting, metode non-solver murni secara keseluruhan lebih unggul dalam metrik QTE. Ini berarti 'keragaman metode' itu sendiri adalah daya saing: semakin mampu model memilih algoritma dekomposisi, heuristik, dan hibrida berdasarkan struktur masalah, semakin besar kemungkinan untuk memenangkan kualitas dan kecepatan secara bersamaan pada instance besar.

Gambar 3 Distribusi metode penyelesaian program yang dihasilkan oleh model berbeda dan analisis mode kegagalan
Migrasi Mode Kegagalan: Dari 'Tidak Bisa Memodelkan' ke 'Pencarian Tidak Cukup Dalam'
Analisis mode kegagalan menunjukkan, seiring peningkatan kemampuan model, lokasi terjadinya kesalahan berpindah secara sistematis ke belakang. Model yang lebih lemah terutama membuat kesalahan pada tahap awal seperti desain model matematika, spesifikasi kendala, skema I/O; model yang lebih kuat secara signifikan mengurangi kesalahan di tautan dasar ini, hambatan baru beralih ke kedalaman dan kualitas pencarian heuristik.
Ini sangat mirip dengan jalur pertumbuhan insinyur algoritma manusia. Pemula pertama-tama akan membuat kesalahan pemodelan: definisi variabel tidak jelas, kendala terlewat, input-output tidak cocok; insinyur yang lebih matang tidak mudah membuat kesalahan dasar ini, tetapi akan menghadapi masalah yang lebih sulit: apakah strategi pencarian cukup kuat, apakah desain lingkungan efektif, apakah relaksasi dan perbaikan dapat menyeimbangkan kecepatan dan kualitas.
Oleh karena itu, FrontierOR tidak hanya memberi tahu kita 'siapa yang skornya lebih tinggi', tetapi juga 'di mana hambatan kemampuan berada'. Ini sangat penting bagi desain sistem LLM-for-OR generasi berikutnya: terobosan di masa depan belum tentu berasal dari model yang lebih pandai menulis rumus, tetapi mungkin berasal dari sistem yang lebih pandai mencari, mengombinasikan keterampilan algoritma, dan memanfaatkan umpan balik untuk memperbaiki diri.
Evolusi Mandiri
Generasi satu kali hanyalah langkah pertama. Desain algoritma dalam kenyataan tidak pernah selesai dalam satu naskah, melainkan proses iteratif yang terus berjalan, menganalisis kegagalan, memodifikasi strategi, dan berjalan lagi. Oleh karena itu, FrontierOR selanjutnya mengevaluasi tiga kerangka evolusi mandiri saat pengujian: OpenEvolve, EoH, dan CORAL.
Eksperimen memilih 40% tugas tersulit dari subset Hard sebagai set pengujian self-evolve, menggunakan program yang dihasilkan sekali oleh GPT-5.3-Codex sebagai benih awal. Setiap kerangka dibatasi seragam dengan 30 kandidat program, menggunakan hasil terbaik akhir sebagai keadaan akhir. Ini memastikan perbedaan terutama berasal dari mekanisme pencarian, bukan dari perbedaan program awal.
Hasilnya sangat mencolok: Di bawah tiga kerangka evolusi mandiri, program kandidat terbaik pada setiap metrik secara signifikan melampaui generasi satu kali. QTE meningkat dari 0,15 pada one-shot menjadi tertinggi 0,50, yang berarti pada tugas tersulit, sekitar setengah instance besar sudah dapat dipenuhi oleh algoritma yang dihasilkan LLM dengan dua kondisi sekaligus: 'kualitas mendekati Gurobi' dan 'kecepatan tidak lebih lambat dari Gurobi'.
Di antaranya, CORAL dengan mekanisme memori bersama multi-agen mencapai peningkatan paling stabil, QTE mencapai 0,50; OpenEvolve menyusul, QTE 0,49; EoH juga membawa peningkatan yang nyata, tetapi kinerja lebih fluktuatif, QTE 0,33.

Tabel 3 Kinerja tiga kerangka evolusi mandiri saat pengujian pada tugas tersulit: QTE meningkat dari 0,15 menjadi 0,50
Mengamati lintasan evolusi lebih lanjut, dapat dilihat fenomena yang sangat menginspirasi: Dimensi kecepatan sering kali dapat melampaui baseline Gurobi dalam 5 upaya pertama, sedangkan dimensi kualitas solusi jauh lebih sulit. Alasannya tidak sulit dipahami: untuk membuat algoritma berjalan lebih cepat, menggunakan heuristik konstruktif ringan mungkin sudah cukup; tetapi untuk mendekati optimal global sambil 'lebih cepat', memerlukan lingkungan yang lebih halus, strategi perbaikan, strategi relaksasi, dan kontrol pencarian.
Ini menunjukkan bahwa evolusi mandiri LLM bukan sekadar 'mencoba kode beberapa kali'. Evolusi mandiri yang benar-benar efektif perlu mampu mengingat kegagalan sejarah, mengidentifikasi hambatan kinerja, menyesuaikan arah pencarian secara dinamis, dan melakukan pertimbangan terstruktur antara kecepatan dan kualitas.

Gambar 4 Lintasan evolusi dua dimensi kualitas-kecepatan dari tiga kerangka evolusi mandiri: kecepatan mudah terlebih dahulu melampaui, peningkatan kualitas lebih sulit
Aplikasi Masa Depan
Nilai FrontierOR tidak hanya terletak pada peringkat model, tetapi juga memberikan arah pengembangan yang jelas untuk sistem optimasi cerdas generasi berikutnya. Jika model besar dapat secara stabil membaca kebutuhan bisnis nyata, mengidentifikasi struktur optimasi, memanggil atau mengombinasikan keterampilan algoritma yang sesuai, dan memperbaiki diri melalui umpan balik eksekusi, maka ia berpeluang menjadi 'insinyur algoritma AI' dalam sistem pengambilan keputusan industri.
Dalam skenario rantai pasok, sistem semacam ini dapat berdasarkan pesanan, gudang, persediaan, jaringan transportasi, dan persyaratan waktu, secara otomatis menghasilkan algoritma penjadwalan dan perutean yang berorientasi pada skala tertentu; dalam sistem energi, ia dapat merancang strategi penyelesaian pendekatan cepat untuk penjadwalan jaringan listrik, manajemen penyimpanan energi, dan keseimbangan beban; dalam sistem transportasi dan perkotaan, ia dapat menghadapi permintaan dinamis, propagasi kemacetan, dan kendala sumber daya, menghasilkan algoritma optimasi yang dapat diterapkan secara real-time.
Lebih jauh, FrontierOR juga mengisyaratkan bentuk masa depan dari optimasi agentik: LLM tidak lagi hanya sebagai generator kode, melainkan agen cerdas desain algoritma yang dapat menggunakan perpustakaan keterampilan, memanggil verifikator, menjalankan eksperimen, melakukan atribusi kesalahan, dan aktif mengeksplorasi di bawah anggaran terbatas.
Prospek
- Membangun perpustakaan keterampilan desain algoritma OR. Mengendapkan strategi umum seperti dekomposisi, relaksasi, column generation, local search, perbaikan, restart, penyelesaian hibrida menjadi modul keterampilan yang dapat dicari, dikombinasikan, dan dieksekusi, sehingga agen dapat secara otomatis memilih templat algoritma berdasarkan struktur masalah.
- Mengembangkan verifier/evaluator yang lebih andal. Evaluator tidak hanya memeriksa kelayakan, tetapi juga mengidentifikasi kendala jenis apa yang menyebabkan kegagalan, jenis pencarian lokal apa yang stagnan, sehingga mengubah umpan balik eksekusi menjadi arah desain putaran berikutnya.
- Meningkatkan kemampuan penjadwalan anggaran evolusi mandiri. Pada instance skala besar, setiap evaluasi sangat mahal. Sistem masa depan perlu belajar kapan mengeksplorasi struktur baru, kapan menyesuaikan parameter, kapan menghentikan arah yang tidak efektif.
- Mendorong integrasi mendalam LLM dengan optimizer tradisional. Arah yang paling menjanjikan mungkin bukan 'LLM menggantikan solver', melainkan LLM bertanggung jawab menemukan struktur dan merancang algoritma, sedangkan solver tradisional bertanggung jawab untuk optimasi eksak lokal dan verifikasi yang dapat dipercaya.
Ringkasnya, FrontierOR telah menggambar peta sistematis pertama kemampuan rekayasa algoritma OR model besar: model besar sudah dapat menulis sebagian algoritma optimasi yang kompetitif, tetapi yang benar-benar menentukan batas atas bukan lagi sintaks kode atau terjemahan rumus, melainkan kemampuan penemuan struktur, desain pencarian, dan evolusi mandiri.
Jika penelitian LLM-for-OR tahap sebelumnya menjawab 'apakah model besar dapat memodelkan', maka FrontierOR mulai menanyakan pertanyaan yang lebih sulit dan realistis: Dapatkah model besar menjadi perancang algoritma yang sesungguhnya?
Referensi: arxiv.org/abs/2605.25246
Artikel ini dari akun WeChat publik "新智元" (New Zhiyuan), penulis: 新智元; editor: LRST






