Доклады

1) Архитектура ранжирования с помощью моделей и факторов (фичей).
2) Инференс моделей ранжирования в поиске Ozon.
3) Попадание новых моделей ранжирования в прод.
4) Вычисление графа зависимостей между моделями и фичами (входами для моделей).
5) Автоматические проверки перфоманса и качества перед доставкой моделей в продакшн.
6) Пайплайн добавления новых факторов ранжирования в прод.
7) Доклад рассказывает про новую версию feature store https://highload.ru/spb/2023/abstracts/10173. Я затрону минусы прошлого решения и расскажу, во что feature store превратился.

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

Если у вас крупный веб-ресурс - вам важно, чтобы он был всегда доступен и работал быстро из любой точки мира.
В этом помогает геораспределенная инфраструктура, позволяющая приблизить контент к пользователям и отдавать его из оптимальной точки. Как обеспечить выбор этой оптимальной точки и балансировку запросов пользователей по этим точкам? Особенно если вы ограничены возможностями самых стандартных технологий, типовых устройств, браузеров и приложений.
На опыте развития распределенной облачной платформы NGENIX (50+ узлов по всей России и странам СНГ, 7+ Tbps, миллионы RPS) - расскажу о том, как:
· выбирать оптимальные технологии балансировки в интернете от уровня сети до уровня приложений: BGP Anycast, DNS, HTTP и выше
· получать данные, необходимые для принятия правильных решений по балансировке
· объективно мониторить (в т.ч. распределенно) и сравнивать эффективность таких распределенных решений

Из доклада слушатели поймут принципы балансировки в интернете и осознанно смогут применять их и реализующие их сервисы для своих веб-ресурсов.

1. Intro. О проекте с большим количеством внешних систем для сбора данных.
2. Решаем, как будем собирать данные и как их обрабатывать.
3. Систематизация и хранение данных: готовые импортозамещенные инструменты.
4. Расскажу и покажу, почему не стоит париться из-за безопасности.
5. Почему бизнесу важно следить за проектом в реальном времени и принимать решения.

Реальный кейс о том, как я собрал такую систему, и в итоге все были счастливы — бизнес, разработчики и я =)

Доклад фокусируется на архитектурных решениях для RAG-систем, где чанкинг становится узким местом при масштабировании. Рассматриваются 10 стратегий оптимизации, их комбинации и интеграция с Weaviate, Qwen и Llama.

Решаемые проблемы:

High latency при индексировании больших данных (PDF, код, таблицы).
Потеря контекста из-за неадаптивного разделения текста.
Сложности балансировки между скоростью (throughput) и точностью (recall).

Ключевые стратегии чанкинга:
Semantic Chunking (на основе Qwen-7B): разделение по смысловым границам.
Recursive Split: иерархическая декомпозиция текста.
Fixed-Size with Overlap: фиксированные окна с перекрытием для сохранения контекста.
Token-Limited Dynamic Chunking: адаптация под лимиты токенов LLM (например, Llama-3).
Rule-Based Chunking: правила для специфичных данных (например, разделение по секциям договоров).
Content-Aware Chunking: анализ типа контента (текст/таблица/код) через Unstructured.io.
Graph-Based Chunking: связь чанков через графы (предотвращение разрывов контекста).
Sliding Window with Threshold: динамическое определение границ на основе эмбеддингов.
Hybrid Approach: комбинация NLTK-статистик и нейросетевых моделей.
Cluster-Driven Chunking: предварительная кластеризация данных для группировки связанных чанков.

Архитектурные инновации:
Интеграция Weaviate как векторной БД с поддержкой мультимодальности и гибридного поиска.
Оптимизация пайплайнов через LangChain и LlamaIndex для работы с Qwen и Llama.
Кэширование чанков и эмбеддингов в Redis для снижения задержек.

Результаты:
Ускорение индексирования в 2 раза (с 10 сек/док до 5 сек/док) при обработке 50K PDF-документов.

Повышение recall на 12% в тестах с медицинскими отчетами.

Снижение стоимости инференса Llama/Qwen за счет уменьшения избыточных чанков.

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

В докладе расскажу:
· Про проблемы крупного монолита при переезде в облако
· Переход от stateful к stateless
· Способы транспорта данных
· Оркестрация применения данных в облаке
· Шардирование сервиса в облаке
· Перевод разработки в облако

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

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

Про Apache Kafka не слышал только ленивый. Apache Kafka — это высокопроизводительная потоковая платформа, предназначенная для передачи и обработки большие объёмов данных с минимальной задержкой. В каких только системах Kafka сейчас не используется!

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

Начнем с основных концепций, но копнем глубже, выйдя за рамки общеизвестной информации. Так что же внутри черного ящика? Мы погрузимся в детали архитектуры системы хранения данных Kafka, рассмотрим принципы работы Sequential IO vs Random IO, а также изучим подход Zero Copy и оценим его влияние на производительность работы брокера. Рассмотрим файловую структура хранилища.

Далее оценим влияние выбранного типа сериализации на производительность – посмотрим бенчмарки “json vs protobuf” на примере data payload с реальных проектов. В рамках этой части доклада пристально посмотрим и на влияние компрессии (gzip vs snappy).

