О чем доклад?

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

О чем доклад?

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

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

О чем доклад?

К нам приходит поток порядка 40+к событий в секунду от каждого клиента. Задача — максимально быстро выдать вердикт, является ли событие в системе клиента инцидентом или легитимной активностью. В докладе расскажу, как устроен потоковый AI/ML-пайплайн, который это делает: ML-модели фильтруют и приоритизируют поток, снижая нагрузку, а собственная LLM-платформа (Positive LLM) формирует финальный вердикт. Всё работает асинхронно — через стриминг — под заданным SLA.

Отдельно и подробно — самая болезненная часть: поведение системы при рестарте и масштабировании stateful-джоб под нагрузкой. Расскажу про эволюцию стейт-бэкенда от локального RocksDB к внешнему YugaByte, и как Bloom-фильтр, кэши и key-group-aware прогрев удерживают latency при масштабировании. И контекст перехода: раньше продукт жил on-premise у клиента. Мы перенесли ядро обработки в облако Flink + Kubernetes®, чтобы быстро подключать клиентов, переиспользовать ресурсы между тенантами и добавлять мощности под каждого клиента отдельно.

О чем доклад?

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

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

О чем доклад?

Молния — это система аварийной доставки данных. Она должна выживать при любых инцидентах, в частности при выпадении нескольких дата-центров. Молния использует push-схему (сама приносит таргеты на целевые хосты), а не pull (когда хосты приходят в некоторый endpoint за данными по таймеру). Это позволяет ей доставлять данные на десятки тысяч хостов за секунды и иметь общий флот более 100 000 хостов под управлением. Молния не требует автоматических или ручных переключений мастера. Её SLO — 99,999%, и она полноценно работает, если жив хотя бы один инстанс.

В этом докладе я расскажу, с какими сложностями мы столкнулись на практике, почему установка gRPC/mTLS‑соединения к хосту — это слишком дорого и как уронить систему на 10 минут, даже если она требует для работы только часы на хостах и рабочую сеть (мигающая тоже подойдёт).

О чем доклад?

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

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

В докладе рассмотрим, как систематизировать и автоматизировать процессы для проведения экспериментов и регулярной разметки, а также в целом, что происходит вокруг LLM и краудсорсинга:

• Сбор, подготовка и хранение данных
• Версионирование проектов разметки, инструкций для живых асессоров, конфигураций моделей, промптов
• Очереди с приоритетом и квотирование, контроль нагрузки, обогащение данных и батчинг
• Интерфейсы, отдельные контуры для экспериментов, оценка качества и согласованности разметки, воспроизводимость бенчмарков
• Кеширование и распространение оценок, сбор и агрегация результатов

О чем доклад?

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

О чем доклад?

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

О чем доклад?

Рассказываю о том, как в R&D‑цикле разработок различных сценариев вокруг LLM мы уменьшали блокировки и необходимость разрабатывать и выкатывать рантайм‑компоненты, предоставляя широкие, но контролируемые инструменты смежным командам. Также постараюсь рассказать о сложностях, ограничениях и ошибках, которые были в процессе.

О чем доклад?

Расскажу про фундамент векторных поисков, напомню про фундамент обычных БД, поясню, почему они склеиваются неидеально. Вместо советов подёргать за настройку X в базе Y дам общий обзор «рынка» и попробую научить базе баз, то есть: понимать в общих чертах, что внутри — а значит, плюс-минус корректно сравнивать и тюнить любые реализации векторного поиска. Времени на детали, как обычно, не хватит, поэтому на докладе быстро пробежимся по верхам!

Глянем на важные ключевые концепции векторного поиска (метрики «расстояний», precision/recall, dimensionality curse, квантизация всех сортов). Обсудим 2.5 основных метода реализации векторного поиска (IVF и HNSW) и пачку важных доп-техник, которые Меняют Всё. Умеете натюнить любой векторный поиск? Знаете, чем FAISS отличается от Qdrant? Понимаете, почему pgvector никогда не обгонит специализированную базу? Отлично, тогда НЕ приходите на этот доклад (но давайте спишемся телегой), вам он не нужен.

О чем доклад?

Автономный грузовик генерирует до 1200 ГБ данных в час. Расскажем, откуда берётся такой объём, как мы записываем и обрабатываем этот поток, какие форматы используем и с какими ограничениями Linux сталкиваемся на практике. Разберём, как обеспечиваем гарантии сохранности данных на машине и надёжно доставляем их со всего флота в целевое хранилище.