Вряд ли найдете много информации ru.wikipedia.org/wiki/%D0%A8%D1%80%D0%B5%D0%B9%D0%B4%D0%B5%D1%80,_%D0%AE%D0%BB%D0%B8%D0%B9_%D0%90%D0%BD%D0%B0%D1%82%D0%BE%D0%BB%D1%8C%D0%B5%D0%B2%D0%B8%D1%87
Там известная проблема — ВИНИТИ до сих пор не очень ценит наработки времен СССР. А скорее их перепродают во всякие мало- и много- мудрые современные фирмы.
Если любопытно, то здесь подробнее пишу www.facebook.com/permalink.php?story_fbid=606818949418449&id=100002710491649
PS Статистика есть у меня, вывод следующий — на сегодняшний день ваше решение нельзя считать перспективным и даже «работающим», зато у вас будет отличный опыт знакомства с комп. лингвистикой, так что «наших больше, наши в городе!»)
Рекомендую также зарегиться здесь forum.dialog-21.ru/actualforum.aspx
По вашей просьбе. Вот мои выводы на сегодняшний день.
1. Построенные на аксиомах «старой парадигмы» (именно о таком походе вы говорите в данном сообщении) программы не способны выявить даже все орфографические ошибки. Это связано с тем, что для исправления определенного класса ошибок требуется более сложные алгоритмы, нежели используются в традиционных программах проверки орфографии. Классический пример — «ться» и «тся» в возвратных глаголах; так, здесь можно использовать наработки Ю. Шрейдера, но подобные алгоритмы медлительны и не подходят для «онлайн» проверки орфографии (см. ниже п.2).
2. Чтобы повысить точность лингвистических программ требуется решить несколько «неклассических» задач. Например, до сих пор нет простого и быстрого способа автоматически выявить терминальные знаки («проблема точки»), нет алгоритма работы с дефисами и т. д. Таким образом, даже в простейшем случае, любая «классическая программа» будет неизбежно «тонуть» в «проблеме точки» и т. п.
PS Алгоритм Шрейдера, позволяющий в 75 % выявлять возможные ошибки использования возвратных глаголов (ться-тся), предполагает работу с «ближайшем окружением». Поэтому так важно сначала определить «терминальные» знаки.
3. Наиболее «точные» на сегодняшний день программы будут использовать т. н. «паттерны» и специальные, описывающие, внутренние языки (скажем, в том числе нечто похожее на регулярные выражения, но ближе к классическим языкам программирования). То есть речь идет о «препроцессорной» обработке текста, когда специальный «встроенный» язык, содержащий инструкции («правила») используется для выполнения действий над текстом. «Транслятор» для такого языка, как вы понимаете, невозможно написать на скриптах или языках интерпретаторах, здесь необходимо использовать по крайней мере компилируемые языки.
4. Почти все современные «классические» программы не работают с синтаксическими ошибками в должном объеме. Подразумевается, что «пользователь» правильно ставит запятые или иные знаки препинания. Также в программах, как правило, не исправляются стилистические или другого рода ошибки. Даже простейшие — типа зияний. Очень редко в программах используют сложные алгоритмы (например, алгоритм исправления ошибок на основе предварительной работы с массивом текстов, кстати, Гугль идет по этому пути). Иными словами — мы медленно и верно подходим к методам статистическим и корпусным.
5. Наконец, некое обобщение. Чтобы «вырваться» за пределы, поставленные многочисленными программами «старой школы» (aspell, myspell и подобные), необходимо иметь сложную и медлительную программу, способную работать с паттернами, также «выявлять» предложения и «встроенные» фразы.
То есть мы говорим о том, что сначала программа должна «понять», где заканчивается предложение, а уж потом провести какую-то «правку» орфографических и синтаксических, стилистических ошибок. Впрочем, во многих случаях достаточно работать просто с массивом слов. Если мы будем работать в рамках парадигмы «старой школы», мы продолжим медленное застревание на прежнем уровне, когда всего лишь «обнаруживаются» неправильные написания слов. Конечно, даже в такой форме это хорошее и полезное начинание. Однако «Хром» уже проверяет некоторого рода ошибки (кажется, используется что-то типа aspell) в окошке чата. Так зачем встраивать еще какие-то программы, ведь «качественного» скачка не будет.
Дополнительно, замечания по тексту. Вы пишите.
«Автоматически же искать разницу между ДЕРЖАТСЯ и ДЕРЖАТЬСЯ не рекомендую»
Алгоритм Шрейдера весьма серьезно и быстро в 75 % исправляет такие ошибки (см. выше).
«Так и родилась идея chas-correct — расширения для браузера, автоматически исправляющего многие ошибки»
«… может быть легко формализовано и исправлено автоматически.»
К сожалению, подобного рода ошибки не так уж и часты.
Боюсь, в итоге вы получите еще одну программу, которая будет предлагать варианты трансформации слова «кыт» в «кот», «кВт», «крот» и т. д. ))
«Полноценный анализ текста в реальном времени в браузере всё равно едва ли возможен»
Возможен. Если будет использоваться «серверное» решение, как с распознаванием речи. Кроме всего прочего, если вы уж говорите об автоматической правке ошибочного слова, то никак не обойтись без работы с достаточно внушительными массивами, хотя бы для того, чтобы «исправлять» с высокой точностью)
К слову сказать, несколько лет назад С. А. Крылов из РГГУ предложил использовать поисковые технологии для создания лингвистических систем. Конечно, «в общем» эта идея очень интересна и привлекательна, но с некоторыми оговорками. Так, мы все понимаем, что «поисковик» (если говорить о Google), работая с массивами текстов, будет очевидно отражать какую-то «социолингвистическую» картину — как ее понимал наш российско-советский академик Ларин. То есть, Google на выходе можно использовать как статистический массив (как в вашем эксперименте с Word2Vec), но с определенного рода ограничениями. Однако даже в этом случае поисковик «исправляет» неправильное написание некоторых слов.
Это легко показать на следующих примерах: а)
«заборомлуг» — Гугль абсолютно логично выдаст следующий вариант «за забором – луг», опустив, правда, вариант «за бором луг»; б) «колубель» остается «колубелью», так как в кэше Гугля это слово есть, но «преключение» однозначно превращается в «приключение»; е) мировозрение — мировоззрение; рубак — рубаки, а не «рыбак» и т.д.; «тероррист» остается «терорристом», но «галюцинации» превращаются в «галлюцинации» и т. д.
Поэтому последние месяцы меня все более соблазняет мысль, что в программы проверки орфографии (и даже пунктуации) следует встраивать классы работы со статистическими массивами. В нашей программе мы реализовали поиск по биграммам и получили весьма любопытные результаты. По крайней мере «тесты» Штольке уже не показывают полную бессмыслицу.
Добрый вечер. Конечно, здесь в сообщении основная тема иная, никакой «человечности». Если говорить более точно, то я пишу о т. н. «классической» проблеме спеллчекеров — «неспособности» традиционных спеллчекеров автоматически исправлять ошибки с более менее высокой «валидностью».
Например, все «классические» спеллчекеры, в которых используются «алгоритмы Левенштейна», «расстояние Хэмминга» и даже «метод Soundex» на выходе явно избыточны. Так, ошибочное слово сравнивается тем или иным образом с «возможно истинным», определяя «расстояние», необходимое для перестановки букв, чтобы превратить какое-либо слово в набор «возможных» слов: возьмем ошибочные слова «колубель» и «преключение», на выходе программы aspell (или подобной) мы получим букет «возможных правок». Полученные варианты «правки» слова «преключение» компьютерными программами типа aspell, myspell: переключение, преклонение, приключение, перезаключение, приключении, приключений, переключен, переключенные — и это не все варианты!
На «колубель» варианты следующие: колу-бель, колу бель, кобель, колебля, колеблешь, клубень, колыбель, колыбелью, колыбели, кабель, колыбелька, колыбельки, колыбельку & etc.
Как из «колубели» получается кобель и «заколебал» остается глубокой тайной работы современных программистов (хотя очевидно, что мы видим работу алгоритма Левенштейна).
В данном сообщении я пишу о возможных решениях этой проблемы, позволяющей с той или иной точностью решать задачи автоматической правки ошибочного написания слова. Что интересно — подобные вышеописанному алгоритмы с успехом будут править и слова с ошибочными двойными гласными, согласными и т.д.
Я обязательно продолжу эту тему, как только будет свободное время. Конечно, перейду к стохастическим грамматикам и биграммам, триграммам & etc
Там известная проблема — ВИНИТИ до сих пор не очень ценит наработки времен СССР. А скорее их перепродают во всякие мало- и много- мудрые современные фирмы.
Если любопытно, то здесь подробнее пишу www.facebook.com/permalink.php?story_fbid=606818949418449&id=100002710491649
PS Статистика есть у меня, вывод следующий — на сегодняшний день ваше решение нельзя считать перспективным и даже «работающим», зато у вас будет отличный опыт знакомства с комп. лингвистикой, так что «наших больше, наши в городе!»)
Рекомендую также зарегиться здесь forum.dialog-21.ru/actualforum.aspx
1. Построенные на аксиомах «старой парадигмы» (именно о таком походе вы говорите в данном сообщении) программы не способны выявить даже все орфографические ошибки. Это связано с тем, что для исправления определенного класса ошибок требуется более сложные алгоритмы, нежели используются в традиционных программах проверки орфографии. Классический пример — «ться» и «тся» в возвратных глаголах; так, здесь можно использовать наработки Ю. Шрейдера, но подобные алгоритмы медлительны и не подходят для «онлайн» проверки орфографии (см. ниже п.2).
2. Чтобы повысить точность лингвистических программ требуется решить несколько «неклассических» задач. Например, до сих пор нет простого и быстрого способа автоматически выявить терминальные знаки («проблема точки»), нет алгоритма работы с дефисами и т. д. Таким образом, даже в простейшем случае, любая «классическая программа» будет неизбежно «тонуть» в «проблеме точки» и т. п.
PS Алгоритм Шрейдера, позволяющий в 75 % выявлять возможные ошибки использования возвратных глаголов (ться-тся), предполагает работу с «ближайшем окружением». Поэтому так важно сначала определить «терминальные» знаки.
3. Наиболее «точные» на сегодняшний день программы будут использовать т. н. «паттерны» и специальные, описывающие, внутренние языки (скажем, в том числе нечто похожее на регулярные выражения, но ближе к классическим языкам программирования). То есть речь идет о «препроцессорной» обработке текста, когда специальный «встроенный» язык, содержащий инструкции («правила») используется для выполнения действий над текстом. «Транслятор» для такого языка, как вы понимаете, невозможно написать на скриптах или языках интерпретаторах, здесь необходимо использовать по крайней мере компилируемые языки.
4. Почти все современные «классические» программы не работают с синтаксическими ошибками в должном объеме. Подразумевается, что «пользователь» правильно ставит запятые или иные знаки препинания. Также в программах, как правило, не исправляются стилистические или другого рода ошибки. Даже простейшие — типа зияний. Очень редко в программах используют сложные алгоритмы (например, алгоритм исправления ошибок на основе предварительной работы с массивом текстов, кстати, Гугль идет по этому пути). Иными словами — мы медленно и верно подходим к методам статистическим и корпусным.
5. Наконец, некое обобщение. Чтобы «вырваться» за пределы, поставленные многочисленными программами «старой школы» (aspell, myspell и подобные), необходимо иметь сложную и медлительную программу, способную работать с паттернами, также «выявлять» предложения и «встроенные» фразы.
То есть мы говорим о том, что сначала программа должна «понять», где заканчивается предложение, а уж потом провести какую-то «правку» орфографических и синтаксических, стилистических ошибок. Впрочем, во многих случаях достаточно работать просто с массивом слов. Если мы будем работать в рамках парадигмы «старой школы», мы продолжим медленное застревание на прежнем уровне, когда всего лишь «обнаруживаются» неправильные написания слов. Конечно, даже в такой форме это хорошее и полезное начинание. Однако «Хром» уже проверяет некоторого рода ошибки (кажется, используется что-то типа aspell) в окошке чата. Так зачем встраивать еще какие-то программы, ведь «качественного» скачка не будет.
Дополнительно, замечания по тексту. Вы пишите.
«Автоматически же искать разницу между ДЕРЖАТСЯ и ДЕРЖАТЬСЯ не рекомендую»
Алгоритм Шрейдера весьма серьезно и быстро в 75 % исправляет такие ошибки (см. выше).
«Так и родилась идея chas-correct — расширения для браузера, автоматически исправляющего многие ошибки»
«… может быть легко формализовано и исправлено автоматически.»
К сожалению, подобного рода ошибки не так уж и часты.
Боюсь, в итоге вы получите еще одну программу, которая будет предлагать варианты трансформации слова «кыт» в «кот», «кВт», «крот» и т. д. ))
«Полноценный анализ текста в реальном времени в браузере всё равно едва ли возможен»
Возможен. Если будет использоваться «серверное» решение, как с распознаванием речи. Кроме всего прочего, если вы уж говорите об автоматической правке ошибочного слова, то никак не обойтись без работы с достаточно внушительными массивами, хотя бы для того, чтобы «исправлять» с высокой точностью)
Это легко показать на следующих примерах: а)
«заборомлуг» — Гугль абсолютно логично выдаст следующий вариант «за забором – луг», опустив, правда, вариант «за бором луг»; б) «колубель» остается «колубелью», так как в кэше Гугля это слово есть, но «преключение» однозначно превращается в «приключение»; е) мировозрение — мировоззрение; рубак — рубаки, а не «рыбак» и т.д.; «тероррист» остается «терорристом», но «галюцинации» превращаются в «галлюцинации» и т. д.
Поэтому последние месяцы меня все более соблазняет мысль, что в программы проверки орфографии (и даже пунктуации) следует встраивать классы работы со статистическими массивами. В нашей программе мы реализовали поиск по биграммам и получили весьма любопытные результаты. По крайней мере «тесты» Штольке уже не показывают полную бессмыслицу.
Например, все «классические» спеллчекеры, в которых используются «алгоритмы Левенштейна», «расстояние Хэмминга» и даже «метод Soundex» на выходе явно избыточны. Так, ошибочное слово сравнивается тем или иным образом с «возможно истинным», определяя «расстояние», необходимое для перестановки букв, чтобы превратить какое-либо слово в набор «возможных» слов: возьмем ошибочные слова «колубель» и «преключение», на выходе программы aspell (или подобной) мы получим букет «возможных правок». Полученные варианты «правки» слова «преключение» компьютерными программами типа aspell, myspell: переключение, преклонение, приключение, перезаключение, приключении, приключений, переключен, переключенные — и это не все варианты!
На «колубель» варианты следующие: колу-бель, колу бель, кобель, колебля, колеблешь, клубень, колыбель, колыбелью, колыбели, кабель, колыбелька, колыбельки, колыбельку & etc.
Как из «колубели» получается кобель и «заколебал» остается глубокой тайной работы современных программистов (хотя очевидно, что мы видим работу алгоритма Левенштейна).
В данном сообщении я пишу о возможных решениях этой проблемы, позволяющей с той или иной точностью решать задачи автоматической правки ошибочного написания слова. Что интересно — подобные вышеописанному алгоритмы с успехом будут править и слова с ошибочными двойными гласными, согласными и т.д.
Я обязательно продолжу эту тему, как только будет свободное время. Конечно, перейду к стохастическим грамматикам и биграммам, триграммам & etc