청킹 전략 심층 비교
청킹(Chunking)은 RAG 파이프라인의 첫 번째 관문 으로, 검색 품질에 결정적인 영향을 미칩니다. 잘못된 청킹은 아무리 좋은 검색 알고리즘과 Re-ranking을 사용해도 보완할 수 없습니다. 아래 표는 주요 청킹 기법을 비교합니다.| 청킹 기법 | 설명 | ML 모델 필요 | Databricks 지원 | 난이도 |
|---|---|---|---|---|
| 고정 크기 (Fixed-size) | 토큰/글자 수 기준으로 기계적 분할. 간단하지만 문맥이 중간에서 끊길 위험 | N/A | ✅ | 낮음 |
| Recursive | 문단 → 문장 → 단어 순으로 재귀적 분할. 가장 표준적. 문맥 보존율이 높음 | N/A | ✅ | 낮음 |
| 부모/자식 (Parent-Child) | Parent(큰 단위)로 LLM에 전달하고, Child(작은 단위)로 검색. 환각 방지에 효과적 | N/A | ✅ | 중간 |
| 의미 기반 (Semantic) | 문장별 임베딩 후 코사인 유사도가 크게 변하는 지점에서 분할 | Embedding | ✅ | 중간 |
| 명제 기반 (Proposition) | LLM으로 각 문장을 “독립적 명제(self-contained proposition)“로 변환 후 분할. 정보 밀도 극대화 | LLM | ✅ | 높음 |
부모/자식 청킹 상세
부모/자식(Parent-Child) 청킹은 검색 정확도와 문맥 풍부함 이라는 두 가지 상충하는 요구사항을 동시에 해결하는 전략입니다. 핵심 원리:- Child 청크(작은 단위, 100~200 토큰): Vector Store에 저장되어 검색 에 사용. 작은 크기 덕분에 정보 밀도가 높아 검색 정확도가 높음
- Parent 청크(큰 단위, 500~1000 토큰): 검색된 Child의 상위 문맥으로, LLM에 전달 되어 풍부한 맥락 제공
- 결과적으로 “작은 청크의 높은 검색 정확도 + 큰 청크의 풍부한 문맥” 을 동시에 확보
의미 기반 청킹 상세
의미 기반(Semantic) 청킹은 고정된 글자 수나 문단 경계가 아닌, 텍스트의 의미가 전환되는 지점 을 자동으로 감지하여 분할하는 기법입니다. 왜 필요한가? Recursive 청킹은 글자 수 기준으로 분할하므로, 하나의 주제를 다루는 문단이 두 청크로 나뉘거나, 서로 다른 주제가 하나의 청크에 섞일 수 있습니다. 의미 기반 청킹은 주제 전환 경계 를 자동으로 찾아 분할하므로, 각 청크가 하나의 일관된 주제를 담게 됩니다. 동작 원리:- 문서를 문장 단위로 분리합니다
- 각 문장을 임베딩 모델로 벡터화합니다
- 인접한 문장 쌍의 코사인 유사도(cosine similarity) 를 계산합니다. 코사인 유사도는 두 벡터가 같은 방향을 가리키는 정도를 -1~1 사이 값으로 나타내며, 1에 가까울수록 의미가 유사합니다
- 유사도가 급격히 감소하는 지점 (= 주제가 전환되는 지점)을 분할 경계로 설정합니다
breakpoint_threshold_type="percentile"과breakpoint_threshold_amount=95의 의미: 인접 문장 간 유사도 차이를 전체적으로 계산한 뒤, 상위 5%에 해당하는 급격한 변화 가 있는 지점에서만 분할합니다
주의 트레이드오프: 의미 기반 청킹은 모든 문장을 임베딩해야 하므로 Recursive 대비 처리 시간이 길고, 청크 크기가 불균일합니다. 또한 임베딩 모델의 품질에 크게 의존하므로, 도메인 특화 문서에서는 해당 도메인에 맞는 임베딩 모델을 사용하는 것이 중요합니다.
명제 기반 청킹 (Proposition-based Chunking)
명제 기반 청킹은 원본 텍스트를 독립적으로 이해 가능한 명제(self-contained proposition) 로 변환한 후 분할하는 기법입니다. 정보 밀도가 가장 높은 청킹 방법이지만, LLM 호출이 필요하므로 비용이 높습니다.핵심 아이디어
일반적인 문장은 문맥(context)에 의존합니다. “그 회사는 2023년에 설립되었다”에서 “그 회사”가 무엇인지는 앞 문장을 봐야 알 수 있습니다. 명제 기반 청킹은 이런 문장을 “Databricks는 2013년에 설립되었다” 와 같이 독립적으로 변환합니다.LLM 프롬프트 + Python 구현
주의 비용 주의: 명제 기반 청킹은 모든 문서를 LLM으로 처리해야 하므로, 대규모 문서에서는 비용이 급증합니다. 고가치 문서(법률 계약서, 기술 사양서) 에만 선택적으로 적용하고, 일반 문서는 Semantic 또는 Recursive 청킹을 사용하세요.
Late Chunking
Jina AI가 2024년에 제안한 기법으로, 기존 청킹의 문맥 손실 문제 를 근본적으로 해결합니다. 왜 필요한가? 기존 청킹 방식은 문서를 먼저 나눈 뒤 각 조각을 독립적으로 임베딩합니다. 이 과정에서 각 청크의 임베딩은 자기 자신만 참조하므로, 전체 문서에서의 위치나 맥락을 반영하지 못합니다. 예를 들어 “이 기능은 보안에 중요하다”라는 문장이 들어 있는 청크는, “이 기능”이 무엇인지 모른 채 임베딩됩니다. Late Chunking은 이 문제를 임베딩 순서를 뒤집어 해결합니다. 동작 원리:- 전체 입력: 문서 전체를 Long-context 임베딩 모델(예: jina-embeddings-v3, 8192 토큰)에 한 번에 입력합니다
- 토큰별 벡터 생성: 모델의 Transformer 레이어가 전체 문맥을 참조하여 각 토큰의 문맥 인식 벡터(contextual embedding) 를 생성합니다. 이 단계에서 “이 기능”이 실제로 무엇을 가리키는지가 벡터에 반영됩니다
- 청크 구간별 풀링(pooling): 토큰 벡터들을 미리 정의한 청크 경계에 따라 그룹화하고, 각 그룹의 벡터를 평균(mean pooling) 하여 하나의 청크 임베딩으로 만듭니다. 풀링(pooling)이란 여러 벡터를 하나로 요약하는 연산으로, 평균 풀링은 각 차원별로 평균값을 취합니다
기존 방식 vs Late Chunking
| 단계 | 기존 방식 | Late Chunking |
|---|---|---|
| 1단계 | 문서를 청크로 분할 | 문서 전체를 임베딩 모델에 입력 |
| 2단계 | 각 청크를 독립적으로 임베딩 | 모델이 전체 문맥을 보고 토큰별 벡터 생성 |
| 3단계 | 벡터 저장 | 토큰 벡터를 청크 구간별로 평균(pooling) |
| 결과 | 각 청크의 임베딩이 전체 문맥을 모름 | 각 청크의 임베딩이 전체 문서 문맥을 반영 |
Late Chunking의 장점
- 문맥 보존: “그것”, “이 회사” 같은 대명사의 참조 대상이 임베딩에 반영됨
- 경계 문제 완화: 청크 경계에서 잘린 정보도 전체 문맥에서 보완됨
- 추가 비용 없음: LLM 호출 불필요 (임베딩 모델만 사용)
참고 제약 사항: Late Chunking은 임베딩 모델의 최대 입력 길이 에 제한됩니다. 대부분의 임베딩 모델은 512~8192 토큰이므로, 긴 문서는 섹션별로 나누어 Late Chunking을 적용해야 합니다. Jina의 jina-embeddings-v3는 8192 토큰까지 지원합니다.
청크 크기 최적화: 경험적 실험 방법
“최적 청크 크기”는 문서 유형과 질의 패턴에 따라 다릅니다. 데이터 기반으로 최적값을 찾아야 합니다.RAGAS 메트릭으로 청크 크기 비교
RAGAS (Retrieval Augmented Generation Assessment)는 RAG 파이프라인의 품질을 자동으로 평가하는 오픈소스 프레임워크입니다. 주요 메트릭 4가지는 다음과 같습니다:- Faithfulness(충실도): 생성된 답변이 검색된 문맥에 근거 하는 정도. 1.0이면 답변의 모든 주장이 문맥에서 확인 가능하고, 낮을수록 환각이 많음
- Answer Relevancy(답변 관련성): 생성된 답변이 원래 질문에 얼마나 적절하게 대응하는 정도. 질문과 무관한 내용이 많으면 점수가 낮아짐
- Context Recall(문맥 재현율): 정답에 필요한 정보가 검색 결과에 포함 된 비율. 낮으면 필요한 문서를 검색하지 못한 것
- Context Precision(문맥 정밀도): 검색 결과 중 질문에 실제로 관련 있는 문서의 비율. 낮으면 불필요한 노이즈 문서가 많이 검색된 것
청크 크기별 특성
| 청크 크기 | Context Precision | Context Recall | Faithfulness | 비고 |
|---|---|---|---|---|
| 100 토큰 | 높음 | 낮음 | 중간 | 정보 단편화. 맥락 부족 |
| 200 토큰 | 높음 | 중간 | 중간~높음 | 사실 기반 Q&A에 적합 |
| 500 토큰 | 중간 | 높음 | 높음 | 대부분의 경우 최적 |
| 1000 토큰 | 중간 | 높음 | 높음 | 긴 설명이 필요한 문서에 적합 |
| 2000 토큰 | 낮음 | 높음 | 중간 | 노이즈 증가. LLM이 핵심을 놓칠 수 있음 |
참고 경험적 가이드: 특별한 이유가 없다면 500 토큰 + 20% 오버랩 으로 시작하세요. 이후 RAGAS 메트릭 기반으로 미세 조정합니다.
문서 유형별 청킹 전략
테이블 (표 구조 보존)
표를 단순 텍스트로 변환하면 구조 정보가 손실됩니다. 표 전체를 하나의 청크로 유지하는 것이 핵심입니다.| 전략 | 설명 |
|---|---|
| 표 전체를 하나의 청크 | 행/열 구조를 마크다운 테이블 형식으로 보존 |
| 표 + 캡션 결합 | ”표 3: 2024년 분기별 매출” + 표 내용을 하나의 청크로 |
| 셀 단위 분할 | 비추천. 구조 정보 완전 손실 |
코드 (함수/클래스 단위)
PDF (레이아웃 인식)
오버랩(Overlap) 전략
왜 오버랩이 중요한가?
청크 경계에서 문맥이 단절 되면, 해당 경계에 걸친 정보는 검색할 수 없게 됩니다.권장 오버랩 비율
| 오버랩 비율 | 저장 용량 증가 | 검색 정확도 | 권장 상황 |
|---|---|---|---|
| 0% | 없음 | 낮음 | 비추천 |
| 10% | ~10% | 중간 | 비용 절약이 중요할 때 |
| 20% | ~20% | 높음 | 기본 권장값 |
| 30%+ | ~30%+ | 높음 (수확 체감) | 중요 문서에만 선택적 |
청킹 품질 평가: Retrieval Recall@K
청킹 전략이 좋은지 나쁜지는 검색 품질 로 측정합니다. 가장 직관적인 메트릭은 Retrieval Recall@K 입니다.정의
측정 방법
참고 실무 팁: Recall@5 기준으로 0.85 이상 이면 양호한 청킹입니다. 0.80 미만이면 청킹 전략을 재검토하세요. 평가 데이터셋은 최소 50~100개의 Q&A 쌍 이 필요합니다.