BlogCategoryTag

Header

Footer

PreFooter

BlogPage

Trusted by world class companies, Scale delivers high quality training data for AI applications such as self-driving cars, mapping, AR/VR, robotics, and more.

AI & ML Blog | Scale AI

PaginationButton

AnnouncementContextProvider

UnnamedGlobalGroupOfVariants2

Screen

Segment

Experiment

Experiment2

scale.com (Production)

plasmic-nav

plasmic-embed-css

plasmic-basic-components

plasmic-tabs

plasmic-cms

react-chartjs-2

react-slick

react-quill

Product

Company

General

People

Engineering

OpenAI recently published <a href="https://openai.com/blog/fine-tuning-gpt-2/" rel="noopener noreferrer" target="_blank">a paper on fine-tuning GPT-2</a>, where they used Scale AI to collect the preferences of human labelers to improve their language models. Although we were already labeling millions of text and computer vision tasks per day at the time, the unique latency requirements and subjective nature of OpenAI’s tasks posed a new challenge for us. In particular: how do you scalably maintain the quality of labels, without having labelers check each other’s work? Today we’re sharing a deep dive into our approach to the problem, the automatic benchmark mining system we built to solve it, and the things we learned along the way. In doing so, we hope to illustrate some of the many challenges that make scalable data labeling such an interesting area of work.<h2>The Problem</h2>First, let’s take a look at one of these tasks. Given a snippet of text and some possible continuations for it, the researchers at OpenAI wanted humans to pick the continuation that best fit a given prompt, such as “which continuation has the most positive sentiment” or “which continuation is the most descriptive”.<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2Fd227eaf7e823414c8446e5095ab2bbe2">But instead of labeling this data in a big batch like we usually do (offline), OpenAI wanted to put their model in a closed loop with our labelers, so the data was labeled online: the model would generate some text samples, have the humans rate it using our API, train based on human preferences, and then repeat this process over a few days.<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2F7eeb3638a0c745c3bc984d9f713e545b"><img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2Fd64dabc8b64848299a8faecdcd826910">This meant that in order for an experiment to have enough epochs of training, and still finish quickly, the tasks needed to be done with very low latency (&lt;30 mins) at high throughput (~5,000 labels/hr). As we will explain later, these constraints were unique and required us to build additional functionality into our data labeling pipeline.Furthermore, the answers to these tasks were also extremely subjective. As an example, here is a real task where one has to pick which continuation is the most descriptive:<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2F5becb9abfe314f64a61d36cc38c86699">Can you pick an answer with certainty?This ambiguity makes it hard to tell the people that are making a genuine effort apart from the people (or bots!) that are guessing randomly. However, we must make that determination correctly in order to scale this up to thousands of labelers, and still deliver high quality data to our customer.<h2>Measuring Quality at Scale</h2>When we first built our labeling pipeline, our customers wanted us to prioritize the highest quality data over other factors such as the fastest turnaround SLAs. Now we had to figure out a way to keep our high quality bar while boosting our turnaround from days to minutes.One reason for higher turn-around time was redundancy. On most projects, we send each task through a pipeline of multiple people, either in series or in parallel. Having this redundancy greatly reduces the probability of errors. It also allows us to estimate the accuracies of each person by grading their responses against the completed version of the task.The other reason for higher turn-around time was lagging quality indicators. We usually hold each batch of tasks in a staging state before it is sent back to a customer, so that our confidence indicators on labelers can catch up based on new information. We can then relabel tasks we have low confidence in.<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2F55389ccfedf84869aa27c1a33210a20f">However, due to OpenAI’s latency and throughput constraints, we would not have been able to use either of these features of our architecture — tasks would have to be immediately sent back to the customer after a single person had attempted them.Fortunately, having people review other people’s work is just one of the ways we get signal on labeler quality. For example, on some computer vision projects, one feature that determines labeler quality is based on localization loss from a deep learning model.<h2>Benchmark Tasks</h2>Another way we measure quality is using a mechanism called benchmark tasks. The idea is to collect high-confidence responses to a subset of tasks first (called benchmark tasks — or a golden dataset in <a href="https://www.aclweb.org/anthology/D08-1027.pdf" rel="noopener noreferrer" target="_blank">literature</a>), and then use them to estimate the quality of active labelers. The benchmark tasks are sprinkled among new tasks served to people, and disguised to be indistinguishable from them. We can then guarantee that we never return tasks to a customer from labelers who do not meet the quality threshold on benchmark tasks.We had been successfully using benchmark tasks as another way of measuring quality, but these were typically created manually by our in-house quality team. This manual creation would not have worked for this project for a few reasons:<ul><li>we wanted to support OpenAI in creating new projects and iterating quickly on experiments without being blocked on the Scale team creating benchmarks.</li><li>due to the ambiguous nature of tasks, it was harder to manually find tasks for which we could have high certainty in the answer.</li></ul>To solve these problems, we augmented our pipeline with a system that automatically mines and maintains a set of benchmark tasks.Once a project came in, our system would take a small subset of tasks from it, and have each one done by multiple trusted labelers. If those people almost all reached consensus that one of the responses on a task was correct, we would make this task a benchmark task, with that response. The broader remote workforce would only be allowed on the project once we had enough benchmarks.<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2F1a8013001a90431ca2b5186b48729688">For added safety, only people we had the most confidence in were selected for benchmark generation. This is in line with a general principle we use in designing our operational systems:* leverage people we have highest trust in*. Here, if the most accurate labelers are working on creating benchmarks, their work can then be used to validate the work of a much larger set of people.Since we only pick tasks that reach consensus, unambiguous tasks are more likely to become benchmarks than ambiguous ones with no clear answer. To an extent, this is helpful because we can be confident our evaluation of quality has low noise. The caveat is that this set of benchmark tasks is no longer representative of our original set of tasks.In this particular case, this was fine, since we were hoping to eliminate malicious and under-qualified labelers, while still allowing for expression of human preference and subjectivity. The need to understand this relationship between test question difficulty and false positives/negatives is one that recurs frequently for us, and has also been studied extensively in fields such as Item Response Theory.<h2>Making This Work</h2>With a complex system that includes free-willed actors (human labelers) with unpredictable behavior, every new feature needs multiple iterations — cycles of deploying changes, observing the system’s reaction to them, and then responding to new developments — in order to make it actually work. The benchmark generation system was no exception. Here we go over two of the many improvements that we made.<h3>Dynamic Serving</h3>As with any job, even the highest quality labelers can be inconsistent on their quality from one day to the next. Initially, we distributed benchmark tasks at a fixed uniform sample rate, which meant that it took a long time before our system could confidently adjust its quality read for a given labeler. We evolved our logic for serving benchmark tasks to instead vary its rate dynamically, and serve more benchmarks as soon as a dip in quality was suspected.<h3>Preventing Heuristics And Bias</h3>Things ran smoothly until we got to the descriptiveness project, in which labelers had to pick the most descriptive continuation among 4 options. Our quality audit showed a dip, confirmed by the fact that the average time people were spending on these tasks had also started to fall.What was special about this project?It turns out that the correct answer (the most descriptive option) had an extremely high likelihood of also being the longest option. This was true often enough that a strategy of “pick the longest option” would be within our tolerance of quality, and prove far more lucrative than acting honestly.This demonstrates the need to care about the distribution of benchmark tasks. By explicitly including and weighting anti-bias examples (in this case, examples where the longest option is not correct) in our benchmark set, we could correct for this issue.<h2>A Note on Testing and Monitoring</h2>Every distributed system needs to be tested and robustly monitored, and a human-based distributed system like ours is no different.How do we test changes if our system depends on unpredictable human behavior? At Scale, we usually test things like that by launching “synthetic projects” — a sandboxed copy of a real project we’ve already done before, with a similar population of labelers as the real project. This allows us to experiment and iterate quickly without fear of disrupting the actual labeling pipeline for a customer. We leveraged synthetic projects to tune our parameters, test hypotheses and also at one point to keep our workforce “warmed up” by giving them tasks to do as we waited for the customer to send in more tasks.In addition to this, we need to monitor the system and output quality to ensure that there are no regressions. This is how we quickly caught and responded to some of the issues described above. We set up <a href="https://scale.com/blog/alert-from-reports" rel="noopener noreferrer" target="_blank">alerts</a> for when inter-labeler agreement rate, throughput or average time per task fell outside the expected range of values.In addition to automated alerts, we need constant qualitative monitoring on all of our projects, which is done by our in-house quality team. This project was no different. To check this system, we set up a process to audit labelers close to our filtering boundary based on benchmarks. This allowed them to alert us if the system was erroneously filtering out labelers who were good (false positives) or not filtering out labelers below quality (false negatives).Finally, since we had access to a small sample of data labeled by the researchers at OpenAI themselves, we set up a daily cron on our async job service that would have the same sample re-labeled by workers, and alert if the quality on this was lower than desired.<h2>What's Next</h2>Since building the prototype of this system and learning from it, we have incorporated it into all natural language and categorization use cases as well as parts of our computer vision pipeline. We have also improved the accuracy of our classifier that determines whether labelers are good quality using a Bayesian model. We will publish blog posts describing those efforts soon.This post emphasizes how we're solving quality measurement, but there's a whole world of other problems we're tackling that are also vital to the data labeling process, such as: using ML to make data labeling orders of magnitude faster, scalably teaching complex instructions, building state of the art 3D point cloud rendering tools, and setting up the data infrastructure to support all these systems. If you’re interested in joining us in solving these problems, and powering the next generation of ML applications, take a look at our <a href="https://scale.com/careers" rel="noopener noreferrer" target="_blank">careers page</a> for the latest open positions. If you have projects that require high quality data labeling, <a href="https://scale.com/sales" rel="noopener noreferrer" target="_blank">let our team know</a>!Find out more about OpenAI <a href="https://openai.com/about/" rel="noopener noreferrer" target="_blank">here</a>.

