newsmode
search
Меню
arrow_back Назад

A Recipe for Training Neural Networks

auto_awesomeКраткое саммари

Андрей Карпати делится практическим рецептом обучения нейронных сетей, основанным на двух ключевых наблюдениях: обучение нейросетей — это «дырявая абстракция», а ошибки в нём проявляются молча, не вызывая исключений. Поэтому подход «быстро и яростно» не работает — нужны терпение, внимательность к деталям и одержимость визуализациями. Автор описывает шестиэтапный процесс: глубокое изучение данных, построение end-to-end скелета обучения с глупыми бейзлайнами, переобучение на большой модели, регуляризация, тонкая настройка и финальное «выжимание сока». На каждом шаге даются конкретные советы: фиксировать random seed, проверять loss при инициализации, переобучать на одном батче, использовать Adam с lr 3e-4, не быть героем и копировать архитектуру из ближайшей статьи, предпочитать random search перед grid search, применять ансамбли и не останавливать обучение слишком рано. Главный посыл — строить от простого к сложному, формулируя гипотезы и проверяя их экспериментами.

Some few weeks ago I posted a tweet on “the most common neural net mistakes”, listing a few common gotchas related to training neural nets. The tweet got quite a bit more engagement than I anticipated (including a webinar :)). Clearly, a lot of people have personally encountered the large gap between “here is how a convolutional layer works” and “our convnet achieves state of the art results”.

Несколько недель назад я опубликовал твит о «самых распространённых ошибках при работе с нейросетями», перечислив несколько типичных подводных камней, связанных с обучением нейронных сетей. Твит получил гораздо больше отклика, чем я ожидал (включая вебинар :)). Очевидно, многие лично сталкивались с огромной пропастью между «вот так работает свёрточный слой» и «наша свёрточная сеть достигает state of the art».

So I thought it could be fun to brush off my dusty blog to expand my tweet to the long form that this topic deserves. However, instead of going into an enumeration of more common errors or fleshing them out, I wanted to dig a bit deeper and talk about how one can avoid making these errors altogether (or fix them very fast). The trick to doing so is to follow a certain process, which as far as I can tell is not very often documented. Let’s start with two important observations that motivate it.

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

1) Neural net training is a leaky abstraction

1) Обучение нейросетей — это дырявая абстракция

It is allegedly easy to get started with training neural nets. Numerous libraries and frameworks take pride in displaying 30-line miracle snippets that solve your data problems, giving the (false) impression that this stuff is plug and play. It’s common see things like:

Якобы легко начать обучать нейросети. Многочисленные библиотеки и фреймворки гордо демонстрируют чудо-сниппеты в 30 строк, решающие ваши задачи с данными, создавая (ложное) впечатление, что это технология plug-and-play. Часто можно увидеть нечто вроде:

>>> your_data = # plug your awesome dataset here >>> model = SuperCrossValidator(SuperDuper.fit, your_data, ResNet50, SGDOptimizer) # conquer world here

>>> your_data = # подключите сюда свой потрясающий датасет >>> model = SuperCrossValidator(SuperDuper.fit, your_data, ResNet50, SGDOptimizer) # покоряем мир здесь

These libraries and examples activate the part of our brain that is familiar with standard software - a place where clean APIs and abstractions are often attainable. Requests library to demonstrate:

Эти библиотеки и примеры активируют ту часть нашего мозга, которая привыкла к обычному софту — где чистые API и абстракции часто достижимы. Покажем на примере библиотеки Requests:

>>> r = requests.get('https://api.github.com/user', auth=('user', 'pass')) >>> r.status_code 200

>>> r = requests.get('https://api.github.com/user', auth=('user', 'pass')) >>> r.status_code 200

That’s cool! A courageous developer has taken the burden of understanding query strings, urls, GET/POST requests, HTTP connections, and so on from you and largely hidden the complexity behind a few lines of code. This is what we are familiar with and expect. Unfortunately, neural nets are nothing like that. They are not “off-the-shelf” technology the second you deviate slightly from training an ImageNet classifier. I’ve tried to make this point in my post “Yes you should understand backprop” by picking on backpropagation and calling it a “leaky abstraction”, but the situation is unfortunately much more dire. Backprop + SGD does not magically make your network work. Batch norm does not magically make it converge faster. RNNs don’t magically let you “plug in” text. And just because you can formulate your problem as RL doesn’t mean you should. If you insist on using the technology without understanding how it works you are likely to fail. Which brings me to…

Здорово! Смелый разработчик взял на себя бремя понимания query-строк, URL, GET/POST запросов, HTTP-соединений и так далее, и в значительной мере спрятал сложность за несколькими строками кода. Это то, к чему мы привыкли и чего ожидаем. К сожалению, нейросети совсем не такие. Они не являются «коробочной» технологией в тот момент, когда вы хоть немного отходите от обучения классификатора на ImageNet. Я пытался донести эту мысль в посте «Yes you should understand backprop», выбрав для критики backpropagation и назвав его «дырявой абстракцией», но ситуация, к сожалению, гораздо плачевнее. Backprop + SGD не превращает магически вашу сеть в работающую. Batch norm магически не заставляет её сходиться быстрее. RNN магически не позволяют вам «подключить» текст. И то, что вы можете сформулировать задачу как RL, не означает, что нужно это делать. Если вы упорно используете технологию, не понимая, как она работает, вы, скорее всего, потерпите неудачу. Что подводит меня к…

