청크 크기는 몇 토큰이 정답일까?
정답은 고정값이 아니라 질의 유형에 달려 있다. 공개 실험들을 종합하면 짧은 사실형 QA는 64~128토큰, 정의·절차·예외가 얽힌 설명형 QA는 512~1024토큰 구간에서 더 나은 검색 성능을 보였다. 다만 이 결과는 특정 임베딩 모델·데이터셋·평가 지표 조합에서 나온 값이라 그대로 복사하면 안 된다.
이 글의 핵심
- 고정 길이 청크 비교 실험에서 짧은 사실형 데이터셋은 64~128토큰, 설명·기술 맥락 데이터셋은 512~1024토큰이 유리했다 (arXiv 2505.21700).
- 동일 코퍼스에서도 질의마다 최적 청크 크기가 달라 Recall@1 차이가 20~30%p, 일부는 40%p 이상 벌어진 오라클 비교가 보고됐다 (AI21 블로그).
- 시맨틱 청킹이 항상 고정 길이보다 낫지는 않았다. 한 공개 비교에서 고정 512토큰(0.8775)이 시맨틱(0.8686)보다 종합 점수가 높았다 (GitHub rag-chunking-benchmark).
- Recall@k와 답변 정확도는 다른 질문이다. 청크 크기 실험은 검색 단계와 생성 단계를 분리해 평가해야 한다.
무엇을 검증하려 했나
이 실험이 검증하려는 건 단순하다. "같은 문서를 어떤 크기로 자르면 검색이 더 잘 되는가"다. 그런데 이 질문은 생각보다 많은 변수를 숨기고 있다. 임베딩 모델, 토크나이저, overlap 비율, top-k, 질의 유형이 모두 결과에 끼어든다. 청크 크기 하나만 바꾸고 나머지를 전부 고정하지 않으면, 어떤 변화가 성능 차이를 만들었는지 구분할 수 없다. 그래서 이번 실험은 "청크 크기"라는 하나의 변수를 분리해서 비교하는 데 집중했다.
실험 설계는 어떻게 짜야 통제가 되나?
통제는 "청크 크기 외 모든 조건을 고정"하는 데서 시작한다. 공개 실험들이 공통으로 지키는 최소 조건은 다음과 같다. 동일한 PDF 파서·토크나이저·임베딩 모델·벡터 DB를 유지하고, 청크 크기만 128·256·512·1024처럼 단계적으로 바꾼다. overlap은 별도 변수로 분리해 0%와 10~20%를 각각 비교해야 섞인 효과를 피할 수 있다.
질의도 하나의 묶음으로 두면 안 된다. 짧은 사실 확인, 회의록의 특정 발언 찾기, 장문 서사의 연결된 맥락은 서로 다른 청크 크기를 요구한다는 보고가 있다 (AI21 블로그). 그래서 질의를 사실형·다단계·표·요약형으로 나눠 결과를 따로 집계해야 한다. 여기서 흔한 실수는 top-k를 고정하지 않는 것이다. 시맨틱 청킹 연구는 top-k = 1, 3, 5, 10을 각각 비교했는데, 청크 크기만 바꾸고 top-k나 재순위화를 함께 바꾸지 않으면 실험이 실제 운영 조건을 충분히 반영하지 못한다 (ACL Findings 2025).
청크 크기별로 검색 성능은 실제로 어떻게 갈렸나?
짧을수록 정밀하고, 길수록 맥락이 붙는다는 큰 흐름은 확인됐지만 경계값은 데이터셋마다 달랐다. 2025년 연구는 stella_en_1.5B_v5와 snowflake-arctic-embed-l-v2.0 임베딩으로 64·128·256·512·1024토큰을 비교했고, Recall@k 기준 짧은 사실형 데이터셋에서는 64~128토큰, 설명·기술적 맥락이 필요한 데이터셋에서는 512~1024토큰이 더 나았다 (arXiv 2505.21700).
다른 실험은 더 세밀한 구간을 봤다. MIRAGE 벤치마크는 위키백과 문서를 BERT 토크나이저 기준 330토큰으로 잘랐는데, 예비 실험에서 110토큰과 550토큰보다 관련·비관련 샘플 검색의 균형이 좋았다고 보고했다 (ACL Findings NAACL 2025). 또 다른 사례는 50·100·200·500·1000·2000토큰 슬라이딩 윈도우로 QMSum, NarrativeQA, 자체 Seinfeld 대화 데이터셋을 비교했는데, 질의마다 최적 청크 크기가 달라 Recall@1 차이가 보통 20~30%p, 일부는 40%p 이상 벌어졌다. 다만 이건 정답을 알고 최적 크기를 고르는 오라클 비교라서 일반 운영 성능으로 그대로 해석하면 안 된다 (AI21 블로그).
구조도 숫자만큼 중요하다. 2025년 연구들은 단순 토큰 수뿐 아니라 제목·절·문단 경계를 보존하는 분할 방식이 검색 성능에 영향을 준다고 보고했다 (ACL Findings 2025). 고정 길이로만 자르면 문장 중간이 끊겨 의미 단위가 깨질 수 있다는 점을 실험 설계 단계에서 함께 비교 대상으로 넣어야 한다.
검색이 잘 되면 답변도 좋아질까? 평가는 어떻게 나눠야 하나?
검색 지표와 답변 품질은 같은 숫자가 아니다. Recall@k가 높다고 생성 답변이 정확하거나 근거를 충실히 인용한다는 보장은 없다. 그래서 검색 단계와 생성 단계를 분리해서 측정해야 한다. 검색 단계에서는 Recall@k, MRR, nDCG, Context Precision, Context Recall을 보고, 최종 답변 단계에서는 정확성, 근거 인용 여부, 환각률, 입력 토큰 수와 비용을 따로 측정한다.
공개 비교 하나가 이 구분이 왜 필요한지 잘 보여준다. 고정 512토큰은 Faithfulness 0.9096, Answer Relevancy 0.8558, Context Precision 0.8143, Context Recall 0.9250을 기록했다. 반면 시맨틱 청킹은 Faithfulness 0.9420으로 더 높았지만 Context Precision은 0.7038로 더 낮았다 (GitHub rag-chunking-benchmark). 즉 "더 충실한 답변"과 "더 정밀한 검색"이 같은 방향으로 움직이지 않을 수 있다는 뜻이다. 비용도 함께 봐야 한다. 같은 실험에서 40개 질문 처리 비용은 고정 512가 $0.023, 고정 1024가 $0.038, 시맨틱이 $0.012로 나타났다. 통화·API 가격·프롬프트·캐시 조건이 명시된 재현 설정을 확인하지 않으면 이 숫자는 다른 환경에서 그대로 재현되지 않는다.
공개 벤치마크들은 왜 서로 다른 결론을 내놓나?
데이터셋과 평가 조건이 다르기 때문이다. 아래는 지금까지 언급한 실험들을 한 표로 정리한 것이다.
| 실험 | 비교 구간 | 유리했던 구간 | 평가 지표 |
|---|---|---|---|
| arXiv 2505.21700 | 64~1024토큰 | 사실형 64~128, 설명형 512~1024 | Recall@k |
| AI21 블로그 | 50~2000토큰 | 질의별 상이, 오라클 비교 | 문서 수준 Recall@K |
| MIRAGE 벤치마크 | 110·330·550토큰 | 330토큰 | 관련/비관련 균형 |
| GitHub 벤치마크 | 256·512·1024·시맨틱·하이브리드 | 고정 512 (해당 문서 한정) | 종합 점수·비용 |
이 표에서 눈여겨볼 건 "이긴 구간"이 실험마다 다르다는 사실 자체다. 어느 하나가 보편적으로 우월하다는 근거는 아직 없고, 각 실험은 자기 데이터셋·모델 조합 안에서의 비교 결과일 뿐이다.
이 실험 결과를 어디까지 믿어도 되나?
여기까지가 한계다. 첫째, 오라클 비교로 나온 Recall@1 차이(20~30%p, 일부 40%p 이상)는 정답을 미리 알고 최적 크기를 고른 상한선이다. 실제 운영에서는 질의마다 청크 크기를 실시간으로 바꿀 수 없으니 이 숫자를 기대 성능으로 오해하면 안 된다. 둘째, GitHub 비교의 0.8775 vs 0.8686 같은 종합 점수 차이는 특정 문서와 40개 질문에 한정된 결과라 일반화할 수 없다고 해당 실험 자체가 명시하고 있다. 셋째, 페이지 단위 청킹의 평균 정확도 0.648 같은 수치는 2차 정리 글에서 인용된 값이라, 실제로 제품 문서에 쓰려면 NVIDIA 원문 벤치마크와 실험 버전을 다시 확인하는 편이 안전하다 (LinkedIn 정리). 넷째, 시맨틱 청킹은 임베딩 기반 경계 탐지 때문에 인덱싱 단계 계산량이 커질 수 있다는 점도 비용 비교에서 빠뜨리면 안 된다 (ACL Findings NAACL 2025).
이번 실험에서 다음에 무엇을 바꿀까?
2026년 기준으로 정리하면, 다음 라운드에서 손볼 부분은 세 가지다. 먼저 overlap 비율을 독립 변수로 완전히 분리해서 0%와 10~20%를 각각의 청크 크기 구간에 적용해봐야 한다. 지금까지의 비교는 overlap이 섞여 있어 "청크가 커서 좋은 건지 overlap이 많아서 좋은 건지"를 구분하지 못한 경우가 있었다. 다음으로 구조 기반 분할(제목·절 경계 보존)을 고정 길이 분할과 나란히 돌려봐야 한다. 마지막으로 질의 유형별 결과를 지금보다 더 세분화해서 표·요약형 질의에 대한 데이터를 따로 모아야 한다. 지금 재료로는 사실형·설명형 구분만 확실하고 표·요약형은 근거가 부족하다. 이번 라운드의 결론은 "이 크기가 맞다"가 아니라 "비교 설계를 다음에 어떻게 더 정교하게 짤 것인가"였다.
핵심 정리
- 청크 크기의 "정답"은 질의 유형에 따라 갈린다. 사실형 QA는 64~128토큰, 설명·기술형 QA는 512~1024토큰을 먼저 비교 실험하는 것이 근거에 맞는 시작점이다 (arXiv 2505.21700).
- 시맨틱 청킹이 고정 길이보다 항상 낫지는 않았다. 특정 비교에서는 고정 512토큰이 종합 점수와 비용 양쪽에서 더 나은 경우도 있었다 (GitHub rag-chunking-benchmark).
- Recall@k 같은 검색 지표와 Faithfulness, Context Precision 같은 답변 품질 지표는 따로 측정해야 하며, 둘이 반대로 움직일 수도 있다.
- 청크 크기만 바꾸고 overlap, top-k, 임베딩 모델을 고정하지 않으면 어떤 변수가 성능을 바꿨는지 알 수 없다.
- 오라클 비교에서 나온 큰 Recall@1 차이는 실제 운영 성능의 상한선이지 기대치가 아니다.