Можете пояснить какие проблемы там были обнаружены?
В случае с датасетами RUSSE и RuCoS, в которых надо ответить сущностью или что-то сказать о смысле слова из предложения, я заметил ряд проблем с соответствием сущностей и сегментов, которые им сопоставлены: например, сегменты включают в себя пунктуацию, пробелы или вообще не те слова, которые должны в них находиться. Это вредит чистоте данных, а соответственно, и качеству моделей: в коде (например, тут) более детально описана суть проблем и исправления, которые применяются при подготовке данных. Как можно видеть по лидерборду, подобные исправления для RUSSE сделали наше решение лучшим по сравнению со всеми другими ML-методами.
На HF Hub у вас лежит только файл модели. Это правильно? Разве там не должен быть рядом сложен vocab и конфиги для токенайзера?
Кажется, всё нужное на месте: по этой ссылке находятся файлы токенизатора (как написано в инструкции на GitHub, они лежат в отдельной папке).
Я бы не стал лишний раз конвертировать модели в TensorFlow без необходимости (скажем, без наличия inference-движка, опирающегося на модели в нужном формате): экосистема PyTorch на текущий момент гораздо богаче, а отличия с точки зрения производительности в стандартных ситуациях бывают в пользу каждого фреймворков и не всегда значимы. Более того, насколько я понимаю, поддержка TensorFlow в целом ослабевает в последнее время на фоне популярности PyTorch.
Использовать эти классы вы в целом действительно можете, но из-за деталей реализации модели (это всё-таки не обычный BERT) загрузить RuLeanALBERT в AutoModel у вас пока что не получится. В качестве решения на текущий момент вы можете использовать реализацию LeanAlbertForSequenceClassification из кода, который мы выложили: общий интерфейс там такой же, как у AutoModel, и, как видно из кода обучения, всё прекрасно работает вместе с классом Trainer из transformers.
какой объем VRAM ей требуется? Хватит 12 Гб у 3060?
На всякий случай специально замерил: в загруженном состоянии модель изначально занимает примерно 2300 MB видеопамяти, при полноценном дообучении на RuCoLA — примерно 10 гигабайт (разумеется, в смешанной точности, но без больших хаков наподобие offloading). Должно хватить в вашем сетапе :)
сколько BERT требует VRAM?
Тут нужно учитывать, что вариаций BERT бывает много: скажем, есть RuRoBERTa-large, которая при обучении в сетапе выше потребляет примерно 7500 MB памяти, а есть rubert-tiny, которая весит десятки мегабайт и сравнительно быстро работает даже на CPU. При этом все модели имеют разный размер и уникальные сильные и слабые стороны; как я писал в посте, выбирать, что использовать, стоит исходя из задачи.
судя по всему, какие-то неподдерживающиеся ТПУ операции
Кстати, технически ничто действительно не мешает использовать и даже предобучать модель нашим кодом на TPU: в частности, в проектах sahajBERT и в особенности CALM волонтёры уже могли пользоваться TPU в рамках эксперимента (код есть в оригинальном репозитории).
Хороший вопрос! Проблема действительно важная: даже один участник может отправлять неправильные градиенты и дестабилизировать обучение, если не предпринимать никаких мер противодействия этому. Здесь в экспериментах мы использовали механизм аутентификации для допуска только доверенных участников, однако есть и более продвинутые методы.
В целом область науки, занимающаяся этой проблемой, называется byzantine-tolerant training, и существует не так мало методов для обеспечения устойчивости. В частности, в ещё одной нашей недавней статье мы предлагаем масштабируемый метод для защиты децентрализованного обучения: он опирается на устойчивую к выбросам агрегацию CenteredClip и идеи из secure multi-party computation для проверки случайного подмножества участников. Уже работаем над его встраиванием в hivemind, stay tuned!
В случае с датасетами RUSSE и RuCoS, в которых надо ответить сущностью или что-то сказать о смысле слова из предложения, я заметил ряд проблем с соответствием сущностей и сегментов, которые им сопоставлены: например, сегменты включают в себя пунктуацию, пробелы или вообще не те слова, которые должны в них находиться. Это вредит чистоте данных, а соответственно, и качеству моделей: в коде (например, тут) более детально описана суть проблем и исправления, которые применяются при подготовке данных. Как можно видеть по лидерборду, подобные исправления для RUSSE сделали наше решение лучшим по сравнению со всеми другими ML-методами.
Кажется, всё нужное на месте: по этой ссылке находятся файлы токенизатора (как написано в инструкции на GitHub, они лежат в отдельной папке).
Я бы не стал лишний раз конвертировать модели в TensorFlow без необходимости (скажем, без наличия inference-движка, опирающегося на модели в нужном формате): экосистема PyTorch на текущий момент гораздо богаче, а отличия с точки зрения производительности в стандартных ситуациях бывают в пользу каждого фреймворков и не всегда значимы. Более того, насколько я понимаю, поддержка TensorFlow в целом ослабевает в последнее время на фоне популярности PyTorch.
Использовать эти классы вы в целом действительно можете, но из-за деталей реализации модели (это всё-таки не обычный BERT) загрузить RuLeanALBERT в AutoModel у вас пока что не получится. В качестве решения на текущий момент вы можете использовать реализацию
LeanAlbertForSequenceClassificationиз кода, который мы выложили: общий интерфейс там такой же, как уAutoModel, и, как видно из кода обучения, всё прекрасно работает вместе с классомTrainerизtransformers.На всякий случай специально замерил: в загруженном состоянии модель изначально занимает примерно 2300 MB видеопамяти, при полноценном дообучении на RuCoLA — примерно 10 гигабайт (разумеется, в смешанной точности, но без больших хаков наподобие offloading). Должно хватить в вашем сетапе :)
Тут нужно учитывать, что вариаций BERT бывает много: скажем, есть RuRoBERTa-large, которая при обучении в сетапе выше потребляет примерно 7500 MB памяти, а есть rubert-tiny, которая весит десятки мегабайт и сравнительно быстро работает даже на CPU. При этом все модели имеют разный размер и уникальные сильные и слабые стороны; как я писал в посте, выбирать, что использовать, стоит исходя из задачи.
Кстати, технически ничто действительно не мешает использовать и даже предобучать модель нашим кодом на TPU: в частности, в проектах sahajBERT и в особенности CALM волонтёры уже могли пользоваться TPU в рамках эксперимента (код есть в оригинальном репозитории).
Хороший вопрос! Проблема действительно важная: даже один участник может отправлять неправильные градиенты и дестабилизировать обучение, если не предпринимать никаких мер противодействия этому. Здесь в экспериментах мы использовали механизм аутентификации для допуска только доверенных участников, однако есть и более продвинутые методы.
В целом область науки, занимающаяся этой проблемой, называется byzantine-tolerant training, и существует не так мало методов для обеспечения устойчивости. В частности, в ещё одной нашей недавней статье мы предлагаем масштабируемый метод для защиты децентрализованного обучения: он опирается на устойчивую к выбросам агрегацию CenteredClip и идеи из secure multi-party computation для проверки случайного подмножества участников. Уже работаем над его встраиванием в hivemind, stay tuned!