explain this briefly in plain english:

The training loss consistently heads down, which is normal since neural networks rarely
underfit the data. When our model trains on a specific set of data and sees the same
data over and over (that’s what an epoch is: seeing all the data once), the model gets
unreasonably good at predicting the right answer for the training data. That’s classic
overfitting, which occurs to different degrees depending on how big your network is.
We expect the training loss to always go down, so it isn’t a good source of information
about how well the learning is going. But if we look at the test loss, we see that it does
not consistently get better with each epoch. The test loss begins to stabilize or plateau
after a certain point.
If the test loss has stabilized, that would be a good time to reduce the learning rate.2 If
we are already at an optimal location, reducing the learning rate will not hurt anything.
If we are bouncing around a better solution, reducing the learning rate can help us
improve based on the same logic we used to justify exponential decay. But now we are
reducing the learning rate when doing so appears necessary based on the data, rather than
based on a fixed arbitrary schedule.
This is the idea behind the reduce learning rate on plateau schedule, implemented by
the ReduceLROnPlateau class in PyTorch. This is also why the step function needs the
last validation loss passed in as an argument in our code, which looks like
lr_schedule.step(results[”val loss”][-1]). That way, the ReduceLROnPlateau class
can compare the current loss to the recent history of losses.
ReduceLROnPlateau has three primary arguments to control how well it works. First
is patience, which tells us how many epochs of no improvement we want to see before
reducing the learning rate. A value of 10 is common, as you don’t want to drop the
learning rate prematurely. Instead, you want some consistent evidence that no more
progress is being made before changing speed.
The second argument is threshold, which defines what counts as not improving.
A threshold of exactly 0 says that we are improving if there is any amount lower than
the previous best loss in the past patience epochs. That might be too pedantic because
the loss could be decreasing by tiny but meaningless amounts every epoch. If we use
a threshold of 0.01, we are saying that the loss needs to decrease by more than 1% to
count as an improvement. But that could also be a little too loose: when you train for
hundreds of epochs, you could be making slow but steady progress, and reducing the
learning rate is unlikely to speed up convergence. It can take some work to setting this
just right, so we stick the default value of 0.0001, but this is a hyperparameter worth
playing with if you want to squeeze out the maximum possible performance.
2 If the test loss starts increasing, which indicates more severe overfitting, that is another good reason to slow
down learning. That helps slow the overfitting. But ideally, the test loss has stabilized.168 CHAPTER 5 Modern training techniques
The last parameter is the factor by which we want to drop the learning rate η every
time we determine that we have hit a plateau. This works the same way γ does for the
StepLR class. Again, values in the range of 0:1 to 0:5 are all reasonable choices.
But we need to recognize one critical thing before using the ReduceLROnPlateau
schedule: you can’t use the test data to choose when to alter the learning rate. Doing
so will cause overfitting because you are using information about the test data to make
decisions and then using the test data to evaluate your results. Instead, you need to have
training, validation, and testing splits. Our normal code has been using validation as
the test data, which was fine because we were not looking at the validation data to make
decisions while training. The process of ReduceLROnPlateau with this important detail
is summarized in figure 5.10