TL;DR
Модели хорошо решают логистику, но системно игнорируют опыт путешественника. Когда просишь составить маршрут, модель оптимизирует под "технически возможно" — и в итоге строит расписание, где 18-летний бэкпекер и 60-летний дедушка получают одинаково насыщенный (и одинаково изматывающий) план. Исследователи проверили 18 топовых моделей: лучший результат по "опыту путешественника" — 0.52 из 1.0. Это не погрешность, это системный провал.
Проблема в двух слоях. Первый: модель обрабатывает жёсткие ограничения (дата, бюджет, транспорт) значительно лучше, чем мягкие предпочтения (темп, комфорт, интересы). Именно потому что мягкие предпочтения нигде не записаны — они "подразумеваются". Второй: в длинном диалоге модель начинает забывать ранние требования — к 4-5 ходу разговора она уже не удерживает полный контекст того, что было согласовано в начале.
Решение простое: давать модели явный профиль путешественника — не только "куда и когда", но и "кто едет и как они хотят себя чувствовать". Плюс периодически суммировать накопленные требования, чтобы ничего не потерялось.
Схема метода
ПЕРЕД ЗАПРОСОМ: Заполни профиль путешественника (1 раз на поездку)
→ Кто едет: состав, возраст, особенности
→ Жёсткие ограничения: даты, бюджет, транспорт
→ Мягкие предпочтения: темп, физическая нагрузка, интересы, комфорт
ШАГ 1: Запрос маршрута с профилем → черновик плана
ШАГ 2: Запрос "симуляции опыта" → модель проигрывает план от лица путешественника
→ Что проверяет: усталость, темп, несоответствие предпочтениям
ШАГ 3 (при длинном диалоге): Суммирование требований → сводный список
→ Когда применять: каждые 3-4 обмена сообщениями
Все шаги выполняются последовательными запросами в одном чате.
Пример применения
Задача: Максим, 42 года, едет с женой и 8-летним ребёнком на неделю на Байкал. Привык к комфорту, ребёнок быстро устаёт, интерес — природа и местная кухня, а не музеи.
Промпт:
Ты — опытный туристический планировщик. Перед составлением маршрута изучи профиль путешественника.
**ПРОФИЛЬ ПУТЕШЕСТВЕННИКА:**
- Состав: мужчина 42, женщина 39, ребёнок 8 лет
- Физическая форма: средняя; ребёнок устаёт после 3 часов активности
- Темп: неспешный, максимум 2 крупные активности в день
- Комфорт: отели 4*, готовы доплатить за удобство
- Интересы: природа Байкала, байкальская кухня (омуль, позы), спокойные прогулки
- Не интересует: городские музеи, длинные переезды внутри дня
- Бюджет: ~150 000 руб. на троих без перелёта
**ЖЁСТКИЕ ОГРАНИЧЕНИЯ:**
- Даты: 10–17 августа
- Прилёт/вылет: Иркутск
- Не более 2 часов дороги между локациями
**ЗАДАЧА:**
Составь маршрут на 7 дней. После каждого дня укажи: суммарное время ходьбы, уровень нагрузки (низкий / средний / высокий), и оцени — подходит ли темп для ребёнка 8 лет.
После черновика — "сыграй" роль мамы из этой семьи и проверь план: что почувствуешь к концу дня 3? Есть ли что-то изматывающее или неудобное?
Результат: Модель сначала выдаст поднёвный маршрут с указанием нагрузки по каждому дню. Затем — "симуляцию" от лица участника поездки: выявит перегруженные дни, неудобные переезды или несоответствие детскому темпу. Это второй проход даст конкретные правки, а не абстрактные "возможно, стоит учесть".
Почему это работает
LLM по умолчанию оптимизирует под "технически выполнимо". Маршрут логичный? Всё открыто? Бюджет сходится? Готово. Но "усталость к вечеру третьего дня" — это не проверяемый факт, это субъективный опыт. Модель не моделирует его, если мы явно не попросим.
Мягкие предпочтения невидимы для модели, пока не записаны. "Мы с детьми" не сигнализирует автоматически "нагрузку нужно резать вдвое". "Любим природу" не означает "три горных перехода не подходят". Эти детали нужно сделать явными — тогда модель с ними работает.
Симуляция опыта — мощный рычаг. Когда просишь модель "сыграть роль" конкретного участника поездки и пройти план пошагово, она начинает замечать то, что пропустила при составлении: слишком длинный день, ресторан который "по дороге" но на деле +40 минут крюк, слишком мало времени на завтрак с ребёнком. Переключение перспективы помогает вытащить проблемы, которые невидимы в таблице расписания.
Рычаги управления: - Детализация профиля → чем конкретнее физические ограничения и интересы, тем лучше мягкое соответствие - Уровень нагрузки в запросе → попроси оценивать каждый день по шкале (низкий / средний / высокий) — это даёт структуру для проверки - Периодическое суммирование → в длинном диалоге каждые 3-4 сообщения пиши "Вот список всего что мы согласовали:" и вставляй накопленный список требований. Без этого модель начинает терять ранние договорённости - Симуляция опыта → можно варьировать роль: "проверь глазами 8-летнего ребёнка" или "оцени с точки зрения человека с больными коленями"
Шаблон промпта
Ты — опытный туристический планировщик. Перед составлением маршрута изучи профиль.
**ПРОФИЛЬ ПУТЕШЕСТВЕННИКА:**
- Состав и возраст: {кто едет}
- Физическая форма и ограничения: {особенности}
- Темп: {неспешный / активный / смешанный}, максимум {число} крупных активностей в день
- Комфорт: {уровень отелей, предпочтения по условиям}
- Интересы: {что важно увидеть / попробовать}
- Не интересует: {что исключить}
- Бюджет: {сумма и что включает}
**ЖЁСТКИЕ ОГРАНИЧЕНИЯ:**
- Даты: {от / до}
- Точки входа/выхода: {город или аэропорт}
- Ограничения по переездам: {максимальное время в дороге за раз}
- Особые требования: {визы, диета, доступность и т.д.}
**ЗАДАЧА:**
{Описание маршрута: направление, длительность, формат}
После черновика маршрута — выступи в роли {участника поездки из профиля} и пройди план пошагово. Отметь: есть ли что-то изматывающее, неудобное или не соответствующее профилю?
Что подставлять:
- {кто едет} — "пара 35+40" / "семья с двумя детьми 6 и 10 лет" / "группа друзей 7 человек"
- {участника поездки из профиля} — конкретизируй: "мама с артритом" / "8-летний ребёнок" / "интроверт который устаёт от людей"
- {особенности} — физические ограничения, которые влияют на маршрут
🚀 Быстрый старт — вставь в чат:
Вот шаблон для планирования поездки с профилем путешественника.
Адаптируй под мою поездку: {опиши свою поездку в двух словах}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит о составе группы, физических ограничениях и мягких предпочтениях — потому что именно эти данные определяют разницу между "технически правильным" и "комфортным" маршрутом.
Ограничения
⚠️ Симуляция — не гарантия: Модель проигрывает опыт путешественника на основе описания, а не реального понимания усталости. Проверка полезна, но не заменяет здравый смысл.
⚠️ Длинные диалоги требуют контроля: Чем дольше разговор о поездке, тем выше риск, что модель забудет ранние требования. Суммируй накопленные договорённости каждые 3-4 обмена — иначе то, что согласовали в начале, тихо исчезнет.
⚠️ Проверяй реальные данные: Модель не знает реальное расписание поездов, часы работы конкретных мест и актуальные цены. Маршрут — хорошая основа, но логистику нужно верифицировать вручную.
⚠️ Для нестандартных профилей — больше конкретики: Чем более специфичный путешественник (тяжёлая инвалидность, экстремально малый бюджет, очень нишевые интересы), тем больше явных деталей нужно давать. Модель плохо "угадывает" нетипичный контекст.
Как исследовали
Команда из HKUST и Tencent построила настоящий испытательный полигон: 40 китайских городов с полной базой данных транспорта (7,2 млн записей по городскому транспорту, 309K поездов, 38K рейсов), гостиниц, ресторанов, погоды и достопримечательностей. Всё это — фиксированный "песочница", в которой модели не могут выдумать несуществующий поезд или закрытый отель.
Интересен дизайн: 11 разных профилей путешественников — от бэкпекера-студента до семьи трёх поколений — чтобы проверить, учитывают ли модели кто едет, а не только куда. 153 сценария, 570 ходов диалога, четыре типа ситуаций: изменение планов пользователя, разрешение конфликтующих требований, форс-мажоры (погода, закрытие мест), долгосрочное удержание всех накопленных договорённостей.
Самое изящное в методологии — симулятор опыта: LLM-"оценщик" буквально "проживает" маршрут от лица профилированного путешественника, оценивая каждую активность по шкале 1-5 по физической нагрузке, темпу, бюджетному стрессу и соответствию интересам. Использовали четыре независимых судьи (Qwen, Claude, Gemini, GPT), брали медиану — чтобы убрать систематическое смещение отдельных моделей. Финальный вывод оказался неожиданным: даже лучшая модель (Gemini 3.1 Pro) набрала лишь 0.52/1.0 по опыту путешественника — при том что с жёсткими ограничениями справлялась на 0.90+. Разрыв огромный, и он явно не случаен.
Адаптации и экстраполяции
🔧 Мягкие vs жёсткие требования в любом планировании → не только в путешествиях
Тот же принцип работает везде, где LLM составляет план или расписание: ремонт квартиры, учебный план, контент-план на месяц. Модель хорошо держит жёсткие ограничения (дедлайн, бюджет), но игнорирует мягкие (уровень стресса, "хочу не работать по воскресеньям"). Решение то же — явно выделить оба слоя требований отдельными блоками.
🔧 Симуляция пользователя как универсальный инструмент проверки
"Сыграй роль клиента и пройди этот онбординг пошагово" / "Выступи в роли новичка и попробуй разобраться в этой инструкции" / "Прочитай это письмо глазами занятого CEO" — переключение перспективы помогает находить проблемы, незаметные автору.
🔧 Явное суммирование контекста в длинных диалогах
Находка про "забывание ранних требований" к 4-5 ходу актуальна для любого сложного проекта в чате. Рецепт: каждые 3-4 обмена добавляй блок "Вот все договорённости на сегодня:" с нумерованным списком. Это не костыль, это профессиональная привычка работы с LLM.
Ресурсы
Trip+: Benchmarking Agents in Personalized Interactive Travel Planning
Junle Chen, Wei Chen, Yehong Xu, Zhengjun Huang, Yuqian Wu, Zhoujin Tian, Kai Wang, Lei Wang, Xiaofang Zhou
HKUST, Tencent Hy, HKUST(GZ) · June 2026
GitHub: github.com/junle-chen/trip-plus
Сайт: junle-chen.github.io/trip-plus-site