Why Korean RAG Needs Morpheme-Aware Chunking

Korean does use spaces, so Korean chunking looks like a solved problem. The units between the spaces are not words, though — they are words with grammar welded on — and that is enough to make lexical retrieval miss documents that contain the exact term the user asked for.

A worked sentence

Take 학생이 학교에서 책을 읽었다 — “the student read a book at school”. Four space-separated units, and every one of them is a stem plus something attached:

학생이      학생 (student)  + 이   subject particle
학교에서    학교 (school)   + 에서 locative particle ("at, from")
책을        책   (book)     + 을   object particle
읽었다      읽   (read)     + 었   past tense
                            + 다   declarative ending

4 space-separated units, 9 morphemes.

Now consider the same noun in other sentences: 학교는, 학교가, 학교를, 학교로, 학교에, 학교의, 학교와, 학교까지. Each is a different string. A user searching for 학교 has typed the bare stem, which appears nowhere in the document as a standalone token.

Why whitespace tokenising breaks

Split on whitespace and every particle-bearing form is its own type in the index. Three consequences follow, and they are worth separating because two of them are severe and one is mild.

• Lexical search misses outright. BM25 matches tokens. The query token 학교 does not equal the document token 학교에서, so the document scores zero on that term. This is a complete miss, not a ranking degradation, and it is the reason hybrid search on Korean underperforms unless the lexical side is analysed.
• Term statistics fragment. A noun occurring 400 times across ten inflected forms looks like ten terms of 40 occurrences each. IDF is computed per form, so every form looks rarer than the concept is, and the scoring is distorted even for queries that do match.
• Dense retrieval degrades, but only mildly. Subword tokenizers usually break 학교에서 into pieces that include the stem, so an embedding model has seen the relationship and largely handles it. The exception is short queries, where there is little else in the vector to carry the meaning — the mechanism described in short queries and morphology in embeddings.

So the honest statement is: dense-only Korean retrieval works tolerably; hybrid Korean retrieval with an unanalysed lexical side is actively worse than dense alone on some queries, because the lexical component contributes noise where it should contribute signal.

The eojeol is not a word

The unit between two spaces in Korean is called an eojeol, and treating it as equivalent to an English word is the specific mistake underneath all of the above. An eojeol is closer to a phrase: a content morpheme plus one or more functional morphemes that would be separate words in English. “At school” is two English words and one Korean eojeol.

For chunking specifically this is mostly good news. Because spaces exist, packing eojeol into chunks never cuts inside a word, and the catastrophic failures that afflict Chinese and Thai do not occur. Korean sentences end with 다. followed by a space, or with ？ and ！, so sentence segmentation is straightforward too.

The place chunk boundaries do matter is that Korean puts the verb at the end of the sentence and drops subjects freely. A chunk that ends mid-sentence loses the predicate, and a chunk that begins mid-paragraph often has no stated subject at all, because the subject was established two sentences earlier and omitted since. That argues for slightly more overlap in Korean than you would use in English, and for never splitting inside a sentence.

Morphological analysis in the index

The fix for the lexical side is a morphological analyser: a component that decomposes each eojeol into morphemes and indexes the ones that carry meaning. Elasticsearch and OpenSearch ship a Korean analysis plugin built on a morphological dictionary; the standalone analysers used in the Python ecosystem wrap the same family of dictionaries.

1. Analyse at index time: store 학교 and 에서 as separate tokens for the eojeol 학교에서, and keep the original eojeol as a token too so exact-phrase queries still work.
2. Apply the identical analyser to the query. An asymmetry here reintroduces the miss you were fixing, in the other direction.
3. Filter particles and endings from the indexed token set — they are the Korean equivalent of stopwords and they inflate the index without discriminating between documents.
4. Keep compound decomposition in mind: analysers can split a compound noun into its parts, which increases recall and can hurt precision. Index both the compound and its parts and let scoring decide.
5. Leave the dense side alone. Embed the original text, unanalysed. The embedding model was trained on natural text and feeding it a morpheme-separated string is out of distribution.

That last step is the one most often got wrong. Morphological analysis belongs to the lexical half of a hybrid system only. Running it over the text you embed makes the embeddings worse, not better.

The Hangul normalisation trap

One more thing will bite a Korean pipeline regardless of how the chunking is done. Hangul syllables have two Unicode representations: a precomposed syllable block such as 학 (U+D559) in NFC, and the decomposed sequence of conjoining jamo — ᄒ, ᅡ, ᆨ — in NFD. They render identically and compare unequal.

The practical source of the mismatch is filenames and text originating on macOS, whose filesystem stores names in a decomposed form, so a corpus assembled from uploaded files can hold both representations of the same string. A query typed on any keyboard arrives composed and matches only half the corpus.

Together these give a Korean pipeline three requirements that an English one does not have: NFC at every boundary, a morphological analyser on the lexical index only, and sentence-aligned chunks with enough overlap to survive a dropped subject. None of them is difficult; all of them are silent when missing.