Как устроен инференс генеративных ответов Алисы в Поиске

О чём доклад?

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

Как меняется разработка на серверной стороне AI-технологий

О чём доклад?

Стремительное развитие ИИ меняет ландшафт бэкенд-разработки. В докладе обсудим, какие новые классы систем возникают и как трансформируется архитектура существующих бэкендов.

Как мы делали агентную платформу надежной (дважды)

О чём доклад?

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

Как устроен поиск в кодовых агентах и почему это важно

О чём доклад?

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

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

Как надежно раздавать конфиги на 200к хостов при отказе [n-1] ДЦ

О чём доклад?

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

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

Миллиард предсказаний в секунду: инфраструктура ML сервисов под нагрузкой

О чём доклад?

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

Расскажу о нашем опыте построения ML-платформы для рекламной системы Яндекса: как в условиях дефицита GPU выжимать максимум из доступного оборудования и делать стоимость запуска новых моделей понятной и предсказуемой.

Прокачка LLM-агентов: как улучшать быстро, безопасно и измеримо

О чём доклад?

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

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

Доклад ориентирован на ML-инженеров и разработчиков, которые уже работают с агентами в продакшене или выстраивают эту инфраструктуру с нуля.

Вердикт за минуту: ML-фильтр и LLM на потоке 40+к событий в секунду

О чём доклад?

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

Отдельно и честно обсудим самую болезненную часть: поведение системы при рестарте и масштабировании stateful-джоб под нагрузкой. Эволюция стейт-бэкенда от локального RocksDB к внешнему YugaByte, Bloom-фильтр, кэши и key-group-aware прогрев — и как все это удерживает latency.

YTsaurus Flow: как распределённо обрабатывать более 100 ГБ/с в реальном времени без потерь и дублей

О чём доклад?

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

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

LLM и краудсорсинг для оценки качества поиска — инфраструктура авторазметки

О чём доклад?

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

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

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

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

База векторных баз

О чём доклад?

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

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

AI Sandboxes: инфраструктура для запуска RL‑окружений и агентов

О чём доклад?

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

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

Автоматическая детекция аномалий в метриках мониторинга: от исследования до прода

О чём доклад?

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

В докладе я расскажу, как мы построили production-систему автоматической детекции аномалий во временных рядахдля мониторинга метрик. Пройдём путь от MVP до продакшена: интерактивный прототип на open source-инструментах, пайплайн обработки временныхрядов, сравнение моделей, бенчмаркинг на размеченныхдатасетах, выбор метрик качества.

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

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

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

RuntimeNodes — как поделиться разработкой рантайма с ML-командами

О чём доклад?

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

Granularity Loss: как правильно умножать нули на GPU

О чём доклад?

Производительность GPU определяется не только числом FLOP и объёмом работы с памятью, но и тем, насколько удачно задача делится между SM, варпами и тайлами тензорных ядер. Если работы недостаточно, она распределена неравномерно или не соответствует аппаратным размерам, возникает Granularity Loss.

На примере Attention и модных оптимизаций инференса (GQA, Speculative Decoding) разберём, почему сокращение числа операций не всегда приводит к ускорению. В каких случаях выгоднее дополнить данные нулями и выполнить больше вычислений при этом получить ускорение

Парсеры на автопилоте: как с помощью агентов пройти путь от страницы в интернете до данных в поисковой базе

О чём доклад?

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

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

AI, который понимает город: бэкенд пешеходных маршрутов Карт

О чём доклад?

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

Расскажу, как LLM помогла с обучением легковесной ML-модели, как мы компактно упаковали данные о местности и методично ускоряли расчёты. Покажу, почему даже хорошо работающего классификатора оказалось недостаточно. Чтобы решить проблему разнообразия, пришлось изменить сам алгоритм построения маршрутов. А в финале — как эта работа стала отправной точкой для нового большого AI-проекта Карт.

Эволюция архитектуры поиска лекарств в Яндекс Еде с ростом нагрузки

О чём доклад?

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

Что в чёрном ящике? Как надежно упаковывать терабайты данных под капотом автономного транспорта

О чём доклад?

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

Одно кольцо, чтоб править всеми? Как мы переписали распределённый персистентный кеш

О чём доклад?

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

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

Что нам стоит дом построить: инфраструктурный квест по созданию Remote IDE на рельсах ML-кластера

О чём доклад?

В Т-Банке мы активно развиваем ML Core — нашу собственную ML-платформу на базе Kubernetes, где всё взаимодействие скрыто за простым и надёжным API.

Однако, несмотря на автоматизацию, некоторые команды продолжали активно использовать dev-тачки с SSH-доступом: они удобны, гибки и позволяют быстро экспериментировать.

Мы решили предложить альтернативу Qwarium — виртуальную среду «по требованию», которая сочетает удобство dev-тачки и преимущества платформы:

• Полный контроль: GPU, IDE, дебаг — почти как на локальной машине
• Персистентность данных и гибкое управление ресурсами
• Интеграция с внутренними системами
• Безопасность, мониторинг и автоматическое управление жизненным циклом

Если ты строишь ML-платформу, поддерживаешь ML-команды или ищешь баланс между свободой разработки и централизованным контролем — будет интересно.

DOOM не должен запускаться внутри eBPF. Но вечер был слишком свободным

О чём доклад?

DOOM внутри eBPF запускаться не должен. Linux обязан отвергнуть такую программу ещё до первой инструкции.

У BPF крошечный стек, пять регистров для аргументов и ограниченная глубина вызовов. Рекурсия запрещена. Любой цикл должен быть конечным не на честном слове, а с точки зрения верификатора. Указатель нельзя просто сохранить в памяти, потом достать и разыменовать: ядро должно помнить, откуда он взялся и куда ему разрешено смотреть.

И всё же обычное ядро Linux принимает мой BPF-объект, проверяет его штатным верификатором и исполняет штатным JIT. В ядре проходят инициализация DOOM, игровая логика и отрисовка. Один игровой тик вместе с полным кадром заканчивается за один вызов BPF-программы. Пользовательская часть передаёт WAD и клавиши, а обратно получает указатель на готовый буфер кадра.

В докладе я расскажу про мой проект BPF Capsule. Это компилятор и среда исполнения для кода на C/C++/Rust внутри обычного BPF: без патчей ядра и без отдельной виртуальной машины в пользовательском процессе. Самый старый поддерживаемый профиль — Linux 5.15. Я проверял загрузку и работу программ на x86—64 и arm64.