39 Lessons on Building ML Systems, Scaling, Execution, and More

Начать отсюда Тексты Выступления Прототипы Обо мне

39 Lessons on Building ML Systems, Scaling, Execution, and More

39 уроков о построении ML-систем, масштабировании, исполнении и не только

[ machinelearning engineering production leadership ] · 10 min read

[ machinelearning engineering production leadership ] · 10 мин чтения

Industry ML conferences are intense. There’s so much information, learning, and context switching between talks and posters and hallway conversations that leaves you exhausted each day. Thus, whenever there’s a break, taking a few minutes to reflect and take notes helps to solidify the learning. Here are my notes from ML conferences in 2024.

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

(I also had the opportunity to share my work at a few of these conferences. Here are the slides for my talks at the Netflix PRS Workshop and the AI Engineer World’s Fair. Unfortunately, my oral presentation at the Amazon ML Conference is internal only.)

(Мне также довелось поделиться своей работой на нескольких из этих конференций. Вот слайды моих выступлений на Netflix PRS Workshop и AI Engineer World’s Fair. К сожалению, моё устное выступление на Amazon ML Conference доступно только внутри компании.)

• • •

Building effective machine learning systems

Построение эффективных систем машинного обучения

1. The real world is messy. To build systems that work, we need to define reward functions (that define labels), operationalize the world as data, find levers that make a difference, and measure what matters. Beware of those who tell you ML is a walk in the park.

1. Реальный мир — это бардак. Чтобы строить работающие системы, нужно определить функции вознаграждения (которые задают метки), операционализировать мир в виде данных, найти рычаги, которые что-то меняют, и измерять то, что важно. Не верьте тем, кто говорит, что ML — это лёгкая прогулка.

2. Getting the reward function right is half the battle won. Short-term rewards don’t convey the full picture. Long-term rewards are delayed and tricky to attribute. Proxy rewards are finicky and may not correlate well with business metrics. And most rewards are sparse, with feedback few and far between. Invest early in reward function engineering.

2. Правильно подобранная функция вознаграждения — это половина победы. Краткосрочные награды не передают полную картину. Долгосрочные — отсрочены и трудно атрибутируются. Прокси-награды капризны и могут плохо коррелировать с бизнес-метриками. А большинство наград разрежены: обратная связь редкая и нерегулярная. Инвестируйте в инженерию функций вознаграждения с самого начала.

3. You don’t always need machine learning. Heuristics and SQL queries are valuable baselines. Start simple and see if the juice is worth the squeeze. Remember the first rule of machine learning: Start without machine learning.

3. ML нужен не всегда. Эвристики и SQL-запросы — это ценные базлайны. Начинайте с простого и смотрите, стоит ли овчинка выделки. Помните первое правило машинного обучения: начинайте без машинного обучения.

4. Machine learning involves trade-offs. Recall vs. precision. Explore vs. exploit. Relevance vs. diversity vs. serendipity. Accuracy vs. speed vs. cost. The challenge is figuring out the right balance for your user experience.

4. Machine learning — это компромиссы. Полнота против точности. Исследование против эксплуатации. Релевантность против разнообразия против серендипности. Точность против скорости против стоимости. Задача — найти правильный баланс под ваш пользовательский опыт.

5. Set realistic expectations. Most problems have a ceiling on what can be achieved, especially those that involve predicting the behavior of unpredictable humans (e.g., search, recommendations, fraud). It may not make sense to aim beyond the ceiling, unless you’re doing core research to push the boundaries on what’s possible.

5. Ставьте реалистичные ожидания. У большинства задач есть потолок достижимого, особенно у тех, где надо предсказывать поведение непредсказуемых людей (поиск, рекомендации, фрод). Целиться выше потолка обычно бессмысленно — разве что вы ведёте фундаментальное исследование и расширяете границы возможного.

6. Don’t overlook the dimension of time. User preferences change. Inventory gets drawn down. Content relevance shifts. Daily, seasonally, over months and years. If time is a key factor in your problem (e.g., recommendations, search, news feed), ensure your systems and models are time-aware.

