The Bareun spell checker's full pipeline at a glance
Bareun spell checking is not a single model that rewrites a whole sentence.
It is a hybrid pipeline that takes the morphological analysis result, applies several stages of rule-based correction first, and hands only the parts that are hard to solve with rules to an LLM.
This page is an overview showing the order in which a single correction request is processed.
The spell check API is provided by RevisionService as CorrectError (single response) and StreamCorrectError (streaming).
An input sentence first goes through morphological analysis and then passes through the correction pipeline in the order below.
The four error filters of the Bareun corrector
Rather than relying on one method, the Bareun corrector layers four error filters of different kinds to catch errors.
| Filter | What it catches | Method |
|---|---|---|
| ① Segmentation-stage error types | Morphological errors such as conjugation, contraction, and dropped sounds | Identified at the segmentation stage with 14 error types among the 115 segmentation labels |
| ② Phoneme-based dictionary | Spellings that violate the spelling rules | The dictionary is built in NFD (decomposed into initial, medial, and final jamo) and searched at the phoneme level |
| ③ LLM confusable-word correction | Word pairs that are easy to mix up because they sound alike | The LLM picks the right word by looking at the meaning in context |
| ④ Sentence error model | Errors seen from the whole-sentence perspective | Sentence-level checking |
The segmentation errors in ① are identified at the "segmentation stage" of morphological analysis, and eojeols (space-delimited word units) with a segmentation error are then restored to the correct form. For ② through ④, see Initial sound rule and jamo error rules, revise-ai categories, and the "Planned" note below.
How the corrector was designed
The Bareun corrector was designed in this flow: understanding the Hangul spelling and standard language rules → preparing data for each error type → an error detection model → non-standard word handling logic → a grammaticality model → remaining work (foreign-language notation and sentence expression). In other words, it follows the order of first analyzing the language regulations closely and then carrying those rules over into dictionary data and models.
graph TD IN[Input sentence] --> POST[Token post-processing]; POST --> SPACE[Rule-based spacing and joining correction]; SPACE --> MERGE[Block merging]; MERGE --> CHECK[Per-eojeol checks]; CHECK --> FREQ[Frequency-based typo correction]; CHECK --> NONSTD[Non-standard word correction]; CHECK --> CONF[Confusable word correction revise-ai]; FREQ --> FALL[LLM correction of OOV and unanalyzable eojeols]; NONSTD --> FALL; CONF --> FALL; FALL --> LSPACE[LLM disambiguation of ambiguous spacing]; LSPACE --> OUT[Correction result + rationale];
Stage 1: Token post-processing
Arranges the array of eojeols and morphemes produced by the morphological analyzer into a form suited to correction.
At this stage, eojeols that need further review are marked, such as out-of-vocabulary words (OOV), unanalyzable ones (NA), and unclassified ones (UNK).
Stage 2: Rule-based spacing and joining correction
Fixes eojeol boundaries according to rules.
Clear cases such as 아름다운강산 → 아름다운 강산 are settled at this stage.
Ambiguous cases that are hard to decide by rules alone, such as 그다음/그 다음, are only marked and passed on to the LLM disambiguation later.
Stage 3: Block merging
Groups correction units into RevisedBlock units. Each block holds the original span (origin) and correction candidates (revisions[]),
and when a compound needs further correction inside it, the blocks are nested in nested[].
Stage 4: Per-eojeol checks
Checks the eojeols inside a block one by one. Three kinds of rule-based correction run at this stage.
| Check | Example |
|---|---|
| Frequency-based typo correction | 스빈다 → 습니다 |
| Non-standard word correction | 글장이 → 글쟁이, 낌을 → 낌새를 |
| Confusable word correction (revise-ai) | Fixes word pairs that are confusing in meaning |
Why run the rules first?
A large share of Korean spelling errors come from frequently repeated typos, non-standard words, and word spacing.
These types can be corrected quickly and consistently with dictionaries and rules, and even with a rationale (rule_article) attached.
Handling what rules can cover first reduces LLM calls, which gains speed, cost savings, and stability together.
Stage 5: LLM correction of OOV and unanalyzable eojeols
Only eojeols that rules could not resolve, meaning unclassified (UNK), unanalyzable (NA), and needs-confirmation (CONFIRM) eojeols, are corrected by the LLM.
Results that stray too far from the original by Hangul edit distance (Levenshtein distance) are rejected to prevent over-correction.
Results are cached per eojeol (MD5 key), so the same input is not called again.
Stage 6: LLM disambiguation of ambiguous spacing
Spacing and joining that were marked ambiguous in stage 2 are decided by the LLM. The decision of whether to join or separate a compound noun is also made here. This stage also uses the cache.
Result: correction + rationale
The final response, CorrectErrorResponse, returns not only the original text (origin) and the corrected text (revised),
but also the revision blocks (revised_blocks[]) and a helps map holding the rationale for each correction.
ReviseHelp contains the reason for the correction (comment), examples (examples), and the source rule (rule_article),
so you can explain "why it was corrected this way" to the user.
(Planned) Sentence-level error correction
While the four filters above deal with errors at the eojeol and word level, sentence-level error correction, which looks at the whole sentence, is planned to be built with an LLM. The error types under consideration include redundant meaning, ambiguity, excessive omission, overuse of the passive, overuse of the causative, subject-predicate agreement problems, overuse of foreign words, subject-object agreement, inappropriate vocabulary, and punctuation.
In one sentence
Bareun uses hybrid correction, fixing most things quickly with rules and handing only ambiguous or out-of-vocabulary parts to the LLM, to get speed, rationale, and accuracy at the same time.
Frequently asked questions
Q. In what order does the correction pipeline run?
It runs in this order: token post-processing → rule-based spacing correction → block merging → per-eojeol checks (frequency typos, non-standard words, confusable words) → LLM correction of OOV and unanalyzable eojeols → LLM disambiguation of ambiguous spacing.
Q. What are the four error filters of the Bareun corrector?
① Identifying morphological errors at the segmentation stage with 14 error types among 115 segmentation labels, ② NFD (phoneme) based dictionary search, ③ LLM confusable-word correction that tells similar-sounding words apart by context, and ④ a sentence error model that looks at the whole sentence.
Q. Does it catch errors across a whole sentence?
Sentence-level error correction, such as redundant meaning, ambiguity, excessive omission, overuse of the passive and causative, subject-predicate agreement, overuse of foreign words, and punctuation, is planned to be built with an LLM. The current pipeline handles eojeol- and word-level errors with the four error filters.
Q. Does the correction result also give the reason?
Yes. ReviseHelp, held in the helps map of the response, provides the reason for the correction (comment), examples (examples),
and the source rule (rule_article).