Комментарии 10
Этот пункт применим к словарным записям, представляющих собой устойчивые группы из нескольких слов (потому что; в следствие; за границу).Нет никакой устойчивой группы «в следствие», есть только предлог «вследствие».
+1
Ещё пример: в течение/в течении. Правильность зависит от контекста.
Не указано, в каком порядке будут предлагаться варианты исправления, если изменения разных букв приведут к разным словам: «премая» — премия или прямая?
Не указано, в каком порядке будут предлагаться варианты исправления, если изменения разных букв приведут к разным словам: «премая» — премия или прямая?
0
НЛО прилетело и опубликовало эту надпись здесь
Вы правы. Поменял на составной предлог *в течение*.
0
Цели конкурировать со зрелыми библиотеками не было. Но, думаю, для определённых сценариев, например где вы работаете с фамилиями или узкоспецифичным словарём терминов, своё решение может составить здоровую конкуренцию Hunspell.
Скорость работы — O(1) на компиляцию фонетической метки, считая максимальную длину слова в русском языке константой, плюс скорость поиска по индексу, т.е. O(1) или O(log N). В общем быстро.
Спасибо за ссылку. Интересно будет сравнить, если удастся разобраться с Perl.
Скорость работы — O(1) на компиляцию фонетической метки, считая максимальную длину слова в русском языке константой, плюс скорость поиска по индексу, т.е. O(1) или O(log N). В общем быстро.
Спасибо за ссылку. Интересно будет сравнить, если удастся разобраться с Perl.
0
Скажите, почему алгоритм построения метки именно такой? Мне некоторые шаги показались спорными.
Например, выкидывание мягкого и твёрдого знака. Раз уж мы решили ориентироваться на то, как слова звучат при произношении — некорректно превращать «съедобный» в <седобный>, поскольку теряется звук «йот» как раз.
Также не очень понял Вашу идею про гласные после шипящих и «ц». Ну да, по правилам орфографии не допускаются конструкции вида «ця». Но есть ли гарантия, что так абсолютно никто не напишет?
И мысль с переусложнением алгоритма — не понял. Та модификация должна была улучшить результат, если это заключение из реальной статистике пользовательских написаний следует, а не ухудшить…
Например, выкидывание мягкого и твёрдого знака. Раз уж мы решили ориентироваться на то, как слова звучат при произношении — некорректно превращать «съедобный» в <седобный>, поскольку теряется звук «йот» как раз.
Также не очень понял Вашу идею про гласные после шипящих и «ц». Ну да, по правилам орфографии не допускаются конструкции вида «ця». Но есть ли гарантия, что так абсолютно никто не напишет?
И мысль с переусложнением алгоритма — не понял. Та модификация должна была улучшить результат, если это заключение из реальной статистике пользовательских написаний следует, а не ухудшить…
0
>> выкидывание мягкого и твёрдого знака
Тут дело в том, что к метке вы приводите как словарное слово, так и пользовательское слово. А пользователи любят распихивать твёрдый знак где нужно и где не нужно (смотрите датасет). В общем идея в том, чтобы подгонять алгоритм под наиболее частотные ошибки, а не под реальную фонетику.
>> Но есть ли гарантия, что так абсолютно никто не напишет?
Нет, гарантии нет. Но, как ни странно, это довольно редкая ошибка.
>> И мысль с переусложнением алгоритма — не понял.
Алгоритм очень грубый. Он, к примеру, не учитывает буквенный контекст — какие буквы до, какие после. И не стоить пытаться эти правила изобрести самостоятельно — это долго, дорого и вообще является задачей для машинного обучения. Мысль исключительно в этом.
Тут дело в том, что к метке вы приводите как словарное слово, так и пользовательское слово. А пользователи любят распихивать твёрдый знак где нужно и где не нужно (смотрите датасет). В общем идея в том, чтобы подгонять алгоритм под наиболее частотные ошибки, а не под реальную фонетику.
>> Но есть ли гарантия, что так абсолютно никто не напишет?
Нет, гарантии нет. Но, как ни странно, это довольно редкая ошибка.
>> И мысль с переусложнением алгоритма — не понял.
Алгоритм очень грубый. Он, к примеру, не учитывает буквенный контекст — какие буквы до, какие после. И не стоить пытаться эти правила изобрести самостоятельно — это долго, дорого и вообще является задачей для машинного обучения. Мысль исключительно в этом.
0
Есть просто такие слова, которые вообще с использованием мягкого/твёрдого знака и без являются разными по смыслу («гостья» — «гостя», «крупье» — «крупе», и так далее). И как-то странно сводить их к одной метке. Мне просто всегда казалось, что хэш-функция должна стремиться к минимизации количества коллизий :)
А насчёт до и после — мне кажется, в случае опечатки это вообще не важно, т.к. вероятность равна. А в случае с орфографией — да, в принципе, можно было бы пытаться сопоставлять полученное слово с базой наиболее распространённых ошибок (кстати, супер-скоростной способ, если базу держать небольшой). Но в этой ситуацией кстати уже делается простое сравнение, то есть выяснять, до появилась лишняя буква или после, нам тоже нужны нет. Либо я опять Вас не понял :)
А насчёт до и после — мне кажется, в случае опечатки это вообще не важно, т.к. вероятность равна. А в случае с орфографией — да, в принципе, можно было бы пытаться сопоставлять полученное слово с базой наиболее распространённых ошибок (кстати, супер-скоростной способ, если базу держать небольшой). Но в этой ситуацией кстати уже делается простое сравнение, то есть выяснять, до появилась лишняя буква или после, нам тоже нужны нет. Либо я опять Вас не понял :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем спеллчекер на фонетических алгоритмах своими руками