6. Не забывайте про измерение времени. Предпочтения пользователей меняются. Запасы расходуются. Релевантность контента дрейфует. По дням, по сезонам, по месяцам и годам. Если время — ключевой фактор вашей задачи (рекомендации, поиск, лента новостей), сделайте систему и модели time-aware.

7. Evals are a differentiator and moat. Over the past two years, teams with solid evals have been able to continuously ship reliable, delightful experiences. No one regrets investing in a robust evaluation framework.

7. Эвалы — это дифференциатор и ров. За последние два года команды с сильными эвалами стабильно выпускают надёжный и приятный пользовательский опыт. Никто ещё не пожалел о вложениях в надёжный фреймворк оценки.

8. Design with the data flywheel in mind. Data alone is not the competitive advantage; it is the data flywheel. How will you gather user feedback to enhance your model, system, or product and fuel a better customer experience? (See this Tesla self-driving example from Andrej Karpathy.) Whoever turns the data flywheel faster, wins.

8. Проектируйте с прицелом на маховик данных. Сами по себе данные — это не конкурентное преимущество, конкурентное преимущество — это маховик данных. Как вы будете собирать обратную связь от пользователей, чтобы улучшать модель, систему или продукт и питать лучший клиентский опыт? (См. пример самоуправляемого автомобиля Tesla от Andrej Karpathy.) Кто быстрее крутит маховик данных — тот и побеждает.

9. Brandolini’s law: The amount of energy needed to refute bullshit is an order of magnitude larger than needed to produce it. The same applies to using LLMs. Generating ~~slop~~ content is easy relative to evaluating and guardrailing the defects. But the latter is how we earn—and keep—customer trust. Invest your efforts accordingly.

9. Закон Брандолини: энергии, нужной чтобы опровергнуть чушь, на порядок больше, чем чтобы её произвести. То же касается работы с LLM. Сгенерировать мусорный контент легко по сравнению с тем, чтобы оценить и заглушить дефекты. Но именно последнее — это то, как мы зарабатываем и удерживаем доверие клиентов. Распределяйте усилия соответственно.

10. We probably won’t have one model to rule them all. Instead, each product will likely have several models supporting it. Maybe a bigger model orchestrating several smaller models. This way, each smaller model can give their undivided attention to their task.

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

11. Altman’s law: When a new model drops, are you nervous, or are you super pumped? Consciously design your product so that you’re in the latter camp. Be prepared to swap the model anytime and reap the benefits of constantly improving models. The model isn’t your product—the system around it is.

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

12. Build with an eye toward the future. Flexibility beats specialization in the long run. Remember The Bitter Lesson. An LLM that’s a bit worse now will likely outperform a custom finetune later, especially as LLMs get cheaper (two orders of magnitude in 18 months!), faster, and more capable. Other examples include using a generative/extractive approach vs. named entity recognition/classification, and explore-exploit/reinforcement learning vs. supervised learning.

12. Стройте с прицелом на будущее. В долгосрочной перспективе гибкость побеждает специализацию. Помните The Bitter Lesson. LLM, который сейчас чуть хуже, скорее всего обгонит вашу кастомную дообученную модель позже — особенно по мере того, как LLM становятся дешевле (в 100 раз за 18 месяцев!), быстрее и способнее. Другие примеры: генеративный/экстрактивный подход против named entity recognition/классификации, и explore-exploit/reinforcement learning против обучения с учителем.

Production and scaling

Продакшн и масштабирование

13. Don’t underestimate the effort it takes to go from demo to production. “There’s a large class of problems that are easy to imagine and build demos for, but extremely hard to make products out of. For example, self-driving. It’s easy to demo a car self-driving around a block but making it into a product takes a decade.” — Andrej Karpathy

13. Не недооценивайте усилия, нужные чтобы дойти от демо до продакшна. «Есть большой класс задач, для которых легко представить и собрать демо, но из которых крайне трудно сделать продукт. Например, самоуправляемые машины. Показать машину, которая сама едет вокруг квартала, — легко; превратить это в продукт — это десятилетие работы». — Andrej Karpathy

