Встречаем маршруты «Прогулочный» и «Оживлённый» в Яндекс Картах, или Как мы учили модель понимать предпочтения людей

Год назад я рассказывал ^[1], как Яндекс Карты научились учитывать рельеф и лестницы при построении пешеходных маршрутов. Но альтернативные варианты по-прежнему выглядели для пользователя как просто «ещё один путь, только дольше» — и люди не раздумывая выбирали самый быстрый. Теперь у каждого альтернативного маршрута появилось имя и характер: например, «Быстрый», «Прогулочный», «Оживлённый» или «Без лестниц».

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

Что на самом деле важно пешеходу

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

Проанализировав, на что именно обращают внимание ^[2] пользователи, мы поняли, что время, которое прежде использовалось как единственный критерий, было далеко не единственным. Кому-то важно избежать лестниц, кому-то — пройти через парк, кому-то — переждать жару на остановке с кондиционером. Один и тот же человек в разных ситуациях хочет разного.

Так появилась идея: вместо набора безымянных альтернатив — пул маршрутов с понятными характеристиками. Каждому маршруту — имя, которое сразу объясняет, чем он полезен.

Большинство категорий считаются по правилам поверх уже имеющихся фичей (признаков) маршрута. «Без лестниц» — лестниц нет совсем. «Меньше лестниц» — их меньше, чем в самом быстром варианте. «С пандусами» — на всех лестницах есть пандусы. «Полегче» — оптимизировано по рельефу. «Комфортный» — учитывает обогреваемые остановки, крытые пространства и время ожидания транспорта с кондиционером (доступен пока не везде — про него отдельно расскажем как-нибудь). «Быстрый» — самый быстрый :) «Оптимальный» — хороший сразу по нескольким критериям. Пожалуй, проще было только написать «Альтернативный» на каких-то наименее выделяющихся вариантах — что мы и сделали.

А вот сложнее всего оказалось с двумя — «Прогулочный» и «Оживлённый».

Когда правила не работают

«Прогулочный» — это маршрут через парки и набережные, где по пути можно встретить интересные места — если для этого не нужно слишком далеко отклоняться от маршрута. «Оживлённый» — по оживлённым улицам, подальше от дворов, промзон и железнодорожных путей.

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

Вот тут и понадобились фичи. Базовые отчасти уже были — длина, время, лестницы. Профиль рельефа пришлось превратить в понятные модели величины: объём подъёмов и спусков, суммарно потраченные калории. Но для «Прогулочного» и «Оживлённого» этого мало. Нужно было понять, что вообще стоит вдоль пути — парки и скверы, коммерческая инфраструктура, промзоны, степень людности — и представить всё это в виде чисел, с которыми может работать модель.

Модель, которая обучает модель

Ключевым требованием к модели была высокая скорость инференса — маршруты не предрассчитываются заранее, а строятся на лету по запросу пользователя. Это сразу исключило архитектуры вроде DSSM — они идеальны для поиска среди заранее подготовленных эмбеддингов, но не для предсказаний на лету. Остановились на CatBoost: отлично работает на качественно подготовленных данных, нетребователен к ресурсам и, что важно, — быстро отвечает. Как раз то, что нам нужно!

Для обучения ^[3] модели нужна разметка. Кто-то должен посмотреть на маршрут и выставить оценку. Казалось бы, асессоры. Но задача субъективная, асессоров нужно долго калибровать, а маршрутов — тысячи. Дорого и медленно.

Мы решили зайти иначе: пусть разметку сделает LLM. Не устаёт, работает быстро — если правильно объяснить задачу. Вопрос был в том, как вообще описать маршрут текстом, чтобы модель поняла, о чём речь.

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

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

Первая версия промпта была наивной: перечисляли свойства и просили модель «оценить прогулочность». Но на одном и том же маршруте оценки скакали от запроса к запросу. Начали разбираться.

Сначала покрутили температуру генерации — чем она ниже, тем предсказуемее отвечает модель. Ответы стали воспроизводимее, хотя качество всё ещё оставляло желать лучшего. Тогда занялись разбором ошибок: смотрели на случаи, где модель промахивалась сильнее всего, читали её цепочку рассуждений и правили промпт.

Один из таких разборов запомнился. Модель занижала «прогулочность», если видела «0 пешеходных переходов». Логика ^[4] у неё была своя: раз переходов нет, значит пользователю придётся перебегать дорогу. Вывод логичный, но неверный — наш сервис никогда не построит маршрут через проезжую часть. Модель просто не знала этого.

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

Можно ли доверять оценкам LLM?

Мы заказали разметку у асессоров — не чтобы заменить LLM, а чтобы проверить, насколько ей можно доверять.

Каждому асессору показывали карточку маршрута:

Геометрия маршрута на карте. Цвет линии указывал на тип участка пути: прогулочная зона, пешеходный переход или универсальная дорога — доступная как для пешеходов, так и для велосипедистов.

Популярные организации поблизости. Не все — только наиболее заметные и значимые: перечисление всего подряд создавало бы информационный шум.

Зоны повышенной посещаемости — выделены жёлтыми гексагонами. Чем насыщеннее цвет, тем выше активность.

Основные параметры маршрута — длина, время, количество лестниц.

Задача: выставить оценки от 1 до 5 по «прогулочности» и «оживлённости». Инструкция для асессоров во многом повторяла наш финальный промпт — чтобы критерии совпадали.

Каждый из 12 000 маршрутов в Москве и Нижнем Новгороде оценили по три асессора независимо друг от друга. По результатам расчета согласованности оценки «оживлённости» отличались на 17%, а «прогулочности» – на 21%. Люди видят одно и то же по-разному, это ожидаемо.

