Доклады

В докладе расскажу, как устроена архитектура RAG-системы RUTUBE, которая уже в 80% случаев даёт операторам службы поддержки готовый ответ и снижает время реакции на 10%. Рассмотрим, как мы совмещаем гибридный поиск (BM25 + семантический поиск FRIDA), локальные LLM (Vikhr-Nemo-12B) и интеграцию с системой поддержки. Разберём основные аспекты разработки и внедрения RAG.
- Технические детали: выбор Milvus как векторной БД для масштабируемого поиска, оптимизация эмбеддингов для русскоязычного контента.
- Интеграция в продукт: автоматическое обновление FAQ через Airflow.
- Мониторинг: метрики качества ответов через Kafka → ClickHouse → Grafana, включая KPI на доля ответов «Я не знаю» и другие решения.

В распределённых системах 2025 года transaction outbox остаётся ключевым паттерном для атомарной публикации событий. В докладе разберём его архитектуру, проблемы с WAL, replica lag, back-pressure и способы масштабирования. Покажу, как проектировать надёжную публикацию, от индексов и CDC до observability и борьбы с edge-case’ами. Обсудим также, когда outbox — не лучший выбор.

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

В основе работы любого приложения всегда лежит железо. Оно может дать как буст нашему приложению, так и забрать "силы" у него. Но мы настолько привыкли к облачным решениям и Kubernetes (K8s), что уже просто забываем про эту истину.

Мы – Sage в Т-Банке. Мы владеем большим количеством инфраструктуры(серверов), на которое запускаем наши хранилища.

И вот мы получаем партию серверов от нового для нас вендора. И казалось бы, что же могло пойти не так? Мы же уже столько раз разворачивали наши Elasticsearch (ES), но именно в этот раз железо решило преподать нам урок. Наши плановые 2 недели превратились в 6+ месяцев.

Из доклада вы узнаете:
1. Архитектуру современного сервера глазами: процессоры, память, riser и RAID-контроллер
2. Наш опыт запуска ES на новом железе и на какие проблемы с аппаратным обеспечением (hardware) мы наткнулись.
3. Как при этом вел себя ES или сервер, и как мы доказывали что проблема не в приложении, а на уровне железа.
4. Как эти проблемы были решены и какие выводы мы сделали на будущее.

Доклад будет интересен как экспертам, так и начинающим.

Блокчейны - медленные и никогда не догонят Web2 сервисы, которые могут себе позволить просто "поверить на слово" доверенному серверу. Для соблюдения требований к безопасности в этих сетях все перепроверяют всех, что создает фундаментальные ограничения на скорость блокчейнов. Несмотря на это, сейчас в Web3 все работает реально быстро и отзывчиво, но как этого удалось добиться?
В этом докладе мы рассмотрим как разные проекты решали проблемы масштабирования. Вертикально: как оптимизировались алгоритмы консенсуса, виртуальные машины и state transitions, параллельное исполнение транзакций и ordering. Горизонтально: что такое sharding, L2 решения и какие подходы в них используются. Примерами будут слушить реально работающие блокчейны: Ethereum, Solana, TON и многие другие.
Доклад будет полезен тем, кому интересно в каких направлениях развивается техническая мысль в децентрализованных сетях со строжайшими требованиями к безопасности и целостности данных.

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

В мире СУБД постоянно меняется абсолютно все. Железо стремительно меняется, диски замещаются NVMe SSD, ядер в процессоре становится больше сотни, появляются новые способы работы с сетью, такие как RDMA. Появляются новые подходы, идеи, алгоритмы. Но еще важнее - все время меняются требования пользователей. В таком динамическом мире требуется или создавать с ноля современные СУБД каждые лет 10 или переписывать с нуля основные ее компоненты. В этом докладе сфокусируемся на двух конкретных компонентах СУБД: движке выполнения запросов и оптимизаторе запросов

При работе Apache Spark промежуточные shuffle-данные по умолчанию хранятся на локальных дисках executor-ов, что связывает их жизненный цикл с конкретными процессами и хостами. Это создаёт уязвимости: сбой или вытеснение executor-а может привести к повторным вычислениям, замедлению работы и росту потребления ресурсов, особенно в долгоживущих и ресурсоёмких приложениях.

В стандартном подходе для повышения надёжности применяется External Shuffle Service, однако он по-прежнему опирается на локальное хранение и требует дополнительной поддержки со стороны инфраструктуры. Мы реализовали альтернативный подход: хранение shuffle-данных в распределённом хранилище YTsaurus. Такой способ повышает надёжность, упрощает квотирование ресурсов, позволяют динамически реконфигурировать кластер, а также открывают возможность применения альтернативного push-based подхода к shuffle-операциям без необходимости изменений со стороны Spark. Реализация полностью прозрачна и может применяться для всех Spark-задач, запускаемых на платформе YTsaurus вне зависимости от типа и объёма нагрузки.

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

