1. 한국어 RAG의 과제
한국어 RAG의 구조적 어려움
한국어 RAG는 영어 RAG와 근본적으로 다른 문제를 해결해야 합니다. 이는 한국어의 언어학적 특성 에서 비롯됩니다. 1. 교착어 (Agglutinative Language) 특성 한국어는 어근에 조사, 어미, 접사가 결합하여 하나의 단어를 형성합니다. 영어가 단어 순서(어순)로 문법적 관계를 표현하는 것과 달리, 한국어는 접사의 결합 으로 표현합니다. 이로 인해 동일한 의미의 단어가 수십 가지 형태로 변화합니다.이 문제들이 RAG에 미치는 실제 영향
위 특성들이 결합되면, 영어 기준으로 설계된 RAG 파이프라인은 한국어에서 심각한 성능 저하를 겪습니다:- BM25 키워드 검색 실패: 조사가 붙은 채로 토큰화되어 “데이터브릭스에서” ≠ “데이터브릭스를”로 처리됨
- 토큰 비용 급증: 일반 토크나이저(tiktoken, SentencePiece)로 한국어를 처리하면 영어 대비 2~3배 많은 토큰 소비
- 임베딩 품질 저하: 한국어 학습 데이터 부족으로 의미 벡터의 정밀도가 떨어질 수 있음
주의 한국어 RAG에서 가장 흔한 실수는 영어 기준 파이프라인을 그대로 적용하는 것입니다. 특히 BM25 기반 키워드 검색은 형태소 분석 없이는 한국어에서 제대로 작동하지 않습니다.
2. Kiwi 한국어 형태소 분석기
형태소 분석이란? — 한국어 RAG의 핵심 전처리
형태소(Morpheme) 는 의미를 가진 최소 언어 단위입니다. 영어에서는 단어 사이의 공백(space)이 곧 의미 단위의 경계이지만, 한국어는 하나의 어절(띄어쓰기 단위) 안에 여러 형태소가 결합되어 있습니다. 형태소 분석은 이 어절을 의미 단위로 분해하는 작업입니다.- 사전 탐색: 내장 사전에서 가능한 형태소 조합 후보를 탐색합니다. 예를 들어 “구축했습니다”는 “구축+했+습니다”로도, “구+축했+습니다”로도 분해할 수 있습니다.
- 확률 모델 적용: 여러 후보 중 가장 자연스러운 조합 을 통계적으로 선택합니다. 대규모 한국어 코퍼스에서 학습된 확률 분포를 기반으로, “구축+했+습니다”가 훨씬 자연스러운 분해임을 판단합니다.
- 미등록어 처리: 사전에 없는 신조어(예: “데이터브릭스”, “레이크하우스”)도 주변 문맥과 문자 패턴을 기반으로 품사를 추정합니다. 이 능력이 기술 문서 처리에서 특히 중요합니다.
Kiwi란?
Kiwi 는 C++ 기반의 고속 한국어 형태소 분석기입니다. 다른 한국어 형태소 분석기(KoNLPy의 Mecab, Komoran 등)와 비교했을 때 정확도와 속도 모두 뛰어나며, 특히 신조어와 미등록어 처리에 강합니다. Python 바인딩(kiwipiepy)을 통해 쉽게 사용할 수 있습니다.
| 형태소 분석기 | 속도 | 정확도 | 설치 편의성 | 미등록어 처리 |
|---|---|---|---|---|
| Kiwi | 매우 빠름 (C++) | 높음 | pip install 한 줄 | 통계 기반 추정 |
| Mecab (KoNLPy) | 빠름 (C) | 높음 | 시스템 의존성 복잡 | 사전 추가 필요 |
| Komoran (KoNLPy) | 보통 (Java) | 보통 | JVM 필요 | 사전 추가 필요 |
| Okt (KoNLPy) | 느림 (Java) | 보통 | JVM 필요 | 제한적 |
설치
기본 사용법
주요 품사 태그
| 태그 | 의미 | 예시 |
|---|---|---|
| NNG | 일반명사 | 파이프라인, 구축, 데이터 |
| NNP | 고유명사 | Databricks, Unity Catalog |
| VV | 동사 | 구축하다, 배포하다 |
| VA | 형용사 | 빠르다, 정확하다 |
| SL | 외국어 | RAG, LLM, API |
| JK* | 조사 | 에서, 을, 의 |
| E* | 어미 | 합니다, 했습니다 |