운영 중인 RAG 시스템 청크 크기 재조정 회고

문제 상황

3개월 전 배포한 사내 문서 검색 RAG 시스템에서 긴 문서에 대한 답변 품질이 떨어진다는 피드백이 계속 들어왔다. 특히 기술 스펙 문서나 가이드라인처럼 문맥이 긴 문서에서 관련 정보를 놓치는 경우가 잦았다.

초기 설정은 청크 크기 512토큰, 오버랩 20토큰이었다. 당시엔 "크게 나누면 문맥을 많이 담을 수 있겠지"라는 단순한 판단이었다.

원인 분석

로그를 분석해보니 두 가지 패턴이 보였다.

청크가 너무 커서 하나의 청크에 여러 주제가 섞임
오버랩이 작아서 중요한 정보가 청크 경계에 걸릴 때 누락

예를 들어 "배포 프로세스"와 "롤백 절차"가 한 청크에 들어가면, 벡터 임베딩이 두 개념을 혼합해 검색 정확도가 떨어졌다.

해결 과정

테스트 환경에서 여러 조합을 실험했다.

# 기존 설정
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=20,
    separators=["\n\n", "\n", " ", ""]
)

# 변경 설정
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=256,
    chunk_overlap=50,
    separators=["\n\n", "\n", "## ", " ", ""]
)

마크다운 헤더(## )를 구분자에 추가해 의미 단위로 분리되도록 했다.

100개 샘플 쿼리로 테스트한 결과:

512/20: 정확도 68%
256/50: 정확도 82%
128/30: 정확도 75% (너무 작아서 문맥 부족)

256/50 조합이 최적이었다.

배포 및 결과

벡터 DB 전체를 재인덱싱해야 해서 주말에 배포했다. 약 15만 개 문서 처리에 2시간 소요.

배포 후 2주간 모니터링 결과 사용자 만족도 설문이 3.2/5에서 4.1/5로 상승했다. 특히 "원하는 답을 찾지 못함" 피드백이 40% 감소했다.

교훈

RAG 시스템은 청크 전략이 생각보다 중요했다. 문서 특성에 따라 최적 크기가 다르므로, 초기 설정 후에도 주기적인 검증이 필요하다. 다음엔 문서 유형별로 다른 청킹 전략을 적용해볼 예정이다.