TL;DR
Исследователи проверили, могут ли LLM восстанавливать пропущенные фрагменты GPS-треков, читая дорожную сеть. Вместо обычного "найди кратчайший путь" задача сложнее: дан трек с пропуском 500-30000 метров — восстанови что было между точками A и B, учитывая контекст движения (скорость, направление, вид транспорта) и ограничения дорог (односторонние, развязки).
Оказалось, что формат имеет значение больше объёма. LLM показали лучшие результаты не когда получили полные геометрии всех дорог, а когда дали компактное топологическое описание — список дорог, их связи, типы и направления. Топология без координат + направленные подсказки ("север", "юго-запад") превзошли сырые данные с километрами координат. Модели справились на уровне Google Maps, обойдя специализированные модели для треков.
Метод работает в два этапа через структурированные инструкции. Сначала LLM планирует пошаговую навигацию по ID дорог ("с дороги X на перекрёстке Y поверни на дорогу Z"), проверяя что путь связный. Потом для каждого шага генерирует точные координаты, привязываясь к геометрии выбранных дорог. Структура промпта (XML-теги, явные роли, псевдокод) убирает двусмысленность и работает как контракт — модель следует чёткому формату.
Схема метода
ЭТАП 1: Планирование пути (один промпт)
Вход:
- Начало/конец пропуска (координаты)
- Контекст до/после (скорость, направление, время)
- Вид транспорта
- Топология дорог (ID, названия, связи, типы, направления)
Выход: Пошаговая навигация
step_1: С дороги [ID=X, название] двигайся [направление] до перекрёстка [ID=Y]
step_2: На перекрёстке [ID=Y] поверни на дорогу [ID=Z]...
step_N: Прибудь в точку назначения
ЭТАП 2: Генерация координат (итеративно для каждого шага)
Вход:
- Описание шага из Этапа 1
- Геометрия дороги (список координат)
- Предыдущая сгенерированная точка
Выход: Список координат [[lat, lon], [lat, lon], ...]Ключевые принципы (применимы в чатах)
1. Двухэтапный workflow: план → детали
Проблема: LLM теряются в сложных задачах, где нужно и рассуждать, и быть точным одновременно.
Решение: Разделить на два запроса:
- Этап 1 — рассуждение, планирование, высокоуровневые решения
- Этап 2 — детальная реализация, следуя плану
Пример для другой задачи:
ЭТАП 1: "Составь структуру статьи про {тема}:
- Основные разделы
- Ключевые тезисы каждого раздела
- Логика переходов"
ЭТАП 2: "Теперь для раздела {название} напиши полный текст,
следуя тезисам: {тезисы из Этапа 1}"Зачем это работает: Модель в первом запросе думает о логике, во втором — о деталях. Без смешивания.
2. Компактное структурированное представление > сырые данные
Находка: Исследователи дали LLM дорожную сеть в разных форматах:
- Сырые геометрии — все координаты всех дорог (25К токенов) → плохо
- Топология + направления — только связи дорог, типы, компасные направления (11К токенов) → лучше всех
Принцип: Уберите избыточные детали, оставьте структуру и ориентиры.
Применение в чатах:
❌ Плохо — дать LLM огромный неструктурированный текст:
"Вот весь сайт компании (50 страниц текста).
Найди информацию о продукте X"✅ Хорошо — дать карту навигации:
"Вот структура сайта:
- /products → [Product A, Product B, Product X]
- /about → [Team, History]
Product X находится по пути: products > Product X
Описание: {краткое резюме}
Ссылки: {релевантные секции}"Направленные подсказки (как компасные направления в исследовании) — добавьте контекстные метки:
- "Этот раздел про прошлое, следующий — про будущее"
- "Аргумент #1 против, #2 — за"
- "Более техническая версия → менее техническая версия"
3. Структурированные инструкции как контракт
Инсайт: XML-теги, псевдокод, явные роли в промптах — это не программирование, а техники промптинга. Они убирают двусмысленность.
Исследователи использовали такую структуру:
<Task>Восстанови маршрут
<Constraints>
- Каждый шаг должен указывать road_id и intersection_id
- Направление: север/юг/восток/запад
- Финальная точка: {coordinates}
Применение: Когда нужен точный формат вывода, дайте контракт.
Пример для анализа конкурентов:
<Task>Сравни наш продукт с конкурентами
Модель будет следовать структуре, не импровизируя формат.
4. Preference-aware reasoning
Находка: LLM могут планировать не только "кратчайший путь", но и учитывать предпочтения, используя внутренние знания.
Пример из исследования (Urban Foodie, Мельбурн):
- Google Maps: прямой путь по главным улицам
- LLM система: маршрут через переулки с ресторанами, включая Hardware Lane (известное место в Мельбурне) — хотя эта улица не была в списке POI
Принцип: LLM интегрируют контекстные знания в рассуждения, если правильно сформулировать задачу.
Применение в чатах:
Задача: Спланируй 3-дневную поездку в Санкт-Петербург
Мои предпочтения:
- Интересуюсь архитектурой модерна
- Избегаю толп туристов
- Люблю атмосферные кафе
- Удобно передвигаться пешком/метро
Контекст: Я уже был в Эрмитаже и Петергофе
Структура ответа:
День X:
Утро: {место} — {почему подходит под предпочтения}
День: {место}
Вечер: {место}
Маршрут: {как добраться, примерное время}
Бонус: {скрытая жемчужина рядом, которую турист может пропустить}LLM будет предлагать не "топ-10 из TripAdvisor", а контекстуальные решения с учётом ваших критериев.
Ограничения принципов
⚠️ Требуется инфраструктура для полной реализации: Само исследование про GPS-треки требует API OpenStreetMap, обработку геоданных, код. Обычный пользователь чата не будет восстанавливать треки. Ценность — в извлечённых принципах, не в прямом копировании системы.
⚠️ Региональные bias: LLM показали разницу до 50% между регионами (лучше для Европы/Северной Америки, хуже для Африки/Южной Азии). В реальных задачах учитывайте что модели могут хуже работать с незападными контекстами.
⚠️ Лучше для структурированных задач: В исследовании LLM отлично справились с driving/cycling (структурированные маршруты), хуже с walking/hiking (свободное движение). Принципы работают лучше когда есть ясная логика и ограничения.
Как исследовали
Команда собрала 4000+ реальных GPS-треков с OpenStreetMap (2024 год, чтобы избежать утечки данных) из 72 городов на всех континентах. Активности: пешком, на машине, велосипед, автобус, поезд, лодка, самолёт. Для каждого трека создали два варианта — с маленьким пропуском (500 м) и большим (до 30 км).
Сравнивали LLM (GPT-4.1, Claude 4 Sonnet, Llama 4, DeepSeek V3, Qwen3) с Google Maps и специализированной моделью TrajFM (обученной на 2.4М треков в Китае).
Ключевой эксперимент: Дали один и тот же пропуск, но в разных форматах:
- Сырая дорожная сеть (все координаты) → 25К токенов
- Топология + направления → 11К токенов
Результат: компактный формат на 8-10% лучше, при этом в 2+ раза меньше токенов.
Почему это важно: Показывает что LLM нужна не максимальная информация, а правильная структура. Это противоречит интуиции "больше контекста = лучше результат".
Удивительная находка: GPT-4.1 достиг 63.3% точности (F1), почти как Google Maps (65%), но TrajFM (специально обученная модель) показала лишь 15.3%. Оказалось, что специализированная модель не генерализуется на новые регионы — она просто рисовала прямую линию или генерировала координаты в совершенно других городах.
Анализ по этапам: Исследователи проверили каждый этап:
- Связность пути — 76% треков у GPT-4.1 имели полностью связный путь (все дороги соединены)
- Соответствие сети — почти 100% сгенерированных ID дорог существовали в карте (нет галлюцинаций)
- Геометрическое соответствие — 84-87% координат попали на выбранные дороги
- Точность направления — отклонение ~55° (в пределах правильного квадранта)
Это показывает что LLM действительно понимают топологию дорожной сети и систему координат, не просто генерируют случайные числа.
Bias анализ: Африка vs Северная Америка — разница до 50% для некоторых моделей. Это коррелирует с социоэкономическим статусом регионов (меньше данных в обучающих корпусах). Тот же паттерн с активностями: driving/bus (структурированные пути) — хорошо, hiking/boat (свободное движение) — плохо.