Что может быть проще, чем сгенерировать голосовую подсказку для навигатора? Считаем угол поворота — озвучиваем манёвр. Именно так наша система и работала годами, пока не обросла таким количеством эвристик и региональных «костылей», что её поддержка стала дороже разработки. Добавление нового правила для одной страны ломало логику в другой, а простая задача «отличить плавный изгиб от поворота» превращалась в детектив.

Меня зовут Дмитрий, и я руковожу ML‑разработкой в команде автонавигации Яндекс Карт. Вместе с моим коллегой Альбертом Юсуповым @al-iusupov в этой статье мы поделимся историей полного переосмысления системы генерации дорожных аннотаций. Расскажем, почему решили отказаться от десятков хитрых условий в коде, а также почему заманчивая идея отдать всё на откуп большим нейросетям (VLM, LLM) провалилась. И, наконец, как пришли к элегантному решению: создали уникальный датасет с помощью сотен водителей‑экспертов и обучили быструю и точную ML‑модель, которая работает по принципу «меньше, но лучше».

Какую проблему решают дорожные аннотации

В процессе поездки водитель видит карту и маршрут — этого уже достаточно, чтобы как‑то доехать из пункта А в пункт Б. Но поездка на автомобиле требует много внимания, которое теряется каждый раз, когда водитель смотрит вместо дороги на экран телефона. Чтобы водителю не приходилось отвлекаться от дороги, в каждом современном навигаторе есть голосовые подсказки. Сразу нужно уточнить, что под ними в рамках этого рассказа я буду понимать только подсказки, помогающие следовать вдоль маршрута и не сходить с него. Предупреждения про школы, камеры, дорожные события остаются за рамками повествования.

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

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

Зачем чинить то, что работает

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

Но если посмотреть на эту дорогу не по карте, а в реальности, то в данном случае аннотация будет только отвлекать от дороги, потому что в физическом мире курс движения очевиден.

Чтобы не спамить аннотациями в аналогичных местах, можно придумать эвристики: например, на основе класса дороги, которая ответвляется. Мысль очень простая: если от основного курса движения ответвляется дорога низкого значения (например, дворовая дорога), то можно о таком потенциальном съезде ничего не говорить. В большинстве случаев водитель не хочет знать о том, что «вот здесь поверни налево, иначе уедешь во двор, а потом ещё вот тут и тут». Поэтому развилки имеет смысл аннотировать, только если класс дорог на развилке как мини��ум не хуже того, который идёт по маршруту. 

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

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

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

В данном случае дорога сначала идёт немного направо и потом поворачивает налево. Если измерить углы поворота, то аннотация будет примерно такой: «Держитесь правее, а затем поверните налево», но в этом случае большинство водителей уедут на съезд направо. А там потом даже развернуться негде. Пришлось снова придумывать дополнительные эвристики, чтобы корректно обрабатывать и такие случаи.

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

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

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

Как мы победили текущие проблемы

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

Чтобы понять, какие подсказки нужны (или не нужны) водителям, мы провели заезды с водителями в режиме «ралли». То есть водитель видит маршрут в начале поездки, а в процессе езды у него нет доступа к навигатору. Рядом сидит человек в роли штурмана: он видит маршрут, карту, текущее местоположение и сам словами формулирует указания водителю о том, куда ехать. Всё общение конспектируется и анализируется. На роль штурмана брали человека, прекрасно знающего район маршрута, чтобы ориентиры и указания были максимально ёмкими. Водители были разного уровня подготовки — как новички, так и опытные.

После серии таких заездов стало видно, что глобально дорожные ситуации можно разделить на три класса:

1. Манёвр озвучивать не нужно (достаточно держаться своей полосы), несмотря на то, что технически есть разные варианты, куда поехать.

2. Достаточно озвучить простой манёвр короткой фразой.

3. Требуется озвучить какой‑либо ориентир, так как простой фразы о манёвре недостаточно. Например: «Перед трамвайными путями поверните налево».

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