А что, если хочется еще быстрее? Поднимем тему тонкой настройки Kafka для максимальной оптимизации производительности. Поговорим про тюнинг пакетной обработки и настройку batching, linger.ms. Посмотрим на бенчмарки и оценим влияние этих параметров конфигурации на реальных примерах с ПРОДа.

Не обойдем стороной тему семантик и гарантий доставки данных – at least once, at most once и exactly once. Тут отдельно остановимся на сценариях их применения в реальных системах.

В самом конце, проведем обзор архитектуры большой высоконагруженной информационной системы на примере топологии гео-кластера, построенного на базе Apache Kafka. Разберемся в отличиях stretched vs connected clusters и рассмотрим инструментарий репликации, включая Mirror Maker 2.

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

В 2ГИС поисковые данные обновляются довольно часто — особо активные сегменты могут обновляться раз в 10 минут. Насколько быстро эти данные начнёт использовать поисковый движок, настолько свежие данные увидит пользователь. Поэтому основная задача — быстро доставить свежие данные до пользователя.

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

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

Брокеры сообщений широко применяются во всем IT, в частности RabbitMQ, однако это далеко не магическая коробка и написать свой код так, чтобы не потерять свои сообщения - крайне нетривиальная задача. RabbitMQ это сложный инструмент, а любой сложный инструмент требует точной настройки. Мы окунемся глубже в архитектуру RabbitMQ, посмотрим, где мы с легкостью можем ошибиться и потерять сообщения, и как себя от этого застраховать. Глянем на 8 практических кейсов работы с RMQ, в которых опишем нюансы работы, хорошие практики и неочевидные сюрпризы, с которыми вы можете столкнуться.

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

На мастер-классе мы вместе с участниками определим, какие варианты распила монолита могут быть, разобьем существующий монолит на ограниченные контексты, спроектируем несколько шагов выпила частей из монолита.

А также изобретем несколько паттернов, обсудим плюсы и минусы реализаций.

Компания Антиплагиат – поисковик, ищущий совпадения в текстовых документах. Нагрузка меняется в течении суток вслед за нормальной активностью пользователей в РФ и странах СНГ, кроме того, есть ярко выраженная сезонность, пиковая нагрузка июня в 10 раз больше пиковой нагрузки в июле. Автомасштабирование сервисов позволяет очень сильно экономить. Я расскажу о том, как это устроено у нас в кубах. Казалось бы, используй спотовые инстансы и будешь экономить 70%, но не все так просто на самом деле. Можно экономить больше, при этом масштабирование будет происходить достаточно быстро, даже с толстыми ML-моделями.
В докладе будет рассказано о практике оптимизации настроек и опыте использования оптимизированных K8S кластеров под управлением deckhouse на прерываемых(спотовых) инстансах в AWS и YC. Текущий суммарный размер K8S: 5500 подов, 3000 ядер, 8 ТБ памяти (в сезонном пике мы ожидаем стандартного увеличения кластера в 3-5раз). Основной упор будет сделан на конкретных решениях позволяющих платить меньше, работать быстрее/надежнее. Расскажу наш практический опыт в настройках, влияющих на скорость масштабирования, скорость работы и доступность сервисов. Пройдемся по особенностям использования compute сервисов облаков позволяющих снизить стоимость эксплуатации при сохранении приемлемого для компании уровне надежности. В компании используется большое количество сервисов на основе ML-моделей, что влечет большой набор данных для первичной инициализации, старта и работы сервиса. Рассмотрим оптимизации, нацеленные на уменьшение времени старта таких сервисов при масштабировании, уменьшении объема межсервисного, служебного и инициализирующего трафика. В докладе будет представлен наш опыт оптимизаций и эксплуатации таких кластеров в двух облачных провайдерах.

Команда Видеоаналитики Сибура занимается анализом онлайн-видеопотока с более 2000 камер. Потребность в анализе большая, при этом вычислительные ресурсы меньше, чем у IT-гигантов. При разработке решений приходится учитывать такие условия, как географическая распределенность камер (от Твери до Томска), отсутствие GPU и доступа к облакам, а также более 40 различных computer vision моделей.
В докладе я расскажу о том, как разработать гибкую и производительную систему с микросервисной архитектурой, позволяющую извлекать видеопоток с 2000+ камер по RTSP, эффективно применять разные cv-модели при отсутствии GPU для решения различных задач видеоаналитики, и о том, как сделать эту систему удобной для пользователей и для других разработчиков.

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

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

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

Естественным этапом развития систем серверной виртуализации является виртуализация сети — возможность создавать виртуальные сетевые инфраструктуры «под задачу», не будучи стесненным рамками реальной сетевой инфраструктуры предприятия. Подобный этап развития настал и у проекта zVirt.

Для обеспечения виртуализации сети в нашей системе мы исследовали существующие решения и остановились на интеграции готового SDN — OVN. При интеграции мы столкнулись с различными проблемами, начиная от просадок в производительности при увеличении нагрузки на SDN и заканчивая задачами, связанными с оберткой в продукт.

В докладе расскажу:
* чем отличается интеграция SDN в облако и SDN в систему виртуализации, почему разработка «механизма» сложнее, чем разработка «политики»;
* почему мы остановились на готовом SDN, а не писали сами;
* с какими трудностями столкнулись при попытках сделать универсальное решение;
* компромиссы и их цена: чем пришлось пожертвовать;
* сравним производительность нашей системы со «стоковой».