assets-e0438815ba51486bbb6a202747122d4b-4ba57966ec8e4f30a76576f000b8f572.jpeg

Labeling 1M Data Points/Week for OpenAI's GPT-2

How to Label 1M Data Points/Week

Building on the news of our <a href="https://scale.com/blog/series-c" rel="noopener noreferrer" target="_blank">Series C</a> round of funding valuing Scale AI over $1B, and our selection as one of <a href="https://scale.com/blog/linkedin-top-startup-2019" rel="noopener noreferrer" target="_blank">LinkedIn’s Top Startups in the US</a>, we are pleased to be selected as one of <a href="https://www.forbes.com/sites/jilliandonfro/2019/09/17/ai-50-americas-most-promising-artificial-intelligence-companies/#53699d8a565c" rel="noopener noreferrer" target="_blank">Forbes AI 50: America’s Most Promising Artificial Intelligence Companies</a>. Three years ago, we started Scale to tackle the most critical bottleneck in modern AI development: generating robust training data. It was a problem born out of our own frustrations building AI models—the majority of our time was spent on producing high quality data rather than building the model itself. This first-hand experience inspired us to solve the data problem for everybody. All companies recognized on the Forbes list leverage artificial intelligence as a core part of their business model and future success. A panel of experts selected the list based on the technology, business model, customers and financials. We are big believers in the transformational impact of AI over the coming decades, and we are proud of our work in enabling our customers to build incredible AI products more quickly. There has never been a better time to join Scale. If you’re interested in working with us, take a look at all of our <a href="https://scale.com/careers?location=All&amp;team=All#jobs" rel="noopener noreferrer" target="_blank">open positions</a>!

