RAG 시스템에서 Chunk Size가 중요한 이유
RAG(Retrieval-Augmented Generation, 검색 증강 생성) 시스템의 성능은 거대언어모델(LLM)의 성능만큼이나 ‘어떤 데이터를 찾아 주느냐’에 따라 결정됩니다. 대규모 문서 데이터를 벡터 데이터베이스에 저장하기 위해 적절한 크기로 자르는 과정을 청킹(Chunking)이라고 하며, 이때 결정되는 Chunk Size(청크 크기)는 검색 정확도에 직접적인 영향을 미칩니다.
Chunk Size를 어떻게 설정하느냐에 따라 임베딩 모델이 텍스트의 의미를 포착하는 방식이 달라집니다. 너무 크거나 너무 작게 설정된 청크 크기는 시스템 내부에서 정보의 왜곡과 손실을 유발하여 최종적으로 LLM이 잘못된 답변을 생성하게 만드는 주된 원인이 됩니다.
Chunk Size가 지나치게 클 때 발생하는 문제점
청크 크기를 과도하게 크게 설정하면 하나의 청크 안에 너무 많은 정보와 서로 다른 주제가 혼재하게 됩니다. 이는 RAG 검색의 정밀도를 심각하게 떨어뜨리는 요인이 됩니다.
- 임베딩 의미의 희석 (Dilution of Meaning): 임베딩 모델은 하나의 청크를 하나의 벡터(점)로 변환합니다. 청크 안에 3~4가지의 서로 다른 주제가 섞여 있으면, 벡터는 이 모든 주제의 중간 지점에 위치하게 됩니다. 결과적으로 특정 주제에 대한 고유한 특징이 희석되어 사용자가 정밀한 질문을 던졌을 때 검색 매칭 확률이 떨어집니다.
- 노이즈 및 콘텍스트 오염 (Context Contamination): 검색 알고리즘이 큰 청크를 올바르게 찾아내어 LLM에 전달하더라도 문제가 발생합니다. 사용자의 질문과 관련이 있는 부분은 청크 전체의 10%에 불과하고 나머지 90%는 무관한 내용일 경우, LLM은 정답을 찾는 데 방해를 받게 되며 이는 할루시네이션(환각 현상)이나 엉뚱한 답변으로 이어집니다.
- 컨텍스트 윈도우 낭비: LLM이 한 번에 받아들일 수 있는 토큰 연산량에는 한계가 있습니다. 불필요하게 큰 청크 몇 개가 컨텍스트 창을 채워버리면, 실제로 도움이 될 수 있는 다른 문서의 청크들을 프롬프트에 포함하지 못하게 됩니다.
Chunk Size가 지나치게 작을 때 발생하는 문제점
반대로 검색의 정밀도를 높이기 위해 청크 크기를 너무 잘게 쪼개는 것 역시 RAG 시스템의 치명적인 독이 될 수 있습니다.
- 맥락의 완전성 상실 (Loss of Context): 문장 하나 또는 구절 하나 단위로 청크를 너무 작게 자르면, 해당 문장이 왜 도출되었는지에 대한 인과관계나 전제 조건이 유실됩니다. 예를 들어 “이 기능은 특정 상황에서 제한됩니다.”라는 문장만 단독 청크로 분리되면, ‘이 기능’이 무엇인지, ‘특정 상황’이 언제인지 알 수 없어 검색되어도 아무런 정보 가치를 가지지 못합니다.
- 파편화된 정보 검색 (Fragmented Retrieval): 사용자의 질문에 답하기 위해 전체적인 맥락 파악이 필요할 때, 정보가 수십 개의 작은 청크로 쪼개져 있으면 검색 시스템이 그중 일부만 단편적으로 가져오게 됩니다. LLM은 전체 그림을 보지 못하고 조각난 정보만으로 답변을 유추해야 하므로 완성도 낮은 답변을 출력하게 됩니다.
- 인덱싱 및 검색 비용 증가: 데이터가 과도하게 많은 청크로 분할되면 벡터 데이터베이스의 인덱스 크기가 비대해집니다. 이는 검색 속도 저하와 데이터베이스 관리 비용 상승이라는 운영상의 문제를 야음합니다.
청크 크기 문제로 인한 검색 실패 유형
잘못된 청크 크기 설정이 RAG 파이프라인에서 구체적으로 어떻게 검색 실패를 유도하는지 분류할 수 있습니다.
- False Negative (미검색): 청크가 너무 커서 내부 핵심 키워드나 의미가 희석된 결과, 검색 알고리즘이 유사도 점수를 낮게 측정하여 정작 필요한 문서를 탑 K(Top-K) 결과에서 제외하는 현상입니다.
- False Positive (오검색): 청크가 너무 작아 우연히 사용자의 질문 단어와 일치하는 단편적인 문장이 검색되었으나, 실질적인 문맥이나 정답은 포함되어 있지 않아 LLM에 쓸모없는 노이즈 정보만 제공하는 경우입니다.
- Information 간섭: 하나의 청크 내에 상반된 지침이나 데이터(예: “A 제품의 가격은 10만 원이다”와 “B 제품의 가격은 20만 원이다”)가 동시에 들어가 있어, LLM이 수치를 오인하고 교차 답변을 생성하는 오류입니다.
검색 정확도를 높이는 최적의 청킹 최적화 전략
RAG 검색 성능을 극대화하기 위해서는 단순한 고정 크기 분할을 넘어 데이터의 특성에 맞는 영리한 청킹 전략을 적용해야 합니다.
- 슬라이딩 윈도우 및 오버랩(Overlap) 적용: 고정 크기 청킹을 사용할 때는 청크와 청크 사이에 반드시 일정 비율(일반적으로 10% ~ 20%)의 텍스트가 겹치도록 오버랩을 설정해야 합니다. 문맥이 경계선에서 잘려 나가는 것을 방지하고 최소한의 전후 맥락을 보존할 수 있습니다.
- 소형 청크 검색 – 대형 청크 전달(Parent-Child Chunking): 검색할 때는 의미가 명확하고 정밀한 작은 청크(Child)를 대상으로 벡터 유사도 검사를 수행하고, 검색된 작은 청크가 속해 있는 상위의 큰 문맥 청크(Parent)를 통째로 LLM에 전달하는 방식입니다. 검색의 정밀도와 생성의 맥락 보존을 동시에 달내할 수 있는 가장 효과적인 아키텍처 중 하나입니다.
- 구조적/의미론적 청킹(Semantic Chunking) 활용: 글자 수로 기계적으로 자르는 대신 Markdown의 헤더(#, ##), HTML 태그, 혹은 문장 간 임베딩 유사도를 분석하여 실제 ‘주제와 의미’가 변하는 구역을 기준으로 청크 크기를 동적으로 조절하는 것이 좋습니다. 이를 통해 청크 내부의 정보 완결성을 확보할 수 있습니다.