А вот LLM ошиблась относительно асессоров на 14% для «оживлённости» и 19% для «прогулочности» — считали MAPE, среднюю абсолютную процентную ошибку ^[5]. Примерно столько же, сколько асессоры расходятся друг с другом.

Эта разметка не только подтвердила, что LLM справляется с задачей, — она помогла ещё немного отточить промпт и выбрать оптимальную LLM для финальной генерации датасета.

Будет ли это работать в других городах?

Когда промпт был готов, мы разметили с его помощью маршруты в обоих городах. Сразу возник вопрос: как масштабировать это дальше? Настройка промпта и калибровка LLM — самая долгая и дорогая часть работы. Если её нужно повторять ^[6] для каждого города заново, масштабироваться не получится.

Мы проверили гипотезу: способна ли LLM, настроенная на московских маршрутах, давать качественные оценки для другого города? Обучили две CatBoost-модели на LLM-разметке — локальную модель только на данных Москвы и универсальную на данных обоих городов. Протестировали на нижегородской выборке.

Универсальная модель оказалась точнее на 2 п. п. Метрики классификации — true positive rate и false positive rate — тоже улучшились. Качество на московской выборке не просело.

Это означает вот что. LLM с московским промптом не просто экстраполирует данные — она использует более глубокое, контекстное понимание «прогулочности» и «оживлённости», которое работает и в другом городе. Переделывать промпт не нужно. Для нового города достаточно прогнать LLM на местных маршрутах с тем же промптом, получить разметку и дообучить CatBoost. А это быстро и дёшево.

Сюжетный поворот: проблема разнообразия маршрутов

После обучения классификатора мы столкнулись с неожиданной проблемой: классификатор исправно работал, но почти не находил маршрутов с высокими оценками «прогулочности» или «оживлённости». Маршруты с базовыми классами — «Без лестниц» и «Полегче» — тоже находились гораздо реже, чем ожидалось.

Причина оказалась в алгоритме поиска альтернатив. Оптимальный путь ищется через минимизацию функции штрафов — она учитывает тип дороги и другие характеристики отдельных участков. Штрафы не были настроены на приоритизацию «прогулочных» или «безопасных» участков, поэтому такие маршруты просто не появлялись в выдаче.

Решение нашлось благодаря уже подготовленному датасету с признаками. Для каждого участка мы определили его релевантность по отношению к определённой категории зон и на этой основе скорректировали функцию штрафа. Например, для участков через парковые зоны уменьшение штрафа в 1,5 раза позволило увеличить долю выдач с прогулочной альтернативой на 7 п. п. Аналогичные действия мы проделали для других признаков. За несколько итераций поиска удалось найти достаточно альтернатив — что мы проверили численно.

Как мы уложились в секунду

На этапе LLM-разметки мы работали с максимально детальными данными — хранили все организации с их типами, названиями и координатами, точную геометрию парков, промзон и других объектов. Для разметки это нормально. Но когда дошло до продакшена, выяснилось: считать фичи на таких данных — несколько секунд на маршрут. Это неприемлемо.

Данных два типа. Первый — организации: торговые центры, рестораны, складские компании — всё, что встречается вдоль пути. Второй — полигональные объекты: парки, промзоны, скверы. Их геометрия в геоданных описывается тысячами координат границ. Считать по ним быстро не получится.

Для организаций решение простое: вместо точных координат каждого объекта храним количество организаций каждого типа внутри гексагона. Модели важна не точная точка на карте, а сколько таких объектов рядом с маршрутом.

С полигонами сложнее. Граница парка на карте превращается в лесенку из гексагонов — часть территории попадает не туда. Чтобы снизить погрешность, мы разделили гексагоны на два типа: граничные — те, что на краю полигона, и внутренние — те, все соседи которых принадлежат тому же полигону. Граничные учитываем иначе, чем внутренние. Это позволило сохранить точность и при этом хранить в разы меньше данных.

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

Но и на этом не остановились — добавили кэширование и параллельную обработку нескольких маршрутов, что позволило ещё на порядок сократить время ответа сервиса.

Каков же итог?

Мы масштабировали выборку до 17 городов-миллионников (включая российские и зарубежные). В каждом сгенерировали по несколько тысяч маршрутов с разными профилями: разной длины, разных типов местности и окружения.

Обучение CatBoost на такой выборке сразу показало проблему: модель переобучалась, запоминая шумы в LLM-разметке вместо общих закономерностей. Лечили двумя способами — более строгой регуляризацией, ограничением, которое не даёт модели слишком точно подгоняться под обучающие данные, и ранней остановкой, когда обучение прекращается, как только качество на валидации перестаёт расти.

Финальные числа получились такие. Относительно LLM-разметки CatBoost ошибается на 7–9% для «оживлённости» и на 12–14% для «прогулочности». Относительно асессоров — на 14,5% и 18% соответственно.

Это отличный результат. И вот почему. Помните, что асессоры между собой расходятся на 17% и 21%? Ошибка модели укладывается в этот же диапазон. Требовать от алгоритма точности выше, чем согласованность между людьми в субъективной задаче, просто бессмысленно. Модель научилась воспроизводить те самые субъективные, «человеческие» предпочтения, но в пределах продуктового видения.

Пайплайн, который мы описали, уже работает в Яндекс Картах — «Прогулочный» и «Оживлённый» доступны пользователям.

Отдельная история — «Комфортный» маршрут. Там своя задача: единый индекс температурной комфортности, обогреваемые остановки, крытые пространства, время ожидания транспорта. Расскажем как-нибудь отдельно!