RAG 시스템에서 청크 크기에 따른 검색 정확도 비교

배경

사내 기술 문서 검색 시스템의 답변 품질이 떨어진다는 피드백이 계속 들어왔다. 특히 긴 문서에서 정보를 찾을 때 맥락이 끊기는 문제가 있었다.

현재 청크 크기는 512 토큰으로 고정되어 있었는데, 이게 적절한지 검증해본 적이 없었다.

테스트 설정

벡터 DB는 Pinecone을 사용 중이고, 임베딩 모델은 text-embedding-3-large를 쓰고 있다.

세 가지 청크 크기로 동일한 문서 세트를 인덱싱했다:

• 256 토큰 (오버랩 50)
• 512 토큰 (오버랩 100)
• 1024 토큰 (오버랩 200)

평가용 쿼리 50개를 준비하고, 각 설정별로 top-5 검색 결과의 relevance를 측정했다.

결과

256 토큰: 검색 정확도는 높았지만(NDCG@5: 0.82), LLM이 여러 청크를 조합해야 해서 답변 생성 시간이 길어졌다. 비용도 증가.

512 토큰: 균형이 가장 좋았다(NDCG@5: 0.79). API 명세처럼 구조화된 문서에서 특히 잘 작동했다.

1024 토큰: 개념 설명이 긴 아키텍처 문서에선 좋았지만, 짧은 FAQ는 노이즈가 많아졌다(NDCG@5: 0.74).

적용

문서 타입별로 청크 전략을 다르게 가져갔다:

def get_chunk_config(doc_type):
    configs = {
        'api_doc': {'size': 512, 'overlap': 100},
        'architecture': {'size': 1024, 'overlap': 200},
        'faq': {'size': 256, 'overlap': 50}
    }
    return configs.get(doc_type, {'size': 512, 'overlap': 100})

메타데이터에 doc_type을 추가해서 인덱싱 시 구분했다.

교훈

청크 크기는 트레이드오프다. 작으면 정확하지만 비용이 높고, 크면 맥락은 좋지만 노이즈가 섞인다. 도메인 특성을 고려한 분리 전략이 효과적이었다.

오버랩도 생각보다 중요했다. 문장이 청크 경계에서 잘리면 의미가 손실되는 경우가 많았다.