⏱️ Дуэль тайм-политик: empirical-v1 против legacy-linear-v1
О чём это
Гипотеза родилась в разборе корпуса:
TimeManagerстартовал сBaseMovesToGo = 30, тогда как медианная партия живёт 12 ходов. Движок 1.14.0 ввёл настраиваемые политики, иempirical-v1стал дефолтом. Здесь — замер, который проверяет, было ли это улучшением. Сырые данные: приватныйdicechess-ev,logs/timed-duel-policy-2026-08-18/.
Результат
Одна и та же KCP-модель аналитики, один и тот же одноплайный поиск с обеих сторон, зеркальные кости, контроль 5+3 (ладдерный). Различается только то, как TimeManager распределяет часы по ходам.
| Партий | 4 220 (2 110 зеркальных пар) |
| W/L/D | 2190/2030/0 |
Win rate empirical-v1 | 51.90% |
| ci95 | ±0.99 пп → [50.90%, 52.89%] |
| Поражений по времени | 0 / 0 |
| Провалов чанков | 0 |
Около +13 elo. Устойчиво по половинам: 52.19% и 51.60%, у каждой ±1.4 пп.
Практический вывод: смена дефолта на empirical-v1, которая в движке уже произошла, для дорогих одноплайных ботов — улучшение, а не риск. Боты доходят до неё через совместимый TimeManager.budgetMs, то есть бамп движка переключает их без правки конфига; теперь известно, что переключение полезно.
Главное здесь — не число
Политика способна что-то изменить только там, где бюджет связывает. Если поиск заканчивается задолго до дедлайна, распределять нечего, и любая дуэль намеряет шум вокруг 50%.
Проверяется это без дуэли: прогнать каждую политику саму против себя и сравнить трату. Четыре минуты вместо суток.
| поиск | empirical-v1 p50 | legacy-linear-v1 p50 | вывод |
|---|---|---|---|
| oracle-3, K=24 | 412 мс | 404 мс | неотличимы |
| oracle-3, K=48 | 3883 мс | 3849 мс | неотличимы |
| KCP, one-ply | 2844 мс (p95 42.9 с) | 7934 мс (p95 13.8 с) | расходятся → замерено |
| oracle-3, K=all | 12 346 мс (p95 41.6 с) | 10 201 мс (p95 13.9 с) | расходятся → отдельный прогон |
При K=24 на 5+3 боту доступно 14–20 с на ход, а тратит он 0.4 с. Именно это и предсказывал разбор корпуса: с трёх минут часы перестают быть ограничением, «дополнительное время не расходуется».
Числа сходятся с кривыми, а не просто различаются
empirical-v1закладывает ~7.5 своих ходов впереди → 300 с / 7.5 ≈ 40 с на ход, замеренный максимум 43 с.legacy-linear-v1закладывает ~29 → ≈10 с, замеренный максимум 13.8 с. Это сильнее простого «политики различаются»: совпадает механизм, а не только факт.
Чего замер НЕ говорит
⚠️ Он ничего не говорит про ладдерную конфигурацию oracle-3 при K=24 или K=48. Там политики неотличимы по трате времени, то есть эффекта нет ни в ту, ни в другую сторону. Переносить +13 elo на дешёвых ботов нельзя.
⚠️ Он про один контроль. Урок дуэли candidateLimit прямо применим: там эффект разворачивался по контролю — слабее на 2+1, сильнее на 10+10. Политика, выигравшая на 5+3, ничего не обещает на 1+0, где бюджет вчетверо меньше и жадная раскладка может обернуться цейтнотом.
⚠️ Диагностика «сам против себя» короткая (8–14 ходов), поэтому у неё надёжен порядок величин, но не форма хвоста.
Операционное
Прогон шёл без sbt (java -cp напрямую): тонкий клиент sbt 2 виснет с нулевым CPU, и однажды это стоило 6 ч 43 мин молчаливого простоя. Чанк считается готовым только при наличии JSON — прежний цикл писал «done» безусловно и превращал провалы в мнимые успехи.
Переключение на следующий замер сделал супервизор: цикл рассчитан на 400 чанков, далеко за цель, поэтому он опрашивал сводный ci95 раз в 15 минут, остановил дуэль при 0.9931 пп и через 8 секунд поднял прогон K=all. Кредит, на который всё считается, сгорает по календарной дате — простой между замерами это потраченные деньги, а не сэкономленные.
Связано: corpus-time-and-game-length · candidate-limit-48-vs-24-timed-duel · bot-is-not-stupid-but-slow