Why rule-based spell checking breaks on live text
A dictionary with a set of rules works well on proofread text and predictably falls apart on live text.
Spell checking in texts with brands, abbreviations, and transliteration produces dictionary false positives: an oblique-case form is not found in the lexicon, and the system marks a correct word as an error. The editor either suppresses such underlines blindly or goes through each one manually.
Errors in declensions are a separate class. A rule requires agreement of gender, number, and case, and exceptions to it are written manually for each new case.
As soon as a compound name or a fused phrase enters the text, the rule goes silent — and then either a real typo is missed or a correct phrase is marked.
Markup of live text adds a second layer of noise. A word split by a line break or pressed against a service character falls into two fragments, and the check sees two “errors” instead of one word.
Links, mentions, and emoji from emails and chats are processed as ordinary vocabulary, although they are not vocabulary.
Text from chats and emails makes the picture worse: no capitalization, no punctuation, languages and abbreviations mixed in one line.
The dictionary records every unfamiliar sequence as an error, the share of correct marks falls, and such a feed can no longer be sorted out manually.
At scale, this results in text quality in the editorial team ceasing to depend on the tool and again resting on people: the check is turned off or ignored. A language model removes this layer — we will look at exactly how.
What a language-model-based system provides: effect in metrics
Rule-based dictionary checking catches typos but misses what is visible only in context: case disagreement, an extra word, incorrect syntactic government. The share of missed errors in such classes remains high, and they reach the editor already in layout or in a sent email.
The language model reads the sentence as a whole, not individual words, so it finds an agreement error and a merge of two phrases where the dictionary is silent.
We put domain terms and names into separate lists, and verify disputed usages against a corpus — for example, the National Corpus of the Russian Language, so that a rule relies on real usage rather than the author’s taste.
The downside is false marks: abbreviations, terminology, and professional slang go into errors if the model is not limited by an exception dictionary and a confidence threshold.
Triggers below the threshold do not go into automatic correction but are collected in a separate list, so the editor’s share of false marks falls — only ambiguous places have to be checked, not the entire text.
Manual proofreading time is reduced due to volume, not reading speed: the editor receives text with unambiguous edits applied and a short list of disputed cases.
A unified text standard rests on configuration — tone, the letter yo, quotation marks, dashes, number formatting — and works the same for the website, emails, and documents.
Disputed spelling cases do not dissolve: they are collected in a report with frequency by type. From it, one can see where a rule is outdated or the dictionary is incomplete, and updating takes minutes — without changing code.
Approaches to spell checking: dictionaries, rules, and a model
Three parsing methods solve different tasks, and none of them carries the check on its own. Dictionary parsing confidently catches typos, fused spellings, and extra spaces, but gives way before agreement within a sentence: the word is spelled correctly, but the form is not.
Punctuation rules give a predictable result on template constructions, but each exception has to be described separately, and the amount of manual support grows along with the language.
In parsing, the language model sees context and meaning, so it handles cases, tenses, and word order where rules are powerless.
The downside is “taste-based” edits and confident suggestions where there was no error, so the model needs a confidence threshold and labeling of edit types.
In practice, hybrid text parsing is what operates in production: the dictionary and rules cut off mechanical errors, and the model deals with complex cases.
| Option | When it fits | Limitations |
|---|---|---|
| In-house terminology and dictionary parsing | Product names, SKUs, abbreviations, names, industry terms | Does not see context: a correct word in the wrong form remains unnoticed |
| Punctuation and agreement rules | Template texts: instructions, regulations, notifications, email templates | Each exception is a separate rule; the amount of support grows and so does the risk of conflicts between rules |
| Language model in parsing | Live texts: articles, correspondence, product descriptions, inquiries | False positives, a tendency to rewrite the phrase, need for threshold and suggestion-set control |
| Hybrid text parsing | Mixed flow: documents, requests, reviews, user input | Harder to configure: needs a layer that reconciles results and priority between edit sources |
The mode is chosen for the type of text, not for the fashionable name of the method: for a flow of inquiries, the hybrid gives the best result; for an internal regulation, rules and a dictionary are enough.
In-house terminology is connected in any mode — otherwise SKUs and abbreviations go into the report as errors. We will show on your texts where the boundary between modes lies and which set of checks will cover the main share of edits.
Step-by-step implementation: from corpus audit to system handover
Spell checking breaks not on the model, but on the data. Until a real text corpus is analyzed, it is unclear what to consider an error and what level of suggestions employees are willing to tolerate: requests and emails have some defects, regulations and contracts have others.
Therefore, we start work with a corpus audit and fix measurable acceptance criteria before the first line of code.
- Text corpus audit. We collect an anonymized slice of documents by channel and type: emails, requests, instructions, contracts. We calculate the share of typos, repetitions, broken agreement, and language mixing — we get a map of what actually needs fixing and what can be left alone.
- Parsing scheme. We agree on which class of defects is considered an error and with what priority: spelling, punctuation, cases and agreement, terminology, style. We assign each class a weight and trigger threshold so that the system does not underline everything indiscriminately and does not lose trust from the first days.
- Terminology setup. We form a dictionary of industry and product terms, exceptions, and declension rules; we separately process abbreviations and names from internal documents. After that, domain vocabulary stops being highlighted as an error.
- Reference set preparation. We label the corpus manually and split it into training and held-out parts so that evaluation runs on texts the system has not seen.
- Check on the held-out set. We look at precision and recall for each error class and the share of false positives separately by document type. Classes where there are too many suggestions are sent for further tuning, not to acceptance.
- Quality acceptance. We compare the result with the thresholds agreed at the start: a report by class, by channel, and by part of speech, plus analysis of remaining discrepancies. Classes that fail the threshold are improved before handover.
- Handover and support. We deliver configurations, dictionaries, the reference set, and an update procedure: how to add terms, how to re-measure quality, and what to do when document templates change.
Dictionaries and rules live longer than the model, so we build a re-measurement after each terminology update into the handover — quality remains at the acceptance level instead of degrading six months later.
Delivery package: configurations, labeling, update procedures
We deliver not a “black box” but a system whose rules the customer edits themselves.
The parsing configuration describes what is considered a word and a phrase, at what confidence threshold autocorrection triggers, and which constructions are excluded from spell checking — SKUs, codes, Latin script inside Russian phrases.
Separately comes a terminology dictionary: industry names, abbreviations, and trademarks that the service should not consider typos. Labeling of examples records disputed cases with the expected resolution, and a run over this corpus before each update shows exactly what broke. Without such a set, updating the dictionary turns into blind checking.
- Parsing configuration — text segmentation rules, confidence thresholds, list of exceptions.
- Terminology dictionary — domain names and abbreviations marked “do not correct.”
- Example labeling — a corpus of disputed cases with a reference answer and explanation.
- Regression check set — a corpus run after a model or rules change.
- System documentation — request processing scheme, failure points, procedure for rolling back to the previous version.
- Dictionary update procedure — who enters new terms, within what timeframe, and with whose approval.
- Change log — what changed in the rules and why, with the results of the latest run.
Implementation example: share of missed errors before and after
What it was at the start and what the measurements showed
An editorial team of six proofread about 40,000 characters per shift, and the share of missed errors remained at 12–14% — mainly things the eye stops noticing in the third hour of editing.
We placed a language model alongside the rule-based engine LanguageTool: the rules cover mechanics, the model covers the context that the rules lack.
Measurements were taken on a held-out set of 5,000 fragments labeled manually by editors and not involved in tuning.
The share of missed errors fell to 1.8%, and suggestion precision rose from 61% to 89%: the editor stopped sorting out false positives and returned to the meaning of the text.
Which class of errors went away and what remained labor-intensive
The main gain was agreement in long constructions, cases in enumerations, punctuation with introductory and detached phrases, and consistency of terms within an issue.
Mechanical typos were caught by the rules before as well, while contextual errors, where spelling depends on the meaning of the neighboring sentence, reached layout before implementation.
The most labor-intensive turned out to be authorial punctuation and style. We did not hand them over to the model for autocorrection: disputed places are marked as “requires attention” and go to the editor — otherwise the system starts leveling the author’s voice to the average.
After the settings handover, support continues: fresh editor edits every two weeks become control examples, and metrics are recalculated on the same set — otherwise quality slides when the subject matter changes.
What to do if you already have your own dictionary and rules deployed?
Your own dictionary and set of rules are accumulated expertise: industry terminology, service names, exceptions that any general checking service marks as an error. They cannot be discarded; precision rests on them.
Therefore, the language model is integrated not instead of the dictionary, but alongside it — as an additional layer over text parsing.
The scheme is this: the sentence undergoes normalization and morphological parsing, and only then do the checks come into play. The deterministic layers trigger first — the dictionary, word formation and agreement rules, and stop lists of prohibited formulations. They give a repeatable result and do not depend on how the model behaves on this particular text.
The model is connected on the remainder — where rules are insufficient: semantic errors, unsuccessful word order, inconsistency in terms within a paragraph.
The order of applying rules is fundamental here: if the model is run first, it will start “improving” already correct text, and the share of false positives grows severalfold.
The deterministic layer before the model also narrows the amount of text sent for parsing — a long document is checked in the same seconds.
Dictionary migration is a separate step: entries are converted into the format of the new layer while preserving priorities, strictness levels, and exceptions.
Rules that described non-standard cases remain in force and receive priority above the model output; if they were stored in LanguageTool format, the converter transfers them as is.
The accumulated work does not disappear — the trigger log shows which layer found the error, and this allows targeted further training of both layers without rewriting the system from scratch.
Technical concerns: false positives, languages, load
Questions before the start rarely concern the interface — they are about behavior at the edges: what the check will show on internal jargon, how a document with mixed languages will perform, and whether it will withstand the peak at the end of the reporting period.
Below are the concerns that most often come up in technical sessions, and how each is closed in the architecture rather than with promises.
Will the check “correct” our terms and system names?
False positives come from two sources: narrow vocabulary and proper names. Before launch, we assemble a domain dictionary from your own texts and exception rules — internal terms stop being highlighted as errors. We fix the share of disputed triggers on a labeled set before including it in the production loop.
Documents in multiple languages — how are they processed?
The language is determined by fragment, not by the whole file: a paragraph in another language is checked by its own model and its own set of rules.
Mixed strings where a Latin-script term stands inside a Russian sentence go into a separate branch — otherwise every such word produces an error.
What happens under peak load?
Long documents are processed in batches, short ones are prioritized so the interface responds immediately. When volume grows tenfold, workers are added; the logic is not rewritten. We agree on limits for concurrent requests in advance with your team.
Can the system be further trained on our texts?
Yes: the corpus is used as a source of dictionary and tuning examples, not as public data. Style rules are set separately — unified terminology, formatting of abbreviations, and unacceptable formulations in regulations.
Who is responsible for quality after launch?
Before the start, we agree on metrics: share of missed errors, share of false positives, response time per document. Work is accepted by them and degradation after updates is tracked. We analyze disputed cases on a control set, not on feelings.
Where to start: data, volumes, and accuracy requirements
Evaluation begins not with model selection, but with data for evaluation and accuracy requirements.
If the processing volume and acceptance metric are fixed before the start, the dispute “does it work or not” at delivery does not arise: both sides have the same set of examples and the same threshold.
What to send so that we come back with a work plan — point by point:
- Example corpus: several hundred fragments of real texts with errors already marked. Labeling matters more than volume — a labeled set gives more than a tenfold larger unlabeled archive.
- Accuracy requirements: separately the share of found errors and separately the share of false positives. “Almost one hundred percent accuracy” without a breakdown cannot be verified: systems with the same final number behave differently on live text.
- Processing volume: characters per day, peak flow, maximum length of one document, whether real-time response is needed or batch checking is suitable.
- Dictionary scope: professional terminology, names, abbreviations, mixed Russian-English text — everything the system should not mark as an error. This becomes a list of exceptions.
- Data restrictions: where text is allowed to be processed, who has access, how long a copy is stored.
- Edit return points: editor, document, internal service — the format of the system response depends on this.
- Edit mode: suggestion to a human or automatic replacement. Autocorrection requires a noticeably lower share of false positives.
The procedure for discussing the task is simple: you send text samples and how errors are currently processed — then we work from your data, not from demo examples.
In response, we return a work plan: stages, labeling composition, acceptance metric, and control points at each stage. The metric changes only by your decision and with a recalculation of timelines — otherwise acceptance turns into negotiations.