14. Scale makes everything harder. While we may not need to face it head-on from day one, we should be ready for it. Especially if we have to support multiple existing markets, languages, devices, user experiences, etc.

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

15. Each 10x-ing of scale/traffic will uncover new bugs and issues. Prepare early for the operational challenges that come with scale and just keeping the lights on.

15. Каждое десятикратное увеличение масштаба/трафика вскроет новые баги и проблемы. Готовьтесь заранее к операционным вызовам, которые приходят вместе с масштабом, и просто к тому, чтобы держать свет включённым.

16. Depending on your product, LLMs are cheap or expensive. “Even the most expensive LLMs are not that expensive for B2B scale; even the cheapest LLMs are not that cheap for consumer scale.” — Will Larson. If you’re mostly B2B or running internal workflows, using LLM APIs could be viable long-term. Address scale when you need to, not prematurely.

16. В зависимости от продукта LLM либо дёшевы, либо дороги. «Даже самые дорогие LLM не так дороги для B2B-масштаба; даже самые дешёвые LLM не так дёшевы для consumer-масштаба». — Will Larson. Если вы в основном B2B или гоняете внутренние workflow, использовать LLM API может быть жизнеспособно надолго. Беритесь за масштаб тогда, когда это действительно нужно, а не преждевременно.

17. [Corollary] The economics aren’t in the way; it’s trust, reliability, security, etc. Costs will keep dropping. But faithfulness, hallucinations, prompt injections, etc. are still open problems. They’re the bottleneck to wider integration of LLMs in user-facing experiences.

17. [Следствие] Экономика — не препятствие; препятствие — доверие, надёжность, безопасность и т. д. Стоимость будет продолжать падать. А вот достоверность, галлюцинации, prompt injection и прочее — всё ещё открытые проблемы. Именно они узкое место для более широкой интеграции LLM в пользовательский опыт.

18. Get the fundamentals right. Robust data pipelines, instrumentation, evaluation, guardrails, experimentation, monitoring, metrics. These core capabilities are essential—and reusable—across most products. Investing in them early will save you the development and operational cost associated with each new product.

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

19. Start simple, always. Complexity will creep in as we patch edge cases and extend an existing system for new requirements and features. Thus, a system that starts complex will inevitably buckle under its own weight or become an operational nightmare.

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

20. Not everything needs to be in real-time. If your user experience allows it, consider batch or asynchronous workflows to simplify the system design and reduce operational costs. When designing a new system, ask yourself: Can this be async?

20. Не всё должно быть в реальном времени. Если пользовательский опыт это позволяет, рассмотрите батч- или асинхронные workflow, чтобы упростить дизайн системы и снизить эксплуатационные расходы. Проектируя новую систему, задайте себе вопрос: можно ли это сделать асинхронно?

21. Design for fast failure detection and recovery. No system is perfect; stuff will slip through. Yet, there’s an optimal investment balance between prevention and cure. Monitoring, alerts, rollbacks, Andon cords—these will go a long way.

21. Проектируйте быстрое обнаружение и восстановление после сбоев. Ни одна система не идеальна; что-то всё равно проскочит. И есть оптимальный баланс инвестиций между профилактикой и лечением. Мониторинг, алерты, откаты, andon-шнуры — всё это даёт большую отдачу.

Execution and collaboration

Исполнение и сотрудничество

22. Execution is everything. Execution is navigating from where we are today (e.g., legacy systems, low velocity, high opex) to our long-term vision. It’s everything from idea to design to implementation to launch to measurement to operations and everything else in between. Executing well is the difference between success and failure.

22. Исполнение — это всё. Исполнение — это навигация из текущего состояния (легаси-системы, низкая скорость, высокий opex) к долгосрочному видению. Это всё: от идеи к дизайну, к реализации, к запуску, к измерению, к эксплуатации и ко всему, что между ними. Хорошее исполнение — это разница между успехом и провалом.

