한국어 RAG에서 chunk size는 단순히 몇 글자나 몇 토큰으로 자를지의 문제가 아닙니다. 문장 경계, 조사와 어미, 표와 목록 구조가 함께 깨지면 검색은 됐는데 답변 근거가 어색해질 수 있습니다.
가장 중요한 기준은 chunk가 독립적으로 읽혀도 질문에 답할 수 있는 의미 단위를 유지하는가입니다. 크기보다 먼저 경계를 봐야 합니다.
chunk size를 숫자로만 정하면 생기는 문제
chunk size를 500자, 1,000자처럼 숫자로만 정하면 구현은 쉽습니다. 하지만 실제 문서에서는 문단 중간, 표의 행 중간, 조건 설명 중간에서 잘릴 수 있습니다. 이렇게 잘린 chunk는 embedding은 되지만 검색 후 답변 근거로 쓰기 어렵습니다.
RAG에서 chunk는 검색 단위이면서 동시에 답변 근거 단위입니다. 검색만 잘 되는 것이 아니라, 검색된 chunk를 읽었을 때 답변에 필요한 정보가 충분히 들어 있어야 합니다.
한국어에서 경계가 더 민감해 보이는 이유
한국어 문장은 조사와 어미가 문장 안의 관계를 많이 표현합니다. 앞 문장에 나온 주어, 대상, 조건을 다음 문장에서 이어받는 경우도 많습니다. 그래서 문단 중간을 잘라버리면 chunk 안에서 누가 무엇을 했는지 흐려질 수 있습니다.
- 이것, 해당 방식, 위 조건 같은 지시어가 앞 문단을 필요로 한다
- 조사와 어미가 관계를 만들지만 chunk가 잘리면 대상이 사라진다
- 문단 제목 없이 본문만 남으면 검색 결과가 맥락을 잃는다
- 목록의 상위 조건과 하위 항목이 분리되기 쉽다
문단 기준 chunking이 기본값이 되는 이유
한국어 업무 문서나 기술 문서는 문단 단위로 하나의 설명이 완결되는 경우가 많습니다. 그래서 먼저 문단을 기준으로 나누고, 너무 긴 문단만 다시 쪼개는 방식이 안전합니다.
1. 제목과 섹션 heading을 보존한다
2. 문단 단위로 먼저 나눈다
3. 너무 긴 문단만 문장 단위로 나눈다
4. 앞뒤 문맥이 필요한 곳은 overlap을 둔다표와 목록은 따로 봐야 한다
표는 일반 문단보다 깨지기 쉽습니다. 표의 한 행만 검색되면 열 이름이 빠질 수 있고, 열 이름만 검색되면 실제 값이 빠질 수 있습니다. 목록도 상위 문장과 하위 항목이 분리되면 의미가 약해집니다.
표를 chunk로 만들 때는 열 이름, 행 값, 표 제목을 함께 보존하는 방식이 필요합니다. 단순 텍스트 추출 후 글자 수로 자르면 답변 근거가 흐려질 가능성이 큽니다.
overlap은 언제 도움이 될까
overlap은 chunk 사이에 일부 문맥을 겹쳐 넣는 방법입니다. 경계 근처의 문장이 다음 chunk에서도 필요할 때 도움이 됩니다. 하지만 overlap을 크게 잡으면 index 크기와 중복 검색이 늘어납니다.
- 도움이 되는 경우: 문단 사이 지시어가 많고 경계 근처 정보가 중요할 때
- 주의할 경우: 같은 근거가 여러 chunk로 반복 검색될 때
- 점검 기준: 답변 근거가 좋아지는지, 중복으로 context가 낭비되는지 함께 본다
chunk size보다 먼저 평가셋을 만든다
chunk size는 감으로 정하면 오래 흔들립니다. 작은 질문 세트를 만들고, 각 질문에 필요한 정답 근거가 어떤 chunk에서 나와야 하는지 표시해야 합니다.
- 실제 사용자가 물을 질문 20개를 고른다
- 각 질문의 정답 근거 문단을 표시한다
- chunk size 후보를 2~3개 만든다
- top-k 안에 정답 근거가 들어오는지 본다
- 답변 품질과 context 낭비를 함께 비교한다
실무 권장 출발점
처음부터 완벽한 숫자를 찾기보다 문서 성격별 출발점을 정하는 편이 좋습니다. FAQ는 작게, 긴 정책 문서는 섹션 단위로, 표가 많은 문서는 표 전처리를 별도로 보는 식입니다.
- FAQ: 질문과 답변 한 쌍을 하나의 chunk로 유지한다
- 기술 문서: heading과 문단을 함께 보존한다
- 정책 문서: 조항 번호와 본문을 분리하지 않는다
- 표 문서: 열 이름과 행 값을 함께 남긴다
정리
한국어 RAG에서 chunk size는 숫자보다 경계의 문제입니다. 의미 단위가 깨지지 않아야 검색 결과가 답변 근거로 살아납니다. 문단, 표, 목록, overlap을 따로 보고 작은 평가셋으로 검증하는 것이 가장 현실적인 접근입니다.
일반적인 chunking 개념은 LangChain text splitters 문서를 참고할 수 있습니다. 기존 글인 RAG chunk size 선택 기준과 함께 보면 전체 흐름이 이어집니다.
