Заметочки по книге ML System Design — ч.1

TL;DR: книжка получилась неплохой. Не в смысле что там есть какой-то священный грааль, а в смысле что она возвращает тебя на землю. Если коротко, то с самого начала книжка кричит: «ПОДУМАЙ, НАДО ЛИ ТЕБЕ ДЕЛАТЬ ML-МОДЕЛЬКУ» и «ЧУВАК, БЕЙЗЛАЙН МОДЕЛЬКИ ЗАЧАСТУЮ ДАЖЕ ЛУЧШЕ». Это, на мой взгляд, очень хорошо. Тут почти нет конкретных техник или чего-то подобного, и нет конкретных рецептов чего заюзать шобы полетело с курса на karpov courses. Зато там есть рассуждения о том, что и как на каком этапе надо сделать, и как писать дизайн-док с нуля. Ребята даже карьеризм затрагивают, лол. А, и ещё — это не книжка чтобы повыёбываться на собесах, это книжка для жизни. Оно и понятно, у Валерия есть целый курс по сисдизу на собесах.

А ещё там много ссылок на фундаментальный резёрч, что приятно, и к концу книжки авторы с нами потихоньку собирают аж 2 дизайн-документа и кучу дополнительных примеров, которыми нас снабжают по ходу. Итак, вот мои хайлайты по общей структуре. Будет прям очень дохуя, поэтому telegra.ph:

1. Статья в блоге Karpathy 2017 года «Software 2.0», из которой сбылось почти всё. Статья, которая сравнивает написание кода человеком с написанием нейросети человеком. Я бы сказал, что это что-то вроде предсказания появления ChatGPT и агентов, которые будут выполнять кучу штук за нас «прямо из данных которые у нас есть». Заканчивается статья словами «In the short term, Software 2.0 will become increasingly prevalent in any domain where repeated evaluation is possible and cheap, and where the algorithm itself is difficult to design explicitly. There are many exciting opportunities to consider the entire software development ecosystem and how it can be adapted to this new programming paradigm. And in the long run, the future of this paradigm is bright because it is increasingly clear that when we develop AGI, it will certainly be written in Software 2.0.», и это это крайне неочевидный взгляд на вещи в 2017 году.

После идёт понятная штука: пока мы строим ML-пайплайн, мы должны первым делом ответить на 2 вопроса: «Что мы строим» и «Как оно должно быть построено». Вопросы непростые, опытным авторам пришлось отвечать на них целую книгу.

2. Дальше мы пытаемся понять, есть ли вообще проблема: для начала её надо найти и чётко сформулировать, как будто ты на экзамене по матану. После этого предлагается определить начальные границы проблемы через пять «Why»:

• Для чего надо решить проблему?
• Какую проблемы мы решаем?
• Почему и когда проблема появляется?
• Какие есть альтернативы решению проблемы?
• Почему мы хотим заставить эту штуку работать (с учётом тех ограничений которые у нас есть)?

После ответа на эти 5 «why» происходит переформулирование проблемы постепенным сужением поля зрения: сначала для C-level, потом для ребяток из отдела, а потом специализированные штуки и edge-cases для того кто это будет прогать.

Понятная штука, о которой авторы часто напоминают во время книги — во время формулировки проблемы ОБЯЗАТЕЛЬНО общайся и с директорами и с исполнителями: несмотря на то что это требует времени, оно поможет тебе добавить мозгов и более чётко сформулировать проблему, обозначить для крутых боссов нахрена это решать, и найти существующие решения, если они есть. Ещё это поможет понять, какие есть риски, ограничения и возможные дальнейшие проблемы, что очень важно, а тут целая подглава чисто про это.

3. Дальше идёт целая глава о том, что после того как вы решили, мол, вам ЖИЗНЕННО НЕОБХОДИМА эта ваша ML-система, надо посмотреть глазками вокруг: чё там в open-source, чё там у конкурентов, возможно можно купить что-то уже готовое, и плюсы или минусы такого решения. Например, расширяемость, поддержку, быструю раскатку и готовность посадить целую команду прогеров это всё писать и поддерживать. Ещё сравнивают риски open-source и proprietary tech. Короче говоря, полезная глава, если вы что-то дизайните не на собесе. Уже тут есть какие-то базовые индикаторы того что надо сделать пайплайн попроще, и способы такого упрощения, чтобы потратить как можно меньше компьюта непосредственно на модельку. Жаль, нету примерных исследований или метрик деградации, но не уверен что это возможно.

