Sasha Harrison

<h2 id="section-1%3A-what-is-nucleus%3F">Section 1: What is Nucleus?</h2>
Imagine you’re a machine learning engineer responsible for building a pedestrian detection algorithm. It’s easy to get started, perhaps by training a standard model on a small dataset. You get some preliminary results, and now you want to improve on the baseline. But what do you do next?
In academia, common approaches are new algorithms, different architectures, or larger hyperparameter searches. But academics fight with one hand tied behind their backs: they usually cannot edit their datasets. In practical applications, on the other hand, datasets are malleable and can be extended to suit a problem’s needs. In practice, the most effective way to improve an ML model is often to improve the dataset.

Andrej Karpathy’s slide deck

Andrej_karpathy_graphic

At Scale, we specialize in creating high-quality, large-scale training datasets for our customers. Expanding beyond our core strength of data labeling, we developed Nucleus because we think it should be easier to visualize, search, and improve computer vision datasets, and because we saw many ML engineers struggling to answer two core questions:

1. I know my ML model isn’t perfect. But where specifically does it fail today, and why?
2. How can I improve my dataset to fix these failures?

With Nucleus, ML teams can use their models to discover issues in their datasets, surface the part of the data distribution where models struggle most, compare model runs, and prioritize what new unlabeled data to label next.


In the rest of this post, we’ll walk through a step by step tutorial on how to get started with Nucleus.  We’ll show you how to upload an image dataset with ground truth annotations, as well as how to integrate the Nucleus python client into a PyTorch training workflow to analyze model results. 

## Section 2: Getting Started with the Nucleus Python Client