Название доклада - не шутка. В действующей сети Ethereum действительно уже больше миллиона активных валидаторов, каждый из которых периодически становится лидером в сетевом консенсусе. И хотя число реальных мастер-серверов сети оценивается в десятки тысяч, сетевой консенсус Ethereum 2.0 на данный момент является самым децентрализованным консенсусом в мире, безопасность которого обеспечивается примерно 100млрд$ замороженных активов и который работает без серьезных сбоев уже несколько лет. Если перекладывать на язык баз данных, то мы имеем БД с мастер-мастер реплицкацией между огромным числом реплик, устойчивую не только к сбоям, но и к сговору большого числа валидаторов. Доклад рассказывает про эту механику репликации, основные алгоритмы, организацию такой сети и ее параметры. Доклад будет интересен всем, кто интересуется отказоустойчивыми распределенными системами и кого задолбали рассказы про майнинг.

Лидеры рынка СУБД в сегменте крупных предприятий — Oracle, MS SQL, PostgreSQL, несмотря на то, что архитектура этих платформ складывалась больше трёх десятилетий назад. В докладе разберём узкие места этой архитектуры и приёмы, применяемые в современных платформах, которые позволяют значительно увеличить производительность базы данных. А в конце посмотрим, почему же никто так и не подвинул с пьедестала традиционные СУБД.

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

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

В 2024 году Ozon полностью перенес свою инфраструктуру объектного хранилища на собственное решение S3-server Lusca. В докладе я раскажу, как мы выбирали хранилища индекса; думали, как реализовать strong consistency на eventual consistency базе; открывали для себя особенности фоновых процессов ScyllaDB и придумывали свои алгоритмы; А еще о том, как боролись с восстанием зомби на Хеллоуин и воскрешали терабайты случайно удаленных данных.

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

Опыт кастомного подхода к шардированию Postgresql в ядре процессинга заказов Яндекс Такси. Как справляемся с нагрузками и строгими требования к доступности и latency. Как организация данных помогла реализовать простой и надежный механизм решардирования.

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

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

В докладе поделимся опытом работы с аналитикой на графовой базе данных JanusGraph на базе Cassandra и проблемами с которыми столкнулись, а также опытом работы с расширением duckpgq для DuckDB, поговорим про наш опыт работы с пакетом GraphScope. Будут представлены предварительные результаты тестирования производительности этих систем, которые мы аккуратно сейчас собираем.

Опыт работы нашей команды основан на выстраивании аналитики с крупными графами, содержащими около 1 млрд. вершин и около 50 млрд. ребер, с историческими изменениями. На графе мы научились быстро вычислять метрики вроде центральности или схожести (Pagerank за 25 минут, Jaccard за 2 часа) и работу с окружениями и уперлись в проблемы работы с результатами расчетов из которых считаем фичи для моделей. Результаты расчетов тоже становятся графом в котором уже работают OLTP сценарии. Потому мы научились быстро работать с сотнями гигабайт данных результатов расчетов на графе и расскажем об опыте исследований представления данных Labeled Property Graph (LPG) в инфраструктуре Data LakeHouse, проведём сравнительный анализ форматов файлового хранения (Parquet, Apache Iceberg) и нового формата GraphAr от Alibaba, расскажем про их преимущества и ограничения для масштабной аналитики включающей OLAP и OLTP сценарии.

Доклад будет интересен исследователям и разработчикам в области Big Data, специалистам по графовой аналитике, архитекторам распределённых систем и всем, кто работает с аналитикой на графах в современных облачных инфраструктурах.

Уже дважды на хайлоаде я рассказывал про наш опыт развёртывания и управления распределённым S3 совместимы хранилищем на базе MinIO. Приятно, что доклады находят своих слушателей и вопросы мне в телеграм продолжают приходить до сих пор. некоторый просят продолжения. Поэтому я решил сделать ещё один доклад на эту тему, тем более что наш опыт растёт вместе с объёмом места, которое занимает информация в нашем хранилище. Сейчас оно размещается в 4 ДЦ, включает в себя 12 нод и 300 дисков.

Итак, коротко о том, о чём я хочу рассказать в этом году

1. Расширение хранилища.
Рано или поздно место заканчивается и приходит время добавлять новые ноды и диски. В прошлый раз я рассказывал, как мы расширялись с 3 до 4 дата-центров, по сути, скопировав все данные, что съело много времени. В этот раз я расскажу, как мы добавляем новые ноды, дисковые полки и диски в них соответственно. С одной стороны казалось бы, тривиальная процедура, с другой она представляет из себя куда более сложный процесс, чем увеличение просто раздела на локальном диске.

2. Эффективность сжатия.
Я уже рассказывал, что MinIO поддерживает сжатие. Но насколько оно эффективно и как быстро работает? Красивые цифры и графики.

3. Быстродействие.
Расскажу, как клиентам удалось под 100% удалось загрузить нам канал в одном из ДЦ, переливая данные с серверов в S3. При том, что для хранения мы используем обычные SAS диски.

