Trong hai năm qua, LLM đã tiến bộ nhanh chóng trong lĩnh vực "ngôn ngữ tự nhiên thành mô hình toán học" và "ngôn ngữ tự nhiên thành mã trình giải". Mô hình có thể đọc hiểu đề bài, viết công thức MIP, gọi Gurobi hoặc các trình giải khác, dường như đã có khả năng mô hình hóa tối ưu sơ khai. Nhưng với các bài toán quy mô công nghiệp thực sự, điều này còn rất xa mới đủ.
Vấn đề khó thực sự không phải là dịch từng ràng buộc thành biểu thức toán học, mà là thiết kế một bộ thuật toán có thể chạy được, chạy chính xác và chạy nhanh trên các thực thể lớn. Ngay cả khi một mô hình MIP hoàn toàn chính xác, sau khi giao cho trình giải tổng quát, cũng có thể không lấy được nghiệm chất lượng cao có thể chứng minh trong vòng một giờ. Đây cũng là lý do tại sao các kỹ sư OR trong thực tế vẫn cần viết thuật toán phân rã, sinh cột, Benders, tìm kiếm cục bộ, siêu heuristic và thuật toán lai ghép giữa lập trình toán học và heuristic.
Gần đây, các nhà nghiên cứu từ MIT và các tổ chức khác đã đề xuất FrontierOR: một chuẩn đánh giá LLM hướng đến khả năng thiết kế thuật toán tối ưu quy mô lớn.
Khác với các benchmark truyền thống chỉ xem xét "có thể mô hình hóa hay không" hoặc "có thể gọi trình giải hay không", FrontierOR tập trung vào việc liệu LLM có thể giống như các nhà nghiên cứu và kỹ sư OR thực thụ, thiết kế ra các thuật toán có khả năng mở rộng, chất lượng cao và hiệu quả cho cấu trúc vấn đề phức tạp.

Link bài báo: arxiv.org/abs/2605.25246
Trang chủ dự án: frontieror.vercel.app
Link mã nguồn: github.com/Minw913/FrontierOR
Link tập dữ liệu: SmartOR/FrontierOR
Câu hỏi cốt lõi của FrontierOR chính là: Các mô hình lớn mạnh nhất hiện nay, rốt cuộc có thể xuất phát từ vấn đề thực tế, tự chủ thiết kế ra các thuật toán hiệu quả có tính cạnh tranh hay không? Nó có thể không còn chỉ là "gọi trình giải", mà giống như chuyên gia OR, lựa chọn các chiến lược phân rã, heuristic, tìm kiếm và hỗn hợp dựa trên cấu trúc vấn đề?
Ý nghĩa của công trình này nằm ở chỗ, nó đẩy trọng tâm đánh giá LLM-for-OR từ "biết viết mô hình hay không" tiến lên "biết thiết kế thuật toán hay không". Đây cũng là một ngưỡng cửa mà mô hình lớn bắt buộc phải vượt qua để tiến đến các hệ thống ra quyết định công nghiệp thực sự.
Bối cảnh nghiên cứu
Đã có không ít chuẩn đánh giá tập trung vào khả năng mô hình hóa của LLM trong các bài toán tối ưu, ví dụ như để mô hình dựa trên mô tả ngôn ngữ tự nhiên tạo ra lập trình toán học, gọi trình giải, hoặc xác minh đáp án trên các thực thể nhỏ. Loại nhiệm vụ này rất quan trọng, nhưng chúng thường khó trả lời một câu hỏi gần hơn với việc triển khai công nghiệp: Liệu mô hình có thể trên các thực thể lớn mà hiệu năng trình giải đã bão hòa, chủ động tạo ra con đường thuật toán hiệu quả hơn không?
Trong thực hành tối ưu vận trù, trình giải tổng quát chỉ là điểm khởi đầu, không phải điểm kết thúc. Vấn đề thực tế thường có cấu trúc đặc biệt: cấu trúc dòng chảy mạng, cấu trúc phân rã thời gian, cấu trúc tuyến đường xe, sự kết hợp giữa tồn kho và tuyến đường, sự kết hợp giữa máy móc và quy trình trong lập lịch, sự kết hợp giữa dung lượng và phủ sóng trong định vị... Kỹ sư thuật toán xuất sắc sẽ lợi dụng những cấu trúc này, tách rời, xấp xỉ, nới lỏng, tổ chức lại bài toán gốc, rồi thông qua phương pháp heuristic hoặc phương pháp chính xác lai ghép để giải.
Vì vậy, một chuẩn đánh giá mô hình lớn thực sự hướng đến OR cần đồng thời thỏa mãn ba điều kiện: nguồn đề đủ thực tế, thực thể đủ lớn, đánh giá đủ nghiêm ngặt. FrontierOR được đề xuất chính trong bối cảnh này: Nó không phải là đưa ra một bộ "bài tập tối ưu" cho mô hình lớn, mà là biến đổi các vấn đề phức tạp đã được thẩm định đồng nghiệp trong hơn ba mươi năm tài liệu OR, thành nhiệm vụ thiết kế thuật toán có thể đánh giá tự động.

