3. Kiwi 기반 BM25 Retriever
기본 BM25는 공백 기반으로 텍스트를 분절하므로, 한국어에서는 조사가 붙은 채로 토큰화됩니다. Kiwi로 형태소 분석 후 명사/동사/외국어만 추출 하면 검색 품질이 크게 향상됩니다.Kiwi + Ensemble Retriever
한국어 RAG에서 가장 효과적인 조합은 Kiwi BM25 + Dense (Vector Search) 앙상블입니다:
팁
한국어 전문 용어가 많은 도메인(법률, 의료 등)에서는 BM25 가중치를 0.5~0.6으로 높이면 정확한 용어 매칭이 강화됩니다.
4. 한국어 청킹 전략
| 전략 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 문장 기반 (KSS) | 한국어 문장 경계 인식 | 자연스러운 분절 | 문장이 짧으면 청크가 너무 작음 |
| 형태소 기반 | Kiwi로 의미 단위 분절 | 정확한 의미 보존 | 구현 복잡 |
| Semantic 청킹 | 임베딩 유사도 기반 경계 결정 | 의미 전환점 자동 감지 | 연산 비용 높음 |
| Recursive + 한국어 구분자 | 한국어 종결어미 기반 분절 | 범용적, 구현 간단 | 구분자 설계 필요 |
KSS (Korean Sentence Splitter) 활용
RecursiveCharacterTextSplitter + 한국어 구분자
참고 한국어에서RecursiveCharacterTextSplitter를 사용할 때는 종결어미(다.,요.)를 구분자에 추가하면 문장 중간에서 잘리는 것을 방지할 수 있습니다.
5. 한국어 임베딩 모델 선택 가이드
임베딩 모델 선택은 RAG 검색 품질에 직접적인 영향을 미칩니다. 한국어 환경에서는 다국어 모델 과 한국어 특화 모델 중 사용 환경에 맞는 것을 선택해야 합니다.multilingual-e5 vs KoSimCSE: 언제 어떤 모델을 선택할 것인가
| 기준 | multilingual-e5-large-instruct | KoSimCSE (SKT) | bge-m3 (BAAI) |
|---|---|---|---|
| 한영 혼용 문서 | 최적 | 영어 성능 약함 | 우수 |
| 순수 한국어 문서 | 우수 | 최적 | 우수 |
| Databricks 기본 제공 | 가능 (Foundation Model API) | 불가 (직접 배포 필요) | 불가 (직접 배포 필요) |
| 운영 복잡도 | 낮음 | 높음 (Model Serving 배포) | 높음 (Model Serving 배포) |
| 추론 속도 | 보통 | 빠름 (768차원) | 보통 |
| Dense + Sparse | Dense만 | Dense만 | 둘 다 지원 |
- 빠른 시작 + 한영 혼용:
multilingual-e5-large-instruct(Databricks 기본 제공, 추가 배포 불필요) - 순수 한국어 + 최고 품질:
KoSimCSE-roberta-multitask(한국어 STS 벤치마크 최상위) - 하이브리드 검색 내장:
bge-m3(Dense + Sparse 벡터를 하나의 모델에서 동시 생성) - 비용 최적화:
gte-multilingual-base(768차원, 빠른 추론, 스토리지 절약)
모델 비교 테이블
| 모델 | 차원 | 한국어 성능 | Databricks 지원 | 비고 |
|---|---|---|---|---|
| multilingual-e5-large-instruct | 1024 | 우수 | Foundation Model API | 다국어, Databricks 기본 제공 |
| bge-m3(BAAI) | 1024 | 우수 | Model Serving 배포 | Dense + Sparse 하이브리드 지원 |
| KoSimCSE(SKT) | 768 | 매우 우수 | Model Serving 배포 | 한국어 특화, STS 벤치마크 상위 |
| gte-multilingual-base(Alibaba) | 768 | 우수 | Model Serving 배포 | 경량, 빠른 추론 속도 |
KoSimCSE를 Model Serving에 배포하는 방법
한국어 특화 모델을 사용하려면 Databricks Model Serving에 직접 배포해야 합니다.Databricks Foundation Model API 활용
팁 한국어 전용 임베딩 모델(KoSimCSE 등)은 한국어 내부 유사도 측정에서는 뛰어나지만, 한영 혼용 문서가 많은 환경에서는 다국어 모델(multilingual-e5-large-instruct,bge-m3)이 더 적합합니다.
6. 한국어 RAG 베스트 프랙티스
권장 구성
| 단계 | 권장 도구/전략 | 이유 |
|---|---|---|
| 토크나이저 | Kiwi + KSS 조합 | 형태소 분석 + 문장 분리 |
| 청킹 | Recursive + 한국어 구분자 | 종결어미 기반 자연스러운 분절 |
| 임베딩 | multilingual-e5-large-instruct | Databricks 기본 제공, 한영 혼용 지원 |
| 검색 | Hybrid (Kiwi BM25 + Vector) | 키워드 + 의미 검색 결합 |
| 재정렬 | bge-reranker-v2-m3 | 다국어 Reranker, 한국어 지원 |
왜 Re-ranking이 한국어 RAG에서 특히 중요한가
위 테이블에서 재정렬(Re-ranking) 을 권장하는 이유를 깊이 살펴봅니다. Re-ranking은 단순히 “검색 결과를 더 잘 정렬하는 것”이 아니라, LLM이 최종 답변을 생성하는 품질에 직접적으로 영향 을 미칩니다. “Lost in the Middle” 문제: LLM은 컨텍스트의 위치에 민감하다 2023년 스탠포드 연구(“Lost in the Middle: How Language Models Use Long Contexts”)에서 밝혀진 핵심 발견은, LLM이 긴 컨텍스트를 받았을 때 처음과 끝에 있는 정보는 잘 활용하지만, 중간에 있는 정보는 간과하는 경향 이 있다는 것입니다.- 조사 변형에 의한 노이즈: 형태소 분석을 적용해도, 1차 검색 단계의 임베딩 모델은 “데이터브릭스에서”와 “데이터브릭스를”에 미세하게 다른 벡터를 부여할 수 있습니다. Cross-encoder는 이런 표면적 차이를 무시하고 핵심 의미만으로 판단합니다.
- 한영 혼용 매칭: “벡터 검색”과 “Vector Search”가 동일 개념임을 Bi-encoder는 불완전하게 포착하지만, Cross-encoder는 질문-문서 쌍을 통째로 읽으므로 교차 언어 의미 매칭 이 더 정확합니다.
- 전문 용어 문맥 이해: “Unity Catalog 권한 설정”이라는 질문에서, Bi-encoder는 “권한”이라는 키워드와 매칭되는 모든 문서를 비슷한 점수로 반환하지만, Cross-encoder는 “Unity Catalog의 권한”이라는 구체적 문맥 을 이해하여 정밀하게 순위를 매깁니다.
참고 실전 수치: 한국어 기술 문서 RAG에서 Re-ranking을 추가하면 Top-5 Precision이 일반적으로 10~25%p 향상 됩니다. 특히 유사한 주제의 문서가 많은 도메인(예: Databricks 공식 문서처럼 여러 기능이 비슷한 키워드를 공유하는 경우)에서 효과가 두드러집니다. Re-ranking의 구체적인 구현 방법과 모델 비교는 Re-ranking 개념 및 Reranking 전략 페이지를 참조하세요.
한국어 특화 전처리
평가 시 주의사항
- 한국어 평가 데이터셋을 직접 구축 해야 합니다. 영어 벤치마크 결과가 한국어 성능을 보장하지 않습니다.
- 평가 지표: Retrieval에는 Recall@K (상위 K개 결과 중 정답이 포함된 비율), MRR(Mean Reciprocal Rank, 정답 문서가 몇 번째에 위치하는지의 역수 평균), 생성에는 정확성, 근거 충실도(Faithfulness, 답변이 제공된 컨텍스트에 근거하는 정도) 를 측정합니다.
- MLflow Evaluate를 활용한 평가 방법은 RAG 평가 가이드를 참조하세요.
주의 한국어 RAG 시스템을 평가할 때, LLM-as-Judge를 사용한다면 평가 프롬프트도 한국어로 작성하거나, 한국어 이해도가 높은 모델(Claude, GPT-4 등)을 Judge로 사용해야 합니다.
7. 한국어 RAG 실전 트러블슈팅
자주 발생하는 문제와 해결법
| 문제 | 원인 | 해결 방법 |
|---|---|---|
| ”데이터브릭스”를 검색하면 “데이터브릭스에서”가 포함된 문서가 안 나옴 | 공백 기반 BM25에서 조사 결합 형태를 다른 단어로 인식 | Kiwi 토크나이저를 적용한 BM25 사용 |
| 한영 혼용 문서에서 영어 키워드 검색이 안 됨 | 한국어 특화 임베딩 모델이 영어 표현을 잘 이해하지 못함 | 다국어 모델(multilingual-e5, bge-m3) 사용 |
| 청크 중간에서 문장이 잘림 | 영어 기반 구분자만 사용 | 한국어 종결어미 구분자 추가 (“다. ”, “요. “) |
| 토큰 비용이 예상보다 높음 | 한국어가 영어 대비 2~3배 많은 토큰 소비 | 청크 크기를 문자 수로 관리, 컨텍스트 길이 최적화 |
| 검색 결과는 좋은데 답변이 부자연스러움 | LLM의 한국어 생성 품질 문제 | Claude 또는 GPT-4 등 한국어 성능이 좋은 모델 사용 |
| 동의어/유의어 검색이 안 됨 | ”자동차”와 “차량” 등 동의어의 임베딩 거리가 멀 수 있음 | Query Expansion 또는 Multi-Query Retriever 적용 |
성능 벤치마크 참고값
한국어 기술 문서 기반 RAG 시스템의 일반적인 성능 범위입니다 (참고용):| 지표 | 양호 | 우수 | 최적화 목표 |
|---|---|---|---|
| Recall@5 | > 0.75 | > 0.85 | > 0.90 |
| Faithfulness | > 0.80 | > 0.90 | > 0.95 |
| Answer Relevancy | > 0.80 | > 0.85 | > 0.90 |
| 검색 지연 | < 500ms | < 200ms | < 100ms |
| 전체 응답 시간 | < 8초 | < 5초 | < 3초 |
참고 위 수치는 한국어 기술 문서 기준의 참고값입니다. 도메인(법률, 의료 등)에 따라 기대치가 다를 수 있으며, 반드시 해당 도메인의 평가 데이터셋으로 측정해야 합니다.