Чому перевірка орфографії на правилах ламається на живому тексті
Словник із набором правил добре працює на вичитаному тексті й передбачувано розсипається на живому.
Перевірка орфографії в текстах із брендами, абревіатурами та транслітерацією дає хибні спрацювання словника: форма в непрямому відмінку не знаходиться в лексиконі, і система позначає коректне слово як помилку. Редактор або гасить такі підкреслення наосліп, або розбирає кожне вручну.
Помилки у відмінюванні — окремий клас. Правило вимагає узгодження роду, числа й відмінка, а винятки до нього дописують вручну під кожен новий випадок.
Щойно в текст потрапляє складена назва або злитий зворот, правило мовчить — і тоді або пропускається справжня друкарська помилка, або позначається коректна фраза.
Розмітка живого тексту додає другий шар шуму. Слово, розрізане перенесенням рядка або притиснуте до службового символу, розпадається на два фрагменти, і перевірка бачить дві «помилки» замість одного слова. Посилання, згадки та смайли з листів і чатів обробляються як звичайна лексика, хоча лексикою не є.
Текст із чату й листів погіршує картину: немає регістру, немає пунктуації, в одному рядку перемішані мови та скорочення. Словник фіксує кожну незнайому послідовність як помилку, частка коректних позначок падає, а вручну таку стрічку вже не розібрати.
На потоці це обертається тим, що якість тексту в редакції перестає залежати від інструмента й знову тримається на людині: перевірку вимикають або ігнорують. Модель знімає цей шар — розбираємо, як саме.
Що дає система на мовній моделі: ефект у метриках
Словникова перевірка за правилами ловить друкарські помилки, але пропускає те, що видно лише в контексті: неузгодженість відмінка, зайве слово, неправильне керування.
Частка пропущених помилок на таких класах залишається високою, і до редактора вони доходять уже у верстці або у відправленому листі.
Мовна модель читає речення цілком, а не окремі слова, тому помилку в узгодженні й склейку двох зворотів знаходить там, де словник мовчить.
Доменні терміни й назви виносимо в окремі списки, а спірні вживання звіряємо з корпусом — наприклад, із Національним корпусом російської мови, щоб правило спиралося на реальне вживання, а не на смак автора.
Зворотний бік — хибні позначки: абревіатури, термінологія й професійний сленг потрапляють у помилки, якщо не обмежити модель словником винятків і порогом упевненості.
Спрацювання нижче порога не йдуть в автоправку, а складаються в окремий список, тому частка хибних позначок редактора падає — перевіряти доводиться не весь текст, а лише неоднозначні місця.
Час ручної вичитки скорочується за рахунок обсягу, а не швидкості читання: редактор отримує текст із застосованими однозначними правками й коротким переліком спірних випадків.
Єдиний стандарт тексту тримається на конфігурації — тон, літера ё, лапки, тире, оформлення чисел, — і однаково працює для сайту, листів і документів.
Спірні випадки правопису не розчиняються: вони збираються у звіт із частотою за типами. За ним видно, де правило застаріло або словник неповний, і оновлення займає хвилини — без правки коду.
Підходи до перевірки орфографії: словники, правила й модель
Три способи розбору розв’язують різні задачі, і жоден не витягує перевірку цілком. Словниковий розбір упевнено ловить друкарські помилки, злиті написання й зайві пробіли, але пасує перед узгодженням усередині речення: слово написано правильно, а форма — ні.
Правила пунктуації дають передбачуваний результат на шаблонних конструкціях, зате кожен виняток доводиться описувати окремо, і обсяг ручної підтримки зростає разом із мовою.
Мовна модель у розборі бачить контекст і сенс, тому справляється з відмінками, часами й порядком слів там, де правила безсилі. Зворотний бік — правки «на смак» і впевнені підказки там, де помилки не було, тому моделі потрібен поріг упевненості й розмітка типів правок.
На практиці в експлуатації живе гібридний розбір тексту: словник і правила відсікають механічні помилки, модель розбирається зі складними випадками.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Своя термінологія й словниковий розбір | Назви продуктів, артикули, абревіатури, імена, галузеві терміни | Не бачить контекст: правильне слово в неправильній формі залишається непоміченим |
| Правила пунктуації й узгодження | Шаблонні тексти: інструкції, регламенти, повідомлення, шаблони листів | Кожен виняток — окреме правило, зростає обсяг підтримки й ризик конфліктів між правилами |
| Мовна модель у розборі | Живі тексти: статті, листування, описи товарів, звернення | Хибні спрацювання, схильність переписувати фразу, потрібен контроль порога й набору підказок |
| Гібридний розбір тексту | Змішаний потік: документи, заявки, відгуки, введення користувачів | Складніше в налаштуванні: потрібен шар зведення результатів і пріоритет між джерелами правок |
Режим вибирають під тип тексту, а не під модну назву методу: для потоку звернень гібрид дає найкращий результат, для внутрішнього регламенту достатньо правил і словника. Своя термінологія підключається в будь-якому режимі — інакше артикули й абревіатури йдуть у звіт як помилки.
Покажемо на ваших текстах, де проходить межа між режимами й який набір перевірок закриє основну частку правок.
Впровадження за кроками: від аудиту корпусу до передачі системи
Перевірка орфографії ламається не на моделі, а на даних. Поки не розібрано реальний корпус текстів, незрозуміло, що вважати помилкою і який рівень підказок співробітники готові терпіти: у заявках і листах одні дефекти, у регламентах і договорах — інші.
Тому роботу починаємо з аудиту корпусу й фіксуємо вимірювані критерії приймання до першого рядка коду.
- Аудит корпусу текстів. Збираємо знеособлений зріз документів за каналами й типами: листи, заявки, інструкції, договори. Рахуємо частку друкарських помилок, повторів, розірваних узгоджень і змішування мов — отримуємо карту того, що реально потрібно виправляти, а що можна не чіпати.
- Схема розбору. Домовляємося, який клас дефектів вважаємо помилкою і з яким пріоритетом: орфографія, пунктуація, відмінки й узгодження, термінологія, стиль. Кожному класу задаємо вагу й поріг спрацювання, щоб система не підкреслювала все підряд і не втрачала довіру з перших днів.
- Налаштування під термінологію. Формуємо словник галузевих і продуктових термінів, винятків і правил відмінювання, окремо розбираємо абревіатури й назви з внутрішніх документів. Після цього профільна лексика перестає підсвічуватися як помилка.
- Підготовка еталонного набору. Розмічаємо корпус вручну й ділимо його на навчальну та відкладену частини, щоб оцінювання йшло на текстах, яких система не бачила.
- Перевірка на відкладеній вибірці. Дивимося точність і повноту за кожним класом помилок і частку хибних спрацювань окремо за типами документів. Класи, де підказок занадто багато, відправляються на доналаштування, а не на приймання.
- Приймання якості. Звіряємо результат із порогами, узгодженими на старті: звіт за класами, за каналами й за частинами мови, плюс розбір залишкових розходжень. Класи, що не пройшли поріг, доопрацьовуються до передачі.
- Передача й супровід. Віддаємо конфігурації, словники, еталонний набір і регламент оновлення: як додавати терміни, як переміряти якість і що робити при зміні шаблонів документів.
Словники й правила живуть довше за модель, тому в передачу закладаємо повторний замір після кожного оновлення термінології — якість залишається на рівні приймання, а не деградує через півроку.
Склад постачання: конфігурації, розмітка, регламенти оновлення
Ми передаємо не «чорну скриньку», а систему, правила якої замовник править сам.
Конфігурація розбору описує, що вважається словом і фразою, за якого порога впевненості спрацьовує автозаміна і які конструкції виключено з перевірки орфографії — артикули, коди, латиниця всередині російських фраз.
Окремо йде словник термінів: галузеві назви, абревіатури й торгові марки, які сервіс не повинен вважати друкарськими помилками. Розмітка прикладів фіксує спірні випадки з очікуваним рішенням, а прогін цим корпусом перед кожним оновленням показує, що саме зламалося. Без такого набору оновлення словника перетворюється на перевірку наосліп.
- Конфігурація розбору — правила сегментації тексту, пороги впевненості, список винятків.
- Словник термінів — доменні назви й абревіатури з позначкою «не виправляти».
- Розмітка прикладів — корпус спірних випадків з еталонною відповіддю й поясненням.
- Набір перевірок для регресії — прогін корпусу після зміни моделі або правил.
- Документація системи — схема обробки запиту, точки відмови, порядок повернення до попередньої версії.
- Регламент оновлення словників — хто вносить нові терміни, у який строк і за чиїм погодженням.
- Журнал змін — що і навіщо змінювалося в правилах, з результатами останнього прогону.
Приклад впровадження: частка пропущених помилок до і після
Що було на старті й що зняли на замірах
Редакція з шести осіб вичитувала близько 40 тисяч знаків за зміну, і частка пропущених помилок трималася на рівні 12–14% — переважно те, що око перестає помічати на третій годині правки.
Ми поставили мовну модель поруч із рушієм на правилах LanguageTool: правила закривають механіку, модель — контекст, якого правилам не вистачає.
Заміри знімали на відкладеній вибірці з 5 000 фрагментів, розмічених редакторами вручну й не задіяних у налаштуванні. Частка пропущених помилок упала до 1,8%, а точність підказок зросла з 61% до 89%: редактор перестав розбирати хибні спрацювання й повернувся до сенсу тексту.
Який клас помилок пішов і що залишилося трудомістким
Основний виграш — узгодження в довгих конструкціях, відмінки в переліках, пунктуація при вставних і відокремлених зворотах, однаковість термінів усередині номера.
Механічні друкарські помилки правила ловили й раніше, а контекстні помилки, де написання залежить від сенсу сусіднього речення, до впровадження доходили до верстки.
Найтрудомісткішою виявилася авторська пунктуація й стилістика. Їх ми не віддали моделі на автоправку: спірні місця позначаються як «потребує уваги» й ідуть редактору — інакше система починає вирівнювати авторський голос під середній.
Після передачі налаштувань супровід продовжується: свіжі правки редакторів раз на два тижні стають контрольними прикладами, метрики перераховуються на тому самому наборі — інакше якість сповзає при зміні тематики.
Що робити, якщо вже розгорнуто свій словник і правила?
Свій словник і набір правил — це накопичена експертиза: термінологія галузі, назви послуг, винятки, які будь-який загальний перевіряльний сервіс позначає як помилку. Викидати їх не можна, на них тримається точність.
Тому мовна модель вбудовується не замість словника, а поруч — як додатковий шар над розбором тексту.
Схема така: речення проходить нормалізацію й морфологічний розбір, і тільки потім у справу вступають перевірки. Першими спрацьовують детерміновані шари — словник, правила словотвору й узгодження, стоп-списки заборонених формулювань.
Вони дають повторюваний результат і не залежать від того, як модель поведе себе на цьому конкретному тексті.
Модель підключається на залишку — там, де правил не вистачає: смислові помилки, невдалий порядок слів, різнобій у термінах усередині абзацу.
Порядок застосування правил тут принциповий: якщо пустити модель першою, вона почне «покращувати» вже коректний текст, і частка хибних спрацювань зростає в рази.
Детермінований шар перед моделлю заразом звужує обсяг тексту, який іде на розбір, — довгий документ перевіряється за ті самі секунди.
Перенесення словника — окремий крок: записи конвертуються у формат нового шару зі збереженням пріоритетів, рівнів строгості й винятків.
Правила, що описували нестандартні випадки, залишаються чинними й отримують пріоритет вище за висновок моделі; якщо вони зберігалися у форматі LanguageTool, конвертер переносить їх як є.
Напрацювання не зникають — у журналі спрацювань видно, який шар знайшов помилку, і це дає змогу точково донавчати обидва шари, не переписуючи систему з нуля.
Технічні сумніви: хибні спрацювання, мови, навантаження
Питання перед стартом рідко стосуються інтерфейсу — вони про поведінку на межах: що покаже перевірка на внутрішньому жаргоні, як відпрацює документ зі змішаними мовами, чи витримає пік у кінці звітного періоду.
Нижче — сумніви, які найчастіше спливають на технічних сесіях, і те, як кожне закривається в архітектурі, а не обіцянками.
Перевірка буде «виправляти» наші терміни й назви систем?
Хибні спрацювання йдуть із двох джерел: вузька лексика й власні назви. Перед запуском збираємо словник домену з ваших же текстів і правила винятків — внутрішні терміни перестають підсвічуватися як помилки. Частку спірних спрацювань фіксуємо на розміченій вибірці до включення в робочий контур.
Документи кількома мовами — як обробляються?
Мова визначається за фрагментом, а не за всім файлом: абзац іншою мовою перевіряється своєю моделлю і своїм набором правил. Змішані рядки, де термін латиницею стоїть усередині російського речення, йдуть в окрему гілку — інакше кожне таке слово дає помилку.
Що відбувається при піковому навантаженні?
Довгі документи йдуть пакетами, короткі — в пріоритеті, щоб інтерфейс відповідав одразу. При десятикратному зростанні обсягу додаються обробники, логіка не переписується. Межі за одночасними запитами погоджуємо заздалегідь із вашою командою.
Чи можна донавчати систему на наших текстах?
Так: корпус використовується як джерело словника й прикладів налаштування, а не як публічні дані. Окремо задаються стильові правила — єдина термінологія, оформлення скорочень, неприпустимі формулювання в регламентах.
Хто відповідає за якість після запуску?
До старту узгоджуємо метрики: частка пропущених помилок, частка хибних спрацювань, час відповіді на документ. За ними приймається робота й відстежується деградація після оновлень. Спірні випадки розбираємо на контрольній вибірці, а не на відчуттях.
З чого почати: дані, обсяги й вимоги до точності
Оцінка починається не з вибору моделі, а з даних для оцінки й вимог до точності. Якщо зафіксувати обсяг обробки й метрику приймання до старту, спір «працює чи ні» на здачі не виникає: в обох сторін той самий набір прикладів і той самий поріг.
Що надіслати, щоб ми повернулися з планом робіт, — за пунктами:
- Корпус прикладів: кілька сотень фрагментів реальних текстів із уже відзначеними помилками. Розмітка важливіша за обсяг — розмічена вибірка дає більше, ніж удесятеро більший нерозмічений архів.
- Вимоги до точності: окремо частка знайдених помилок і окремо частка хибних спрацювань. «Точність майже сто відсотків» без розбивки не перевіряється: системи з однаковою підсумковою цифрою поводяться на живому тексті по-різному.
- Обсяг обробки: знаків на добу, піковий потік, максимальна довжина одного документа, чи потрібен відгук у реальному часі або підходить пакетна перевірка.
- Словниковий контур: професійна термінологія, імена, абревіатури, змішаний російсько-англійський текст — усе, що система не повинна позначати як помилку. Це перетворюється на список винятків.
- Обмеження на дані: де дозволено обробляти текст, хто має доступ, скільки зберігається копія.
- Точки повернення правок: редактор, документ, внутрішній сервіс — від цього залежить формат відповіді системи.
- Режим правок: підказка людині або автоматична заміна. Автозаміна вимагає помітно нижчої частки хибних спрацювань.
Порядок обговорення задачі простий: надсилаєте зразки текстів і те, як зараз обробляються помилки, — далі працюємо за вашими даними, а не за демонстраційними прикладами. У відповідь повертаємо план робіт: етапи, склад розмітки, метрику приймання й точки контролю на кожному етапі.
Метрика змінюється тільки за вашим рішенням і з перерахунком строків — інакше приймання перетворюється на переговори.
