RAG chunk size는 RAG를 만들 때 가장 자주 막히는 설정값입니다. 하지만 300자, 500자, 1,000자 중 하나가 항상 정답인 것은 아닙니다.
핵심은 chunk size를 숫자가 아니라 검색 단위와 답변 근거 단위로 보는 것입니다. 문서 구조, 질문 유형, context packing, 평가셋을 함께 봐야 합니다.
RAG chunk size 선택 기준
RAG chunk size에 정답 숫자는 없다
LangChain의 text splitters 문서는 긴 텍스트를 작은 chunk로 나누는 여러 방법을 다룹니다. 중요한 것은 문서를 의미 있는 검색 단위로 자르는 것입니다.
작은 chunk는 검색 결과가 정밀해질 수 있지만 문맥이 끊기기 쉽습니다. 큰 chunk는 문맥을 넓게 담지만 관련 없는 문장까지 함께 들어올 수 있습니다.
문서 구조를 먼저 본다
- FAQ는 질문-답변 단위가 자연스럽다
- 정책 문서는 heading과 섹션 경계가 중요하다
- 코드 문서는 함수와 클래스 경계를 깨면 이해하기 어렵다
- 리포트는 문단보다 제목 계층을 유지하는 편이 나을 수 있다
overlap은 보험이지 해결책이 아니다
overlap은 chunk 경계에서 문맥이 잘리는 문제를 줄여주지만, 너무 크면 같은 정보가 여러 번 검색되고 비용이 늘어납니다.
chunk_size = 800
chunk_overlap = 120
# 출발점일 뿐, 평가셋으로 조정해야 한다평가셋으로 확인한다
- 필요한 근거 chunk가 top-k 안에 들어오는가
- 불필요한 chunk가 너무 많이 섞이지 않는가
- 답변이 검색 근거를 실제로 사용했는가
- 비용과 지연시간이 감당 가능한가
정리
RAG chunk size는 한 번 정하고 끝나는 값이 아닙니다. 문서 구조를 기준으로 시작하고, 실제 질문 평가셋으로 검색 품질과 답변 근거를 확인하면서 조정해야 합니다.
RAG chunk size를 숫자로만 정하면 생기는 문제
RAG chunk size를 500 tokens, 800 tokens처럼 숫자 하나로 정하려고 하면 결정은 빨라집니다. 하지만 실제 품질은 숫자보다 문서가 어디서 끊기는지에 더 크게 흔들립니다.
- FAQ나 짧은 정책 문서는 작은 chunk가 더 잘 맞는 경우가 많다
- 긴 기술 문서나 튜토리얼은 너무 작게 자르면 전제와 결론이 갈라진다
- 표, 코드, 절차 문서는 문단보다 의미 단위로 끊는 편이 안전하다
- 문서마다 최적값이 다르므로 한 설정을 전체 문서에 강제하면 품질이 흔들린다
그래서 chunk size는 “몇 글자가 정답인가”가 아니라 “검색된 조각만 보고 답할 수 있는가”를 묻는 설정입니다.
문서 유형별 출발점
- 짧은 Q&A 문서: 질문과 답변 한 묶음을 한 chunk로 본다
- API 문서: 엔드포인트, 파라미터, 예제 응답을 가능하면 같은 chunk에 둔다
- 강의/블로그 글: H2/H3 섹션 단위로 먼저 나누고 너무 긴 섹션만 다시 쪼갠다
- 계약서/정책 문서: 조항 번호와 예외 조건이 분리되지 않도록 overlap을 보수적으로 둔다
특히 RAG에서 자주 생기는 실패는 답변 모델 문제가 아니라 검색 단위 문제입니다. 답을 만들 정보는 문서에 있는데 chunk가 어색하게 잘려서 검색 결과에 들어오지 않는 경우가 많습니다.
평가셋으로 chunk size를 고르는 절차
- 실제 사용자가 물을 만한 질문 20~50개를 먼저 만든다
- 각 질문마다 반드시 들어와야 하는 근거 문단을 표시한다
- chunk size와 overlap 후보를 3~4개만 정한다
- 각 후보에서 top-k 검색 결과에 정답 근거가 들어오는지 본다
- 답변 품질보다 먼저 retrieval recall을 확인한다
- 비용과 latency가 급격히 늘어나는 설정은 제외한다
candidates = [
{"chunk_size": 400, "overlap": 80},
{"chunk_size": 800, "overlap": 120},
{"chunk_size": 1200, "overlap": 160},
]
for config in candidates:
index = build_index(documents, **config)
score = evaluate_retrieval(index, question_set)
print(config, score.recall_at_5, score.avg_context_tokens)이런 식으로 비교하면 “대충 1000자로 자르자”보다 훨씬 안정적인 결정을 할 수 있습니다. 중요한 것은 한 번에 완벽한 값을 찾는 것이 아니라, 검색 실패가 줄어드는 방향을 관찰하는 것입니다.
실패 신호별 조정 기준
- 근거가 자주 누락된다: chunk를 키우거나 overlap을 늘린다
- 엉뚱한 문서가 자주 검색된다: chunk를 줄이고 제목/메타데이터를 보강한다
- 답변이 길고 느리다: top-k나 chunk size를 줄여 context 낭비를 줄인다
- 비슷한 조각이 반복 검색된다: overlap을 줄이거나 중복 제거를 넣는다
관련해서 같이 보면 좋은 글
RAG context packing이 중요한 이유도 함께 보면 이 글의 기준을 더 쉽게 연결할 수 있습니다.
RAG reranking은 왜 필요할까도 함께 보면 이 글의 기준을 더 쉽게 연결할 수 있습니다.
