Возможно, опечатка в слове python что это такое
Обновлено: 03.07.2024
В этой главе мы разработаем маленькое и чрезвычайно быстрое средство проверки орфографии, которое полностью размещается в памяти и занимает на удивление мало памяти.
Мотивация для создания такой программы восходит к середине 70-х годов, когда я работал в газете программистом. Отсутствие какой-либо формы автоматической проверки орфографии означало огромное количество времени для людей, читающих корректуру, чтобы тщательно найти слова с ошибками и исправить их. Нам нужна была программа, которая могла бы просто пометить слово, которого нет в лексиконе (у нас было более 50 000 слов)
С сегодняшними компьютерными технологиями это довольно тривиально. У нас есть файл с 53 751 общим словом заклинание.words, который выглядит следующим образом:
Мы можем получить это в список в памяти с помощью следующего
Функция полосы необходима для удаления символа новой строки в конце каждого слова.
Теперь мы можем просто проверить, есть ли слово в нашем списке
Но если бы мы проверяли каждое слово в статье из 1000 слов, требования к времени были бы аналогичны
И даже на моем ноутбуке 2014 года есть пауза примерно в 2 секунды.
Но сегодня это не проблема. В Python у нас есть словари, встроенные в язык. Поэтому мы можем просто сделать следующее.
Теперь даже при 100-кратном увеличении количества запросов над подсказкой возвращается почти сразу же.
Увы, в середине 70-х о такой вычислительной мощности можно было только мечтать. За 40 лет у нас было примерно тысячекратное увеличение скорости процессора, оперативной памяти и емкости диска. Вчерашний мегабайт — это сегодняшний гигабайт. Еще вчера циклы ЦП измерялись в микросекундах, сегодня — в наносекундах. Нашим серверным компьютером, на котором должна была работать программа проверки орфографии (наряду с примерно 20 другими программами), был PDP-11/70, у которого было всего 1,5 мегабайта основной памяти и несколько лишних тактов процессора.
То, что мы сделали, было похоже на хеш-таблицу. Хэш-функции могут генерировать псевдослучайный адрес, повторяющийся для ключа. Каждое слово в лексиконе может быть ключом и может быть преобразовано в адрес. Это можно сделать недорого с точки зрения времени. А поскольку нам нужны только значения True и False, мы можем заменить их на «1» и «0».
Итак, рассмотрим растровое изображение с миллионом битов. Если каждое из 53751 слова в нашем лексиконе используется для генерации хэша от нуля до 999 999, то мы можем установить соответствующий бит в растровом изображении равным единице. А позже, чтобы проверить, есть ли какое-то слово в лексиконе, мы просто генерируем его хеш и смотрим, установлен ли этот бит. Если это так, то мы предполагаем, что слово написано правильно. Если нет, то предполагается опечатка.
Со вторым предположением все в порядке. Если бит не установлен, то слова явно нет в нашем лексиконе (наше определение слова с ошибкой). Но может случиться так, что действительно ошибочное слово все равно порождает хеш, уже заданный одним (или даже несколькими) словами из лексикона. Это приводит к «ложноположительному результату» и не может быть устранено. Но его можно свести к минимуму.
Если бы каждое из 53751 слова генерировало уникальный хэш, мы бы установили ровно столько битов. Но из-за возможности перекрытия устанавливается меньше фактических битов. Оказывается, шансы получить ложное срабатывание из-за слова с ошибкой в этой конфигурации чуть меньше одного из двадцати.
Этого недостаточно.
Одним из способов улучшить ситуацию может быть простое удвоение размера растрового изображения. Тогда будет установлен только около 1 бита из 40, и наш уровень ложных срабатываний уменьшится вдвое. Конечно, наша хэш-функция должна охватывать новый размер.
Еще лучше и гораздо интереснее было бы создать второе растровое изображение с другой хеш-функцией и позволить каждому слову в словаре установить один бит в обоих. Чтобы проверить тестовое слово, мы смотрим, установлены ли оба бита. Слова, которых нет в лексиконе, теперь имеют только 1/400 (20*20) шанс быть ложным срабатыванием.
Но теперь мы использовали вдвое больше памяти, а результат по-прежнему так себе. Интересный компромисс состоит в том, чтобы использовать только одно растровое изображение, но по-прежнему устанавливать биты из двух независимых хеш-функций. Тогда будет установлен примерно 1 бит из 10 и частота ошибок будет около 1/100 (10*10). Что ж, это все же лучше, чем 1/20.
Мы можем продолжить это с еще большим количеством функций. С каждым из них плотность битов увеличивается (плохо), но количество ложных срабатываний сохраняется. Вот некоторые результаты использования от 4 до 7 хеш-функций.
На самом деле это делается с размером растрового изображения 1048576 (2 ** 20). Числа от 194320 до 277565 — это количество битов, фактически установленных нашим лексиконом. Деление на общее количество битов дает нам базовую дробь, которая затем возводится в соответствующую степень, чтобы получить ожидаемую частоту ложных срабатываний. Для 4 функций это чуть больше 1/1000. К 7 это примерно 1/10000. По причинам, которые вскоре станут понятны, мы будем использовать 6 функций.
Класс Bitmap¶
Наш модуль bitmap.py определяет класс Bitmap, который можно использовать следующим образом.
Смоделированное растровое изображение представляет собой список целых чисел, каждое из которых состоит из 16 бит.Итак, 4 целых числа дают нам растровое изображение из 64 бит. Наблюдая за изменением b.map, вы заглядываете под капот. Мы можем установить биты следующим образом.
Для нашего средства проверки орфографии мы получаем нашу миллионную (1048576) битовую карту следующим образом
Последний вызов len показывает, что мы используем 65 536 (64 КБ) 16-битных слов для получения растрового изображения из 1048 576 бит. В то время это составляло около 12% памяти нашего PDP 11/70.
Получение наших хеш-функций¶
Мы достаточно тщательно изучили возможные хэш-функции, чтобы убедиться, что каждая из них будет давать одинаковые результаты по растровому изображению и что эти функции не зависят друг от друга. Но для этой симуляции я собираюсь просто использовать функцию md5 модуля hashlib, чтобы сгенерировать красивое 32-значное шестнадцатеричное число (строковая форма) из любой входной строки. Я подозреваю, что это просто отлично, особенно для этой демонстрации.
Для отображения 2**20 бит требуется 5 шестнадцатеричных цифр (почему?). Если мы разделим первые 30 цифр на 6 фрагментов по 5 цифр, то у нас будет 6 независимых хэш-чисел для использования.
Вы можете видеть, что все биты, которые должны быть установлены для «зиготического», находятся в соответствующем диапазоне.
Простая проверка орфографии¶
Наша программа SpellCheck.py объединяет все эти идеи. Сначала он создает и заполняет растровое изображение всеми 53751 словом (это занимает пару секунд). Затем он берет текст со стандартного ввода. Текст сначала лишен знаков препинания и переведен в нижний регистр. Затем каждое слово проверяется на орфографию и выводится на стандартный вывод вместе с результатом. Логика программы должна быть простой.
Это наш тестовый файл:
Сейчас самое время съесть зиготический цвибек. Не делайте этого в помещении с кондиционером, хорошо?:
Комментарии¶
В нашей исходной реализации мы использовали только 4 хеш-функции и всего 32768 слов памяти. Та двухсекундная пауза, что сопровождала заполнение растрового изображения лексиконом, составляла тогда около минуты. Это не в тысячу раз медленнее. Мы получаем преимущество примерно 30 к 1, используя C или ассемблер вместо Python. Также я не уверен, насколько дорога (по времени) функция md5.
Первоначальная программа работала как серверная программа (в то время называлась "спуллер"). Растровое изображение с загруженным словарем находилось в виде файла на диске. Это может быть загружено за секунду или слишком. Но менять лексику на лету было сложно. Удаление ошибки означало перезагрузку всего растрового изображения. (почему?).
Для своего времени эта маленькая программа была воплощением мечты, и она распространилась из нашей газеты примерно на 30 других, использующих ту же компьютерную систему для набора текста. Но в течение 10-15 лет гораздо лучшая проверка орфографии стала доступна в других системах, построенных на более мощном оборудовании. Они могут предложить предложения по исправлению. Наши не смогли. (почему?)
Чтобы увидеть, как далеко мы продвинулись с тех пор, взгляните на курс Coursera Natural Language Processing от Stanford Online. На момент написания он не был доступен как курс, но видео можно было посмотреть в качестве превью. Вторая половина второй недели посвящена исправлению правописания.
В ближайшем будущем я хочу написать главу о фонетическом алгоритме Soundex, разумеется, с небольшой реализацией на Python. Это может предоставить элементарный способ предложить возможные исправления слов с ошибками.
И последнее. Лексика довольно старая. Последнее обновление могло быть около 1990 года. Некоторые слова отсутствуют. Особенно очевидны электронная почта и интернет.
Однажды в 2007 году два друга (Дин и Билл) независимо друг от друга сказали мне, что они поражены исправлением орфографии Google. Введите запрос, например [правописание], и Google мгновенно выдаст результаты для: правописание . Я думал, что Дин и Билл, будучи высококвалифицированными инженерами и математиками, должны иметь хорошее представление о том, как работает этот процесс. Но они этого не знали, и, если подумать, зачем им знать о чем-то, что так далеко выходит за рамки их специальности?
Я подумал, что им и другим было бы полезно получить объяснение. Полная информация о корректоре орфографии промышленной силы довольно сложна (вы можете немного прочитать об этом здесь или здесь). Но я прикинул, что во время трансконтинентального перелета на самолете я смогу написать и объяснить игрушечный корректор орфографии, который достигает 80-90% точности при скорости обработки не менее 10 слов в секунду примерно на половине страницы кода.
И вот он (или см. в файле Spell.py):
Функция correction(word) возвращает вероятное исправление правописания:
Как это работает: немного теории вероятности
Вызов correction(w) пытается выбрать наиболее вероятное исправление правописания для w. Невозможно узнать наверняка (например, следует ли исправить «опоздания» на «поздно», или «последние», или «латте», или . ), что предполагает использование вероятностей. Мы пытаемся найти исправление c из всех возможных исправлений-кандидатов, которое максимизирует вероятность того, что c является предполагаемым исправлением, учитывая исходное слово w< /я>:
- Механизм выбора: argmax
Мы выбираем кандидата с наибольшей комбинированной вероятностью.
Очевидный вопрос: зачем брать простое выражение, такое как P(c|w), и заменять его более сложным выражением, включающим две модели, а не одну? Ответ заключается в том, что P(c|w) уже объединяет два фактора, и их легче разделить и разобраться с ними. явно. Рассмотрим слово с ошибкой w="thew" и два кандидата на исправление c="the" и c="thaw". У кого выше P(c|w)? Что ж, "оттепель" кажется хорошей, потому что единственное изменение - это "а" на "е", что является небольшим изменением. С другой стороны, «the» кажется хорошим, потому что «the» — очень распространенное слово, и хотя добавление «w» кажется большим и менее вероятным изменением, возможно, палец машинистки соскользнул с «e». Дело в том, что для оценки P(c|w) мы должны учитывать как вероятность c, так и вероятность изменения от < i>c в w в любом случае, поэтому лучше формально разделить два фактора.
Как это работает: немного Python
- Механизм выбора: в Python max с аргументом key выполняет 'argmax'.
Это может быть большой набор. Для слова длины n будет n удалений, n-1 транспозиций, 26n изменений, и 26(n+1) вставок, всего 54n+25 (некоторые из которых обычно дублируются). Например, однако, если мы ограничимся известными словами, т. е. имеющимися в словаре, то набор будет намного меньше: мы также рассмотрим исправления, требующие двух простые правки. Это создает гораздо больший набор возможностей, но обычно только некоторые из них являются известными словами: мы говорим, что результаты edits2(w) имеют расстояние редактирования 2 от w.
- Исходное слово, если оно известно; иначе
- Список известных слов на расстоянии редактирования один, если они есть; иначе
- Список известных слов на расстоянии редактирования два, если они есть; иначе
- Исходное слово, хотя оно и неизвестно.
Оценка
Пришло время оценить, насколько хорошо работает эта программа. После того, как мой самолет приземлился, я загрузил корпус орфографических ошибок Биркбека Роджера Миттона из Оксфордского текстового архива. Из этого я извлек два тестовых набора исправлений. Первый предназначен для разработки, то есть я могу смотреть на него, пока разрабатываю программу. Второй - это окончательный набор тестов, то есть мне не разрешено ни смотреть на него, ни изменять мою программу после его оценки. Эта практика иметь два комплекта является хорошей гигиеной; это не дает мне обмануть себя, думая, что я справляюсь лучше, чем на самом деле, настроив программу на один конкретный набор тестов. Я также написал несколько модульных тестов:
Это дает результат:
Итак, на тестовом наборе мы получаем 75 % правильных ответов (обработка слов со скоростью 41 слово в секунду), а на финальном тестовом наборе — 68 % правильных ответов (35 слов в секунду). В заключение я достиг своих целей по краткости, времени разработки и скорости выполнения, но не по точности. Возможно, мой тестовый набор был слишком сложным, или, возможно, моя простая модель просто недостаточно хороша, чтобы достичь точности 80 % или 90 %.
Будущая работа
-
P(c), языковая модель. Мы можем выделить два источника ошибок в языковой модели. Тем серьезнее неизвестные слова. В наборе для разработки неизвестных слов 15, или 5%, а в финальном тестовом наборе неизвестных слов 43 или 11%. Вот несколько примеров вывода spelltest с verbose=True):
В этом выводе мы показываем вызов исправления, а также фактические и ожидаемые результаты (со счетчиками WORDS в скобках). Счетчики (0) означают, что целевого слова не было в словаре, поэтому у нас нет шансов сделать это правильно. Мы могли бы улучшить языковую модель, собрав больше данных и, возможно, используя немного английской морфологии (например, добавив "ility" или "able" в конец слова).
Еще один способ справиться с неизвестными словами — разрешить в результате исправления быть слово, которое мы не видели. Например, если введено слово «электроэнцефалографическиz», хорошим исправлением будет замена конечной «z» на «y», хотя слова «электроэнцефалографически» нет в нашем словаре. Мы могли бы добиться этого с помощью языковой модели, основанной на компонентах слов: возможно, на слогах или суффиксах, но проще основывать ее на последовательностях символов: обычных двух-, трех- и четырехбуквенных последовательностях.
Почему "адрес" следует исправить на "адрес", а не на "акры"? Интуиция подсказывает, что две правки с «d» на «dd» и с «s» на «ss» должны быть довольно распространенными и иметь высокую вероятность, в то время как единственная правка с «d» на «c» должна иметь низкую вероятность. .
Очевидно, что мы могли бы использовать лучшую модель стоимости правок.Мы могли бы использовать нашу интуицию, чтобы назначить более низкие затраты на удвоение букв и замену гласной на другую гласную (по сравнению с произвольной заменой буквы), но, похоже, лучше собрать данные: получить корпус орфографических ошибок и подсчитать, насколько вероятно, что это произойдет. заключается в выполнении каждой вставки, удаления или изменения с учетом окружающих символов. Нам нужно много данных, чтобы сделать это хорошо. Если мы хотим посмотреть на замену одного символа другим, учитывая окно с двумя символами с каждой стороны, это 26 6 , что составляет более 300 миллионов символов. В среднем вам понадобится несколько примеров каждого, поэтому нам нужно как минимум миллиард символов корректирующих данных; вероятно, безопаснее иметь по крайней мере 10 млрд.
Обратите внимание, что существует связь между языковой моделью и моделью ошибок. Текущая программа имеет такую простую модель ошибок (все редактирование на расстоянии 1 слова перед любым редактированием на расстоянии 2 слова), что препятствует языковой модели: мы боимся добавлять в модель непонятные слова, потому что, если одно из этих непонятных слов окажется редактировать расстояние 1 от входного слова, тогда оно будет выбрано, даже если на расстоянии редактирования 2 есть очень распространенное слово. С лучшей моделью ошибок мы можем более агрессивно добавлять непонятные слова в словарь. Вот несколько примеров, когда наличие непонятных слов в словаре причиняет нам боль:
Мы могли бы рассмотреть возможность расширения модели, разрешив ограниченный набор правок на расстоянии редактирования 3. Например, разрешив только вставку гласной рядом с другой гласной, или замену гласной на другую, или замену близких согласных. например, от "c" до "s" будет обрабатывать почти все эти случаи.
Мы не можем знать, что correction('where') должно быть "were" хотя бы в одном случае, но должно оставаться "where" в других случаях. Но если бы запрос был correction('Они, куда идут'), то вполне вероятно, что "где" следует исправить на "были".
Контекст окружающих слов может помочь, когда есть очевидные ошибки, но два или более хороших кандидата на исправление. Учтите:
Почему слово "теар" должно исправляться как "там", а не как "их"? Трудно сказать по одному слову, но если бы запрос был исправление('Здесь ничего нет'), это было бы ясно.
Чтобы построить модель, которая анализирует несколько слов одновременно, нам потребуется много данных. К счастью, Google выпустил базу данных с количеством слов для всех последовательностей длиной до пяти слов, собранных из триллионов слов.
Я считаю, что корректор правописания с точностью 90 % должен использовать контекст окружающих слов, чтобы сделать выбор. Но мы оставим это на другой день.
Дополнительная литература
- У Роджера Миттона есть обзорная статья о проверке орфографии.
- Джурафски и Мартин хорошо освещают исправление орфографии в своем тексте Speech and Language Processing.
- Мэннинг и Шутце очень хорошо освещают статистические языковые модели в своем тексте Основы статистической обработки естественного языка, но, похоже, они не охватывают орфографию (по крайней мере, ее нет в указателе).< /li>
- В проекте aspell есть много интересного материала, в том числе некоторые тестовые данные, которые кажутся лучше, чем то, что я использовал.
- В проекте LingPipe есть учебник по правописанию.
Благодарности
Иван Пеев, Джей Лян, Дмитрий Рябой и Дариус Бэкон указали на проблемы в более ранних версиях этого документа.
Другие компьютерные языки
После того, как я опубликовал эту статью, разные люди написали версии на разных языках программирования. Это может быть интересно для тех, кто любит сравнивать языки, или для тех, кто хочет позаимствовать реализацию на желаемом целевом языке:
Другие естественные языки
- Упрощенный китайский, Эрик Ю Сюй
- Ясуси Аоки на японском
- Корейский: Чонман Ку
- Русский Петров Александр
Спасибо всем авторам за эти реализации и переводы.
Проверка орфографии Pure Python на основе записи в блоге Питера Норвига о настройке простого алгоритма проверки орфографии.
Он использует алгоритм расстояния Левенштейна для поиска перестановок в пределах расстояния редактирования, равного 2, от исходного слова. Затем он сравнивает все перестановки (вставки, удаления, замены и транспозиции) с известными словами в списке частоты слов. Те слова, которые чаще всего встречаются в частотном списке, с большей вероятностью являются правильными результатами.
pyspellchecker поддерживает несколько языков, включая английский, испанский, немецкий, французский и португальский. Информацию о том, как создавались словари и как их можно обновлять и улучшать, см. в разделе «Создание и обновление словарей» файла readme!
pyspellchecker поддерживает Python 3
pyspellchecker позволяет настроить расстояние Левенштейна (до двух) для проверки.Для более длинных слов настоятельно рекомендуется использовать расстояние 1, а не значение по умолчанию 2. См. краткое руководство, чтобы узнать, как можно изменить параметр расстояния.
Установка¶
Проще всего установить с помощью pip:
Для установки из исходного кода:
Для поддержки python 2.7 установите выпуск 0.5.6, но учтите, что никакие будущие обновления не будут поддерживать python 2.
Быстрый старт¶
После установки использование pyspellchecker должно быть достаточно простым:
Если список частоты слов вам не нравится, вы можете добавить дополнительный текст, чтобы создать список, более подходящий для вашего варианта использования.
Если слова, которые вы хотите проверить, длинные, рекомендуется уменьшить расстояние до 1. Это можно сделать либо при инициализации класса проверки орфографии, либо постфактум.
Неанглийские словари¶
pyspellchecker поддерживает несколько словарей по умолчанию как часть пакета по умолчанию. Каждый из них прост в использовании при инициализации словаря:
- Английский — en
- Испанский — "es"
- Французский – ‘fr’
- Португальский – ‘pt’
- Немецкий — "de"
- Русский - "ru"
Создание и обновление словаря¶
Создание словарей, к сожалению, не точная наука. Я предоставил сценарий, который на основе текстового файла предложений (в данном случае из OpenSubtitles) будет генерировать список частоты слов на основе слов, найденных в тексте. Затем скрипт пытается *очистить* частоту слов, например, удаляя слова с недопустимыми символами (обычно из других языков), удаляя слова с малым количеством слов (орфографические ошибки?) и пытаясь применить доступные правила (не более одного ударения). за слово на испанском языке). Затем он удаляет слова из списка известных слов, которые должны быть удалены. Затем он добавляет в словарь слова, которые, как известно, отсутствуют или были удалены из-за слишком низкой частоты.
Будет очень желательна любая помощь в обновлении и поддержании словарей. Для этого можно начать обсуждение на GitHub или добавить запросы на обновление файлов включения и исключения.
Дополнительные методы¶
Доступна онлайн-документация; ниже приведена краткая версия некоторых доступных функций:
исправление(слово) : возвращает наиболее вероятный результат для слова с ошибкой
candidates(word) : возвращает набор возможных кандидатов на слово с ошибкой
known([words]): возвращает те слова, которые есть в списке частоты слов
unknown([words]): возвращает те слова, которых нет в частотном списке
word_probability(word): частота данного слова среди всех слов в списке частот
Следующие элементы вряд ли потребуются пользователю, но доступны:¶
edit_distance_1(word): возвращает набор всех строк с расстоянием Левенштейна, равным единице, на основе алфавита выбранного языка
edit_distance_2(word): возвращает набор всех строк с расстоянием Левенштейна, равным двум, на основе алфавита выбранного языка
В этом посте мы поговорим о трех разных пакетах для написания кода для проверки орфографии на Python: pyspellchecker, TextBlob и autocorrect.
pyspellchecker
Пакет pyspellchecker позволяет выполнять орфографические исправления, а также просматривать возможные варианты написания слова с ошибкой. Чтобы установить пакет, вы можете использовать pip:
После установки pyspellchecker очень прост в использовании. Обратите внимание: несмотря на то, что мы используем «pyspellchecker» при установке через pip, мы просто вводим «spellchecker» в операторе импорта пакета. Первая часть — это создание объекта SpellChecker, который мы просто назовем «spell».
Теперь мы готовы проверить это с несколькими опечатками. Мы будем использовать несколько слов из этого списка часто употребляемых слов с ошибками.
Чтобы попытаться исправить ошибку, вы можете использовать метод исправления:
pyspellchecker также имеет метод разделения слов в предложении.
После того, как у нас есть список слов в предложении, мы можем просто перебрать каждое слово (путем понимания списка), используя наш объект SpellChecker.
Если вы просто хотите отметить, какие слова в предложении написаны с ошибками, вы можете использовать метод неизвестно. Этот метод вернет набор слов Python с возможными ошибками.
Мы также можем увидеть возможные варианты написания слова с ошибкой.
TextBlob
Мощный TextBlob также может исправлять орфографию. Чтобы установить TextBlob, мы можем использовать pip (обратите внимание на строчные буквы):
Чтобы использовать функцию проверки орфографии TextBlob, нам просто нужно импортировать класс Word. Затем мы можем ввести слово и проверить его правописание с помощью метода проверка правописания, как показано ниже.
Как видно выше, TextBlob возвращает две части: рекомендуемое исправление для этого слова и показатель достоверности, связанный с исправлением. В этом случае мы просто получим одно слово с достоверностью 1,0 или 100%.
Давайте попробуем другое слово, которое возвращает несколько вариантов. Если мы введем строку «personell», мы получим список возможных исправлений с оценкой достоверности, потому что эта строка довольно похожа по написанию на несколько разных слов.
Согласно документации, точность исправления орфографии в TextBlob составляет около 70 %.
автозамена
Последний пакет, который мы рассмотрим, называется autocorrect. Опять же, мы можем установить этот пакет с помощью pip:
После установки мы импортируем класс Speller из автозамены. Затем мы создадим объект, использующий английский язык (lang = ‘en’). Мы будем использовать этот объект для исправления правописания.
Далее мы можем ввести предложение в наш объект, и он попытается исправить любые опечатки.
Несколько предостережений
Важно помнить, что программная проверка орфографии не идеальна. Тем не менее, в Python есть несколько готовых опций, как описано выше, но вы также можете создать свои собственные, используя нечеткое сопоставление. Кроме того, слова вне контекста затрудняют определение правильного написания, если строка с ошибкой похожа на несколько слов. Например, возьмем строку «liberry». Это известная опечатка в слове library. Однако это также всего одна буква от liberty.
Если мы используем один из вышеперечисленных пакетов, мы получим слово «liberty», что вполне логично, поскольку строка очень близка по написанию, но контекст может помочь определить, какое слово имеет наибольший смысл. Для создания контекстной проверки орфографии на Python вам могут понадобиться рекуррентные нейронные сети или марковские модели.
Читайте также: