Pull to refresh
2
0
Send message

Я тоже не знаю, поэтому и написал "возможно".

Однако речь немного про другое. Куда по сути этот подход и должен быть расширен — последовательное с накоплением. Мы же не учим учебник за раз. Тему за темой, параграф за параграфом, абзац за абзацем, тезис за тезисом. Используя на следующем шаге всю информацию предыдущих. А также уточняя их понимание.

Как писал в других темах, естественный язык это инструмент описания реальности. То есть языковая модель переводит с естественного языка на некий промежуточный, создавая модель этой реальности. Смысловая ей оперирует. И потом языковая выступает в роли вокодера.

То есть для изучения Rust нам не надо трогать языковую модель. Ни одного нового символа не появилось. Ну может кроме зарезервированных слов. Вся работа проводится в смысловой модели. Которая сама изначально должна быть построена на расширении, а не вытеснении или перестройке весов. И следовательно теряется смысл в этапных Hebbian-патчах. Точнее, они приобретают совсем другой смысл — фрагмента реальности с которым мы сейчас оперируем, быстрой памяти.

Эволюции это хорошо. Но возможно, данная, заведет процесс создания ИИ еще глубже в тупик.

Представим, что модель как-то обучена программированию и как-то знает несколько языков. Выходит новый. Для него пишется документация, учебник. Вот это переменная, вот это функция, вот это структура, вот это трейт, вот это модель владения, вот это... и так далее. Попросту представим что Rust вышел только сейчас. Скормив BDH эту доку, сможет ли он выучить язык?

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

class OrderProcessor:
    def __init__(self):
        self.handlers = {
            "new": [validate_order, process_payment, send_confirmation_email],
             ...
        }
    
    def __call__(self, order_data):
        status = order_data['status']
        if status in self.handlers:
            for handler in self.handlers[status]:
                reuslt = handler(order_data)
        else:
            logger.warning(f"Unknown order status: {status}")
            result = {"error": "Unknown status"}
        return result

нейросетки выучивают просодию из данных.

Скажу как читатель со стажем. Впоследствии перешедшим на аудио. Как декламаторов, так и синтезированное. Подход если не полностью, то существенно ошибочен.

Как сознание читает текст? В нейтральном ключе, последовательно строит фрагмент реальности. Видит знак препинания и фиксирует этот фрагмент в соответствующем ключе. Для вопросительного и возможно восклицательного, ища и подсвечивая точку внимания. Ретроспективно.

С печатным текстом иное невозможно. Там нет указаний на акцентирование. Что авторы учитывают, возможно подсознательно. Вопросительные и восклицательные статистически заметно короче и обладают более простой внутренней структурой.

А что же с аудио, создаваемому синтезатором по этому тексту? С хорошим декламатором, который подсвечивает точку внимания, в ближайшем будущем сравниться невозможно. Нужно понимать смысл. Без него, более целевое декламаторское интонирование, только повредит выучиванию. А с пониманием смысла пока беда-беда.

А что же надо? Достаточно интонацией уверенно "ставить" знак препинания. Обобщенно. Не мешая мозгу излишней ажиотацией, самому находить и подсвечивать эту точку. То есть стать подобным обычному чтению! Тем более, мозгу сложнее обрабатывать ошибки, чем достраивать нюансы. Лучше нейтрально обозначить знак препинания, который получен из текста, гарантированно, чем ошибиться во внимании, о котором нужно догадываться.

Как это сделать? Пара соображений есть. Но общий низкий уровень понимания говорит — не позорься. Думайте, вы больше в этом понимаете!

Много непонятных слов, в целом понял, но на вопрос вы плохо ответили. Ушли сильно в сторону. Попробую перефразировать. Есть алгоритм, в терминологии плаваю, поэтому назову его параметрическим. Человек фиксировано задал кривые интонирования, как понимаю, из знаков пунктуации и количества слов между ними. Он работает. Работает неплохо и даже хорошо. Куда и почему это "хорошо" исчезло в нейросетевых синтезаторах? И можно ли этот параметрический метод надстроить над графическим для MEL или волновым представлением звука? В зависимости от того, в какой этап проще внедрить. Получив гибридную нейро-параметрическую модель, взяв лучшее от старых — интонирование, и новых синтезаторов — фонетика.

Впрочем, даже многие слушатели в первую очередь обращают внимание на фонетику, а интонирование за скобки. Хотя книга превращается в бу-бу-бу-бу. Я же стараюсь на это обращать внимание. Предлагаю слушать стихотворение, где ритм заложен изначально или синтетический тест, который сделал на основе как раз вашей демки.

