RAG 시스템 구축하며 겪은 청크 사이즈 최적화 문제

배경

사내 기술 문서와 API 문서를 검색하는 시스템에 RAG를 도입하게 되었다. OpenAI Embeddings와 Pinecone을 조합해 구축했는데, 초기 설정에서 검색 정확도가 생각보다 낮았다.

문제 상황

처음엔 청크 사이즈를 512 토큰으로 설정했다. 대부분의 예제에서 사용하는 값이었기 때문이다. 하지만 실제 검색 결과를 보니 문맥이 잘려나가거나, 너무 많은 내용이 포함되어 관련성이 떨어지는 경우가 많았다.

특히 코드 스니펫이 포함된 문서에서 문제가 심했다. 함수 설명과 예제 코드가 분리되거나, 반대로 여러 함수가 한 청크에 뭉쳐져 검색 정확도가 떨어졌다.

실험 과정

여러 청크 사이즈를 테스트했다:

• 512 토큰: 초기 설정, 문맥 분리 문제
• 1024 토큰: 너무 넓은 범위로 정확도 하락
• 256 토큰: 문맥은 좋지만 경계 문제 발생
• 256 토큰 + 오버랩 20%: 경계 문제 해결

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=256,
    chunk_overlap=51,  # 20%
    length_function=tiktoken_len,
    separators=["\n\n", "\n", ". ", " ", ""]
)

chunks = text_splitter.split_text(document)

결과

256 토큰에 20% 오버랩을 적용하니 검색 정확도가 체감상 30% 정도 개선되었다. 특히 코드 예제가 포함된 문서에서 효과가 컸다.

다만 청크 수가 2배 가까이 늘어나 임베딩 비용과 저장 공간이 증가했다. 우리 케이스에선 정확도가 더 중요해서 트레이드오프를 감수했다.

배운 점

청크 사이즈는 문서 특성에 따라 달라진다. 일반적인 가이드라인도 중요하지만, 실제 데이터로 직접 테스트해보는 게 답이었다. 특히 코드가 포함된 기술 문서는 작은 청크 사이즈가 유리했다.