Разработка системы проверки грамматики и орфографии с LLM

Почему проверка орфографии на правилах ломается на живом тексте

Словарь с набором правил хорошо работает на вычитанном тексте и предсказуемо рассыпается на живом. Проверка орфографии в текстах с брендами, аббревиатурами и транслитерацией даёт ложные срабатывания словаря: форма в косвенном падеже не находится в лексиконе, и система помечает корректное слово как ошибку. Редактор либо гасит такие подчёркивания вслепую, либо разбирает каждое руками.

Ошибки на склонениях — отдельный класс. Правило требует согласования рода, числа и падежа, а исключения к нему дописывают вручную под каждый новый случай. Как только в текст попадает составное название или слитный оборот, правило молчит — и тогда либо пропускается настоящая опечатка, либо помечается корректная фраза.

Разметка живого текста добавляет второй слой шума. Слово, разрезанное переносом строки или прижатое к служебному символу, распадается на два фрагмента, и проверка видит две «ошибки» вместо одного слова. Ссылки, упоминания и смайлы из писем и чатов обрабатываются как обычная лексика, хотя лексикой не являются.

Текст из чата и писем усугубляет картину: нет регистра, нет пунктуации, в одной строке перемешаны языки и сокращения. Словарь фиксирует каждую незнакомую последовательность как ошибку, доля корректных пометок падает, а вручную такую ленту уже не разобрать.

На потоке это оборачивается тем, что качество текста в редакции перестаёт зависеть от инструмента и снова держится на человеке: проверку отключают или игнорируют. Модель снимает этот слой — разбираем, как именно.

Что даёт система на языковой модели: эффект в метриках

Словарная проверка по правилам ловит опечатки, но пропускает то, что видно только в контексте: рассогласование падежа, лишнее слово, неверное управление. Доля пропущенных ошибок на таких классах остаётся высокой, и до редактора они доходят уже в вёрстке или в отправленном письме.

Языковая модель читает предложение целиком, а не отдельные слова, поэтому ошибку в согласовании и склейку двух оборотов находит там, где словарь молчит. Доменные термины и названия выносим в отдельные списки, а спорные употребления сверяем с корпусом — например, с Национальным корпусом русского языка, чтобы правило опиралось на реальное употребление, а не на вкус автора.

Обратная сторона — ложные пометки: аббревиатуры, терминология и профессиональный сленг уходят в ошибки, если не ограничить модель словарём исключений и порогом уверенности. Срабатывания ниже порога не идут в автоправку, а складываются в отдельный список, поэтому доля ложных пометок редактора падает — проверять приходится не весь текст, а только неоднозначные места.

Время ручной вычитки сокращается за счёт объёма, а не скорости чтения: редактор получает текст с применёнными однозначными правками и коротким перечнем спорных случаев. Единый стандарт текста держится на конфигурации — тон, буква ё, кавычки, тире, оформление чисел, — и одинаково работает для сайта, писем и документов.

Спорные случаи правописания не растворяются: они собираются в отчёт с частотой по типам. По нему видно, где правило устарело или словарь неполон, и обновление занимает минуты — без правки кода.

Подходы к проверке орфографии: словари, правила и модель

Три способа разбора решают разные задачи, и ни один не тянет проверку целиком. Словарный разбор уверенно ловит опечатки, слитные написания и лишние пробелы, но пасует перед согласованием внутри предложения: слово написано верно, а форма — нет. Правила пунктуации дают предсказуемый результат на шаблонных конструкциях, зато каждое исключение приходится описывать отдельно, и объём ручной поддержки растёт вместе с языком.

Языковая модель в разборе видит контекст и смысл, поэтому справляется с падежами, временами и порядком слов там, где правила бессильны. Обратная сторона — правки «по вкусу» и уверенные подсказки там, где ошибки не было, поэтому модели нужен порог уверенности и разметка типов правок. На практике в эксплуатации живёт гибридный разбор текста: словарь и правила отсекают механические ошибки, модель разбирается со сложными случаями.

Режим выбирают под тип текста, а не под модное название метода: для потока обращений гибрид даёт лучший результат, для внутреннего регламента хватает правил и словаря. Своя терминология подключается в любом режиме — иначе артикулы и аббревиатуры уходят в отчёт как ошибки. Покажем на ваших текстах, где проходит граница между режимами и какой набор проверок закроет основную долю правок.

Внедрение по шагам: от аудита корпуса до передачи системы

Проверка орфографии ломается не на модели, а на данных. Пока не разобран реальный корпус текстов, непонятно, что считать ошибкой и какой уровень подсказок сотрудники готовы терпеть: в заявках и письмах одни дефекты, в регламентах и договорах — другие. Поэтому работу начинаем с аудита корпуса и фиксируем измеримые критерии приёмки до первой строки кода.

