Five Lessons From the First Three Years of Michelangelo

Five Lessons From the First Three Years of Michelangelo

  • November 14, 2018
Table of Contents

Five Lessons From the First Three Years of Michelangelo

Uber has been one of the most active contributors to open source machine learning technologies in the last few years. While companies like Google or Facebook have focused their contributions in new deep learning stacks like TensorFlow, Caffe2 or PyTorch, the Uber engineering team has really focused on tools and best practices for building machine learning at scale in the real world. Technologies such as Michelangelo, Horovod, PyML, Pyro are some of examples of Uber’s contributions to the machine learning ecosystem.

With only a small group of companies developing large scale machine learning solutions, the lessons and guidance from Uber becomes even more valuable for machine learning practitioners (I certainly learned a lot and have regularly written about Uber’s efforts). Recently, the Uber engineering team published an evaluation of the first three years of operations of the Michelangelo platform. If we remove all the Michelangelo specifics, Uber’s post contains a few non-obvious, valuable lessons for organizations starting in their machine learning journey.

I am going to try to summarize some of those key takeaways in a more generic way that can be applicable to any mainstream machine learning scenario.

Source: towardsdatascience.com

Tags :
Share :
comments powered by Disqus

Related Posts

EPO Issues First Guidelines on AI Patents

EPO Issues First Guidelines on AI Patents

The European Patent Office (EPO) has issued official guidelines on the patenting of artificial intelligence and machine learning technologies. The guidelines became valid on November 1st, 2018. When determining whether the claimed subject-matter satisfies this condition, the guidelines note that expressions such as “support vector machine,” “reasoning engine” or “neural network” may not qualify, as these are regarded as terms for mathematical methods which do not have a unique technical character of their own.

Read More
A Google Brain engineer’s guide to entering AI

A Google Brain engineer’s guide to entering AI

Note that this guide was written in November 2018 to complement an in-depth conversation on the 80,000 Hours Podcast with Catherine Olsson and Daniel Ziegler on how to transition from computer science and software engineering in general into ML engineering, with a focus on alignment and safety. If you like this guide, we’d strongly encourage you to check out the podcast episode where we discuss some of the instructions here, and other relevant advice. Technical AI safety is a multifaceted area of research, with many sub-questions in areas such as reward learning, robustness, and interpretability.

Read More