Простыми (или базовыми) манёврами мы называем манёвры вида «налево», «направо», «разворот», «круг», «съезд». Их особенность в том, что любой из них можно нарисовать пиктограммой на плашке в карте. Иногда в голосовой аннотации к таким манёврам добавляются атрибуты про нумерацию и плавность ��ли резкость.

Как я уже рассказывал выше, разметка базовых манёвров вдоль маршрута может оказаться задачей нетривиальной с алгоритмической точки зрения. И при этом люди с такой задачей справляются отлично. Решение напрашивается само — с помощью опытных водителей разметить разные участки дороги и обучить на таком датасете ML‑модель. Но разметка с помощью живых людей обходится дорого, поэтому сначала нужно рассмотреть более простые варианты.

Почему не взять готовую VLM или LLM

Современные модели научились очень хорошо отвечать на вопросы по картинкам, поэтому первым делом мы проверили банальную мысль: а что, если подавать языковой модели на вход картинку с маршрутом (и, возможно, какое‑то дополнительное текстовое описание и системный промпт) с просьбой рассказать, какие нужно произнести голосовые подсказки для водителя? 

В качестве примера я взял упомянутый выше отрезок маршрута и скормил разным моделям:

Сначала можно получить целый эпос на тему того, как нам проехать эти сложные 150 метров:

(Начинаем движение по прямой, за несколько сотен метров до развязки)

«Так, внимание. Продолжаем движение прямо по главной, мы на трассе 29К-015. Впереди будет круговое движение».

(Приближаемся к круговому движению)

«Готовься, подъезжаем к кольцу. Нам нужно будет съехать на третий съезд, это налево. Заранее занимаем левый ряд, чтобы было удобнее».

(Непосредственно перед въездом на кольцо)

«Выезжаем на кольцо, уступаем тем, кто на нём. И сразу держимся левее».

(Движение по кольцу)

«Пропускаем первый съезд... Пропускаем второй... Наш следующий, третий съезд! Налево, уходим с кольца».

(Сразу после съезда с кольца)

«Отлично, выехали верно. Теперь продолжаем движение прямо по этой дороге. Маршрут верен».

Если поработать над правильной формулировкой промпта, получим уже что‑то более пригодное:

Въезд на кольцо, уступите тем, кто уже на круге.

На круге — второй съезд, в сторону налево.

Съезжайте со второго выезда и уст��пите тем, кто движется прямо.

Хорошо, что модель предупреждает об отсутствии приоритета при съезде с этого псевдокруга. Плохо, что в первой выдаче модель просила уйти на третий съезд, а теперь предлагает уйти на второй. Хотя маршрут никак не менялся. А ещё после съезда модель просит повернуть налево,так как не смогла сориентироваться в пространстве.

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

Дело в том, что сервисы Яндекс Карт обрабатывают десятки тысяч запросов на построение маршрута каждую секунду. Каждый маршрут нужно проаннотировать. И каждый маршрут содержит десятки, а порой и сотни участков, для которых нужно опрашивать нейронку. Это миллионы запросов на инференс каждую секунду. Даже если один инференс будет стоить 1 копейку, ежедневно такой сервис будет тратить почти миллиард рублей. Конечно же, всё можно оптимизировать: батч‑запросы, дистилляция, понижение размерности картинок. Но на этом проблемы не заканчиваются.

Нашим сервисом пользуются не только рядовые водители, но и крупные бизнесы, логистические компании. Время ответа в таких случаях строго регламентировано. Построение маршрута — сложная задача, состоящая из многих шагов. На аннотирование мы можем потратить не больше десятка миллисекунд, а в идеале — меньше одной миллисекунды. Много ли вы знаете языковых моделей, способных на такую скорость ответа?

KISS: Keep it simple, stupid

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

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

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

Здесь хочется сделать важное уточнение: это не обычная разметка датасета асессорами. Здесь водители на каждой карточке заданий видели и отрезок маршрута, и саму карту. В непонятных ситуациях они смотрели по панорамам, что представляет собой дорожная ситуация. Стоимость разметки одной карточки в десятки раз выше, чем ��сли делать это руками асессоров, но и качество несоизмеримо лучше.