Scale AI selected as one of Forbes' Most Promising Artificial Intelligence Companies

Scale AI Selected as One of America's Most Promising AI Companies

Scale AI is pleased to be selected as one of <a href="http://lnkd.in/USTopStartups2019" rel="noopener noreferrer" target="_blank">LinkedIn’s 2019 Top Startups</a> in the U.S. Our mission is to accelerate the development of AI applications. Labeled data is the key bottleneck to the growth of the machine learning industry, and by building the infrastructure for machine learning, we are enabling a new age of software. There are three broad reasons why someone should join Scale AI: <ul><li> </li><li>Our Work:</li><li> </li><li> </li><li>Machine learning (ML) is likely the most significant technological shift happening today. Powered by a dynamic research community, computers can now recognize images and audio, translate languages, generate realistic text, and even beat humans at games. But aside from a few innovative products from large tech companies, ML has not yet made a tremendous impact. </li><li> </li><li> </li><li>Labeled data is the key bottleneck to the growth of the machine learning industry. Scale AI not only provides high quality labeled data for a wide range of AI applications, but our team is working to build the infrastructure needed to realize ML’s potential impact. </li><li> </li><li>Timing:</li><li> </li><li> </li><li>In the last year, Scale AI has grown from 20 employees to just north of 100. We have experienced phenomenal revenue growth and have also tripled the number of enterprise customers year on year. Customers also quickly realize the quality, scalability and value of leveraging Scale AI, and increase their usage on the platform rapidly. Scale AI is positioned to continue growing at an incredibly fast pace. </li><li> </li><li> </li><li>Now is a great time to join Scale AI, because as we continue to expand into new use cases and new verticals, employees (we like to call ourselves Scaliens) have the ability to make an incredible impact with their work. By joining now, you have the ability to move and execute on projects quickly, have the steep upside of joining early, but with significantly less risk. </li><li> </li><li>Culture:</li><li> </li><li> </li><li>Scale AI succeeds or fails as a team, and we make an effort to constantly trust and invest in each other to build a robust, scalable company. Scaliens include people who helped scale Cruise, Dropbox, Facebook, Lyft and Uber as well as new graduates just starting their careers. We believe that having diverse perspectives is crucial to build products to accelerate the development of AI, and we strive to create an environment where employees can give their all at work, while still being able to give their all at home. </li><li> </li></ul>There has never been a better time to join Scale. If you’re interested in working with us, take a look at all of our <a href="https://scale.com/careers?location=All&amp;team=All#jobs" rel="noopener noreferrer" target="_blank">open positions</a>!

Scale AI selected as one of LinkedIn’s 2019 Top Startups in the U.S..

Scale AI Selected as One of LinkedIn’s 2019 Top Startups in the U.S.

We at Scale AI felt inspired to use our computer vision training tools to put the two self driving methods to the test. 

Is Elon Musk wrong about LiDAR? We put the two self driving methods to the test.

Is Elon Wrong About LiDAR?