В недрах тундры. Выдры в гетрах. Тырят в ведра. Ядра кедров.
В недрах тундры, выдры в гетрах. Тырят в ведра, ядра кедров.
В недрах тундры, выдры в гетрах, тырят в ведра, ядра кедров.
В недрах тундры, выдры в гетрах? Тырят в ведра, ядра кедров!
В недрах тундры, выдры в гетрах! Тырят в ведра, ядра кедров?

Нужно анализировать даже не само произношение, а различие между строками. В идеале, слушатель должен уверено восстановить пунктуацию прослушанной строки.

Это не спор. С прошлым нельзя спорить, его можно только оценивать. Не представляю, на кого повлияло ваше решение, при сохранении широкой доступности предыдущей более качественной модели (что легко предсказывалось) и опаска использовать в одном предложении представителей широко распространённой технологии voice cloning общего применения, вместе с нехорошими людьми. Все это гуглится за 10-30 минут. Это даже не против мамкиных хакеров действительно, а лишь их личинок. Которые купюры на ч/б ксероксе копируют. И, как понял, после вашего ответа, редактирование поста мне стало недоступно.

Про метрики я говорил про Vosk. Это быстрая модель, плюс-минус сопоставимая с вашей. Часть информации взята из их презентации на какой-то конференции (там старая модель сравнивается), часть из ридми актуальной модели. Про VITS с вами абсолютно согласен.

Кстати, раз уж зашел разговор про метрики, позвольте обсудить один вопрос. Есть старые "быстрые" синтезаторы. Фонетика — ахтунг и максимум удовлетворительно, просодия и интонирование — хорошо и местами отлично. Даже стихи заходят в их исполнении (некоторыми). Получше, чем половина школьников на уроке декламирует. Есть новые нейросетевые синтезаторы. Как достаточно быстрые, так и медленные. Фонетика — хорошо и местами отлично, просодия и интонирование — деградация, местами сильная. Причем практически независящая от ресурсоемкости.

Это принципиальная невозможность заложить их в новый пайплайн (обучение-MEL-вокодер)? Или просто создатели новых моделей настолько увлеклись новыми технологиями, что забили болт и видят только фонетику? В лучшем случае тянут тяжеленный непредсказуемый BERT, с таким же непредсказуемым результатом.

В последнее время синтезаторы, в том числе открытые, растут как грибы после дождя. Онлайн Яндекс и Edge; оффлайн Дмитрий/Светлана из edge-пула, в том числе с SAPI адаптером; новые модели Vosk (ver9 и 10), которые по метрикам приблизились к Яндекс/Edge и опередили вашу ver.3; синтезаторы с вообще клонированием голоса, раздолье для мошенников — VITS и базирующиеся на нем, F5, Chatterbox. И это только то что вспомнилось, из последнего обсуждаемого на TTS-форуме.

Более того, найти вашу ver.3 мошенникам не представляет ни малейшей сложности. То есть можно было не улучшать качество, но в ухудшении точно смысла не много.

В ё-омографах — все/всё, отсек/отсёк, сел/сёл, — тоже меняется звучание, а не ударение. Только тут имеем смену звучания е-э, вместо е-ё. Какая вредная буква "е".

Возможно вы неправильно поняли. Дело не в измененной, а в контекстно измененной фонетике. Взвесьте килограмм теста и После тэста по математике. Утром придет Стэн и Даже у стен есть уши.

Я хотел показать влияние модификации контекста плюсами на распознавание формы. Раз наткнулся в отношении "еду", то и в любом другом омографе можно будет словить. Считать это багом или штатным поведением — на ваше усмотрение. Я скорее отношу к штатному. А вот удвоение ударений +ед+у это действительно баг.

Также посмотрите, не ставите ли сами себе подножки. Не может ли собственная предыдущая коррекция, попасть в окно оценки следующих за ней омографов. Предыдущий оутпут попадает в инпут следующего. Такое может как помочь ("берегу озера", если контекст указал на "бе́регу", то "о́зера", если на "берегу́", то "озёра"), так и помешать. Сам стараюсь избегать такого seq2seq, но вы там лучше в языках разбираетесь.

Нашей - не помешают. Другой - не могу сказать.

Коллега, а вы меня обманули.

Я взял еду на пикник -> Я взял ед+у на пикник

Я вз+ял еду на пикник -> Я взял +еду на пикник

То есть коррекция до деомографии недопустима.

Ну убрать плюсик тут довольно рудиментарная операция, имхо.

Сразу уточню для чего это. Некоторые синтезаторы, вроде даже Google TTS в Android, не любят такие ударения. А библиотека будет использоваться не только с вашим синтезатором.