4. Стоимость.
Мы используем не просто SAS диски. Мы используем б/у SAS диски небольшого объёма, но в большом количестве. Расскажу, как мы к этому пришли.

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

В процессе развития сервиса мы упирались в несколько проблем — ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть — мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду.

По роду деятельности мы занимаемся аналитикой товаров на маркетплейсах, собираем очень много данных. Например, на WildBerries размещено 110 млн товаров, для каждого товара мы зайдем в его карточку, запишем данные (как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель). Сохраним это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров — каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed-данных в ClickHouse.

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

Как с помощью Debezium и Kafka настроить синхронизацию данных между географически распределенными узлами БД Postgres, а также как автоматизировать переключение между базами в случае отказа и минимизировать простой.

Что слушатель вынесет с доклада?
- Рабочий подход к реализации гео резервирования PostgreSQL. Он успешно работает в продакшене для клиентского MDM у одного из крупнейших заказчиков.
- Пошаговое руководство по настройке Debezium, написанию sink-коннектора и адаптации Java-приложения для работы с несколькими базами.

Доклад для тех, кто задумывается или уже решился на интеграцию системы единого входа (SSO) в свою инфраструктуру.

Расскажу о текущих вариантах интеграции с сервисами машинного обучения - Airflow, MLFlow, Superset. Как сервисы поддерживают OpenID Connect, как разделяется авторизация пользователей и авторизация сервисов. Как внедрить решение в рамках платформы работающей в multitenant режиме.

Также обсудим интеграцию с сервисами мониторинга. Рассмотрим изоляцию пользователей Grafana по организациям при помощи Keycloak. И как внедрить Keycloak для сервисов, которые не поддерживают OAuth.

1. SaluteEye - платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Сегодня мы собираем более 5 млрд событий в день, но так было не всегда...
2. С чего всё начиналось. Как мы использовали для аналитики Amplitude и с какими ограничениями сталкивались. Почему импортозамещение было неизбежно.
3. «Верните мне мой 2022» - санкции, экстренное внедрение нового решения и взрывной рост с 10 млн до 10 млрд событий в месяц за два месяца. Первые проблемы и выводы - формирование задела на масштабируемость системы.
4. Как мы собирали шишки и начали их считать - эволюция платформы и повсеместное внедрение мониторинга. Неожиданные проблемы стандартных инструментов и взгляд со стороны продукта - как сохранить лояльность пользователей в условиях частых перебоев.
5. Внедрение ClickHouse и появление realtime аналитики. Нетипичные кейсы применения - технический мониторинг продуктов и работа с логами на ClickHouse + Grafana вместо привычного Elastic Stack. Забиваем гвозди отверткой или эффективно используем уже имеющиеся ресурсы?
6. Что мы имеем сегодня

Какие механизмы беспарольной аутентификации можно встроить в PAM-систему: FIDO2, WebAuthn, одноразовые токены, биометрия, сертификаты. В чем риски безопасности и неудобство для пользователей паролей. Механизмы Passwordless (FIDO2/WebAuthn (аппаратные ключи), TOTP/push-токены, биометрия, сертификаты PKI). Реализация в PAM системах: протоколы (SAML, OAuth), гибридные сценарии, управление жизненным циклом. Кейсы: банки (FIDO2), DevOps (сертификаты), корпорации (биометрия + TOTP).

- Введение в веб-скрапинг: определение, популярные инструменты (requests, beautifulsoup4, selenium, playwright), признаки атаки на сайт

- Базовые методы скрапинга и защита от них:
- Простые HTTP запросы и их детектирование
- Rate limiting и его реализация
- Проверка и валидация User-Agent
- Анализ паттернов запросов

- Продвинутые техники скрапинга и противодействие:
- Эмуляция браузера через Selenium/Playwright
- Browser fingerprinting как метод защиты
- JavaScript проверки и валидация клиента
- Поведенческий анализ посетителей

- CAPTCHA и другие методы верификации:
- Типы CAPTCHA и их эффективность
- Honeypot поля в формах
- Скрытые элементы для детекции ботов
- Временные задержки и их валидация

- Динамический контент как защита:
- Рендеринг на стороне клиента
- Обфускация данных

- Мониторинг и обнаружение атак:
- Системы логирования подозрительной активности
- Анализ и агрегация логов
- Автоматическое блокирование подозрительных IP
- Real-time мониторинг активности

- Комплексные решения защиты:
- Cloud-based WAF решения
- Проксирование запросов
- Geo-фильтрация
- IP reputation системы

- Практические примеры реализации защиты:
- Код для базовой защиты от ботов
- Примеры интеграции CAPTCHA
- Реализация rate limiting
- Система детекции аномалий

- Будущее противостояния:
- AI в скрапинге и защите от него
- Новые методы верификации пользователей
- Баланс между доступностью и безопасностью
- Тренды в развитии защитных механизмов

Рассмотрим несколько живых актуальных CVE
Будут примеры реальных свежих CVE от момента ресерча до их эксплуатации
Рассмотрим пример эксплуатации CVE без эксплоита (когда его нет в паблике)
Рассмотрим как оценивать CVE и какие параметры учитывать
Рассмотрим ресурсы и сканеры которые помогут выявить CVE
Напоследок пример 0DAY

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

