RAG 청킹는 단어 뜻만 알고 넘어가면 실제 판단에서 자주 흔들리는 주제입니다. 이 글은 개념보다 먼저 실무에서 어디를 봐야 하는지부터 정리합니다.
핵심은 RAG에서 답변 품질이 흔들릴 때 chunk size와 문서 분할 기준을 점검하는 것입니다. 그래서 단순 요약이 아니라 선택 기준, 실패 신호, 점검 순서를 함께 보겠습니다.
RAG 청킹 판단 흐름
RAG 청킹은 검색 품질의 첫 단추다
RAG 청킹은 문서를 일정 글자 수로 잘라 넣는 단순 전처리가 아닙니다. 사용자의 질문이 들어왔을 때 검색 시스템이 의미 있는 조각을 찾을 수 있게 문서의 경계를 설계하는 작업입니다.
핵심은 모델이 답하는 데 필요한 맥락은 남기고, 검색에는 방해되는 노이즈는 줄이는 것입니다.
chunk size가 작을 때와 클 때
chunk가 너무 작으면 정확한 문장은 찾을 수 있지만 배경 맥락이 사라집니다. 반대로 너무 크면 필요한 내용과 필요 없는 내용이 한 조각에 섞여 검색 결과가 흐려집니다.
- 작은 chunk: 정확한 키워드 매칭은 쉬우나 맥락 부족 위험
- 큰 chunk: 맥락은 남지만 embedding이 여러 주제를 한꺼번에 품을 위험
- 중간 크기: 문서 종류와 질문 유형에 맞춰 실험 필요
문단과 제목 계층을 먼저 본다
기술 문서나 업무 문서는 보통 제목, 소제목, 문단, 표, 코드 블록의 구조를 가지고 있습니다. 이 구조를 무시하고 고정 길이로만 자르면 같은 의미 단위가 여러 조각으로 갈라질 수 있습니다.
def split_by_section(document):
sections = parse_markdown_headings(document)
chunks = []
for section in sections:
for part in split_long_paragraphs(section.body):
chunks.append({
"title_path": section.title_path,
"text": part,
})
return chunks제목 경로를 metadata로 남기면 검색 결과가 왜 선택됐는지 설명하기도 쉬워집니다.
overlap은 보험이지 해결책이 아니다
overlap은 앞뒤 문맥이 잘려 나가는 문제를 줄여줍니다. 하지만 overlap을 많이 넣으면 같은 내용이 여러 chunk에 반복되고, 검색 결과가 비슷한 조각으로 채워질 수 있습니다.
따라서 overlap은 기본값으로 크게 잡기보다 질문 유형과 문서 구조를 보면서 조정해야 합니다. 특히 FAQ, API 문서, 코드 문서는 문단 경계가 더 중요할 때가 많습니다.
표와 코드는 그대로 자르면 위험하다
표는 헤더와 행이 함께 있어야 의미가 살아납니다. 코드도 함수 이름, 매개변수, 설명 주석이 함께 있어야 검색 결과로 쓸 수 있습니다. 표 중간이나 코드 블록 중간에서 잘라 버리면 검색은 됐는데 답변에는 쓸 수 없는 조각이 됩니다.
- 표는 헤더를 각 chunk에 함께 보존한다
- 코드는 함수나 클래스 단위로 분할한다
- 긴 코드에는 파일 경로와 심볼 이름을 metadata로 남긴다
- 이미지 기반 문서는 OCR 품질을 별도로 검토한다
검색 결과와 답변 결과를 따로 평가한다
RAG 품질이 낮을 때 곧바로 프롬프트를 고치면 원인을 놓칠 수 있습니다. 먼저 검색 결과가 맞는 문서를 가져왔는지 봐야 합니다. 검색이 틀렸다면 청킹, embedding, metadata, reranking 문제입니다.
검색 결과는 맞는데 답변이 틀렸다면 context packing, 프롬프트, 출처 인용, 모델 선택을 봐야 합니다.
실무 체크리스트
- 문서 종류별로 chunk 전략을 다르게 잡았는가
- 제목 계층과 metadata를 함께 저장했는가
- 표와 코드 블록을 중간에서 끊지 않았는가
- overlap이 검색 결과를 중복으로 채우지 않는가
- 검색 품질과 답변 품질을 분리해 평가했는가
검색 의도별로 읽는 법
- RAG 입문자는 chunk size가 작거나 클 때의 차이부터 봅니다.
- 검색 결과가 자꾸 빗나간다면 문단, 제목 계층, metadata 섹션을 먼저 점검합니다.
- 표와 코드 문서가 많다면 해당 섹션의 분할 기준을 별도로 적용합니다.
자주 묻는 질문
RAG chunk size는 몇 토큰이 정답인가요?
고정된 정답은 없습니다. 문서 종류, 질문 길이, 모델 context, 검색 방식에 따라 달라집니다. 기본값보다 평가셋으로 비교하는 과정이 중요합니다.
overlap은 많이 넣을수록 좋은가요?
아닙니다. overlap이 많으면 맥락 보존에는 도움이 되지만 중복 검색과 비용 증가가 생깁니다.
청킹보다 embedding 모델이 더 중요한가요?
둘 다 중요합니다. 다만 문서가 엉뚱하게 잘려 있으면 좋은 embedding 모델도 필요한 맥락을 찾기 어렵습니다.
마지막 점검 체크리스트
- 고정 길이 분할만 쓰고 있지 않은가
- 제목과 문단 경계를 metadata로 보존했는가
- 표와 코드가 의미 단위로 유지되는가
- 검색 top-k에 비슷한 chunk만 반복되지 않는가
- 실패 질문을 모아 chunk 전략을 비교했는가
정리
RAG 청킹를 제대로 보려면 하나의 정답을 외우기보다 글에서 정리한 기준을 실제 상황에 대입해야 합니다. 핵심은 RAG에서 답변 품질이 흔들릴 때 chunk size와 문서 분할 기준을 점검하는 것입니다.
관련 글로는 RAG 검색 품질은 왜 흔들릴까, RAG context packing이 중요한 이유, Vector DB는 언제 필요할까을 함께 보면 좋습니다. 외부 기준은 Retrieval-Augmented Generation paper, OpenAI File Search guide, LlamaIndex node parsers을 확인했습니다.
