39 Lessons on Building ML Systems, Scaling, Execution, and More
Юджин Ян делится 39 уроками с ML-конференций 2024 года, охватывающими построение эффективных ML-систем, масштабирование, исполнение и работу с пользователями. Среди ключевых идей: важность правильно выстроенной функции вознаграждения, ценность эвалов как конкурентного преимущества, маховик данных как реальное преимущество (со ссылкой на пример Tesla от Andrej Karpathy), и закон Альтмана о том, что продукт должен выигрывать от появления новых моделей. Автор подчёркивает, что путь от демо до продакшна сильно недооценивается (цитируя Karpathy про self-driving), что LLM дёшевы для B2B и дороги для consumer-масштаба (по Will Larson), и что узкое место — не экономика, а доверие, надёжность и галлюцинации. В разделах об исполнении он напоминает, что скорость итераций равна скорости инноваций, что не все вызовы технические, и что лучшие практики добры и щедры. Финальные уроки — о работе от клиента, о ненасытности людей (AI не отнимет работу, а сделает её интереснее) и о магии живых конференций.
39 уроков о построении ML-систем, масштабировании, исполнении и не только
[ machinelearning engineering production leadership ] · 10 мин чтения
Индустриальные ML-конференции — это интенсив. Столько информации, обучения и переключений контекста между докладами, постерами и разговорами в коридорах, что к концу каждого дня выматываешься до предела. Поэтому, как только появляется пауза, несколько минут на рефлексию и заметки помогают закрепить услышанное. Вот мои заметки с ML-конференций 2024 года.
(Мне также довелось поделиться своей работой на нескольких из этих конференций. Вот слайды моих выступлений на Netflix PRS Workshop и AI Engineer World’s Fair. К сожалению, моё устное выступление на Amazon ML Conference доступно только внутри компании.)
• • •
Построение эффективных систем машинного обучения
1. Реальный мир — это бардак. Чтобы строить работающие системы, нужно определить функции вознаграждения (которые задают метки), операционализировать мир в виде данных, найти рычаги, которые что-то меняют, и измерять то, что важно. Не верьте тем, кто говорит, что ML — это лёгкая прогулка.
2. Правильно подобранная функция вознаграждения — это половина победы. Краткосрочные награды не передают полную картину. Долгосрочные — отсрочены и трудно атрибутируются. Прокси-награды капризны и могут плохо коррелировать с бизнес-метриками. А большинство наград разрежены: обратная связь редкая и нерегулярная. Инвестируйте в инженерию функций вознаграждения с самого начала.
3. ML нужен не всегда. Эвристики и SQL-запросы — это ценные базлайны. Начинайте с простого и смотрите, стоит ли овчинка выделки. Помните первое правило машинного обучения: начинайте без машинного обучения.
4. Machine learning — это компромиссы. Полнота против точности. Исследование против эксплуатации. Релевантность против разнообразия против серендипности. Точность против скорости против стоимости. Задача — найти правильный баланс под ваш пользовательский опыт.
5. Ставьте реалистичные ожидания. У большинства задач есть потолок достижимого, особенно у тех, где надо предсказывать поведение непредсказуемых людей (поиск, рекомендации, фрод). Целиться выше потолка обычно бессмысленно — разве что вы ведёте фундаментальное исследование и расширяете границы возможного.
6. Не забывайте про измерение времени. Предпочтения пользователей меняются. Запасы расходуются. Релевантность контента дрейфует. По дням, по сезонам, по месяцам и годам. Если время — ключевой фактор вашей задачи (рекомендации, поиск, лента новостей), сделайте систему и модели time-aware.
7. Эвалы — это дифференциатор и ров. За последние два года команды с сильными эвалами стабильно выпускают надёжный и приятный пользовательский опыт. Никто ещё не пожалел о вложениях в надёжный фреймворк оценки.
8. Проектируйте с прицелом на маховик данных. Сами по себе данные — это не конкурентное преимущество, конкурентное преимущество — это маховик данных. Как вы будете собирать обратную связь от пользователей, чтобы улучшать модель, систему или продукт и питать лучший клиентский опыт? (См. пример самоуправляемого автомобиля Tesla от Andrej Karpathy.) Кто быстрее крутит маховик данных — тот и побеждает.
9. Закон Брандолини: энергии, нужной чтобы опровергнуть чушь, на порядок больше, чем чтобы её произвести. То же касается работы с LLM. Сгенерировать мусорный контент легко по сравнению с тем, чтобы оценить и заглушить дефекты. Но именно последнее — это то, как мы зарабатываем и удерживаем доверие клиентов. Распределяйте усилия соответственно.
10. Скорее всего, не будет одной модели, чтобы править всеми. Вместо этого у каждого продукта будут несколько моделей. Возможно, бóльшая модель оркестрирует несколько меньших. Так каждая маленькая модель может полностью сосредоточиться на своей задаче.
11. Закон Альтмана: когда выходит новая модель, вы нервничаете или в восторге? Сознательно проектируйте продукт так, чтобы оказаться во втором лагере. Будьте готовы поменять модель в любой момент и пожинать плоды постоянно улучшающихся моделей. Модель — это не ваш продукт; продукт — это система вокруг неё.
12. Стройте с прицелом на будущее. В долгосрочной перспективе гибкость побеждает специализацию. Помните The Bitter Lesson. LLM, который сейчас чуть хуже, скорее всего обгонит вашу кастомную дообученную модель позже — особенно по мере того, как LLM становятся дешевле (в 100 раз за 18 месяцев!), быстрее и способнее. Другие примеры: генеративный/экстрактивный подход против named entity recognition/классификации, и explore-exploit/reinforcement learning против обучения с учителем.
Продакшн и масштабирование
13. Не недооценивайте усилия, нужные чтобы дойти от демо до продакшна. «Есть большой класс задач, для которых легко представить и собрать демо, но из которых крайне трудно сделать продукт. Например, самоуправляемые машины. Показать машину, которая сама едет вокруг квартала, — легко; превратить это в продукт — это десятилетие работы». — Andrej Karpathy
14. Масштаб всё усложняет. Возможно, его не придётся преодолевать с первого дня, но к нему нужно быть готовым. Особенно если приходится поддерживать несколько существующих рынков, языков, устройств, пользовательских опытов и т. д.
15. Каждое десятикратное увеличение масштаба/трафика вскроет новые баги и проблемы. Готовьтесь заранее к операционным вызовам, которые приходят вместе с масштабом, и просто к тому, чтобы держать свет включённым.
16. В зависимости от продукта LLM либо дёшевы, либо дороги. «Даже самые дорогие LLM не так дороги для B2B-масштаба; даже самые дешёвые LLM не так дёшевы для consumer-масштаба». — Will Larson. Если вы в основном B2B или гоняете внутренние workflow, использовать LLM API может быть жизнеспособно надолго. Беритесь за масштаб тогда, когда это действительно нужно, а не преждевременно.
17. [Следствие] Экономика — не препятствие; препятствие — доверие, надёжность, безопасность и т. д. Стоимость будет продолжать падать. А вот достоверность, галлюцинации, prompt injection и прочее — всё ещё открытые проблемы. Именно они узкое место для более широкой интеграции LLM в пользовательский опыт.
18. Доведите фундамент до ума. Надёжные дата-пайплайны, инструментация, оценка, гардрейлы, эксперименты, мониторинг, метрики. Эти базовые возможности — необходимые и переиспользуемые для большинства продуктов. Инвестиции в них на ранней стадии экономят затраты на разработку и эксплуатацию каждого следующего продукта.
19. Начинайте просто, всегда. Сложность всё равно подкрадётся, когда мы будем латать пограничные случаи и расширять существующую систему под новые требования и фичи. Поэтому система, которая стартует со сложности, неизбежно рухнет под собственным весом или превратится в эксплуатационный кошмар.
20. Не всё должно быть в реальном времени. Если пользовательский опыт это позволяет, рассмотрите батч- или асинхронные workflow, чтобы упростить дизайн системы и снизить эксплуатационные расходы. Проектируя новую систему, задайте себе вопрос: можно ли это сделать асинхронно?
21. Проектируйте быстрое обнаружение и восстановление после сбоев. Ни одна система не идеальна; что-то всё равно проскочит. И есть оптимальный баланс инвестиций между профилактикой и лечением. Мониторинг, алерты, откаты, andon-шнуры — всё это даёт большую отдачу.
Исполнение и сотрудничество
22. Исполнение — это всё. Исполнение — это навигация из текущего состояния (легаси-системы, низкая скорость, высокий opex) к долгосрочному видению. Это всё: от идеи к дизайну, к реализации, к запуску, к измерению, к эксплуатации и ко всему, что между ними. Хорошее исполнение — это разница между успехом и провалом.
23. Ваша скорость итераций = ваша скорость инноваций. Фокусируйтесь на быстрых экспериментах, быстрой обратной связи и быстром обновлении или развороте. Скорость имеет значение.
24. [Контрпункт] Прорывы займут больше времени, чем вы думаете. Девять женщин не родят ребёнка за месяц, и нельзя ускорить меняющие игру исследования и инновации. Начинайте рано, наберитесь терпения и продолжайте давить.
25. Не каждый вызов — технический. Некоторые касаются согласования, культуры и организаций. Работать с людьми трудно. Если отойти на шаг назад, оказывается, что технологии часто — это самая лёгкая часть.
26. Чтобы вырастить ML-систему, нужна целая деревня. Инфра, инженерия, данные, ML, дизайн, продукт, бизнес и многое другое. Ни одна роль не важнее остальных. 1 + 1 = 3.
27. Гений может прийти откуда угодно. Не только из академических башен из слоновой кости. Некоторые из лучших идей приходят от тех, кто глубоко понимает клиента, — независимо от того, техническая ли у них роль, креативная или операционная. Не недооценивайте мудрость толпы.
28. Не надо идти в одиночку. Над чем бы вы ни работали, есть другие, кто бьётся над похожими задачами. Свяжитесь с ними, чтобы поучиться и/или скооперироваться, — внутри вашей организации или в интернете. Вместе мы сильнее.
29. Люди хотят помочь. Особенно если вы сделали домашнюю работу, принесли данные и держите ум открытым. Все, и я имею в виду буквально все, на этих конференциях невероятно добры и щедры. Я ощутил это тепло на себе, общаясь с некоторыми из лидеров отрасли. Самые сильные одновременно и самые добрые.
30. То, что кажется очевидным вам, может стать переломным для других. Экспертиза — это лестница. Где бы вы ни были, есть люди на пару ступеней ниже (и пару ступеней выше), которые хотят у вас учиться. Поэтому делитесь тем, что знаете, даже если кажется, что это слишком базово и не стоит публикации. Это может помочь кому-то с его задачей.
31. Отключите шум; фокусируйтесь на стройке. Не дайте себя задиподать ежедневным потоком блестящих новых техник. Большинство из них всё равно никуда не приведёт. За настоящей альфой по тому, что реально работает, идите в коридорные разговоры и в личку к практикам, которые тихо разрывают.
Строить для пользователей
32. Всегда работайте от клиента назад. Зачем мы решаем эту задачу? Как это помогает клиенту? Какие осязаемые и неосязаемые выгоды? Если вы не исследователь, не занимайтесь наукой ради науки. Фокус на клиенте.
33. Чтобы создавать продукты-победители, мечтайте по-крупному и возитесь с мелочами. Целитесь в звёзды, но не забывайте о деталях. Лучшие лидеры обладают видением и при этом не боятся испачкать руки в деталях. Нельзя выбрать только одно; нужно и то и другое.
34. Люди ненасытны. LLM автоматизируют какие-то задачи. LLM упростят другие. Но всегда будут новые задачи, которые надо решать, и больше вещей, которые надо строить. AI не отнимет вашу работу — он просто сделает её интереснее.
Выступления на конференциях и их посещение
35. Выступление на индустриальной конференции — это хождение по канату. Тонкий баланс между тем, чтобы поделиться ценными инсайтами и сохранить секретный соус. Это видно, когда спикеры опираются на публичные данные, ссылаются на опубликованные работы и публичные техблоги, держатся высокоуровневых идей и тщательно подбирают слова. (Поэтому многие из лучших практиков отказываются выступать.) Тем не менее, все всё понимают.
36. GOAT’ы становятся GOAT’ами потому, что много работают. Я видел, как многие из них старательно ведут заметки, открывают презентуемые статьи, чтобы изучить таблицы и графики, и допрашивают про пункты, которые не поняли. Поэтому они и лучшие.
37. Свои на конференциях держатся дружелюбно во время публичных Q&A. Жёсткие вопросы и дебаты резервируются для разговоров в коридорах, на happy hour и за ужином.
38. Никому особо не важно, как красиво выглядят ваши слайды. Хитрые лейауты? Тёмная тема? Не приоритет. Никогда и не были, насколько я могу судить. Некоторые из топ-спикеров используют просто шрифт по умолчанию на белом фоне. Содержание важнее формы, всегда.
39. Соберите достаточно гиков в одном месте — и случится магия. Энергия, вдохновение, идеи. Это заразно. Я ухожу с каждой конференции на подъёме, заряженный мыслями о том, что исследовать дальше, мотивированный разговорами и готовый строить. Очень рекомендую посещать хорошую конференцию хотя бы раз в год.
Похожее чтение
Чему мы научились за год работы с LLM Метаигра прикладного машинного обучения Истории и советы от практиков машинного обучения
Если этот материал оказался полезен, цитируйте его так:
Yan, Ziyou. (Nov 2024). 39 Lessons on Building ML Systems, Scaling, Execution, and More. eugeneyan.com. https://eugeneyan.com/writing/conf-lessons/.
или
@article{yan2024conflessons, title = {39 Lessons on Building ML Systems, Scaling, Execution, and More}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2024}, month = {Nov}, url = {https://eugeneyan.com/writing/conf-lessons/} }
К 11 800+ читателям, получающим обновления по машинному обучению, RecSys, LLM и инженерии.