Tại sao AI vẫn chưa thể giải quyết các bài toán tối ưu hóa thực tế và cách ORPilot khắc phục điều này

Nếu bạn từng cố gắng sử dụng AI để xây dựng mô hình tối ưu hóa toán học cho một vấn đề kinh doanh thực tế, bạn có lẽ đã vấp phải một rào cản giống như những người khác: AI hoạt động tuyệt vời trên các ví dụ trong sách giáo khoa nhưng lại sụp đổ ngay lập tức khi bạn đưa cho nó dữ liệu thực và vấn đề thực của mình.

Khoảng cách này không phải là ngẫu nhiên. Nó là kết quả của thiết kế, và đó chính là lý do tôi xây dựng ORPilot.

Lời hứa của Tối ưu hóa dựa trên AI

Nghiên cứu Vận hành (Operations Research - OR) đã âm thầm thúc đẩy một số quyết định quan trọng nhất trong kinh doanh trong nhiều thập kỷ — từ điều phối xe tải giao hàng, lập kế hoạch sản xuất nhà máy, thiết kế chuỗi cung ứng đến phân bổ hàng hóa cho các đơn vị vận chuyển. Toán học của lĩnh vực này đã rất trưởng thành và các bộ giải (solvers) hoạt động xuất sắc. Điểm nghẽn luôn nằm ở chuyên môn của con người cần thiết để chuyển đổi một vấn đề kinh doanh thành mô hình toán học.

Các Mô hình Ngôn ngữ Lớn (LLMs) dường như là giải pháp hoàn hảo. Một lượng lớn nghiên cứu, bao gồm chuỗi bài OptiMUS, OR-LLM và các công trình khác, đã chỉ ra rằng các LLM hiện đại có thể tạo ra mã giải đúng cho các bài toán lập trình tuyến tính (LP) và lập trình nguyên hỗn hợp (MIP) được xác định rõ ràng. Kết quả trông rất ấn tượng. Các bản demo rất thuyết phục.

Nhưng khi bạn cố gắng sử dụng một trong những công cụ này cho một vấn đề thực, những rạn nứt xuất hiện ngay lập tức.

Tại sao các công cụ hiện tại gặp khó khăn

Hầu hết mọi công cụ LLM cho OR được xây dựng cho đến nay đều chia sẻ một giả định ngầm định: mô tả vấn đề là hoàn chỉnh, không mơ hồ và được đưa cho AI trong một lời nhắc (prompt) duy nhất, được định dạng tốt với tất cả dữ liệu được nhúng gọn gàng bên trong.

Đó không phải là cách các bài toán OR thực tế hoạt động. Không hề gần giống như vậy.

Hãy xem xét điều gì thực sự xảy ra khi một đội ngũ chuỗi cung ứng muốn xây dựng một mô hình tối ưu hóa:

• Mô tả vấn đề không hoàn chỉnh và mơ hồ: Một chuyên gia phân tích kinh doanh sẽ nói "chúng tôi muốn giảm thiểu chi phí vận chuyển" và quên đề cập rằng mỗi trung tâm phân phối có giới hạn thông lượng, một số tuyến đường không tồn tại, hoặc việc mở một cơ sở phát sinh chi phí cố định một lần. Những sự bỏ sót này không phải do sự cẩu thả. Chúng là những giả định mà chuyên gia coi là hiển nhiên, và chính vì thế chúng lại nguy hiểm. Một hệ thống AI bắt đầu mô hình hóa trước khi các chi tiết này được xác định sẽ tạo ra một mô hình về mặt kỹ thuật là đúng nhưng về mặt thực tế thì sai.

• Dữ liệu quá lớn để vừa trong một lời nhắc: Một bài toán chuỗi cung ứng thực tế có thể liên quan đến hàng trăm địa điểm sản xuất, trung tâm phân phối, khách hàng và hàng nghìn sản phẩm trong nhiều giai đoạn. Chỉ riêng bảng nhu cầu có thể có hàng triệu mục. Bạn không thể nhúng tất cả vào một lời nhắc. Ngay cả khi có thể, việc làm ngập cửa sổ ngữ cảnh (context window) với dữ liệu thô sẽ làm tăng đáng kể nguy cơ ảo giác (hallucinations).

