?

Log in

No account? Create an account

Компьютерная лингвистика

Новостная лента www.solarix.ru

Previous Entry Share Next Entry
Визуализация влияния batch_size на качество модели wordchar2vector - ч.2
kelijah
В комментарии к предыдущему посту коллега p2004r подсказал замечательную мысль по поводу того, что надо бы смотреть не на количество эпох, а на количество градиентов, которые увидела сетка при обучении. И получается вот такая замечательная картина.

1) Смотрим по-старому, динамика обучения в зависимости от числа эпох:


2) Теперь то же самое, но в зависимости от количества батчей (масштаб по OX сделан криво, поэтому цена деления такая странная - надо домножать на число сэмплов в обучающем датасете):



То есть начиная с какого-то размера батча (>100 в данном случае) сетка обучается примерно с одинаковым темпом для разных batch_size. Разница только в том, что для каких-то значений обучение обрывается раньше, и максимальная точность не достигается.

Новая тетрадка выложена в репозиторий.

PS: сделан расчет еще для нескольких batch_size и получился вот такой график максимально достижимой точности:


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

Можно автору keras в git такое предложение о развитии функций пакета добавить.

В Keras уже все есть, в частности fit* методы возвращают объект класса History с историей метрик при обучении. Подпихнуть данные из него в matplotlib тоже пустяшное дело.

При необходимости можно воспользоваться штатным механизмом колбэков https://keras.io/callbacks/ и добавить что-то свое, сохранять хоть в БД.

А переход от эпох к батчам в принципе делается тривиально.

Когда пользователь делает отображение результатов оптимизации значений гиперпараметров процесса обучения сети готовый метод следящий за тем, что по "оси Х" "не откладываются килограммы с секундами" не помешает.

Иначе зачем там вообще введен "объект", который не имеет "методов" учитывающих "его природу и размерность"? Генерик функция "нарисовать" должна принимать несколько объектов истории и учитывать ситуацию изменения размера batch.

PS Вообще все эти "эпохи" (которые то и "логичны" только когда не написан fit-генератор и сделана заглушка для простых случаев train), по сути имеем решение сделанное от рандомизации "в стиле складного ножа", и еще большой вопрос как оно соотносится по эффективности с простой "выборкой с возвращением"...

Обычно простой бутстреп лучше чем "складной нож".

Ну вот выкиньте из fit-генератора этой задачи условие "обходить все случаи в обучающей выборке каждую эпоху строго по одному разу"?

Edited at 2018-03-17 05:56 am (UTC)

>Обычно простой бутстреп лучше чем "складной нож".

>Ну вот выкиньте из fit-генератора этой задачи условие "обходить все случаи в обучающей выборке каждую эпоху строго по одному разу"?

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

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

  • 1