RWB Тех

⭐️⭐️ Планы на 3 октября — прийти на RWB Infra x Security Meetup Мы направим прожекторы на инфраструктуру и информационную безопасность — туда, где за привычными решениями скрываются сложные инженерные задачи, компромиссы и неочевидные риски. Будем разбирать реальные кейсы, искать узкие места, обсуждать и показывать решения, которые помогают инфраструктуре и безопасности выдерживать рост. Когда: суббота, 3 октября, старт в 13:00 Где: Москва + онлайн В программе 8 докладов, разделенных по двум тематическим трекам ⬇️

1️⃣ Трек Infra: • Тюнинг Gitlab CE как реакция на быстрый рост нагрузки • Путь баланса и компромиссов в DCIM • Единая инфраструктура доверия: PKI на базе Vault • Kubernetes vs Bare Metal: что может пойти не так 2️⃣ Трек Security: • DevSecOps: от сканирования в пайплайне к платформе — и обратно • Почти эффективный VM: как мы боролись с хаосом в инфраструктуре и сократили время обработки уязвимостей • Как защищать данные, когда единого периметра больше нет • От заявки до доступа за 90 секунд: как шесть инженеров управляет доступом в тысяче систем

Регистрация уже открыта — не откладывайте заявку и приглашайте коллег (количество мест на площадке ограничено)!

Как поместить 1000+ моделей в один ансамбль? Отвечает Лев Нечаев, руководитель команды «Автоматическая модерация методами ИИ» в RWB. Лев рассказал, как команда успешно применяет детекторы на основе векторного поиска в модерации контента на маркетплейсе.

В статье: • почему традиционные классификаторы и few-shot перестают работать при росте числа брендов; • как мы собрали и очистили датасет, избежав перекоса по категориям; • как выбрали YOLO для детекции и эмбеддеры CLIP/ArcFace для векторного представления; • как организовали высокопроизводительный инференс (Triton + TensorRT) и перешли с PGVector на Faiss; • как гибко настраиваем пороги срабатывания под разные сценарии; • и где ещё применяем эту архитектуру — от детекции лиц до каскадных решений и автоматической разметки.

➡️ Подробнее — в канале RWB делает ML

Как оценивать сложность задач технических писателей и понимать реальную загрузку команды Рассказала Евгения Красильникова, технический писатель в команде разработки документации и методик обучения ПО. Чтобы выработать единый подход к оценке задач, команда выделила два ключевых параметра — объем изменений и уровень исследования — и на их основе собрала матрицу сложности. Затем с помощью ИИ превратила её в простой калькулятор, который помогает определить сложность задачи и предварительную оценку в часах. Подробнее — на Хабре

Что делать, если классический A/B-тест не работает из-за конфаундеров и сетевых эффектов? Рассказал Платон Попов, дата-аналитик в команде A/B-платформы RWB, на примере кейса оценки эффекта таргетированной рекламы в ПВЗ. Сначала использовали Propensity Score Matching (PSM), но метод не прошёл валидацию: доля ложноположительных результатов оказалась выше допустимого уровня. ➡️ Тогда перешли к Double Machine Learning (DML) — и получили более устойчивую оценку. Читать статью на Хабре

🟣Дайджест полезного🟣 Через неделю осень — подводим итоги насыщенных месяцев работы. Мы много кодили, улучшали продукты и процессы, а ещё выступали на профессиональных мероприятиях и организовывали собственные, участвовали в хакатонах и проводили стажировки. Делимся полезными ссылками, а ещё больше летних событий — в каналах tech-команд Ecom.tech, MAGNIT TECH, Lamoda Tech, Data Fusion (ВТБ) и Купер.тех.