• Dữ liệu bạn có không phải là dữ liệu mô hình cần: Mô hình có thể cần ma trận khoảng cách giữa tất cả các cặp địa điểm. Những gì bạn có là bảng tọa độ GPS. Mô hình có thể cần nhu cầu tổng hợp theo sản phẩm và kỳ. Những gì bạn có là sổ cái giao dịch với một dòng cho mỗi đơn hàng. Thu hẹp khoảng cách này, tức là tính toán các tham số phái sinh từ dữ liệu thô, là một bước kỹ thuật đáng kể mà không công cụ LLM cho OR hiện tại nào xử lý tự động.

Đây không phải là các trường hợp ngoại lệ. Chúng là điều kiện tiêu chuẩn cho bất kỳ triển khai OR thực tế nào. Các công cụ LLM cho OR hiện tại được xây dựng cho một thế giới khác — một thế giới sách giáo khoa — và chúng lộ rõ những điểm yếu ngay khi rời khỏi môi trường đó.

Giới thiệu ORPilot

ORPilot là một tác nhân AI mã nguồn mở được xây dựng từ đầu cho các điều kiện sản xuất. Theo hiểu biết của tôi, đây là công cụ OR dựa trên LLM đầu tiên được thiết kế rõ ràng cho thực tế lộn xộn, quy mô lớn và nhiều dữ liệu của tối ưu hóa công nghiệp.

Hầu hết các công cụ AI cho tối ưu hóa nhảy thẳng vào việc viết mã ngay khi bạn mô tả vấn đề của mình. ORPilot làm điều gì đó khác biệt: nó đặt câu hỏi trước.

Quyết định thiết kế này, ưu tiên sự hiểu biết tốc độ, phản ánh một nguyên tắc hướng dẫn duy nhất: một tác nhân AI nên hoạt động giống như một chuyên gia tư vấn OR có kỹ năng.

Một chuyên gia giỏi không bước vào cuộc họp với khách hàng và bắt đầu viết mô hình toán học trên bảng trắng. Họ đặt câu hỏi. Họ lắng nghe cẩn thận. Họ phản biện khi điều gì đó mơ hồ. Họ đảm bảo dữ liệu ở đúng dạng trước khi bắt đầu mô hình hóa. Chỉ sau khi tất cả những điều đó, họ mới cầm bút lên.

Quy trình của ORPilot phản ánh sự kỷ luật này thông qua năm giai đoạn kết nối tuần tự.

Giai đoạn 1: Tác nhân Phỏng vấn (Interview Agent)

Tác nhân phỏng vấn là điểm nhập. Nó nhận mô tả ban đầu của bạn về vấn đề kinh doanh, có thể mơ hồ, không hoàn chỉnh hoặc thậm chí mâu thuẫn, và tham gia vào một cuộc đối thoại có cấu trúc để lấp đầy các khoảng trống. Nguyên tắc thiết kế chính là không có mô hình hóa nào bắt đầu cho đến khi cuộc phỏng vấn kết thúc.

Tác nhân được lập trình để xác định các khoảng trống thông tin trong mô tả hiện tại, đặt tối đa một câu hỏi làm rõ mục tiêu mỗi lượt (để không làm quá tải bạn) và kết thúc khi hàm mục tiêu, biến quyết định, ràng buộc và yêu cầu dữ liệu đều được xác định rõ ràng.

Trong thực tế, điều này có nghĩa là các cuộc trò chuyện như:

ORPilot: "Khi một cơ sở được mở, nó có giữ mở cho tất cả các kỳ tiếp theo không, hay có thể đóng lại sau đó?"

ORPilot: "Mô hình này xử lý một loại sản phẩm hay nhiều sản phẩm?"

ORPilot: "Bạn đã đề cập đến chi phí vận chuyển. Chi phí này là theo đơn vị vận chuyển, theo lô hàng bất kể số lượng, hay cái gì khác?"

Trước khi kết thúc phỏng vấn, tác nhân trình bày một bản tóm tắt có cấu trúc đầy đủ với hàm mục tiêu, biến quyết định, ràng buộc, tham số, chỉ số và cho bạn cơ hội sửa chữa bất kỳ điều gì trước khi bản tóm tắt đó được chuyển xuống dưới. Đây là lớp bảo vệ chống lại chế độ thất bại phổ biến nhất trong các công cụ LLM cho OR: mô hình hóa sai vấn đề.

Giai đoạn 2: Tác nhân Thu thập Dữ liệu (Data Collection Agent)

Giai đoạn này không có đối tác trong hầu hết các công cụ LLM cho OR hiện tại. Nó là một trong những đổi mới cấu trúc quan trọng nhất trong ORPilot.

