How to Design a Neural Network

  • by
How to Design a Neural Network

How to Design a Neural Network – We will talk about how to design a neural network in 2020, covering some of the useful techniques that came out or popularized between 2018 and 2020. At the end of the video, I will also go through some of our recent papers and explain how my colleagues and I designed neural networks for constrained environments. Alright, let’s get started!

My first advice is still the same. You don’t really need to spend too much time trying to design a neural network. You can pick something that worked for a similar problem and use it. But what if your model needs to have some special properties that mainstream models don’t provide?

What if you have some unique concerns that others typically disregard or haven’t researched yet, such as minimizing the hardware footprint of a model or dealing with very large multispectral images. In many of those cases, you still don’t have to start from scratch.

There are many good practices and useful design patterns that you can use in your model architecture. That’s what we will be covering in this article. Let’s first talk about efficient model architectures. Despite the recent advances in automated network architecture search, hand-designed models are still relevant, especially when it comes to designing efficient models.

For example, the ShuffleNetV2 paper argues that automatically found network architectures are much slower in practice even when they require a smaller number of operations to run. Their paper reports that MobileNetV2, a hand-designed model, is much faster than the NasNet-A, which was a result of an automated network architecture search process. This is because the speed of a model depends not only on the number of floating-point operations but also on memory access costs and platform characteristics.

Keeping those in mind, the ShuffleNetV2 paper proposes some guidelines to design efficient model architectures, optimized for inference speed. One of their guidelines is based on the observation that equal channel width at both ends of a layer minimizes memory access costs. So it’s a good practice not to change the number of input and output channels too frequently.

Models that make use of bottlenecks and expand-and-contract modules such as SqueezeNet and MobileNet V2 violate this guideline. It doesn’t mean you should never use them, though. Speaking of bottlenecks, something I observed is that extremely narrow bottlenecks also hurt training stability. A few dead neurons and the entire model collapses. So, if you really need to use layers having very few filters, such as 8 or smaller, using linear activation instead of ReLU at the end of those layers would at least prevent dead neurons.

MobileNetV2 also does something similar by using ReLU activations at the expansion layers while keeping the bottlenecks linear. Another guideline is that network fragmentation reduces the degree of parallelism. Using a lot of small operations instead of a few large ones decreases efficiency since they are not very GPU-friendly, and they introduce extra overheads. This is a well-known phenomenon and is one of the reasons why some automatically designed models run slower.

Network architecture search algorithms may result in heavily fragmented architectures when accuracy and the number of operations are the only search criteria. The paper also points out is that element-wise operations have a non-negligible cost. Point-wise operations such as ReLU and 1×1 convolutions have a small number of floating-point operations, but their memory access cost is non-negligible. Therefore, one shouldn’t consider them free in model architecture design.

