Chunking vs Semantic Chunking, RAG 문서를 어떻게 나눌까요?
Chunking는 긴 문서를 검색·임베딩·모델 문맥에 맞는 작은 단위로 나누는 일반 과정입니다. Semantic Chunking는 문단, 제목, 의미 유사도나 문서 구조를 이용해 주제가 바뀌는 경계를 중심으로 나누는 방식입니다.
세 줄 요약
Chunking는 문서를 고정 크기·문자·토큰·규칙으로 나누는 전반적인 과정이고, Semantic Chunking는 제목·문단·레이아웃·의미 변화를 경계로 삼는 하위 접근입니다.
Semantic Chunking가 항상 더 나은 것은 아니며, 문서 분석·임베딩·변화 탐지 비용과 가변 청크 크기 때문에 필터·저장·평가 복잡도가 높아질 수 있습니다.
먼저 구조를 보존한 고정·규칙 기반을 기준선으로 만들고, 정답 근거 Recall·Citation Correctness·지연·비용이 실제로 개선될 때만 더 복잡한 분할을 선택해야 합니다.
Semantic Chunking는 일반 Chunking와 다른 단계일까요?
완전히 다른 단계라기보다 분할 경계를 정하는 방식 중 하나입니다. 모든 RAG 파이프라인은 문서를 저장·검색·모델 입력에 맞는 단위로 나눠야 합니다. 고정 500토큰으로 나누는 것도, 제목과 문단을 따라 나누는 것도, 문장 임베딩 사이의 유사도가 크게 떨어지는 지점을 경계로 삼는 것도 모두 Chunking입니다.
Semantic Chunking가라는 말은 의미적 일관성을 유지하려는 여러 방식을 넓게 가리킵니다. Azure AI Search의 문서 레이아웃 기반 방식은 제목·문단·표 등 구조를 읽고 의미적으로 연결된 본문을 묶습니다. 다른 구현은 인접 문장 벡터의 거리로 주제 전환을 추정합니다. 같은 이름이어도 알고리즘은 다를 수 있습니다.
구분 | 고정·규칙 기반 Chunking | Semantic Chunking |
|---|---|---|
경계 | 문자·토큰 수, 구분자, 문단 | 제목·레이아웃·주제 전환·의미 유사도 |
청크 크기 | 비교적 일정 | 문서 구조에 따라 가변적 |
구현 비용 | 낮고 재현하기 쉬움 | 레이아웃 분석·임베딩·모델 비용이 더 들 수 있음 |
주요 장점 | 대규모 처리·디버깅·버전 관리가 간단 | 제목과 근거를 같은 단위에 남길 가능성 |
주요 위험 | 주장·예외·표가 경계에서 잘릴 수 있음 | 너무 큰·작은 가변 청크, 알고리즘·모델 변경에 따른 재생성 |
청크 크기는 어떻게 정할까요?
평균적인 숫자 하나로 모든 문서를 처리하지 않습니다. 임베딩 모델의 입력 한도, 생성 모델에 전달할 전체 문맥, 검색기가 반환할 후보 수, 문서의 표·목록·제목 구조를 같이 봅니다. 청크가 너무 크면 한 벡터에 여러 주제가 섞이고, 너무 작으면 정의·조건·예외가 서로 떨어질 수 있습니다.
일반 청크에도 문단 경계를 우선하고 제목과 출처 URL을 메타데이터로 보존합니다. 그다음 최대 토큰 수를 넘을 때만 추가 분할합니다. 이 기준선은 비용이 낮고 어느 지점에서 잘렸는지 재현하기 쉽습니다.
Semantic Chunking가 더 나은 경우는 언제일까요?
표의 행과 헤더, 법령·정책의 조항과 예외, 기술 문서의 절차와 주의사항처럼 구조가 정답 의미에 직접 영향을 주는 문서에서 유리할 수 있습니다. 고정 크기가 핵심 조건을 반복해 잘라 정답 문단이 상위 후보에서 계속 누락될 때 평가할 이유가 생깁니다.
반면 짧은 FAQ, 구조가 일정한 상품 소개, 한 문단에 하나의 정의만 있는 데이터는 복잡한 Semantic Chunking으로 얻는 추가 이익이 작을 수 있습니다. 청크 개수가 늘면 임베딩·저장·회수 비용도 늘고, 필터와 권한 메타데이터 관리가 복잡해집니다. 복잡한 방식을 쓴다는 이유만으로 품질이 오르지 않습니다.
회수 품질 비교 기준
질문별로 정답을 지지하는 원문 문단과 문서 ID를 먼저 지정합니다. 정답 청크가 상위 k개 후보에 들어왔는지, 필수 조건과 예외가 같은 청크에 남았는지, 출처 URL과 제목이 보존됐는지를 봅니다. 최종 답에서는 주장과 인용된 청크가 일치하는지를 별도로 확인합니다.
평가 단계 | 지표 | 실패 해석 |
|---|---|---|
분할 | 정답 근거·조건·예외의 동일 청크 보존 | 구조를 무시한 경계에서 정보가 잘림 |
임베딩 | 질문 집합별 정답 청크 Recall@k | 적절한 청크가 있어도 벡터 표현으로 회수되지 않음 |
필터·저장 | 권한·버전·날짜 메타데이터 유지 | 정답이 없는 것이 아니라 필터로 제외됨 |
재순위화 | 정답 청크의 상위 순위와 잡음 비율 | 회수됐지만 생성 문맥에서 누락됨 |
생성·인용 | 주장-근거 일치·Citation Correctness | 청크가 있어도 모델이 과장·오해함 |
품질만이 아니라 전처리 시간, 임베딩 호출 수, 인덱스 크기, 검색 지연, 문서 갱신 시 재처리 비용을 함께 남깁니다. 평균 정확도가 조금 올라도 중요한 정책 질문의 예외가 잘린다면 운영 기준을 통과하지 못합니다.
문서 유형별로 어떻게 나눌까요?
웹 페이지는 H1·H2·H3와 문단을 우선하고 URL·제목·canonical을 메타데이터로 보존합니다. PDF는 페이지·제목·표·각주·읽기 순서를 먼저 복원해야 합니다. 스캔 문서는 OCR 오류가 구조 오류로 이어질 수 있으므로 숫자·표 헤더·서명란을 별도 검사합니다.
설명서는 절차와 주의사항을 같이 두고, 정책 문서는 시행일·대상·예외를 같은 청크에 남깁니다. 제품 카탈로그는 항목별 스키마로 저장하는 편이 텍스트 청크보다 낫을 수 있습니다. 문서 유형을 무시한 하나의 분할기가 모든 콘텐츠를 잘 처리하지는 않습니다.
기존 사이트 적용 범위
SEO 기록에는 Chunking와 Semantic Chunking의 구조 보존이 노출·클릭에 미친 영향을 남깁니다. GEO 기록에는 청크 크기가 AI 답변의 언급·인용과 맞물린 장면을 별도로 남겨 두 결과를 억지로 합치지 않습니다.
RAG 저장소를 위해 웹사이트 콘텐츠를 별도로 옮기기보다 기존 페이지의 HTML 구조를 바로잡는 편이 먼저입니다. 제목·소제목·표 헤더·출처·날짜가 렌더된 본문에 있으면 어떤 Chunking를 적용해도 원문과 정답 근거를 연결하기 쉬워집니다.
이 운영 방식은 기존 웹사이트를 유지한 채 설치해 공개 원문의 구조·렌더·메타데이터와 AI 답변의 인용을 연결해 볼 수 있게 합니다. 질문별 누락이 원문·분할·검색·생성 중 어느 단계에서 시작됐는지를 나눠, Semantic Chunking의 추가 비용을 지불할 이유가 있는지 판단할 수 있습니다.
Chunking와 Semantic Chunking 병행 운영의 실제 판단
Chunking와 Semantic Chunking 중 하나를 먼저 고르기보다 분할 기준, 구조 보존, 계산 비용 항목의 기준값을 만듭니다. 이 값이 없으면 수정 전후를 비교할 수 없고 담당자가 바뀔 때 같은 진단을 반복합니다. 영향이 큰 URL과 질문을 소수 선정한 뒤 누가 어떤 값을 언제 고쳤는지 남깁니다.
Chunking와 Semantic Chunking의 청크 크기 항목도 전체 평균만 보지 않습니다. 새로 고친 페이지, 그대로 둔 페이지와 계절성 영향을 받는 페이지를 나눠야 차이가 드러납니다. 결과가 예상과 다르면 새 페이지를 늘리기 전에 원문 부족, 기술 차단, 외부 정보와 측정 공백을 확인합니다.
참고 자료
검색·RAG 구조를 이어서 보면
Chunking와 Semantic Chunking 비교 이후의 Search OS 운영
현재 사이트에 Search OS를 연결하면 Chunking와 Semantic Chunking 비교에서 구조 보존, 계산 비용 항목을 같은 질문 묶음으로 추적할 수 있습니다. 전면 이전 없이 공개 URL과 원문을 대조하고 영향이 큰 수정부터 적용합니다.
Search OS가 내부 성과를 집계한 결과, 적용 고객사의 SEO와 AI 검색 노출은 평균 88% 이상 늘었습니다. 성과가 나온 뒤에도 Chunking와 Semantic Chunking 관련 검색 노출, AI 답변의 정확성과 인용을 계속 확인합니다. 기존 자산을 지키면서 변화가 필요한 부분만 보완해 현재 환경에서 가능한 최상의 노출 상태를 유지합니다.