Мы разберемся, какие качественные изменения несут новые поколения процессоров и архитектур. Как эффективные, но неприемлемые из-за производительности программные подходы, обретают новую жизнь в аппаратном исполнении. И как в этом новом мире изменятся атакующие.

Но главное, обсудим - возможно ли сделать не взламываемые системы имея свою аппаратную платформу?

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

Тема с Supply Chain уже который год не на слуху, закономерно развиваются и меры предотвращения таких атак. Одним из популярных фреймворков является SLSA, однако он достаточно абстрактен и не учитывает некоторые виды атак.

В докладе вы узнаете про фреймворк OSC&R, мы сравним его с SLSA и разберемся, какие конкретно атаки нам угрожают и что с этим делать.

Фаззинг API веб-приложений позволяет выявлять уязвимости, которые могут оставаться незамеченными при проведении статического анализа кода (SAST) или ручного анализа. В докладе будет рассмотрен наглядный пример.
Главная проблема фаззинга - это сбор данных. Для того чтобы выявить уязвимость, нужно собрать как можно больше входных точек, параметров запросов и самое главное поддерживать согласованность типов значений для этих параметров. В докладе рассмотрим различные источники, откуда можно добыть данные:
1) Openapi спецификации
2) Postman коллекции
3) Proxy (BurpSuite, OWASP ZAP, mitmproxy)
4) Логи
5) Данные команд нагрузочного тестирования (ammo для yandex-tank)
В качестве движка сканирования рассмотрим open source инструмент от команды Project Discovery - nuclei, который поддерживает фаззинг и имеет community фаззинг шаблоны. Рассмотрим как конвертировать данные из упомянутых выше источников в формат, подходящий для nuclei, и запустить фаззинг.

Будет практика. Настоятельно рекомендуем взять ноутбук.

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

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Ни для кого не секрет, что современные архитектурные решения для ML, помимо мощностей ЦПУ, задействуют ресурсы тензорных или графических ускорителей. В итоге производительность упирается в пропускную способность шины, и не всегда перенос вычислений на ускоритель стоит свеч. Обсудим, каким образом эта проблема может быть решена в процессорах на базе архитектуры RISC-V и почему многие эксперты считают ее будущим для ML-приложений.
Но, чтобы будущее наступило, необходимы не только процессоры, но и работающая на них программная экосистема. Покажем, как удалось не только портировать на RISC-V важную составляющую ML-фреймворков — высокопроизводительную open source-библиотеку линейной алгебры Eigen, но и «малой кровью» оптимизировать ее под векторное расширение RISC-V RVV.

Посмотрим, что дает «ручная» векторизация на RISC-V и Arm, на примере двух широко используемых высокопроизводительных open source-библиотек линейной алгебры — Eigen и OpenBLAS. Поймем, почему автовекторизации не хватает для ускорения приложений AI/ML, AR/VR, CV, HPC. На графиках производительности увидим, далеко ли до roofline и где прячутся compute-bound и memory-bound алгоритмы.
Если вы
* не понимаете, зачем программисты продолжают оптимизировать руками в век стремительно умнеющих компиляторов, то вам сюда;
* находитесь в противоборствующем лагере и не отдаете производительность целиком на откуп компилятору, то вам тоже сюда;
* вообще никогда не задумывались о каких-то оптимизациях и не понимаете, из-за чего весь сыр-бор, то тоже приходите!
Даже если вы не знаете, кто такая линейная алгебра, больно не будет.

В 2019 году мы начали предлагать в аренду клиентам выделенные серверы на базе десктопных процессоров Intel Core i9-9900K. И через некоторое время столкнулись с тем, что процессоры сильно перегреваются в 1U корпусе и серверы выходят из строя. Стандартное воздушное охлаждение не справлялось. Увеличивать размеры корпусов мы не хотели — теряли в плотности размещения серверов в стойке, а, как следствие, деньги. Это заставило нас искать нестандартные решения в направлении жидкостного охлаждения.

Путь оказался тернистым. Первые решения от поставщиков с кастомной СЖО, казалось, решили проблему, но на самом деле только отсрочили ее. Через пару лет серверы стали массово выходить из строя. Это привело к длительным простоям оборудования и необходимости замены клиентских серверов. Самостоятельные попытки решить вопрос также не приводили к успеху. Все это подтолкнуло нас к более глубокому изучению вопроса: разобрали по “косточкам” всю систему охлаждения, проанализировали конструктивные особенности, технические ошибки, изучили опыт геймеров и кастомеров, и в итоге создали собственную систему — надёжную в использовании и простую в обслуживании.

В докладе расскажем:
Зачем мы начали ставить десктопные процессоры в клиентские серверы, в то время, как конкуренты нас осуждали
Как решали проблемы с СЖО, чем нам помогли и помешали поставщики
На какие «грабли» наступили и что нужно было делать по-другому
Happy end или очередной этап развития: как дело обстоит сейчас и что мы планируем делать дальше