1️⃣ BerryLM-XL вошла в топ-3 русскоязычного бенчмарка MERA Дообученная командой RWB модель BerryLM-XL заняла 3-е место в общем лидерборде MERA с интегральной оценкой 0,835. Для сравнения, результат Human Benchmark на тех же задачах составляет 0,852. В топ-5 также вошла BerryLM-v2, занявшая 5-е место с оценкой 0,810. 2️⃣ Saint HighLoad++ 2026 Два дня конференции запомнились инженерными испытаниями, архитектурными задачами и десятками разговоров про системы, архитектуру и технологии с нашими CTO, а доклады наших спикеров вошли в топ-10 выступлений конференции. 3️⃣ TechDocs Meetup Поговорили о документации с разных сторон: как создавался портал разработчиков RWB, зачем техническим писателям единая система оценки задач и можно ли построить зрелые процессы документирования, если в команде всего один техписатель. Смотрите здесь: — Летопись документации разработчиков WB API — Единая система оценки задач техписателей: как внедрить новый подход без боли — 100 к 1: Как организовать подход «документация как услуга» в одиночку 4️⃣ Подкаст Tech Talks Запустили собственный подкаст про технологии RWB и людей, которые их создают. Смотрите первые выпуски и ждите новые! — Open Source, AI и Forks — Цена доверия: боты, капчи, ML и миллиарды запросов 5️⃣ Награды на премии Хакатоны России У нас сразу две победы на национальной премии «Хакатоны России»! Студенческий хакатон RWB по машинному обучению и программированию стал лучшим сразу в двух номинациях — «Дебют года» и «Лучший хакатон в сфере ИИ». К Хакатону присоединились более 270 студентов из ведущих вузов страны — НГУ, НГТУ, ТГУ, МИСИС, МИРЭА, СПбГУ, МАИ, Школы 21 и многих других. До финала дошли 100 участников, а 10 сильнейших команд представили свои решения экспертному жюри.

Как мы внедрили AIOps для контроля GPU-утилизации и повысили её на 60 процентов В RWB команда ML-платформы построила поверх мониторинга отдельный слой для управления такими кейсами на базе open source KeepHQ. Через систему прошло около 400 тысяч событий, а дедупликация составила ~99%. В новой статье на Хабре рассказываем, как устроили жизненный цикл алерта — от поиска владельца и сохранения контекста до автоматической проверки исправления и эскалации. И показываем, какие части Keep пришлось доработать и почему AI оказался далеко не главным элементом решения ⚙️ Результат: +62% к средней месячной утилизации GPU на одном из кластеров @rwb_delaet_ml

Запустили собственный сервис для сокращения ссылок WB Link Можно сокращать длинные ссылки и мгновенно генерировать QR-коды. Без регистрации и СМС — пользуйтесь сами и отправляйте коллегам :)

Учим небольшую LLM с нуля: гибридное внимание, XSA, доменные бленды и загадки роста онлайн-бенчмарков Команда обучения и инференса RWB обучила текстовую версию Qwen3.5-2B с нуля — без pretrained-весов. В статье разбираем весь путь: от сборки доменных датасетов и Megatron-LM до online-оценки и экспериментов с архитектурой 👆 Хайлайты: ⏹️ обучили модель сначала на 1, затем на 11 трлн токенов ⏹️ протестировали XSA и получили −0,009 val loss и +1,6 п. п. на MMLU ⏹️ разобрались, почему MMLU в разных форматах показывает совершенно разную динамику ⏹️ проверили, как меняется качество при разных доменных блендах ⏹️ нашли слабое место модели — математику и reasoning А ещё рассказали, как устроен наш pretrain-пайплайн и какие эксперименты планируем дальше. ➡️ Узнать больше @rwb_delaet_ml

Сколько запросов делает ваш фронтенд, чтобы отрисовать один экран? Разбираемся с BFF (Backend for Frontend) — слоем между интерфейсом и доменными сервисами, который берёт на себя агрегацию данных, кэширование и защиту от нестабильности внутренних систем. О том, как BFF применяют в RWB, расскажут Александр Краснянский, Frontend Lead команды РКИ, и Сергей Корень, Backend Lead главной страницы и онбординга Портала Продавца. ⏹️Когда фронтенду действительно нужен свой BFF?

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

⏹️Где сейчас проходит граница между фронтендом и бэкендом?

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

⏹️Как BFF ускоряет разработку продуктов?

Главное преимущество — не нужно согласовывать доработки сразу в нескольких бэкенд-командах. Если новая страница требует данные из нескольких сервисов, BFF собирает контракт на своей стороне и отдаёт фронтенду единый API. Фронтенд и BFF-команда разрабатывают функциональность параллельно с доменными сервисами — это сокращает зависимости и ускоряет вывод фич на продакшен.

⏹️Как не допустить дублирования бизнес-логики в BFF?

Бизнес-логика остаётся в доменных сервисах. В BFF допускается только логика представления: агрегация, преобразование моделей, сценарии взаимодействия. Помогают: чёткое разделение ответственности между слоями, контрактное проектирование API, общие библиотеки для типизации и автогенерация клиентов по OpenAPI и GraphQL-схемам.

⏹️Не увеличивает ли BFF задержки и риски для безопасности?

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

⏹️Самый интересный кейс с BFF