В коде убрать, точнее, найти слова с одной гласной несложно, но для словарной коррекции, это достаточно нетривиально — таких одногласных слов довольно много, в том числе при неожиданном авторском словообразовании. Так может сразу убрать или не ставить в вашем коде? Это может даже на капельку увеличит скорость.

Аналогично с "поверх менять в них ударение на нужное" при словарной коррекции. Нужно иметь две версии словаря или по два правила — для чистого текста и для неправильного ударения. Усложняется пайплайн. Впрочем, если плюсы вам не мешают, то библиотеку можно поставить в конец цепочки. Что не отменяет влияния правил меняющих сам текст ( "не с кем=не́скем" ).

С обычными ударениями понятно. Нет — поставим, есть — пропустим. Но не помешают ли расставленные плюсы деомо-модели? sent = "Я с легкостью узнаю их л+ица ", если морфологию рд.ед/им.мн решил доверить другой библиотеке.

Еще, предложу не ставить ударения в словах с одной гласной. Зачем "+я к+от"?

В целом, отличное решение для "ленивых", просто и достаточно качественно. Намного лучше чем голый текст и другие простые решения. Но если подготовка текста для создания аудиокниг (для личного прослушивания) требует чуть больше перфекционизма, будут проблемы.

Например немало омографов имен собственных. Начиная с явных Ангара́ и Саха́ра, которые вы наверное отслеживаете, заканчивая более специфичными Ба́совым, Бережно́го и даже среди имен встречается омография — бере(ё)зина, Бере́зина (фамилия), Березина́ (река). У меня таких более 400. Бывает надо поработать с аббревиатурами — КГБешник=кэгэбэ́шник или со словосочетаниями "под руку=по́друку", "не с кем=не́скем" (200 правил).

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

Омографы также можно разделить на смысловые, пресловутый "замок" и морфологические — скалы, краю. С последними неплохо справляются морф-таггеры — например Natasha (быстрая) и ее исторический предок DeepPavlov (точнее, но медленно). Не сравнивали с ними? А еще есть сложнейшая задач классификации (не)совершенных глаголов — узнаю, признаюсь; и чуть попроще, но кмк ненамного, изъявительные/повелительные — цените, служите. Не проверяли качество отдельно по таким группам?

В связи с вышесказанным, есть ли возможность разрешать неоднозначности только у указанных пользователем омографов? Естественно среди списка вами поддерживаемых. Чтобы появилась возможность использовать сильные стороны там, где справляется лучше, и отказаться от использования в областях, где не устроит.

Мы зациклились на внутренней схожести с устройством и работой мозга — ааа, нейрон. Предлагаю посмотреть на внешнюю — обучение. Человек обученный языку на потоке сырых данных, потом идет в школу и обучается предмету по учебнику, класс за классом, тема за темой, параграф за параграфом. Обучение на дистиллированных данных. С сетями надо идти по этому пути — композиция языковой и смысловых моделей. Считаю, что такая способность поэтапно обучаться на дистиллированных данных, как раз и есть отражение того самого "здравого смысла". А создать персистентные дистиллированные данные описания реальности, тот самый учебник для следующего поколения, должна помочь нам текущая модель. По мере его наполнения, может даже удастся полностью уйти от языковой модели обучающейся на потоке сырых данных.

Любой наш прогноз, тоже как бы в вероятностном поле. Скорее всего выгорит — действуем. Скорее всего провалится — ищем альтернативное, потенциально более успешное решение.

В целом — согласен. Но как вы хотите обучать действительно слепой, глухой и лишенный осязания "мозг в банке". Для начального набора эрудиции, существующий подход вполне рационален. Нерационально выжимать из него то, на что он изначально плохо приспособлен или не приспособлен вовсе.

Язык — инструмент описания реальности. Обучаться которой надо подобно школьникам. От простого к сложному. Параграф за параграфом, тему за темой, курс за курсом, предмет за предметом. Так, чтобы для обучения этому курсу, нужны были не гигабайты данных, а обычный учебник. На основании которого строить дистиллированный промежуточный слой графа понятий/сущностей, описывающий некий фрагмент реальности и уже на нем обучаться модели v.2.0.

Существующие модели, после соответствующего тюнинга, должны помочь в построении таких графов. А тюнингованные немного по другому, помогать тестерам искать слабые места. И так до тех пор, пока не удастся перейти на полное использование новой модели. Как при разработке компилятора, написать компилятор на том языке, который он компилирует.

Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.

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

По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.

Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.

Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.

Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.

Information

Rating
5,880-th
Registered
Activity