RAG 실전 ③ — 청킹: 관성적인 overlap 400은 손해다

청킹은 "적당히 512토큰"으로 넘기기 쉬운 단계지만, 공개 어블레이션과 검증된 업그레이드 순서가 이미 나와 있다.

기본값 — Chroma 어블레이션의 결론

Chroma의 청킹 전략 평가(토큰 수준 recall/precision으로 정면 비교): RecursiveCharacterTextSplitter 200토큰·overlap 0이 recall 88.1%로 최상위권, 널리 쓰이는 OpenAI 기본값(800토큰/overlap 400)은 효율 하위권. overlap을 줄일수록 IoU가 개선됐다 — 관성적으로 넣는 큰 overlap은 인덱스만 부풀린다. LLM 시맨틱 청킹은 recall 91.9%지만 precision 3.9%로 토큰 낭비. 주의: 이 결과는 top-k 토큰 예산과 묶여 있어, 답변 생성 품질 기준으로는 512~1024가 나은 경우도 있다(LlamaIndex 계열 결과) — 실무 기본값: 구조 인지 recursive 200~512토큰, overlap 0~10%. 한국어는 문장 경계 처리를 Kiwi 같은 형태소 분석기와 결합할 것.

검증된 업그레이드 1: Small-to-Big (인덱스 구조로 해결)

"작은 청크는 검색에 유리하지만 생성 문맥이 부족하다"는 근본 트레이드오프를 부모-자식 계층 인덱스로 푼다: 검색은 128~512토큰 자식 청크로 정밀하게, LLM에는 1024토큰 부모 청크를 전달. 문서화된 실험에서 hit rate 77.8% → 89.7%, MRR 0.563 → 0.691. 임베딩 모델 교체 없이 +12%p — 구현 난이도 대비 효과가 가장 큰 패턴. LangChain은 ParentDocumentRetriever가 같은 것.

검증된 업그레이드 2: Contextual Retrieval (문맥을 인덱싱 시점에 되사기)

Anthropic의 기법: 청크마다 LLM이 "이 청크가 문서 전체에서 갖는 맥락" 50~100토큰을 생성해 앞에 붙인 뒤 임베딩+BM25 인덱싱. top-20 검색 실패율이 5.7% → 3.7%(임베딩만) → 2.9%(BM25 병행, -49%) → 1.9%(리랭킹까지, -67%). 프롬프트 캐싱을 쓰면 비용은 문서 100만 토큰당 $1.02 — 도입 품의서에 그대로 쓸 수 있는 숫자다. 코퍼스가 자주 안 바뀔수록 유리한 1회성 투자.

대안: Late Chunking (LLM 호출 0으로 같은 문제 풀기)

Jina의 late chunking: 롱컨텍스트 임베딩 모델로 문서 전체를 먼저 인코딩한 뒤 청크 경계별로 풀링 — 앞 문맥이 조건화된 청크 임베딩이 공짜로 나온다(BeIR NFCorpus +6.5pt). 단 토큰 임베딩을 노출하는 모델(jina-v3 등)이 필요해 임베딩 선택을 제약한다. Contextual Retrieval과의 비용-효과 비교로 결정하라.

도구

이 글의 전략 전부(recursive/semantic/late/LLM 청킹)를 단일 API로 A/B 테스트할 수 있는 경량 라이브러리가 Chonkie(설치 49MB, 경쟁 프레임워크의 1/3)다. LangChain 전체를 끌고 오지 않고 청킹만 필요할 때.

한 줄 요약: recursive 200~512·overlap 최소로 시작 → small-to-big → contextual retrieval — 이 순서가 검증된 업그레이드 경로다.

— RAG 실전 시리즈 ③ / 다음 글: 임베딩 모델 선택 — 리더보드 1등을 그대로 쓰지 마라