Имея такой датасет, мы стали подбирать архитектуру ML‑модели по двум критериям: минимальное количество ошибочных классификаций манёвров и время инференса не выше заданного порога.

Из чего складывается качество голосовой аннотации

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

Например, в данном случае, если произнести: «На светофоре поверните налево» раньше нужного, неопытный водитель может подумать, что он уже в полосе на поворот и ему надо уехать налево перед площадью Иосипа Броз Тито, а там обе полосы — встречное движение.

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

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

Таким образом, есть три исхода в зависимости от ответа модели:

• Модель разметила «держитесь левее»: ответ правильный (это самый популярный ответ экспертов).

• Модель разметила «ничего не говорить»: ответ неправильный (не самый популярный у экспертов), но он приемлем с точки зрения некоторых экспертов, поэтому такую модель можно катить в продакшн.

• Модель разметила любой другой манёвр: критическая ошибка, такую модель нельзя катить в продакшн.

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

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

Для каждого семпла из 30 000 размеченных мы имеем какое‑то количество ответов живых водителей.И для некоторых семплов ответы водителей различаются. По умолчанию мы считали правильным тот ответ, за который проголосовало большинство экспертов. Но оказалось, что мы в обучении иногда имеем практически идентичные семплы, в которых голоса для первого разделяются 60/40 и для второго, например, 40/60. И взятие большинства голосов приводит к тому, что в идентичных ситуациях имеем разные ответы. В этом случае помогли два действия: объединить голоса по похожим семплам и после этого выкинуть все семплы, у которых за основной вариант проголосовало меньше 90% водителей. Качество заметно улучшается и теперь мы не видим аномалий в обучении.

Казалось бы, что в этом удивительного? Выкинули варианты с низкой согласованностью ответов — качество стало лучше. А удивительно то, что после таких манипуляций из всей выборки остаётся меньше 1000 семплов. То есть мы урезали обучающую выборку в 30 раз, а качество стало лучше. Это лишний раз доказывает тот факт, что при обучении ML‑моделей качество разметки намного важнее количества семплов.

Таким образом, мы получили датасет с разметкой дорожных ситуаций и ML‑модель, обученную на нём. И теперь, когда к нам приходит фидбэк от пользователей про некорректные голосовые подсказки, программистам не требуется придумывать новые эвристики, чинить старые и соблюдать хрупкий баланс. Достаточно просто добавить в обучение новый семпл. Стоимость поддержки ощутимо уменьшилась.

Как мы попутно добавили новый вид аннотаций

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

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

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

После того как мы собрали ориентиры для ограниченного числа мест, осталось лишь обучить ML‑модель, которая будет по контексту ситуации подсказывать, имеет ли смысл в данной ситуации озвучивать ориентир, и если да, то какой именно.

Про метрики

Выше мы уже видели, каким способом можно оценивать офлайн‑качество сервиса по разметке дорожных аннотаций. Но это, скорее, лосс‑функция для обучения и выбора правильной модели, а в продукте хотелось бы измерять показатели, связанные с пользовательским опытом.

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

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

Переход от эвристик к ML‑модели в задаче голосовых аннотаций оказался не просто техническим улучшением, а принципиальным изменением подхода к разработке для нас. Оказалось, что иногда проще научить машину подражать поведению человека, чем пытаться описать человеческую логику через код. Вместо бесконечного латания дыр в коде мы теперь просто добавляем новые примеры в датасет. Вместо размышлений о том, какая эвристика важнее, — доверяемся коллективному опыту сотен водителей‑экспертов. И самое главное — теперь система масштабируется на новые регионы и дорожные ситуации без переписывания половины кодовой базы.

Конечно, не всё так радужно. ML‑модель — это чёрный ящик, и когда пользователь жалуется на конкретную подсказку, мы не можем просто поправить if‑условие. Нужно собирать новые данные, переобучать модель, валидировать на всём датасете. Но практика показала, что это всё равно дешевле и надёжнее, чем поддерживать легаси‑код с множеством условий.