Еще один шаг

[ushastyi]

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

Comments

[dr_klm]

Ну, для стандартного минимакса есть альфа-бета отсечение, которое для того и придумано, чтобы не рассматривать заведомо плохие ветви. При его прикручивании к обычному минимаксу глубина перебора повышается и такая программа будет переигрывать исходную.

К.Л.М.

[ushastyi]

Это немного разные вещи. Альфа-бета отсечение не рассматривает заведомо плохие ветви, а ограничение по глубине или вероятностям определяет насколько глубоко надо рассматривать потенциально хорошие ветви. Кроме того, альфа-бета отсечение чувствительно к порядку обхода ветвей.

[dr_klm]

Ну "насколько глубоко" -- это и есть отсечение (альфа-бета или ещё какое).

Кроме того, зависимость результата (окончательных оценок позиций) от порядка обхода ветвей -- лишь следствие того, что граф обходится не полностью. А разве эта зависимость как-то мешает ?

К.Л.М.

p.s. Альфа-бета отсечение я когда-то ещё в школе делал для игры в шашки. Давно это было, мог позабыть чего...

[ushastyi]

Насколько я понимаю, при неограниченном времени разница невелика. При ограниченном -- и порядок обхода имеет значение, и глубина анализа "перспективных" ходов еще большее.

Кстати, одно из следующих направлений исследований, которое предлагают авторы в статье, это использование сети для распределения времени на анализ тех или иных ветвей.

[dr_klm]

Эвристики (а применение нейросетей для оценки позиций я тоже отношу к эвристикам) в шахматных программах используются широко. Да и конкретно нейросети используются для этого с середины-конца прошлого века. Сегодняшняя программа-чемпион Jonny не использует нейросетей (но использует альфа-бета отсечение).

Если программы на нейросетях будут стабильно переигрывать другие программы на том же железе -- это будет для меня новостью, конечно.

К.Л.М.

[ushastyi]

> Если программы на нейросетях будут стабильно переигрывать другие программы на том же железе -- это будет для меня новостью, конечно

[dr_klm]

Пример показывает, что если взять программу и доработать её, то она станет лучше. Так, в принципе, должно быть всегда. Ну, если дорабатывать с умом, конечно. И особенно если исходная программа была "не очень

[ushastyi]

> Идее использования NN в шахматных программах уже десятки лет. Если бы эта идея была продуктивной -- все лучшие программы сейчас использовали бы NN.

Возможно, что не хватало дешевых вычислительных мощностей и тестовых наборов (позиций, партий), которые в достаточном для обучения количестве стали открыто доступны в последние лет 5-10, не больше.

> Вообще NN решает задачу подгонки произвольной неизвестной функции другой функцией, которая имеет огромное число параметров.

Безусловно. Я как-то даже обсуждал этот вопрос менее абстрактно: http://ushastyi.livejournal.com/248444.html

Как говорил Ландау

[son_0f_morning]

Как говорил когда-то известный физик Ландау -- "дайте мне 5 параметров и я нарисую слона".

О_О спасибо
Вот прям недавно с пытался объяснить плохи переоптимизация и подгонка параметров но похоже так и не донёс (дошёл аж до Колмогоровской сложности).

Re: Как говорил Ландау

[dr_klm]

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

К.Л.М.

Re: Как говорил Ландау

[son_0f_morning]

"чем плохи". "чем" в процессе редактирования стёрлось ;)

А если более развёрнуто, то:
1. Переоптимизация -- плохо всегда (тут по определению просто что для одного проекта (способа задания свободных коннстант) "пере" то для другого вполне себе оптимизация).

2. Подгонка (в этой вселенной) -- плохо почти всегда.
те из 2х случаев (дающих сразу после коммита одинаковый эффект)

if (app_name == "gcc") {
RunSpecialGccOptimization()
}

или

// область определения 1.0 - 1.5
// 1.1 - 1.4 "плато" с примерно одинаковой производительностью
// было 1.25 -- ровно середина мы соптимизировали
#define DEFICITE_KOEF 1.203

Первый случай -- вполне может быть оправданным распространённым юз-кейсом
А второй -- почти наверняка чистая переоптимизация которая даёт эффект "здесь и сейчас" с учётом всех остальных коэффициентов и эвристик. И вопрос лишь в том когда (через неделю или месяц) она перестанет работать.