23. Your rate of iteration = your rate of innovation. Focus on experimenting fast, getting rapid feedback, and updating or pivoting quickly. Velocity matters.

23. Ваша скорость итераций = ваша скорость инноваций. Фокусируйтесь на быстрых экспериментах, быстрой обратной связи и быстром обновлении или развороте. Скорость имеет значение.

24. [Counterpoint] Breakthroughs will take longer than you think. Nine women can’t give birth to a baby in a month, and we can’t rush game-changing research and innovation. Start early, be patient, and keep pushing.

24. [Контрпункт] Прорывы займут больше времени, чем вы думаете. Девять женщин не родят ребёнка за месяц, и нельзя ускорить меняющие игру исследования и инновации. Начинайте рано, наберитесь терпения и продолжайте давить.

25. Not every challenge is technical. Some challenges are about alignment, culture, and organizations. Working with people is hard. When you zoom out, it turns out that tech is often the easier part.

25. Не каждый вызов — технический. Некоторые касаются согласования, культуры и организаций. Работать с людьми трудно. Если отойти на шаг назад, оказывается, что технологии часто — это самая лёгкая часть.

26. It takes a village to raise a machine learning system. Infra, engineering, data, ML, design, product, business, and more. No role is more important than the others. 1 + 1 =3.

26. Чтобы вырастить ML-систему, нужна целая деревня. Инфра, инженерия, данные, ML, дизайн, продукт, бизнес и многое другое. Ни одна роль не важнее остальных. 1 + 1 = 3.

27. Genius can come from anywhere. Not just the ivory towers of research. Some of the best ideas come from people who deeply understand the customer, regardless of whether their role is technical, creative, or operational. Don’t overlook the wisdom of the crowd.

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

28. You don’t have to go it alone. Whatever you’re working on, there will be others tackling similar problems. Reach out to them to learn and/or collaborate, either within your organization or on the internet. Together, we’re stronger.

28. Не надо идти в одиночку. Над чем бы вы ни работали, есть другие, кто бьётся над похожими задачами. Свяжитесь с ними, чтобы поучиться и/или скооперироваться, — внутри вашей организации или в интернете. Вместе мы сильнее.

29. People want to help. Especially if you’ve done your homework, bring data, and keep an open mind. Everyone, and I mean everyone, at these conferences is incredibly kind and generous. I experienced this warmth firsthand interacting with some of the leaders in the field. The strongest are also the kindest.

29. Люди хотят помочь. Особенно если вы сделали домашнюю работу, принесли данные и держите ум открытым. Все, и я имею в виду буквально все, на этих конференциях невероятно добры и щедры. Я ощутил это тепло на себе, общаясь с некоторыми из лидеров отрасли. Самые сильные одновременно и самые добрые.

30. What seems obvious to you can be game-changing for others. Expertise is a ladder. Wherever you’re at, there are people a few rungs below (and a few rungs above) who are eager to learn from you. Thus, share what you know, even if you think it’s too basic and not worth sharing. It could help someone with a challenge they’re facing.

30. То, что кажется очевидным вам, может стать переломным для других. Экспертиза — это лестница. Где бы вы ни были, есть люди на пару ступеней ниже (и пару ступеней выше), которые хотят у вас учиться. Поэтому делитесь тем, что знаете, даже если кажется, что это слишком базово и не стоит публикации. Это может помочь кому-то с его задачей.

31. Tune out the noise; focus on building. Don’t get nerd-sniped by the daily barrage of shiny new techniques. Most don’t pan out anyway. For real alpha on what actually works, have hallway conversations and DMs with the practitioners who are quietly crushing it.

31. Отключите шум; фокусируйтесь на стройке. Не дайте себя задиподать ежедневным потоком блестящих новых техник. Большинство из них всё равно никуда не приведёт. За настоящей альфой по тому, что реально работает, идите в коридорные разговоры и в личку к практикам, которые тихо разрывают.

Building for users

Строить для пользователей

