Хороший аргумент. :) Но разве к WPF реактивность прибита гвоздями? В свойство Text обычного TextBox можно записать одно и двунаправленные биндинги, а можно собственно текст. И это правильно. Где удобнее реактивность, используем реактивность. Где не удобнее, используем свойства и события UI контрола. Думаю на мобилах разработчик тоже не прибит гвоздями к парадигме.
Тут правда рядом на биндинги жаловались, но я наоборот, считаю это контролируемой сложностью.
Мышкой, кодом или декларативно аля QML, но да, что-то похожее.
Причем нужна не столько для формочки из 3 полей, сколько для возможности увидеть и сравнить две парадигмы. Фронтендеры не готовы выйти из зоны комфорта и не видят жизни за пределами реактивной "клетки". А точно ли ее там нет? Почему за столько лет десктопа, не появилось ни одного новомодного, самого лучшего, изначально и до самого конца реактивного фреймворка? Уж точно дело не в простоте отображения изменения состояния окна, в противовес сложности модификации DOM. Реактивность вообще лежит вне этой аргументации. Это просто двунаправленная связь данных и контрола отображения.
Мои тезисы ничуть не противоречат вашим. Я не говорю что реактивность плоха, лишь что она — полезный инструмент, а не основополагающая базовая концепция, вокруг которой вертится всё-всё-всё. Должна быть сверху, предоставлять выбор использовать только там где нужна, а не снизу, вынуждая подстраиваться под себя везде.
В принципе, никто не мешает реализовать часть самостоятельно. Но есть нюанс, нет ни одного императивного WebUI фреймворка. а самостоятельная реализация уходит в излишне низкоуровневый слой. А вот если бы был, возможно архитектура и взяла бы лучшее из обоих миров.
Вот про это и речь. Почему сразу реактивность? Свет клином сошелся? Десктоп испокон живет без нее, а интерфейсы многих программ, намного более функциональны. Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений. При этом я не отрицаю полезности реактивности в отдельных местах.
Когда поглядываю на веб-фреймворки, вижу в них скорее не UI фреймворки, а брокера связности, на котором можно писать UI. Не настолько квалифицирован в данной области, чтобы продвигать настолько глобальные архитектурные концепции, однако хотелось бы видеть более глубокое разделение на собственно UI фреймворк и брокера. Первый позволяет писать UI и только за него отвечает. Причем UI виджеты должны быть более отдалены от их реализации, которую поймет браузер и более отражать сущность виджета. Второй отвечает за объект данных. А разработчик может выбрать, использовать классическую модель событий onCreate / onShow / onChange реализуя требуемое императивно или подключить данный виджет к отслеживаемой переменной декларативно. И даже сделать гибрид — пользовательские действия в виджете обрабатывать императивно, а изменения в данных отображать на виджет декларативно.
Возможно стоит обратиться внимание на GUI приложений. Тут конечно и про них немало "добрых" слов уже сказали. Однако создается впечатление, что все WebUI фрейморки, по своей сути ближе к этапу написания GUI на чистом WinAPI, чем к сколь-нибудь развитым GUI фреймворкам.
Мы кажется немного о разном. Впрочем поправлю свое утверждение — вероятность нарастания ошибки. И ошибки не уровне обработки языка (что это вообще такое?), а уровне рассуждений. Из этого следует это. Следствие становится достоверным (?) утверждением. Из этого следует это.
Языковые модели этого не умеют by design. Следствие будет иметь score меньше 1. А перемножение двух таких значений, первый*второй уровень, даст результат меньше, чем каждый множитель. Остается только гадать, когда в конкретной цепочке утверждений, итоговый score упадет ниже порога достоверности и точно ли модель его правильно рассчитала (здравствуй галлюцинации).
В комментариях уже пробегал анекдот про 1000 символов в минуту и получаемую чушь. А ведь в каждой шутке, есть доля правды. Можно снижать требования к качеству набора. Естественно соблюдая баланс с качеством результата.
Можно собрать типовые ошибки из тренажеров набора. Можно вспомнить про swipe метод набора на виртуальных клавиатурах. Сколько там лишних букв затрагивается, но получаем вменяемый результат. То есть можно прогнозировать как более вероятную коррекцию, замену символа на соседний. И достаточно будет ткнуть пальцем куда-то в ту степь. Эдакий псевдо-Т9, но символы сгруппированы не по алфавиту, а по размещению на ЙЦУКЕН. Наверняка есть и другие варианты упрощения ввода.
Естественно будут возникать коллизии. Которые уже разрешат БЯМ, исходя из контекста. А в случае с недостаточной достоверностью можно даже оставить вариативность|палиативность, что послужит триггером "обратить внимание" при перечитывании написанного. Ведь в отличии от пиш.машинки, ввод можно редактировать.
Археология, потому что не смогли переложить на матричное исчисление и отказались, посчитав альтернативу перспективнее. А она оказалась недостаточно масштабируемой и уперлась в тупик. Но суть не в типе изменений, а направлении движения — нужна более детерминированная модель реальности.
Решил как-то посмотреть, как модели видят слова. Разметил омоним/омограф "вертел", по полсотни вхождений на каждый класс. Взял несколько BERT-энкодеров. И уменьшил размерность до 2.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.
Когда пишешь сверху вниз, можно хорошо прописать интерфейсы и типы. Но если снизу вверх, проект постепенно сшивается из кусков, сами интерфейсы видоизменяются во времени. Здесь была серия статей про использование Rust в геймдеве и возникающие проблемы упомянутого класса.
Не в упрек языку. Но очень редко плюсы бывают без сопровождающих минусов и соответственно наоборот.
Самое главное в оценке этого вопроса, воздержаться от ярлыков. Потому что тема вполне может быть урегулирована компромиссно. Компромисс означает, что каждый что-то получит, но не так, как хотел изначально.
Изначальная проблема, кмк, в однонаправленности отношений субъектов продавец/покупатель. Закрепленных законом и подтвержденных практиками. Вот тебе условия, или соглашаешься, или проходи мимо. В принципе это нормально. На каком-то низком уровне. Но чем значимее тема, чем больше ее контекст отличается от привычного ранее, тем больше к этому тезису вопросов. Государство вполне устанавливает цены/наценки на значимые товары или применяет антимонопольное законодательство. Юристы наверняка назовут еще десятки механизмов регулирования.
В случае информации, есть примеры саморегулирования до уровня win-win. Например gPlay с фактически микроплатежом за программу. "Автор.сегодня" неплохо модернизирует ситуацию с литературой. То есть внешние регулирующие механизмы, раз уж внутренние вызывают такие яркие конфликты, должны не запрещать что-либо, а приводить к компромиссу.
Не спорю с экспертами, но хочу заметить, что корректную экспертизу провести весьма непросто. Слишком часта ошибка несовпадения контекста ЧП и экспертизы — послезнание. Которая отлично показана в фильме Sully (Чудо на Гудзоне). Эксперимент должен проводится, когда эксперт не ожидает чрезвычайной ситуации и тем более не знает, что проверяет уже случившееся ЧП. То есть должен находится в состоянии обычного рабочего внимания и действовать строго по процедуре, с учетом времени на осознание ситуации и принятие решения. Каковое время, в постфактумной экспертизе обычно игнорируют.
Когда-то писал довольно развернутые приложения на Delphi. Десятки форм с разной степенью генерации содержимого по метаданным. Grid, list, edit, label собранные на Panel или саму форму. В том числе с получением и сохранением данных во внешних источниках — невидимый DataSet и визуальные компоненты с приставкой Data. Сложность была контролируемой. Понятной. Вменяемый цикл событий. При желании, вполне можно было реализовать реактивность. В нужном объеме.
Так может проблемы WebGUI в недостаточном уровне инкапсуляции? И безальтернативной реактивностью? Слишком близко к низам — html, css. Нет вменяемой объектной модели компонентов. И только один поток связывания, где надо и не надо.
Строки правильны с алгоритмической точки зрения, но это приносит некоторое количество боли. Во-первых многословны. Если код направлен на массовую работу со строками, читать тяжело. Во-вторых, не совпадает опыт с другими языками/реализациями. Ни в одном языке нет такого количества WTF при работе со строками у изучающих язык.
Резоны разработчиков языка о гарантиях производительности при работе со строками понятны. Индексация UTF вытащена в код. Но хотелось бы видеть в дополнение к существующему варианту, реализацию StringScalar (аналог видения строк в Питоне) и StringGrapheme, с которыми можно было работать именно как со строками (размер, срез, итерация и пр.). Где сложность обработки/индексации инкапсулирована, пусть и в ущерб производительности. Точнее в ущерб не производительности (она одинаковая), а в ущерб ожиданиям производительности.
Предположу что написанное уже учтено, но на всякий случай хотелось бы отметить. Очень уж хочется решения давней проблемы. Омографы можно разделить на группы:
Каждая группа требует немного различных критериев. Многие из которых, можно перенести от одного популярного слова на другие непопулярные, для которых составление корпуса для индивидуального обучения затруднительно. Можно вообще обучать группой. И только смысловые — индивидуально.
Просмотрел ваш список омографов. В первой сотне нашел слова — отзывы, сила, стихи, — вторую форму которых представить не смог.
Сколько еще таких популярных слов ошибочны? И как можно добиться безошибочной озвучки длинных текстов (книг), не забивая в корректирующий словарь все известные миллионы правил?
Допускаю, что вы не только не хотите выкладывать свои наработки, но и затруднены в этом архитектурой приложения. Поэтому просьба трансформируется. Используя публичные датасеты (Зализняк, Викисловарь) проверьте корректность сами и прикладывайте к модели список исключений. Хотя бы для популярных слов составляющих 99% текста.
Ни в коем случае не претензия. Омографы были затронуты вскользь и не являются предметом обсуждения. Только слова с постоянным ударением и попытка убедить, что отдача предсказанной позиции ударения вреда коммерции не принесет. Невозможно составить достоверный словарь ударений по прогнозам, только сравнить с уже существующим эталоном. Что облегчит генерацию корректирующих словарей конкретно под движок. Облегчит, а не даст возможность. Новые слова, как и прежде для SAPI движков, будут добавляться путем прослушивания.
И не надо засовывать. Это отдельный проект, используется как мидлваре. Лишь намек, что и уникальность разрешения омографов не столь велика. Точность Наташи зависит от частотности. Все/всё и чем/чём больше 98%. А для нечасто употребляемых слов, может вообще заклинить в одном положении — в уже` или ду`шу. Еще сами с столкнетесь. Но тут частотность тоже позволяет утверждать хорошую достоверность. Одно у`же встречается на 500+ уже`.
По словоформам, это лишь реально встреченные в тексте. Оценка важности, а не количества. Количество же в исходных публичных словарях уже не помню, но мнооооого.
Есть ощущение что у вас замылился взгляд с позиции разработчика. Кажется что пользователи смогут вытащить из результата работы модели ваши наработки. В реальности, для них все ударения потенциально недостоверные. Без ручного контроля восстановить не выйдет. А ручной контроль можно сделать и на других предикторах. Поэтому, в первую очередь, это нужно для улучшения работы пользователей с вашей же моделью. "Вредоносное" использование даже представить не могу.
По поводу словарей. Это ваше решение, но предлагаю взглянуть на вопрос еще раз.
Существуют публичные словари Зализняка (плюс извеcтный в кругах любителей TTS основанный на нем orfoepic) и дамп Викисловаря. Это миллионы словоформ с большой избыточностью. Чтобы ее сократить, проводил исследование частотности использования слов. Проверено ~10к книг разных жанров и времен, включая классику, русскую и переводы зарубежной. Найдено ~1.9м словоформ требующих ударения, с ~400м вхождений. Из них в публичных словарях найдено ~1м словоформ, с ~375м вхождений. Покрытие словарями 95%
Не знаю насколько более полон ваш словарь, пусть будет предельные 5%, но отсюда вопрос: я их недооцениваю или вы переоцениваете скрывая? Речь не об омографах, для которых нужен контекст и с которыми хорошо справляется проект Natasha (есть на Хабре). Только об обычных словах. Для которых API будет принимать только одиночные вхождения.
По поводу лички. Спасибо, но откажусь. Не люблю использовать привилегированный доступ в некритичных вопросах.
Хороший аргумент. :) Но разве к WPF реактивность прибита гвоздями? В свойство Text обычного TextBox можно записать одно и двунаправленные биндинги, а можно собственно текст. И это правильно. Где удобнее реактивность, используем реактивность. Где не удобнее, используем свойства и события UI контрола. Думаю на мобилах разработчик тоже не прибит гвоздями к парадигме.
Тут правда рядом на биндинги жаловались, но я наоборот, считаю это контролируемой сложностью.
Мышкой, кодом или декларативно аля QML, но да, что-то похожее.
Причем нужна не столько для формочки из 3 полей, сколько для возможности увидеть и сравнить две парадигмы. Фронтендеры не готовы выйти из зоны комфорта и не видят жизни за пределами реактивной "клетки". А точно ли ее там нет? Почему за столько лет десктопа, не появилось ни одного новомодного, самого лучшего, изначально и до самого конца реактивного фреймворка? Уж точно дело не в простоте отображения изменения состояния окна, в противовес сложности модификации DOM. Реактивность вообще лежит вне этой аргументации. Это просто двунаправленная связь данных и контрола отображения.
Мои тезисы ничуть не противоречат вашим. Я не говорю что реактивность плоха, лишь что она — полезный инструмент, а не основополагающая базовая концепция, вокруг которой вертится всё-всё-всё. Должна быть сверху, предоставлять выбор использовать только там где нужна, а не снизу, вынуждая подстраиваться под себя везде.
В принципе, никто не мешает реализовать часть самостоятельно. Но есть нюанс, нет ни одного императивного WebUI фреймворка. а самостоятельная реализация уходит в излишне низкоуровневый слой. А вот если бы был, возможно архитектура и взяла бы лучшее из обоих миров.
Вот про это и речь. Почему сразу реактивность? Свет клином сошелся? Десктоп испокон живет без нее, а интерфейсы многих программ, намного более функциональны. Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений. При этом я не отрицаю полезности реактивности в отдельных местах.
Когда поглядываю на веб-фреймворки, вижу в них скорее не UI фреймворки, а брокера связности, на котором можно писать UI. Не настолько квалифицирован в данной области, чтобы продвигать настолько глобальные архитектурные концепции, однако хотелось бы видеть более глубокое разделение на собственно UI фреймворк и брокера. Первый позволяет писать UI и только за него отвечает. Причем UI виджеты должны быть более отдалены от их реализации, которую поймет браузер и более отражать сущность виджета. Второй отвечает за объект данных. А разработчик может выбрать, использовать классическую модель событий onCreate / onShow / onChange реализуя требуемое императивно или подключить данный виджет к отслеживаемой переменной декларативно. И даже сделать гибрид — пользовательские действия в виджете обрабатывать императивно, а изменения в данных отображать на виджет декларативно.
Возможно стоит обратиться внимание на GUI приложений. Тут конечно и про них немало "добрых" слов уже сказали. Однако создается впечатление, что все WebUI фрейморки, по своей сути ближе к этапу написания GUI на чистом WinAPI, чем к сколь-нибудь развитым GUI фреймворкам.
Мы кажется немного о разном. Впрочем поправлю свое утверждение — вероятность нарастания ошибки. И ошибки не уровне обработки языка (что это вообще такое?), а уровне рассуждений. Из этого следует это. Следствие становится достоверным (?) утверждением. Из этого следует это.
Языковые модели этого не умеют by design. Следствие будет иметь score меньше 1. А перемножение двух таких значений, первый*второй уровень, даст результат меньше, чем каждый множитель. Остается только гадать, когда в конкретной цепочке утверждений, итоговый score упадет ниже порога достоверности и точно ли модель его правильно рассчитала (здравствуй галлюцинации).
В комментариях уже пробегал анекдот про 1000 символов в минуту и получаемую чушь. А ведь в каждой шутке, есть доля правды. Можно снижать требования к качеству набора. Естественно соблюдая баланс с качеством результата.
Можно собрать типовые ошибки из тренажеров набора. Можно вспомнить про swipe метод набора на виртуальных клавиатурах. Сколько там лишних букв затрагивается, но получаем вменяемый результат. То есть можно прогнозировать как более вероятную коррекцию, замену символа на соседний. И достаточно будет ткнуть пальцем куда-то в ту степь. Эдакий псевдо-Т9, но символы сгруппированы не по алфавиту, а по размещению на ЙЦУКЕН. Наверняка есть и другие варианты упрощения ввода.
Естественно будут возникать коллизии. Которые уже разрешат БЯМ, исходя из контекста. А в случае с недостаточной достоверностью можно даже оставить вариативность|палиативность, что послужит триггером "обратить внимание" при перечитывании написанного. Ведь в отличии от пиш.машинки, ввод можно редактировать.
Археология, потому что не смогли переложить на матричное исчисление и отказались, посчитав альтернативу перспективнее. А она оказалась недостаточно масштабируемой и уперлась в тупик. Но суть не в типе изменений, а направлении движения — нужна более детерминированная модель реальности.
Решил как-то посмотреть, как модели видят слова. Разметил омоним/омограф "вертел", по полсотни вхождений на каждый класс. Взял несколько BERT-энкодеров. И уменьшил размерность до 2.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.
Разве при очистке регулярка '\W+' не заменит пунктуацию на пробелы? Чем поломает и/или сделает ненужной всю следующую обработку.
Беря только первую форму из PyMorphy, прощай омонимы. У слова может быть несколько нормальных форм и частей речи.
Когда пишешь сверху вниз, можно хорошо прописать интерфейсы и типы. Но если снизу вверх, проект постепенно сшивается из кусков, сами интерфейсы видоизменяются во времени. Здесь была серия статей про использование Rust в геймдеве и возникающие проблемы упомянутого класса.
Не в упрек языку. Но очень редко плюсы бывают без сопровождающих минусов и соответственно наоборот.
Самое главное в оценке этого вопроса, воздержаться от ярлыков. Потому что тема вполне может быть урегулирована компромиссно. Компромисс означает, что каждый что-то получит, но не так, как хотел изначально.
Изначальная проблема, кмк, в однонаправленности отношений субъектов продавец/покупатель. Закрепленных законом и подтвержденных практиками. Вот тебе условия, или соглашаешься, или проходи мимо. В принципе это нормально. На каком-то низком уровне. Но чем значимее тема, чем больше ее контекст отличается от привычного ранее, тем больше к этому тезису вопросов. Государство вполне устанавливает цены/наценки на значимые товары или применяет антимонопольное законодательство. Юристы наверняка назовут еще десятки механизмов регулирования.
В случае информации, есть примеры саморегулирования до уровня win-win. Например gPlay с фактически микроплатежом за программу. "Автор.сегодня" неплохо модернизирует ситуацию с литературой. То есть внешние регулирующие механизмы, раз уж внутренние вызывают такие яркие конфликты, должны не запрещать что-либо, а приводить к компромиссу.
Не спорю с экспертами, но хочу заметить, что корректную экспертизу провести весьма непросто. Слишком часта ошибка несовпадения контекста ЧП и экспертизы — послезнание. Которая отлично показана в фильме Sully (Чудо на Гудзоне). Эксперимент должен проводится, когда эксперт не ожидает чрезвычайной ситуации и тем более не знает, что проверяет уже случившееся ЧП. То есть должен находится в состоянии обычного рабочего внимания и действовать строго по процедуре, с учетом времени на осознание ситуации и принятие решения. Каковое время, в постфактумной экспертизе обычно игнорируют.
Когда-то писал довольно развернутые приложения на Delphi. Десятки форм с разной степенью генерации содержимого по метаданным. Grid, list, edit, label собранные на Panel или саму форму. В том числе с получением и сохранением данных во внешних источниках — невидимый DataSet и визуальные компоненты с приставкой Data. Сложность была контролируемой. Понятной. Вменяемый цикл событий. При желании, вполне можно было реализовать реактивность. В нужном объеме.
Так может проблемы WebGUI в недостаточном уровне инкапсуляции? И безальтернативной реактивностью? Слишком близко к низам — html, css. Нет вменяемой объектной модели компонентов. И только один поток связывания, где надо и не надо.
Строки правильны с алгоритмической точки зрения, но это приносит некоторое количество боли. Во-первых многословны. Если код направлен на массовую работу со строками, читать тяжело. Во-вторых, не совпадает опыт с другими языками/реализациями. Ни в одном языке нет такого количества WTF при работе со строками у изучающих язык.
Резоны разработчиков языка о гарантиях производительности при работе со строками понятны. Индексация UTF вытащена в код. Но хотелось бы видеть в дополнение к существующему варианту, реализацию StringScalar (аналог видения строк в Питоне) и StringGrapheme, с которыми можно было работать именно как со строками (размер, срез, итерация и пр.). Где сложность обработки/индексации инкапсулирована, пусть и в ущерб производительности. Точнее в ущерб не производительности (она одинаковая), а в ущерб ожиданиям производительности.
Предположу что написанное уже учтено, но на всякий случай хотелось бы отметить. Очень уж хочется решения давней проблемы.
Омографы можно разделить на группы:
мн.им/ед.род — скалы, адреса, беды;
жен/муж — внучка, ворона, голубка, толстячкам;
сов/несов — зерно (еще) высыпАлось, зерно (уже) вЫсыпалось;
смысловые;
возможно какие-то еще.
Каждая группа требует немного различных критериев. Многие из которых, можно перенести от одного популярного слова на другие непопулярные, для которых составление корпуса для индивидуального обучения затруднительно. Можно вообще обучать группой. И только смысловые — индивидуально.
Просмотрел ваш список омографов. В первой сотне нашел слова — отзывы, сила, стихи, — вторую форму которых представить не смог.
Прошу прощения за навязчивость. Сегодня занялся тестированием более плотно. За 30 минут нашел ошибки ударения в крайне популярных словах.
ему. просто. такой. именно. свои. прямо. сама. кого. своей. моей. моих. мире. всему. судя. власти. столе. дочери. шаги. коня. будучи. зверя. братьев. второй. никого.Сколько еще таких популярных слов ошибочны? И как можно добиться безошибочной озвучки длинных текстов (книг), не забивая в корректирующий словарь все известные миллионы правил?
Допускаю, что вы не только не хотите выкладывать свои наработки, но и затруднены в этом архитектурой приложения. Поэтому просьба трансформируется. Используя публичные датасеты (Зализняк, Викисловарь) проверьте корректность сами и прикладывайте к модели список исключений. Хотя бы для популярных слов составляющих 99% текста.
Ни в коем случае не претензия. Омографы были затронуты вскользь и не являются предметом обсуждения. Только слова с постоянным ударением и попытка убедить, что отдача предсказанной позиции ударения вреда коммерции не принесет. Невозможно составить достоверный словарь ударений по прогнозам, только сравнить с уже существующим эталоном. Что облегчит генерацию корректирующих словарей конкретно под движок. Облегчит, а не даст возможность. Новые слова, как и прежде для SAPI движков, будут добавляться путем прослушивания.
И не надо засовывать. Это отдельный проект, используется как мидлваре. Лишь намек, что и уникальность разрешения омографов не столь велика. Точность Наташи зависит от частотности. Все/всё и чем/чём больше 98%. А для нечасто употребляемых слов, может вообще заклинить в одном положении — в уже` или ду`шу. Еще сами с столкнетесь. Но тут частотность тоже позволяет утверждать хорошую достоверность. Одно у`же встречается на 500+ уже`.
По словоформам, это лишь реально встреченные в тексте. Оценка важности, а не количества. Количество же в исходных публичных словарях уже не помню, но мнооооого.
Есть ощущение что у вас замылился взгляд с позиции разработчика. Кажется что пользователи смогут вытащить из результата работы модели ваши наработки. В реальности, для них все ударения потенциально недостоверные. Без ручного контроля восстановить не выйдет. А ручной контроль можно сделать и на других предикторах. Поэтому, в первую очередь, это нужно для улучшения работы пользователей с вашей же моделью. "Вредоносное" использование даже представить не могу.
По поводу словарей. Это ваше решение, но предлагаю взглянуть на вопрос еще раз.
Существуют публичные словари Зализняка (плюс извеcтный в кругах любителей TTS основанный на нем orfoepic) и дамп Викисловаря. Это миллионы словоформ с большой избыточностью. Чтобы ее сократить, проводил исследование частотности использования слов.
Проверено ~10к книг разных жанров и времен, включая классику, русскую и переводы зарубежной.
Найдено ~1.9м словоформ требующих ударения, с ~400м вхождений.
Из них в публичных словарях найдено ~1м словоформ, с ~375м вхождений.
Покрытие словарями 95%
Не знаю насколько более полон ваш словарь, пусть будет предельные 5%, но отсюда вопрос: я их недооцениваю или вы переоцениваете скрывая? Речь не об омографах, для которых нужен контекст и с которыми хорошо справляется проект Natasha (есть на Хабре). Только об обычных словах. Для которых API будет принимать только одиночные вхождения.
По поводу лички. Спасибо, но откажусь. Не люблю использовать привилегированный доступ в некритичных вопросах.