Skip to main content
한국어 임베딩 모델 선택, RAG 베스트 프랙티스(Re-ranking 포함), 한국어 특화 전처리, 평가 주의사항, 트러블슈팅을 다룹니다.

​
5. 한국어 임베딩 모델 선택 가이드

기준multilingual-e5KoSimCSE (SKT)bge-m3 (BAAI)
한영 혼용 문서최적영어 성능 약함우수
순수 한국어 문서우수최적우수
Databricks 기본 제공가능불가 (직접 배포)불가 (직접 배포)
Dense + SparseDense만Dense만둘 다 지원
권장 선택 기준:
  1. 빠른 시작 + 한영 혼용: multilingual-e5-large-instruct
  2. 순수 한국어 + 최고 품질: KoSimCSE-roberta-multitask
  3. 하이브리드 검색 내장: bge-m3
  4. 비용 최적화: gte-multilingual-base

​
KoSimCSE를 Model Serving에 배포하는 방법

import mlflow
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BM-K/KoSimCSE-roberta-multitask")

with mlflow.start_run():
    mlflow.sentence_transformers.log_model(
        model=model, artifact_path="kosimcse",
        registered_model_name="catalog.schema.kosimcse_embedding",
        input_example=["한국어 임베딩 테스트"],
    )
팁 한영 혼용 문서가 많은 환경에서는 다국어 모델(multilingual-e5, bge-m3)이 더 적합합니다.

​
6. 한국어 RAG 베스트 프랙티스

​
권장 구성

단계권장 도구/전략
토크나이저Kiwi + KSS 조합
청킹Recursive + 한국어 구분자
임베딩multilingual-e5-large-instruct
검색Hybrid (Kiwi BM25 + Vector)
재정렬bge-reranker-v2-m3

​
왜 Re-ranking이 한국어 RAG에서 특히 중요한가

Re-ranking은 LLM이 최종 답변을 생성하는 품질에 직접적으로 영향 을 미칩니다. “Lost in the Middle” 문제: LLM은 긴 컨텍스트에서 처음과 끝 에 있는 정보는 잘 활용하지만, 중간 에 있는 정보는 간과합니다. 가장 관련성 높은 문서가 상위(1~2위)에 위치해야 합니다. 한국어에서 Re-ranking이 특히 효과적인 이유:
  1. 조사 변형에 의한 노이즈: Cross-encoder는 표면적 차이를 무시하고 핵심 의미만으로 판단
  2. 한영 혼용 매칭: “벡터 검색”과 “Vector Search”가 동일 개념임을 정밀 포착
  3. 전문 용어 문맥 이해: 구체적 문맥을 이해하여 정밀하게 순위 매김
참고 한국어 기술 문서 RAG에서 Re-ranking을 추가하면 Top-5 Precision이 일반적으로 10~25%p 향상 됩니다.

​
한국어 특화 전처리

import re
from kiwipiepy import Kiwi

kiwi = Kiwi()

def preprocess_korean(text: str) -> str:
    text = re.sub(r'\s+', ' ', text).strip()
    text = re.sub(r'[^\w\s가-힣a-zA-Z0-9.,!?·\-()]', '', text)
    return text

​
평가 시 주의사항

  • 한국어 평가 데이터셋을 직접 구축 해야 합니다
  • 평가 지표: Retrieval에는 Recall@K, MRR, 생성에는 정확성, Faithfulness
  • LLM-as-Judge를 사용한다면 한국어 이해도가 높은 모델을 Judge로 사용

​
7. 한국어 RAG 실전 트러블슈팅

문제원인해결 방법
”데이터브릭스”를 검색하면 안 나옴공백 기반 BM25에서 조사 결합Kiwi 토크나이저 BM25 사용
한영 혼용 문서에서 영어 키워드 검색 안 됨한국어 특화 모델의 영어 한계다국어 모델 사용
청크 중간에서 문장이 잘림영어 기반 구분자만 사용한국어 종결어미 구분자 추가
토큰 비용이 예상보다 높음한국어가 2~3배 많은 토큰 소비청크 크기를 문자 수로 관리
동의어/유의어 검색 안 됨임베딩 거리가 멀 수 있음Query Expansion 또는 Multi-Query Retriever

​
성능 벤치마크 참고값

지표양호우수최적화 목표
Recall@5> 0.75> 0.85> 0.90
Faithfulness> 0.80> 0.90> 0.95
전체 응답 시간< 8초< 5초< 3초

​
참고 문서