Представьте: 30+ устройств как отечественных, так и зарубежных, с разной архитектурой и форм-фактором — IP-камеры, электросчётчики, планшеты, одноплатные компьютеры и т.д. Все они разбросаны по офису словно детали пазла, из которых не складывается единая картинка. Как превратить это в цельную тестовую лабораторию с удалённым управлением, Wi-Fi и автотестами?
Мой доклад — это история инженера-новичка, который за год собрал (не имея опыта) стенд-трансформер, переживший миграцию устройств из Москвы в Томск, победил «сетевой адресный апокалипсис» и подключил их к единой тестовой межрегиональной инфраструктуре.
Расскажу, как создать «умную» инфраструктуру с нуля, даже если вы, как и я, также больше тестировщик, чем сетевик. Поделюсь реальным опытом того, как обуздать хаос и перевести его в структуру, способную эффективно решать задачи по тестированию ПО из любого офиса компании.

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

Многим разработчикам приходится решать задачи по оптимизации различных бизнес процессов. В данном докладе спикер расскажет как ускорить вставку и обновление данных при помощи популярного фреймворка Spring и одной из самых популярных БД PostrgeSQL.

Разногласие в дефолтных настройках TCP и CNI может приводить к различным сайд-эффектам в трафике системы и приводить к ошибкам в приложении в kubernetes-кластере. Но есть случае, когда сайд-эффект встречается редко и приводит к даунтайму приложения.
Расскажу про инцидент с зависанием на 15 минут в нашей системе. Какие особенности работы TCP, gRPC Keepalive мы подчернули для проверки статуса соедиения. В чем именно нам не помог ServiceMesh, на который мы рассчитывали.
И какую еще настройку стоит подкрутить у вас в микросервисах или все же использовать ServiceMesh

В Ozon нагрузочное тестирование проводится по продакшен окружению. Используя реальные запросы пользователей. Одна из проблем – все эти запросы собрать. Мы это делаем, клонируя трафик с других сервисов. И если другие сервисы держат нагрузку только от их пользователей, то наш сервис – держит суммарную нагрузку сотен сервисов.

В своем докладе я расскажу про:

- Первую версию архитектуры, державшую нагрузку в тысячи раз меньше текущей;
- Сложности, с которыми мы столкнулись. В частности - как положили kafka для части сервисов;
- Развитие архитектуры, вплоть до текущей версии, выдерживающий 1 500 000 RPS;
- Как мы ежедневно записываем 20 терабайт трафика;
- Зачем мы это делаем.

– Информационная безопасность и конфиденциальность данных: похожие понятия, но разные акценты;

– Защита данных во время использования: централизованный и децентрализованные подходы;

– Разные судьбы яиц, сложенных в одну корзину, или основные проблемы централизации;

– Децентрализация: как делать математику с числами, не глядя на сами числа, или Multi-Party Computation (MPC, совместные конфиденциальные вычисления);

– Пример применения MPC: как Bloomtech сделал первую в РФ (а, может, и в мире) межбанковскую платформу конфиденциальных вычислений, которая работает на проде;

– Цена конфиденциальности: проблемы технологии совместных конфиденциальных вычислений вчера и сегодня;

– Перспективы технологии: MPC как неотъемлемая часть цифровой инфраструктуры и стандарт для информационных коллабораций;

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

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

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

Система дополнена комплексными процессами и командой специалистов, которые используют распределенную карту для создания HD-карт высокого разрешения. Эти карты играют ключевую роль в модуле планирования, помогая автономным транспортным средствам выполнять точные и безопасные маневры.

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

в мир развития технологий в космосе поход с обработкой данных на Земле уже устарел. Пользователям нужна информация с минутными задержками, а не ждать сутки. Законы физики не позволяют это сделать, так как для обработки данных надо передавать огромные массивы по нестабильным каналам связи, да ещё и на ограниченный по периодам наблюдений наземный сегмент. Я расскажу про то, как трансформируется индустрия космических датацентров, при чём тут лазеры, реален ли ЦОД в космосе и надо ли охлаждать сервера если в космосе очень холодно. Конечно же мы обсудим какие страны какие проекты делают, российские космические ЦОДы и что могут делать энтузиасты для космических вычислений.

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

Отдельное внимание уделим процессу разработки высоконагруженных систем в автомобилях, от анализа рынка до тестирования на реальных примерах. В частности, мы погрузимся в проблематику того, как 17 различных высоконагруженных систем уживаются в одном автомобиле на примере адаптивного круиз-контроля. Несмотря на то, что пользователю могут быть важны всего 2-3 функции, он получает много дополнительных возможностей, что создает сложности в их восприятии и использовании.

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

Как выглядят исходные данные со спутников и какую обработку им необходимо пройти до их публикации на Яндекс.Картах?
Почему нам приходится по пикселям пересобирать спутниковые снимки? И как в этом помогает рельеф земли?
Посмотрим на такие технологии как: Cloud Optimized GeoTIFF, Pansharpening, RPC-трансформации. Разберём возникающие проблемы и как мы их решаем.

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

