Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
ROAM составляет многодневные туристические планы, которые учитывают географию и часы работы мест. В нерецензированном препринте Ye Zihao и Lin Xiaoheng из City University of Hong Kong, где все числа получили сами авторы, система включила в трёхдневный план в среднем 27,5 места против 19,3 у обычной LLM. Для продуктовой команды вывод практический: модели можно оставить язык и предпочтения, а проверяемые ограничения передать обычным алгоритмам.
Поиск задаёт набор мест, но не строит маршрут
Сначала LLM превращает свободный запрос в структуру: темы поездки, обязательные и нежелательные места, время начала и окончания дня, способ передвижения. Город и исключения система применяет как жёсткие фильтры, а не как пожелания внутри подсказки.
Затем ROAM ищет подходящие достопримечательности в подготовленной базе. Модель BGE-small-zh-v1.5 сопоставляет смысл запроса с названиями, категориями, адресами и описаниями мест. Если запрос слишком общий и смысловое сходство мало помогает, система собирает кандидатов по категориям с поправкой на рейтинг.
На этом роль поиска заканчивается. Он отвечает на вопрос, какие места подходят человеку, но не решает, в какой день и в каком порядке их посещать. Именно смешение этих задач часто заставляет LLM ставить удалённые районы рядом только потому, что их достопримечательности часто упоминают вместе.
ROAM строит граф близости, находит в нём плотные группы и объединяет их по дням через кластеризацию K-means. После этого отдельный решатель задачи коммивояжера упорядочивает остановки по реальным дорожным расстояниям. Рейтинг места немного снижает его условную стоимость, поэтому кратчайший путь не вытесняет более привлекательные точки.
Готовый порядок ещё не считается планом. Система рассчитывает прибытие и длительность посещения, ищет точки, куда маршрут не успевает до закрытия, а затем меняет их местами. Если исправить день перестановками нельзя, неподходящее место удаляется.
Погода, часы работы, дорожные расстояния и советы по способу передвижения попадают в контекст только после оптимизации. LLM оформляет результат как JSON, а отдельный разборщик проверяет структуру, число дней и порядок времени. При просьбе заменить место агент снова запускает поиск, маршрутизацию и проверку выполнимости, а не редактирует текст изолированно.
Систему проверяли на четырёх китайских городах, базе из 510 достопримечательностей и 36 запросах; все поездки длились три дня. Сравнивали полный конвейер, обычную LLM без базы и вариант с поиском, но без маршрутизации и исправления времени. Во всех случаях использовали DeepSeek V4 Flash, поэтому сравнение относится прежде всего к архитектуре.
Оптимизатор сократил переезды, а проверка времени убрала скрытые ошибки
Условная стоимость участка маршрута снизилась с 2 101 до 677 метров относительно варианта только с поиском. Это не общая длина поездки, а показатель, который учитывает расстояния между соседними остановками и по-разному взвешивает ходьбу, велосипед и автомобиль. Чем он ниже, тем меньше маршрут мечется между удалёнными точками.
Разбор отдельных компонентов показал, что основной вклад внесло пространственное разбиение и упорядочивание остановок. Без него дни снова смешивали удалённые районы. Если убрать исправление временных окон, примерно 30% посещений приходились на время после закрытия, хотя формально план сохранял высокое число мест.
Смысловое соответствие запросу почти не изменилось между подходами. ROAM улучшил не понимание предпочтений, а исполнение плана после выбора кандидатов. Поправка на рейтинг также почти не повлияла на сводные метрики, хотя без неё маршрут реже отдавал приоритет лучше оценённым местам.
Погода выявила зависимость от качества каталога. Там, где в базе хватало закрытых помещений, система заменяла уличные точки и сохраняла плотный маршрут. В Shanghai набор таких мест оказался беднее, поэтому ROAM вернул более короткий план вместо выдуманных альтернатив.
Работа меняет архитектуру планировщика, но не выбор модели
ROAM не даёт основания искать более крупную LLM ради географической точности. В этой задаче модель полезна на границах конвейера: она разбирает намерение, помогает выбрать кандидатов, объясняет результат и понимает правки. Расстояния, расписание и допустимость маршрута лучше хранить как состояние процесса и пересчитывать детерминированно.
Такое разделение подходит не только туризму. Тот же принцип применим к выездному обслуживанию, доставке, расписаниям и подбору ресурсов: LLM принимает запрос на естественном языке, а специализированный решатель отвечает за ограничения. После изменения пользователь получает не отредактированный рассказ, а заново проверенный план.
Пока это ориентир для прототипа, а не готовое подтверждение производственной надёжности. Проверка была офлайн, без оценки путешественниками и с одним запуском каждого запроса; система также рассчитывала поездку одного человека в одном городе без очередей, билетов и движения в реальном времени. Команде всё равно придётся проверять собственный каталог, внешние сервисы и поведение на противоречивых запросах.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