Our mission at Scale is to accelerate the development of AI applications. We’re proud of what we’ve built over the last three years, and today we’re announcing our Series C funding round to support our continued work against that mission. Scale has raised $100m at a valuation of over $1B. <a href="https://foundersfund.com/" rel="noopener noreferrer" target="_blank">Founders Fund</a> led the round, supported by <a href="https://accel.com/" rel="noopener noreferrer" target="_blank">Accel</a>, <a href="https://www.coatue.com/" rel="noopener noreferrer" target="_blank">Coatue Management</a>, <a href="https://www.indexventures.com/" rel="noopener noreferrer" target="_blank">Index Ventures</a>, <a href="http://www.sparkcapital.com/" rel="noopener noreferrer" target="_blank">Spark Capital</a>, <a href="https://www.thrivecap.com/" rel="noopener noreferrer" target="_blank">Thrive Capital</a>, <a href="https://en.wikipedia.org/wiki/Kevin_Systrom" rel="noopener noreferrer" target="_blank">Kevin Systrom</a>, <a href="https://en.wikipedia.org/wiki/Mike_Krieger" rel="noopener noreferrer" target="_blank">Mike Krieger</a> and <a href="https://en.wikipedia.org/wiki/Adam_D%27Angelo" rel="noopener noreferrer" target="_blank">Adam d’Angelo</a>. We are big believers in the transformational impact of AI over the coming decades. Machine learning is likely the most important technological shift of our time, and the overall benefits to the world will be comparable to those of the internet. What we noticed after working on AI at some of the most advanced organizations in the world was that building machine learning systems was challenging due to a lack of mature infrastructure. In particular, we noticed that the critical bottleneck to further progress today was data—in particular, labeled datasets. Many engineers will tell you that getting labeled data is the hardest part of building a machine learning model. Building AI represents a fundamentally different paradigm than building traditional software. The performance of an AI system depends more on the data than the algorithm—in most cases, without labeled data, there is no model. Similarly, for a model to improve and adapt, it requires more data rather than simply more code. This paradigm has been true since the very beginning of deep learning; the modern deep learning age was ignited by the launch of the ImageNet dataset by Fei-Fei Li’s lab at Stanford in 2009.<img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2F8c80d06e32aa42c689836dbda1f7fd09" alt="AI DEV CYCLE"><img src="https://cdn.builder.io/api/v1/image/assets%2Fe0438815ba51486bbb6a202747122d4b%2Fb0518c76600f4b9fa58189d4bfe750ba" alt="TRADITIONAL DEV CICLE"> We set out to solve this problem by building a platform that enables organizations with large high-quality datasets needed to build AI systems. Especially now, as AI is being applied in more and more ways, this matters because:<ul><li> </li><li> Safe, accurate and unbiased AI systems depend on large volumes of high</li><li> quality training data.</li><li> </li><li> </li><li> The process to acquire, label, and verify training data is slow, manual and</li><li> expensive.</li><li> </li><li> </li><li> Today’s training data bottleneck limits AI's impact to a small group of</li><li> well-funded technology companies.</li><li> </li><li> </li></ul> Scale is a solution to these problems. Developers use our API to send their raw data to our platform. We then use a combination of machine learning and human insight to label and annotate this data. We pass this high-quality ground truth data back to our customers, who are then enabled to build world-class models to solve real-world problems. Scale is now used by world leading machine learning teams at companies like OpenAI, Airbnb, Nuro, and Lyft. Our platform is being used to provide high-quality training data to an ever growing number of machine learning teams and industries, including:<ul><li>Autonomous Vehicles: Advancements in AI for perception,</li><li> prediction, and planning have enabled the development of autonomy, which in</li><li> turn relies on data.</li><li> </li><li>Natural Language and Content Understanding: More than ever</li><li> before, systems can understand and drive decision-making on large corpuses</li><li> of speech, text, images, and other forms of content.</li><li> </li><li>E-commerce and Search: Powerful search systems that connect</li><li> consumers to specific content, images, or products increasingly rely on AI</li><li> systems to drive understanding of this content. Our platform helps engineers</li><li> train those systems.</li><li> </li><li>Mapping: Mapping using satellite, drone, and street-level</li><li> imagery for use cases from agriculture to insurance rely on high quality</li><li> training data to ensure accuracy.</li><li> </li><li>Robotics: Robots in factory or warehouse settings need to</li><li> be able to understand their environments, safely interact with humans and</li><li> recognize products or components.</li><li> </li><li>Augmented Reality and Virtual Reality: AR and VR systems</li><li> used in gaming, real estate or manufacturing rely on being able to perceive</li><li> the 3D environment around a camera, headset or user.</li><li> </li><li>Offline retail: Cashierless checkouts, inventory management</li><li> systems and footfall analysis all depend on perception systems, which in</li><li> turn depend on training data.</li><li> </li><li> </li></ul> We’re proud of the progress we’ve made building the Scale platform for our customers. It’s been an incredibly quick 3 years since I started the company, and the ability we’ve had to accelerate progress in machine learning is palpable. But, as we hope is always the case, we’re far more excited about what we will do in the future. There is a lack of mature infrastructure for building AI, forcing teams to build their own technology stack from scratch before they can have a meaningful impact. Per our mission, we know there are many problems beyond the training data bottleneck for us to solve to continue accelerating AI development. Despite our excitement for the potential of AI, we’re closer to the beginning of its history than we are to the end. We’re grateful to our customers for building world-leading AI products with Scale, and we’re looking forward to accelerating the development of machine learning in an even broader set of industries and technologies as we grow. If you are interested in being part of creating the infrastructure machine learning needs, take a look at our <a href="https://scale.com/careers?location=All&amp;team=All" rel="noopener noreferrer" target="_blank">open positions</a>. If you're interested in partnering with us, please <a href="https://scale.com/sales" rel="noopener noreferrer" target="_blank">reach out</a>.

