Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM научили составлять допустимые планы и исправлять их после программной проверки. CityPlanner из работы Beihang University в целом обошёл эвристики, специализированное обучение с подкреплением и универсальных LLM-агентов, хотя работа не прошла рецензирование и числа в ней получили сами авторы. Для продуктовых команд ценность не в градостроении как таковом, а в схеме: вынести проверку правил в исполняемую среду и отдельно обучать создание и исправление решения.
Файлы и оценщик заменяют специальный API задачи
Городское планирование здесь сводится к выбору действий из конечного набора. Агент распределяет назначение участков, выбирает новые дороги или размещает зарядные станции, а результат должен одновременно соблюдать ограничения и набирать высокую целевую оценку.
UrbanSandbox представляет каждую задачу как набор файлов. В каталоге input/ лежат данные города, доступные действия, правила и программа-оценщик. В work/ агент сохраняет расчёты и сценарии, а в outputs/ записывает итоговый план.
Агент работает через команды оболочки: читает файлы, запускает сценарии и отправляет результат оценщику. Тот проверяет формат и ограничения, рассчитывает целевую оценку и возвращает диагностические сообщения. Качество решения определяет программа, а не правдоподобие текстового ответа.
Такой интерфейс отделяет общую механику агента от правил конкретной задачи. Чтобы добавить новый тип планирования, разработчику нужно подготовить входные файлы, формат результата и оценщик, но не обязательно проектировать новый набор инструментов для модели.
Полная траектория работы агента остаётся неудобной для обучения: в контексте копятся неудачные команды, устаревшие наблюдения и отвергнутые планы, а награда приходит лишь после итоговой проверки. CityPlanner делит эту траекторию на две короткие задачи. BuildPlan строит исходный допустимый план, а ImprovePlan получает текущий вариант и диагностику оценщика, после чего предлагает исправление.
Обе задачи обучают с отдельной наградой за итоговый план. При запуске BuildPlan создаёт первый вариант, затем ImprovePlan несколько раз пытается его улучшить. Система принимает новую версию только тогда, когда она допустима и превосходит лучший сохранённый результат.
Метод проверяли на базе Qwen3-8B и на 5 670 примерах из OpenStreetMap по трём задачам в городских регионах Китая. Сравнение охватывало эвристики, специализированные модели с обучением с подкреплением и универсальных LLM-агентов, которые работали через ту же среду.
Короткие задачи обучаются лучше полной траектории
Основная метрика работы — целевая оценка плана: для каждой задачи её рассчитывает собственный оценщик, и большее значение означает лучшее решение. CityPlanner занял первое место в восьми из девяти сочетаний задачи и сложности. Исключением стало строительство дорог на малых примерах, где лучший результат показала эвристика GRASP.
Главное различие проявилось не между исходными моделями, а между способами обучения. Переход от GRPO на полных траекториях к раздельному обучению BuildPlan и ImprovePlan повысил долю допустимых решений в среднем на 8,3 процентного пункта. Средняя целевая оценка выросла на 20,7%.
Повторное улучшение во время запуска добавило ещё 4,9% к целевой оценке. Замена базовой Qwen3-8B на Qwen3-14B дала ещё 2,8%, то есть архитектура процесса повлияла на результат сильнее, чем одно увеличение модели.
Отдельное сравнение с замороженной DeepSeek показало, что сама исполняемая среда тоже влияет на надёжность. Доступ к файлам, оценщику и циклу исправлений дал лучшие результаты на всех задачах, чем текстовый ответ и два варианта поиска программ. Значит, часть выигрыша можно получить до специализированного обучения модели.
Когда эта схема меняет план разработки агента
Работа предлагает практичную архитектуру для задач, где результат можно записать в структурированном виде и однозначно проверить программой. Это могут быть расписания, конфигурации, распределение ресурсов или набор действий под бюджетом. Ключевое условие — оценщик должен возвращать не только общий балл, но и диагностику, по которой агент исправит решение.
Первый шаг для команды — не обучение модели, а контракт среды. Нужно разделить неизменяемые входные данные, рабочие файлы и итоговый результат, затем сделать детерминированную проверку формата и ограничений. Такой каркас позволяет испытать готовую LLM и понять, достаточно ли цикла «создать — проверить — исправить».
Раздельное обучение имеет смысл, если один и тот же класс задач решается регулярно. Тогда примеры построения начального решения не смешиваются с примерами локального улучшения, а короткая траектория облегчает распределение награды между действиями агента. Во время запуска стоит хранить лучший допустимый вариант отдельно: это не даёт неудачному исправлению испортить уже найденный результат.
CityPlanner не заменяет специализированный оптимизатор во всех случаях. Эвристики остались конкурентоспособными, а весь эксперимент охватывает задачи одного типа: выбор подмножества пространственных действий по данным OpenStreetMap. Метод также требует нескольких обращений к LLM и оценщику, поэтому работает медленнее прямого запуска небольшой политики и не гарантирует оптимальное решение.
Планы стоит менять там, где команда собиралась поручить LLM длинную последовательность действий и выдать награду только в конце. CityPlanner показывает более управляемый путь: сначала стандартизировать исполняемую среду, затем разделить построение и исправление, а длинный процесс собрать из этих двух навыков уже при запуске.
Источники
Иллюстрация: рисунок из статьи «CityPlanner: A Sandbox Agent for Executable Urban Planning», Wentao Zhang, Jingyuan Wang, Zetong Zhou и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
