Я хотел показать влияние модификации контекста плюсами на распознавание формы. Раз наткнулся в отношении "еду", то и в любом другом омографе можно будет словить. Считать это багом или штатным поведением — на ваше усмотрение. Я скорее отношу к штатному. А вот удвоение ударений +ед+у это действительно баг.
Также посмотрите, не ставите ли сами себе подножки. Не может ли собственная предыдущая коррекция, попасть в окно оценки следующих за ней омографов. Предыдущий оутпут попадает в инпут следующего. Такое может как помочь ("берегу озера", если контекст указал на "бе́регу", то "о́зера", если на "берегу́", то "озёра"), так и помешать. Сам стараюсь избегать такого seq2seq, но вы там лучше в языках разбираетесь.
Ну убрать плюсик тут довольно рудиментарная операция, имхо.
Сразу уточню для чего это. Некоторые синтезаторы, вроде даже Google TTS в Android, не любят такие ударения. А библиотека будет использоваться не только с вашим синтезатором.
В коде убрать, точнее, найти слова с одной гласной несложно, но для словарной коррекции, это достаточно нетривиально — таких одногласных слов довольно много, в том числе при неожиданном авторском словообразовании. Так может сразу убрать или не ставить в вашем коде? Это может даже на капельку увеличит скорость.
Аналогично с "поверх менять в них ударение на нужное" при словарной коррекции. Нужно иметь две версии словаря или по два правила — для чистого текста и для неправильного ударения. Усложняется пайплайн. Впрочем, если плюсы вам не мешают, то библиотеку можно поставить в конец цепочки. Что не отменяет влияния правил меняющих сам текст ( "не с кем=не́скем" ).
С обычными ударениями понятно. Нет — поставим, есть — пропустим. Но не помешают ли расставленные плюсы деомо-модели? sent = "Я с легкостью узнаю их л+ица ", если морфологию рд.ед/им.мн решил доверить другой библиотеке.
Еще, предложу не ставить ударения в словах с одной гласной. Зачем "+я к+от"?
В целом, отличное решение для "ленивых", просто и достаточно качественно. Намного лучше чем голый текст и другие простые решения. Но если подготовка текста для создания аудиокниг (для личного прослушивания) требует чуть больше перфекционизма, будут проблемы.
Например немало омографов имен собственных. Начиная с явных Ангара́ и Саха́ра, которые вы наверное отслеживаете, заканчивая более специфичными Ба́совым, Бережно́го и даже среди имен встречается омография — бере(ё)зина, Бере́зина (фамилия), Березина́ (река). У меня таких более 400. Бывает надо поработать с аббревиатурами — КГБешник=кэгэбэ́шник или со словосочетаниями "под руку=по́друку", "не с кем=не́скем" (200 правил).
Все это делается в программах словарной коррекции, на стадии после омографии, чтобы не помешать ей, но до расстановки ударений. То есть, как минимум, нужна возможность по отдельности снять омографию и проставить ударения.
Омографы также можно разделить на смысловые, пресловутый "замок" и морфологические — скалы, краю. С последними неплохо справляются морф-таггеры — например Natasha (быстрая) и ее исторический предок DeepPavlov (точнее, но медленно). Не сравнивали с ними? А еще есть сложнейшая задач классификации (не)совершенных глаголов — узнаю, признаюсь; и чуть попроще, но кмк ненамного, изъявительные/повелительные — цените, служите. Не проверяли качество отдельно по таким группам?
В связи с вышесказанным, есть ли возможность разрешать неоднозначности только у указанных пользователем омографов? Естественно среди списка вами поддерживаемых. Чтобы появилась возможность использовать сильные стороны там, где справляется лучше, и отказаться от использования в областях, где не устроит.
Мы зациклились на внутренней схожести с устройством и работой мозга — ааа, нейрон. Предлагаю посмотреть на внешнюю — обучение. Человек обученный языку на потоке сырых данных, потом идет в школу и обучается предмету по учебнику, класс за классом, тема за темой, параграф за параграфом. Обучение на дистиллированных данных. С сетями надо идти по этому пути — композиция языковой и смысловых моделей. Считаю, что такая способность поэтапно обучаться на дистиллированных данных, как раз и есть отражение того самого "здравого смысла". А создать персистентные дистиллированные данные описания реальности, тот самый учебник для следующего поколения, должна помочь нам текущая модель. По мере его наполнения, может даже удастся полностью уйти от языковой модели обучающейся на потоке сырых данных.
Любой наш прогноз, тоже как бы в вероятностном поле. Скорее всего выгорит — действуем. Скорее всего провалится — ищем альтернативное, потенциально более успешное решение.
В целом — согласен. Но как вы хотите обучать действительно слепой, глухой и лишенный осязания "мозг в банке". Для начального набора эрудиции, существующий подход вполне рационален. Нерационально выжимать из него то, на что он изначально плохо приспособлен или не приспособлен вовсе.
Язык — инструмент описания реальности. Обучаться которой надо подобно школьникам. От простого к сложному. Параграф за параграфом, тему за темой, курс за курсом, предмет за предметом. Так, чтобы для обучения этому курсу, нужны были не гигабайты данных, а обычный учебник. На основании которого строить дистиллированный промежуточный слой графа понятий/сущностей, описывающий некий фрагмент реальности и уже на нем обучаться модели v.2.0.
Существующие модели, после соответствующего тюнинга, должны помочь в построении таких графов. А тюнингованные немного по другому, помогать тестерам искать слабые места. И так до тех пор, пока не удастся перейти на полное использование новой модели. Как при разработке компилятора, написать компилятор на том языке, который он компилирует.
Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.
Предположу, что мы уже оба в достаточной мере высказали свою позицию. На чем предлагаю попрощаться.
По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.
Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.
Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.
Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.
Хороший аргумент. :) Но разве к 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.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.
Я хотел показать влияние модификации контекста плюсами на распознавание формы. Раз наткнулся в отношении "еду", то и в любом другом омографе можно будет словить. Считать это багом или штатным поведением — на ваше усмотрение. Я скорее отношу к штатному. А вот удвоение ударений +ед+у это действительно баг.
Также посмотрите, не ставите ли сами себе подножки. Не может ли собственная предыдущая коррекция, попасть в окно оценки следующих за ней омографов. Предыдущий оутпут попадает в инпут следующего. Такое может как помочь ("берегу озера", если контекст указал на "бе́регу", то "о́зера", если на "берегу́", то "озёра"), так и помешать. Сам стараюсь избегать такого seq2seq, но вы там лучше в языках разбираетесь.
Коллега, а вы меня обманули.
Я взял еду на пикник -> Я взял ед+у на пикник
Я вз+ял еду на пикник -> Я взял +еду на пикник
То есть коррекция до деомографии недопустима.
Сразу уточню для чего это. Некоторые синтезаторы, вроде даже Google TTS в Android, не любят такие ударения. А библиотека будет использоваться не только с вашим синтезатором.
В коде убрать, точнее, найти слова с одной гласной несложно, но для словарной коррекции, это достаточно нетривиально — таких одногласных слов довольно много, в том числе при неожиданном авторском словообразовании. Так может сразу убрать или не ставить в вашем коде? Это может даже на капельку увеличит скорость.
Аналогично с "поверх менять в них ударение на нужное" при словарной коррекции. Нужно иметь две версии словаря или по два правила — для чистого текста и для неправильного ударения. Усложняется пайплайн. Впрочем, если плюсы вам не мешают, то библиотеку можно поставить в конец цепочки. Что не отменяет влияния правил меняющих сам текст ( "не с кем=не́скем" ).
С обычными ударениями понятно. Нет — поставим, есть — пропустим. Но не помешают ли расставленные плюсы деомо-модели? sent = "Я с легкостью узнаю их л+ица ", если морфологию рд.ед/им.мн решил доверить другой библиотеке.
Еще, предложу не ставить ударения в словах с одной гласной. Зачем "+я к+от"?
В целом, отличное решение для "ленивых", просто и достаточно качественно. Намного лучше чем голый текст и другие простые решения. Но если подготовка текста для создания аудиокниг (для личного прослушивания) требует чуть больше перфекционизма, будут проблемы.
Например немало омографов имен собственных. Начиная с явных Ангара́ и Саха́ра, которые вы наверное отслеживаете, заканчивая более специфичными Ба́совым, Бережно́го и даже среди имен встречается омография — бере(ё)зина, Бере́зина (фамилия), Березина́ (река). У меня таких более 400. Бывает надо поработать с аббревиатурами — КГБешник=кэгэбэ́шник или со словосочетаниями "под руку=по́друку", "не с кем=не́скем" (200 правил).
Все это делается в программах словарной коррекции, на стадии после омографии, чтобы не помешать ей, но до расстановки ударений. То есть, как минимум, нужна возможность по отдельности снять омографию и проставить ударения.
Омографы также можно разделить на смысловые, пресловутый "замок" и морфологические — скалы, краю. С последними неплохо справляются морф-таггеры — например Natasha (быстрая) и ее исторический предок DeepPavlov (точнее, но медленно). Не сравнивали с ними? А еще есть сложнейшая задач классификации (не)совершенных глаголов — узнаю, признаюсь; и чуть попроще, но кмк ненамного, изъявительные/повелительные — цените, служите. Не проверяли качество отдельно по таким группам?
В связи с вышесказанным, есть ли возможность разрешать неоднозначности только у указанных пользователем омографов? Естественно среди списка вами поддерживаемых. Чтобы появилась возможность использовать сильные стороны там, где справляется лучше, и отказаться от использования в областях, где не устроит.
Мы зациклились на внутренней схожести с устройством и работой мозга — ааа, нейрон. Предлагаю посмотреть на внешнюю — обучение. Человек обученный языку на потоке сырых данных, потом идет в школу и обучается предмету по учебнику, класс за классом, тема за темой, параграф за параграфом. Обучение на дистиллированных данных. С сетями надо идти по этому пути — композиция языковой и смысловых моделей. Считаю, что такая способность поэтапно обучаться на дистиллированных данных, как раз и есть отражение того самого "здравого смысла". А создать персистентные дистиллированные данные описания реальности, тот самый учебник для следующего поколения, должна помочь нам текущая модель. По мере его наполнения, может даже удастся полностью уйти от языковой модели обучающейся на потоке сырых данных.
Любой наш прогноз, тоже как бы в вероятностном поле. Скорее всего выгорит — действуем. Скорее всего провалится — ищем альтернативное, потенциально более успешное решение.
В целом — согласен. Но как вы хотите обучать действительно слепой, глухой и лишенный осязания "мозг в банке". Для начального набора эрудиции, существующий подход вполне рационален. Нерационально выжимать из него то, на что он изначально плохо приспособлен или не приспособлен вовсе.
Язык — инструмент описания реальности. Обучаться которой надо подобно школьникам. От простого к сложному. Параграф за параграфом, тему за темой, курс за курсом, предмет за предметом. Так, чтобы для обучения этому курсу, нужны были не гигабайты данных, а обычный учебник. На основании которого строить дистиллированный промежуточный слой графа понятий/сущностей, описывающий некий фрагмент реальности и уже на нем обучаться модели v.2.0.
Существующие модели, после соответствующего тюнинга, должны помочь в построении таких графов. А тюнингованные немного по другому, помогать тестерам искать слабые места. И так до тех пор, пока не удастся перейти на полное использование новой модели. Как при разработке компилятора, написать компилятор на том языке, который он компилирует.
Зачем-то опять выставляете так, будто я отрицаю полезность реактивности. Повторю, она полезна. Но как опциональный инструмент, а не фундаментальная концепция — ни шагу в сторону. Модель контролов, должна в равной удобной мере позволять использовать для них как реактивность, так и реализовать связи вручную через свойства/события.
Предположу, что мы уже оба в достаточной мере высказали свою позицию. На чем предлагаю попрощаться.
По нынешним временам слишком низкоуровнево. Как говорил выше, почти WinAPI. И даже если можно инкапсулировать, это надо делать самому. Поэтому не надо передергивать.
Возможно вы и правы. Но скорее потому, что мы говорим о разных интерфейсах. Для информационных страниц, просто добавь интерактивность, возможно существующие фреймворки годны. С другой стороны расположены полноценные десктопные приложения, в виде html-страницы (без рисования на canvas). Сплошь состоящие из контролов, контролов и еще раз контролов.
Как из моих слов вы сделали такой вывод? Хочу видеть UI контрол (скорее, хорошо проработанную библиотеку контролов), где вся сложность инкапсулирована и нужна, только если хочется чего-то эдакого, то есть в обычных условиях почти никогда. Он управляется собственными свойствами и событиями, в том числе с одно и двунаправленной привязкой к данным. Где ключевое "в том числе", а не исключительно.
Backbone, насколько про него когда-то читал, мог бы служить далеким предком такого подхода. А вот с jQuery даже рядом не лежало.
Хороший аргумент. :) Но разве к 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.
Все модели повели себя плюс-минус одинаково. Что-то заподозрили, но облако точек выглядело как начало процесса размножения делением у одноклеточных. Начали формироваться две группы, но с громадным их пересечением. И это для слова, принадлежащего к разным частям речи — существительное и глагол.
Также добавил два синонима, соответственно существительное и глагол — шампур и крутил. Их облака точек расположились, как и ожидалось после уменьшения размерности, довольно далеко друг от друга. А "вертел" притянулся заметно ближе к "крутил", как содержащий наиболее частотную форму "верте́л".
Но что же ожидалось? Одинаковые части речи должны были показать гораздо большую семантическую близость, чем близость между обоим их представителями — верте́л ближе к крутил и дальше от ве́ртел. В идеале иметь не облако "смыслов", а точку.
А ведь эти эмбединги лежат в основе языковых моделей. Поверх которых строится оценка фраз — последовательностей смыслов. Оцените как будет нарастать ошибка при построении связей второго порядка — сущность через сущность. Причем, считаю, что эмбединг не способен полностью отразить все связи сущности/термина с учетом их веса. Нужна более детерминированная древовидная/графовая модель реальности. Тогда и рассуждения перестанут накапливать ошибку.
Ну а пока надо помнить, что языковая модель ≠ модель реальности. Со всеми вытекающими.