2) Neural net training fails silently

2) Обучение нейросетей падает молча

When you break or misconfigure code you will often get some kind of an exception. You plugged in an integer where something expected a string. The function only expected 3 arguments. This import failed. That key does not exist. The number of elements in the two lists isn’t equal. In addition, it’s often possible to create unit tests for a certain functionality.

Когда вы ломаете или неверно настраиваете код, вы обычно получаете какое-то исключение. Подсунули integer туда, где ожидалась строка. Функция принимала только 3 аргумента. Этот импорт не прошёл. Этого ключа не существует. Количество элементов в двух списках не совпадает. Кроме того, часто можно написать unit-тесты для определённой функциональности.

This is just a start when it comes to training neural nets. Everything could be correct syntactically, but the whole thing isn’t arranged properly, and it’s really hard to tell. The “possible error surface” is large, logical (as opposed to syntactic), and very tricky to unit test. For example, perhaps you forgot to flip your labels when you left-right flipped the image during data augmentation. Your net can still (shockingly) work pretty well because your network can internally learn to detect flipped images and then it left-right flips its predictions. Or maybe your autoregressive model accidentally takes the thing it’s trying to predict as an input due to an off-by-one bug. Or you tried to clip your gradients but instead clipped the loss, causing the outlier examples to be ignored during training. Or you initialized your weights from a pretrained checkpoint but didn’t use the original mean. Or you just screwed up the settings for regularization strengths, learning rate, its decay rate, model size, etc. Therefore, your misconfigured neural net will throw exceptions only if you’re lucky; Most of the time it will train but silently work a bit worse.

Это лишь начало, когда речь идёт об обучении нейросетей. Всё может быть синтаксически правильно, но при этом в целом устроено неверно — и это очень сложно заметить. «Поверхность возможных ошибок» большая, логическая (а не синтаксическая) и очень трудно покрывается unit-тестами. Например, возможно, вы забыли отразить метки, когда отразили изображение по горизонтали при аугментации данных. Ваша сеть всё равно (поразительно) может работать вполне неплохо, потому что внутри она научится распознавать отражённые изображения и затем зеркалить свои предсказания. Или, может быть, ваша авторегрессионная модель случайно принимает на вход то, что пытается предсказать, из-за off-by-one бага. Или вы пытались клипнуть градиенты, но вместо этого клипнули loss, из-за чего выбросы игнорировались при обучении. Или вы инициализировали веса из предобученного чекпоинта, но не использовали оригинальное среднее. Или вы просто накосячили с настройками силы регуляризации, learning rate, его decay rate, размером модели и т.д. Поэтому ваша неправильно настроенная нейросеть выбросит исключения только если вам повезло; в большинстве случаев она обучится, но молча будет работать чуть хуже.

As a result, (and this is reeaally difficult to over-emphasize) a “fast and furious” approach to training neural networks does not work and only leads to suffering. Now, suffering is a perfectly natural part of getting a neural network to work well, but it can be mitigated by being thorough, defensive, paranoid, and obsessed with visualizations of basically every possible thing. The qualities that in my experience correlate most strongly to success in deep learning are patience and attention to detail.

В результате (и это нееевероятно сложно переоценить) подход «быстро и яростно» к обучению нейросетей не работает и приводит только к страданиям. Страдания — совершенно естественная часть процесса получения хорошо работающей нейросети, но их можно смягчить, будучи скрупулёзным, оборонительным, параноидальным и одержимым визуализациями буквально всего возможного. Качества, которые по моему опыту сильнее всего коррелируют с успехом в deep learning — это терпение и внимание к деталям.

The recipe

Рецепт

In light of the above two facts, I have developed a specific process for myself that I follow when applying a neural net to a new problem, which I will try to describe. You will see that it takes the two principles above very seriously. In particular, it builds from simple to complex and at every step of the way we make concrete hypotheses about what will happen and then either validate them with an experiment or investigate until we find some issue. What we try to prevent very hard is the introduction of a lot of “unverified” complexity at once, which is bound to introduce bugs/misconfigurations that will take forever to find (if ever). If writing your neural net code was like training one, you’d want to use a very small learning rate and guess and then evaluate the full test set after every iteration.