32. Always work backwards from the customer. Why are we solving this problem? How does it help the customer? What are the tangible and intangible benefits? Unless you’re a researcher, don’t do science for the sake of science. Focus on the customer.

32. Всегда работайте от клиента назад. Зачем мы решаем эту задачу? Как это помогает клиенту? Какие осязаемые и неосязаемые выгоды? Если вы не исследователь, не занимайтесь наукой ради науки. Фокус на клиенте.

33. To create winning products, dream big and sweat the small stuff. Aim for the stars but don’t forget the details. The best leaders have vision and get their hands dirty with the details. You can’t just do one or the other; you need to do both.

33. Чтобы создавать продукты-победители, мечтайте по-крупному и возитесь с мелочами. Целитесь в звёзды, но не забывайте о деталях. Лучшие лидеры обладают видением и при этом не боятся испачкать руки в деталях. Нельзя выбрать только одно; нужно и то и другое.

34. Humans are insatiable. LLMs will automate some tasks. LLMs will simplify others. But there will always be new problems to solve, and more things to build. AI won’t steal your job—it’ll just make it more interesting.

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

Speaking at and attending conferences

Выступления на конференциях и их посещение

35. Speaking at industry conferences is a tightrope act. It’s a delicate balance between sharing valuable insights and protecting the secret sauce. You’ll see this when speakers rely on public data, reference published work and public tech blogs, stick to high-level ideas, and choose their words carefully. (This is also why many of the best practitioners decline to speak.) Nonetheless, everyone understands.

35. Выступление на индустриальной конференции — это хождение по канату. Тонкий баланс между тем, чтобы поделиться ценными инсайтами и сохранить секретный соус. Это видно, когда спикеры опираются на публичные данные, ссылаются на опубликованные работы и публичные техблоги, держатся высокоуровневых идей и тщательно подбирают слова. (Поэтому многие из лучших практиков отказываются выступать.) Тем не менее, все всё понимают.

36. GOATs are GOATs because they work hard. I saw many diligently taking notes, pulling up the papers being presented to review the tables and charts, and following up on points they didn’t understand. This is why they’re the best.

36. GOAT’ы становятся GOAT’ами потому, что много работают. Я видел, как многие из них старательно ведут заметки, открывают презентуемые статьи, чтобы изучить таблицы и графики, и допрашивают про пункты, которые не поняли. Поэтому они и лучшие.

37. Conference insiders keep it friendly during public Q&A. The hard questions and debates are reserved for hallway conversations, happy hours, and over dinner.

37. Свои на конференциях держатся дружелюбно во время публичных Q&A. Жёсткие вопросы и дебаты резервируются для разговоров в коридорах, на happy hour и за ужином.

38. No one really cares how good your slides look. Fancy layouts? Dark mode? Not a priority. Never has been, from what I can tell. Some of the top speakers just use the default font on white backgrounds. Substance over style, always.

38. Никому особо не важно, как красиво выглядят ваши слайды. Хитрые лейауты? Тёмная тема? Не приоритет. Никогда и не были, насколько я могу судить. Некоторые из топ-спикеров используют просто шрифт по умолчанию на белом фоне. Содержание важнее формы, всегда.

39. Get enough geeks together and magic happens. The energy, the inspiration, the ideas. It’s infectious. I leave every conference on a high, fired up by thoughts on what to explore next, motivated by the conversations, and ready to build. Highly recommend attending a good conference at least once a year.

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

Похожее чтение

What We’ve Learned From A Year of Building with LLMs

The Metagame of Applying Machine Learning

Stories and Advice from Machine Learning Practitioners

Чему мы научились за год работы с LLM Метаигра прикладного машинного обучения Истории и советы от практиков машинного обучения

If you found this useful, please cite this write-up as:

Если этот материал оказался полезен, цитируйте его так:

Yan, Ziyou. (Nov 2024). 39 Lessons on Building ML Systems, Scaling, Execution, and More. eugeneyan.com. https://eugeneyan.com/writing/conf-lessons/.

or

или

@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/} }