- Мир шоссейно-кольцевых гонок
- Суть дисциплины
- Суть мотоспорта: сочетание технической подготовки мотоцикла и скилла пилота
- Техническая часть. Чем гоночный мотоцикл отличается от обычного (спойлер: почти всем)
- Пилот и умение управлять мотоциклом. Из чего складывается пилотирование.
- К чему приводят критические ошибки при пилотировании, помимо ухудшения времени круга. Самые распространенные виды падений
- Данные не врут. В отличие от пилотов мотогонок 😃
- Необъективность ощущений пилотов. Как мы оцифровываем скиллы.
- Датчики, которые мы ставим
- Метрики, которые мы собираем
- Примеры графиков, основанных на реальных данных
- Разбор телеметрии. Что мы видим на графиках, и как картинки на экране приводят к победе в чемпионате
- Пример 1. Закрытие газа
- Пример 2. Улучшение техники торможения, сдвиг точки торможения (1 поворот трассы Igora Drive)
- Пример 3. Изменение траектории и увеличение скорости прохождения поворота (4 поворот трассы Moscow Raceway)
- Заключение. Мотоспорт и снимаемые метрики как метафора реальному бизнесу

Low-code и no-code решения привлекают своей простотой, вроде как устраняющей нужду в отладке, трассировке, профилировании и других инструментах "классического" программирования. Но в масштабах реальных промышленных проектов без них оказывается трудно, ведь иначе как понять, что делает та или иная low-code конструкция под капотом? И, что особенно важно, как она ведёт себя под нагрузкой?

В докладе мы посмотрим на имплементацию этих функций на примере российской IoT-платформы AggreGate, где встроенный язык выражений был наделён средствами трассировки и визуализации, позволяющими low-code разработчикам видеть ход и результаты выполнения их команд на всех этапах от редактора до production. Особый акцент сделаем на производительности:
построение/слияние/кэширование деревьев разбора, ленивая загрузка результатов, троттлинг вычислений – словом, всё, что позволяет сохранить сервер живым, а отладку – пригодной даже при сотнях тысяч RPS.

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

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

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

В рамках доклада расскажу:

1. Вредные советы по работе с ClickHouse — поделюсь полученными на собственном опыте знаниями, распространёнными ошибками при создании и разработки на CH-кластере. Расскажу, к каким последствиям приводят ошибки и как их избежать.

2. Внедрение шардгрупп. Расскажу, как поменяли политику работы с кластером и перевели первые 2 домена за неделю.

3. Результаты первого квартала – раскрою, как мы вышли на стабильность кластера в 99,9% и разделили большой кластер между аналитическими командами.

Доклад будет полезен как командам, плотно работающим с ClickHouse, так и тем, кто только стоит на стадии выбора архитектуры. Он поможет избежать ошибок и сразу получить лучший результат.

В 2018 году в Авито появилось in-house решение для автоматизации A/B-экспериментов. За несколько лет платформа выросла в зрелый продукт, с помощью которого производятся почти все релизы нового функционала Авито — это 4000+ экспериментов в год.

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

* Каждый день в Авито активны сотни экспериментов
* Объем сырых данных (кликстрим и тд) исчисляется миллиардами строк
* В одном эксперименте — до 30 тыс. метрико-разрезов
* На выходе имеем около полу-миллиарда рассчитанных стат. тестов (дисперсии, p-value и тд)

При этом весь compute мы успеваем провести за несколько часов на относительно небольшом (в масштабах Авито) кластере Trino. Расскажу об основных способах оптимизации, которые позволяют эффективно утилизировать вычислительные ресурсы.

Отношения между Spark и Parquet (и другими колоночными форматами) можно вкратце описать так:
– Мама, можно нам домой doExecuteColumnar?
– У нас есть дома doExecuteColumnar.
*doExecuteColumnar дома: ColumnarToRowExec.*

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

Чтобы понять причины такого поведения и выяснить, можем ли мы его контролировать, нам надо сделать шаг назад и разобрать текущую модель вычислений в Spark: данные (строки, колонки, партиции, JVM-объекты, внутренние структуры и типы даных Spark, Arrow) и их обработка (Columnar Execution, WholeStageCodeGeneration), связав эти понятия в единую картину. Рассмотрим, как из примитивных конструкций формируются распределенные коллекции, и как нам их приручить, чтобы писать более оптимальные приложения. Обсудим нюансы и детали связанных концепций: кеширование, шаффл, некоторые трансформы. В конце проведем небольшое сравнение архитектуры Spark и смежных фреймворков: Databricks Photon, Apache Comet, Apache Gluten.

1. Использование Debezium и kafka-connect для репликации
- Использование Kafka-Connect для доставки изменений из базы данных в топик Kafka

2. Роль Heartbeat, и как он решает проблему отставания слота репликации
- Heartbeat облегчает мониторинг Debezium.
- Решение проблемы отставания в PostgreSQL при чтении части таблиц.

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

Data Lake является хранилищем сырых данных в Аналитической платформе X5 . Уже много лет данные в него загружается самописным фреймворком при помощи Sqoop. Это крайне простая и удобная утилита, отлично справляющаяся со своими задачами. Мы даже её портировали на Hadoop3, хотя для него нет готовых сборок, но она больше не развивается и уже морально устарела.
Было принято решение найти ему замену, но как оказалось Sqoop не оставил приемников.
Конечно же есть универсальный швейцарский нож Spark который справится с любыми задачами. Но после использования элементарной утилиты не хотелось утяжелять решение.

Решением ситуации для нас было использовать Trino. Он активно используется в Big Data стеке для построения как распределенынй SQL движок, но и отлично подходит для достаточно простых задач интеграции. Это конечно не консольная утилита для загруки, но ключевым приемущестовом стала настройка интеграции при помощи SQL.

