프로덕션 RAG 시스템에서 청크 크기 최적화하기

문제 상황

사내 기술 문서 검색 시스템을 RAG로 개편하면서 임베딩 청크 크기를 얼마로 할지 고민이었다. 대부분의 예제는 512 토큰을 사용하지만, 우리 문서는 API 레퍼런스부터 트러블슈팅 가이드까지 성격이 다양했다.

테스트 설계

512, 1024, 2048 토큰 세 가지 크기로 동일한 200개 문서를 청킹하고, 실제 질문 50개에 대한 검색 정확도를 측정했다. Claude 3.5 Sonnet으로 답변 품질을 평가했다.

def chunk_text(text, chunk_size=512, overlap=50):
    tokens = tokenizer.encode(text)
    chunks = []
    
    for i in range(0, len(tokens), chunk_size - overlap):
        chunk = tokens[i:i + chunk_size]
        chunks.append(tokenizer.decode(chunk))
    
    return chunks

결과

• 512 토큰: API 레퍼런스처럼 짧은 문서에서 가장 좋은 성능. 검색 속도 빠름
• 1024 토큰: 트러블슈팅 가이드처럼 맥락이 중요한 문서에서 우수. 균형잡힌 선택
• 2048 토큰: 긴 설명이 필요한 아키텍처 문서에 적합하지만, 노이즈 증가

오버랩은 50~100 토큰이 적당했다. 너무 크면 중복 정보가 많아지고, 작으면 문맥이 끊겼다.

최종 구현

문서 타입별로 다른 청크 크기를 적용하는 방식으로 결정했다.

CHUNK_SIZE_MAP = {
    'api': 512,
    'guide': 1024,
    'architecture': 1536
}

def process_document(doc):
    doc_type = classify_document(doc)
    chunk_size = CHUNK_SIZE_MAP.get(doc_type, 1024)
    return chunk_text(doc.content, chunk_size)

문서 분류는 간단한 키워드 기반 휴리스틱으로 처리했다. 완벽하진 않지만 80% 이상 정확도를 보였고, 전체적인 검색 품질이 20% 정도 향상됐다.

교훈

만능 청크 크기는 없다. 문서 특성과 질문 패턴을 분석해서 결정해야 한다. 초기에는 1024 토큰으로 시작하고, 로그를 보며 조정하는 게 현실적이다.