Hầu hết các công cụ hiện tại giả định dữ liệu được nhúng trong văn bản vấn đề, đủ nhỏ để vừa trong một lời nhắc. Đối với các bài toán sách giáo khoa, điều này hoạt động. Đối với các bài toán thực, nó bị phá vỡ theo hai cách. Thứ nhất, tập dữ liệu thực quá lớn. Ví dụ, bài toán chuỗi cung ứng 500 khách hàng, 500 sản phẩm, 12 kỳ sẽ có 3.000.000 mục nhu cầu. Thứ hai, việc nhúng dữ liệu trong lời nhắc làm tăng nguy cơ ảo giác và lãng phí cửa sổ ngữ cảnh một cách không cần thiết.

Câu trả lời của ORPilot là tách dữ liệu hoàn toàn khỏi lời nhắc. Dữ liệu sống trong các tệp CSV. AI chỉ truy cập nó bằng cách viết và thực thi mã. Công việc của tác nhân thu thập dữ liệu là xác định chính xác các tệp CSV đó cần trông như thế nào.

Dựa trên thông số kỹ thuật vấn đề từ tác nhân phỏng vấn, tác nhân thu thập dữ liệu xác định:

• Các thực thể (tập hợp) nào tồn tại trong mô hình
• Các thuộc tính (tham số) mà mỗi thực thể cần
• Lược đồ chính xác cho mỗi bảng cần thiết: tên cột, kiểu dữ liệu, ngữ nghĩa

Nó trình bày thông số kỹ thuật này cho bạn và chờ cho đến khi bạn cung cấp tất cả các tệp ở định dạng đúng. Nó xác thực tính đầy đủ trước khi tiếp tục.

Quan trọng, tác nhân này linh hoạt: nếu bạn không có một phần dữ liệu sẵn sàng cho mô hình cụ thể (ví dụ, mô hình cần ma trận khoảng cách nhưng bạn chỉ có tọa độ GPS), bạn cho tác nhân biết những gì bạn thực sự có, và nó sẽ cập nhật lược đồ tương ứng — chuyển khoảng trống sang giai đoạn tiếp theo để xử lý.

Giai đoạn 3: Tác nhân Tính toán Tham số (Parameter Computation Agent)

Hầu hết mọi công cụ LLM cho OR hiện tại giả định các đại lượng số cần thiết cho mô hình xuất hiện trực tiếp trong dữ liệu do người dùng cung cấp. Trong thực tế, điều này hầu như không bao giờ đúng. Hai ví dụ thường xuyên xuất hiện trong các bài toán OR thực:

• Một mô hình định tuyến xe cần ma trận khoảng cách theo cặp. Người dùng có tọa độ GPS. Việc tính toán khoảng cách Euclide hoặc địa lý là một phép biến đổi hoàn toàn nằm ngoài phạm vi công thức LP/MIP.
• Một mô hình sản xuất đa kỳ cần nhu cầu tổng hợp theo kỳ. Người dùng có sổ cái giao dịch với một dòng cho mỗi đơn hàng. Tham số mô hình là một tổng hợp (sum-aggregation) phải được tính toán từ dữ liệu thô.

Tác nhân tính toán tham số thu hẹp khoảng cách này tự động. Nó nhận thông số kỹ thuật vấn đề và các tệp CSV thô, sau đó:

• Xác định các tham số mô hình không thể đọc trực tiếp từ các bảng thô
• Tạo một tập lệnh Python để tính toán các tham số phái sinh đó
• Thực thi tập lệnh trong môi trường sandbox
• Ghi kết quả dưới dạng các tệp CSV bổ sung, được chuyển sang bước mô hình hóa

Điều này đảm bảo rằng vào thời điểm tác nhân mô hình hóa nhìn thấy dữ liệu, nó đã sạch, đúng kiểu, đúng chỉ mục và sẵn sàng cho mô hình. Trong các thí nghiệm của chúng tôi, bước này làm giảm đáng kể các lỗi tạo mã và số lần thử lại.

Một tình huống phổ biến khác mà tác nhân tính toán tham số có thể hữu ích là tính toán các giá trị BigM. Trong một số thí nghiệm với ORPilot, tác nhân tính toán tham số đã tính toán giá trị BigM cần thiết cho các ràng buộc liên kết biến vận chuyển liên tục với các quyết định mở cơ sở nhị phân. Đây là một tham số phái sinh mà việc yêu cầu người dùng cung cấp trực tiếp là không thực tế.

