Why the first DLManaka self-play loop plateaued
Historical diagnosis from 2026-08-12/13. The first loop improved once, then stopped. This page keeps the measurements that changed the design; the long survey of possible causes has been removed.
Symptom
At 32 simulations per move:
| child | parent | training data | result |
|---|---|---|---|
| gen2 | supervised 100k | 434k positions × 4 epochs | +74 Elo |
| gen3 | gen2 | 430k × 4 epochs | +4.1, not significant |
| gen3' | gen2 | 1.72M × 1 epoch | +11.7, not significant |
Quadrupling the fresh data improved validation policy loss but did not improve head-to-head strength. Data volume alone was therefore not the missing lever.
Internal versus was not enough
A replay-window experiment appeared to beat its sibling by +29.9 Elo internally. External measurement against fixed YaneuraOu KP256 @10k reversed the conclusion:
| net | Elo vs fixed reference |
|---|---|
| gen3' | +13.2 |
| replay-gen123 | −7.1 |
With 4,000 games each, gen3' was about 20 Elo stronger against the external reference even though replay-gen123 won their direct match.
This established the standing measurement rule:
Internal child-vs-parent games can choose a parent, but they do not establish that the engine became stronger at shogi. A fixed external anchor must agree.
Replay buffers may still be useful, but this experiment did not demonstrate a strength gain from one.
The decisive result: search was too shallow
The same weights were compared at 256 versus 32 simulations, with no training change:
| result | |
|---|---|
| score | 0.9611 over 180 games |
| Elo | +557 |
This was much larger than all data/training changes in the first loop. The network was already stronger than the 32-simulation search used to generate its teaching targets.
Batched evaluation was then implemented so deeper search could be afforded. Batch 1 reproduced sequential search exactly; wider batches improved throughput but could cause descents to collide on queued leaves, reducing distinct nodes. This is why batch width must rise with the simulation budget rather than independently.
External position after the search fix
At 256 simulations, measured against fixed YaneuraOu KP256:
| opponent budget | DLManaka Elo |
|---|---|
| 10k nodes | +416.6 |
| 100k nodes | −121.4 |
| 950k nodes, about 1 s | −609.0 |
The remaining gap was largely a search-time handicap: the reference evaluated far more nodes in the same wall-clock time.
Measurement traps found
Use nodes, not byoyomi, for fixed YaneuraOu budgets
YaneuraOu's NetworkDelay settings reduce effective byoyomi. A nominal one-second command can therefore search only a fraction of a second. For reproducible anchors, use go nodes N or explicitly neutralize the delay settings.
Keep probe stdin open
Sending quit immediately after go can terminate a manual probe before search starts and produce a misleading nodes 0. Keep stdin open long enough when debugging the engine directly.
What changed after this record
The later loop adopted deeper/batched search, a larger replay window and gating; the gen11 state and the latest documented priorities are summarized in the improvement plan.
The important conclusion from this historical page is narrower:
- simply increasing same-distribution game count was not enough;
- internal Elo could give the wrong architectural conclusion;
- the first plateau was dominated by an underpowered search teacher.