The complete code for this tutorial is available in [this colab notebook](https://colab.research.google.com/drive/1Cu2Xw0kPwbMMSdqUsSgmMMTzQ5b7usDZ#scrollTo=m-UTKVIts6Ru).  If you’d like to follow along step by step and create a personal dataset on Nucleus, you will first need to make a [free scale account](http://scale.com/) and obtain a test API key.  You can then copy the notebook and add your personal key to upload data for free. 

To continue with the example of pedestrian detection, we’ll use the PennFudan pedestrian detection dataset to finetune a pre-trained Faster R-CNN model for a pedestrian detection task. PennFudan consists of 170 images labeled with both bounding boxes and segmentation masks.  Some code has been omitted for brevity, see [this colab notebook](https://colab.research.google.com/drive/1Cu2Xw0kPwbMMSdqUsSgmMMTzQ5b7usDZ) for the complete implementation. Let’s get started by instantiating the nucleus client and downloading the dataset.

### Download the Dataset and Upload to Nucleus

To get started with Nucleus, we will first upload the PennFudan dataset to the Nucleus Dashboard. Uploading data is easy using the Nucleus python client — either specify the local file path or image url if your data is stored in the cloud.  In this case, we’ve downloaded the PennFudan dataset locally, so for each dataset item we specify the file path of the image.  We’ll use the file name as a reference_id that can be used to refer to the images in later API requests.

Once the images are uploaded, the next step is to upload the ground truth bounding box annotations.

With the images and annotations uploaded, we can visualize the PennFudan Dataset in the Nucleus Dashboard.

gif_id_1_dataset_explorer_insights2

From the insights tab, we can get a quick overview of the labeled dataset.  In particular, you’ll notice that the annotations consist of exactly one class (pedestrian), and that the dataset overall is biased toward images with fewer annotations. The visualization, querying, and insights features in Nucleus make it easy to dig into interesting subsets of the training dataset.

Next, we’ll set up the Pytorch DataLoaders needed for training and evaluation.

### Setting up transforms and DataLoaders

 ### Use Slices to keep track of test and train sets within Nucleus

When evaluating model predictions, we’ll want to differentiate between train and test examples within the Nucleus platform.  We can do so using slices. A slice is just a collection of dataset items. Below, we create slices for the train and test sets.

Once a slice is created via the Python client, it will appear in the Nucleus interface.  The slicing feature is useful for examining a particular subset of the dataset.  When viewing a slice, the search bar queries are applied only to the items within the current slice.

gif_id_2_select_test_slice

### Define the model & training loop

We are now ready to start using Nucleus to analyze experiments, the next step is to upload model predictions. In the code block below, we finetune the Faster R-CNN for 7 epochs before evaluating it on the test set consisting of 50 held-out examples. 

In the code segment below, we’ve factored the details of the training loop into some helper functions imported from vision/references/detection/.  Here’s the simplified training loop:

The evaluation output shows that overall, the finetuned model achieves an average precision of 0.827 and average recall of 0.386.  Not bad for a first shot!

__But now what?__ These summary statistics don’t tell us very much about how we could make this model better.  That’s where Nucleus comes in.  Below, we create a model_run, which functions as a container for the predictions from this experiment.  Formatting the predictions and sending them to Nucleus takes just a couple lines of code, and can easily be integrated into a PyTorch evaluation function. Once these predictions are visible in the Nucleus dashboard, there are all kinds of error analysis tools at our disposal.

### Adding model predictions to Nucleus

The first step for uploading model predictions is to create a Nucleus model.  Below, we name the model faster_r_cnn so that we can use it to track all experiments using this architecture.

Then, we create a corresponding model_run. The model_run will keep track of the results of this particular experiment.  Once the model_run object is created, we upload the model_predictions.

After model predictions are uploaded, we are ready to commit the model run.  On commit, Nucleus automatically matches predictions to ground truth, calculates IoU, and indexes false positives and false negatives.

## Section 3: Analysis

Now that we have the newly created model_run uploaded to the Nucleus platform, we can easily compare the predicted bounding boxes to the ground truth. Using the patches view, we can examine the individual predictions, sorting by best IoU, worst IoU, false positives, and false negatives.

gif_id_3_dataset_explorer_model_run

In the patches view, we find a number of interesting observations:

Figure 1_false_positives

__Figure 1 (above):__ Examining false positives, we see that there are several instances where the model detected a cyclist as a pedestrian, but there was no ground truth bounding box for the cyclist.  It would likely improve model performance to add a cyclist class; this would encourage the model to differentiate between the two types of objects, rather than just ignore cyclists.

Figure_2

__Figure 2:__ The treatment of partially-occluded pedestrians is not consistent across different images. The occluded pedestrians are labeled in some places, but not in others.

Figure_3

__Figure 3:__ There are many instances of missing ground truth annotations, particularly for pedestrians in the background.

Figure_4

__Figure 4:__ In general, it seems the model performs best on pedestrians in the foreground, and exhibits poor performance on crowded images. 

### The worst-kept secret in machine learning

Nucleus shines a light on the worst-kept secret in machine learning: __most datasets are filled with errors.__ Not only are they often full of bad annotations, but a typical ML engineer __would never even notice.__ All we see is “average precision = 0.827”. Annotation errors are particularly insidious because they put a ceiling on model performance that is invisible to the ML engineer. The fact that these errors remain invisible is a failure of ML tooling. Nucleus helps address it. (In fact, one reason Scale can provide annotations at such high quality is because we leverage tools like Nucleus internally.)

### Addressing the problem

Having the ability to visualize predictions and view errors all in one place gives us much better insight into what is actually going wrong with this model’s performance.  Looking through the test set, we find that many of the predictions marked as false positives are actually just missing ground truth annotations. __This is concerning — without high-quality labels on the test set, it’s difficult to trust evaluation metrics as an unbiased performance indicator.__ 

Some actionable next steps we can take to improve this model’s performance are:

* Add a new label class for cyclist
* Correct missing annotations
* Source additional examples of crowded scenes

### Correcting missing Annotations

In order to continue making progress on this pedestrian detection task, we need to be sure that the evaluation metrics on the test set are actually reflective of good model performance.  We can only trust these metrics when the labels are exhaustive and high quality.  Using Nucleus patches view, we correct missing annotations in both the train and test sets.  The mean average precision (mAP) and mean average recall (mAR) from these experiments are summarized in the following table. 


Table_1

We found that evaluating the baseline model against the improved test set yields lower mAP and mAR, indicating that __evaluating against noisy labels in the test set overestimated model performance.__  Moreover, after also correcting labels in the training dataset, the precision on the corrected test set improved by 7.98%, and recall improved by 7.36% relative to the baseline model.  Overall, these results demonstrate that concentrating on label quality yields significant gains in overall performance.

### Finding additional examples for the training dataset

One finding that label corrections do not address is the poor performance on crowded scenes. As discussed above, the dataset is heavily skewed towards examples with two or fewer pedestrians. Crowded scenes are rare in our dataset— one reliable way to address this edge case is to include more crowded scenes in our training dataset.  In addition to the analysis tools like the patches and insights views, Nucleus supports a variety of features targeted at mining large sets of unlabeled data for rare scenarios.

Since we’re already using all of the images in PennFudan for training and evaluation, we’ll use another publicly available dataset, WiderPerson, as a source of additional examples.

Putting PennFudan and WiderPerson together in one dataset, we now have a mix of labeled and unlabeled data.


gif_id_4_unlabeled_items

Once we’ve found one example from WiderPerson that we would want to include in our training set, we can use image similarity search to find other, similar examples.

gif_id_5_similarity_search

Nucleus features like similarity search are particularly useful on massive datasets where it’s impossible to look through every example.  Using similarity search, we can locate additional examples of pedestrians without having to rely on annotations, helping prioritize what unlabeled data to label next.

## Conclusion

In this tutorial, we’ve demonstrated how Nucleus can help developers get actionable insights into model performance and dataset management.  We’ve shown how to get started by uploading images, annotations, and predictions via the python API.  Using Nucleus features for model analysis, we learned that labeling quality can really interfere with evaluation metrics.  If such errors occur in small datasets like PennFudan, you can only imagine how commonly they occur in larger datasets like Imagenet and MSCOCO. Using Nucleus to identify issues with annotation taxonomy, quality, and consistency can thus play a huge role in producing quality results.

### Acknowledgements

This tutorial is adapted from [this PyTorch tutorial](https://pytorch.org/tutorials/intermediate/torchvision_tutorial.html) and uses the [PennFudan Dataset](https://www.cis.upenn.edu/~jshi/ped_html/).


An introduction to Scale Nucleus, a dataset management tool that helps machine learning teams improve their models by improving their data. In this article, we show how Nucleus can help debug model failures, trace them back to dataset issues, and make it easy to prioritize which data to label next.

Getting Started with Nucleus

Alexandre Matton

Adrian Lam

At Scale AI, we use Machine Learning models in a wide range of applications to empower our data labeling pipeline. We strive for speed and efficiency, and always try to get the best out of the models. Here, we will discuss some tricks we discovered that drastically improve over the PyTorch Transformer implementation in just a few lines of code.
<h2 id="transformers-are-here-to-stay">Transformers are Here to Stay</h2>
Transformers have become ubiquitous. They were first introduced in Attention is All You Need <a href="#references">(Vaswani et al., 2017)</a> and were quickly added to Pytorch. Their popularity increased even more with the development of HuggingFace, which made large NLP pre-trained models such as BERT <a href="#references">(Devlin et al., 2018)</a> widely accessible, and created recipes to enable simple fine-tuning on a wide range of tasks. They’ve been successfully applied to a wide variety of sequence-to-sequence (Seq2Seq) tasks including machine translation, text summarization, or even image captioning (an image is just a sequence of pixels!). This popularity is completely warranted, because Transformers have some significant upsides:
<ul>
<li>
The Transformer architecture is non-sequential making it distributable. Other traditional methods for sequence modeling such as RNNs are limited to processing sequences one token at a time. This sequential nature prevents parallelization and makes training slow. Transformers process entire sequences at once in a highly parallel fashion. This makes them incredibly fast on GPUs and helps handle long-range dependencies elegantly.
</li>
<li>
Transformers make few assumptions about the data. Traditionally, ML practitioners have tailored their networks to process specific types of data. Constraints such as forcing RNNs to process text sequentially from left-to-right allowed these networks to perform well even on scarce training data, spearheading breakthroughs. However, these constraints introduce biases in the model as sequential ordering is rarely the most optimal way to understand text. Transformers keep data representations generic, which make them capable of learning more subtle interactions between words. Recent papers <a href="#references">(Alexey Dosovitskiy et al., 2020)</a> show that the same story could also be true in computer vision, with transformers outperforming the long established CNNs once trained on the huge datasets that have recently been collected. With enough data, Transformers learn more complex and accurate representations than the constrained networks which used to be the only viable option.
</li>
</ul>
<h2 id="sequence-to-sequence-with-transformers">Sequence-to-Sequence with Transformers</h2>
But Transformers also have their weaknesses. When generating sequences for Seq2Seq tasks at inference time, Transformers are constrained because each item in the output sequence can only be predicted one at a time. This, combined with the quadratic attention complexity can make them slower than their counterparts. (For training, this is not an issue thanks to teacher forcing).
Seq2Seq models typically create an internal high-level representation of the input sequence and then decode (i.e. generate) the output sentence. Given the high-level representation of the input sentence and the words that have already been decoded, Seq2Seq models estimate the most likely words to complete the sentence. This phenomenon is called auto-regression and the phase corresponding to generating a new word (or token) is a timestep.

pytorch_01

## Decoding Inefficiency of the **PyTorch** Transformers

The Transformer class in Pytorch is generic which is great because it gives the ML researchers at Scale AI fine-tuned control but that also means it isn’t optimized for speed. Let’s take a deeper look.

First, it can be seen in Figure 1 that the encoder output can be computed separately from the decoder. This means that the encoder outputs can be computed once and re-used for each timestep thereafter. But Pytorch does NOT save this for you - and in fact wastes compute for each decoding timestep. To fix this, the Transformer Encoder and Decoder should always be separated.

```
# THIS IS THE NAIVE WAY TO USE TRANSFORMERS

# INITIALIZATION
transformer = nn.Transformer(
  d_model=hdim,
  nhead=nhead,
  num_encoder_layers=num_layers,
  num_decoder_layers=num_layers,
  dim_feedforward=dim_feedforward,
).to(device=device)
transformer.eval()

# INFERENCE LOOP
decoded_tokens = first token
for i in range(len_output_to_decode) : # generate `len_output_to_decode` tokens
  mask_dec = generate_square_subsequent_mask(
    i + 1, device=first_token.device
  ) # create mask for autoregressive decoding
  decoded_embeddings = embedding(decoded_tokens)
  output = transformer(src, decoded_embeddings, tgt_mask=mask_dec)
  logits = to_vocab(output) # projection to vocab size

  # keep most likely tokens
  top_indices = torch.argmax(logits, dim=-1)
  # we only care about the last token that was decoded
  top_indices_last_token = top_indices[-1:]
  # add most likely token to the already decoded tokens
  decoded_tokens = torch.cat(
    [decoded_tokens, top_indices_last_token], dim=0
  )
```

The code below is a much more efficient way to get the same results by decoupling the encoder and the decoder. Note that the code corresponding to the inference loop barely changes.

```
# INITIALIZATION
encoder = nn.TransformerEncoder(
  nn.TransformerEncoderLayer(
    d_model=hdim, nhead=nhead, dim_feedforward=dim_feedforward
  ),
  num_layers=num_layers,
).to(device=device)
encoder.eval()

decoder = nn.TransformerDecoder(
  nn.TransformerDecoderLayer(
    d_model=hdim, nhead=nhead, dim_feedforward=dim_feedforward
  ),
  num_layers=num_layers,
).to(device=device)
decoder.eval()

# INFERENCE LOOP
decoded_tokens = first_token
src_embeddings = encoder(src)
for i in range(lenoutput_to_decode):
  mask_dec = generate_square_subsequent_mask(
    i + 1, device=first_token.device
  ) # create mask for autoregressive decoding
  decoded_embeddings = embedding(decoded_tokens)

  # the decoder uses the encoder output `src_embeddings`
  output = decoder(decoded_embeddings, src_embeddings, tgt_mask=mask_dec)

  logits = to_vocab(output) # projection to vocab size

  # keep most likely tokens
  top_indices = torch.argmax(logits, dim=-1)
  # we only care about the last token that was decoded
  top_indices_last_token = top_indices[-1:]
  # add most likely token to the already decoded tokens
  decoded_tokens = torch.cat(
    [decoded_tokens, top_indices_last_token], dim=0
  )
```

The main inefficiency extends on the previous point. It can be seen in Figure 2 that the embedding of a decoded token only depends on the tokens that were decoded before it. This is a direct benefit of the Transformer model being autoregressive. Thus, it is unnecessary to recompute the embeddings of the already decoded tokens repeatedly and instead, we can again cache them. Each timestep then only consists of computing the attention for the newest token’s embedding. 


Decoder_self_attention_links_image

__Figure 3: Decoder self-attention links when decoding tokens__. *The boxes at the bottom represent the embeddings of the output tokens before self-attention, the top boxes represent the embeddings of the output tokens after self-attention. Using our trick (right side), most of the embeddings are not recomputed as they are cached. The number of links to into account becomes linear instead of quadratic.*

From a complexity perspective, generating the n-th output token without our trick involves computing self-attention over the entire current output  (*O*(n²)) and computing encoder-decoder attention between the whole input (of size that we will note M) with the current output (*O*(Mn)). Hence, the complexity of each timestep is *O*(Mn + n²). Given that we want to decode N tokens, N timesteps are needed, and the final complexity is *O*(MN² + N³).

Our trick accelerates each timestep. Only the parts of the self-attention and encoder-decoder attention responsible for updating the last token are computed. Figure 3 shows how this works for the self-attention. The new complexity of each timestep is *O*(M + N), so with N timesteps the final complexity is sped up to *O*(MN + N²).

The PyTorch Transformer decoder architecture is not assumed to be autoregressive. However, by inheriting the TransformerDecoder layer, we introduce a CausalTransformerDecoder which uses a cache to implement the improvement above. Our [code](https://github.com/alexmt-scale/causal-transformer-decoder) differs from the Pytorch implementation by a few lines only. Our new decoder works similarly to the original TransformerDecoder, except that we now have to take into account the cache:


```
causal_decoder = CausalTransformerDecoder(
  CausalTransformerDecoderLayer(
    d_model=hdim,
    nhead=nhead,
    dim_feedforward=dim_feedforward,
  ),
  num_layers=6,
).to(device=device)
causal_decoder.eval()

decoded_tokens = first_token
src_embeddings = encoder(src)
cache = None
for i in range(len_output_to_decode):
  mask_dec = generate_square_subsequent_mask(
    i + 1, device=first_token.device
  ) # create mask for autoregressive decoding
  decoded_embeddings = embedding(decoded_tokens)

  # only change here: we add the cache as an extra parameter
  output, cache = causal_decoder(decoded_embeddings, src_embeddings, cache)

  logits = to_vocab(output) # projection to vocab size

  # keep most likely tokens
  top_indices = torch.argmax(logits, dim=-1)
  # we only care about the last token that was decoded
  top_indices_last_token = top_indices[-1:]
  # add most likely token to the already decoded tokens
  decoded_tokens = torch.cat(
    [decoded_tokens, top_indices_last_token], dim=0
  )
```

## Experiments 

We put our changes to the test to see how much faster we could get. We present two different scenarios: translation and generation of long texts. 

We compare our three different implementations [(see footnotes for details)](#footnotes):

* The most naive Pytorch implementation (defined in the first piece of code), which uses nn.Transformer
* The Pytorch encoder-decoder implementation (second piece of code).
* Our CausalTransformerDecoder (third piece of code).

As a reminder, these are three different implementations of the same model. When initialized with the same weights, they return the same outputs.

### Text Translation

The first setting corresponds to translation. In this setting the input and output sequences are generally short and of similar lengths. 


Time_spent_decoding_sentence_figure

Time_ratio_between_models_figure

### Long Text Generation

We now ask the model to generate long sequences from a fixed size input. Such a situation might arise when generating a story from an image or from an initial prompt.

The results below were obtained with a fixed input size of 500 tokens. Increasing the number of input tokens makes the models slower but doesn’t change the overall trends observed.


Time_spent_decoding_a_sentence_when_generating_text_figure

Finally, our CausalTransformerDecoder can also be used without any input sentence (i.e. without an encoder), as it is the case in some common generation settings. The model is typically asked to complete a story or an article. More information about this type of generation can be found in the GPT papers [(Alec Radford et al., 2018)](#references). The results we find for this case are similar to the ones above.

## Digging deeper...

One might notice that caching the output of each layer is sub-optimal. Indeed, the first stage of the attention layers consists of projecting the embeddings to the keys, values and queries spaces. In the PyTorch implementation and the proposed implementation, the same embeddings get projected repeatedly. Instead, the queries, keys and values could be directly cached. However, this requires substantially more changes, which could become unstable with new Pytorch upgrades. Moreover, the estimated gains are minor - less than 5% from our experiments.

For standard NLP use cases, the HuggingFace repository already embeds these optimizations. Notably, it caches keys and values. It also comes with different decoding flavors, such as beam search or nucleus sampling.

## Conclusion

The simple tricks proposed take advantage of the fact that the overall Pytorch implementation of the Transformer is too generic. The changes provide modest speed improvements when generating a few hundreds of tokens which can become significant boosts over the original PyTorch implementation when the output length nears a thousand tokens. These gains are naturally directly proportional to the number of output tokens to decode. And best of all, they can be implemented in just a few lines using our [repo](https://github.com/alexmt-scale/causal-transformer-decoder).

<h3 id="references">References:</h3>

Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. *Attention is all you need*. In Advances in Neural Information Processing Systems 30, pp. 5998–6008. Curran Associates, Inc., 2017. URL: [https://proceedings.neurips.cc/paper/2017/file/3f5ee243547dee91fbd053c1c4a845aa-Paper.pdf](https://proceedings.neurips.cc/paper/2017/file/3f5ee243547dee91fbd053c1c4a845aa-Paper.pdf)

Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. *BERT: pre-training of deep bidirectional transformers for language understanding*. CoRR, abs/1810.04805, 2018. URL: [http://arxiv.org/abs/1810.04805](http://arxiv.org/abs/1810.04805).

Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani et al. *An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale.* arXiv preprint 2020 URL: [https://arxiv.org/pdf/2010.11929](https://arxiv.org/pdf/2010.11929)

Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac et al. *Transformers: State-of-the-art natural language processing* arXiv preprint 2019 URL: [https://arxiv.org/pdf/1910.03771.pdf](https://arxiv.org/pdf/1910.03771.pdf)

Alec Radford, Karthik Narasimhan, Tim Salimans, and Ilya Sutskever. *Improving language understanding by generative pre-training.* arXiv preprint 2018 URL: [https://www.cs.ubc.ca/~amuham01/LING530/papers/radford2018improving.pdf](https://www.cs.ubc.ca/~amuham01/LING530/papers/radford2018improving.pdf)

<h3 id="footnotes">Footnotes:</h3>

1 - The vocabulary size used for this experiment was 30,000. It corresponds to the vocabulary size chosen in the BERT original paper, which uses BPE tokenization. We also ran the same experiments with a much smaller vocabulary (128 tokens), to imitate a character-level setting which did not show significant benefits.

2 - The hyperparameters used for the Transformer architecture are the ones of the original paper (6 layers, 8 heads, 512 hidden dimensions, 2048 feed-forward hidden dimensions for both encoder/decoder). The results should be similar with other configurations, provided that the encoder and decoder have the same size.

3 - The displayed results correspond to a batch-size of 8 sequences, but we made sure that a batch-size of 1 gives the same trend. A batch-size of 1 is usually the most common in inference as requests are sent asynchronously. However, in our specific setup the model takes several seconds to generate sentences, so it is more natural to batch requests.

3 - As a safety check, we benchmarked GPT-2 HuggingFace implementation against our Causal Decoder. To do that, we used the same set of hyperparameters. We generated up to 1000 tokens with the two models. The speed ratio between these two models was close to 1, oscillating between 0.85 and 1.10.

4 - All the experiments were run on a V100 GPU.

How the machine learning team at Scale AI improved Pytorch Transformer architecture on sequence generation. 

Make Pytorch Transformer twice as fast on sequence generation.

Making Pytorch Transformer Twice as Fast on Sequence Generation.

Alexandr Wang

Today we are excited to share several key updates that build on Scale AI’s mission to accelerate the development of AI.
First, we are officially announcing Scale’s Series D funding round. Following our Series C fundraise last year, Scale has raised $155M at a post-money valuation north of $3.5B led by Tiger Global.
We are in the midst of one of the most impactful technology transformations of human history with AI. The potential applications of AI are going to deeply improve the world: scalable medical diagnosis to everyone in the world, massive reduction in driving accidents, goods which are dramatically cheaper to manufacture and transport, and much more. What’s holding us back from building those dreams is lack of infrastructure. While many organizations are adopting AI, they are forced to build their technology stack from scratch, significantly slowing progress.
Four years ago, we recognized this problem and sought to unlock the bottlenecks holding back AI development. We started by building a platform that solves the necessary, foundational layer that fuels all machine learning models: large annotated datasets. Our solution gives developers the ability to send data to our platform through the Scale API and receive high-quality training data that’s ready for building production-grade AI algorithms. We use a combination of machine learning and human intelligence to annotate tens of millions of data points per week for hundreds of customers like OpenAI, DoorDash, Pinterest, General Motors, NVIDIA, Nuro, and Toyota.
We’ve chosen to stay focused on the applications of AI with the greatest potential for impact: autonomous driving, government, and cutting-edge consumer technology. As AI has transformed every industry, we’ve continued to see demand for our platform to grow—from e-commerce and AR /VR to relevance &amp; personalization and financial services. We are still very early in the journey of AI, and we remain optimistic about all the future dreams we will support.
Our team is tackling the next bottleneck in AI development: managing the full life cycle of AI development across teams. Building and deploying scalable machine learning infrastructure is slow, manual and costly, and in August we launched <a href="https://scale.com/nucleus" target="_blank">Nucleus</a> to enable seamless collaboration across the AI development cycle. Teams can visualize and organize their datasets, test and compare models, and share data with colleagues. With Nucleus, our goal is to become the mission control for your data, and over time we’ll be rolling out support for more data types and adding more features to make developing AI easier and faster than ever.

Scale_Nucleus_ML_Development_Cycle

As part of today’s announcement, we are also excited to announce the acquisition of Helia AI. Helia’s team brings deep expertise in applying AI to real-time video, from core algorithm development to necessary AI infrastructure. Their AI infrastructure experience aligns closely with what we’re building with Scale Nucleus, and the Helia team will help advance the Scale platform as we expand its capabilities.

We look forward to continuing our work of building AI infrastructure with Scale’s hundreds of customers, and our new funding will allow us to accelerate hiring, expand to new markets and build more robust products to match the evolving needs of AI as the technology matures. We’re still in the early days of AI, and we believe Scale will enable a future where AI is as easy to build and manage as any other software. If you are interested in joining us on our mission, check out our [open positions](https://scale.com/careers). If you’re interested in partnering with us, please [reach out](https://scale.com/sales). 

Accelerating the development of AI applications and empowering AI dreamers with a new round of funding led by Tiger Global. 

Scale AI's Series D: Expanding our team to empower AI dreamers

Scale AI’s Series D: Expanding our Team to Empower AI Dreamers

Logan Ford

Teddy Lee

When Covid-19 first hit, many companies had to rapidly reorient their operations – from altering their supply chains to implementing social distancing and work-from-home orders.
One sector that was particularly hard hit was the restaurant industry. When in-person dining was suspended, restaurants turned to delivery to survive. But setting up a delivery service from scratch takes time and money that many establishments, with their income drying up, did not have. Suddenly, food delivery platforms became an economic lifeline.
To ensure restaurants could onboard quickly and seamlessly in these critical early days, one of the leading delivery platforms turned to Scale.
<h3 id="scaling-labeling">Scaling labeling</h3>
Every time a restaurant joins one of the delivery platforms or changes its menu, the menu’s contents need to be inputted into the platform so users can select their food. Inputting menus manually is slow, expensive, and leads to mistakes. With restaurants relying on delivery to reach customers and support their staff, a leading delivery platform knew it was vital to ensure an efficient process for its partner restaurants.
This presented Scale with unique latency and quality control challenges, requiring both an incredibly high level of accuracy with a fast turnaround to provide operational efficiencies at a critical time for our customer. Our aim was to use the combination of partial automation and human quality control in our <a href="https://scale.com/document" target="_blank">Scale Document</a> labeling pipeline to make dramatic efficiency improvements over manual processes. In all, we nearly halved the time it takes our customer to process menus and reduced critical error rates to &lt;1% for all items labeled, allowing them to onboard restaurants smoothly exactly when they needed it.
<h3 id="building-the-right-data-infrastructure">Building the right data infrastructure</h3>
While processing standardized documents such as food menus, government IDs or loan application forms might be intuitive and simple for humans, it is a surprisingly nontrivial problem for algorithms, involving much more than automatic transcription. In particular, the data often contains many dependencies that need to be captured accurately. For example, ordering a pepperoni pizza doesn’t just mean choosing the type, but also the size, the type of base, choosing to substitute or customize toppings (which can also vary in price depending on the size of the pizza, creating more interdependencies), and whether to add extras like burgers or sandwiches. It’s important to capture these dependencies in the menu correctly, otherwise inputting errors risk causing losses for both the restaurant and the delivery platform.

DD_decision

Algorithmically, this has to be represented as complex decision trees made up of categories, items, and lists of options, capturing the relationships between them. Thankfully, both our document processing pipeline and form capture tools were already set up to capture these types of nested data structures automatically without the need for customization. This meant we were able to quickly pivot our tools for our customer’s requirements.

### Judicious Automation and Scaling
Once we have the right tooling in place to pull the raw data and label complex data structures, we can then start processing the data. Given how many menus delivery platforms were processing at the start of shelter-in-place, and how important for restaurants’ continued operations it was to process this data quickly with no drop-off in quality, we need to make this process as efficient as possible. 

At Scale AI, we believe that a mix of judicious labeling automation with continued human oversight is the only way to provide data at the scale, quality, and low cost needed to enable many enterprise applications of AI. In particular, we aim to automate the lower-skilled parts of the data labeling pipeline to focus human review on the hard parts – quality control, edge cases, and the most complex data types. That way, we can help guarantee quality without sacrificing efficiency.

We use automation to prefill menu taxonomies for expert human labelers to review and confirm. 

<figure class="expand-image">
<video autoplay muted loop>
 <source src="https://videos.ctfassets.net/1qgw036lpkfx/3frjAvFdxn4pE0ZHJBnlaO/878291c892968b416019b22a4ecf62e8/scale-document-blog-video.mp4" type="video/mp4" />
</video>
 
<figcaption>We trained our form capture tool to automatically understand document structure and predict the next transcription.</figcaption>
</figure>

And when our labelers needed to add inputs manually, we built a “smart suggestion” feature that provides them with ready prompts for common items that they have already encountered in their batch of menus. 

Both have helped improve both the efficiency and accuracy of labeling simultaneously: allowing us to transcribe more than 3,000 menus in a single day and return menus within short turnaround times to onboard restaurants within 24 hours from start-to-finish. By drawing on our wide network of well-trained labelers and augmenting their work with careful automation, we’re able to handle changes in demand dynamically – essential for providing a smooth service during sudden peaks in demand.

### Custom Benchmarks and Integrations
Once data is flowing smoothly and efficiently through this labeling pipeline, the next step is to ensure that the data is being labeled to an incredibly high standard, with almost zero errors. We’ve developed a range of techniques to guarantee label quality, including the randomized use of benchmark quality tests, confidence-based consensus, and, for ambiguous labeling requirements, our own [automated benchmark generation system](https://scale.com/blog/how-to-label-1m-data-points-week). 

Benchmarking is not always an objective science – the most effective benchmarks are often task-specific. The high stakes of onboarding restaurants during a pandemic required particularly high guarantees of labeling quality. To meet them, we worked closely with our customer to build custom benchmarks for this workflow, turning the most complex mislabeled menus into benchmarks that assessed our labelers’ performance.

In surveying mislabeled menus, we noticed two key groups of errors. One was associated with the cross-referencing of menu sections between many items and mistaking how they relate to each other, while the other group tended to be mistakes from larger menus where it may be less obvious when certain features of the menu are missing. By identifying these key groups and creating benchmarks out of the associated menus, we can ensure that tasker performance in such cases exceeds the necessary standard to meet menu quality needs.


Menu_dd_photos

### What’s Next
AI models are rapidly becoming critical infrastructure for a huge range of businesses – a trend of automation that the COVID pandemic has rapidly accelerated. But gathering effective, accurate, and unbiased data currently remains such a challenging task that it is preventing real-world AI systems from reaching their full potential and presenting high complexity barriers for smaller companies.

We’re tackling a whole host of problems to help accelerate that progress. Right now, teams at Scale AI are making better use of machine learning to make labeling orders of magnitude more efficient, building tools to process increasingly complex data types, such as 3D point clouds in computer vision, and developing new infrastructure tools to help streamline the management of data. Our first such management tool, [Scale Nucleus](https://scale.com/blog/introducing-scale-nucleus), is already helping our computer vision customers automate time-consuming manual steps in the ML development process. We’re now working on deploying it for our customers in natural language. 

Ultimately, we want to make it as easy to deploy AI as any other type of software. If you’re interested in joining us in solving these problems, take a look at our [careers page](https://scale.com/careers) for our latest open positions. If you have projects that require high-quality data labeling, [let our team know](https://scale.com/sales)!


How Scale AI worked with a leading food delivery platform to ensure restaurants could onboard quickly and seamlessly. 

Rapidly scaling menu transcription to support restaurants during the pandemic

Scaling Menu Transcription Tasks with Scale Document

Shannon Hong

The Scale AI team hosted its first ever Hackathon last month. The hackathon was designed to:
<ol>
<li>Encourage innovative thinking to solve some of Scale’s biggest challenges</li>
<li>Prototype and potentially launch impactful projects that make Scale better in practice</li>
<li>Facilitate long-term cross-functional relationships</li>
<li>Give all Scaliens a creative break from their daily work.</li>
</ol>
Scaliens across functions and teams leapt to the challenge, proposing 63 ideas and ultimately working on 10 separate projects comprising of 37 team members. Projects ranged from new product proposals to better internal search, from refactoring tech debt to streamlining instructions for Taskers.

Nofel_Naoman_Hackathon_Quote

## Project Highlights: 

The following are just some of the projects Scaliens tackled during the Hackathon. As a disclaimer, most of these projects are not live, nor do they indicate immediate plans to build these ideas.

### Super Instructions 

__Winner:__ Best In Show

__Team Members:__ [Shaun VanWeelden](https://www.linkedin.com/in/svanweelden/), [Taisia Karaseva](https://www.linkedin.com/in/taisiakaraseva/), [Jeff Lin](https://www.linkedin.com/in/jeffrey-linj/), [Galen Bertozzi](https://www.linkedin.com/in/galenbertozzi/), [Rashid Lasker](https://www.linkedin.com/in/rashidlasker/), [Ivan Roumec](https://www.linkedin.com/in/ivan-roumec-b0450a6b/), [Nofel Naoman](https://www.linkedin.com/in/nofel-naoman-aa28a0142/), [Lawder Paul](https://www.linkedin.com/in/nba/)

__Problem Statement:__
Annotation instructions are critical for the development of high-quality training data. Today’s annotation instructions are mostly made on static, non-interactive documents, not connected to the API payloads creating the task and requiring 3rd party solutions to host.

__Solution:__
The Super Instructions team tackled this problem in 3 ways:

  1. Extending the Task Schema used in our APIs to accommodate labeling         instructions.
  2. Creating an in-app instruction builder that simultaneously creates the     instructions as well as the API payloads that would need to be leveraged     in task creation.
  3. Bringing a world-class interactive design to the in-app educational         experience for those doing the annotating, including features like           search, navigation, and zoomable images. 

The goal of this prototype was to re-imagine the experience both our customers and Taskers have when creating and completing work on Scale’s platform. We firmly believe better instruction design and more consistency leads to higher-quality annotations for all involved. 

### Corp Search

__Winner:__ Audience Choice

__Team Members:__ [Lawder Paul](https://www.linkedin.com/in/nba/) and [James Lennon](https://www.linkedin.com/in/james-lennon-30421078/)

__Problem Statement:__ 
“Corp” is Scale AI’s admin portal for employees to gather information on on-going projects and to influence the quality and outcome of data annotation. The Scale AI team has launched countless tools and introduced new functionalities to Corp to improve our operations but the Corp portal itself was not very user friendly. There are now so many tools in Corp that it can be hard to find the exact tool, and for new Scaliens it’s not always clear what different tools do. 


Scale_Corp_Search

Scale Corp Search

__Solution:__ 
Corp Search allows employees to quickly search across all areas and tools within Corp, packaged in an elegant "command-line" interface that can be surfaced anywhere in Corp.

### Corp Migration

__Winner:__ Most Immediately Impactful

__Team Members:__ [Diego Muracciole](https://www.linkedin.com/in/diegomura/), [Federico Marcos](https://www.linkedin.com/in/federicomarcos/), [Martin Cabral](https://www.linkedin.com/in/martin-cabral-b0897615/)

__Problem Statement:__ As stated in the Corp Search project, Corp had become a complex and sophisticated tool used by many to provide the best service to our customers. Many of the Tasker and customer-facing features and tools were tied together or interlinked with Corp, making additional engineering work more challenging. 

__Solution:__ 
The team spent the week separating these Tasker and customer-facing features were separated from Corp. The team also developed a framework to encourage internal modularity and code reuse to enable faster deployment in the future as Scale continues to grow. The team also ensured backwards compatibility with previous code to ensure daily operations could continue. This project has already enabled several refactors and performance improvements. 

### The Great Refactor

__Team Members:__ [Andrew Liu](https://www.linkedin.com/in/liuandrewk/), [Nick Induni](https://www.linkedin.com/in/nick-induni-44357292/), [Steven Hao](https://www.linkedin.com/in/steven-hao-160b9638/)

__Problem Statement:__ Like many fast-growing startups, Scale AI has accumulated some level of tech debt in order to quickly deliver new features and products to our customers. 

__Solution:__
The Great Refactor team looked to tackle this issue by investing a week of their time to improve code quality to optimize for long-term maintainability and development velocity.

### Tasker Scoresheets

__Team Members:__ [Akshat Bubna](https://www.linkedin.com/in/akshat-bubna-188885103/), [Rilka Li](https://www.linkedin.com/in/rilka/), [Alan Yu](https://www.linkedin.com/in/alan-yu-954926110/)

__Problem Statement:__ Although Taskers (our global data annotation workforce) regularly receive feedback on the quality of their submissions, it is difficult to provide granular feedback with specific areas of strength and weakness.

__Solution:__ 
The team developed Scoresheets that could be accessed on the Tasker dashboard. The dashboard allows Taskers to track their individual performance on specific skills over time and provides learning resources to improve at weak skills.

### Scale Grep

__Team Members:__ [Jonathan Fung](https://www.linkedin.com/in/jonfung1/)

__Problem Statement:__ Instead of searching through command-line grep, IDE search, or Github search, which can be slow and unwieldy, engineers need quick, interactive, on-the-fly code search that can generate quickly sharable links.

__Solution:__ 
We deployed two open-source projects, Livegrep and Webgrep internally, and added automated index-generation so that the code in our git repositories gets indexed every 2 hours. Now, engineers can search through our large codebase in milliseconds and click code fragments to generate sharable links to exact lines of code.

## Facilitating Interactions to Foster Cross-Functional Relationships

In addition to working on impactful projects, another goal of the Hackathon was to facilitate cross-functional relationships. Fostering these connections when everyone is remote can be particularly tricky. How do you recruit teammates to work on your project when you can’t organically run into folks in hallways? How do you whiteboard ideas, or learn a new skill from teammates when you can’t physically sit together?

### Pitch Session 

To help idea originators find teammates, we held a company-wide pitch session a week before the Hackathon. Scaliens then spent the following week signing up for the pitched projects and forming cross-functional teams. 

### Events and Activities


Scale_Hackathon_Zoom

To help Scaliens develop new skills, we organized workshops throughout the week of the Hackathon. Workshops included:

  - A session on Storybook for planning engineering deployments
  - A session on Figma to understand Scale’s design resources and to             enable better designing and prototyping
  - A session on Tableau to enhance data visualization. 

We also organized daily social activities and special events throughout the week to facilitate social bonding. These activities included a Daily “Brain Game” and a virtual Game Night. 

To help everyone get into the spirit of the Hackathon (whether they were on a team or not), we fully branded the hackathon experience. Our Brand Director, [Ty Wilkins](https://www.linkedin.com/in/tywilkins/), created custom Zoom backgrounds, and branded swag, while Product Designer, [Chun Jiang](https://www.linkedin.com/in/chun-jiang-0428/), designed our *Paranormal Hacktivity* mascot.


![scale_blog_hackathon_ghost](//images.ctfassets.net/1qgw036lpkfx/1MOMHZ4lAmvgsNDSxgZCFY/bc103016d8fc58881eba0d8d87b201b5/scale_blog_hackathon_ghost_04.svg)

### Presentations and Hackathon Wrap-up

Once projects were wrapped up, the teams presented their projects to the entire company. A team of internal judges gave out awards for “Best-In-Show” and “Most Immediately Impactful” and the entire company voted on a “Audience Choice” award.  After the final presentations, Scaliens gathered in a virtual stretch session to unwind and relax.

We hope this blog inspires you to host your own virtual hackathon or spark ideas for a hackathon that is in the works. If you’re interested in tackling new challenges and joining a collaborative and exciting team, take a look at all of our [open positions](https://scale.com/careers#jobs)!

Encouraging innovative thinking and making Scale AI better in practice with our first virtual Hackathon. 

Encouraging innovative thinking and tackling Scale AI's biggest challenges.

Scale Hackathon

Facundo Pepe

Back on September 16th, we introduced you to our <a href="https://scale.com/blog/introducing-our-new-api-docs" target="_blank">new API Docs</a>. Today, we’re pleased to follow up the original announcement with further details on how we implemented this with Next.JS, Tailwind CSS, and ReadMe. Furthermore, rather than simply describing how we used each platform and framework, we have packaged together an example for you to implement and build off of <a href="https://github.com/scaleapi/custom-documentation-example" target="_blank">in this repository</a>.
<h2 id="some-context%3A">Some Context:</h2>
At Scale AI, we are building the critical tools that make it easier to build and scale real-world AI systems. To provide our customers with the best experience possible on the Scale AI platform, we believe that a clear, simple, and memorable front-end, user interface, and user experience is critical. Scale’s design team has been hard at work building out a design system and improving customer-facing interfaces to bring front-end consistency across our platform.
Most important to this effort was to implement the design system across our different applications. We decided to use Tailwind CSS as a CSS framework and CSS Modules as a way to add custom elements when some customization was needed. To ensure our website and applications were highly performant and loaded quickly, we chose to use Next.js as our react framework.
<h2 id="why-tailwind%3F">Why Tailwind?</h2>
Scale’s design team have used Next.js and styled-jsx as a way of providing CSS styling since the initial launch of our website. While this was fine when there were fewer pages on the website, it proved to be hard to scale and maintain a design system without proper documentation. At this point the team faced two options: we could either spend a lot of time creating and improving our own CSS and writing documentation for it, or we could use a CSS framework that could adapt to our needs.
Since the Scale team prefers not to re-invent the wheel when it isn’t needed, we decided that using a CSS framework would yield the best results in the shortest period of time. Tailwind has allowed us to expedite the development of new layouts and pages while maintaining consistency across our website. Tailwind also has the advantage of having strong documentation behind it to support future development. Using Tailwind has also freed the team up to spend more time focusing on special details for each page like custom animations and interactions.
<h2 id="why-next.js%3F">Why Next.js?</h2>
Next.js is one of the best React Frameworks out today. Since the launch of <a href="https://nextjs.org/blog/next-9-3#next-gen-static-site-generation-ssg-support">SGG support</a> in March, it’s a no brainer for a fast and performant website and API docs.
Quoting them from their own <a href="https://nextjs.org/blog/next-9-3#next-gen-static-site-generation-ssg-support">blog post</a>:

Nextjs Quote

Next.js Quote

Next.js’s API routes also proved to be helpful as we used this to retrieve the search values made by the user. More on their API Routes [here](https://nextjs.org/docs/api-routes/introduction). 

## Why Readme?

As we highlighted in our previous [blog post](https://scale.com/blog/introducing-our-new-api-docs), we chose ReadMe as the platform for our API documentation because ReadMe allowed us to:

1. Unify the API reference and the Customer Dashboard documentation into a unified website.
2. Improve the developer experience. Instead of only showing static code examples, ReadMe enables developers to submit API requests directly with their Scale API key. ReadMe also has built in search functionality to make it easier for developers to find specific topics.
3. Democratize the content creation process. Instead of editing raw markdown, making a pull request, and then deploying to a server, we just had to update the text we needed in the ReadMe UI. Ultimately, the ReadMe platform provided a richer and more dynamic user experience.

## Sharing our example code with the developer community

We developed the new API documentation during Scale’s Hackathon. We are incredibly proud of what we accomplished in just one week and we wanted to share our solution with anyone who is looking to solve a similar problem. Rather than simply providing a step-by-step instruction for this solution, we have packaged together an example for you in our [Github repo](https://github.com/scaleapi/custom-documentation-example). 

We hope this sample code allows you to build your own beautiful and customized documentation.


How to customize your API Documentation’s front-end leveraging cutting-edge platforms and frameworks.

Customizing API Documentation with Next.JS, Tailwind CSS, and ReadMe.

Quick Start Guide to Customized API Documentation

Nishant Subramani

<h2 id="introduction">Introduction</h2>
The ML Team at Scale hosts a weekly reading groups where members choose papers from the broad AI/ML community and discuss them ranging from topics in Computer Vision to NLP to Active Learning. Here, we describe a brief summary of some of the insights we gained from various papers and how we aim to use some of that knowledge in future research projects and applications to Scale AI’s business.
<h3 id="discovering-useful-sentence-representations-from-large-pretrained-language-models"><a href="https://arxiv.org/abs/2008.09049" target="_blank">Discovering Useful Sentence Representations from Large Pretrained Language Models</a></h3>
Presenter: <a href="https://www.linkedin.com/in/nishantsubramani/" target="_blank">Nishant Subramani</a>
This is Scale’s first research paper and we wrote a <a href="https://scale.com/blog/discovering-useful-sentence-representations" target="_blank">blog post summarizing the paper</a>. This paper focuses on whether we can adapt pre-trained language models off-the-shelf as universal decoders. To be considered “universal,” a decoder must have an implicit representation for any target sentence such that it can recover that sentence exactly when conditioned on its representation. We investigated whether such representations exist and whether they can be easily discovered. Experiments show that not only do these representations exist for sentences from a variety of different genres, but also that our methods can recover these sentences almost perfectly without fine-tuning the underlying language model at all.

scale blog ml papers 1.jpg

Scale blog ml papers B_01

### [Scalable Nearest Neighbor Search for Optimal Transport](https://arxiv.org/abs/1910.04126)
__Presenter:__ [Anastasiia Alokhina](https://www.linkedin.com/in/anastasiia-alokhina-534b1014a/)

The authors of this paper look at the problem of nearest neighbor search with respect to Wasserstein distance. As Wasserstein distance has become popular in high-resource data environments and domains (images, text, etc.), search becomes prohibitively slow. As a result, approximation methods are important. The authors introduce a Quadtree variant called a Flowtree that formally shows better asymptotic accuracy and empirically show that it beats existing methods on a variety of different real-world datasets on either running time or accuracy.

Flowtree is a fast nearest neighbor search algorithm for Optimal Transport (Wasserstein-1 distance), which has a linear running time and speeds up SOTA performance by up to 7x. They do this by evaluating the optimal tree flow in the original metric space.

scale blog ml papers B_02

At Scale AI, we work with lots of high dimensional data such as documents and images for a variety of tasks. For these, we often need to find good representation spaces for these data points such that we can do fast and highly accurate similarity search in order to find outliers in datasets in order to find errors in labeling and find examples to label to improve our models using active learning. We think the flowtree method here could be invaluable in giving us the ability to use a different distance for this end and is something we will explore going forward. 

### [Structure-from-Motion Revisited](https://demuc.de/papers/schoenberger2016sfm.pdf)
__Presenter:__ [Hongbo Tian](https://www.linkedin.com/in/ppyht2/)

Structure-from-Motion(SfM) is a field of computer vision techniques which aim to reconstruct full 3-dimensional scenes from only a series of images. Accurate SfM algorithm can reproduce colored point clouds similar to LiDAR. The authors of this paper along with [Schönberger’s thesis](https://colmap.github.io/bibliography.html) introduced a robust computational pipeline for accurate dense 3D reconstruction. The authors also introduced [COLMAP](https://colmap.github.io/index.html) - an open-sourced CUDA accelerated software to reproduce the results.

scale blog ml papers B_03

Scale blog ml papers B_03

At Scale AI, our labelling pipeline is not subjected to the same online computational constraints compared to our customers. This allows us to pursue batch methods to enrich our 2D dataset, enabling our human labelers to capture 3D contexts from only images.

### [Representation Learning for Information Extraction from Form-like Documents ](https://storage.googleapis.com/pub-tools-public-publication-data/pdf/59f3bb33216eae711b36f3d8b3ee3cc67058803f.pdf)
__Presenter__: [Nishant Subramani](https://www.linkedin.com/in/nishantsubramani/)

The authors aim to extract structured information from form-like documents. They observe that forms have fields that often correspond to well-understood types and are often associated with a specific key phrase that bears a visual relationship with it. They also observe that key phrases in documents are drawn from a small vocabulary. Due to these observations, the authors build a system with two parts: candidate generation and scoring & assignment.

In the candidate generation phase each field type is associated with a candidate generator based on a cloud-based entity extraction service. Spans are then detected. In an invoice there are multiple dates. Every date in an invoice becomes a candidate for every date field in the target schema. This process is repeated for every target field.

In the scoring and assignment phase, the goal is to find the correct extraction candidate for each field. To do this, a score is computed for each candidate independently using a neural model. Next, the most likely scored candidate is assigned for each field. This process yields an independent learned representation based only on the candidates’ neighborhood (this is entirely independent of other candidates of fields). The neural scoring model is below.


scale blog ml papers B_04

Scale blog ml papers B_04

Our major takeaways are that structured extraction is not super well-studied by the academic community, but is relatively simple. The extraction system presented has promising accuracy and generalizes well to different domains. The representations have some interpretability as well. Ultimately some of the learnings from this paper could influence some of our work on [Scale Document](https://scale.com/document).

### [Big Transfer (BiT): General Visual Representation Learning](https://arxiv.org/abs/1912.11370)
__Presenter__: [Felix Lau](https://www.linkedin.com/in/felix-lau-0386641a/)

This paper focuses on how to transfer pre-trained representations to other tasks in the visual space. They propose a recipe called Big Transfer (BiT) and achieve very strong performance on ILSVRC-2012 (87.5% top-1 accuracy), CIFAR-10 (99.4%), and the Visual Task Adaptation Benchmark (VTAB; 76.3%).


scale blog ml papers B_05

Scale blog ml papers B_05

BiT has two phases: upstream and downstream. In upstream pre-training, the authors first investigate the scale of computational budget and how that affects performance. Secondly, they look at ground normalization and weight standardization, which helps significantly with small-batch and large-batch training alike. In downstream transfer, the authors propose a cheap fine-tuning methodology by using the BiT-HyperRule to select the most important hyperparameters for tuning as a function of the task’s intrinsic image resolution and number of datapoints. The hyperparameters they thought were important were training schedule length, resolution, and whether to use MixUp regularization.

There are a few takeaways from this method we found interesting. There’s a lot of value in balancing the computational budget and simplifying the experimental pipeline when needed. The BiT-HyperRule focusing on only a few hyperparameters was illuminating. We were interested in the dynamics of how large batches, group normalization, and weight standardization interplayed and were surprised at how poorly batch normalization performed relative to group normalization and weight standardization for large batches. The empirical strength of group normalization and weight standardization surprised us as well and we will start exploring these techniques in some of our computer vision models with lots of data available. However, the most impressive part was the empirical few-shot learning performance relative to the baseline. We are trying to build models that quickly adapt to new customers and domains and often struggle with fine-tuning, so these ideas are very top of mind.

### [Learning Loss for Active Learning](https://arxiv.org/abs/1905.03677)
__Presenter__: [Rishab Goyal](https://www.linkedin.com/in/rishgoyell/)

The authors present an active learning method that is a task-agnostic by attaching a loss prediction module to a target network and train it to be able to predict target losses of unlabeled inputs. The module can then provide insight into data that the model could predict incorrectly and thus improve the overall model by choosing just those examples to go and label.

scale blog ml papers B_06

Scale blog ml papers B_06

Their general process is that for every labeled example you predict the target and predicted loss for your prediction. Next, you take the unlabeled pool and pass them through the model to get predicted losses. Lastly you annotate the top-k data points and add them to the labeled training set. The loss prediction module uses a ranking loss.

As a data labeling company, we are very interested in active learning and how we can leverage our own strengths to better build ML models. We really liked the approach because it is widely applicable, but were concerned that there could be many degenerate cases. We weren’t convinced that the loss prediction module would be strong enough to offer significant improvements over uncertainty or coverage based methods such as entropy, query-by-committee, and coreset based methods.

### [LayoutLM: Pre-training of Text and Layout for Document Image Understanding](https://arxiv.org/pdf/1912.13318v5.pdf)
__Presenter__: [Malcolm Greaves](https://www.linkedin.com/in/malcolm-greaves/)

The authors try and solve the problem of automated understanding from scanned business documents. They use both computer vision and natural language processing techniques via textual and visual layout information for pre-training their system. Their system achieves SOTA on a set of layout analysis, receipt understanding, and document image classification tasks. They claim that their empirical performance is from their novel loss functions: a masked visual-language model (MVLM) loss and a multi-label document classification (MDC) loss.


scale blog ml papers B_07

Scale blog ml papers B_07

MVLM extends the masked language model loss from BERT by randomly choosing some words to mask. They then keep the masked token’s 2D positional embedding and forces the model to predict the word’s text. MVLM forces the model to understand language context and 2D relationships between words in the document. MDC assumes that documents have possibly several labels and is a standard cross-entropy loss. This is optional and seems to help on the document image classification tasks.

We found this paper interesting, but computationally demanding: alongside their loss functions, a key contribution of this paper is their pre-training routine. Without significant pre-training, these models do not seem to work well. This work requires off-the-shelf OCR and treats that as ground truth, which simplifies the work, but makes it less practical for document analysis practitioners. For the business document tasks that our ML team takes on, we often like to have greater control on the OCR task. It's sometimes advantageous to be able to adjust OCR to provide better downstream task-dependent results. We do a lot of document analysis at Scale, but can’t obfuscate or explain away the OCR component, which do produce some errors (e.g. with handwriting). Although this approach needs word-level annotations, Scale is in a unique position to get large amounts of these labor-intensive labels using our labeling platform.

### [Simplifying Models with Unlabeled Output Data](https://arxiv.org/abs/2006.16205v1)
__Presenter__: [Alexandre Matton](https://www.linkedin.com/in/alexandre-matton-73042b170/)

This paper focuses on tasks whose outputs have to obey some constraints. This happens in pseudo-code to code transcription for example. What we ultimately want is a code that compiles and runs without error. The usual way to address these tasks is to build a single end-to-end model and hope that it will learn the input-output mapping and understand the output constraints. The authors provide a new way to tackle these tasks by replacing the original model by two sub-models: a base predictor and a denoiser. The goal of the base predictor is to learn the mapping between the input and the output. The goal of the denoiser is to learn the constraints of the output space, in order to fix the base predictor’s output. 

scale blog ml papers B_08

Scale blog ml papers B_08

There is a reason why this decomposition works well. As the denoiser simplifies the job of the base predictor, it is now possible to increase the regularization of the base predictor without affecting the overall model performance. This in turn leads to solutions that generalize better on unseen data. The big win of this architecture is that the denoiser can be trained on unlabelled output data, which is often abundant (e.g. there is a huge amount of compiling code pieces freely available on github).

A big number of tasks actually impose constraints on the output (such as molecule generation, or translation from one language to another). At Scale, our ML team also tackles such problems. This paper provides a very general way to increase our downstream scores on them.

### Join our Team
If you’re interested in joining our growing engineering team, take a look at our [careers page](https://scale.com/careers) for open positions.


The machine learning research papers the Scale AI team read and discussed in Q3 2020.

Research Papers the Scale AI Team has Read in Q3 2020

Scale AI Machine Learning Digest - Q3 2020

Scale Team

At Scale AI, we envision a future where AI is as easy to build as any software. To help AI achieve its full potential, we are building the tools that make it easier to build and scale real-world AI systems. We began by focusing on the data - the foundation of all AI applications. With the Scale AI platform, customers can understand, visualize, and curate raw datasets, send raw data to be annotated, then debug model performance - all in one place.
From the beginning, we knew the Scale AI platform had to be API-based to enable teams working on AI and ML to automate their data pipelines and seamlessly integrate Scale into ML development cycles. Since our start in 2016, our engineering team has built incredible products to deliver large volumes of training data at high-quality, whether the data input is 3D sensor data, video, image, document, or text. Despite the continued evolution of our products and the robustness of our APIs, until recently, the API documentation itself was static, with limited interactions and not a lot of details to fully understand our products, set up effective workflows, and optimize for quality.
<h2 id="the-evolution-of-our-documentation%3A">The Evolution of our Documentation:</h2>
If you are a long-time Scale customer, you are probably familiar with this as our API documentation:

A screenshot of Scale's original API Documentation

Original API Documentation

Scale AI's Original API Documentation

The early documentation simply served as an API reference guide. The parameters were well spaced out, included relevant examples, and showed some example code using our SDKs. 

As we expanded the documentation to include content on key concepts, the customer dashboard, and other elements of the Scale AI platform, the documentation became increasingly clunky and awkward to navigate. The early documentation was also very static, with limited interactions, no search capability, and overall proved to be a less than ideal user experience. 

### Transition to ReadMe
Earlier this year, our Customer Experience and Field Engineering team identified [ReadMe](https://readme.com/) as an industry-leading documentation platform that could scale with our evolving needs. 

With ReadMe, we were able to realize three tangible benefits:

1. Unify the API reference and the Customer Dashboard documentation into a unified website.
2. Improve the developer experience. Instead of only showing static code examples, ReadMe enables developers to submit API requests directly with their Scale API key. ReadMe also has built in search functionality to make it easier for developers to find specific topics. 
3. Democratize the content creation process.  Instead of editing raw markdown, making a pull request, and then deploying to a server, we just had to update the text we needed in the ReadMe UI. Ultimately, the ReadMe platform provided a richer and more dynamic user experience.

The only limitation of the ReadMe platform out-of-the-box was the lack of front-end customization to ensure visual consistency between the documentation and the rest of our website. 

### Latest State:
The latest update to our documentation marries the content and functionality of ReadMe with our front-end to provide a better and more consistent experience between our API documentation and the rest of our platform. 

Newest State of API Documentation

Latest State of API Documentation

We accomplished this by effectively leveraging ReadMe as a content management system (CMS) on the back end. We then used [Tailwind CSS](https://tailwindcss.com/), a utility-first framework to build the UI for the front end, and [Next.JS](https://nextjs.org/)’s static generation feature to pre-render the page into HTML on the server ahead of each request. The HTML can be globally cached by a CDN and served instantly. Technical details on how we implemented this will follow in another blog post. 

## New Features:
### In-depth Customer Dashboard Documentation
As a Scale AI customer, the Dashboard is the central location to manage your account and your projects. The new in-depth Customer Dashboard documentation walks you through how to manage your account,  your projects, get an overview of submitted and completed tasks, and audit a random sample of tasks for quality.  

### Scale 101 Workflow Overviews
Every institution, company, and even team has their own ways of describing the data labeling workflow. To ensure every customer is successful on the Scale AI platform, we introduce the terminology we’ve developed in this section.  

Scale 101: Key Concepts

### Make API calls using your Scale API key directly from the Documentation
Instead of static code examples, this feature enables developers to submit live API requests directly using their Scale API key. 

API Key

### Search
As we continue to expand the documentation, we realize it can also become more challenging to navigate to and find details on a specific topic. To offer a faster and easier way to find keywords or key phrases, we have added a new search feature in our documentation powered by Algolia.    

Search Functionality

### Dark Mode
Dark mode reduces the light emitted by device screens while maintaining the minimum color contrast ratios required for optimal readability. To view the API documentation in dark mode, select “Dark” in your computer’s display settings or “Auto” to switch from light mode to dark mode at sunset or at a specified time. 

Light Mode/Dark Mode

## What this Means:
If you are an existing Scale customer, rest assured that the updates to the documentation do not impact any existing projects, batches, tasks, or workflows. If anything, we hope these updates will clarify the expected behavior, showcase our API’s flexibility, and enable easier task creation with more effective instructions to improve the overall quality of returned tasks. 

If you are just getting to know our products, we hope the updated documentation inspires you to come up with new project ideas. 

Introducing a new look and new features for our API Documentation

Introducing Scale AI's updated API Documentation

Introducing: Our New API Docs

Patrick Liu

At Scale AI, customers come first. This is a core credo that drives many of our daily decisions. We take the trust of our customers and the security of their data seriously, which is why we are pleased to announce the availability of our System and Organizational Controls (SOC) 2 Type 1 report.
As a cloud-based data annotation provider, our customers need to be confident that we securely handle their data. SOC reports are prepared by independent Certified Public Accountant (CPA) auditors based on the internationally recognized <a href="https://www.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/trust-services-criteria.pdf" target="_blank">Trust Services Criteria</a> framework developed by the American Institute of Certified Public Accountants (<a href="https://www.aicpa.org/" target="_blank">AICPA</a>). Achieving compliance with SOC 2 requires Scale demonstrating the achievement of their service commitments and system requirements based on the Security Trust Services Category. We take our commitments to security and the responsibilities they entail seriously, which is why we have partnered with CPA firm Schellman &amp; Company, LLC to provide ourselves and, most importantly, our customers with independent, third-party validation of our processes and controls to keep our systems and customer data safe.
Our commitment to enterprise-grade security is one reason leading ML teams such as NVIDIA, Toyota Research Institute, Open AI, and more rely on Scale AI to accelerate the development of their AI applications. Scale continues to invest in security best practices, and to that end, we are pursuing a Type 2 report moving forward. If you’d like further details on our SOC 2 report, please contact us at <a href="mailto:security@scale.com" target="_blank">security@scale.com</a> or <a href="mailto:sales@scale.com" target="_blank">sales@scale.com</a>.

At Scale AI, we take the trust of our customers and the security of their data seriously. We are pleased to announce the availability of our SOC 2 report. 

Reaffirming Our Commitment to Building Customer Trust: Scale+ SOC 2

Reaffirming Our Commitment to Building Customer Trust: Scale + SOC 2

When we founded Scale in 2016, we envisioned a future where AI was as easy to build as any other software. Four years on, we’ve seen incredible success bringing that vision to life for a huge range of businesses across self-driving, natural language, ecommerce, robotics, and many other fields. As we continue to develop our ambitious roadmap to accelerate AI development, I’m delighted to welcome Brad Porter—formerly Amazon’s VP and Distinguished Engineer of Robotics—as our first CTO.
<h3 id="our-vision-for-scale">Our vision for Scale</h3>
I got hooked on machine learning from a young age. As a student, I’d build models in my free time that predicted how hard it would be to find parking outside my house, or whether I needed to restock my fridge on the way home.
The beauty of AI systems is their flexibility—define a goal, and they learn an optimal process themselves. But I soon realized that AI is much harder to deploy than it should be. It was incredibly cumbersome to find enough data to train my models. And when I moved, my parking model needed retraining—so I had to find more data all over again.
Other fields of software, like app development, have an entire ecosystem of support tools that streamline development, abstracting away complexity and automating basic workflows.
You don’t need a PhD to build a website. What if the same was true for AI?
<h3 id="building-the-technology-stack-for-ai-development">Building the technology stack for AI development</h3>
Brad and I first met a year ago. I had made it a point to get to know all of the people out there who were doing production AI in meaningful ways. Brad, leading robotics at Amazon, was at the top of the list.
Brad is a very humble guy. It is striking when you meet him. Many technology leaders have a bit of show and flair to them, but Brad immediately reminded me of the kind of leader that I strive to be: exceedingly humble, extremely technical, excited by ideas (both good and bad), and insatiably curious to understand how things work. As we were getting to know each other, he told me that he’s been in love with things that can fly since he was a kid: paper airplanes, kites, boomerangs, radio-controlled planes, flying soda cans, and more. As a kid who was personally obsessed with math and physics out of an intrinsic curiosity for the world, I realized Brad and I had a lot in common.
When we were talking about successful teams, I quickly realized I had a lot to learn from Brad. One core tenet of our work at Scale is our belief that ambition shapes reality. It is something we try to live every day. Unprompted, in one of my email correspondences with Brad, he wrote: “One thing all startups need is ambition. In my experience, ambition is the greatest limiter.”
Brad has a reputation as an incredible leader. One indication is former teammates who are fiercely loyal and incredibly effusive. Every person I have spoken to who has worked with Brad, either at Netscape, Tellme, or Amazon, could not stop raving about him. The same themes continued to pop up—humble, compassionate, dedicated to his teams, curious, and deeply technical.
Then, there’s all of Brad’s technical accomplishments! More than almost anyone, Brad knows what it takes to productionize AI systems and deploy them at global scale in complex, changing environments. With his experience leading robotics at Amazon, he managed one of the most impressive uses of machine learning at scale—the over 200,000 robots powering Amazon’s unrivaled global warehouse and distribution infrastructure. He also has deep expertise in natural language, working with AI and language scientists at Tellme Networks to accelerate the rollout of speech recognition, processing and dialog management technologies. I’m thrilled he has decided to join us.
Brad and I both agree that getting effective, accurate and unbiased data is currently the hardest problem in machine learning. At Scale, we’ve built tools to eliminate those frictions. We’ve built an API that integrates seamlessly with our customers’ workflows, and our own ML models automate much of the annotation process and help ensure we deliver ground-truth data of the highest quality.
As our CTO, Brad will help continue to improve the efficiency and sophistication of our technologies and processes by orders of magnitude, building new tools to continue to accelerate the development of AI systems. He will manage our entire technology stack, with combined ownership of product direction and engineering, to turbocharge our ambitious technology roadmap.
Brad understands first hand the need for better tools that will become the backbone of AI development. Under his leadership, we’ll be able to accelerate our development of tools that can support the AI development lifecycle—building the full development stack for AI.
<h3 id="scale%E2%80%99s-network-effects-and-future-of-ai">Scale’s network effects and future of AI</h3>
Right now, AI is at a crossroads. With systems like AlexNet, AlphaGo and GPT-3, AI research has made incredible strides. But demand for data annotation is far outstripping the supply of skilled labelers. And the data to be annotated is only getting more complex as AI models become more sophisticated.
With data bottlenecks persisting, the delta between what AI could do in theory and in practice is only growing. The field desperately needs better technology to overcome these barriers.
But a new era of AI has begun. AI is about to enter a wave of productionization. The industrialization of AI—with global spending on AI systems <a href="https://www.businesswire.com/news/home/20180919005045/en/Worldwide-Spending-Cognitive-Artificial-Intelligence-Systems-Forecast" target="_blank">predicted</a> to triple between 2018-2022—is beginning to take shape.
What’s holding it back is a lack of infrastructure. I believe Scale will play a major role shaping that future. Thanks to our own machine learning technologies, our data annotation products become more sophisticated with every annotation instance they encounter. That provides powerful network effects that benefit all our customers. As we grow, the impact on the deployment of AI will be transformative.
I look forward to working with Brad as he helps drive our progress on that journey.
If you’d like to join Brad’s engineering team, you can find all our open roles on our <a href="https://scale.com/careers" target="_blank">careers page</a>.

Brad Porter—formerly Amazon’s VP and Distinguished Engineer of Robotics—joins Scale AI as our first CTO

Scale AI welcomes Brad Porter as our first CTO

Welcoming Brad Porter to Scale AI as our first CTO

Nivedita Suresh

<h2 id="ai%2Fml-research-at-scale-ai%3A">AI/ML Research at Scale AI:</h2>
Scale AI is dedicated to accelerating the development of AI applications. As part of this mission, Scale AI’s growing AI/ML Team aims to meaningfully contribute to the AI ecosystem with research and resources that can bring significant and practical benefits to our customers and the broader research community.
Research and experimentation happens throughout Scale. In some cases, our contribution is in areas where the bar has already been set high. Some examples include the open-source datasets we have released with various partners such as <a href="https://pandaset.org/" target="_blank">PandaSet</a>, <a href="https://www.nuscenes.org/" target="_blank">nuScenes</a>, and <a href="https://scale.com/resources/download/nlp-dataset-balanced-conll" target="_blank">CoNLL Balanced</a>. As our AI/ML team continues to grow, we aim to contribute in entirely new spaces by publishing cutting edge research papers. In this blog post, we spotlight a research paper we recently submitted.
The research paper was a collaboration with <a href="https://www.linkedin.com/in/nivedita-suresh/" target="_blank">Nivedita Suresh</a> of Arrive. <a href="https://arriveorigin.com/" target="_blank">Arrive</a> links multi-omics and AI cell characterization to discover hidden patterns in data and improve outcomes in precision medicine.
<h2 id="conditioning-unconditional-language-models-to-recover-sentences-without-fine-tuning%3A">Conditioning Unconditional Language Models to Recover Sentences without Fine-Tuning:</h2>
Pretrained language models are used as encoders with widespread success for a wide variety of NLP tasks. These models learn useful representations that can be directly applied to certain tasks. Despite the success of these models on the encoder, there isn’t much research out today on whether these large pretrained language models can be used as universal decoders. To be considered “universal,” a decoder must have an implicit representation for any sentence, such that it can recover that sentence exactly when conditioned on its representation.
Task-specific decoders are typically trained from scratch for each task. In this research, we propose a method to try and learn useful representations of sentences using large, pretrained, transformer-based decoders. Our work investigates whether a universal decoder is even possible. If we had access to such a decoder, we could use it for a wide variety of sequence generation tasks without having to retrain or rebuild the decoder on new data. This could open up a new paradigm for low-resource machine translation, summarization, image captioning, and dialog generation.
<h2 id="the-sentence-space%3A-how-language-models-represent-sentences">The Sentence Space: How Language Models Represent Sentences</h2>
Transformer-based language models like ELMo, BERT, and GPT-2 have replaced word vectors as off-the-shelf general-purpose encoders for natural language understanding. These models are trained on large amounts of text data and represent a sentence as a sequence of hidden states that come from a final layer of the transformer model. Representations in this sentence space are sequence length dependent, making comparisons between sentences with differing lengths inequitable and measuring the efficacy of using an unconditional language model as a universal decoder impossible.
To resolve these issues and to make analysis easier, we propose to reparametrize the original sentence space into a lower-dimensional and sentence length agnostic vector space. We do this by adding a bias term to the fixed language model and finding the representation that minimizes the cross entropy loss of the sentence. This reparameterization now gives us the ability to project sentence tokens to representations (sentence encoding) and recover sentences from the representation (sentence recovery) via the fixed language model. We develop three representation injection mechanisms and inject biases at three different locations.

Figure 1

Sentence space representations of transformer-based language models.

## Experiments:
Since we are testing the efficacy of a large pretrained language model as a universal decoder, we measure how well a representation can recover a sentence when injected into a language model. We measure performance across sentences from 4 different genres: books, news articles, Wikipedia, and movie dialogs. We conduct controlled experiments, varying the representation injection mechanism, representation injection location, initialization, and dimensionality of the representation.

## Results:
We find that our representations recover sentences nearly perfectly even across genres -- achieving a BLEU score of over 98.


BLEU performance on LRC stratified by genre for different dimensionalities of z.

Figure 5: BLEU performance

BLEU Scores

In addition, we observe that the intrinsic dimension of the representation space is the model’s latent dimension, which indicates that the language model uses its entire capacity to represent sentences.

Plot of sentence length vs. BLEU score on LRC for experiment IV with error regions.

BLEU

Sentence length v. BLEU score

Additionally, our interpolation experiments reveal that the representation space has some human-understandable meaning. Our learned representations seem to have some synonym awareness. In the first sentence pair example below, the word “tale” transforms to the word “story” and the word “long” transforms to “long-running” when referring to a war. In the second example, we observe some syntactic awareness at the 0.7 mixture level. The syntax of the first sentence is retained with mostly words from the second sentence. 

Interpolation

Linear interpolations between perfectly recovered pairs.

## Broader Impact:
This work informs us that we can discover meaningful, sentence-length agnostic sentence representations, hinting at the possibility of a “universal” decoder. Such a decoder would improve low-resource sequence generation task performance and allow for considerable parameter sharing in memory and data-limited environments.

## Conclusion:
For further details on how we set up the experiment, results, and analysis, you can find the full paper on [arXiv](https://arxiv.org/abs/2008.09049). If you’re interested in joining our growing machine learning team, you can find all of the open positions on our [careers page](https://scale.com/careers?location=All&team=Engineering). 

Learning useful sentence representations from large transformer-based language models.

Discovering Useful Sentence Representations from Large Pre-trained Language Models

Discovering Useful Sentence Representations from Large Pre-Trained Language Models

James Lennon

<h2 id="introduction">Introduction</h2>
Machine learning is a once-in-a-generation technological shift that is creating huge value by unlocking insights from data. But algorithmic bias remains a major concern as ML becomes more widespread. Unless ML models are trained on representative data, they can develop serious biases, significantly harming underrepresented groups and leading to ineffective products. We investigated the CoNLL-2003 dataset—a standard for building algorithms that recognize named entities in text—and found that the data is highly skewed toward male names. Using Scale’s technology we were able to systematically mitigate this bias by:
<ol>
<li>Enriching the data to illuminate the hidden biases</li>
<li>Enhancing the dataset with underrepresented examples to mitigate gender bias</li>
</ol>
A model trained on our enhanced CoNLL-2003 dataset has both less bias and better performance—demonstrating how bias can be removed without any changes to the model. We’ve open-sourced the Named Entity Recognition annotations for the original CoNLL-2003 dataset and our augmentation of it <a href="https://scale.com/resources/download/nlp-dataset-balanced-conll" target="_blank">here</a>.
<h2 id="algorithmic-bias%3A-ai%E2%80%99s-weakness">Algorithmic bias: AI’s weakness</h2>
Today, thousands of engineers and researchers are building systems that teach themselves how to achieve significant breakthroughs—improving road safety with self-driving cars, curing diseases with AI-optimized treatments, and combating climate change by managing energy usage.
But the power of self-learning systems is also their weakness. Because data is the foundation of all machine learning applications, learning from imperfect data can lead to biased outputs.
The power of AI systems means their potential to cause harm if they are biased is significant. Recent protests against the police brutality that has led to the tragic deaths of George Floyd, Breonna Taylor, Philando Castile, Sandra Bland and many others are an essential reminder of the systemic inequalities in our society that AI systems must not perpetuate. But, as we know from countless examples—whether it’s image search results <a href="http://www.mjskay.com/papers/chi_2015_gender-bias-in-image-search.pdf" target="_blank">perpetuating gender stereotypes</a>, offender management systems <a href="https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing" target="_blank">discriminating against black defendants</a>, or facial recognition systems <a href="https://www.nist.gov/news-events/news/2019/12/nist-study-evaluates-effects-race-age-sex-face-recognition-software" target="_blank">misidentifying people of color</a> – we have a long way to go before we can say the problem of AI bias has been solved.
Bias is prevalent because it is so easily introduced. It creeps up, for example, in gold-standard open-sourced models and datasets that are the foundation of huge volumes of work in ML. The word2vec sentiment dataset for building other language models is <a href="https://blog.conceptnet.io/posts/2017/how-to-make-a-racist-ai-without-really-trying/" target="_blank">skewed by ethnicity</a>, and word embeddings—the way an ML algorithm represents words and their meanings—have been found to contain <a href="https://arxiv.org/pdf/1608.07187.pdf" target="_blank">strongly biased assumptions</a> about what occupations women are associated with.
The problem—and at least part of the solution—lie in data. To illustrate this, we’ve conducted an experiment into one of the most popular datasets for building systems that can recognize named entities in text: CoNLL-2003.
<h2 id="what-is-named-entity-recognition%3F">What is Named Entity Recognition?</h2>
Named-Entity Recognition (NER) is one of the fundamental building blocks of natural language models—without it, online searches, information extraction, and sentiment analysis would be impossible.
At Scale AI, our mission is to accelerate the development of AI. Natural language is one of our main areas of focus. Our Scale Text offering includes NER—which involves annotating text according to a predefined list of labels. In practice, this might help major retailers analyze how their products are being discussed online, among other applications.
Many NER systems are trained and <a href="https://paperswithcode.com/sota/named-entity-recognition-ner-on-conll-2003" target="_blank">benchmarked</a> on CoNLL-2003—a dataset of roughly 20,000 sentences from Reuters news articles that are annotated with attributes such as ‘PERSON’, ‘LOCATION’, and ‘ORGANIZATION’.
We wanted to explore if the data was biased. To do this, we used our Scale AI labeling pipeline to categorize all the names in the dataset, asking whether they could be male, female, or either, inferring gender based on the traditional use of the name.
We found a dramatic difference. Male names are mentioned almost five times more than female names, and less than 2% of names were gender-neutral:
<figure class="expand-image">
 <img src="//images.ctfassets.net/1qgw036lpkfx/23DTaOdXIuKthLUAEG4Pdg/335f2763d6373c91cf113a60bd100282/chart-2.svg" />
</figure>
This is because news articles, for societal reasons, tend to contain mostly male names. But an NER model trained on this data will be better at picking out male names than female. For example, search engines use NER models to help classify names in search queries to give more accurate results. But deploy a biased NER model, and the search engine will be worse at identifying names of women than of men—exactly the kind of subtle, pervasive bias that can creep into many real-world systems.
<h2 id="a-novel-experiment-to-reduce-bias">A novel experiment to reduce bias</h2>
To illustrate this, we trained an NER model to investigate how this gender bias would affect its performance. We built a name extraction algorithm to pick out PERSON labels using <a href="https://spacy.io/" target="_blank">spaCy</a>, a popular NLP library, and trained the model on a subset of the CoNLL data. When we tested the model on novel names in the test data that weren’t present in the training data, we found that the model was 5% more likely to miss a new female name than a new male name—a significant discrepancy in performance:
<figure class="expand-image">
 <img src="//images.ctfassets.net/1qgw036lpkfx/2ZYmbgILyiKAI4tjSgIDph/9d431f098a830c0c3c0df5b820ab0b1b/chart-3.svg" />
</figure>
We saw similar results when we used our model on the template “NAME is a person”, substituting the 100 most popular male and female names for each year of the US census—the model performs significantly worse on female names for all years of the census:
<figure class="expand-image">
 <img src="//images.ctfassets.net/1qgw036lpkfx/lsDqk1QgcCnL2vt1jxbdO/fce68bdac2e729f28e97392e8ca31a8e/chart-4.svg" />
</figure>
Crucially, biased training data means errors are skewed toward underrepresented categories. This census experiment illustrates this a second way, too: the model’s performance degrades significantly after 1997—the cut-off point of the Reuters articles in the CoNLL dataset—because the dataset is not representative of the popularity of names in the years since.
Models learn to fit the trends of the data they are trained on. They can’t be expected to perform well on cases for which they have seen few examples.
<h2 id="if-you%E2%80%99re-de-biasing-the-model%2C-it%E2%80%99s-too-late">If you’re de-biasing the model, it’s too late</h2>
So how do we fix this?
One way is to try and de-bias the model—perhaps by post-processing the model, or adding an objective function to mitigate bias, leaving it to our model to figure out the details.
But there are several reasons why this is not the best approach:
<ol>
<li>Fairness is a highly complex issue that we can’t expect an algorithm to define on its own. Research has shown that training an algorithm to perform equally on all subsets of the population will not ensure fairness and will <a href="http://blog.mrtz.org/2016/09/06/approaching-fairness.html" target="_blank">cripple the model’s learning</a>.</li>
<li>Adding extra objective functions can hurt model accuracy, causing a tradeoff. Better instead to keep the algorithm simpler and ensure the data is balanced—improving model performance and avoiding the tradeoff.</li>
<li>It’s unreasonable to expect a model to perform well on cases for which it’s seen few examples. The best way to ensure good results is to improve the diversity of the data.</li>
<li>Attempting to de-bias a model with engineering techniques is expensive and time-consuming. It’s much cheaper and easier to train your models on unbiased data in the first place, freeing up your engineers to focus on applications.</li>
</ol>
Data is only one part of the bias problem. But it is foundational, affecting everything that comes after it. That’s why we think it holds the key to some of the solution, providing potential systematic fixes at the source. Unless you explicitly label for protected classes, like gender or ethnicity, it is impossible to properly mitigate these classes as a source of bias.
This is counterintuitive. Surely, if you want to build a model that doesn’t depend on sensitive characteristics, like gender, age or ethnicity, it’s best to omit those properties from the training data so the model can’t take them into account?
“Fairness by ignorance” actually makes the problem worse. ML models excel at drawing inferences across features—they don’t stop doing this just because we haven’t explicitly labeled those features. The biases simply remain undetected, making them harder to remove.
The only robust way to deal with the problem is to label more data to balance out the distribution of names. We used a separate ML model to identify sentences in the <a href="http://kdd.ics.uci.edu/databases/reuters21578/reuters21578.html" target="_blank">Reuters</a> and <a href="https://archive.org/details/BrownCorpus" target="_blank">Brown</a> corpora likely to contain female names, and then labeled those sentences via our NER pipeline to augment CoNLL.
The resulting dataset, which we’ve called CoNLL-Balanced, has over 400 more female names. When we retrained our NER model on it, we found that our algorithm is no longer biased to perform worse on female names:
<figure class="expand-image">
 <img src="//images.ctfassets.net/1qgw036lpkfx/4vOWZTzsDU7MxxK870EiE1/e685239cfbc507405d64072f466ebbee/chart-9.svg" />
</figure>
Not only that, but the model also performed better at identifying male names, as well.
This is an impressive demonstration of the power of data. Mitigating bias at the source meant we did not have to make any adjustments to our ML model—saving engineering time. And we achieved this without any tradeoff in our model’s performance—in fact, its performance slightly improved.
<figure class="expand-image">
 <img src="//images.ctfassets.net/1qgw036lpkfx/3vc17brFOvBpwmPxJvThR/d74fe758f2a81a30db5458ba8bb7bd4d/image__14_.png" />
</figure>
To allow the community to build on our work and mitigate gender bias in models built on CoNLL-2003, we’ve open-sourced Scale AI’s augmented dataset, which also includes gender information on <a href="https://scale.com/resources/download/nlp-dataset-balanced-conll" target="_blank">our website</a>.
The AI/ML community has its own diversity problems, but we are cautiously excited by these results. It suggests how we might be able to offer a technical solution to a pressing social problem—provided we tackle the issue head on, illuminating the hidden biases and improving the model’s performance for everyone.
We’re now exploring how we might apply this approach to another highly sensitive attribute—ethnicity—to explore whether we can create a robust framework for eliminating dataset bias that scales to other protected classes.
It also illustrates why we at Scale AI pay so much attention to data quality. Unless data is provably accurate, balanced, and unbiased, there’s no guarantee that models built on it will be safe and accurate. And without that, we won’t be able to build the transformational AI technologies that benefit everyone. If you are developing AI technologies and would like help in balancing your own datasets to ensure your models work for everyone, <a href="https://scale.com/sales" target="_blank">reach out to us</a>.
Acknowledgements:
The CoNLL 2003 Dataset referenced in this blog post is the Reuters-21578, Distribution 1.0 test collection, available on the project page for the original 2003 experiment: <a href="https://www.clips.uantwerpen.be/conll2003/ner" target="_blank">https://www.clips.uantwerpen.be/conll2003/ner/</a>.

Scale AI's platform can help mitigate bias before training a model.

The importance of detecting and mitigating bias from training data before even starting to build an algorithm.

If You’re De-Biasing The Model, It’s Too Late

We founded Scale to create the infrastructure needed to build AI in any industry, by anyone. We started tackling this complex problem at the root — turning raw data into high quality training data for models. In this pursuit, we spent the last four years building ML-augmented annotation products for all data types, expanding our solutions for major industries, and making significant technological strides in <a href="https://scale.com/blog/how-we-scale-machine-learning" target="_blank">scaling our use of ML</a> in doing so.
But the problem of building effective, accurate, unbiased ML models still remains. To do this, aggregate metrics in ML are not good enough. Better ML starts with understanding your data in depth. To improve production ML, you need to understand their qualitative failure modes, fix them by gathering the right data, and curate diverse scenarios.
<ol>
<li>Before training a model, ML engineers must curate and sample their data, ensuring that they have the right data to solve a specific problem. This process is too often very manual. For example, to teach a self-driving car how to handle left turns, an ML team has to manually crawl through their driving sequences to isolate examples of left turns to create a training dataset. The data also needs to be representative of the ground truth of the problem you’re trying to solve. If you’re building a model to assign a gender to faces, you have to ensure representative data for all genders to have unbiased outputs. Again, that’s too often a manual and highly inefficient process.</li>
<li>After training, ML teams test and benchmark model performance, ensuring that the test dataset is also sufficiently representative of the problem they are trying to assess its performance against. For example, a model learning how to tell cars apart from pedestrians needs enough of both examples for accurate benchmarking. This requires ML engineers to spend significant amounts of time building one-off UIs to chart and share performance data.</li>
<li>After deployment, debugging the model, identifying failure modes and fixing them. Too often issues in data only arise after a model has entered deployment – requiring time-consuming debugging. One Scale customer, for example, found that their vehicle recognition algorithm didn’t perform well in certain environments – it turned out that the model was trained on a dataset where vehicles were mostly in the bottom of the image, so the model associated “bottom of the image” with “likelihood of being a car.”</li>
</ol>
The Scale team has been working to productize the concept that Andrej Karpathy calls “<a href="https://www.youtube.com/watch?v=oBklltKXtDE&amp;feature=youtu.be&amp;t=475s" target="_blank">Operation Vacation</a>.” Nucleus is a new way—the right way—to develop ML models, helping us move away from the concept of one dataset and towards a paradigm of collections of scenarios and giving ML engineers the ability to automate time-consuming manual steps in the ML development process. 
<img src="//images.ctfassets.net/1qgw036lpkfx/01d1iYza6qIJQco0C6bIi0/e4f6510aa29f322f975b2c4cfc0c2dc1/dev_cycle_diagram_03.svg" alt="ML Development Cycle">

[Scale Nucleus](https://scale.com/nucleus) provides advanced tooling for understanding, visualizing, curating, and collaborating on your data – allowing teams to build better ML models via a powerful interface and APIs. With Scale Nucleus, you can:
- __Visualize your dataset__, ground truth, and model predictions to improve model performance
- __Curate interesting slices within your dataset__ for active learning and identifying key edge cases
- __Upload and choose data to be annotated__ for rare event mining and dataset balancing
- __Search your data__ based on metadata or ML-produced attributes
- __Identify edge cases__ through visual search
- __Measure key metrics__ like dataset balance, class correlation, and confusion, via a powerful insights tab that shows the overall health of the data
- __Debug__ model performance
- __Share your dataset__ seamlessly to provide a single source of truth for data within your team.

pandaset - query

Scale Nucleus Query

Scale Nucleus is directly integrated with Scale AI’s data labeling pipeline – allowing teams to fix any issues in their data at the source. Nucleus currently supports Image data, with support for 3D Sensor Fusion, Video, Text and Document data coming soon.

We built Scale Nucleus to allow data scientists and ML engineers to manage data more efficiently and increase the marginal value of their data. Deeper insight into a dataset’s features can have several transformational effects on the development of AI:

- For engineers, the easier visualization and curation of datasets lowers the barriers to entry to building ML systems.
- Spotting hidden modes of failure in datasets before deployment (such as a set of driving sequences that doesn’t include any sequences at night) makes it much easier to train high-quality models, and provides a robust way of eliminating issues like bias at source.
- The ease of debugging could significantly improve iteration speed on model fine-tuning post-deployment. 

We are excited to take the next step in building the infrastructure to enable efficient, accurate, and unbiased ML development. If you’d like to join us in this journey and try Scale Nucleus, contact us at nucleus@scale.com or sign up on our [website](https://scale.com/nucleus#sales). 


Scale Nucleus: The mission control for your data

Introducing Scale AI's latest product: Scale Nucleus

Introducing: Scale Nucleus

June Lee

Fostering connection when everyone is remote can be tricky. Wind back to four months ago-- it was easy to high five a coworker, give surprise birthday cakes outside of meeting rooms, and hop down to the juice shop downstairs for a walk and talk. Shelter-in-place restrictions pose new challenges that inspired our people team to think of creative ways to keep the team connected.
Our initiatives centered around the following dimensions:
<ul>
<li>Social Connection - How do we facilitate interaction between people across different teams and departments?</li>
<li>Wellness - How do we encourage people to take care of themselves and remain mentally well during uncertain times?</li>
<li>Alignment - How can we keep teams aligned, engaged, and focused on company-wide goals and objectives?</li>
</ul>

The People Team's initiatives and how they map to social connection, wellness, and alignment.

People Team Initiatives

For the purpose of this blog post, we chose to highlight and share our social connection initiatives. We are happy to share these ideas with other companies looking to provide employee social support.

## Wellness Programs

The pandemic threw a curveball of new work environments, screen-focused social interactions, along with uncertainty around the current economy. To help our employees prioritize their health and well-being, we launched a wellness program. We created a space for our employees to participate together, foster camaraderie, and not feel alone in their personal wellness endeavors. 

### April Wellness Program: Building Healthy Habits

An example of our April Wellness Tracker.

April Wellness Tracker

__Details of the Program__ 
The program reminded employees to track key health criterias to build healthy habits. In a two-week span, participants recorded if they met the following criterias:
<ul>
 <li>7+ hours of sleep</li>
 <li>Drink 64 oz + of water</li>
 <li>20+ minutes of exercise</li>
 <li>10+ minutes of mindfulness</li>
</ul>

__Social Interaction__ 
We encouraged social interaction through a leaderboard, seeing how we stack rank against each other. We also had a slack channel dedicated to this challenge to share knowledge with each other and asking, “Does tea count towards our water intake?” We could also commiserate on the channel about how drinking a lot of water was difficult.

We ended the challenge with a virtual celebration highlighting winners for:
<ol>
 <li>Highest consecutive points</li>
 <li> Category leaders </li>
 <li> Week 2 leaders (to motivate late joiners) while celebrating everyone who participated</li>
 </ol>
Overall, the participation rate was 20 percent of the whole company.

[Gabby Zetino](https://www.linkedin.com/in/gabbyzetino/), our sales development representative, shares her experience with the challenge:

Quote from Sales Development Representative, Gabby Zetino, on participating in the April Wellness Challenge.

Gabby Zetino Quote

### May Wellness Program: Bingo Board and Scale Sponsored Events


May Wellness Program

May Wellness Challenge Tracker

__Details of the Program__
 
This month, in honor of Mental Health Awareness Month, we assembled a mental health bingo board which highlighted a list of activities employees can do at their own pace. If an employee completed ten of the activities, they were entered into a raffle. 

[Taisia Karaseva](https://www.linkedin.com/in/taisiakaraseva/), our Pilots & POC lead, shares how the bingo board pushed her to reflect on wellness habits along with the Scale-sponsored event:

Quote from Pilots & Proof of Concept Lead, Taisia Karaseva, on participating in the May Wellness Challenge.

Taisia Karaseva Quote

Shelter-in-place restrictions posed new challenges that inspired our people team to think of creative ways to keep the team connected.

Resources

The Learning Curve

The Learning Curve

The Learning Curve: What's New in Scale AI's Computer Vision APIs

Product

Getting Started with Nucleus

Get Labeled Data Today