Bảng 1 So sánh đa chiều giữa FrontierOR và các chuẩn đại diện về OR/LLM-for-optimization
Phương pháp nghiên cứu
Quy trình xây dựng FrontierOR có thể tóm tắt thành bốn bước: chọn đề từ tài liệu, chuyển đổi vấn đề trong bài báo thành các thành phần nhiệm vụ tiêu chuẩn hóa, trải qua kiểm tra chất lượng kép tự động và chuyên gia, sau đó lọc ra tập con Hard có tính thử thách hơn.
- Bước một, chọn đề từ tài liệu thực. Nguồn dữ liệu bao phủ 180 bài báo từ hơn 20 tạp chí OR trong giai đoạn 1992–2025. Nhiệm vụ được chọn cần có định nghĩa vấn đề rõ ràng, và bài báo gốc đã thể hiện giá trị kỹ thuật của thuật toán chuyên dụng so với trình giải tổng quát.
- Bước hai, thành phần nhiệm vụ tiêu chuẩn hóa. Mỗi bài báo được chuyển thành mô tả vấn đề bằng ngôn ngữ tự nhiên, mô hình toán học, triển khai tham chiếu Gurobi, nghiệm tham chiếu và bộ kiểm tra tính khả thi độc lập.
- Bước ba, xác minh chất lượng hai lớp. Đầu tiên thông qua kiểm tra chéo tự động để xem nghiệm tham chiếu Gurobi và bộ kiểm tra tính khả thi có nhất quán không; sau đó do 15 chuyên gia OR đánh giá nhiều vòng, kiểm tra tính nhất quán của mô hình, mô tả, mã và bộ kiểm tra.
- Bước bốn, lọc tập con Hard. Từ 180 nhiệm vụ, chọn ra 50 nhiệm vụ khó hơn, tập trung vào các kịch bản bùng nổ tổ hợp, quy mô lớn hơn, ràng buộc kết hợp chặt chẽ hơn và Gurobi không thể chứng minh tối ưu trong ngân sách 1 giờ.

Hình 1 Toàn cảnh benchmark FrontierOR: Loại bài toán, lĩnh vực ứng dụng, quy mô thực thể và quy trình xây dựng
Giao thức đánh giá
Quy trình đánh giá cũng nhấn mạnh khả năng đầu-cuối. Đầu tiên mô hình dựa trên mô tả nhiệm vụ ngôn ngữ tự nhiên tạo ra chương trình thuật toán hoàn chỉnh. Chương trình trải qua sàng lọc trước về khả năng thực thi, tính khả thi và chất lượng trên các thực thể nhỏ: nếu quá thời gian, không khả thi, hoặc chênh lệch (gap) với Gurobi trên thực thể nhỏ vượt quá 10%, thì không vào đánh giá thực thể lớn.
Sau khi qua sàng lọc trước, chương trình sẽ chạy trên nhiều thực thể lớn của mỗi nhiệm vụ, và đối chiếu với nghiệm tham chiếu Gurobi đã được chuyên gia thẩm định. FrontierOR sử dụng bốn chỉ số: Execution rate (tỷ lệ thực thi), Feasibility (tính khả thi), Solution quality (chất lượng nghiệm) và Quality-Time Efficiency (QTE, hiệu suất chất lượng-thời gian). Trong đó QTE nghiêm ngặt nhất: chỉ khi giá trị mục tiêu chênh lệch tương đối với nghiệm tham chiếu Gurobi không quá 1% hoặc vượt nghiệm của Gurobi, mới tính là thành công.

