Lotook
RAG를 위해 문서를 효과적으로 청크로 나누려면 먼저 기존 문서 구조를 따라 파일을 분할하고, 지나치게 큰 섹션에는 문장 단위 중복을 두면서 토큰 길이 상한을 적용한 다음, 모든 지문에 출처 메타데이터를 붙입니다. 토큰 기반, 의미 기반, 구조 기반 청크 분할 중 어떤 방식을 선택할지는 코퍼스가 균일한 산문, 변화하는 주제, 서식이 있는 표와 제목 중 무엇으로 구성되는지에 달려 있습니다.
RAG 청크 분할이 검색 품질을 결정하는 이유는 무엇인가요?
Retrieval-Augmented Generation(RAG)은 원본 문서를 더 작은 지문으로 나눈 뒤 임베딩하고 검색 인덱스에 저장합니다. 질의 시 시스템은 가장 관련성이 높은 청크를 검색해 사용자의 질문과 함께 언어 모델에 전달합니다. 문서 전체는 보통 특정 질문과 정확히 일치하기에는 범위가 너무 넓고 다른 후보와 함께 모델의 컨텍스트 윈도에 들어가기에는 너무 크기 때문에 청크 분할이 검색 단위를 결정합니다.
Patrick Lewis와 동료들이 2020년 NeurIPS 논문(Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks)에서 이 프레임워크를 소개했을 때, 실험에서는 각 Wikipedia 문서를 겹치지 않는 약 100단어 청크로 나누어 약 2,100만 개의 지문을 만들었습니다. 이 100단어 분할은 2020년 Wikipedia를 위한 실험 설정이었으며 2026년 운영 환경의 기본값은 아닙니다. 2026년 11월 기준 현대적인 운영 환경의 RAG는 대개 원래의 종단 간 미분 가능한 DPR과 BART 구성 대신 모듈식 엔지니어링 파이프라인(청크 분할, 임베딩, 인덱싱, 검색, 생성)으로 실행됩니다.
RAG 청크 분할의 세 가지 주요 방법은 무엇인가요?
RAG 청크 분할 방법은 토큰 기반 분할, 의미 기반 분할, 구조 기반 분할의 세 가지 계열로 나뉩니다. 각 계열은 길이, 의미 또는 문서 마크업을 이용해 지문의 시작과 끝을 결정합니다.
| 청크 분할 방법 | 분할 기준 | 가장 적합한 대상 | 주요 위험 | 인덱싱 비용 |
|---|---|---|---|---|
| 토큰(또는 길이) 기반 분할 | 이동하는 중복을 둔 고정 토큰 또는 문자 윈도 | 균일한 산문, 일반 텍스트 또는 구조 분할 후 길이 제한 | 문장, 표의 행, 코드 블록 또는 정의를 중간에서 자름 | 낮음 |
| 의미 기반 분할 | 인접한 문장 사이의 임베딩 유사도 감소 | 제목 없이 문서 중간에 주제가 바뀌는 서식 없는 산문 | 인덱싱이 느리고 비용이 높으며 청크 크기가 고르지 않음 | 높음 |
| 구조 기반 분할 | 제목, 문단, 목록, 표, 코드 블록 또는 페이지 | Markdown, HTML, API 문서, 법률 조항 및 구조화된 매뉴얼 | 스캔한 PDF의 구조가 불명확하고 개별 섹션이 매우 클 수 있음 | 낮음~중간 |
1. 토큰 및 문자 기반 청크 분할
토큰 기반 분할은 텍스트를 토큰 또는 문자로 측정한 고정 길이 윈도로 나누며, 흔히 이동하는 중복을 함께 사용합니다. 토큰으로 측정하는 것은 모델의 작동 방식에 부합합니다. 임베딩 모델과 LLM에는 엄격한 토큰 제한이 있고 API 요금은 토큰 단위로 책정되며, 같은 문단도 모델 계열에 따라 다르게 토큰화될 수 있습니다. 문자 수는 대략적인 대용치일 뿐입니다.
팀은 보통 임베딩 모델의 제한에 들어가는 윈도 크기에서 시작하고(튜토리얼은 흔히 수백 토큰에서 시작합니다) 검색 실패를 확인한 뒤 조정합니다. 고정 윈도의 주요 위험은 구문과 레이아웃을 무시해 문장, 표의 행, 코드 블록 또는 정의를 가로질러 자르고 질문에 답하는 절을 빠뜨리는 것입니다.
2. 의미 기반 청크 분할
의미 기반 분할은 고정된 토큰 수가 아니라 인접 문장의 임베딩 유사도가 떨어지거나 담화 경계가 나타나는 등 의미가 바뀌는 지점에서 텍스트를 나눕니다. 문서 중간에 제목 없이 주제가 바뀔 때 하나의 완전한 생각을 한 청크에 유지하면 검색에 도움이 됩니다.
하지만 분할 자체에 임베딩 호출이 필요할 수 있으므로 의미 기반 분할은 인덱싱이 느리고 비용이 더 듭니다. 노이즈가 많은 유사도 임계값은 텍스트를 지나치게 많이 또는 적게 나누어 크기를 고르지 않게 만들 수도 있으며, 문장 유사도가 표, 양식 또는 코드에 자동으로 더 적합한 것은 아닙니다.
3. 구조 기반 청크 분할
구조 기반 분할은 기존 문서 구조를 첫 분할 기준으로 사용합니다. Markdown 또는 HTML 제목, 문단, 목록, 섹션, 페이지, 구분자로 둘러싼 코드 블록 또는 표의 경계가 그 대상입니다. AWS Prescriptive Guidance의 RAG 안내에서 설명하듯 문서 구조를 보존하면 논리적으로 관련된 컨텍스트를 온전히 유지할 수 있습니다. 환불 정책 제목에서 시작해 전체 섹션을 포함하는 청크는 문장 중간에서 시작하는 윈도보다 검색하고 인용하기 쉽습니다.
많은 PDF와 스캔 문서에는 명확한 제목이 없고 하나의 제목이 20페이지에 걸칠 수도 있으므로 운영 파이프라인은 보통 여러 방법을 결합합니다.
- 먼저 구조에 따라 계층적으로 분할합니다: 문서를 섹션 또는 제목으로 나눈 다음 문단 또는 블록으로 나누되 코드 블록, 표, 목록은 온전히 유지합니다.
- 다음으로 토큰 길이 상한을 적용합니다: 섹션이 여전히 너무 크면 토큰 윈도로 해당 섹션을 분할합니다.
- 비구조화 텍스트에는 대체 분할을 사용합니다: 스캔한 PDF나 긴 비구조화 섹션에는 페이지 분할, 토큰 윈도 또는 의미 경계를 사용합니다.
청크 중복과 RAG 메타데이터는 어떻게 설정해야 하나요?
청크 중복과 지문 메타데이터는 경계에 있는 절이 누락되는 것을 방지하고 검색된 발췌문을 원본 문서에 연결합니다.
청크 중복 설정하기
청크 중복은 한 청크의 끝을 다음 청크의 시작에 반복해 경계에 있는 문장이나 정의가 검색된 지문 중 적어도 하나에는 완전하게 나타나도록 합니다. 고정 윈도나 대체 분할이 생각의 중간을 자를 때 간단한 대비책이 됩니다.
코퍼스의 일반적인 문장 한두 개를 포함하도록 중복 크기를 정하되 거의 같은 청크를 두 번 저장하지 않을 만큼 작게 유지합니다. 중복은 임베딩, 저장, 검색할 토큰을 늘려 인덱스 크기를 키우고 결과에 거의 중복되는 이웃 항목을 추가합니다. 검색 결과에 거의 같은 청크가 자주 반환되면 중복이나 청크 크기를 줄이거나 검색 후 중복 제거 단계를 추가합니다.
RAG 메타데이터 추가하기
RAG 메타데이터는 각 청크와 함께 저장되는 구조화된 필드로, 다음을 포함합니다.
- 원본 문서 ID 또는 URL과 제목
- 섹션 또는 제목 경로와 페이지 번호
- 생성일 또는 수정일과 문서 유형(정책, 티켓, API 참조 문서)
- 접근 및 권한 라벨, 언어, 안정적인 청크 ID
원시 ID나 타임스탬프가 유사도를 오염시킬 경우 팀은 메타데이터를 임베딩에서 제외할 수 있습니다. 검색에 도움이 되는 경우에는 선택한 필드(예: 섹션 제목)를 임베딩할 텍스트 앞에 붙일 수도 있습니다. 메타데이터는 운영 환경의 세 가지 요구를 지원합니다.
- 인용: UI나 모델이 단순한 지문 대신 파일, 제목, 페이지 번호를 인용할 수 있습니다.
- 권한 및 버전 필터: 최신 정책 버전, 특정 제품 또는 사용자가 볼 권한이 있는 문서만 검색합니다. 비공개 문서를 필터링되지 않은 RAG 인덱스에 넣으면 시스템에 질의할 수 있는 누구에게나 노출되므로 권한은 프롬프트뿐 아니라 인덱스 필터에 적용해야 합니다.
- 디버깅 및 업데이트: 원본 문서가 변경되면 해당 문서를 다시 청크로 나누고 임베딩하며 오래된 청크 ID를 폐기해 낡은 사실이 사실 오류를 일으키지 않도록 합니다.
청크가 너무 크거나 작은지 어떻게 알 수 있나요?
실제 사용자 질문에 대해 검색된 청크를 살펴보면 지문이 지나치게 크거나 단편화되어 있는지 알 수 있습니다.
청크가 너무 크다는 징후
- 묻힌 답변: 검색 결과가 질의어는 언급하지만 실제 답변은 묻혀 있는 긴 섹션을 반환해 모델이 답을 찾아야 하거나 놓칩니다.
- 혼잡한 프롬프트: 프롬프트에 몇 개의 청크만 들어가므로 평범한 일치 항목 하나가 더 좋은 항목을 밀어냅니다.
- 높아진 비용과 지연: 관련 없는 토큰을 많이 보내면 지출과 응답 시간이 늘어납니다.
- 심해진 주의 분산: 추가 노이즈는 context rot을 악화시킵니다. 모델이 큰 프롬프트에 올바른 사실을 가지고도 학습 기억이나 인접한 잘못된 문장에 의존하는 현상입니다.
청크가 너무 작다는 징후
- 맥락 없는 단편: 검색된 청크를 앞 문장 없이는 이해할 수 없습니다(예를 들어 규칙은 밝히지 않고 기업용 요금제의 예외만 언급하는 문장).
- 여러 단계로 된 답변의 분리: 정의와 예외, 함수와 매개변수, 정책과 시행일이 서로 다른 청크에 들어가고 top-k는 한 부분만 반환합니다.
- 거의 같은 단편: 반복되는 발췌문을 많이 검색해도 완전한 생각은 얻지 못하고, 문장마다 별도 출처가 되어 인용도 복잡해집니다.
실용적으로 크기를 조정하려면 실제 질문을 검토하고 검색된 청크를 살펴본 뒤, 그 지문만 받은 사람이 답할 수 있는지 물어봅니다. 필요한 문장이 검색되지 않은 이웃 청크에 있다면 중복, 구조 규칙 또는 크기를 조정합니다. 필요한 문장이 검색된 청크 안에서 관련 없는 텍스트에 둘러싸여 있다면 더 작게 나누거나 더 좁은 범위의 청크를 더 적게 검색합니다.
RAG 청크 분할은 context rot에 어떤 영향을 주나요?
RAG 청크 분할은 context rot에 대응하는 직접적인 수단입니다. 이는 프롬프트가 길어지거나 복잡해질수록, 알려진 컨텍스트 한도보다 훨씬 낮은 수준에서도 모델의 추론 품질, 지시 이행 및 정보 회상이 저하되는 현상입니다.
RAG는 전체 코퍼스를 프롬프트에 넣지 않도록 하기 위해 존재합니다. 하지만 너무 큰 청크를 검색하거나 안전을 위해 top-k를 높이고 어렴풋이 비슷한 청크를 많이 프롬프트에 채워 넣으면 길고 노이즈가 많은 컨텍스트가 다시 만들어집니다. 컨텍스트가 많다고 자동으로 더 정확해지는 것은 아닙니다. 청크의 범위를 좁히면 프롬프트의 혼잡이 줄지만, 좋은 청크 분할만으로는 나쁜 임베딩 모델을 고치거나 모델이 검색된 텍스트를 무시할 때 AI 환각을 없앨 수 없습니다.
FAQ
RAG 청크 크기는 토큰과 문자 중 무엇으로 측정해야 하나요?
가능하면 RAG 청크 크기를 토큰으로 측정하세요. 임베딩 모델과 언어 모델은 토큰 단위로 컨텍스트 제한을 적용하고 API 사용량도 토큰당 과금됩니다. 같은 문단도 언어, 코드 블록, 모델 계열에 따라 서로 다른 수의 토큰으로 나뉠 수 있으므로 문자 수는 대략적인 대용치일 뿐입니다. 임베딩 모델의 토크나이저를 사용하면 인덱싱 중 예상치 못한 잘림을 방지할 수 있습니다.
의미 기반 분할은 항상 토큰 기반 분할보다 낫나요?
의미 기반 분할이 토큰 또는 구조 기반 분할보다 자동으로 더 나은 것은 아닙니다. 문장 유사도가 떨어질 때 분할하면 비구조화 산문에서 생각을 함께 유지하는 데 도움이 되지만, 인덱싱 중 추가 임베딩 작업이 필요하고 청크 크기가 고르지 않으며 노이즈가 많은 임계값에서 너무 많이 또는 적게 분할할 수 있습니다. 서식이 있는 문서는 제목, 표, 코드 블록을 따라 나누는 편이 더 빠르고 작성자가 의도한 경계를 따릅니다.
RAG를 위해 표와 코드 블록은 어떻게 나눠야 하나요?
표, 송장, 법률 조항, 코드에는 블록을 온전히 유지하는 구조 기반 규칙이 필요합니다. Markdown 표나 함수 본문을 단순히 문자 또는 토큰으로 가로질러 분할하면 값이 열 제목과 분리되거나 구문이 깨져 사용할 수 없는 청크가 만들어집니다. 가능하면 코드 블록, 표, 목록을 통째로 유지하고 단일 블록이 모델 제한을 넘을 때만 구조 기반 대체 방법을 적용하세요.
메타데이터를 청크 임베딩에 포함해야 하나요?
메타데이터를 임베딩할 텍스트에 포함할지는 필드에 따라 달라지는 설계 선택입니다. 문단이 맥락을 제목에 의존할 때 문서 제목이나 섹션 제목 경로를 청크 텍스트 앞에 붙이면 검색에 도움이 되는 경우가 많습니다. 원시 식별자, 타임스탬프, 접근 라벨은 임베딩 유사도를 오염시키지 않도록 별도의 필터 가능한 메타데이터 필드에 보관해야 합니다.
원본 문서가 변경되면 어떻게 되나요?
원본 문서가 변경되면 수집 파이프라인은 해당 문서를 다시 청크로 나누어 임베딩하고 인덱스에서 기존 청크 ID를 폐기해야 합니다. 오래된 청크를 업데이트된 청크와 함께 활성 상태로 두면 검색기가 낡은 정책이나 상충하는 지문을 제시하여 인덱스 관리상의 누락이 최종 답변의 사실 오류로 이어집니다.
