이득:
- 청크 크기, 중첩 및 의미론적 청킹 트레이드오프를 수치적으로 평가합니다.
- 다양한 문서 유형(PDF, 테이블, 코드, 채팅 로그)에 적합한 청크 전략 선택
- 각 청크에 메타데이터를 추가하여 검색 품질 및 필터링을 강화합니다.
RAG에서 가장 간과되지만 가장 결정적인 단계는 바로 문서를 분류하는 방법입니다. 이것을 청킹이라고 합니다. 동일한 문서를 동일한 모델에 제공하더라도 잘못된 청킹으로 인해 검색 시 잘못된 조각이 반환되고 모델은 결코 좋은 답변을 생성하지 않습니다. 이 단원에서는 조각화 전략, 문서 유형에 따라 이를 적용하는 방법, 각 조각에 의미 있는 메타데이터를 추가하는 방법을 다룹니다.
우리는 왜 파쇄하는가?
세 가지 이유가 있습니다. 첫째, 임베딩 모델은 특정 길이까지의 텍스트를 의미 있는 벡터로 변환합니다. 40페이지 분량의 장 전체를 하나의 벡터로 밀어넣으면 의미가 "흐릿해진다". 둘째, 우리는 컨텍스트로 필요한 부분만 모델에 제공하고 싶습니다. 전체 문서를 전달하는 것은 비용이 많이 들고 주의가 산만해집니다. 셋째, 검색이 정확하려면 검색 단위가 작고 집중적이어야 합니다.
따라서 청크는 검색의 가장 작은 단위입니다. 너무 크거나 너무 작아서는 안 됩니다. 딱 맞습니다.
청크 크기 및 오버랩 밸런스
두 가지 주요 설정이 있습니다: 청크 크기(청크에 포함될 토큰/단어 수)와 겹침(인접 청크가 공유하는 부분).
매우 작은 청크(예: 토큰 100개): 초점이 맞춰져 있지만 컨텍스트와 연결이 끊어져 있습니다. "14일 동안"이라고 했는데 앞 문장에는 14일이 남았네요. 매우 큰 청크(예: 토큰 2000개): 컨텍스트를 유지하지만 많은 스레드가 혼합되어 있습니다. 임베딩이 혼란스러워지고 관련 없는 주제가 모이게 됩니다.
중첩은 경계 문제를 해결합니다. 문장이 정확히 두 부분의 경계에 있으면 겹치지 않고 두 부분으로 나누어져 의미가 상실됩니다. 50~100개의 토큰을 겹치면 한도 내에 속하는 정보가 적어도 한 부분에서 그대로 유지됩니다.
청크 크기
장점
단점
적절한 내용
소형(토큰 100-250개)
고감도, 집중
컨텍스트가 깨질 수 있음
FAQ, 짧은 기사, 정의
중간(토큰 300-600개)
균형; 대부분의 시나리오
—
절차, 정책 텍스트
대형(800-1500토큰)
컨텍스트 무결성
흐릿한 임베딩
내러티브, 긴 설명
팁: 어디서부터 시작해야 할지 모르겠다면 400-500 토큰 청크와 50-80 토큰 중복으로 시작하세요. 그런 다음 자신의 데이터로 측정하고 조정하세요. "올바른" 크기는 보편적이지 않으며 상황에 따라 다릅니다.
청킹 전략
고정 크기: N 토큰마다 텍스트를 자릅니다. 간단하고 빠르지만 문장 중간에 중단될 수 있습니다.
구분자 기반(재귀적/구분자): 단락과 문장 경계에 따라 구분합니다. 의미의 무결성을 더 잘 보존합니다. 대부분의 생산 시스템은 이것으로 시작됩니다.
의미적 청킹: 문장의 임베딩을 살펴보고 주어 변경이 발생하는 위치를 나눕니다. 이는 최고 품질이지만 가장 비용이 많이 드는 방법입니다. 거래량이 많을수록 거래 비용이 증가합니다.
구조 인식: 제목, 섹션, 표와 같은 문서 구조를 사용합니다. 예를 들어 Markdown 문서를 제목별로 분할하면 각 부분에 고유한 제목이 포함됩니다.
문서 유형별 조정
모든 문서가 동일한 것은 아닙니다. 전략은 유형에 따라 다릅니다.
- PDF/정책 텍스트: 북마크 기반, 중간 크기. 페이지 상단/하단 반복(머리글/바닥글)을 지웁니다.
- 테이블: 문맥에서 벗어나지 마십시오. 각 행에 헤더 정보("품목: X, 가격: Y, 재고: Z")를 유지합니다. 원시 테이블을 일반 텍스트로 변환하는 것이 필수적인 경우가 많습니다.
- 코드: 함수/클래스 경계로 분할됩니다. 방해가 되는 기능을 중단하지 마세요.
- 채팅/티켓 녹음: 메시지 또는 대화 라운드별로 분할됩니다. 누가 무엇을 말했는지에 대한 지식을 유지하세요.
# 괄호 기반 청크(개념적) Chuns = bol( text, target_size=450, # tokenoverlap=70, # token Brackets=["\n\n", "\n", ". ", " "] # 단락 먼저, 단어 마지막)
각 트랙에 메타데이터 추가
청킹은 단순한 "분할"이 아닙니다. 각 부분을 풍성하게 만드는 것입니다. 트랙에 첨부하는 모든 태그는 향후 필터링 및 출처 인용을 위해 금만큼의 가치가 있습니다.
# 강화된 청크(개념){ "text": "연간 유급 휴가는 14일이며 1~5년의 근속 기간은...", "metadata": { "source": "ik_el_kitabi_v7.pdf", "section": "5.2 연차 휴가", "page": 23, "date": "2025-06", "department": "IK", "privacy": "internal" }}
또 다른 강력한 기술은 상황에 맞는 헤더를 추가하는 것입니다. 즉, 각 작품의 시작 부분에 해당 장의 제목을 적는 것입니다. 따라서 "14일 동안"과 같이 단절된 작품이라도 "연차 휴가 - 14일"이 더 잘 삽입되고 더 의미가 있습니다.
약한 청킹 / 강한 청킹
약함(블라인드 하드컷, 메타데이터 없음):
1000자마다 텍스트를 자릅니다. 텍스트만 유지합니다.# 결과: 테이블이 중간에 분할되고 "14일"이 컨텍스트 없이 남습니다.# 어느 문서에서 왔는지 알 수 없으며 필터를 만들 수 없습니다.
강력함(구조 인식 + 헤더 + 메타데이터):
문서를 제목별로 나누십시오. 각 부분에 섹션 제목을 추가하고 소스, 페이지, 날짜 및 개인정보 메타데이터를 첨부합니다. 표 행을 헤더와 함께 일반 텍스트로 변환합니다.# 결과: 집중형, 상황별, 필터링 가능, 소스 가능.
미니 케이스 3개
사례 1 - 회화 재해. 재무팀은 200페이지에 달하는 가격표를 블라인드 하드커팅으로 나누었습니다. 테이블 행이 무작위로 분할되었습니다. "제품 X의 가격은 얼마입니까?" 모델이 잘못된 행을 읽고 잘못된 가격을 제시했습니다(12개 중 9개가 틀렸습니다). 테이블 행을 "제품: … | 가격: … | 단위: …" 형식의 일반 텍스트로 변환하면 오류가 12개 중 0개로 감소했습니다.
사례 2 - 매우 큰 덩어리. Wiki에서 각 페이지는 단일 청크로 구성됩니다(일부에서는 3,000개의 토큰이라고도 함). 한 페이지에 "휴가", "초과 근무", "급여"가 있기 때문에 임베딩이 흐릿합니다. 휴가 문제와 관련하여 근무 시간 섹션도 작동했습니다. 페이지를 제목별로 중간 크기로 나누었을 때, Recall@5는 64%에서 91%로 증가했습니다.
사례 3 — 겹치지 않고 잘린 문장. 법무팀을 위한 250개의 토큰 고정 컷, 중복 없음. 중요한 정의는 두 부분의 경계에 바로 위치하여 두 부분으로 나누어졌습니다. 어느 쪽도 완전한 답을 담고 있지 않습니다. 60개의 토큰 중첩이 추가되었을 때 동일한 정의가 한 조각에 그대로 남아 정답이 반환되었습니다.
일반적인 실수
- 블라인드 고정 컷: 문장과 표를 중간에 분할합니다. 의미가 사라집니다.
- 겹치는 부분을 0으로 두기: 경계에 있는 정보는 분할되어 손실됩니다.
- 메타데이터를 추가하지 않음: 필터링 및 소스 표시가 불가능해집니다.
- 테이블을 원시 상태로 유지: 모델이 테이블 구조를 확인할 수 없습니다. 줄을 일반 텍스트로 변환합니다.
- 하나의 전략 부과: PDF, 코드 및 테이블이 동일한 방법으로 분할되지 않습니다. 장르에 적응하세요.
주의: 청킹을 한 번 설정하고 잊어버리지 마십시오. 새로운 문서 유형(새 시스템의 티켓, 스캔한 PDF)이 도착하면 검색 품질을 다시 측정합니다. 잘못된 입력 데이터는 잘못된 응답("가비지 입력, 쓰레기 출력")을 의미합니다.
요약하면
- 청크는 검색의 가장 작은 단위입니다. 너무 크지도 작지도 않게, 내용물에 따라 균형을 맞춰야 합니다.
- 청크 크기는 포커스-컨텍스트 균형을 나타냅니다. Overlap은 경계 손실을 관리합니다.
- 브래킷 기반 및 구조 인식 청킹은 대부분의 생성 시스템의 출발점입니다. 의미론적 청킹은 품질은 좋지만 비용이 많이 듭니다.
- 테이블, 스크립트, 채팅과 같은 유형에는 고유한 전략이 필요합니다. 테이블을 일반 텍스트로 변환합니다.
- 각 트랙에 소스/날짜/챕터/개인정보 메타데이터 및 섹션 제목을 추가합니다. 이것이 필터링과 인용의 기본입니다.
응용과제
선택한 문서의 섹션을 세 가지 방법으로 나눕니다. (1) 200개 토큰의 작은 조각, (2) 500개 토큰의 중간 조각(70개 토큰 중복), (3) 단일 큰 조각. 각 전략에 대해 동일한 3가지 질문을 하고, 어떤 부분을 가져올 것인지 수동으로 표시하고, 어떤 전략이 해당 문서에 가장 적합한지에 대한 추론을 적습니다. 그런 다음 각 트랙에 최소 4개의 메타데이터 필드와 "챕터 제목"을 추가합니다. 문서에 테이블이 포함된 경우 테이블 행을 "필드:값" 형식의 일반 텍스트로 변환합니다.
체크리스트
- [ ] 청크는 검색의 가장 작은 단위이고 크기는 초점-컨텍스트 균형임을 알 수 있습니다.
- [ ] Overlap이 경계 손실을 방지하는 이유를 알고 있습니다.
- [ ] 대괄호 기반, 의미론적 청킹, 구조 인식 청킹을 구분할 수 있습니다.
- [ ] 테이블, 코드, 채팅에 전략을 적용할 수 있습니다.
- [ ] 각 트랙에 메타데이터와 챕터 제목을 추가하여 검색을 강화합니다.