Главная страница Портала Продавца зависит от сервисов с разными SLA: один отвечает за 50 мс, другой — за 500, третий может периодически деградировать под нагрузкой. BFF берёт на себя управление таймаутами, кэшированием и сценариями деградации — и отдаёт фронтенду стабильный контракт, даже когда часть сервисов работает нестабильно.

⏹️Как устроена команда, которая работает над BFF?

Чаще всего это кросс-функциональная продуктовая команда: фронтенд- и бэкенд-разработчики, QA-инженеры, DevOps/SRE-инженеры, аналитики и продуктовые менеджеры. Хорошая практика — когда инженеры понимают обе стороны системы и вместе проектируют контракты. Цель — минимизировать межкомандные зависимости и повысить скорость поставки продукта.

⏹️Какие навыки нужны инженеру и что в этой работе нравится больше всего

Сильный инженер разбирается и во фронтенде, и в бэкенде: знает JavaScript/TypeScript/Go, умеет проектировать API и работать с микросервисной архитектурой. Но главное — системное мышление: видеть продукт целиком, а не только свой слой. BFF находится на стыке фронтенда и бэкенда, поэтому влияет на весь пользовательский сценарий. Главный челлендж — не превратить BFF в ещё один монолитный бэкенд. Главный плюс — быстро адаптировать систему под продукт без изменений в доменных сервисах.

Половина лета прошла: что успели? Наши коллеги — выпуститься из университета, сходить в поход, построить на сап-доске парусник и многое другое. Рассказываем, как проводят лето наши инженеры, аналитики и тестировщики (когда не сидят за компьютером 🤭).

⭐️⭐️ Уже сегодня — RWB TechDocs Meetup! Включайте трансляцию в 16:00: ⏹️VK ⏹️YouTube

🔔 Цена доверия: боты, капчи, ML и миллиарды запросов В новом выпуске подкаста Tech Talks разбираемся, как отличить человека от бота, почему капчи далеко не всегда лучший инструмент защиты и какую роль в этом играют машинное обучение и поведенческая аналитика. Вместе с Алексеем Медошиным, директором департамента защиты от DDoS-атак, поговорили о том, почему абсолютной защиты не существует, как устроена экономика кибератак и зачем крупным компаниям создавать собственные решения вместо готовых продуктов. Смотреть: ⏹️YouTube ⏹️VK

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

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

⭐️⭐️ На следующей неделе ждем вас на TechDocs митапе! А пока ближе знакомимся с докладами наших коллег. Когда: 16 июля, 16:00 Формат: онлайн ➡️ Регистрация

Напоминание: не катите ничего в пятницу

⭐️⭐️ 16 июля подключаемся на онлайн-митап TechDocs Поговорим о документации с разных сторон: как создавался портал разработчиков RWB, зачем техническим писателям единая система оценки задач и можно ли построить зрелые процессы документирования, если в команде всего один техписатель.

В программе: ⏹️ «Летопись документации разработчиков WB API» | Лидия Рудакова, лид команды документирования Public API. ⏹️ «Единая система оценки задач техписателей: как внедрить новый подход без боли» | Евгений Красильникова, технический писатель в команде разработки документации и методик обучения ПО. ⏹️ «100 к 1: Как организовать подход "документация как услуга" в одиночку» | Антон Гафаров, технический писатель в команде FinTech Infra.

Когда: 16 июля, 16:00 Формат: онлайн ➡️ Регистрируйтесь

Вы это слышите? Мы тоже! Первый выпуск Tech Talks — подкаста про технологии RWB и людей, которые их создают, — уже в сети. Александр Стовбунский, техлид команды поддержки инфраструктурных сервисов, и Константин Макаров, техлид в команде корпоративных коммуникаций, встретились, чтобы поговорить про опенсорс без романтизации — с форками, конфликтами при слиянии, ответственностью мейнтейнера и влиянием AI на профессиональный путь разработчика. ⏹️YouTube ⏹️VK Делитесь впечатлениями в комментариях и предлагайте свои темы — самые интересные увидите в новых выпусках!

Вы уже несколько лет в IT. Не раз меняли команды. Казалось бы, знаете, как это работает. Но каждый раз первый месяц в новой команде — это стресс и неопределенность. Рассказываем, как сделать процесс адаптации эффективнее. Поделитесь в комментариях — опыт старших специалистов помогает молодежи избежать этих ошибок ⏪️

Принесли ещё ML-новостей 🔥🔥🔥