Giai đoạn 4: Tác nhân Tạo Mã (Code Generation Agent)

Với thông số kỹ thuật vấn đề hoàn chỉnh, dữ liệu thô và các tham số phái sinh đã sẵn sàng, tác nhân tạo mã tạo ra một tập lệnh trình giải Python hoàn chỉnh cho backend bạn chọn. ORPilot hiện hỗ trợ năm backend: Gurobi, CPLEX, PuLP, Pyomo và OR-Tools.

Mã được tạo được thực thi ngay lập tức trong sandbox. Nếu có bất kỳ điều gì sai: lỗi cú pháp, ngoại lệ thời gian chạy, hoặc kết quả trình giải không khả thi/không giới hạn, thông báo lỗi đầy đủ và dấu vết (traceback) được gửi lại LLM cùng với mã được tạo trước đó. Tác nhân thử lại, tối đa số lần do người dùng cấu hình.

Trong thực tế, phần lớn các thất bại được giải quyết trong một hoặc hai lần thử lại. Lý do chính vòng lặp thử lại của ORPilot hiệu quả là các giai đoạn thượng nguồn đã thực hiện công việc khó khăn: vấn đề được xác định đúng, dữ liệu sẵn sàng cho mô hình, và tác nhân chỉ cần sửa lỗi cấp mã thay vì suy nghĩ lại toàn bộ cấu trúc mô hình.

Giai đoạn 5: Tác nhân Báo cáo (Reporter Agent)

Sau khi giải quyết thành công, một tác nhân báo cáo dịch kết quả số thành ngôn ngữ tiếng Anh đơn giản, giải thích cơ sở nào cần mở, tuyến đường nào cần sử dụng, số lượng nào cần sản xuất, bằng ngôn ngữ của vấn đề kinh doanh ban đầu, để người dùng kinh doanh thay vì chuyên gia OR có thể tiêu thụ.

Tại sao Thứ tự này Quan trọng

Quy trình được thiết kế có chủ đích theo tuần tự. Mỗi giai đoạn được chốt dựa trên sự hoàn thành thành công của giai đoạn trước. Cuộc phỏng vấn phải kết thúc trước khi thu thập dữ liệu bắt đầu. Dữ liệu phải được xác thực trước khi tính toán tham số chạy. Các tham số phải sẵn sàng trước khi mã được tạo.

Sự sắp xếp này ngăn chặn chế độ thất bại phổ biến nhất trong các công cụ OR dựa trên LLM: các lỗi lan truyền (cascading errors) nơi mô tả vấn đề mơ hồ lan truyền qua quy trình và tạo ra mã về mặt cú pháp hợp lệ nhưng mô hình hóa sai hàm mục tiêu.

Cái này trông như thế nào ở Quy mô Lớn

Tôi đã kiểm tra ORPilot trên một vài bài toán OR, một trong số đó là bài toán thiết kế mạng lưới chuỗi cung ứng với 50 địa điểm sản xuất, 50 trung tâm phân phối, 500 khách hàng, 500 sản phẩm, 12 kỳ. Mô hình kết quả có hơn 9,7 triệu biến quyết định và 963.000 ràng buộc. ORPilot đã xử lý thành công toàn bộ quy trình từ đầu đến cuối, từ cuộc trò chuyện ban đầu thông qua thu thập dữ liệu, tính toán tham số, tạo mã và báo cáo giải pháp, tạo ra giải pháp tối ưu với Gurobi.

Bạn có thể xem kết quả của nhiều bài toán kiểm tra hơn trong bài báo của tôi tại đây: https://arxiv.org/abs/2605.02728.

Bắt đầu ngay

ORPilot là mã nguồn mở và có sẵn ngay bây giờ:

• GitHub: https://github.com/GuangruiXieVT/ORPilot
• Bài báo: https://arxiv.org/abs/2605.02728

Việc cài đặt chỉ mất vài phút. ORPilot hỗ trợ OpenAI, Anthropic, Google và DeepSeek làm nhà cung cấp LLM, và Gurobi, CPLEX, PuLP, Pyomo và OR-Tools làm backend trình giải.

Trong bài viết tiếp theo của loạt bài này, chúng ta sẽ đi sâu vào Biểu diễn Trung gian (IR) — tạo tác JSON không phụ thuộc trình giải giúp kết quả của ORPilot có thể tái tạo và chuyển port qua các backend mà không cần gọi LLM nữa. Hãy theo dõi!