1. Аудит корпуса текстов. Собираем обезличенный срез документов по каналам и типам: письма, заявки, инструкции, договоры. Считаем долю опечаток, повторов, разорванных согласований и смешения языков — получаем карту того, что реально нужно чинить, а что можно не трогать.
2. Схема разбора. Договариваемся, какой класс дефектов считаем ошибкой и с каким приоритетом: орфография, пунктуация, падежи и согласование, терминология, стиль. Каждому классу задаём вес и порог срабатывания, чтобы система не подчёркивала всё подряд и не теряла доверие с первых дней.
3. Настройка под терминологию. Формируем словарь отраслевых и продуктовых терминов, исключений и правил склонения, отдельно разбираем аббревиатуры и названия из внутренних документов. После этого профильная лексика перестаёт подсвечиваться как ошибка.
4. Подготовка эталонного набора. Размечаем корпус вручную и делим его на обучающую и отложенную части, чтобы оценка шла на текстах, которых система не видела.
5. Проверка на отложенной выборке. Смотрим точность и полноту по каждому классу ошибок и долю ложных срабатываний отдельно по типам документов. Классы, где подсказок слишком много, отправляются на донастройку, а не в приёмку.
6. Приёмка качества. Сверяем результат с порогами, согласованными на старте: отчёт по классам, по каналам и по частям речи, плюс разбор оставшихся расхождений. Не прошедшие порог классы дорабатываются до передачи.
7. Передача и сопровождение. Отдаём конфигурации, словари, эталонный набор и регламент обновления: как добавлять термины, как перезамерять качество и что делать при смене шаблонов документов.

Словари и правила живут дольше модели, поэтому в передачу закладываем повторный замер после каждого обновления терминологии — качество остаётся на уровне приёмки, а не деградирует через полгода.

Состав поставки: конфигурации, разметка, регламенты обновления

Мы передаём не «чёрный ящик», а систему, правила которой заказчик правит сам. Конфигурация разбора описывает, что считается словом и фразой, при каком пороге уверенности срабатывает автозамена и какие конструкции исключены из проверки орфографии — артикулы, коды, латиница внутри русских фраз.

Отдельно идёт словарь терминов: отраслевые названия, аббревиатуры и торговые марки, которые сервис не должен считать опечатками. Разметка примеров фиксирует спорные случаи с ожидаемым решением, а прогон по этому корпусу перед каждым обновлением показывает, что именно сломалось. Без такого набора обновление словаря превращается в проверку вслепую.

• Конфигурация разбора — правила сегментации текста, пороги уверенности, список исключений.
• Словарь терминов — доменные названия и аббревиатуры с пометкой «не исправлять».
• Разметка примеров — корпус спорных случаев с эталонным ответом и пояснением.
• Набор проверок для регрессии — прогон корпуса после смены модели или правил.
• Документация системы — схема обработки запроса, точки отказа, порядок возврата к предыдущей версии.
• Регламент обновления словарей — кто вносит новые термины, в какой срок и по чьему согласованию.
• Журнал изменений — что и зачем менялось в правилах, с результатами последнего прогона.

Пример внедрения: доля пропущенных ошибок до и после

Что было на старте и что сняли на замерах

Редакция из шести человек вычитывала около 40 тысяч знаков за смену, и доля пропущенных ошибок держалась на уровне 12–14% — в основном то, что глаз перестаёт замечать на третьем часу правки. Мы поставили языковую модель рядом с правиловым движком LanguageTool: правила закрывают механику, модель — контекст, которого правилам не хватает.

Замеры снимали на отложенной выборке из 5 000 фрагментов, размеченных редакторами вручную и не участвовавших в настройке. Доля пропущенных ошибок упала до 1,8%, а точность подсказок выросла с 61% до 89%: редактор перестал разбирать ложные срабатывания и вернулся к смыслу текста.

Какой класс ошибок ушёл и что осталось трудоёмким

Основной выигрыш — согласование в длинных конструкциях, падежи в перечислениях, пунктуация при вводных и обособленных оборотах, единообразие терминов внутри номера. Механические опечатки правила ловили и раньше, а контекстные ошибки, где написание зависит от смысла соседнего предложения, до внедрения доходили до вёрстки.

Самым трудоёмким оказалась авторская пунктуация и стилистика. Их мы не отдали модели на автоправку: спорные места помечаются как «требует внимания» и уходят редактору — иначе система начинает выравнивать авторский голос под средний.

После передачи настроек сопровождение продолжается: свежие правки редакторов раз в две недели становятся контрольными примерами, метрики пересчитываются на том же наборе — иначе качество сползает при смене тематики.

Что делать, если уже развёрнут свой словарь и правила?