В докладе расскажу вам о нашем опыте применения Trino для загрузки данных из других источников

Мы в Сбере разрабатываем платформу для построения рекомендательных сценариев для всех компаний экосистемы начиная от онлайн-кинотеатров до мира e-commerce. За прошедшие годы мы разработали универсальные подходы для создания персонализированных рекомендаций. И в докладе поделюсь аспектами MLOps-архитектуры для запуска рекомендательных сценариев:

- Как выглядит cloud-native платформа для построения production-ready рекомендательных сценариев и почему это важно
- Какие MLOps инструменты нужны для быстрого запуска достаточно сложных рекомендательные сценарии (от инструментов для обработки больших данных до Feature Store и онлайн моделей)

Расскажу о пути, который мы прошли, чтобы построить кластеризацию товаров на маркетплейсе с целью создания тематических подборок c персонализированным ранжированием, что позволяет улучшить пользовательский опыт.
Зачем нам проводить кластеризацию товаров?
В рамках бизнеса, кластеризация особенно важна тем, что позволяет решить часть проблем каталогизации, создания тематических групп товаров, а также предложить новые товары, которые еще не проиндексированы рекомендательной системой.
Что еще будет в докладе?
* Наш подход к решению проблемы кластеристеризации в пространстве высокой размерности
* Решение проблемы поиска оптимального числа кластеров
* Как мы подходили к метрикам, на базе которых пробовали оценить качество полученной кластеризации
* Как проводили кластеризацию только-только появившихся товаров и обобщили подход на миллионы товаров, представленных в нашем маркетплейсе.

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

“Как мы создали свое аппаратное решение для измерения габаритов товара с помощью нейросетей и стереокамер”

1️⃣ Автоматизация измерений: зачем это бизнесу?
– Как точные и быстрые измерения товаров сокращают затраты и улучшают логистику.

2️⃣ От идеи к работающему устройству: как мы разрабатывали свое аппаратное решение?
– Выбор оборудования, архитектура системы, технические вызовы.

3️⃣ Нейросети + стереокамеры: почему такая конфигурация?
– Как нейронные сети помогают измерять объекты в 2D и 3D-пространстве.

4️⃣ Как мы решали проблему точности?
– Коррекция ошибок, фильтрация данных, калибровка системы.

5️⃣ Реальные результаты: насколько точно работает наша система?
– Разбираем данные из продакшена и выводы по итогам проекта.

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

Обучив камеры в крупнейшем логистическом операторе мы смогли на порядок повысить производительность сотрудников отдела мониторинга по детектированию динамических инцидентов на сладе (Например, бросание груза при погрузке/разгрузке).

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

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

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

На воркшопе мы рассмотрим различные виды эмбеддингов и применим их для построения векторного поиска и простой системы рекомендаций.

Классификация эмбеддингов(Текстовые, Звуковые, Изображения, Составные эмбеддинги)

Операции с эмбеддингами:
Суммирование и кластеризация для выявления групп и схожести данных.

Эмбеддинге в поиске:
Делаем векторный поиск на коленке на базе Qdrant

Рекомендательные системы:
Векторная рекомендательная система за 5 минут

Основной посыл:
Эмбеддинги — мощный инструмент для структурирования и анализа данных, который трансформирует подход к поиску, рекомендациям и обработке информации.

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

В докладе я расскажу, что такое состязательные суффиксы, почему любая LLM им подвержена, как самостоятельно создать такой суффикс и почему OpenAI не считает это угрозой безопасности. Также я поделюсь результатами исследования о переносимости суффиксов между различными моделями и дам советы по тестированию ИИ-приложений на основе LLM.

Основные задачи, которые нужно решать полноценной стриминговой платформе - это хранение событий, доставка этих событий до хранилища, ну и конечно обработка c возможность хранения состояния(так называемый stateful processing). Разберём как может выглядеть архитектура потоковой обработки данных на референсах от AWS и Microsoft. И построим свою архитектуру из open-source компонент, таких как Kafka Connect, Apache Kafka и Apache Flink.

У нас не задеплоилось с первого раза, давайте влепим кол инфраструктуре. А то, что мы криво поставили переменные пода - это не к нам, это к devops. Часто ли вы такое слышали от разработчиков, тестировщиков или поддержки? Как сделать доказательную базу того, что с инфраструктурой всё хорошо, а проблема в коде? Сегодня мы поговорим с вами о том, как можно организовать процесс снятия метрик удовлетворённости инфраструктуры для команд разработки и тестирования, рассмотрим вариант стэка технологий для этого, а так же пример реализации с видом метрик, которые могут оказаться полезными в вашей работе.

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

Что спрятано под кнопкой "Я согласен", которую многие нажимают не читая, когда обращаются к AI-помощникам?
В докладе планирую рассказать о том, кому обычно принадлежат права на код, написанный самостоятельно, и разобрать важные моменты принадлежности авторских прав на код, написанный с помощью искусственного интеллекта.

Основано на лицензионных соглашениях ChatGPT, GigaChat, Copilot, Codeium, CodeWhisperer, Gemini.
Путей обхода - не будет.
Подводные камни - будут.