4. После этого происходит понятный транзишн к собственно написанию первичного дизайн-дока. Первичный дизайн-док тут включает в себя определение целей и анти-целей, структуры и наставления задалбывать людей до того момента, когда их «looks good for me» сменится на что-то более конструктивное, как гарантия того что они хотя бы открыли первую страницу. В идеале получить критику и альтернативы. Ещё тут затрагивается следующая мысль: дизайн-док должны увидеть как можно больше людей, и ты обязан сделать так чтобы его прочитали. Потрать время на разметку страниц и пиздатое содержание, чтобы люди меньше боялись монстра на 15+ страниц. Пожелания подрочить людям, которым платят за это деньги, я не нашёл.

5. НАКОНЕЦ-ТО что-то ML-specific — целая глава о том, как правильно определять метрики и функции потерь, чё такое proxy-метрики, как их выбирать и нахрена, ну и что такое иерархия метрик. ИМХО, эта глава получилось слабой: я честно прочитал всю и честно говорю — мне было скучно дочитывать. Рассказывают о разных трюках для DL-моделек: Focal Loss, что такое combined losses с аж 6ю примерами из сильно разноплановых статей, и огромный акцент на метриках. Конкретно мне зашли метрики консистентности и как их выбирать. Несмотря на то что мне не понравилась глава, тут я встретил первый крутой хайлайт из книги:

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

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

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

6. Продолжаем с ML-specific штуками: собираем датасеты. Подробная глава о том, как собирать датасет, почему данные так важны, почитайте Саню, если в 2025 году для вас важность качества данных — инсайт; что такое модальность, как собрать данные из разных источников, почему фичи на 20% чистых данных >>> фичи на 80% грязных данных, и всё такое. Ещё есть штуки про хранение сырых и агрегированных данных, когда и почему стоит увеличивать объёмы хранилища, и то чего я лично никогда не делал — способы правильно лейблить данные и работа с платформами для краудсорсинга. Чувствуется опыт обоих авторов и моя неподкованность в этом вопросе, поэтому было супер-полезно.

Ещё тут рассказывают о теореме Condorcet, так что я ощутил что не зря проучился эти два долгих года в РЭШ. Авторы предлагают кучу других способов понять консистентность разметчиков, выделить какой конкретно разметчик лажает и подобные побочные эффекты.

Кроме того, рассказывают, как лучше версионировать данные, если пришлось переключаться между версиями, и почему всегда нужно хранить метадату. Что такое feedback loop внутри модели и когда надо растить датасет, а когда уже, в целом, достаточно. Active и online learning упомянуты и сильно раскрыты. Даже как посчитать целесообразность добавления данных рассказали, и как примерно оценить эластичность метрики по доп. данным, что делать в случае cold start и очень крутые истории от Арсения и Валерия о том, чё строить первым (спойлер: ETL).

Убер-крутая глава. Серьёзно.

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

Сначала ребята рассказывают, как выбрать количество фолдов K; рассказывают про связь bias, variance, computation time и K, и процедуру выбора этой K. Далее — статья 95 года, которая рассказывает про бутстрап, и алгоритм выбора K из неё. Потом способы валидации для time-series данных, но, к сожалению, без combinatorial purged CV от M.L. de Prado.

Потом идёт крутая штука про adversarial validation как способ отловить data drift, и через неё выходим на то, как определять, что твой датасет не содержит слишком много одинаковых семплов. И всё это вместе формирует очень крутой алгоритм первичной защиты от ликов, ИМХО. В конце идёт так любимый мистором Валерием пуассоновский бутстрап и рассказывается, почему оно работает. Есть ещё чуть-чуть про бакетирование и агрегацию метрик внутри бакетов, если они дрифтуют.

Тема важная, и раскрыта авторами хорошо.

8. «Кто такой этот ваш бейзлайн?» — вопрос, на который отвечает следующая глава. Зачем он нужен, на что повесить сервис если основная модель лежит, почему лучше построить систему попроще и сразу протестировать, чем 100 лет лелеять устаревающего (и, возможно, бесполезного) гиганта, зачем нужна модулярность и ссылочка на статью о том что сложную модель проще продать, когда простая модель зачастую лучше.

Тут мы применяем формулу Тейлора и узнаём, что сначала была константа, начинаем с неё, и понимаем что для кучи проблем или для внезапных пиздецов в системе это, в общем-то, тоже решение. А ещё что бейзлайн на ифах — не всегда «слишком просто».

Дальше идёт про трейд-оффы, в т.ч. экономические, когда стоит улучшать модельку и стоит ли; про простоту фичей и трейдоффы между простотой и скорость подсчёта. А ещё в конце Арсений палит смешную идею тестового для кандидатов.

Главный месседж главы — simplicity > complexity.

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