Исследователи NTU Singapore сократили создание софта для решений с месяцев до часа

Команда Наньянского технологического университета в Сингапуре (NTU Singapore) представила ИИ-фреймворк, который автоматически собирает сложное ПО для принятия решений. По словам исследователей, на разработку такой системы раньше уходили месяцы работы узких специалистов. Теперь хватает примерно часа. Если цифра подтвердится на практике, это сжатие срока на два порядка.

Что известно о разработке

В опубликованном описании мало деталей, и это важно сразу зафиксировать. Из него следует, что фреймворк берёт на себя задачу, которую обычно решает связка предметного эксперта и инженера: превратить постановку проблемы в рабочую программу, выбирающую действия при заданных ограничениях и целях. Классические примеры такого ПО: планирование маршрутов, расписания, распределение ресурсов, управление запасами. Какие из них охватывает фреймворк, в анонсе не сказано.

Ключевые факты, которые можно считать установленными:

• Разработчик: NTU Singapore.
• Что автоматизируется: создание сложного ПО для принятия решений.
• Прежний срок: месяцы специализированной инженерной работы.
• Заявленный срок с фреймворком: около одного часа.
• Тип системы: ИИ-фреймворк. Лежит ли в основе большая языковая модель, неизвестно.

Почему такие системы строятся месяцами

Узкое место здесь не написание кода как такового. Решающую программу нужно сначала формализовать: определить переменные, ограничения и целевую функцию, затем выбрать подходящий алгоритм, настроить его и проверить на реальных данных. Каждый шаг требует людей, которые одновременно понимают бизнес-задачу и математический аппарат. Таких людей мало, а итерации с заказчиком растягивают проект.

Если фреймворк действительно берёт на себя формализацию и подбор решателя, экономия получается не на строчках кода, а на цикле согласований. Именно поэтому заявленный срок в час выглядит смелым: пока непонятно, входит ли в него валидация результата или только генерация первой версии.

Чего в сообщении не хватает

Число «около часа» без контекста мало что говорит. Нет ответов на вопросы, от которых зависит вся ценность работы:

• На каких задачах и в каком количестве проводились замеры.
• Сравнивали ли результат с решением, написанным человеком, по качеству и стоимости найденных решений.
• Сколько ручной подготовки требуется на входе: описание задачи на естественном языке, формальная спецификация или готовые данные.
• Как система ведёт себя на нестандартных ограничениях и как обнаруживает собственные ошибки.
• Доступен ли код, и в какой форме работа будет опубликована.

До появления статьи или препринта с этими данными оценивать результат следует осторожно. Автоматическая генерация решающего ПО подводит чаще всего именно на неочевидных ограничениях: модель выдаёт программу, которая работает и выглядит убедительно, но нарушает правило, о котором никто не сказал вслух.

Что проверить до внедрения

Для компаний, у которых есть собственные задачи планирования и оптимизации, практический порядок действий такой. Сначала возьмите одну уже решённую задачу с известным эталоном и сравните с ним результат автоматической сборки. Затем проверьте, как инструмент реагирует на изменение условий: добавьте новое ограничение и посмотрите, потребуется ли пересборка с нуля. Наконец, оцените, кто будет проверять выходные данные. Если ответ «никто», час разработки превращается в риск, а не в экономию.

Следить стоит за публикацией полной работы NTU Singapore. Там должны появиться бенчмарки, ограничения подхода и условия доступа, и именно по ним станет ясно, сократился ли срок разработки для всех задач или только для удобных демонстрационных.