Свой словарь и набор правил — это накопленная экспертиза: терминология отрасли, названия услуг, исключения, которые любой общий проверяющий сервис помечает как ошибку. Выбрасывать их нельзя, на них держится точность. Поэтому языковая модель встраивается не вместо словаря, а рядом — как дополнительный слой над разбором текста.

Схема такая: предложение проходит нормализацию и морфологический разбор, и только потом в дело вступают проверки. Первыми срабатывают детерминированные слои — словарь, правила словообразования и согласования, стоп-листы запрещённых формулировок. Они дают повторяемый результат и не зависят от того, как модель поведёт себя на этом конкретном тексте.

Модель подключается на остатке — там, где правил не хватает: смысловые ошибки, неудачный порядок слов, разнобой в терминах внутри абзаца. Порядок применения правил здесь принципиален: если пустить модель первой, она начнёт «улучшать» уже корректный текст, и доля ложных срабатываний вырастает в разы. Детерминированный слой перед моделью заодно сужает объём текста, который уходит на разбор, — длинный документ проверяется за те же секунды.

Перенос словаря — отдельный шаг: записи конвертируются в формат нового слоя с сохранением приоритетов, уровней строгости и исключений. Правила, описывавшие нестандартные случаи, остаются в силе и получают приоритет выше вывода модели; если они хранились в формате LanguageTool, конвертер переносит их как есть. Наработки не пропадают — в журнале срабатываний видно, какой слой нашёл ошибку, и это позволяет точечно дообучать оба слоя, не переписывая систему с нуля.

Технические сомнения: ложные срабатывания, языки, нагрузка

Вопросы перед стартом редко касаются интерфейса — они про поведение на границах: что покажет проверка на внутреннем жаргоне, как отработает документ со смешанными языками, выдержит ли пик в конце отчётного периода.

Ниже — сомнения, которые чаще всего всплывают на технических сессиях, и то, как каждое закрывается в архитектуре, а не обещаниями.

Документы на нескольких языках — как обрабатываются?

Язык определяется по фрагменту, а не по всему файлу: абзац на другом языке проверяется своей моделью и своим набором правил. Смешанные строки, где термин латиницей стоит внутри русского предложения, уходят в отдельную ветку — иначе каждое такое слово даёт ошибку.

Что происходит при пиковой нагрузке?

Длинные документы идут пакетами, короткие — в приоритете, чтобы интерфейс отвечал сразу. При десятикратном росте объёма добавляются обработчики, логика не переписывается. Пределы по одновременным запросам согласуем заранее с вашей командой.

Можно ли дообучить систему на наших текстах?

Да: корпус используется как источник словаря и примеров настройки, а не как публичные данные. Отдельно задаются стилевые правила — единая терминология, оформление сокращений, недопустимые формулировки в регламентах.

Кто отвечает за качество после запуска?

До старта согласуем метрики: доля пропущенных ошибок, доля ложных срабатываний, время ответа на документ. По ним принимается работа и отслеживается деградация после обновлений. Спорные случаи разбираем на контрольной выборке, а не на ощущениях.

С чего начать: данные, объёмы и требования к точности

Оценка начинается не с выбора модели, а с данных для оценки и требований к точности. Если зафиксировать объём обработки и метрику приёмки до старта, спор «работает или нет» на сдаче не возникает: у обеих сторон один и тот же набор примеров и один и тот же порог.

Что прислать, чтобы мы вернулись с планом работ, — по пунктам:

• Корпус примеров: несколько сотен фрагментов реальных текстов с уже отмеченными ошибками. Разметка важнее объёма — размеченная выборка даёт больше, чем вдесятеро больший неразмеченный архив.
• Требования к точности: отдельно доля найденных ошибок и отдельно доля ложных срабатываний. «Точность почти сто процентов» без разбивки не проверяется: системы с одинаковой итоговой цифрой ведут себя на живом тексте по-разному.
• Объём обработки: знаков в сутки, пиковый поток, максимальная длина одного документа, нужен ли отклик в реальном времени или подходит пакетная проверка.
• Словарный контур: профессиональная терминология, имена, аббревиатуры, смешанный русско-английский текст — всё, что система не должна помечать как ошибку. Это превращается в список исключений.
• Ограничения на данные: где разрешено обрабатывать текст, кто имеет доступ, сколько хранится копия.
• Точки возврата правок: редактор, документ, внутренний сервис — от этого зависит формат ответа системы.
• Режим правок: подсказка человеку или автоматическая замена. Автозамена требует заметно более низкой доли ложных срабатываний.

Порядок обсуждения задачи простой: присылаете образцы текстов и то, как сейчас обрабатываются ошибки, — дальше работаем по вашим данным, а не по демонстрационным примерам. В ответ возвращаем план работ: этапы, состав разметки, метрику приёмки и точки контроля на каждом этапе. Метрика меняется только по вашему решению и с пересчётом сроков — иначе приёмка превращается в переговоры.