Scale AI’s Series C: Building the data platform for ML

Scale AI’s Series C: Building the data platform to accelerate machine learning

Scale AI is pleased to announce the launch of Sensor Fusion Segmentation - Scale’s endpoint for point cloud segmentation.<iframe class="ql-video" frameborder="0" allowfullscreen="true" src="https://lidar-now.scale.com/examples/semseg" height="100%" width="100%"></iframe> Sensor Fusion Viewer rendering a scene from nuScenes Released at CVPR 2019, Sensor Fusion Segmentation provides the highest precision for annotating complex objects that cannot be easily described with LiDAR cuboid labeling. Examples include vegetation, smoke/exhaust, splashes/puddles, rain and reflections.<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/34fe7aaa-a1a6-4737-823a-ffe19dbe8b00/public" alt="fog seen through LiDAR">Fog<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/bbbb9168-544a-4866-b096-9bb07cf87c00/public" alt="fog seen through LiDAR">Smoke/Exhaust<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/6cd0ad4c-0d0a-48c6-65f3-e18ac64a1700/public" alt="vegetation seen through LiDAR">Vegetation<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/ae620a78-79bd-4c4c-2ade-0e7de9ddf500/public" alt="Trucks with open backs seen through LiDAR">Trucks with open backs<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/9cb13a70-42a2-4559-1c44-a5b34bebbc00/public" alt="reflections seen through LiDAR">Reflections<img src="https://imagedelivery.net/wLbZE4_NzVVdgHc15St55g/dff8770c-e1cc-4e77-8d73-d35007f3f200/public" alt="Splashes &amp; Puddles seen through LiDAR">Splashes &amp; Puddles Semantic scene understanding is important for a variety of applications, particularly autonomous driving. Rigorously tested by a handful of Scale’s customers during a private beta, Sensor Fusion Segmentation annotation provides fine-grained understanding of surfaces and objects in a 3D point cloud. Take a look below, for how we helped the Toyota Research Institute (TRI) accelerate their research projects by giving them greater flexibility and the ability to amend workflows.<iframe class="ql-video" frameborder="0" allowfullscreen="true" src="https://www.youtube.com/embed/2XURB1nE11w"></iframe> Since starting its work with Scale, TRI has been able to support four large annotation pipelines without significantly increasing the size of their team.<a href="https://scale.ai/sensor-fusion-segmentation" rel="noopener noreferrer" target="_blank">Learn More</a>

Introducing Point Cloud Segmentation

We believe that creating jobs can be very impactful. We asked some labelers for times when working for Scale made a positive difference in their lives.

Positive Externalities

Positive Externalities: Life of a Labeler

Deep Learning models have amazing capacity, <a href="https://ai.googleblog.com/2017/07/revisiting-unreasonable-effectiveness.html" rel="noopener noreferrer" target="_blank">getting better with more data</a> seemingly without limit. To get a well-functioning model, it is not enough to have large amounts of data, you also need accurate annotations. Although large amounts of data will help the model resolve data inconsistencies between different annotations, humans can still make repeated mistakes that become ingrained in the model. For example, when asked to draw a box around an object, it is natural for humans to always ensure that the box contains the object - i.e., to err on the side of making the box too big. Using such a model for collision avoidance will result in false positives, causing the autonomous vehicle to halt unnecessarily. The oversizing of bounding boxes is an example of a systematic error, as opposed to a random error. Random and systematic errors impact the trained model differently. <h2>Random vs Systematic Errors</h2> Random errors cause the model to require more data to converge to the same result. A model trained with data with random errors will ultimately arrive at the same parameters, just more slowly and after having been fed more data. Systematic errors cause the model to converge to a different result - this does not get better with data quantity. A model trained with oversized boxes will output oversized boxes regardless of how much data it is trained with. <h2>Mitigation Strategies</h2> One simple, if expensive, way to deal with random errors is to use more training data. There are also other more sophisticated and cost-efficient approaches - for example, if your training data has multiple sources, and if each source has a different amount of random errors, you can mitigate the effects of the errors by weighing the low-error sources more heavily while training. Systematic errors, on the other hand, can only be resolved by fixing the data, or understanding the nature of error well enough to turn it into a random error. Many interesting techniques exist in this area, including <a href="https://arxiv.org/abs/1802.05300" rel="noopener noreferrer" target="_blank">Golden Label Correction</a>, where you carefully annotate a subset of the data in order to characterize the non-randomness of the rest of the data. At the end of the day, the key to overcoming annotation errors effectively and efficiently is understanding how the errors are generated. Let’s take the previous example of oversized bounding boxes. Taking into account the tendency of inexperienced workers to oversize boxes, Scale is able to use simple models to check for oversizing. Over time, with feedback from those models, workers learn to make fewer systematic mistakes, consistently drawing tight bounding boxes. By matching complex annotation specifications with annotator training and an understanding of the systematic errors, Scale is able to efficiently produce quality annotations in quantity, facilitating cost-effective training of accurate models.

Training Data - Quantity vs Quality of Annotated Data - Scale

Training Data - Quantity is no Panacea

We’ve had an incredible group of people join Scale—and we’re still <a href="https://scale.com/about#jobs" rel="noopener noreferrer" target="_blank">hiring</a>! We wanted to take a moment to follow up on <a href="https://scale.com/blog/scale-engineering-team" rel="noopener noreferrer" target="_blank">this post</a> and call out the latest team members that have joined the Engineering, Product and Design teams at Scale: <ul><li> </li><li>Catherine Wu / Catherine is a full-stack engineer at Scale working primarily on our infrastructure team. She has previously worked as an engineer at Google and product manager at Yelp. She studied computer science at Princeton University, where she also competed on the synchronized skating team.</li><li> </li><li> </li><li>Eugene Fratkin / Prior to Scale, Eugene led R&amp;D for the Cloud division at Cloudera, responsible for the development of managed distributed data processing services in AWS/Azure. Prior to Cloudera, Eugene was a co-founder and VP of R&amp;D at Lifecode – a Sequoia Capital-backed genomic cancer diagnostic start-up. Prior to Lifecode, he was one of the founding members of Greenplum’s machine learning team, which started the MADlib Apache project. Eugene holds a PhD in Machine Learning from Stanford. Eugene also served as an assault team section leader in the United States Marine Corps for missions such as the anti-terrorism quick reaction force within the continental US, and the initial phase of Operation Iraqi Freedom.</li><li> </li><li> </li><li>Gabriel Andretta / Gabriel previously worked at <a href="https://auth0.com/" rel="noopener noreferrer" target="_blank">Auth0</a> with Ricky, Martín and Ramiro, where he rebuilt <a href="https://github.com/auth0/lock" rel="noopener noreferrer" target="_blank">Lock</a> from scratch and was the lead developer of the browser SDKs. He was a contributor to the sinatra web framework, a coach in the first edition of <a href="https://twitter.com/ClojureBridgeBA" rel="noopener noreferrer" target="_blank">Clojure Bridge Buenos Aires edition</a>, and built a <a href="https://github.com/gnandretta/literate-2048" rel="noopener noreferrer" target="_blank">2048</a> clone with almost no mutable state.</li><li> </li><li> </li><li>Steven Salka / <a href="http://ssalka.io/" rel="noopener noreferrer" target="_blank">Steven</a> joined the engineering team at Scale as a product-focused full-stack engineer, working largely on internal applications and the frontend for Scale’s LiDAR tool. Previously, he was the first engineering hire at <a href="https://podible.co/" rel="noopener noreferrer" target="_blank">Podible</a>, and before that built out a UI framework for text-based annotations at <a href="https://x.ai/" rel="noopener noreferrer" target="_blank">x.ai</a>. Steven studied Applied Mathematics at UC Berkeley.</li><li> </li><li> </li><li>Ramiro Silveyra d'Avila / Prior to Scale, Ramiro was a software engineer at <a href="https://auth0.com/" rel="noopener noreferrer" target="_blank">Auth0</a> working on the marketing and engineering teams. He loves open source software, especially web tooling. He has contributed to yarn, babel, stylelint, eslint plugins and webpack loaders.</li><li> </li><li> </li><li>Michael Woo / Michael is a supply product manager at Scale. After graduating from Harvard in Computer Science, he joined McKinsey &amp; Company as a business analyst. Michael is a former captain of the Harvard Fencing Team and National Junior Team Member for the US National Fencing Team.</li><li> </li><li> </li><li>Sara Xiang / Sara is a supply product manager at Scale. She previously worked at Twitter on the Moments team, and at Facebook on the Oculus Developer Technologies and Oculus TV teams. She studied computer science at Carnegie Mellon University.</li><li> </li><li> </li><li>Pato Perez / Pato is a full-stack engineer at Scale working primarily on our LiDAR annotation tool. He previously worked as an Android and iOS engineer at other startups. He was the winner of multiple software engineering competitions, including Microsoft Imagine Cup @ Australia.</li><li> </li><li> </li><li>Shivaal Roy / Shivaal graduated from Stanford with a B.S. and M.S. in computer science. He founded Stanford's health hackathon, <a href="http://healthplusplus.stanford.edu/" rel="noopener noreferrer" target="_blank">Health++</a>, and was president of <a href="http://shift.stanford.edu/" rel="noopener noreferrer" target="_blank">SHIFT</a>, Stanford’s health-tech student organization. Prior to Scale, he worked at Google on the Photos Machine Intelligence team, and at Oscar Health.</li><li> </li><li> </li><li>Mauro Giamberardino / Mauro is a senior full-stack engineer who previously worked for companies like Globant and Spark Digital. He studied Systems Engineering at Buenos Aires University.</li><li> </li><li> </li><li>Martin Cabral / Martin joins Scale as a software engineer with ten years of experience in different positions and companies. His last adventure was as a product manager at <a href="https://www.auth0.com/" rel="noopener noreferrer" target="_blank">Auth0</a> where he learned to work very closely with customers and understand how they approach products. When he is not working, you can find him gaming (Dota2, CS, Fortnite et al.) or playing real life tennis.</li><li> </li><li> </li><li>Nathan Hayflick / Nathan is a frontend engineer at Scale. He joins from Uber, where he worked for 3 years on the Safety Engineering and Develeper Platform teams, and worked at Rockbot before that. He studied Literature at Stanford University.</li><li> </li><li> </li><li>Jeff Hilnbrand / Jeff is the Design Manager at Scale. He was most recently a Senior Product Designer at Facebook on the Groups and Payments teams. Prior to that, Jeff founded a design agency called Minimill and worked on design teams at Autodesk and Venmo. Jeff studied product design and engineering at the University of Maryland.</li><li> </li><li> </li><li>Andrew Wang / Andrew was a tech lead at Cloudera working on HDFS and cloud-based machine learning platforms for 6 years. He’s one of the biggest contributors to the open-source Apache Hadoop project, served as the release manager for Apache Hadoop 3.0, and is an Apache member. Before that, he was a PhD student in distributed systems at UC Berkeley and studied computer science at the University of Virginia.</li><li> </li><li> </li><li>Craig Weiss / Craig joins Scale with experience from Lyft, Snapchat, Facebook, and Google. Craig frequently competed in and won several awards at regional hackathons and competitive programming competitions (including the ACM-ICPC). Craig studied computer science at the University of Maryland.</li><li> </li><li> </li><li>Aatish Nayak / Aatish is a supply product manager at Scale, with previous experience at Shield AI, Uber, MongoDB, and Skurt. At ShieldAI he worked on life-saving autonomous robots for special operations and law enforcement use cases. Aatish studied computer engineering at Carnegie Mellon University and led Autolab, a startup for auto-grading CS homework assignments.</li><li> </li><li> </li><li>Ty Wilkins / Ty has worked closely with Scale from the beginning to establish Scale’s branding, icon system, and illustration style. Previously, Ty was an early employee at <a href="https://dribbble.com/shots/2994377-Robinhood-Gold" rel="noopener noreferrer" target="_blank">Robinhood</a> where he created product UI, branding, illustration, and marketing. He has extensive experience in branding, working with clients including Google, <a href="https://dribbble.com/shots/2347496-Facebook" rel="noopener noreferrer" target="_blank">Facebook</a>, and <a href="https://dribbble.com/shots/195804-Target-Education" rel="noopener noreferrer" target="_blank">Target</a>. Ty has also branded numerous startups including <a href="https://auth0.com/" rel="noopener noreferrer" target="_blank">Auth0</a>, <a href="https://www.useloom.com/" rel="noopener noreferrer" target="_blank">Loom</a>, and <a href="https://dribbble.com/shots/314295-Orchestra" rel="noopener noreferrer" target="_blank">Orchestra</a> in addition to many open source projects including <a href="https://dribbble.com/shots/4738771-Celery" rel="noopener noreferrer" target="_blank">Celery</a> and <a href="https://dribbble.com/shots/2153014-JWT" rel="noopener noreferrer" target="_blank">JWT</a>. His editorial illustration work has been featured in publications including <a href="https://dribbble.com/shots/192949-Monocle" rel="noopener noreferrer" target="_blank">Monocle</a>, <a href="https://dribbble.com/shots/1215603-Bloomberg-Markets" rel="noopener noreferrer" target="_blank">Bloomberg Markets</a>, <a href="https://dribbble.com/shots/2083018-ESPN" rel="noopener noreferrer" target="_blank">ESPN Magazine</a>, and <a href="https://dribbble.com/shots/766236-Wired-UK" rel="noopener noreferrer" target="_blank">Wired UK</a>. Ty holds a B.F.A. in Graphic Design from Auburn University.</li><li> </li><li> </li><li>Facundo Pepe / Facundo is a UI Developer in charge of the marketing landing pages at Scale. He previously worked at Infobae, the most popular news media in Argentina and at <a href="https://aerolab.co/" rel="noopener noreferrer" target="_blank">Aerolab</a>, a digital agency where he and his team won a <a href="https://www.a24.com/actualidad/a24com-gano-un-martin-fierro-digital-por-la-aplicacion-juga-24-12112018_H1xcRshkN" rel="noopener noreferrer" target="_blank">Martín Fierro Digital award for Best New Application</a> with a betting game for the World Cup. Better known as Turbo because he makes things fast, Facundo loves to deliver pixel perfect projects while working on user interactions that look cool and also perform well.</li><li> </li></ul>

