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

Как заставить ее это «забыть» без полного переобучения, которое может занять дни или даже недели? Это не просто академический вопрос, а требование регуляторов и критическая задача для обеспечения приватности и безопасности.

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

В этой статье глубокое погружение в то, как измерить эффективность такого «забывания» и какие методы позволяют его достичь. От метрик забвения, таких как Unlearn Accuracy и MIA Metrics, до сохранения качества модели и вычислительной эффективности.

Если вы работаете с ML-моделями и сталкиваетесь с вопросами приватности, безопасности данных или просто хотите понять, как работает контролируемое «забывание», эта статья для вас 🙌

Через 2 дня закроется дополнительный прием докладов для стрима «Внедрение ИИ в цикл разработки» на Saint HighLoad++ 2026.

📍15 мая – последний день

Мы ищем тех, кто уже применяет AI в реальной инженерной работе: в требованиях, архитектуре, разработке, тестировании, CI/CD, эксплуатации, SRE. Не «как AI написал код», а как он встроился в процесс и что из этого вышло.

Особенно интересны кейсы, где было непросто: legacy, compliance, дорогой inference, сложный rollout, конфликт с процессами, скепсис команды. Что не взлетело, что пришлось переделывать, какие компромиссы приняли.

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

Присылайте ваши заявки, мы поможем оформить и собрать в подходящий формат: доклад, case clinic, postmortem.

✅ Подробности и кнопка для отправки заявки на сайте

Если исправил одну строку, а упал тест в модуле, который ты даже не открывал — это понедельник.

Если нажал rerun без изменений, и всё стало зелёным — это пятница.

#хроникиITбудней

Что ломается при росте систем — и как это разбирают на практике ⤵️

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

Эти четыре выступления из программы Saint HighLoad++ 2026 для тех, кто работает с архитектурным долгом, выносом функционала из монолита, платформенными ошибками на масштабе и внедрением AI в production-контур. Здесь и кейсы команд, и практические разборы инженерных решений — когда важно не только увидеть результат, но и понять, как к нему пришли.

1️⃣ Игра «System Design». Владимир Невзоров (Servicepipe)
Архитектурная викторина: задачи про протоколы, архитектуру, паттерны, антипаттерны и историю IT. Формат, в котором можно проверить собственное инженерное мышление на практических вопросах.

2️⃣ Мастер-класс «Детские болезни доменных платформ в BigTech: архитектурные ошибки, которые дорого чинить». Екатерина Лысенко (Независимый эксперт)
Разбор повторяющихся архитектурных ошибок в платформенных доменах: FinTech, compliance, заказы, каталог. Как похожие решения в разных системах со временем приводят к одинаковым проблемам.

3️⃣ Вынос функционала из монолита. Алексей Лосев (Wildberries & Russ)
Мастер-класс о том, как выносить критичный функционал, когда на полноценный распил монолита нет времени и ресурсов. На примере сервиса мастер-баланса — разбор нескольких архитектурных подходов, их плюсов и минусов, а также особенностей работы с базами данных и шардированием.

4️⃣ Мультимодальный RAG для чертежей и ГОСТов: как подружить NebulaGraph, Qdrant и Nemotron-Mamba в закрытом контуре. Андрей Носов (Raft)
Разбор гибридной системы поиска для инженерных задач: работа с чертежами, регламентами и структурой изделий, сочетание графового и векторного поиска, запуск AI-стека в приватном контуре с ограниченными ресурсами.

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

✅ Если в вашей работе сейчас есть похожие задачи — сохраните себе эти выступления: вы сможете найти не только кейсы, но и способы принятия решений в сложной архитектуре.

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

AI-native, AI-first, AI Engineer, Prompt Engineer — эти слова все чаще видим в вакансиях и стратегиях. Но спроси трех людей, что они значат, и получишь три мнения. Это создает путаницу на собесах, в командах, в стратегиях.

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

Начинаем с четырех терминов:
🔹 AI-native компания: что это и чем принципиально отличается от обычной
🔹 AI-first подход: синоним AI-native или все же что-то другое
🔹 AI Engineer: новая роль или переименованный ML Engineer
🔹 Prompt Engineer: профессия будущего или временный навык

👉 Напишите нам, как вы это понимаете. Коротко, своими словами, из своей практики.
 
Все варианты мы соберем и вынесем на живую дискуссию на Saint TeamLead Conf и Saint HighLoad++ в Питере. Там участники вместе с экспертным советом разберут, что получилось, и зафиксируют финальные версии в глоссарии. Авторы формулировок будут указаны.

Потом цикл повторится: новые термины, новый сбор, новая дискуссия.

Решения, которые экономят месяцы.

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

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

Программа Saint HighLoad++ 2026 особенно сильна в темах AI: от практики внедрения ML/LLM в продукты до инфраструктуры, данных и архитектурных решений, которые делают такие системы устойчивыми в проде. Рядом — платформенные подходы, эксплуатация и масштабирование: все, что определяет, как сегодня развиваются сложные инженерные системы.

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

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

✅ Если планировали участвовать, программу уже стоит посмотреть внимательно. Финальное повышение цены на билеты — 1 июня.

Ждем вас 22 и 23 июня в Санкт-Петербурге на Saint HighLoad++ 2026 🖐️

Архитектурное соревнование надо?

На Saint HighLoad++ 2026 вас ждет викторина по System Design и архитектуре в live-режиме 🔥

Ведущий игры: Владимир Невзоров, старший backend-разработчик на проекте Антибот по защите крупнейших банков, маркетплейсов от массовых ботовых атак.

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

✅ Для участия нужно заполнить форму до 17:00 сегодня (21.05)
➡️ Отборочный этап пройдет сегодня в 19:00 по ссылке

Четверо сильнейших выйдут в финал уже на самой конференции. Окунитесь в мир System Design, участвуйте и болейте за своего финалиста 🙌

Если вы строите продукт на базе AI или внедряете AI для внутренних нужд компании, приходите на доклад Егора Андреева «Почему вам (скорее всего) не нужен локальный LLM-инференс», с которым он выступит на Saint HighLoad++ 2026.

В этом видео Егор поделился некоторыми деталями своего доклада 📝