Hình 2 Quy trình đánh giá hai giai đoạn của FrontierOR: Sàng lọc trước trên thực thể nhỏ, đánh giá chất lượng và tốc độ trên thực thể lớn
Kết quả thực nghiệm
One-shot: Khả năng thực thi gần chạm trần
Trong thiết lập one-shot, mô hình cần tạo chương trình thuật toán hoàn chỉnh từ đầu, có thể thực hiện tự gỡ lỗi hạn chế dựa trên lỗi thực thi, nhưng không thể dựa trên phản hồi đánh giá để viết lại thuật toán nhiều lần. Thiết lập này khảo sát năng lực tổng hợp đọc đề, mô hình hóa, thiết kế thuật toán và mã hóa một lần của mô hình.
Kết quả cho thấy, khả năng thực thi của mô hình mạnh nhất đã rất cao. Ví dụ GPT-5.3-Codex trên tập Full đạt Execution rate 0.98, Gemini 3.1 Pro và Claude Opus 4.6 cũng đạt 0.93. Điều này cho thấy với các mô hình tiên phong, "mã có chạy được không" không còn là nút cổ chai chính.
Nhưng thực thi được không có nghĩa là biết giải. Feasibility, Solution quality và QTE vẫn thấp hơn đáng kể so với Execution rate. Nói cách khác, mô hình lớn đã có thể viết ra chương trình tối ưu hoàn chỉnh về hình thức, nhưng để chương trình đó duy trì tính khả thi, gần tối ưu trên quy mô cấp công nghiệp, và nhanh hơn Gurobi, vẫn còn khó khăn.
Nhìn từ phân tầng tổng thể, các mô hình tiên phong trên cả tập Full và tập con Hard đều vượt trội hơn hẳn so với các mô hình chủ lưu khác. Trên toàn tập FrontierOR, Feasibility của các mô hình tiên phong tập trung ở 0.60–0.62, trong khi các mô hình chủ lưu khác khoảng 0.18–0.42. Trên tập con Hard, khoảng cách vẫn tồn tại: mô hình tiên phong là 0.49–0.64, các mô hình chủ lưu khác giảm xuống 0.13–0.37.
Tập con Hard càng làm nới rộng khoảng cách năng lực thuật toán giữa các mô hình tiên phong. Trên toàn tập, QTE của ba mô hình tiên phong rơi vào khoảng hẹp 0.25–0.31, trông có vẻ gần nhau; nhưng trên tập con Hard, QTE của Claude Opus 4.6 vẫn đạt 0.32, GPT-5.3-Codex thì giảm xuống 0.18, chênh lệch gần 2 lần. Tập con Hard vì thế trở thành "đường phân thủy năng lực kỹ thuật thuật toán" thực sự.

Bảng 2 Kết quả đánh giá one-shot trên FrontierOR: Tỷ lệ thực thi, tính khả thi, chất lượng nghiệm và QTE trên tập Full và tập con Hard
Lựa chọn thuật toán xuất hiện phân hóa
Nhóm nghiên cứu tiếp tục phân tích phương pháp giải mà chương trình do mô hình tạo ra sử dụng, chia thành năm loại: gọi trình giải thuần túy, phân rã, heuristic kiến tạo, tìm kiếm cục bộ/siêu heuristic, và phương pháp lai ghép lập trình toán học-heuristic. Phân tích này rất quan trọng, vì nó trực tiếp tiết lộ mô hình có thực sự có ý thức thiết kế thuật toán hay không.
Kết quả cho thấy, các mô hình yếu hơn phụ thuộc nhiều vào việc gọi trình giải thuần túy. Ví dụ, khoảng 99% chương trình của LLaMA-4-Maverick là monolithic solvercall, bản chất là ném bài toán cho trình giải tổng quát. Ngược lại, phân bố phương pháp của Claude Opus 4.6 cân bằng nhất: khoảng 37% là trình giải thuần túy, 27% là tìm kiếm cục bộ/siêu heuristic, 27% là lai ghép lập trình toán học-heuristic.
Quan trọng hơn, các phương pháp không phải trình giải thuần túy nhìn chung có lợi thế hơn về chỉ số QTE. Điều này có nghĩa "sự đa dạng phương pháp" bản thân nó đã là sức cạnh tranh: mô hình càng có thể dựa trên cấu trúc vấn đề để lựa chọn thuật toán phân rã, heuristic và lai ghép, thì càng có khả năng giành được cả chất lượng và tốc độ trên các thực thể lớn.

