t
кроме памяти, конечно
Size: a a a
2021 February 05
CT
Аттеншен квадратичную сложность имеет от длины
t
а, ну в этом плане да, т.к. нужно посчитать скор перекрестный
VC
А кто-нибудь тестировал Big Bird?
VC
Он там же такой крутой O(n) и точнее, но только все ванильным пользуются...
T
кстати в гпт2, насколько я помню, позишнал эмбеддинги вообще учатся как обычные эмбеддинги
собсна там строгое ограничение по количеству токенов
собсна там строгое ограничение по количеству токенов
t
@Cookie_thief @VadimChashechnikov и извините за еще вопрос тогда - насколько я понял, сколько бы аттеншен-голов у трансформера ни было, их специально выученным кодером сколлапсит в вектор меньшей размерности, который имеет такой же шейп, как у входа слоя.
в illustrated transformer этому далось объяснение в духе не бей лежачего - "так как слой ожидает, что ему дадут по одному вектору эмбеддинга на каждое слово, а не по (количество-голов) векторов, их нужно сколлапсить". при том говорится, что каждая голова аттеншена тренируется отдельно с рандомно инициализированными параметрами, т.е. какой-то магии ассоциированной с головами нет, это простой ансамбль
поэтому вопрос - не происходит ли утери данных при понижении размерности с большого количества голов? и есть ли какие-то причины, почему не передавать в следующий слой в качестве скрытого состояния выхлоп всех голов в виде конкатенированной матрицы?
я так понимаю, одна из причин - это как раз уменьшение количества оптимизируемых параметров, но не в ущерб ли качеству это происходит?
в illustrated transformer этому далось объяснение в духе не бей лежачего - "так как слой ожидает, что ему дадут по одному вектору эмбеддинга на каждое слово, а не по (количество-голов) векторов, их нужно сколлапсить". при том говорится, что каждая голова аттеншена тренируется отдельно с рандомно инициализированными параметрами, т.е. какой-то магии ассоциированной с головами нет, это простой ансамбль
поэтому вопрос - не происходит ли утери данных при понижении размерности с большого количества голов? и есть ли какие-то причины, почему не передавать в следующий слой в качестве скрытого состояния выхлоп всех голов в виде конкатенированной матрицы?
я так понимаю, одна из причин - это как раз уменьшение количества оптимизируемых параметров, но не в ущерб ли качеству это происходит?
VC
Не знаю, потестируй, но вообще это же как densenet будет, которая реально быстро разрастается.
t
ну почему, размерность инпутов будет такая же, как и размерность аутпутов - просто на самом начальном этапе подавать не просто эмбеддинги начального контекта, а контекст, повторенный N раз по количеству голов
t
т.е. в отличие от densenet, тут не будет лавинообразного увеличения размерности с каждым новым слоем
CT
@Cookie_thief @VadimChashechnikov и извините за еще вопрос тогда - насколько я понял, сколько бы аттеншен-голов у трансформера ни было, их специально выученным кодером сколлапсит в вектор меньшей размерности, который имеет такой же шейп, как у входа слоя.
в illustrated transformer этому далось объяснение в духе не бей лежачего - "так как слой ожидает, что ему дадут по одному вектору эмбеддинга на каждое слово, а не по (количество-голов) векторов, их нужно сколлапсить". при том говорится, что каждая голова аттеншена тренируется отдельно с рандомно инициализированными параметрами, т.е. какой-то магии ассоциированной с головами нет, это простой ансамбль
поэтому вопрос - не происходит ли утери данных при понижении размерности с большого количества голов? и есть ли какие-то причины, почему не передавать в следующий слой в качестве скрытого состояния выхлоп всех голов в виде конкатенированной матрицы?
я так понимаю, одна из причин - это как раз уменьшение количества оптимизируемых параметров, но не в ущерб ли качеству это происходит?
в illustrated transformer этому далось объяснение в духе не бей лежачего - "так как слой ожидает, что ему дадут по одному вектору эмбеддинга на каждое слово, а не по (количество-голов) векторов, их нужно сколлапсить". при том говорится, что каждая голова аттеншена тренируется отдельно с рандомно инициализированными параметрами, т.е. какой-то магии ассоциированной с головами нет, это простой ансамбль
поэтому вопрос - не происходит ли утери данных при понижении размерности с большого количества голов? и есть ли какие-то причины, почему не передавать в следующий слой в качестве скрытого состояния выхлоп всех голов в виде конкатенированной матрицы?
я так понимаю, одна из причин - это как раз уменьшение количества оптимизируемых параметров, но не в ущерб ли качеству это происходит?
Эксперименты говорят что ок работает, если ставить меньше голов и больше размерность эмбеддинга будет работать хуже
VC
ну почему, размерность инпутов будет такая же, как и размерность аутпутов - просто на самом начальном этапе подавать не просто эмбеддинги начального контекта, а контекст, повторенный N раз по количеству голов
Сори, я тебя не понял значит
t
Сори, я тебя не понял значит
а, нет, я попробовал объяснить, и понял, что это я не так понял
t
ты был прав, получается рост размерности
2021 February 06
VC
Notion, roam research
А я вот ещё нашел tiddly wiki и obsidian.md. Есть отзывы?
VC
Насколько я понимаю, notion хостится у них на сервере
I
Я видел косвенные признаки, что notion хостится на AWS
D
косвенных? если ты ткнешь на картинку https://i.tk-chel.ru/denisio/202102/06_132848.png то увидишь что она откроется с amazonaws
I
Ну я это я называл косвенным. Потому что если быть занудой до конца, то они могут в АВС хостить только файлы
VC
Я в итоге выбрал obsidian md