не используй метод decode с параметром clean_up_tokenization_spaces=True !

https://huggingface.co/transformers/model_doc/bert.html#berttokenizer

Never split там

tokenizers нормализует пробелы между словами (и апострофами). оно отличает слипшиеся слова и разделённые слова, а вот метод decode с этим параметром некорректно слепляет слова.

а как его применить в данном случае?

Да это не к вордpiece

Действительно

>Вопрос почему так сделано и как исправить ситуацию?
Почему так сделано — люди часто пишут апострофы неправильно, разделяя слова пробелами. Поэтому считают апостроф знаком препинания. Если бы он был буквой алфавита — то обрабатывался бы правильно. Для этого надо переучить модель, скорее всего. Без переучивания вряд ли ручка будет.

да, в sentencepiece пробел явно в символы попадает, а здесь неявно токены пробелом разделяются.

Похоже что если тут слова с апострофами к additional special tokens добавить то они не будут никакой токенизацией делиться и wordpiece   тоже https://huggingface.co/transformers/main_classes/tokenizer.html#transformers.PreTrainedTokenizer

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

Тогда ситуация будет ещё хуже - все слова и апострофы будут разделены, в нормальный текст это уже не склеишь.

Так они и так уже разделены после encode... Используй свою нормализацию просто

В смысле написать свои правила по типу: "isn ' t" -> "isn't"?

Ага

Для английского языка правил с апострофами всего штук 5 :)

Кто-нибудь разворачивал в продакшен ml-модели в связке flask+gunicorn. Когда ставишь несколько worker'ов то создается несколько экземпляров самой модели потому что на каждый экземпляр app свой экземпляр модели, которые получается используют общие ресурсы (сохраненные на диск пайплайны). Проблемы возникают когда надо переобучить модель на новых месячных данных, например, потому что встает вопрос синхронизации. Какая архитектура в данному случае верная? Делать несколько docker контейнеров, которые будут обмениваться сообщениями?

У меня такое, переобучал на ноуте (модель относительно небольшая), собирал новый докер-образ, заливал в свой docker registry, потом на сервере обновлял из регистри и перезапускал.
Но у меня только один инстанс докера запущен (а внутри докер контейнера 10 воркеров gunicorn)

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

Просто хотелось сделать автоматическое, чтобы по расписанию модель из бд собирала новые данные, переобучалась

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