Hình 3 Phân tích phân bố phương pháp giải và các kiểu thất bại của chương trình do các mô hình khác nhau tạo ra
Di chuyển kiểu thất bại: Từ "không biết mô hình hóa" sang "tìm kiếm không đủ sâu"
Phân tích kiểu thất bại cho thấy, cùng với sự nâng cao năng lực mô hình, vị trí xảy ra lỗi đang di chuyển có hệ thống về phía sau. Các mô hình yếu hơn chủ yếu mắc lỗi ở các khâu đầu như thiết kế mô hình toán học, quy định ràng buộc, lược đồ I/O; các mô hình mạnh hơn lỗi ở các khâu cơ bản này giảm rõ rệt, nút cổ chai mới chuyển sang độ sâu và chất lượng của tìm kiếm heuristic.
Điều này rất giống với con đường trưởng thành của kỹ sư thuật toán con người. Người mới học trước tiên sẽ mắc lỗi mô hình hóa: định nghĩa biến không rõ, thiếu ràng buộc, đầu vào đầu ra không khớp; kỹ sư trưởng thành hơn không dễ mắc những lỗi cơ bản này, nhưng sẽ đối mặt với vấn đề khó hơn: chiến lược tìm kiếm có đủ mạnh không, thiết kế lân cận có hiệu quả không, việc nới lỏng và sửa chữa có thể cân bằng tốc độ và chất lượng hay không.
Vì vậy, FrontierOR không chỉ cho chúng ta biết "ai điểm cao hơn", mà còn cho biết "nút cổ chai năng lực ở đâu". Điều này đặc biệt quan trọng với việc thiết kế hệ thống LLM-for-OR thế hệ tiếp theo: đột phá trong tương lai không nhất thiết đến từ mô hình viết công thức giỏi hơn, mà có thể đến từ hệ thống tìm kiếm giỏi hơn, kết hợp kỹ năng thuật toán giỏi hơn, lợi dụng phản hồi tự cải thiện giỏi hơn.
Tự tiến hóa
Tạo một lần chỉ là bước đầu tiên. Trong thực tế, thiết kế thuật toán không bao giờ là định đời một bản thảo, mà là quá trình lặp đi lặp lại liên tục chạy, phân tích thất bại, sửa chiến lược, chạy lại. Do đó, FrontierOR tiến thêm một bước đánh giá ba khuôn khổ tự tiến hóa trong lúc kiểm tra: OpenEvolve, EoH và CORAL.
Thực nghiệm chọn 40% nhiệm vụ khó nhất trong tập con Hard làm bộ kiểm tra self-evolve, lấy chương trình do GPT-5.3-Codex tạo một lần làm hạt giống ban đầu. Mỗi khuôn khổ thống nhất giới hạn 30 chương trình ứng viên, lấy kết quả tốt nhất cuối cùng làm trạng thái cuối. Cách này đảm bảo khác biệt chủ yếu đến từ cơ chế tìm kiếm, chứ không phải từ chương trình ban đầu khác nhau.
Kết quả rất ấn tượng: Trong ba khuôn khổ tự tiến hóa, chương trình ứng viên tốt nhất trên các chỉ số đều vượt trội hẳn so với tạo một lần. QTE tăng từ 0.15 one-shot lên cao nhất 0.50, nghĩa là trên nhiệm vụ khó nhất, khoảng một nửa thực thể lớn đã có thể được thuật toán do LLM tạo ra đồng thời thỏa mãn hai điều kiện "chất lượng gần Gurobi" và "tốc độ không chậm hơn Gurobi".
Trong đó, CORAL nhờ cơ chế chia sẻ bộ nhớ đa tác nhân đạt được cải thiện ổn định nhất, QTE đạt 0.50; OpenEvolve theo sau, QTE là 0.49; EoH cũng mang lại cải thiện rõ ràng, nhưng hiệu năng dao động nhiều hơn, QTE là 0.33.

Bảng 3 Biểu hiện của ba khuôn khổ tự tiến hóa trong lúc kiểm tra trên nhiệm vụ khó nhất: QTE cao nhất từ 0.15 nâng lên 0.50
Quan sát thêm quỹ đạo tiến hóa, có thể thấy một hiện tượng đầy gợi mở: chiều tốc độ thường trong 5 lần thử đầu tiên đã có thể vượt qua đường cơ sở Gurobi, còn chiều chất lượng nghiệm thì khó khăn hơn nhiều. Lý do không khó hiểu: muốn thuật toán chạy nhanh hơn, dùng heuristic kiến tạo nhẹ nhàng có thể đã làm được; nhưng muốn vừa "nhanh hơn" vừa gần tối ưu toàn cục, thì cần lân cận tinh tế hơn, chiến lược sửa chữa, chiến lược nới lỏng và kiểm soát tìm kiếm.
Điều này chứng tỏ, tự tiến hóa của LLM không đơn giản là "thử mã nhiều lần". Tự tiến hóa thực sự hiệu quả, cần có khả năng ghi nhớ thất bại lịch sử, nhận diện nút cổ chai hiệu năng, điều chỉnh động hướng tìm kiếm, và cân bằng có cấu trúc giữa tốc độ và chất lượng.