Мы расскажем про WebAssembly в SQL-движке для безопасных UDF:
- Рассмотрим SQL UDF, боли и проблемы подхода
- Раскроем преимущества и ограничения технологии WebAssembly
- Посмотрим на эту же технологию в других СУБД
- Расскажем, как приделать WebAssembly к существующему SQL-движку
- Изучим преимущества результата над классическим подходом к UDF
- Расскажем про переиспользование функциональности других СУБД
- Покажем реальные проблемы кросс-компиляции произвольного кода под WebAssembly

⁃ Как Яндекс внедряет GPT для автоматизации различных процессов
⁃ Как построить RAG для высоко эффективной автоматизации обращений в службу поддержки
⁃ Какие уроки были извлечены в процессе переосмысления подхода к использованию языковых моделей

Чтобы обеспечить автоматическими субтитрами миллионы часов UGC-контента, нужно не просто точно распознавать речь — требуется промышленная платформа, способная к экстремальному масштабированию. В RUTUBE мы прошли путь от ограниченного MVP на Whisper до высокопроизводительной системы на собственных моделях, которая сейчас обрабатывает новые пользовательские видео почти без задержки.
В докладе раскрою архитектурные решения, позволившие добиться такой пропускной способности: асинхронную обработку задач через Kafka, эффективный инференс моделей с помощью Triton Server, оркестрацию ресурсов через кастомный Speech Worker.
Вы узнаете, как мы:
- Научились без проблем обрабатывать видео любой продолжительности (вплоть до 24+ часов).
- Добились качества автоматических субтитров, сопоставимого с ручными, благодаря борьбе с «галлюцинациями» и NLP-анализу.
- Обеспечили горизонтальное масштабирование под любую нагрузку на видеохостинг.
Опыт будет полезен для ML- и бэкенд-разработчиков, работающих над сервисами обработки больших объемов аудиоданных в реальном времени.

Мы разработали решение, анализирующее структурную целостность около миллиона видеопотоков одновременно.

Это поток в 2 млрд строк в Clickhouse в сутки. Эти данные просматривают люди через Grafana, адаптированную для мультитенатного доступа и роботы, присылающие алерты в системы мониторинга клиентов.

В докладе технические детали:

* Запись в БД с множества версий нашего видеостримера
* Организация стейджинга, тестов и подбор железа под БД
* Чтение из кликхауса: как прикидываться прометеусом
* Связь личного кабинета с графаной, интеграция пользователей и ограничение доступа к данным
* И на сладкое: как всё это развернуть on-prem в редуцированном виде

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

В нашей системе аналитики события проходят путь от шины данных через сервис сбора событий, попадают в Kafka, а затем — в ClickHouse с помощью Kafka-Engine. В архитектуре — три кластера ClickHouse (main, replica, sandbox) с настроенной репликацией, каждый из которых обслуживает свою зону ответственности: сбор, BI, пользовательские запросы.

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

— Как устроен наш стриминговый пайплайн: от шины данных до ClickHouse
— Как сервис сбора событий справляется с миллиардами событий
— Какие тесты проводили:
— 9 млрд событий в сутки
— 15 млрд событий в сутки
— 24 млрд событий в сутки — предел, к которому стремились
— Внезапный скачок нагрузки х2
— Сбой кластера ClickHouse и как он проявился
— Сбой Kafka и поведение пайплайна
— Запись всех событий в один проект вместо 50+ — и к чему это привело
— Kafka-Engine vs Kafka-Connect — замеры, сравнение, выбор
— Как организовали мониторинг и метрики, на что смотрели в Grafana и ClickHouse.
— Какие баги, затыки и инсайты мы получили, и как это повлияло на прод

Доклад будет интересен всем, кто работает с ClickHouse под высокой нагрузкой, собирает real-time данные, использует Kafka и хочет понять, где тонко и как не порвать.

Доклад посвящен практическому использованию ключевых инструментов диагностики Dotnet для решения сложных задач: от устранения утечек памяти до оптимизации производительности многопоточных приложений. В рамках мастер-класса будут рассмотрены инструменты dotnet-trace, dotnet-dump, ClrMD и dotnet-monitor, а также их применение в реальных кейсах с демонстрацией кода и примеров анализа дампов. Участники узнают, как автоматизировать сбор метрик, визуализировать трейсы и проводить глубокий анализ хипа, чтобы минимизировать время на решение проблем в продакшене. Материал подойдет разработчикам, тестировщикам и DevOps-инженерам, стремящимся улучшить стабильность и скорость приложений.