1. 청킹이 RAG 품질에 미치는 영향
청크 크기는 RAG 파이프라인 전반에 영향을 미칩니다:| 청크 크기 | 검색 정밀도 | 컨텍스트 품질 | 토큰 비용 |
|---|---|---|---|
| 너무 작음(< 100 토큰) | 높음 | 컨텍스트 부족, 의미 불완전 | 낮음 |
| 적정(256~1024 토큰) | 적정 | 충분한 컨텍스트 | 적정 |
| 너무 큼(> 2000 토큰) | 낮음 (노이즈 포함) | 관련 없는 정보 혼재 | 높음 |
참고 일반적으로 256~1024 토큰 이 적정 범위이지만, 도메인과 문서 특성에 따라 달라집니다. 반드시 평가를 통해 최적 크기를 찾아야 합니다.
각 청킹 전략의 “왜”와 트레이드오프
청킹은 단순한 텍스트 분할이 아니라, 검색 정밀도와 컨텍스트 품질 사이의 트레이드오프 를 관리하는 작업입니다. 작은 청크 (< 256 토큰)- 왜 좋은가: 검색 정밀도가 높아집니다. 질문에 정확히 매칭되는 문장을 찾을 확률이 높습니다.
- 왜 나쁜가: LLM에 전달되는 컨텍스트가 부족합니다. “Unity Catalog의 접근 제어”라는 청크만으로는 전체 맥락을 이해할 수 없습니다.
- 적합한 경우: FAQ, 용어 정의, 짧은 규정 조항
- 왜 좋은가: 충분한 컨텍스트를 제공하여 LLM이 맥락을 이해하고 완전한 답변을 생성할 수 있습니다.
- 왜 나쁜가: 청크 내에 관련 없는 내용이 혼재하여 임베딩 벡터의 의미가 희석됩니다. 검색 시 노이즈가 증가합니다.
- 적합한 경우: 긴 서술형 문서, 법률 조항, 기술 사양서
- 왜 권장되는가: 대부분의 기술 문서에서 하나의 개념이나 절차를 설명하는 자연스러운 단위입니다.
- 트레이드오프: 모든 문서 유형에 최적은 아닙니다. 반드시 평가를 통해 검증해야 합니다.
한국어 특화 청킹 고려사항
한국어 텍스트는 영어와 다른 특성을 가지므로, 청킹 시 추가 고려가 필요합니다:- 토큰 수 차이: 동일한 의미의 텍스트가 영어 대비 2~3배 많은 토큰을 소비합니다.
chunk_size를 문자 수 기반으로 설정하면 더 예측 가능합니다. - 조사 결합: “데이터브릭스에서”, “데이터브릭스를” 등 조사가 붙어 동일 단어가 다르게 토큰화됩니다. 형태소 분석기(Kiwi)를 활용한 전처리가 효과적입니다.
- 종결어미 기반 분절: 한국어 문장은 “~합니다.”, “~입니다.”, “~하세요.” 등의 종결어미로 끝납니다. 이를 구분자로 활용하면 자연스러운 문장 경계에서 분할됩니다.
최적 청크 크기 실험 결과
실제 한국어 기술 문서(Databricks 가이드, 정책 문서)로 실험한 결과입니다. 동일한 평가 데이터셋(50개 질문)에 대해 각 청크 크기별 성능을 비교했습니다.| 청크 크기 (문자) | Recall@5 | Faithfulness | 평균 답변 길이 | 비고 |
|---|---|---|---|---|
| 200 | 0.72 | 0.85 | 짧음 | 맥락 부족으로 불완전한 답변 빈번 |
| 500 | 0.81 | 0.88 | 적정 | FAQ 스타일 문서에 적합 |
| 800 | 0.86 | 0.91 | 적정 | 한국어 기술 문서 최적 |
| 1000 | 0.84 | 0.90 | 풍부 | 영어 기술 문서에 적합 |
| 1500 | 0.78 | 0.87 | 매우 풍부 | 노이즈 증가, 비용 상승 |
| 2000 | 0.71 | 0.83 | 매우 풍부 | 관련 없는 정보 혼재 |
팁 한국어 문서에서는 800 문자(chunk_overlap=100)가 좋은 시작점입니다. 이는 영어의 1000 토큰과 유사한 의미 밀도를 가집니다. 단, 이 결과는 기술 문서 기준이므로 도메인에 따라 다를 수 있습니다.
2. 전략별 비교
아래 테이블은 네 가지 주요 청킹 전략을 한눈에 비교한 것입니다. 각 전략의 핵심 차이는 청크 경계를 결정하는 기준 이 무엇인가에 있습니다.| 전략 | 방식 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|---|
| Fixed-size | 고정 문자/토큰 수로 분할 | 구현 간단, 예측 가능 | 문장/의미 중간에서 잘림 | 빠른 프로토타이핑 |
| Recursive | 구분자 우선순위로 재귀 분할 | 범용적, 구조 보존 | 최적 구분자 설계 필요 | 대부분의 프로덕션 환경 |
| Semantic | 임베딩 유사도로 경계 결정 | 의미 전환점 자동 감지 | 연산 비용 높음, 임베딩 의존 | 주제가 다양한 문서 |
| Document-structure | 헤딩/섹션 기반 분할 | 문서 구조 완벽 보존 | 구조화된 문서에만 적용 | Markdown, HTML 문서 |
3. 각 전략 코드 예제
RecursiveCharacterTextSplitter (가장 범용적)
LangChain에서 가장 많이 사용되는 텍스트 분할기입니다. 구분자 우선순위에 따라 재귀적으로 분할합니다.\n\n(문단)으로 먼저 분할 시도- 청크가 여전히 크면
\n(줄바꿈)으로 재분할 - 그래도 크면
.(문장)으로 재분할 - 최종적으로 공백, 문자 단위까지 분할
SemanticChunker (의미 기반)
SemanticChunker는 고정 길이나 구분자 대신, 텍스트의 의미 변화 를 감지하여 자연스러운 주제 경계에서 분할합니다. 동작 원리는 다음과 같습니다:- 텍스트를 문장 단위로 나눕니다
- 각 문장을 임베딩 모델로 벡터화합니다
- 인접한 문장 쌍의 코사인 유사도(cosine similarity) 를 계산합니다
- 유사도가 급격히 떨어지는 지점(breakpoint)을 주제 전환점으로 판단합니다
- breakpoint를 기준으로 청크를 분할합니다
breakpoint_threshold_type 파라미터로 전환점 감지 방식을 조절합니다. "percentile"은 유사도 변화량의 상위 N%를 전환점으로 사용하고, "standard_deviation"은 평균에서 N 표준편차 이상 벗어난 지점을 전환점으로 사용합니다.
주의 SemanticChunker는 모든 문장에 대해 임베딩을 계산하므로, 대규모 문서셋에서는 비용과 시간이 크게 증가합니다. 문서 수가 적고 품질이 중요한 경우에 적합합니다.
MarkdownHeaderTextSplitter (문서 구조 기반)
Markdown 문서의 헤딩을 기준으로 분할하며, 헤딩 정보를 메타데이터로 보존합니다.토큰 기반 분할
문자 수 대신 토큰 수 기반으로 분할하면 LLM 컨텍스트 윈도우를 더 정확하게 관리할 수 있습니다.4. 청크 오버랩 전략
오버랩(overlap)은 인접 청크 간에 겹치는 영역을 두어 경계에서의 정보 손실을 방지하는 기법입니다. 예를 들어 “A 기능은 B 조건에서 작동합니다”라는 문장이 청크 경계에 걸려 “A 기능은”과 “B 조건에서 작동합니다”로 나뉘면, 두 청크 모두 의미가 불완전해집니다. 오버랩을 설정하면 이 문장이 양쪽 청크에 모두 포함되어 정보 손실을 방지합니다. 아래 테이블은 오버랩 비율별 장단점을 비교한 것입니다.| 오버랩 비율 | 장점 | 단점 |
|---|---|---|
| 0% | 중복 없음, 인덱스 크기 최소 | 경계에서 문맥 단절 |
| 10~20%(권장) | 경계 문맥 보존, 검색 품질 향상 | 약간의 인덱스 증가 |
| 30% 이상 | 문맥 보존 극대화 | 중복 과다, 비용 증가, 검색 노이즈 |
팁 오버랩이 너무 크면 동일한 내용이 여러 청크에 포함되어 검색 결과가 중복될 수 있습니다. 10~20% 를 시작점으로 설정하고 평가를 통해 조정하세요.
5. 메타데이터 첨부
청크에 메타데이터를 첨부하면 검색 시 필터링으로 정밀도를 높일 수 있습니다.권장 메타데이터 필드
| 필드 | 용도 | 예시 |
|---|---|---|
source | 원본 파일 경로/이름 | "policies/hr-guide.pdf" |
page | 페이지 번호 | 3 |
section | 섹션/챕터 제목 | "휴가 정책" |
doc_type | 문서 유형 | "policy", "faq", "manual" |
created_at | 문서 생성/수정 일자 | "2025-01-15" |
메타데이터 첨부 예제
메타데이터 기반 필터 검색
참고 Databricks Vector Search는 메타데이터 필터를 서버 사이드에서 처리하므로, 대규모 인덱스에서도 효율적으로 필터링됩니다. Self-Query Retriever와 결합하면 사용자의 자연어 질문에서 자동으로 필터를 추출할 수 있습니다.
6. 청킹 전략 선택 플로우
어떤 청킹 전략을 선택할지 결정하는 데 도움이 되는 가이드입니다:프로덕션 환경 권장 설정
| 환경 | 전략 | chunk_size | chunk_overlap | 비고 |
|---|---|---|---|---|
| 영어 기술 문서 | Recursive | 1000 | 200 | 기본 구분자 |
| 한국어 기술 문서 | Recursive + 한국어 구분자 | 800 | 100 | 종결어미 구분자 추가 |
| Markdown 문서 | MarkdownHeader + Recursive | 800 | 100 | 2단계 분할 |
| FAQ 문서 | Fixed-size | 300 | 0 | 짧은 청크, 오버랩 불필요 |
| 법률/의료 문서 | Semantic | 1200 | 150 | 의미 경계 중요 |
성공 핵심 원칙: 완벽한 청킹 전략은 없습니다. 평가 데이터셋을 만들고, 여러 전략을 비교 실험하여 해당 도메인에 최적인 설정을 찾으세요. MLflow Evaluate로 Recall@K, Faithfulness를 측정하면 객관적인 비교가 가능합니다.