В свете двух фактов выше я выработал для себя определённый процесс, которому следую, применяя нейросеть к новой задаче, и который попытаюсь описать. Вы увидите, что он очень серьёзно относится к двум вышеназванным принципам. В частности, он строится от простого к сложному, и на каждом шаге мы формулируем конкретные гипотезы о том, что произойдёт, и затем либо подтверждаем их экспериментом, либо разбираемся до тех пор, пока не найдём какую-то проблему. Чего мы очень стараемся избегать — это введения большого количества «непроверенной» сложности сразу, что неминуемо приведёт к багам/неправильным настройкам, которые потом будут искать вечно (если вообще найдут). Если бы написание кода нейросети было похоже на её обучение, вы бы использовали очень маленький learning rate и угадывали бы, а затем оценивали полный тестовый набор после каждой итерации.

1. Become one with the data

1. Слейся с данными

The first step to training a neural net is to not touch any neural net code at all and instead begin by thoroughly inspecting your data. This step is critical. I like to spend copious amount of time (measured in units of hours) scanning through thousands of examples, understanding their distribution and looking for patterns. Luckily, your brain is pretty good at this. One time I discovered that the data contained duplicate examples. Another time I found corrupted images / labels. I look for data imbalances and biases. I will typically also pay attention to my own process for classifying the data, which hints at the kinds of architectures we’ll eventually explore. As an example - are very local features enough or do we need global context? How much variation is there and what form does it take? What variation is spurious and could be preprocessed out? Does spatial position matter or do we want to average pool it out? How much does detail matter and how far could we afford to downsample the images? How noisy are the labels?

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

In addition, since the neural net is effectively a compressed/compiled version of your dataset, you’ll be able to look at your network (mis)predictions and understand where they might be coming from. And if your network is giving you some prediction that doesn’t seem consistent with what you’ve seen in the data, something is off.

Кроме того, поскольку нейросеть фактически является сжатой/скомпилированной версией вашего датасета, вы сможете посмотреть на (не)верные предсказания вашей сети и понять, откуда они могут идти. И если ваша сеть выдаёт предсказание, которое не согласуется с тем, что вы видели в данных, что-то не так.

Once you get a qualitative sense it is also a good idea to write some simple code to search/filter/sort by whatever you can think of (e.g. type of label, size of annotations, number of annotations, etc.) and visualize their distributions and the outliers along any axis. The outliers especially almost always uncover some bugs in data quality or preprocessing.

Получив качественное понимание, также неплохо написать простой код для поиска/фильтрации/сортировки по чему угодно (например, по типу метки, размеру аннотаций, количеству аннотаций и т.д.), визуализировать их распределения и выбросы по любым осям. Особенно выбросы почти всегда вскрывают какие-то баги в качестве данных или препроцессинге.

2. Set up the end-to-end training/evaluation skeleton + get dumb baselines

2. Настрой end-to-end скелет обучения/оценки + получи глупые бейзлайны

Now that we understand our data can we reach for our super fancy Multi-scale ASPP FPN ResNet and begin training awesome models? For sure no. That is the road to suffering. Our next step is to set up a full training + evaluation skeleton and gain trust in its correctness via a series of experiments. At this stage it is best to pick some simple model that you couldn’t possibly have screwed up somehow - e.g. a linear classifier, or a very tiny ConvNet. We’ll want to train it, visualize the losses, any other metrics (e.g. accuracy), model predictions, and perform a series of ablation experiments with explicit hypotheses along the way.

Теперь, когда мы понимаем данные, можем ли мы дотянуться до нашего супер-крутого Multi-scale ASPP FPN ResNet и начать обучать потрясающие модели? Однозначно нет. Это путь к страданиям. Наш следующий шаг — настроить полный скелет обучения + оценки и обрести уверенность в его корректности через серию экспериментов. На этом этапе лучше всего выбрать какую-то простую модель, которую вы никак не могли бы сломать — например, линейный классификатор или совсем крошечную ConvNet. Мы захотим её обучить, визуализировать loss, любые другие метрики (например, accuracy), предсказания модели и провести серию ablation-экспериментов с явными гипотезами по ходу дела.

Tips & tricks for this stage:

Советы и трюки для этого этапа:

  • fix random seed. Always use a fixed random seed to guarantee that when you run the code twice you will get the same outcome. This removes a factor of variation and will help keep you sane.
  • simplify. Make sure to disable any unnecessary fanciness. As an example, definitely turn off any data augmentation at this stage. Data augmentation is a regularization strategy that we may incorporate later, but for now it is just another opportunity to introduce some dumb bug.
  • add significant digits to your eval. When plotting the test loss run the evaluation over the entire (large) test set. Do not just plot test losses over batches and then rely on smoothing them in Tensorboard. We are in pursuit of correctness and are very willing to give up time for staying sane.
  • verify loss @ init. Verify that your loss starts at the correct loss value. E.g. if you initialize your final layer correctly you should measure -log(1/n_classes) on a softmax at initialization. The same default values can be derived for L2 regression, Huber losses, etc.
  • init well. Initialize the final layer weights correctly. E.g. if you are regressing some values that have a mean of 50 then initialize the final bias to 50. If you have an imbalanced dataset of a ratio 1:10 of positives:negatives, set the bias on your logits such that your network predicts probability of 0.1 at initialization. Setting these correctly will speed up convergence and eliminate “hockey stick” loss curves where in the first few iteration your network is basically just learning the bias.
  • human baseline. Monitor metrics other than loss that are human interpretable and checkable (e.g. accuracy). Whenever possible evaluate your own (human) accuracy and compare to it. Alternatively, annotate the test data twice and for each example treat one annotation as prediction and the second as ground truth.
  • input-indepent baseline. Train an input-independent baseline, (e.g. easiest is to just set all your inputs to zero). This should perform worse than when you actually plug in your data without zeroing it out. Does it? i.e. does your model learn to extract any information out of the input at all?
  • overfit one batch. Overfit a single batch of only a few examples (e.g. as little as two). To do so we increase the capacity of our model (e.g. add layers or filters) and verify that we can reach the lowest achievable loss (e.g. zero). I also like to visualize in the same plot both the label and the prediction and ensure that they end up aligning perfectly once we reach the minimum loss. If they do not, there is a bug somewhere and we cannot continue to the next stage.
  • verify decreasing training loss. At this stage you will hopefully be underfitting on your dataset because you’re working with a toy model. Try to increase its capacity just a bit. Did your training loss go down as it should?
  • visualize just before the net. The unambiguously correct place to visualize your data is immediately before your y_hat = model(x) (or sess.run in tf). That is - you want to visualize exactly what goes into your network, decoding that raw tensor of data and labels into visualizations. This is the only “source of truth”. I can’t count the number of times this has saved me and revealed problems in data preprocessing and augmentation.
  • visualize prediction dynamics. I like to visualize model predictions on a fixed test batch during the course of training. The “dynamics” of how these predictions move will give you incredibly good intuition for how the training progresses. Many times it is possible to feel the network “struggle” to fit your data if it wiggles too much in some way, revealing instabilities. Very low or very high learning rates are also easily noticeable in the amount of jitter.
  • use backprop to chart dependencies. Your deep learning code will often contain complicated, vectorized, and broadcasted operations. A relatively common bug I’ve come across a few times is that people get this wrong (e.g. they use view instead of transpose/permute somewhere) and inadvertently mix information across the batch dimension. It is a depressing fact that your network will typically still train okay because it will learn to ignore data from the other examples. One way to debug this (and other related problems) is to set the loss to be something trivial like the sum of all outputs of example i, run the backward pass all the way to the input, and ensure that you get a non-zero gradient only on the i-th input. The same strategy can be used to e.g. ensure that your autoregressive model at time t only depends on 1..t-1. More generally, gradients give you information about what depends on what in your network, which can be useful for debugging.
  • generalize a special case. This is a bit more of a general coding tip but I’ve often seen people create bugs when they bite off more than they can chew, writing a relatively general functionality from scratch. I like to write a very specific function to what I’m doing right now, get that to work, and then generalize it later making sure that I get the same result. Often this applies to vectorizing code, where I almost always write out the fully loopy version first and only then transform it to vectorized code one loop at a time.
  • зафиксируй random seed. Всегда используйте фиксированный random seed, чтобы при двукратном запуске кода вы получали один и тот же результат. Это убирает фактор вариативности и поможет сохранить рассудок. упрощай. Обязательно отключите всё лишнее. Например, точно отключите любую аугментацию данных на этом этапе. Аугментация данных — это стратегия регуляризации, которую мы можем подключить позже, но сейчас это просто ещё одна возможность ввести какой-то глупый баг. добавь значащие цифры в evaluation. При построении графика test loss запускайте оценку на всём (большом) тестовом наборе. Не просто стройте test loss по батчам и полагайтесь на сглаживание в Tensorboard. Мы стремимся к корректности и охотно жертвуем временем ради сохранения рассудка. проверь loss @ init. Убедитесь, что ваш loss стартует с правильного значения. Например, если вы правильно инициализировали финальный слой, на softmax при инициализации вы должны измерить -log(1/n_classes). Те же дефолтные значения можно вывести для L2-регрессии, Huber losses и т.д. хорошо инициализируй. Корректно инициализируйте веса финального слоя. Например, если вы делаете регрессию значений со средним 50, инициализируйте финальный bias значением 50. Если у вас несбалансированный датасет с соотношением 1:10 positives:negatives, установите bias на логитах так, чтобы при инициализации сеть предсказывала вероятность 0.1. Правильная установка этого ускорит сходимость и устранит «хоккейные» кривые loss, где в первые несколько итераций сеть, по сути, просто учит bias. человеческий бейзлайн. Отслеживайте метрики, помимо loss, которые интерпретируемы человеком и проверяемы (например, accuracy). При возможности оценивайте свою собственную (человеческую) accuracy и сравнивайте с ней. Альтернативно, аннотируйте тестовые данные дважды и для каждого примера трактуйте одну аннотацию как предсказание, а вторую как ground truth. input-independent бейзлайн. Обучите input-independent бейзлайн (например, проще всего — обнулить все входы). Это должно работать хуже, чем когда вы реально подключаете данные без обнуления. Работает? То есть учится ли ваша модель извлекать какую-либо информацию из входа вообще? переобучи один батч. Переобучитесь на одном батче из всего нескольких примеров (например, всего двух). Для этого мы увеличиваем ёмкость модели (например, добавляем слои или фильтры) и проверяем, что можем достичь наименьшего возможного loss (например, нуля). Также мне нравится визуализировать на одном графике и метку, и предсказание и убеждаться, что они в итоге идеально совпадают, когда мы достигаем минимума loss. Если нет — где-то баг, и мы не можем двигаться к следующему этапу. проверь убывание training loss. На этом этапе вы, надеюсь, будете недообучаться на датасете, потому что работаете с игрушечной моделью. Попробуйте слегка увеличить её ёмкость. Уменьшился ли training loss, как должен был? визуализируй прямо перед сетью. Однозначно правильное место для визуализации данных — это непосредственно перед y_hat = model(x) (или sess.run в tf). То есть вы хотите визуализировать именно то, что попадает в сеть, декодируя сырой тензор данных и меток в визуализации. Это единственный «источник истины». Я не могу сосчитать, сколько раз это меня спасало и вскрывало проблемы в препроцессинге данных и аугментации. визуализируй динамику предсказаний. Мне нравится визуализировать предсказания модели на фиксированном тестовом батче в ходе обучения. «Динамика» того, как двигаются эти предсказания, даст вам невероятно хорошую интуицию о ходе обучения. Часто можно почувствовать, как сеть «борется» с подгонкой к данным, если она слишком сильно колеблется в каком-то виде, что выдаёт нестабильности. Очень низкие или очень высокие learning rate также легко заметны по амплитуде дрожания. используй backprop для построения зависимостей. Ваш код deep learning часто содержит сложные, векторизованные и broadcast-операции. Относительно распространённый баг, который я встречал несколько раз — это когда люди делают это неверно (например, используют view вместо transpose/permute где-то) и непреднамеренно смешивают информацию по размерности батча. Удручающий факт состоит в том, что ваша сеть обычно всё равно неплохо обучится, потому что научится игнорировать данные из других примеров. Один из способов отладить это (и другие связанные проблемы) — задать loss как что-то тривиальное, например, сумму всех выходов примера i, прогнать backward pass до самого входа и убедиться, что ненулевой градиент вы получаете только на i-том входе. Та же стратегия может использоваться, например, для проверки того, что ваша авторегрессионная модель в момент t зависит только от 1..t-1. В целом, градиенты дают вам информацию о том, что от чего зависит в вашей сети, что может быть полезно для отладки. обобщай частный случай. Это уже более общий совет по программированию, но я часто видел, как люди создают баги, когда откусывают больше, чем могут прожевать, написав сразу с нуля довольно общую функциональность. Мне нравится писать очень специфичную функцию для того, что я делаю прямо сейчас, заставлять её работать, а затем обобщать её позже, убеждаясь, что получаю тот же результат. Часто это применимо к векторизации кода, где я почти всегда сначала пишу полностью циклическую версию и только потом превращаю её в векторизованный код, один цикл за раз.

    3. Overfit

    3. Переобучи

    At this stage we should have a good understanding of the dataset and we have the full training + evaluation pipeline working. For any given model we can (reproducibly) compute a metric that we trust. We are also armed with our performance for an input-independent baseline, the performance of a few dumb baselines (we better beat these), and we have a rough sense of the performance of a human (we hope to reach this). The stage is now set for iterating on a good model.

    К этому моменту мы должны хорошо понимать датасет, и у нас есть рабочий полный пайплайн обучения + оценки. Для любой данной модели мы можем (воспроизводимо) посчитать метрику, которой доверяем. Также мы вооружены результатом input-independent бейзлайна, результатами нескольких глупых бейзлайнов (которые нам лучше превзойти), и у нас есть грубое представление о человеческом результате (которого мы надеемся достичь). Теперь сцена готова для итераций по поиску хорошей модели.

    The approach I like to take to finding a good model has two stages: first get a model large enough that it can overfit (i.e. focus on training loss) and then regularize it appropriately (give up some training loss to improve the validation loss). The reason I like these two stages is that if we are not able to reach a low error rate with any model at all that may again indicate some issues, bugs, or misconfiguration.

    Подход, который я предпочитаю для поиска хорошей модели, состоит из двух стадий: сначала получить модель, достаточно большую, чтобы переобучаться (т.е. фокус на training loss), а затем регуляризовать её надлежащим образом (пожертвовать частью training loss ради улучшения validation loss). Причина, по которой мне нравятся эти две стадии, в том, что если мы не способны достичь низкого error rate ни с какой моделью вообще, это снова может указывать на какие-то проблемы, баги или неправильную настройку.

    A few tips & tricks for this stage:

    Несколько советов и трюков для этого этапа:

  • picking the model. To reach a good training loss you’ll want to choose an appropriate architecture for the data. When it comes to choosing this my #1 advice is: Don’t be a hero. I’ve seen a lot of people who are eager to get crazy and creative in stacking up the lego blocks of the neural net toolbox in various exotic architectures that make sense to them. Resist this temptation strongly in the early stages of your project. I always advise people to simply find the most related paper and copy paste their simplest architecture that achieves good performance. E.g. if you are classifying images don’t be a hero and just copy paste a ResNet-50 for your first run. You’re allowed to do something more custom later and beat this.
  • adam is safe. In the early stages of setting baselines I like to use Adam with a learning rate of 3e-4. In my experience Adam is much more forgiving to hyperparameters, including a bad learning rate. For ConvNets a well-tuned SGD will almost always slightly outperform Adam, but the optimal learning rate region is much more narrow and problem-specific. (Note: If you are using RNNs and related sequence models it is more common to use Adam. At the initial stage of your project, again, don’t be a hero and follow whatever the most related papers do.)
  • complexify only one at a time. If you have multiple signals to plug into your classifier I would advise that you plug them in one by one and every time ensure that you get a performance boost you’d expect. Don’t throw the kitchen sink at your model at the start. There are other ways of building up complexity - e.g. you can try to plug in smaller images first and make them bigger later, etc.
  • do not trust learning rate decay defaults. If you are re-purposing code from some other domain always be very careful with learning rate decay. Not only would you want to use different decay schedules for different problems, but - even worse - in a typical implementation the schedule will be based current epoch number, which can vary widely simply depending on the size of your dataset. E.g. ImageNet would decay by 10 on epoch 30. If you’re not training ImageNet then you almost certainly do not want this. If you’re not careful your code could secretely be driving your learning rate to zero too early, not allowing your model to converge. In my own work I always disable learning rate decays entirely (I use a constant LR) and tune this all the way at the very end.
  • выбор модели. Чтобы достичь хорошего training loss, вам нужно подобрать подходящую архитектуру под данные. Когда дело доходит до этого выбора, мой совет №1: Не будь героем. Я видел много людей, которым не терпится начать креативить и сходить с ума, складывая лего-блоки нейросетевого инструментария в различные экзотические архитектуры, кажущиеся им осмысленными. Решительно сопротивляйтесь этому искушению на ранних стадиях проекта. Я всегда советую людям просто найти наиболее релевантную статью и copy-paste-нуть оттуда простейшую архитектуру, дающую хороший результат. Например, если вы классифицируете изображения, не будьте героем и просто copy-paste-ните ResNet-50 для первого запуска. Что-то более кастомное вам разрешается сделать позже и превзойти это. Adam безопасен. На ранних стадиях установки бейзлайнов мне нравится использовать Adam с learning rate 3e-4. По моему опыту Adam гораздо более прощающий по отношению к гиперпараметрам, включая плохой learning rate. Для ConvNet хорошо настроенный SGD почти всегда слегка обходит Adam, но область оптимальных learning rate гораздо уже и специфична для задачи. (Замечание: если вы используете RNN и связанные sequence-модели, более распространено использовать Adam. На начальной стадии проекта, опять же, не будьте героем и следуйте тому, что делают самые близкие по теме статьи.) усложняй только по одному за раз. Если у вас есть несколько сигналов для подачи в классификатор, я бы посоветовал подключать их по одному и каждый раз убеждаться, что вы получаете ожидаемый прирост качества. Не швыряйте в модель всё подряд с самого начала. Есть и другие способы наращивать сложность — например, можно сначала подавать меньшие изображения, а потом увеличивать их и т.д. не доверяй дефолтам learning rate decay. Если вы переиспользуете код из другой области, всегда будьте очень осторожны с learning rate decay. Мало того, что для разных задач вы захотите разные schedule'ы decay, так ещё и — что хуже — в типичной реализации schedule основан на текущем номере epoch, который может сильно варьироваться просто в зависимости от размера вашего датасета. Например, ImageNet делает decay в 10 раз на 30-й epoch. Если вы не обучаете ImageNet, вам почти наверняка такое не нужно. Если вы невнимательны, ваш код может тайно сбрасывать learning rate в ноль слишком рано, не давая модели сойтись. В своей работе я всегда полностью отключаю learning rate decay (использую константный LR) и подбираю это в самом конце.

    4. Regularize

    4. Регуляризуй

    Ideally, we are now at a place where we have a large model that is fitting at least the training set. Now it is time to regularize it and gain some validation accuracy by giving up some of the training accuracy. Some tips & tricks:

    В идеале мы теперь в точке, где у нас есть большая модель, по крайней мере подгоняющая training set. Теперь время её регуляризовать и получить какую-то validation accuracy, пожертвовав частью training accuracy. Несколько советов и трюков:

  • get more data. First, the by far best and preferred way to regularize a model in any practical setting is to add more real training data. It is a very common mistake to spend a lot engineering cycles trying to squeeze juice out of a small dataset when you could instead be collecting more data. As far as I’m aware adding more data is pretty much the only guaranteed way to monotonically improve the performance of a well-configured neural network almost indefinitely. The other would be ensembles (if you can afford them), but that tops out after ~5 models.
  • data augment. The next best thing to real data is half-fake data - try out more aggressive data augmentation.
  • creative augmentation. If half-fake data doesn’t do it, fake data may also do something. People are finding creative ways of expanding datasets; For example, domain randomization, use of simulation, clever hybrids such as inserting (potentially simulated) data into scenes, or even GANs.
  • pretrain. It rarely ever hurts to use a pretrained network if you can, even if you have enough data.
  • stick with supervised learning. Do not get over-excited about unsupervised pretraining. Unlike what that blog post from 2008 tells you, as far as I know, no version of it has reported strong results in modern computer vision (though NLP seems to be doing pretty well with BERT and friends these days, quite likely owing to the more deliberate nature of text, and a higher signal to noise ratio).
  • smaller input dimensionality. Remove features that may contain spurious signal. Any added spurious input is just another opportunity to overfit if your dataset is small. Similarly, if low-level details don’t matter much try to input a smaller image.
  • smaller model size. In many cases you can use domain knowledge constraints on the network to decrease its size. As an example, it used to be trendy to use Fully Connected layers at the top of backbones for ImageNet but these have since been replaced with simple average pooling, eliminating a ton of parameters in the process.
  • decrease the batch size. Due to the normalization inside batch norm smaller batch sizes somewhat correspond to stronger regularization. This is because the batch empirical mean/std are more approximate versions of the full mean/std so the scale & offset “wiggles” your batch around more.
  • drop. Add dropout. Use dropout2d (spatial dropout) for ConvNets. Use this sparingly/carefully because dropout does not seem to play nice with batch normalization.
  • weight decay. Increase the weight decay penalty.
  • early stopping. Stop training based on your measured validation loss to catch your model just as it’s about to overfit.
  • try a larger model. I mention this last and only after early stopping but I’ve found a few times in the past that larger models will of course overfit much more eventually, but their “early stopped” performance can often be much better than that of smaller models.
  • добывай больше данных. Во-первых, безусловно лучший и предпочитаемый способ регуляризации модели в любых практических условиях — добавить больше реальных тренировочных данных. Очень распространённая ошибка — тратить кучу инженерных циклов, пытаясь выжать сок из маленького датасета, когда вместо этого можно было бы собирать больше данных. Насколько мне известно, добавление большего количества данных — это практически единственный гарантированный способ монотонно улучшать качество хорошо настроенной нейросети практически бесконечно. Другим был бы ensemble (если можете себе позволить), но он перестаёт давать прирост примерно после 5 моделей. аугментируй данные. Следующее лучшее после реальных данных — полуподдельные данные: попробуйте более агрессивную аугментацию данных. креативная аугментация. Если полуподдельные данные не помогают, поддельные данные тоже могут что-то дать. Люди находят креативные способы расширения датасетов: например, domain randomization, использование симуляций, хитрые гибриды вроде вставки (возможно, симулированных) данных в сцены, или даже GAN. предобучение. Редко когда вредно использовать предобученную сеть, если можете, даже если у вас достаточно данных. придерживайся supervised learning. Не слишком восторгайтесь unsupervised pretraining. В отличие от того, что говорит вам тот блог-пост из 2008 года, насколько мне известно, ни одна его версия не показала сильных результатов в современном computer vision (хотя NLP, похоже, неплохо себя чувствует с BERT и компанией в последнее время, что весьма вероятно связано с более осмысленной природой текста и более высоким соотношением сигнал/шум). меньшая размерность входа. Удалите признаки, которые могут содержать ложный сигнал. Любой добавленный ложный вход — это просто ещё одна возможность переобучиться, если ваш датасет небольшой. Аналогично, если низкоуровневые детали не очень важны, попробуйте подать меньшее изображение. меньший размер модели. Во многих случаях вы можете использовать доменные знания как ограничения на сеть, чтобы уменьшить её размер. Например, раньше было модно использовать Fully Connected слои поверх backbone для ImageNet, но с тех пор их заменили на простой average pooling, устранив тонну параметров в процессе. уменьши размер батча. Из-за нормализации внутри batch norm меньшие размеры батча в каком-то смысле соответствуют более сильной регуляризации. Это связано с тем, что эмпирические mean/std батча — это более приблизительные версии полных mean/std, поэтому scale & offset «болтают» ваш батч сильнее. drop. Добавьте dropout. Используйте dropout2d (spatial dropout) для ConvNet. Используйте это умеренно/осторожно, потому что dropout не очень хорошо ладит с batch normalization. weight decay. Увеличьте штраф weight decay. early stopping. Останавливайте обучение на основе измеренного validation loss, чтобы поймать модель прямо в тот момент, когда она вот-вот переобучится. попробуй модель побольше. Упоминаю это последним и только после early stopping, но в прошлом несколько раз я обнаруживал, что большие модели, конечно, переобучаются гораздо сильнее в итоге, но их «early stopped» качество часто может быть гораздо лучше, чем у меньших моделей.

    Finally, to gain additional confidence that your network is a reasonable classifier, I like to visualize the network’s first-layer weights and ensure you get nice edges that make sense. If your first layer filters look like noise then something could be off. Similarly, activations inside the net can sometimes display odd artifacts and hint at problems.

    Наконец, чтобы получить дополнительную уверенность, что ваша сеть — разумный классификатор, мне нравится визуализировать веса первого слоя сети и убеждаться, что вы получаете красивые осмысленные грани. Если фильтры вашего первого слоя выглядят как шум, что-то может быть не так. Аналогично, активации внутри сети иногда могут показывать странные артефакты и намекать на проблемы.

    5. Tune

    5. Настраивай

    You should now be “in the loop” with your dataset exploring a wide model space for architectures that achieve low validation loss. A few tips and tricks for this step:

    Теперь вы должны быть «в теме» с вашим датасетом, исследуя широкое пространство моделей в поисках архитектур, дающих низкий validation loss. Несколько советов и трюков для этого шага:

  • random over grid search. For simultaneously tuning multiple hyperparameters it may sound tempting to use grid search to ensure coverage of all settings, but keep in mind that it is best to use random search instead. Intuitively, this is because neural nets are often much more sensitive to some parameters than others. In the limit, if a parameter a matters but changing b has no effect then you’d rather sample a more throughly than at a few fixed points multiple times.
  • hyper-parameter optimization. There is a large number of fancy bayesian hyper-parameter optimization toolboxes around and a few of my friends have also reported success with them, but my personal experience is that the state of the art approach to exploring a nice and wide space of models and hyperparameters is to use an intern :). Just kidding.
  • random search вместо grid search. Для одновременной настройки нескольких гиперпараметров может показаться заманчивым использовать grid search, чтобы обеспечить покрытие всех настроек, но имейте в виду, что лучше использовать random search. Интуитивно это потому, что нейросети часто гораздо чувствительнее к одним параметрам, чем к другим. В пределе, если параметр a важен, а изменение b не имеет эффекта, вы предпочли бы сэмплировать a более тщательно, чем в нескольких фиксированных точках по многу раз. оптимизация гиперпараметров. Существует большое количество модных байесовских инструментов для оптимизации гиперпараметров, и несколько моих друзей сообщали об успехе с ними, но мой личный опыт говорит, что state-of-the-art подход к исследованию хорошего и широкого пространства моделей и гиперпараметров — это использовать стажёра :). Шучу.

    6. Squeeze out the juice

    6. Выжми сок

    Once you find the best types of architectures and hyper-parameters you can still use a few more tricks to squeeze out the last pieces of juice out of the system:

    Как только вы нашли лучшие типы архитектур и гиперпараметров, вы можете использовать ещё несколько трюков, чтобы выжать последние капли сока из системы:

  • ensembles. Model ensembles are a pretty much guaranteed way to gain 2% of accuracy on anything. If you can’t afford the computation at test time look into distilling your ensemble into a network using dark knowledge.
  • leave it training. I’ve often seen people tempted to stop the model training when the validation loss seems to be leveling off. In my experience networks keep training for unintuitively long time. One time I accidentally left a model training during the winter break and when I got back in January it was SOTA (“state of the art”).
  • ансамбли. Ансамбли моделей — это практически гарантированный способ получить 2% accuracy на чём угодно. Если не можете позволить себе вычисления на тесте, посмотрите в сторону дистилляции вашего ансамбля в одну сеть с помощью dark knowledge. оставь её обучаться. Я часто видел, как у людей возникает соблазн остановить обучение модели, когда validation loss, кажется, выходит на плато. По моему опыту сети продолжают обучаться неинтуитивно долгое время. Один раз я случайно оставил модель обучаться на зимние каникулы, и когда я вернулся в январе, это был SOTA («state of the art»).

    Conclusion

    Заключение

    Once you make it here you’ll have all the ingredients for success: You have a deep understanding of the technology, the dataset and the problem, you’ve set up the entire training/evaluation infrastructure and achieved high confidence in its accuracy, and you’ve explored increasingly more complex models, gaining performance improvements in ways you’ve predicted each step of the way. You’re now ready to read a lot of papers, try a large number of experiments, and get your SOTA results. Good luck!

    Как только вы дойдёте сюда, у вас будут все ингредиенты для успеха: вы глубоко понимаете технологию, датасет и задачу, вы настроили всю инфраструктуру обучения/оценки и достигли высокой уверенности в её корректности, и вы исследовали всё более сложные модели, получая прирост качества способами, которые предсказывали на каждом шагу. Теперь вы готовы прочитать кучу статей, провести большое количество экспериментов и получить свои SOTA-результаты. Удачи!