Scale's Engineering, Product and Design Teams - Meet Our Team

Scale Engineering, Product and Design Teams

Scale AI is pleased to announce the full release of <a href="https://www.nuscenes.org/" rel="noopener noreferrer" target="_blank">nuScenes by Aptiv</a> —a large-scale open source dataset for autonomous driving. Scale AI was involved as Aptiv's data labeling partner on this initiative. On March 28, 2019, Aptiv announced the full dataset release of nuScenes, an initiative intended to broadly support research into computer vision and autonomous driving by AV innovators and academic researchers to further advance the mobility industry. One key bottleneck in the advancement of deep learning is access to labeled data. Most machine learning algorithms learn from large amounts of examples to understand the world. These incredible algorithms are powered behind the scenes by billions of hand-labeled examples of what humans can easily understand. While we like to believe as computer scientists that it is all about the algorithms, labeled data is incredibly impactful to progress. The current age of deep learning was ignited by the launch of the ImageNet dataset by Fei-Fei Li's lab at Stanford in 2009. As Fei-Fei said once in an interview: <blockquote>Our vision was that Big Data would change the way machine learning works. Data drives learning.</blockquote><blockquote> </blockquote>The release of the full 1000 scenes means nuScenes now includes 1.4M camera images, 390k LiDAR sweeps, 1.4M RADAR sweeps and 1.4M object bounding boxes in 40k keyframes. nuScenes is the largest multi-sensor dataset for autonomous vehicle data with LIDAR, RADAR, camera, IMU, and GPS, and builds upon great work in the field by others such as the KITTI dataset. Collected in Boston and Singapore, nuScenes data contains 7x more object annotations than KITTI and will enable researchers, students and developers to study challenging urban driving situations. <iframe class="ql-video" frameborder="0" allowfullscreen="true" src="https://lidar-now.scale.com/examples/demo" height="100%" width="100%"></iframe> Sensor Fusion Viewer From conception, we partnered with Aptiv to produce the nuScenes dataset. By leveraging Aptiv's autonomy stack and <a href="https://scale.com/sensor-fusion-annotation" rel="noopener noreferrer" target="_blank">our sensor fusion and LIDAR annotation products</a>, nuScenes sets a new standard for quality in public datasets, along with a web-based visualizer for LIDAR and camera data for <a href="https://www.nuscenes.org/explore/scene-0120/0" rel="noopener noreferrer" target="_blank">exploring the dataset</a>. It is crucial to machine learning development to be able to visualize data to develop intuitions about the problems at hand. We, <a href="https://eng.uber.com/avs-autonomous-vehicle-visualization/" rel="noopener noreferrer" target="_blank">like</a> <a href="https://medium.com/cruise/introducing-worldview-749aaf98112d" rel="noopener noreferrer" target="_blank">others</a>, noticed a gap where previous options like <a href="http://wiki.ros.org/rviz" rel="noopener noreferrer" target="_blank">rviz</a> were not built for a web-based world. Our LiDAR visualizer allows point cloud data to be easily embedded into any webpage and shared. We've also built it to be developer-friendly and usable for a broad range of use cases. We hope that the nuScenes dataset will become the new standard in the industry and allow researchers to develop safer autonomous driving technology. There is a large gap today in the machine learning community—the larger organizations have significantly larger datasets and compute budgets than smaller organizations or universities. Our hope is to bridge that gap and democratize access to state-of-the-art data in autonomous vehicles. With the launch of nuScenes, we hope to do for the autonomous vehicle community what ImageNet did for computer vision.