As you may know, my work mostly focuses on models that operate on image data, and I haven’t been working on anything natural language processing related for the past few years. However, it’s hard not to see how successful the Transformer model has been in the field of natural language processing. This new type of architecture relies on what’s called `attention mechanisms.’

At a very high level, an attention mechanism tells a model where to look; what parts of the input signal are more relevant. You can think of it as a module that generates a weight vector given a query. For example, to resolve what ‘it’ refers to in “This video is very interesting. I liked it.”, an attention vector would put a higher weight on the words “this” and “video.”

This type of attention mechanism is called self-attention. It’s straightforward to see how attention mechanisms help in this example, but can we apply this type of self-attention also to models that deal with computer vision problems? Yes, we can.

We don’t have words and sentences in images, but we certainly can design mechanisms to shift the attention towards particular spatial locations or feature maps. For example, this paper, titled “Squeeze-and-Excitation Networks,” proposes a self-attention mechanism that assigns weights to feature maps based on their relevance for a given input. The way they do it is quite simple.

For a given layer, they first squeeze the feature maps into a global description vector by averaging over the spatial axes. This is basically a global average pooling operator. Then, they feed that information into a mini fully-connected neural network that outputs an attention vector. Finally, they take those weights in the attention vector and multiply them with their corresponding feature maps at the input. This process essentially puts the attention on more relevant feature maps by recalibrating their channels.

This method can easily be applied to many types of convolutional neural network architectures, such as ResNet. MobileNetV3 also makes use of similar attention modules, combining manual design practices with an automated network architecture search approach. For many computer vision tasks, it seems that it’s a good strategy to use self-attention mechanisms in convolutional neural network architectures. At the beginning of the video, I mentioned using a well-known model architecture off-the-shelf would be sufficient in many cases.

But if you are trying to solve a problem that has some specific requirements or limitations, then you may need to make some task-specific design choices to adapt your model to a targeted application. Let’s go through two such examples. The first one is a pixel-wise segmentation model that I designed to handle very large input images. The goal was to create surface water maps given satellite imagery.

This is a typical semantic segmentation task that any mainstream pixel-wise prediction model would be expected to perform well. However, satellite imagery can be much larger, like orders of magnitude larger, than images that the mainstream models are designed to deal with. So, I needed to make some design choices to process large inputs in one shot, without dividing them into tiles, given a certain memory budget.

It’s a common practice to double the number of feature maps whenever you downscale the input by two and vice versa. In this setting, higher-resolution layers get much more memory allocation than the coarser scale ones. Because downscaling an image by two in both spatial axes while doubling the number of channels still reduces the overall feature map volume by two. One design choice I made was to quadruple the number of channels whenever the feature maps are spatially downscaled so that the model uses constant memory throughout the network and layers at different levels of abstraction get their fair share of memory allocation.

This approach also has some downsides, but for this particular task, it worked very well. I published a paper on this in the IEEE Geoscience and Remote Sensing Letters very recently. There’s a lot more in the paper. Check it out to learn more about it. Let’s move on to the second custom model design example, in which our goal was to minimize the latency and hardware footprint of our model.

We used several tricks to do that. The main innovation in our model was the use of 3-way separable FIR-IIR filters for the purposes of line buffer minimization, and I’ll explain what that means. The concept of separable convolutions is nothing new. Many efficient model architectures use depthwise separable convolutions.

However, as I mentioned in one of my earlier articless, 3-way separable convolutions having vertical, horizontal, and depthwise components are fairly uncommon. There is a reason for that. Convolutional neural networks typically use very small kernel sizes, such as 3×3. Therefore, breaking down a spatial convolution into column and row convolutions doesn’t really save much.

I’m guessing that’s also why popular models don’t use depthwise separable convolutions in the first layer, although I haven’t seen it stated explicitly in the papers. Since the input is usually a 3-channel RGB image, the number of channels is too few for depthwise separability to be worth it. In our case, spatial separability was very useful for factorizing the hardware cost.

The cost of vertical convolutions was disproportionally high because of the number of lines that need to be buffered. The hardware acquired images line-by-line. Therefore, a column convolution required more elements to be buffered. For example, a 5×1 convolution would need 4 lines of data to be buffered, whereas a 1×5 convolution would need only 4 elements to be buffered.

We addressed this problem by replacing the vertical convolutions in a 3-way separable convolution layer with infinite impulse response filters. You can think of those IIR filters as recurrent neural network modules that summarize pixels in the vertical direction. Unlike fixed-window convolutions, our separable FIR-IIR filters start processing their input as soon as the pixels arrive, without having to buffer the lines that would be spanned by a fixed-sized window.

This reduces latency and the size of the line buffers, leading to significant savings in silicon area. You can find our paper in the description below. My final tip in this video is not to follow any advice or guideline religiously, including my own. Things change fast, especially in this field. Guidelines, rules of thumb, and design patterns are practical, but they don’t always work well.

Things change, our understanding of things change. So it’s better to keep an open mind. Alright, that’s all for today. I hope you liked it.

 

 

Useful links:

reference – How to Design a Neural Network

Share this post ...

Leave a Reply

Your email address will not be published. Required fields are marked *