Repository navigation
[RFC] Korean Tokenization: Jamo Decomposition as Pre-tokenizer (A Blueprint for Compositional Scripts) #511
Description
Summary
Korean (Hangul) characters should be decomposed into their constituent jamo (consonant/vowel components) before tokenization. While this proposal focuses on Korean, this sub-character preprocessing step serves as a highly scalable blueprint for improving token efficiency and pattern generalization across other compositional scripts (e.g., Tibetan, Devanagari) in multilingual models.
This is a low-hanging fruit. Current approaches expand vocabulary tables by tens of thousands of entries to brute-force Korean coverage — at enormous compute and memory cost. A 10-line structural preprocessing step in the pre-tokenizer can achieve better coverage, slash token overhead by half, and improve multilingual performance simultaneously.
Background: How Hangul Works
Hangul is a compositional writing system. Every syllable block is a combination of 2-3 components:
한 = ㅎ (initial) + ㅏ (vowel) + ㄴ (final)
글 = ㄱ (initial) + ㅡ (vowel) + ㄹ (final)
가 = ㄱ (initial) + ㅏ (vowel) (no final)
The entire system uses only 68 jamo: 19 initials + 21 vowels + 28 finals (including none).
These combine into 11,172 possible syllable blocks in Unicode (U+AC00–U+D7A3). The composition is pure arithmetic:
code = 0xAC00 + (initial * 588) + (vowel * 28) + final
# Decomposition is the reverse — 3 lines of codeThe Problem
Current BPE/Unigram tokenizers treat each of the 11,172 syllable blocks as independent symbols with no structural relationship:
한 (U+D55C) → token #8234
할 (U+D560) → token #9102
함 (U+D568) → token #7891
These three share initial ㅎ + vowel ㅏ (differing only in final consonant), but the tokenizer sees zero relationship. It's like treating "cat", "car", "can" as completely unrelated symbols instead of recognizing the "ca-" prefix.
Result:
- Korean text consumes 2-3x more tokens than equivalent English text.
- Pattern generalization across similar-sounding words is lost.
- Vocabulary table wastes space on 11,172 entries vs 68 jamo.
- Korean users pay more for API usage for the same semantic content.
Proposed Solution
Add an optional Hangul jamo decomposition step in the normalizer/pre-tokenizer pipeline:
Input: "한글 처리"
Current: [한] [글] [처] [리] → 4+ tokens (opaque blocks)
Proposed: [ㅎㅏㄴ] [ㄱㅡㄹ] [ㅊㅓ] [ㄹㅣ] → jamo sequences (composable)
The decomposition is trivial — Unicode arithmetic, ~10 lines of code:
def decompose_hangul(char: str) -> str:
code = ord(char) - 0xAC00
if not (0 <= code < 11172):
return char
initial = code // 588
vowel = (code % 588) // 28
final = code % 28
result = INITIALS[initial] + VOWELS[vowel]
if final > 0:
result += FINALS[final]
return resultExpected Benefits
| Metric | Current | With Jamo Decomposition |
|---|---|---|
| Vocabulary entries for Korean | ~11,172 syllable blocks | 68 jamo |
| Token count for Korean text | 2-3x vs English | Potentially close to parity |
| Cross-word pattern sharing | None (opaque blocks) | Structural (shared jamo = shared tokens) |
| Implementation cost | — | Minimal (Unicode arithmetic) |
Considerations
- Token count per Korean word may increase (1 syllable → 2-3 jamo tokens), but vocabulary compression + pattern generalization should offset this.
- Reconstruction is lossless — jamo → syllable block is deterministic.
- This could be opt-in (language-detected or user-specified).
- Multilingual Scalability: This sub-character decomposition approach provides a foundational framework that can be directly adapted to benefit other compositional scripts (e.g., Tibetan, Devanagari, Thai) for broader multilingual token optimization.
- Empirical Validation: Research like KR-BERT (Lee et al., 2020) has already proven the empirical superiority of Sub-character BPE for Korean. Modern global tokenizers still rely on inefficient Byte-Level BPE (BBPE) that ignores the mathematical compositionality of scripts. Supporting Jamo decomposition in the pre-tokenizer is a cost-free architectural win.
References & Empirical Evidence
- KR-BERT (Lee et al., 2020): Proves that Sub-character BPE drastically reduces vocabulary size while outperforming character-level models. (arXiv:2008.03979)
- Jeon et al., 2023: "Improving Korean NLP Tasks with Linguistically Informed Subword Tokenization and Sub-character Decomposition" (arXiv:2311.03928)
- ACL 2024 Findings: "Korean Character Representations Based on the Combination Rules of Subcharacters" (ACL Anthology)
- Unicode Hangul Syllable Decomposition: Official algorithmic specification. (Unicode Standard, Chapter 3.12)
- Reference Implementation: MorphSubDecomp-Korean — Sub-character decomposition pre-tokenizer pipeline
Activity
[-][Feature Request] Hangul Jamo Decomposition as Tokenizer Preprocessing (A Blueprint for Compositional Scripts)[/-][+][RFC] Korean Tokenization: Jamo Decomposition as Pre-tokenizer (A Blueprint for Compositional Scripts)[/+]nicezic commentedon Mar 22, 2026
[RFC] 한국어 토큰화: 자소(Jamo) 분해를 Pre-tokenizer에 도입하자 (조합형 문자를 위한 청사진)
요약
한글 음절 블록을 자모(초성/중성/종성)로 분해하는 전처리를 토크나이저 파이프라인에 추가하자는 제안이다. 한국어에 초점을 맞추고 있지만, 이 방식은 티베트어, 데바나가리, 태국어 등 다른 조합형 문자 체계에도 동일하게 적용 가능한 확장 가능한 프레임워크이다.
이건 "가장 따기 쉬운 열매(Low-Hanging Fruit)"다. 현재 방식은 한국어 커버리지를 위해 수만 개의 어휘 항목을 무차별적으로 추가하면서 막대한 연산 비용과 메모리를 낭비하고 있다. Pre-tokenizer에 10줄짜리 구조적 전처리 하나만 넣으면, 더 나은 커버리지를 달성하고 토큰 오버헤드를 절반 이하로 줄이며 다국어 성능까지 동시에 잡을 수 있다.
배경: 한글의 구조
한글은 조합형 문자 체계다. 모든 음절 블록은 2~3개의 구성 요소의 조합이다:
전체 시스템은 68개의 자모만 사용한다: 초성 19개 + 중성 21개 + 종성 28개(없음 포함).
이것들이 유니코드(U+AC00~U+D7A3)에서 11,172개의 음절 블록으로 조합된다. 조합 공식은 순수 산술이다:
문제점
현재 BPE/Unigram 토크나이저는 11,172개의 음절 블록 각각을 구조적 관계가 없는 독립 심볼로 취급한다:
이 세 글자는 초성 ㅎ + 중성 ㅏ를 공유하고(종성만 다름), 하지만 토크나이저는 이 관계를 전혀 모른다. 영어로 비유하면 "cat", "car", "can"을 "ca-" 접두사를 인식하지 못하고 완전히 무관한 기호로 취급하는 것과 같다.
결과:
제안하는 해결책
Normalizer/Pre-tokenizer 파이프라인에 한글 자모 분해 단계를 추가한다:
분해 구현은 간단하다 — 유니코드 산술, ~10줄의 코드:
기대 효과
고려사항
현재 글로벌 빅테크의 맹점
영어/라틴어 계열은 알파벳이 1차원으로 늘어선 선형적(Linear) 구조이기 때문에 BPE/BBPE가 잘 작동한다. 그래서 "모든 언어를 바이트 단위로 쪼갠 뒤 통계적으로 묶으면 된다"는 영어 중심적(English-centric) 사고방식에 갇혀 있다.
한글이 **수학적 계산식으로 이루어진 2D 블록(Compositional block)**이라는 걸 이해하지 못하니, 11,172개의 음절을 무식하게 Vocabulary에 때려넣는 Brute-force 방식에 엄청난 메모리와 컴퓨팅 자원을 낭비하고 있다.
참고문헌 및 실증적 근거