nuScenes by Aptiv ImageNet for Autonomous Vehicles

open-dataset-nucleus

slugs must be all lowercase. ie: ‘my-slug’

events-banner

This entry represents both interview quote highlight and interview chat highlight because of Builder limitations. Choose the fields that matches either of them.

interview-highlight

If it's selected, the author and quote fields will be taken, otherwise the chat fields. The default is for chat.

resources-download-model

transform-session

CTA to open the session. Leave blank if you don't want a cta for that session

Link for the CTA. Usually the link to the exchange session

blog-filter-type

event-transform-x-ticket

solution

homepage-quotes

logos

homepage-content

builder-debug

transfrom-x-in-person

event-model

Toggle if the event is featured. Featured events will be moved to the top of the list

guides-cta

summit-2023-partners

sales

z[deprecated] page

quotes

z[deprecated] compare

product

blog-category-model

announcement-banner

accelerate

Vercel Powered and Edge Computed OG Image. Preferred over og img file upload. If this field is non empty, it will take precedent over the uploaded file

summit-2023-speakers

homepage-resources

customers

Display order on the page /customers. Higher values show first

page-cross-product-webinar

interview

event-transform

Event model for new marketing events page

event-2-0

homepage-event

custom-fonts

transform-x-speaker

Be careful to not add any trailing white spaces to the slug. Slugs must be all lowercase. ie: ‘my-slug’

Order of the featured speakers displayed on the home page for transformX

z[deprecated] document-ai

summit-2023-agenda

event-converge

hosts

author

transform-x

Page: /In-Person. Section: Hero. Text: Title Text

Page: /In-Person. Section: Slider Card. Text: Title Text

Page: /In-Person. Section: Slider Card. Text: Card Body

Page: /In-Person. Section: Hero. Text: Tagline

open-dataset

z[deprecated] customers

URL redirections for Website. Disclaimer: takes 5~ min for each added or edited.

url-redirects

Use relative path. use `/blog/foo` not `https://scale.com/blog/foo`

legal

event

Optional second image intended to show on the grid view, should be a more squared image closer to 1:1 aspect ratio than the one used in the Cover field.

guides

z[deprecated] guides-old

z[deprecated] guides-lp

partners

blog-model

Option to list or not list this post in the Blog index. Enabled = not list in the index, Disabled = list in the index

Products

Government

Solutions

Resources

Customers

Pricing →

Blog

The future of your industry starts here.