Великі мовні моделі (LLM) досягли надзвичайного прогресу в розумінні природної мови, генеруванні плавних відповідей і створенні цілком нових можливостей для клієнтів і працівників. Однак через імовірнісну природу LLM їх застосування для складних числових або логічних міркувань дає мало гарантій, що результати відповідатимуть вимогам або будуть оптимальними. Наприклад:
Керівник каже ШІ-помічнику з планування: “Ship as much as possible next week while keeping costs low,” — і система пропонує агресивний план, який здається ефективним, але непомітно перевищує місткість складу й порушує гарантії доставки.
Координатор каже ШІ-помічнику: “Reassign crews to reduce overnight stays and minimize disruption,” — і модель створює дешевший графік, який здається оптимальним, але порушує обов’язкові обмеження щодо робочого часу або відпочинку.
ШІ-помічник з фінансових операцій має схвалювати транзакції з урахуванням суворих регіональних обмежень і вимог щодо ризиків, але пропускає підозрілу транзакцію, вигадуючи обґрунтування, яке звучить правомірно, хоча й порушує внутрішню політику.
У середовищах із суворими операційними вимогами поєднання LLM із формальними розв’язувачами допомагає втримувати рішення на основі природної мови у визначених межах і уникати нездійсненних, неоптимальних або неправомірних результатів.
Наша команда досліджень і розробок вивчає гібридний підхід, що поєднує креативність і гнучкість LLM зі строгістю, гарантіями та прозорістю формальних математичних розв’язувачів, як-от Z3, Pyomo та OR-Tools. Ми також створюємо багаторазовий формальний ШІ-рушій, щоб ця можливість стала стандартною частиною корпоративного технологічного стеку. Платформа дасть організаціям змогу отримувати бізнес-правила безпосередньо з наявних систем, безперервно перевіряти рішення за цими правилами та безпечно впроваджувати ШІ-агентів у чітко визначених межах.
Наша мета — знизити операційні ризики й водночас прискорити ухвалення рішень у масштабі. Керівники швидше отримують рішення на основі природної мови, що відповідають політикам, а організації можуть автоматизувати ситуативні зміни в плануванні, розподілі ресурсів ланцюга постачання, фінансових операціях, перевірці політик і навіть проєктуванні відео чи 3D-об’єктів. Вбудовані запобіжники не допускають до робочого середовища нездійсненні, неправомірні або небезпечні результати.
У контрольованих експериментах із задачами оптимізації на кшталт логістичних і трьома загальнодоступними бенчмарками наш гібридний підхід стабільно демонстрував:
Вищу точність
Кращу інтерпретованість і придатність до аудиту
Наш підхід перевертає звичну парадигму «LLM робить усе» й натомість передбачає таку схему:
Цей підхід чітко розмежовує обов’язки: LLM видобувають правила й обмеження з природної мови, а детерміновані розв’язувачі, як-от OR-Tools, Z3 і Pyomo, виконують оптимізацію та перевірку. Результат поєднує переваги обох підходів:
LLM | Розв’язувачі | Гібрид (LLM + розв’язувач) | |
|---|---|---|---|
Розуміння людських намірів у різних галузях | ✅ Відмінне | ❌ Немає | ✅ Відмінне |
Детермінована поведінка | ❌ Ні | ✅ Гарантовано | ✅ Так |
Математично доведена правильність міркувань і оптимізації з урахуванням численних обмежень | ⚠️ Ненадійна | ✅ Гарантовано | ✅ Так |
Придатність до аудиту та інтерпретованість | ⚠️ Ненадійна | ✅ Зрозуміла | ✅ Зрозуміла |
Стійкість до шуму й ін’єкцій у запитах | ❌ Вразлива | ✅ Несприйнятлива | ✅ Висока |
Ми почали із завдання, з яким стикаються деякі наші клієнти:
Перетворювати запити природною мовою на оптимальні рішення щодо ресурсів у реальному часі, суворо дотримуючись операційних, політичних і вартісних обмежень.
Це завдання лежить в основі сучасної логістики та ланцюгів постачання, зокрема планування персоналу, розподілу активів, маршрутизації, планування виконання замовлень і керування потужностями. Саме тут LLM і формальні розв’язувачі мають працювати разом, щоб створювати надійні системи. Для оцінювання ми створили контрольовані тестові сценарії, джерела даних і обмеження, а також 240 синтетичних запитів. Ось приклади:
Please revise the existing schedule following a cancellation. The target facility must be fully supplied by 24 December 2025. When possible, source inventory from a nearby warehouse and route it through a specific consolidation point. The earliest allowable start date is 14 December 2025.
Last-minute request: a VIP will arrive at location A in three hours. We need the required staff on site within two hours. Please adjust staff allocations while minimizing changes to the existing schedule.
Із запитів видно, що система має надійно видобувати й застосовувати жорсткі та м’які обмеження безпосередньо із запитів природною мовою:
Жорсткі обмеження не підлягають обговоренню (наприклад, найраніші дати початку, договірні умови та граничні потужності). Порушення будь-якого з них робить рішення недійсним.
М’які обмеження визначають побажання, як-от мінімізація затримок, зниження витрат і обмеження змін. Мета — оптимізувати рішення, не порушуючи жорстких меж.
Деякі аспекти цих задач оптимізації неможливо повністю визначити заздалегідь. Їх потрібно динамічно компонувати, використовуючи не лише заздалегідь визначені обмеження й цілі зі структурованої бізнес-логіки, внутрішніх документів та операційних даних, а й запит користувача.
Щоб зрозуміти ефективність різних методів у цих умовах, ми реалізували й порівняли три підходи.
Чиста LLM: за найпростішого підходу всі відповідні дані та запит користувача природною мовою передаються в одному запиті до LLM, яка має створити оптимальний план або розподіл. Це може працювати для невеликих задач або задач із нечисленними обмеженнями, але зі зростанням складності підхід перестає бути ефективним. Модель може ігнорувати обмеження, обирати неправильну пріоритетну ціль або створювати плани, які звучать розумно, але є нездійсненними, причому надійно виявити чи запобігти таким помилкам неможливо.
LLM + інтерпретатор коду: за цього підходу LLM інтерпретує запит і використовує інструменти для доступу до джерел даних та генерування виконуваного коду оптимізації. Це підвищує гнучкість і спостережуваність, але проблема надійності залишається. LLM усе одно має правильно перетворити обмеження на код, а незначні помилки в міркуваннях або коді можуть призвести до недійсних чи неоптимальних результатів, особливо зі збільшенням кількості обмежень.
Гібрид: LLM → структуровані обмеження → детермінований розв’язувач: третій підхід розмежовує обов’язки. LLM ніколи не «ухвалює» рішення, а допомагає формалізувати змінні, обмеження й цілі. Перевірений розв’язувач оптимізації застосовує обмеження, гарантує здійсненність і створює результати, які можна перевірити та піддати аудиту. Роль LLM обмежується перетворенням запитів природною мовою на явні структуровані обмеження за допомогою попередньо визначених схем. Ці обмеження автоматично компілюються в код розв’язувача, наприклад OR-Tools, який детерміновано обчислює здійсненне оптимальне рішення.
Ми протестували методи за допомогою кількох LLM, зокрема GPT-5, GPT-5.1 і GPT-5.2. Як і очікувалося, гібридний підхід перевершив альтернативи:
Метод | Точність розподілу | Середня затримка | Використано токенів на запит |
|---|---|---|---|
Чиста LLM | 70–78% | 62–190 с | ~175 000 |
LLM + інтерпретатор коду | 82–84% | 62–140 с | ~9 000 |
LLM → розв’язувач (гібрид) | 95–97% | 6–25 с | ~2 000 |
Наш гібридний метод демонструє істотне підвищення точності, більш ніж чотириразове зростання ефективності використання токенів і десятикратне скорочення затримки.
Наш наступний крок — створити універсальний багаторазовий інтерфейс, який перетворюватиме природну мову на структуровані семантичні представлення, а серверна частина транслюватиме їх у готовий для розв’язувача код. У цьому експерименті ми зосередилися на задачах лінійної оптимізації та оцінили підхід за трьома загальнодоступними наборами даних (NLP4LP, NL4OPT і IndustryOR).
Автономна LLM
Гібридний метод (LLM → структуровані правила → розв’язувач → перевірений результат)
Використати LLM, щоб видобути з вхідних даних змінні, обмеження й цілі та сформулювати структуровану задачу оптимізації.
Передати структуровану задачу й початковий запит до LLM для самоперевірки.
Перетворити структуровану задачу на код OR-Tools для обчислення оптимального розподілу.
Ми оцінили цей підхід за допомогою власних передових моделей, зокрема GPT-5.1, GPT-5 mini, GPT-5.1-Codex-Max і GPT-5.2, а також моделей із відкритим кодом, як-от Kimi K2, моделі GPT-OSS і MiniMax M2. Коробкові діаграми узагальнюють результати кожного методу.
Майже для всіх оцінених базових мовних моделей гібридний підхід стабільно дає точніші, сталіші та краще перевірні результати, ніж автономна LLM, узята за базовий рівень. Хоча абсолютна ефективність різниться залежно від моделі, відносний виграш гібридного підходу залишається стабільним. Це свідчить, що покращення зумовлені відокремленням розуміння природної мови від формальної оптимізації, а не здатністю окремої моделі до міркувань.
Точність
На NLP4LP і NL4OPT, які переважно складаються із задач лінійного програмування, гібридний метод досягає майже граничної точності й перевершує автономні запити до LLM. Замість «приблизно правильних» міркувань гібридна система стабільніше створює дійсні й правильно сформовані математичні постановки. На складнішому наборі даних IndustryOR точність обох методів знижується, але з різних причин. Чимало задач IndustryOR містять комбінаторні структури, як-от маршрутизація транспортних засобів, визначення послідовності завдань і розподіл персоналу, що виходять за межі можливостей лінійної оптимізації, які наразі підтримує наш серверний розв’язувач.
Аналіз характеру помилок показує, що автономні LLM часто порушують обов’язкові обмеження, як видно нижче:
Приклад 1:
Plain Text
Автономна LLM пропонує рішення з нижчим загальним вмістом жиру, але порушує вимогу, за якою страви з індичкою мають становити не більш ніж 40% усіх прийомів їжі. Гібридний підхід правильно застосовує це жорстке обмеження й повертає дійсну відповідь.
Приклад 2:
Plain Text
Автономна LLM знову пропонує рішення з меншою кількістю виписок, але перевищує гранично допустиму норму знеболювальних препаратів. Гібридний підхід правильно застосовує це жорстке обмеження й повертає дійсну відповідь.
Затримка й використання токенів
Дані про затримку та використання токенів виявляють важливу відмінність. Гібридний підхід має вищу середню затримку й використовує більше токенів, ніж одноразовий запит до LLM, однак це зумовлено архітектурними рішеннями, а не неефективністю.
Гібридний конвеєр охоплює:
Один або кілька викликів LLM для видобування структурованих змінних, обмежень і цілей.
Етап самоперевірки для виявлення внутрішніх суперечностей.
Хоча ці етапи створюють додаткове навантаження порівняно з одним запитом, затримка залишається обмеженою та передбачуваною, а після правильного формулювання задачі розв’язувач зазвичай працює швидко. Ця додаткова робота створює явні, багаторазові проміжні представлення, придатні до аудиту. Натомість автономні LLM стискають міркування в одну непрозору генерацію, перекладаючи витрати на повторні спроби, ручні перевірки й подальші збої. У майбутніх версіях це навантаження можна знизити завдяки:
Кешуванню видобутих схем.
Поетапному оновленню обмежень.
Удосконаленню оркестрації запитів і викликів.
Прозорість і придатність до аудиту
Зрештою, навіть коли обидва методи зазнають невдачі, сам характер збою докорінно відрізняється.
В автономної LLM збої часто непомітні: модель може повернути результат із малопомітною помилкою.
За гібридного підходу явне формулювання задачі робить збої прозорими й допомагає командам визначити, яка частина формулювання спричинила помилку.
У майбутніх версіях ці формулювання можна буде показувати в інтерфейсі, щоб користувачі могли перевірити їх до запуску розв’язувача. Така прозорість підвищує вимірювану точність і полегшує налагодження та вдосконалення системи, що вкрай важливо для реального впровадження.
Головний висновок
Результати всіх бенчмарків і більшості протестованих базових моделей підтверджують головний висновок нашої роботи:
LLM добре розуміють і передають наміри, але для забезпечення правильності критично важливі детерміновані розв’язувачі.
Гібридний підхід перетворює природну мову з джерела неоднозначності на надійний інтерфейс для математично обґрунтованого ухвалення рішень, наближаючи корпоративний ШІ до систем, які є не лише інтелектуальними, а й гідними довіри.
Корпоративні обмеження рідко існують у зручних схемах або ідеально сформульованих запитах. Вони розпорошені між базами даних, електронними таблицями, внутрішніми політиками й договорами. Запити користувачів можуть бути неповними, неоднозначними або суперечити бізнес-правилам. Щоб цей підхід працював у масштабі, ми створюємо багаторазовий серверний рушій, який перетворює цю складність на надійну корпоративну можливість.
По суті, цей рушій слугує формальною основою систем ухвалення рішень на базі ШІ та надає:
Символьну базу знань з адаптерами, які отримують бізнес-правила, обмеження, змінні та цілі.
Рівень перетворення, що компілює схеми в код розв’язувача.
Інтерфейси, які дають командам змогу переглядати, перевіряти й змінювати обмеження.
Хоча нинішні експерименти зосереджені на оптимізації, той самий метод можна поширити на логічну перевірку. Можливі бізнес-застосування:
Динамічно й ситуативно планувати, прокладати маршрути та розподіляти ресурси з дотриманням усіх операційних обмежень.
Генерувати відповіді й рекомендації, які незмінно відповідають бізнес-правилам.
Проєктувати й перевіряти складні 3D-об’єкти, відео та архітектури, виявляючи нездійсненні проєкти ще до виробництва.
Сучасний ШІ має великі можливості, але підприємствам цього замало: їм потрібні правильність, послідовність і контроль. Наша гібридна система з LLM і розв’язувачем — це крок до світу, у якому:
Агенти не вигадують правил або обмежень.
Логічні висновки й оптимізація є математично обґрунтованими.
Природна мова слугує універсальним інтерфейсом для детермінованих систем.