Hình 4 Quỹ đạo tiến hóa hai chiều chất lượng—tốc độ của ba khuôn khổ tự tiến hóa: Tốc độ dễ vượt qua trước, nâng cao chất lượng khó hơn
Ứng dụng tương lai
Giá trị của FrontierOR không chỉ ở việc xếp hạng mô hình, mà còn ở việc cung cấp hướng phát triển rõ ràng cho hệ thống tối ưu thông minh thế hệ tiếp theo. Nếu mô hình lớn có thể ổn định đọc hiểu nhu cầu nghiệp vụ thực tế, nhận diện cấu trúc tối ưu, gọi hoặc kết hợp kỹ năng thuật toán phù hợp, và thông qua phản hồi thực thi tự cải thiện, thì nó có cơ hội trở thành "kỹ sư thuật toán AI" trong hệ thống ra quyết định công nghiệp.
Trong kịch bản chuỗi cung ứng, hệ thống loại này có thể dựa trên yêu cầu đơn hàng, kho hàng, tồn kho, mạng lưới vận tải và thời hạn, tự động tạo ra thuật toán lập lịch và tuyến đường hướng đến quy mô cụ thể; trong hệ thống năng lượng, nó có thể thiết kế chiến lược giải gần đúng nhanh cho điều độ lưới điện, quản lý lưu trữ năng lượng, cân bằng tải; trong hệ thống giao thông và đô thị, nó có thể hướng đến nhu cầu động, lan truyền tắc nghẽn và ràng buộc tài nguyên, tạo ra thuật toán tối ưu có thể triển khai thời gian thực.
Tiến thêm một bước, FrontierOR cũng gợi ý hình thái tương lai của agentic optimization: LLM không còn chỉ là bộ tạo mã, mà là một tác nhân thông minh thiết kế thuật toán biết sử dụng thư viện kỹ năng, biết gọi bộ kiểm tra, biết chạy thực nghiệm, biết quy nguyên lỗi, biết chủ động khám phá dưới ngân sách hạn chế.
Tầm nhìn
- Xây dựng thư viện kỹ năng thiết kế thuật toán OR. Lắng đọng các chiến lược thường gặp như phân rã, nới lỏng, sinh cột, tìm kiếm cục bộ, sửa chữa, khởi động lại, giải lai ghép... thành mô-đun kỹ năng có thể truy xuất, kết hợp, thực thi, để agent có thể dựa trên cấu trúc vấn đề tự động chọn mẫu thuật toán.
- Phát triển verifier/evaluator đáng tin cậy hơn. Bộ đánh giá không chỉ kiểm tra tính khả thi, mà còn nhận diện loại ràng buộc nào dẫn đến thất bại, loại tìm kiếm cục bộ nào đình trệ, từ đó chuyển hóa phản hồi thực thi thành hướng thiết kế cho vòng tiếp theo.
- Nâng cao khả năng điều phối ngân sách tự tiến hóa. Trên các thực thể lớn, mỗi lần đánh giá đều đắt đỏ. Hệ thống tương lai cần học cách khi nào khám phá cấu trúc mới, khi nào tinh chỉnh tham số, khi nào dừng hướng vô hiệu.
- Thúc đẩy sự hòa quyện sâu sắc giữa LLM và trình tối ưu truyền thống. Hướng triển vọng nhất có thể không phải là "LLM thay thế trình giải", mà là LLM phụ trách phát hiện cấu trúc và thiết kế thuật toán, trình giải truyền thống phụ trách tối ưu chính xác cục bộ và xác minh đáng tin.
Tóm lại, FrontierOR đã vẽ ra bản đồ hệ thống hóa đầu tiên về năng lực kỹ thuật thuật toán OR của mô hình lớn: mô hình lớn đã có thể viết ra một phần thuật toán tối ưu có tính cạnh tranh, nhưng thứ thực sự quyết định trần cao, không còn là cú pháp mã hay dịch công thức, mà là năng lực phát hiện cấu trúc, thiết kế tìm kiếm và tự tiến hóa.
Nếu nói nghiên cứu LLM-for-OR giai đoạn trước trả lời câu hỏi "mô hình lớn có biết mô hình hóa không", thì FrontierOR bắt đầu chất vấn một câu hỏi khó hơn và thực tế hơn: Mô hình lớn có thể trở thành nhà thiết kế thuật toán thực sự không?
Tài liệu tham khảo: arxiv.org/abs/2605.25246
Bài viết này từ tài khoản WeChat công chúng "Tân Trí Nguyên", tác giả: Tân Trí Nguyên; biên tập: LRST






