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