AdaGrad's per-parameter scaling is a good idea, but its sum never stops growing. Both methods in this lesson repair that by forgetting.
RMSProp
Replace the running sum of squared gradients by an exponentially decaying average:
with . Old gradients fade away, so tracks the recent size of the gradient instead of growing forever. The name comes from the denominator: is a root mean square (RMS) of recent gradients.
Because the step is times "gradient divided by its typical size", each parameter moves by roughly per step whatever the scale of its gradient. A parameter with tiny gradients and one with huge gradients both take steps of about the same size.
How it behaves
On the sigmoid toy problem, RMSProp with has the loss below for good after roughly 100 to 160 steps (RMSProp keeps jittering close to the threshold, so the exact step changes with tiny numerical differences), against 183 for plain gradient descent at its best rate of 1.
There is a catch in that scale-free step. Near the minimum, the gradient becomes small, but shrinks along with it, so the step stays about in size. The parameters then bounce around the minimum instead of settling. On the narrow valley with :
- the loss never stays below : after several hundred steps it sits at ,
- the parameters end up alternating around , which is either side of the minimum.
The remedy is a schedule from the previous lesson. Decaying the rate as brings the loss to after 2000 steps, instead of stalling at .
The learning rate still matters
The rate means something different here: it is approximately a distance per step. That makes it easier to choose when gradients vary widely in scale, but it still has to fit the problem. The table shows the steps needed on the sigmoid toy problem (blank means it never settled in 3000 steps, or diverged):
| Rate | Plain GD | RMSProp |
|---|---|---|
| 0.03 | none | 129 |
| 0.1 | 1815 | about 100 to 160 |
| 0.3 | 606 | about 3000 (barely settles) |
| 1 | 183 | none |
| 3 | 62 | none |
| 10 | 15 | none |
Plain gradient descent needs a large rate here because the gradients on this problem are small. RMSProp is happy with small rates but, with of 1 or more, takes steps larger than the whole problem and never settles. There is no rate that is best everywhere.
AdaDelta
RMSProp's update is unit-inconsistent: the parameter change should have the units of the parameter, but has the units of . AdaDelta (Zeiler, 2012) fixes this by replacing with a running RMS of past updates, so no learning rate is needed:
and . Here .
So the method needs no initial learning rate. The catch is how it starts. At step 1 the average of past updates is 0, so the numerator is , and with the first steps are tiny, about 0.0045 per parameter on the valley and about 0.0035 to 0.0039 on the toy problem, whatever the gradient. They grow as the running average of updates builds up. The result on these problems is a slow start:
| Problem | Loss after 100 steps | Steps to stay below threshold |
|---|---|---|
| Narrow valley | 1.96 | never within 3000 |
| Sigmoid toy problem | 0.40 | 348 |
The constant quietly plays the role of the learning rate at the start. A larger gives bigger initial steps.
Summary so far
| Method | What it keeps | Result |
|---|---|---|
| AdaGrad | sum of squared gradients | rate shrinks forever |
| RMSProp | decaying average of squared gradients | rate adapts, but steps stay about |
| AdaDelta | decaying averages of gradients and of updates | no learning rate to tune, slow start |
Try the preset where RMSProp jitters, then add a decay schedule.