В крупном приложении, таком как «Яндекс Go», живут тысячи алертов — маленьких программ, которые смотрят за метриками и «зажигают красную лампочку» при превышении определенного значения. Только вот статичный порог будет работать плохо, потому что он не знает про время суток, сезонность, снегопад. Пошел снег — заказов стало больше, порог сработал. Аналитик смотрит — ничего страшного, погода. И просто отключает алерт. Задача — научить систему отличать реальные отклонения от фоновых колебаний, чтобы каждый алерт был действительно значимым.
Решает такие нетривиальные проблемы исследовательский отдел ML Research. Команда появилась внутри Техплатформы Городских сервисов Яндекса осенью 2024 года; большую ее часть составляют студенты и недавние выпускники. За первый год для нескольких сервисов компании они успели создать новые алгоритмы поиска и рекомендаций, ИИ-инструменты для разработчиков и многое другое.
Послушать о том, как создаются технологии Городских сервисов Яндекса, можно будет на конференции Day&Night, которая пройдет 18 апреля. Регистрируйтесь по ссылке.
Один из ярких примеров — детектор аномалий во временных рядах: алгоритм, который сам понимает, какие значения нормальны для любого графика, и замечает отклонения меньше чем за секунду. В «Яндекс Такси» он уже развернут более чем на двести алертов, покрывающих около ста крупнейших городов. За счет универсальности его начали применять в других сервисах Яндекса.
Что происходит «под капотом» таких систем, как вообще устроена работа ML-R&D внутри бигтеха, где проходит граница между «научно интересно» и «полезно в проде» и почему команда предпочитает браться за задачи, где можно научиться новому, — в интервью с Андреем Соколовым, руководителем ML Research отдела Техплатформы Яндекса.
Техплатформа Городских сервисов Яндекса
Это инженерная платформа, которая разрабатывает инфраструктуру и внутренние инструменты для сервисов городской экосистемы Яндекса, таких как «Яндекс Такси», «Яндекс Доставка», «Яндекс Еда» и другие. Ее задача — помогать командам быстрее создавать новые функции, обеспечивать надежность высоконагруженных сервисов и строить общие платформенные решения для биллинга, безопасности и бизнес-процессов.
Зачем продуктовой платформе исследовательский ML-отдел
— ML-инженеры есть во многих продуктовых командах. Зачем понадобился отдельный R&D?
На самом деле нужны и R&D, и продуктовые ML-команды. Наше появление — не замена и не попытка конкурировать. Разница структурная.
Продуктовая команда работает в первую очередь на улучшение метрик своего сервиса: например, чтобы он был удобнее и им пользовалось большее количество людей. Как следствие, аккуратнее смотрит в сторону экспериментов: зачем ввязываться в проект, который может сжечь ресурсы и не гарантировать результат на выходе? Когда бизнес и качество сервиса на зрелой стадии, команды предпочитают использовать привычные архитектуры и решения, которые позволяют внедрять улучшения пусть медленнее, но стабильно. Это рабочая стратегия, но она не оставляет пространства для того, чтобы попробовать что-то принципиально новое.
У нашей команды есть организационная свобода выбирать задачи. Мы ходим по бизнес-юнитам, изучаем, где у них болит, — и, если у нас есть экспертиза, можем предложить свою помощь.
— И как вы решаете, за какую задачу браться?
Два ключевых критерия. Первый — обобщаемость: если решение может быть полезно сразу двум и более бизнес-юнитам, это сильный сигнал. Нас интересуют технологии, а не разовые решения для одного заказчика. Второй — данные: у задачи должен быть доступ к большому объему релевантных данных. Третий, дополнительный, критерий — комплиментарность: хорошо, если задача дополняет то, что уже делает команда, и понятно, у кого есть нужная экспертиза.
Если этого нет — задача не плохая, просто ее откладываем и сможем сделать, когда появится время и ресурсы.
— Кто формально является заказчиком ваших проектов?
Верхнеуровневая цель — помогать бизнес-юнитам достигать новых метрик. Параллельно мы стремимся концентрировать у себя ML-экспертизу высокого уровня, публиковаться, выступать на конференциях, развиваться как исследовательски, так и прикладным образом.
Важно понимать: многие серьезные прорывы в машинном обучении за последние десять лет произошли в исследовательских подразделениях корпораций. Зачастую именно в индустрии больше вычислительных, денежных и инженерных ресурсов.
Некоторые технологии, вышедшие из корпоративных лабораторий за последние десять лет
- Трансформер — архитектура, лежащая в основе всех современных языковых моделей, — появился в Google Brain в 2017 году.
- AlphaFold, решивший задачу предсказания структуры белка, которую биологи не могли победить полвека, — DeepMind.
- ResNet — архитектура, без которой не обходится компьютерное зрение, — вышла из Microsoft Research.
- CatBoost — алгоритм градиентного бустинга с механизмом снижения переобучения — разработан в «Яндексе» в 2017 году.
- Airflow — система оркестрации вычислительных и ML-пайплайнов, ставшая промышленным стандартом управления data-процессами, — создана в Airbnb и передана в Apache Software Foundation.
Команда и студенты
— Как вы формировали команду — какие компетенции искали в первую очередь?
Изначально было два фокусных направления: глубокое обучение (обучение нейросетевых моделей и энкодеров, построение эмбеддингов товаров, водителей и других сущностей) и AI-инструменты для разработчиков — все, что связано со статическим анализом кода и языковыми моделями для кода. Под эти направления и искали людей.
Но довольно быстро стало понятно, что не менее важная стратегия — растить специалистов внутри команды. Поэтому примерно через квартал после старта начали активно брать стажеров — студентов и недавних выпускников — и давать им возможность включаться в реальные проекты. Эта ставка себя оправдала. Поэтому и сейчас у нас действует стажерская программа, так что к нам можно и нужно приходить учиться и работать.
— Студенты ведут проекты самостоятельно, до продакшна?
Без ограничений. Если человек готов взяться и тянет — пусть ведет. Например, мультимодальный энкодер, который сейчас используется для поиска в одном из наших сервисов, — его обучил один из моих сотрудников. На тот момент он был стажером и студентом одновременно.
— Бывало, что студенческий проект превращался в дипломную работу или публикацию?
Да, несколько таких случаев уже есть. Один из проектов — инструмент для генерации описаний pull request’ов. Pull request — это минимальная единица изменения кодовой базы. Нужно было не только научить систему генерировать описание, но и оценивать качество этих описаний по разным аспектам. Студент построил бенчмарк — систему метрик для оценки качества описаний — и это легло в основу его дипломной работы. А детектор аномалий, о котором сегодня можно уже с уверенностью рассказать, реализовали два молодых специалиста.
Как два стажера построили детектор аномалий временных рядов
— Расскажите, с какой конкретной инженерной болью пришли коллеги.
Ко мне пришли ребята из SRE-команды (Site Reliability Engineering) «Яндекс Такси» — они отвечают за надежность и бесперебойную работу сервисов, причем не только такси, но и других родственных сервисов бизнес-группы. Запрос звучал примерно так: «У нас есть огромное множество алертов. Алерт — это маленькая программа, которая следит за одним временным рядом. Алерты создают разработчики, обычно в виде правила: если метрика превысила X — зажечь лампочку. Таких алертов в Городских сервисах — тысячи, а может, и десятки тысяч».
Проблема вот в чем. Когда алерт срабатывает, разработчик смотрит — и видит, что ничего страшного нет, это не технический сбой. Ну, снег пошел в городе или длительность поездок стал больше из-за затрудненного движения. Он либо поднимает порог срабатывания, либо просто отключает алерт. В итоге наблюдаемость за системой не растет, а снижается.
Наблюдаемость (observability)
Свойство системы, определяющее, насколько по ее внешним сигналам (логам, метрикам, трассировкам) можно восстановить и оценить ее внутреннее состояние. Если сигналов недостаточно или алерты настроены плохо, внутреннее состояние системы труднее корректно интерпретировать.
Хотелось иметь «умные» алерты, которые смотрят на временной ряд и сами понимают, что для него типично, — и сигнализируют только тогда, когда что-то действительно идет не так.
— Почему статические пороги здесь принципиально не работают?
Возьмем конкретный пример: количество заказов такси в городе N за пятиминутный интервал. Ночью эта величина может упасть почти до нуля. Днем подскакивает до максимума. Летом и зимой паттерны тоже совершенно разные. Под каждый город, под каждое время суток и каждый сезон выставить отдельный осмысленный порог вручную — практически нереально. Детально следить за здоровьем сервиса в разрезе каждого крупного города было сложно.
Временной ряд (time series)
Последовательность числовых значений, упорядоченных по времени: например, количество заказов в такси за каждые пять минут. Анализ временных рядов — отдельная область машинного обучения, занимающаяся прогнозированием, классификацией и обнаружением аномалий в таких последовательностях.
— Прежде чем разрабатывать свое решение, вы смотрели на рынок?
Да, конечно, ребята из SRE сходили на рынок, поискали готовые решения — и нашли компании, которые делают что-то похожее, но не полностью то, что нам нужно. И оказалось, что такие решения стоят довольно дорого и не всегда гибко настраиваются под внутренние задачи. Поэтому коллеги решили, что разработать собственное решение может быть дешевле и надежнее. После этого они вернулись ко мне с вопросом, готов ли я взяться за такой проект. Я нанял двух стажеров специально под него — и примерно за девять месяцев они сделали продукт, который сейчас живет в продакшне.
— В машинном обучении есть целое семейство алгоритмов anomaly detection. Какой класс алгоритмов вы рассматривали?
В индустрии существуют алгоритмы двух основных типов. Первый — model-based: берешь длинную историю временного ряда, обучаешь на ней модель, и дальше эта модель долго используется для описания нормального поведения. Второй — легкие алгоритмы, которые обучаются буквально на лету, в момент вычисления алерта.
Мы почти сразу принципиально отсекли тяжелые model-based подходы. Главный аргумент: мы целились в систему, которую можно масштабировать. Сейчас у нас поднято порядка тысячи алертов, но количество будет расти. Упираться в вычислительные ресурсы нам не хотелось.
— Насколько легкие алгоритмы уступают тяжелым по качеству?
В среднем такие алгоритмы показывают очень достойные результаты. Если нужен детектор «из коробки», который подходит широкому классу временных рядов, простых и легких алгоритмов вполне достаточно.
— Опишите, как именно работает ваш детектор изнутри.
В момент вычисления алерта берется история временного ряда за относительно небольшое окно — скажем, одна-две недели. На этих данных сразу же обучается минималистичная модель: это может быть сезонная декомпозиция или авторегрессия. Модель тут же используется для оценки последних 30 секунд ряда: если они отклоняются от предсказанного нормального поведения — алерт срабатывает.
Принципиально важный момент: через 30 секунд все повторяется заново. Берется уже следующее окно — со сдвигом на 30 секунд, — и снова обучается новая модель, снова вычисляется детектор. Модель не хранится нигде между вызовами.
— Это звучит как минус — терять модель каждые 30 секунд. Разве это не расточительство?
На первый взгляд кажется минусом, но на практике — огромный плюс. Поскольку модель нигде не хранится, этот микросервис можно вызывать откуда угодно, не нужно поддерживать целостность хранилища моделей. Сервис становится stateless (без хранения состояния между вызовами) — это сильно упрощает и масштабирование, и поддержку.
Сезонная декомпозиция (seasonal decomposition)
Метод разложения временного ряда на три компонента: тренд (долгосрочное изменение), сезонность (регулярно повторяющиеся паттерны, например суточный цикл) и остаток (случайные отклонения). Аномалия обнаруживается как значимое отклонение в компоненте остатка.
Алгоритм STL (Seasonal and Trend decomposition using LOESS) — один из наиболее распространенных методов этого класса.
— Как выглядит путь данных от метрики до уведомления дежурного?
Все метрики живут в общей системе мониторинга — она едина для всего «Яндекса». Когда разработчик создает умный алерт, он указывает параметры: какой временной ряд отслеживать, с какой частотой и какое историческое окно использовать.
Система мониторинга по расписанию забирает датафрейм — двухнедельную историю нужного временного ряда с заданной частотой дискретизации — и отправляет его в отдельный микросервис детекции. Микросервис за один вызов обучает модель и вычисляет значения детектора на последних 30 секундах. Результат возвращается в систему мониторинга, и та решает, должен ли алерт сработать. Задержка на стороне микросервиса — менее секунды.
— Какие именно метрики отслеживаются в «Яндекс Такси»?
Ключевые — количество принятых заказов за пятиминутный интервал и количество отклоненных заказов или заказов, на которые не нашлось исполнителя. Плюс еще ряд метрик. Если перемножить количество метрик на количество крупных городов — получим двести с лишним умных алертов на сто городов. Нагрузка на микросервис — порядка двухсот запросов в секунду от активных алертов.
— Как оценивали качество алгоритма — на каких данных, с какими метриками?
Детекция аномалий — это задача, которая в самом своем фундаменте содержит дисбаланс классов: аномалия по определению является редким событием. Поэтому метрики качества нужно выбирать аккуратно — те, которые пригодны для работы с редкими событиями. Стандартная accuracy здесь бессмысленна: если аномалий один процент, можно просто всегда говорить «все нормально» и получить 99 процентов правильных ответов.
В индустрии есть несколько датасетов с временными рядами, где аномалии размечены. Их выпустили крупные компании — Yahoo, AWS и другие. Существует и хороший обзор от китайских исследователей, собравших порядка десятка таких датасетов. В 2024 году команда из ZTE совместно с коллегами из Chinese Academy of Sciences и Tsinghua University опубликовала бенчмарк TimeSeriesBench, где коллеги систематизировали накопленные датасеты и проверили, как алгоритмы работают в реальных промышленных условиях — с жесткими требованиями к скорости обнаружения и новыми рядами, которых модель никогда раньше не видела. Мы взяли эти датасеты плюс добавили несколько внутренних датасетов Яндекса: как бизнес-метрики, так и технические временные ряды.
— Разметка — всегда больная тема. Как решали?
Разметка оказалась настоящим квестом. Записать сами временные ряды несложно, а вот разметить, в какие именно моменты должен срабатывать алерт, — это другая история. Пришлось очень много общаться с владельцами сервисов: только они понимают, где в их временном ряде норма, а где аномалия. Это ресурсоемкая работа, которая продолжается до сих пор.
— Вы выбрали алгоритм, оптимальный для множества временных рядов, а не для каждого отдельно. Почему?
Можно было пойти двумя путями: под каждый ряд подбирать наилучший алгоритм — или найти один алгоритм, который хорошо работает в среднем по большому классу рядов. Мы выбрали второй путь: ориентируемся на детектор «из коробки», который подходит для широкого класса временных рядов без ручной настройки. За основу взяли существующие легкие алгоритмы — сезонную декомпозицию и авторегрессию — и адаптировали их под обучение на лету; сейчас команда разрабатывает собственные улучшения поверх этой базы.
При этом, если временной ряд имеет ярко выраженную сезонность, алгоритмы класса сезонной декомпозиции работают лучше. Сейчас, когда разработчик создает новый алерт, у него есть выбор в интерфейсе: дефолтный алгоритм или сезонный детектор, оптимизированный для периодических рядов. В идеале хотелось бы иметь один суперумный детектор, который сам все понимает. Но пока таких нет — и расширять набор опций нужно осторожно: каждая новая опция усложняет выбор разработчику.
— Как проходило внедрение — с какими сложностями столкнулись?
Технической работы было очень много: создание API, согласование интерфейса с командой системы мониторинга метрик, длительная отладка. Сейчас еще ведется работа по оптимизации производительности: когда технологию запустили в прод, обнаружились заметные задержки, и коллеги из системы мониторинга попросили их снизить. Ребята много усилий вложили в оптимизацию — и все равно видно, где еще можно улучшить. Внедрение не остановилось.
— Что реально изменилось для команды надежности «Яндекс Такси»?
Команда надежности Такси видит в реальном времени, что происходит с сервисом в каждом крупном городе. Это и есть основной эффект — повышение стабильности работы приложения.
— Технология распространилась за пределы «Такси»?
Да, причем сама технология живет теперь отдельно от нас: она интегрирована в общую платформу мониторинга метрик, и любая команда может создавать умные алерты самостоятельно. Среди тех, кто использует: команда аналитики «Алисы», несколько проектов в «Поиске», «Путешествия», B2B, «Маркет», «Музыка». Уже несколько сотен умных алертов создали другие команды для своих нужд, кроме того, детектор аномалий уже доступен и внешним пользователям.
— Какие классы аномалий детектор пока плохо находит?
Детектор хорошо справляется с одномерной задачей: следит за одним временным рядом. Но легко предъявить сценарий, который пока выглядит фантастически: возьмем не один ряд, а тысячу — и не просто как независимые графики, а с семантикой. Вот этот ряд — количество запросов в микросервис A, вот этот — в микросервис B, они явно взаимосвязаны. Хочется понимать инциденты на более высоком уровне: не «в этом ряду есть аномалия», а «что-то пошло не так в этой группе связанных сервисов».
Многомерная детекция аномалий, или детекция в семантически связанных временных рядах, — вот серьезная задача, которую нам еще предстоит решить.
— Что еще можно улучшить в инфраструктуре?
Потенциально можно отказаться от микросервисной архитектуры и интегрировать алгоритмы прямо в систему хранения и обработки метрик. Это снизит латентность (время задержки между запросом и ответом) и уберет лишний сетевой хоп (промежуточный узел, через который проходит запрос по сети). Пойдем ли туда — пока решается.
Еще одна задача, которую сейчас нельзя назвать решенной, — root cause analysis. Дано: тысяча микросервисов, они взаимодействуют друг с другом. Происходит поломка: кто-то выкатил новый релиз, и начали стрелять детекторы аномалий. Задача — найти первопричину, конкретно — коммит или строчку в коммите, которая все сломала. Это не решено.
Процессы и методология
— Как вы отличаете «исследовательски интересно» от «полезно в проде»?
Это, честно говоря, довольно трудно. Бывает, что на бумаге или в симуляторе все выглядит красиво — а в реальную жизнь не переносится. Тогда приходится принимать решение: если понятно, чего не хватает модели, — можно попробовать снова. Если перепробовали все — откладываем задачу. Такие отложенные задачи у нас есть. Это нормально.
— А обратная ситуация — когда очевидна прикладная польза, но нет исследовательского интереса?
Тоже бывает. Если задача интересна одному заказчику и из нее нельзя вырастить обобщаемую технологию — это менее желательная история. Как раз потому, что за нее могут взяться продуктовые команды этого сервиса. Самое главное для меня — это рост людей. Если задача очевидно полезная, но в ней нет технологического вызова, мы за нее не беремся.
Исключение — стажер, у которого это первый рабочий опыт. На несложной задаче он может вырасти: познакомиться с инфраструктурой, научиться работать с данными. Тогда взяться можно.
— Что вы точно не будете делать, несмотря на хайп или запросы?
Не будем браться за задачи, нерелевантные нам: те, от которых нет ни исследовательского роста, ни обобщаемой технологии. Задачи, которые делаются ради галочки или хорошего отзыва от коллег. За это не возьмемся.
Будущее через ограничения
— Когда ваши разработки могут стать опенсорсом или публикацией?
Пока мы публикуемся на индустриальных конференциях. Когда появится что-то достойное серьезной научной конференции — опубликуем.
С опенсорсом принцип такой: выкладывать имеет смысл тогда, когда выгода от опенсорса превышает стоимость его поддержки. Если есть большое сообщество, которое будет его развивать, — нужно выкладывать. Если нишевая история, которую ты будешь поддерживать в одиночку, а пользоваться только сам, — тогда, скорее всего, не нужно. Посмотрим, что вырастет.
— Какие направления на горизонте двух-трех лет считаете наиболее перспективными?
Три направления. Первое — AI-инструменты для разработчиков: это очевидный и быстро развивающийся рынок. Второе — обучение глубоких моделей для поиска, рекомендаций и принятия решений. Третье — задачи надежности инфраструктуры, то, что называется AI-SRE: в сильной постановке, то есть без упрощений, это выглядит как суперзадача. Тот же root cause analysis в промышленных масштабах.
— Если бы ограничений не было — какую задачу решили бы в первую очередь?
Знаете, красивые и сложные истории возникают именно потому, что есть ограничения — по производительности, по времени, по ресурсам. Уберите ограничения — и задача теряет большую часть интереса. Поэтому конкретного ответа у меня нет. Детектор аномалий во временных рядах — один из первых успешных проектов отдела, которому от роду меньше года. За это время технология прошла путь от прототипа двух стажеров до общеяндексовой инфраструктуры. Задачи root cause analysis и многомерной детекции пока остаются открытыми — и именно поэтому интересными.
Реклама: ООО «Яндекс.Такси», ИНН: 7704340310. Erid: 2W5zFK5cHfo