Несмотря на полное отсутствие публичных датасетов, после трудного и одинокого похода мы-таки опубликовали библиотеку silero-stress (статья на Хабре), которая:
Расставляет ударения в обычных словах, расставляет ударения в омографах, расставляет буквы ё
Занимает порядка 50 мегабайт места (сжатие данных в 400 раз)
Работает на 1 потоке процессора, занимает 0.5ms на 1 обычное слово и порядка 30ms на 1 предложение с 2 омографами
Покрывает ~4.1M слов и словоформ на русском языке с точностью 100% (до качества нашего словаря)
Покрывет порядка 2К омографов с F1 0.85, средней точностью по омографам в 91% и средней точностью по датасету в 93%
Основана на приватном датасете в 120М предложений и словаре в ~4.1М слов
Предсказывает ударение в новых / неизвестных / придуманных словах с точностью до 60-70%
Опубликована под популярной лицензией (MIT), не содержит телеметрии, связки с экосистемами, ключей, регистрации, подписок
Максимально упрощена и минифицирована и не содержит зависимостей кроме стандартной библиотеки питона и PyTorch
Работает с последними актуальными версиями питона и PyTorch
И еще, зачем ставть знак '+' перед всегда ударной 'ё'?
То, что ё всегда ударная, это верно в 95% случаев, но строго говоря это не так. Плюс бывают слова с двумя буквами ё. Значит по закону Оккама проще не делать отдельное правило, а просто ставить ударение всегда даже на букву ё.
В русском языке во всех словах, где присутствует буква ё, ударение обязательно падает на неё. Исключением являются заимствованные (сёгун, сёрфингист, кёнигсбергский) и сложные, составные слова (трёхярусный). Также в группу исключений входят формы косвенных падежей (родительного, дательного и предложного) числительных "триста" и "четыреста": трёхсот, трёмстам, о трёхстах; четырёхсот, четырёмстам, о четырёхстах; слова с побочным ударением, например, самолётостроение; и ещё слово-неологизм ёфикатор = программа, которая умеет превращать в тексте букву Е в букву Ё где нужно.
—
print(accentor(sample_sent, put_stress=False, put_yo=True, put_stress_homo=True, put_yo_homo=True, stress_single_vowel=False)) выдает:'Мо+я мать, м+оя посуду, рассказала о нём, что он нем. Ну... Говорить не умеет. И с этого момента всё завертелось, и все завертелись. А ёлка моей сестр+ы засияла!' Т.е. омограф 'все' в 'все завертелись' остался не обработанным.
Ну омограф-то обработался, просто ударение пропустилось из-за флага stress_single_vowel=False, который вы поставили.
То будет так: Мо+я мать, м+оя посуду, рассказала о н+ём, что он н+ем. Ну... Говорить не умеет. И с этого момента вс+ё завертелось, и вс+е завертелись. А ёлка моей сестр+ы засияла!
То всё будет в порядке. Ведь слова нем / нём / все / всё имеют всего 1 гласную, вот и пропускаются.
Добавили несколько QoL изменений, о которых попросило комьюнити, а так же внесли немного фиксов и обновили документацию.
Модели можно использовать на CPU/GPU. Примеры тут.
Добавили флаги put_stress, put_yo, put_stress_homo, put_yo_homo, которые позволяют включать/выключать простановку ударений и/или буквы ё как в обычных словах, так и в омографах.
Добавили флаг stress_single_vowel, который отвечает за расстановку ударений в односложных словах.
Добавили пример, как расставлять ударения в обычных словах и в омографах независимо друг от друга.
Пофиксили небольшой баг — акцентор удалял символы переноса строки из исходного текста.
С одной стороны - расстановка знаков препинания более простая задача, т.к. для неё тривиально фармить датку.
С другой - она более необъятная и склонная к большим моделям.
С третьей - пользы на практике от неё на порядок меньше.
С четвёртой - в устной речи не действуют законы расстановки знаков препинания и живые люди говорят совсем иначе, нежели чем принято писать. Ну то есть половина всей речи (условно) не поддаётся ей в той или иной степени.
Вся история языка - это его "порча". Люди "и так понимают всё", а в быту и па письме всё диктуется законом языковой экономии.
Наш алфавит и система письма практически минималистичны и основаны на морфологическом принципе орфографии. То есть всё прекрасно, если, конечно, знать ударение наперёд.
Поэтому вы по сути предлагаете пойти против законов развития языка и 400 лет языковой традиции.
Поэтому в древности люди пользовались древнегреческим
Времени было побольше, а сейчас английский язык общения. А там вообще с правилами чтения полная жесть. Но проще, чем в китайском.
Тут можно заметить только, что у нас тулза для расстановки ударения в предложениях / нескольких предложениях, а не книгах целиком.
То есть знак переноса строки действительно лучше не удалять при санации (или потом возвращать назад), но если засунуть в инструмент целую главу или страницу книги - работать, понятное дело, не будет, или будет работать хуже.
Конкретно с инсертами в базу есть простейшее архитектурное решение, собирать транзакции в батчи (и разнести отправку в очередь и отправку в базу на два разных воркера / процесса / executor-а). И имхо, тут ограничения будут скорее уже на стороне базы в любом серьёзном проекте.
with ThreadPoolExecutor(max_workers=n_requests) as executor:
Я понимаю, что вы иллюстрируете краевые случаи тут. Но нужно конечно быть самим себе злым буратино, чтобы создавать 10,000 потоков.
Моё личное мнение - что less is more, и ко всем этим интерфейсам (multiprocessing, threading, asyncio) их комбинациям надо прибегать, если ОЧЕНЬ понятно зачем и почему вы делаете.
В примере с базой - если наивное решение в вашем случае даёт x10 пропускной способности, может x1000 и не нужна. You are not Google.
Ну то есть формулировать вывод, имхо надо так, что для каждой задачи свой инструмент, но есть существенный элемента хайпа, который надо разумно анализировать.
Короткий ответ - потому что нейросетки выучивают просодию из данных. И иногда там есть так называемый inductive bias (крутилки для юзера по-простому), которые учитывает сетка. В новых сетках крутилок меньше.
А чем более новый и огромный синтез - тем он лучше выучивает что-то, но непонятно что.
А старый синтез весь был грубо говоря на хардкоде. У нас в нашем старом синтезе тоже вот такие рофлы работали. А в новом такого веселого ада уже нет.
Все это гуглится за 10-30 минут. Это даже не против мамкиных хакеров действительно, а лишь их личинок. Которые купюры на ч/б ксероксе копируют. И, как понял, после вашего ответа, редактирование поста мне стало недоступно.
Ну гуглить ещё надо уметь, плюс на инглише. Надеюсь, что мошенники им владеют меньше) А вы помогли им, своим постом, азазаза, живите с этим
Про метрики я говорил про Vosk. Это быстрая модель, плюс-минус сопоставимая с вашей.
Про VITS с вами абсолютно согласен.
Насколько я знаю они сидели на витсе, а потом перешли на флоу матчинг модели. Мы гоняли и оригинальные модели авторов статей и их пре-трейн, и с точки зрения продукта эти архитектуры нас не впечатлили. Они скорее приносят больше проблем, чем решают.
Что касается скорости, обычно сравнивают со старой медленной моделью, потому что v4 не торт. Наши текущие актуальные модели ~ на порядок быстрее. Плюс никто никогда не пишет сколько это потоков, на каком процессоре. Там мягко говоря можно взять оверклокнутный процессор на 5 гигагерц и подогнать всё к нужным параметрам. А менее оптимизированные модель могут жрать процессора в 2-3 раза больше на самом деле при "такой же" скорости.
При этом есть и много других критериев, в которые мало смысла погружаться. Но тут не буду прямо пускаться в рассказ, достаточно качественно оформлять наши выводы для публичного использования - лень, да и мало смысла. А иначе можно скатиться в такое.
Я понимаю, что на длине метрики с чем-то коррелируют, но в статьях всегда очень странное видение мира, и синтез реально "обогнал" реальный мир ещё во время второго такотрона. Особенно забавно анализировать perceptual метрики и следование интонации, когда у исследователей нет ground truth того как сами дикторы говорят.
Мы гоняли perceptual метрики на спикерах на разных языках на разных микрофонах - там тупо от языка, ресепмлинга, формата исходного файла, голоса или настроения диктора могут метрики меняться на 0.5 - 1 (из 5 баллов). При этом мы игрались оценкой обычных людей - они перестали по 1 фразе отличать синтез ещё года 3+ назад. А в телефонном канале в 8 килогерц и тому подавно.
С абзацами у всех проблемы. Но тут имхо нужны совсем гигантские модели. Либо будет звучать плоско. То есть как бы синтез будет нашколен на абзац, а на 1 фразу. То есть на втором абзаце станет понятно, что синтез.
И это, конечно, без музыки, в 48 kHz, в наушниках, молодыми ушами, без шума на фоне.
Кстати, раз уж зашел разговор про метрики, позвольте обсудить один вопрос. Есть старые "быстрые" синтезаторы. Фонетика — ахтунг и максимум удовлетворительно, просодия и интонирование — хорошо и местами отлично. Даже стихи заходят в их исполнении (некоторыми). Получше, чем половина школьников на уроке декламирует. Есть новые нейросетевые синтезаторы. Как достаточно быстрые, так и медленные. Фонетика — хорошо и местами отлично, просодия и интонирование — деградация, местами сильная. Причем практически независящая от ресурсоемкости.
Ну кожаные ублюдки, потраченный перевод и подобное - банально смешное само по себе. Это раз, оно не дошло до uncanny valley.
Чем больше или новее модель, тем она более "end-to-end". То есть грубо говоря труд инженеров заменяется на "GPU go brrrr" в широком смысле. То есть не делается отладка всего, сравнение разных систем, взвешивание за и против, длинный путь по допиливанию напильником.
Это не хорошо и не плохо (более того во многих областях ML это дало кембрийский взрыв возможностей), просто становится меньше "крутилок" и больше соблазн "закинул всё и пусть оно само так учится". А модели, чем более продвинутые, тем более "умные" по-своему, то есть они хорошо всасывают домен, и как бы не торопятся генерализовываться, если прямо сильно палками не бить. Отчасти многие генераторы картинок в поздней версии стали выдавать одно и то же рафинированное и скучное - будто финально оверфитнулись все на один сет красивых картинок. Хотя недавно я пробовал nano banana от гугл и был в принципе удивлён. Но уже давно перестал следить в чём там фишка.
Соответственно получаем высокие метрики звучания, но при этом само звучание может быть скучным и нет никаких крутилок. Ну или крутилки в духе "вкидывай промпт, с 100й попытки чет получится, но и то будет на рандоме".
просодия и интонирование — деградация, местами сильная.
Думаю хороший пример тут - вокалоиды. Просто определение проклятого синтеза и контроля. Там буквально можно пением до % тона управлять и приёмов пения. Но в интернете мемов про то, что Хацуне Мику не умеет говорить по-английски - тысячи с миллионами просмотров.
При этом сделать качественный хорошо поющий синтез - это задача со звёздочкой, ну или как минимум немалая работа. Если честно я хз как он сделан у сервисов генерации музыки. Моя догадка, что там присутствуют "голливудские" банки условно всей лицензированной музыки. Аранжировки там точно часто не MIDI, а реальные шаблоны из реальных записей. Что касается редактирования поющего голоса - тут есть ряд идей, но как минимум это отдельная работа со всеми вытекающими. Но Хацуне Мику хорошо поёт … и плохо говорит. А тут наоборот.
Это принципиальная невозможность заложить их в новый пайплайн (обучение-MEL-вокодер)? Или просто создатели новых моделей настолько увлеклись новыми технологиями, что забили болт и видят только фонетику? В лучшем случае тянут тяжеленный непредсказуемый BERT, с таким же непредсказуемым результатом.
Тут не могу за всех сказать. Могу сказать, что как и в IT присутствует огромный культ-карго, "неповторимые" эксперименты, парки на сотни тысяч GPU и прочий пузырь. Ну и если представить, что вы ТРУЪ рисёрчер, и хотите потратить два годика, чтобы сделать лучший мире маленький, компактный классный синтез. Вам нужно как-то обойти все эти ваши "стартапы" с US$100m финансирования и опен-ай-ай. Отсюда наблюдаем, что наблюдаем. Кембрийский взрыв систем синтеза, где по сути одна и та же идея в виде LLM и GPU go brrrr.
Более того, найти вашу ver.3 мошенникам не представляет ни малейшей сложности. То есть можно было не улучшать качество, но в ухудшении точно смысла не много.
Ну тут вы получается спорите с нами, но 3-4 года назад. Ситуация тогда была совсем иная. Мы видели проблему в моменте, и решали её как могли, тогда этого всего или не было, или оно было менее на слуху, на порядок.
синтезаторы с вообще клонированием голоса, раздолье для мошенников
По поводу на чём базируются мошенники - я бы не писал (удолите), т.к. они потом будут использовать Хабр как базу знаний для этого в поиске. У этих решений есть свои моменты, но для генерации 10 аудио можно использовать вообще всё что угодно, хоть платные сервисы дорогие.
которые по метрикам приблизились к Яндекс/Edge и опередили вашу ver.3
Тут я бы поспорил, но не с точки зрения абстрактного "качества звучания", оно у моделей класса VITS или "больших" моделей или моделей на основе flow matching-а действительно чуть "бархатнее", а с точки зрения реальной применимости:
По ресурсам там как правило всё довольно печально. VITS можно натянуть на глобус, но с проблемами. Маленькие flow matching модели, имхо теряют свою фишку по сравнению с большими, а большие сразу получают ярлык GPU-only и на два порядка медленнее ПОСЛЕ всех оптимизаций;
Небольшой прирост качества звучания идёт ценой сильно более высоких вычислительных ресурсов и стабильности. То есть если с нашими актуальными моделями мы боремся с ударениями и какими-то странными краевыми кейсами у клиентов, то с новыми моделями мы ловим краевые случаи и нестабильности сразу при "лакмусовых" тестах при оценке адекватности технологии;
При этом фишка в виде разнообразия генерации прикольная, как мне кажется. Но тут tech отрасль и академические метрики, как мне кажется, идут немного вбок. Но если писать про это - это уже отдельная большая статья, да и вряд ли у неё найдутся читатели (в одиночку не перебить шквал контента AGI is near), тут поможет только прорыв пузыря.
Про пиратские решения или решения за облаком гига-корпораций я не буду комментировать)
Когда мы делали релиз 4й версии, мы увидели, что нашу говорилку используют мошенники при звонках, поэтому скрутили звучание.
В ближайшее время мы планируем сделать релиз 5й версии, там будет ускорение синтеза ещё в несколько раз, повышение качества, и упаковка модели омографов прямо в модель синтеза речи.
Да не, я в всё понял, по сути вы просто привели пример ещё более экзотического "омографа", но у вас от смысла меняется звучание, а не ударение (хотя это близкие понятие). Есть нечто похожее в обычных омографах, это слова Один и одИн. Тоже разные языки как бы.
Просто ваш пример мне напомнил про более частотный кейс с шинелями. Я к тому, что на самом деле бездна всего такого, что учесть крайне сложно.
Ох, тут есть ещё бездонная бездна иностранных слов, которые читаются не по правилам, типа шинель / панель / Нинель, мы в нее пока только заглядывали, но пока контакт не наладили. Это скорее имеет отношение уже к синтезу, но в каком-то смысле это похоже на постановку буквы ё.
Имхо, лучше использовать общепринятую конвенцию из фреймворка, чем плодить параметр, но в документацию это конечно забыли добавить, да и изначально не планировали такой метод, его просто забыли удалить.
Несмотря на полное отсутствие публичных датасетов, после трудного и одинокого похода мы-таки опубликовали библиотеку
silero-stress(статья на Хабре), которая:Расставляет ударения в обычных словах, расставляет ударения в омографах, расставляет буквы
ёЗанимает порядка 50 мегабайт места (сжатие данных в 400 раз)
Работает на 1 потоке процессора, занимает 0.5ms на 1 обычное слово и порядка 30ms на 1 предложение с 2 омографами
Покрывает ~4.1M слов и словоформ на русском языке с точностью 100% (до качества нашего словаря)
Покрывет порядка 2К омографов с F1 0.85, средней точностью по омографам в 91% и средней точностью по датасету в 93%
Основана на приватном датасете в 120М предложений и словаре в ~4.1М слов
Предсказывает ударение в новых / неизвестных / придуманных словах с точностью до 60-70%
Опубликована под популярной лицензией (MIT), не содержит телеметрии, связки с экосистемами, ключей, регистрации, подписок
Максимально упрощена и минифицирована и не содержит зависимостей кроме стандартной библиотеки питона и PyTorch
Работает с последними актуальными версиями питона и PyTorch
То, что ё всегда ударная, это верно в 95% случаев, но строго говоря это не так. Плюс бывают слова с двумя буквами ё. Значит по закону Оккама проще не делать отдельное правило, а просто ставить ударение всегда даже на букву ё.
—
Ну омограф-то обработался, просто ударение пропустилось из-за флага
stress_single_vowel=False, который вы поставили.Если поставить такие флаги:
То будет так:
Мо+я мать, м+оя посуду, рассказала о н+ём, что он н+ем. Ну... Говорить не умеет. И с этого момента вс+ё завертелось, и вс+е завертелись. А ёлка моей сестр+ы засияла!То всё будет в порядке. Ведь слова
нем/нём/все/всёимеют всего 1 гласную, вот и пропускаются.Обновили silero-stress до версии 1.1.
Добавили несколько QoL изменений, о которых попросило комьюнити, а так же внесли немного фиксов и обновили документацию.
Модели можно использовать на CPU/GPU. Примеры тут.
Добавили флаги put_stress, put_yo, put_stress_homo, put_yo_homo, которые позволяют включать/выключать простановку ударений и/или буквы ё как в обычных словах, так и в омографах.
Добавили флаг stress_single_vowel, который отвечает за расстановку ударений в односложных словах.
Добавили пример, как расставлять ударения в обычных словах и в омографах независимо друг от друга.
Пофиксили небольшой баг — акцентор удалял символы переноса строки из исходного текста.
С одной стороны - расстановка знаков препинания более простая задача, т.к. для неё тривиально фармить датку.
С другой - она более необъятная и склонная к большим моделям.
С третьей - пользы на практике от неё на порядок меньше.
С четвёртой - в устной речи не действуют законы расстановки знаков препинания и живые люди говорят совсем иначе, нежели чем принято писать. Ну то есть половина всей речи (условно) не поддаётся ей в той или иной степени.
Поэтому я бы наверное не мешал это в кучу.
Вся история языка - это его "порча". Люди "и так понимают всё", а в быту и па письме всё диктуется законом языковой экономии.
Наш алфавит и система письма практически минималистичны и основаны на морфологическом принципе орфографии. То есть всё прекрасно, если, конечно, знать ударение наперёд.
Поэтому вы по сути предлагаете пойти против законов развития языка и 400 лет языковой традиции.
Времени было побольше, а сейчас английский язык общения. А там вообще с правилами чтения полная жесть. Но проще, чем в китайском.
Тут можно заметить только, что у нас тулза для расстановки ударения в предложениях / нескольких предложениях, а не книгах целиком.
То есть знак переноса строки действительно лучше не удалять при санации (или потом возвращать назад), но если засунуть в инструмент целую главу или страницу книги - работать, понятное дело, не будет, или будет работать хуже.
Конкретно с инсертами в базу есть простейшее архитектурное решение, собирать транзакции в батчи (и разнести отправку в очередь и отправку в базу на два разных воркера / процесса / executor-а). И имхо, тут ограничения будут скорее уже на стороне базы в любом серьёзном проекте.
Я понимаю, что вы иллюстрируете краевые случаи тут. Но нужно конечно быть самим себе злым буратино, чтобы создавать 10,000 потоков.
Моё личное мнение - что less is more, и ко всем этим интерфейсам (multiprocessing, threading, asyncio) их комбинациям надо прибегать, если ОЧЕНЬ понятно зачем и почему вы делаете.
В примере с базой - если наивное решение в вашем случае даёт x10 пропускной способности, может x1000 и не нужна. You are not Google.
Ну то есть формулировать вывод, имхо надо так, что для каждой задачи свой инструмент, но есть существенный элемента хайпа, который надо разумно анализировать.
Мы в ближайшее время добавим флаги.
Короткий ответ - потому что нейросетки выучивают просодию из данных. И иногда там есть так называемый inductive bias (крутилки для юзера по-простому), которые учитывает сетка. В новых сетках крутилок меньше.
А чем более новый и огромный синтез - тем он лучше выучивает что-то, но непонятно что.
А старый синтез весь был грубо говоря на хардкоде. У нас в нашем старом синтезе тоже вот такие рофлы работали. А в новом такого веселого ада уже нет.
Ну гуглить ещё надо уметь, плюс на инглише. Надеюсь, что мошенники им владеют меньше) А вы помогли им, своим постом, азазаза, живите с этим
Насколько я знаю они сидели на витсе, а потом перешли на флоу матчинг модели. Мы гоняли и оригинальные модели авторов статей и их пре-трейн, и с точки зрения продукта эти архитектуры нас не впечатлили. Они скорее приносят больше проблем, чем решают.
Что касается скорости, обычно сравнивают со старой медленной моделью, потому что v4 не торт. Наши текущие актуальные модели ~ на порядок быстрее. Плюс никто никогда не пишет сколько это потоков, на каком процессоре. Там мягко говоря можно взять оверклокнутный процессор на 5 гигагерц и подогнать всё к нужным параметрам. А менее оптимизированные модель могут жрать процессора в 2-3 раза больше на самом деле при "такой же" скорости.
При этом есть и много других критериев, в которые мало смысла погружаться. Но тут не буду прямо пускаться в рассказ, достаточно качественно оформлять наши выводы для публичного использования - лень, да и мало смысла. А иначе можно скатиться в такое.
Я понимаю, что на длине метрики с чем-то коррелируют, но в статьях всегда очень странное видение мира, и синтез реально "обогнал" реальный мир ещё во время второго такотрона. Особенно забавно анализировать perceptual метрики и следование интонации, когда у исследователей нет ground truth того как сами дикторы говорят.
Мы гоняли perceptual метрики на спикерах на разных языках на разных микрофонах - там тупо от языка, ресепмлинга, формата исходного файла, голоса или настроения диктора могут метрики меняться на 0.5 - 1 (из 5 баллов). При этом мы игрались оценкой обычных людей - они перестали по 1 фразе отличать синтез ещё года 3+ назад. А в телефонном канале в 8 килогерц и тому подавно.
С абзацами у всех проблемы. Но тут имхо нужны совсем гигантские модели. Либо будет звучать плоско. То есть как бы синтез будет нашколен на абзац, а на 1 фразу. То есть на втором абзаце станет понятно, что синтез.
И это, конечно, без музыки, в 48 kHz, в наушниках, молодыми ушами, без шума на фоне.
Ну кожаные ублюдки, потраченный перевод и подобное - банально смешное само по себе. Это раз, оно не дошло до uncanny valley.
Чем больше или новее модель, тем она более "end-to-end". То есть грубо говоря труд инженеров заменяется на "GPU go brrrr" в широком смысле. То есть не делается отладка всего, сравнение разных систем, взвешивание за и против, длинный путь по допиливанию напильником.
Это не хорошо и не плохо (более того во многих областях ML это дало кембрийский взрыв возможностей), просто становится меньше "крутилок" и больше соблазн "закинул всё и пусть оно само так учится". А модели, чем более продвинутые, тем более "умные" по-своему, то есть они хорошо всасывают домен, и как бы не торопятся генерализовываться, если прямо сильно палками не бить. Отчасти многие генераторы картинок в поздней версии стали выдавать одно и то же рафинированное и скучное - будто финально оверфитнулись все на один сет красивых картинок. Хотя недавно я пробовал nano banana от гугл и был в принципе удивлён. Но уже давно перестал следить в чём там фишка.
Соответственно получаем высокие метрики звучания, но при этом само звучание может быть скучным и нет никаких крутилок. Ну или крутилки в духе "вкидывай промпт, с 100й попытки чет получится, но и то будет на рандоме".
Думаю хороший пример тут - вокалоиды. Просто определение проклятого синтеза и контроля. Там буквально можно пением до % тона управлять и приёмов пения. Но в интернете мемов про то, что Хацуне Мику не умеет говорить по-английски - тысячи с миллионами просмотров.
При этом сделать качественный хорошо поющий синтез - это задача со звёздочкой, ну или как минимум немалая работа. Если честно я хз как он сделан у сервисов генерации музыки. Моя догадка, что там присутствуют "голливудские" банки условно всей лицензированной музыки. Аранжировки там точно часто не MIDI, а реальные шаблоны из реальных записей. Что касается редактирования поющего голоса - тут есть ряд идей, но как минимум это отдельная работа со всеми вытекающими. Но Хацуне Мику хорошо поёт … и плохо говорит. А тут наоборот.
Тут не могу за всех сказать. Могу сказать, что как и в IT присутствует огромный культ-карго, "неповторимые" эксперименты, парки на сотни тысяч GPU и прочий пузырь. Ну и если представить, что вы ТРУЪ рисёрчер, и хотите потратить два годика, чтобы сделать лучший мире маленький, компактный классный синтез. Вам нужно как-то обойти все эти ваши "стартапы" с US$100m финансирования и опен-ай-ай. Отсюда наблюдаем, что наблюдаем. Кембрийский взрыв систем синтеза, где по сути одна и та же идея в виде LLM и GPU go brrrr.
Ну тут вы получается спорите с нами, но 3-4 года назад. Ситуация тогда была совсем иная. Мы видели проблему в моменте, и решали её как могли, тогда этого всего или не было, или оно было менее на слуху, на порядок.
По поводу на чём базируются мошенники - я бы не писал (удолите), т.к. они потом будут использовать Хабр как базу знаний для этого в поиске. У этих решений есть свои моменты, но для генерации 10 аудио можно использовать вообще всё что угодно, хоть платные сервисы дорогие.
Тут я бы поспорил, но не с точки зрения абстрактного "качества звучания", оно у моделей класса VITS или "больших" моделей или моделей на основе flow matching-а действительно чуть "бархатнее", а с точки зрения реальной применимости:
По ресурсам там как правило всё довольно печально. VITS можно натянуть на глобус, но с проблемами. Маленькие flow matching модели, имхо теряют свою фишку по сравнению с большими, а большие сразу получают ярлык GPU-only и на два порядка медленнее ПОСЛЕ всех оптимизаций;
Небольшой прирост качества звучания идёт ценой сильно более высоких вычислительных ресурсов и стабильности. То есть если с нашими актуальными моделями мы боремся с ударениями и какими-то странными краевыми кейсами у клиентов, то с новыми моделями мы ловим краевые случаи и нестабильности сразу при "лакмусовых" тестах при оценке адекватности технологии;
При этом фишка в виде разнообразия генерации прикольная, как мне кажется. Но тут tech отрасль и академические метрики, как мне кажется, идут немного вбок. Но если писать про это - это уже отдельная большая статья, да и вряд ли у неё найдутся читатели (в одиночку не перебить шквал контента AGI is near), тут поможет только прорыв пузыря.
Про пиратские решения или решения за облаком гига-корпораций я не буду комментировать)
Вы правы, но этот кейс более частотный . Просто ваш кейс более экзотический. Поэтому и перечисляю всякое редкое.
Когда мы делали релиз 4й версии, мы увидели, что нашу говорилку используют мошенники при звонках, поэтому скрутили звучание.
В ближайшее время мы планируем сделать релиз 5й версии, там будет ускорение синтеза ещё в несколько раз, повышение качества, и упаковка модели омографов прямо в модель синтеза речи.
Да не, я в всё понял, по сути вы просто привели пример ещё более экзотического "омографа", но у вас от смысла меняется звучание, а не ударение (хотя это близкие понятие). Есть нечто похожее в обычных омографах, это слова Один и одИн. Тоже разные языки как бы.
Просто ваш пример мне напомнил про более частотный кейс с шинелями. Я к тому, что на самом деле бездна всего такого, что учесть крайне сложно.
Ох, тут есть ещё бездонная бездна иностранных слов, которые читаются не по правилам, типа шинель / панель / Нинель, мы в нее пока только заглядывали, но пока контакт не наладили. Это скорее имеет отношение уже к синтезу, но в каком-то смысле это похоже на постановку буквы ё.
В идеале, конечно, оно должно принимать
torch.device, но для начала думаю и стринга пойдёт.Имхо, лучше использовать общепринятую конвенцию из фреймворка, чем плодить параметр, но в документацию это конечно забыли добавить, да и изначально не планировали такой метод, его просто забыли удалить.
del
Эту модель можно крутить и на CPU. Для 1-2 омографов на 1 предложение разница не прямо существенна.
Надо чуть больше санировать инпут. Плюс баг с регуляркой.