Он слишком сильно привязан к генератору, и по факту умеет только его сэмплы от настоящих отличать, да и обучался на довольно странном лосе. Чем то, думается, похоже по природе на adversarial examples, когда незначительные изменения во входе, могут сильно влиять на выход в нужную сторону. Впрочем первые свертки вполне могут выучивать что-то полезное, но это не точно.
На самом деле в Керасе всего хватает. И можно было бы несколько исхитриться и не приплетать сюда tensorflow, просто это было бы менее удобно, например не получилось бы использовать .fit() у модели, так как у моделей различные лоссы и обучаются они поддельности.
Нужно, чтобы модели обучались совместно, и чтобы дискриминатор не слишком обыгрывал генератор (тогда его градиенты уходят в ноль, ибо сигмоида). Эта проблема отчасти решается в Wasserstein GAN. В идеале было бы наоборот обучать генератор каждый раз до сходимости при шаге дискриминатора, но это не реально.
Сначала по второму вопросу. Дискриминатор нужен только чтобы обучать генератор. Без него, генератор бы не мог научиться генерировать сэмплы. Когда генератор обучен, то дискриминатор уже не нужен. Стоит также отметить, что дискриминатор без генератора бесполезен, то есть мы не можем его обучить, а потом использовать для какой-нибудь другой задачи.
По первому вопросу. Мы можем не передавать лейблы в дискриминатор, но он тогда не будет использовать всю доступную информацию, а значит будет тяжелее учиться, что в свою очередь будет влиять на качество градиентов передаваемых в генератор, и он тоже будет хуже учиться.
Можно добавлять, конечно, и я пробовал делать, как вы предлагаете. Мне тоже казалось более рационально добавлять в конце, но работало так похуже, поэтому оставил ближе к началу.
Энкодер восстанавливает вход на выходе, это не задача классификации. А «y» тут вообще не нужны нигде (до conditional моделей), в «у» просто лейблы цифр лежат.
По поводу дропоута, возможно лосс на тесте он бы и не уменьшил, не проверял, если честно. Но во всех статьях, что видел, его используют, так что я просто даже не пробовал его убирать)
А вот по поводу кодов не могу согласиться, когда входная размерность 2, то при размерности кодов, скажем, 100, автоэнкодер бы без проблем выучил тождественную функцию и толку бы от него не было (там же не вае, регуляризации на код никакой нету). Даже при двух это теоритически возможно)
За статью огромное спасибо, прочитаю в ближайшее время!
По поводу дропаута: ну сам по себе он нужен не только для регуляризации, он еще и вынуждает активации в слоях быть более-менее независимыми, например, чтобы одни активация не исправляли другие, а также чтобы следующий слой не слишком полагался на активации конкретных нейронов ниже. Так поидее слои выучиваются более равномерно и больше нелинейностей используется. Я бы сказал, что тут больше претензия к батч-нормализации: по последним данным она куда лучше работает перед активацией, а не после (опять же из-за этого больше нелинейностей в слое появляется).
По поводу одномерности кода: во второй статье было про то, что автоэнкодер выучивает k-мерное определяющее многообразие, где k — размерность кода. В данном случае определяющее многообразие искусственно одномерное, поэтому и код одномерный, больше было бы уже переобучение. На том примере показывается именно то, что в случае без лейблов автоэнкодер вынужден продолжать одну связную область в другую, а в случае, когда есть лейблы он может выучить их по-отдельности.
Могу раскрыть. В VAE + GAN буду избавлять именно от размытостей.
Не могу согласиться. В гистограмме плотность вероятности p(Z) оценивается по количеству X отображенных в нужный интервал по Z. Проходясь по сэмплированной выборке мы и приближаем мат ожидание по p(X). А p(Z|X) в представлении энкодера — это вообще дельта функция.
2) Почти, 101 точек по x и 101 по y, то есть 10 201 точек по координатам и 10 000 по времени (конкретно для того примера). Да, смотрел, примерно половина операций в графе идут на GPU, какие именно не помню, но думаю, что самые основные вроде перемножения или сложения тензоров.
3) C Cython'ом не сравнивал, но время работы сравнимо и даже быстрее моей реализации на С + MPI для курсовой (у меня правда нет уверенности в оптимальности того кода).
Нужно, чтобы модели обучались совместно, и чтобы дискриминатор не слишком обыгрывал генератор (тогда его градиенты уходят в ноль, ибо сигмоида). Эта проблема отчасти решается в Wasserstein GAN. В идеале было бы наоборот обучать генератор каждый раз до сходимости при шаге дискриминатора, но это не реально.
По первому вопросу. Мы можем не передавать лейблы в дискриминатор, но он тогда не будет использовать всю доступную информацию, а значит будет тяжелее учиться, что в свою очередь будет влиять на качество градиентов передаваемых в генератор, и он тоже будет хуже учиться.
Можно добавлять, конечно, и я пробовал делать, как вы предлагаете. Мне тоже казалось более рационально добавлять в конце, но работало так похуже, поэтому оставил ближе к началу.
А вот по поводу кодов не могу согласиться, когда входная размерность 2, то при размерности кодов, скажем, 100, автоэнкодер бы без проблем выучил тождественную функцию и толку бы от него не было (там же не вае, регуляризации на код никакой нету). Даже при двух это теоритически возможно)
За статью огромное спасибо, прочитаю в ближайшее время!
По поводу одномерности кода: во второй статье было про то, что автоэнкодер выучивает k-мерное определяющее многообразие, где k — размерность кода. В данном случае определяющее многообразие искусственно одномерное, поэтому и код одномерный, больше было бы уже переобучение. На том примере показывается именно то, что в случае без лейблов автоэнкодер вынужден продолжать одну связную область в другую, а в случае, когда есть лейблы он может выучить их по-отдельности.
Могу раскрыть. В VAE + GAN буду избавлять именно от размытостей.
Спасибо!
1) Ноутбук Jupyter: http://nbviewer.jupyter.org/github/urtrial/pde/blob/master/partial_differential_equation.ipynb
2) Почти, 101 точек по x и 101 по y, то есть 10 201 точек по координатам и 10 000 по времени (конкретно для того примера). Да, смотрел, примерно половина операций в графе идут на GPU, какие именно не помню, но думаю, что самые основные вроде перемножения или сложения тензоров.
3) C Cython'ом не сравнивал, но время работы сравнимо и даже быстрее моей реализации на С + MPI для курсовой (у меня правда нет уверенности в оптимальности того кода).