축적(chunking)이 검색 품질, 임베딩 성능, 그리고 검색 강화 생성(RAG) 시스템의 전반적인 효과에 어떤 영향을 미치는지 배우세요.
서론
검색 강화 생성(RAG)를 사용하여 AI 애플리케이션을 개발할 때 개발자들은 종종 최고의 LLM 또는 임베딩 모델을 선택하는 데 집중합니다. 하지만 하나의 기초 단계는 자주 과소평가됩니다축소
축소
축소는 대량의 문서를 임베딩 생성 및 벡터 데이터베이스에 저장하기 전에 더 작고 관리하기 쉬운 조각으로 나누는 과정입니다.
나쁜 축소는 다음과 같은 문제를 일으킬 수 있습니다.
- 관련 없는 검색 결과
- 허구된 답변
- 문맥 누락
- 높은 추론 비용
좋은 청킹은 반대로 검색 정확도와 응답 품질을 혁신적으로 향상시킵니다.
이 기사에서 우리는 가장 일반적인 청킹 전략과 그들의 트레이드오프와 각각을 사용할 때를 탐구할 것입니다.
청킹이 중요한 이유
LLMs과 임베딩 모델은 무한히 큰 문서를 효율적으로 처리할 수 없습니다.
200페이지짜리 PDF를 고려해보세요.
전체 파일을 하나의 벡터로 포함시키는 대신, 작은 조각으로 나눕니다:
Large Document
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
Semantic Retrieval
↓
LLM Response
조각 나누기 없이
하나의 거대한 임베딩:
- 의미적 세분성을 잃어버립니다
- 무관련 섹션을 검색합니다
- 토큰 비용을 증가시킵니다
Chunking을 사용하여
관련 문서 섹션은 검색 및 검색할 수 있습니다.
Chunking의 트레이드오프를 이해합니다.
Chunk 크기는 검색 품질에 영향을 미칩니다.
Missing context
너무 큼:
Noise + irrelevant information
이상적인 청크 균형:
- 의미론적 의미
- 검색 정확도
- 토큰 효율성
1. 고정 크기 청크 분할
가장 간단하고 널리 사용되는 방법.
문서는 고정된 문자 또는 토큰 한도에 따라 분할됩니다.
예시:
- 500 토큰
- 1000자 문자
작동 방식
Document
──────────────────────────
Chunk 1 (500 tokens)
Chunk 2 (500 tokens)
Chunk 3 (500 tokens)
파이썬 예제
LangChain 사용하기:
from langchain.text_splitter import CharacterTextSplitter
splitter = CharacterTextSplitter(
chunk_size=500,
chunk_overlap=50
)
chunks = splitter.split_text(document)
장점
- 구현하기 쉽다
- 빠른 처리
- 예측 가능한 청크 크기
단점
- 문서 구조 무시
- 문장 중간에서 잘림
- 의미론적 의미 감소
최적 적용 사례
- 빠른 프로토타입
- 작은 데이터 세트
- 간단한 RAG 시스템
2. 재귀 청크 분할
크기가 고정된 청크 처리의 더 현명한 버전입니다.
맹목적으로 나누는 대신 구조를 보존하려고 시도합니다.
보통 계층 구조:
- 단락
- 문장
- 단어
더 큰 섹션이 크기 제한을 초과할 때만 추가로 나눕니다.
워크플로우
Paragraph too large?
↓
Split into sentences
↓
Sentence too large?
↓
Split into words
예시
LangChain 재귀 분할기:
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50
)
chunks = splitter.split_text(document)
장점
- 의미를 보존
- 더 나은 검색 품질
- 혼합 문서 처리
단점
- 약간 느림
- 여전히 도메인 특정 구조를 무시할 수 있습니다
최고의 대상
대부분의 RAG 시스템입니다.
이것은 종종 기본 추천입니다.
3. 문장 기반 청킹
이 전략은 청킹을 문장 경계와 정렬합니다.
임의의 토큰 수 대신:
Chunk = Complete Sentences
예시
문서:
AI systems rely on retrieval.
Chunking improves retrieval quality.
Poor chunking hurts accuracy.
가능한 조각들:
Chunk 1:
AI systems rely on retrieval.
Chunk 2:
Chunking improves retrieval quality.
Chunk 3:
Poor chunking hurts accuracy.
파이썬 예시
NLTK를 사용하여:
import nltk
from nltk.tokenize import sent_tokenize
sentences = sent_tokenize(document)
장점
- 자연어 경계
- 더 깨끗한 임베딩
- 개선된 의미적 일관성
단점
- 불균일한 청크 크기
- 긴 문장은 제한을 초과할 수 있음
최적 대상
- 대화 데이터
- 기사
- QA 시스템
4. 문단 기반 청크 분할
문단은 일반적으로 일관된 아이디어를 포함합니다.
이는 그들을 유용한 청크 경계로 만듭니다.
예시
Paragraph 1 → Chunk 1
Paragraph 2 → Chunk 2
Paragraph 3 → Chunk 3
장점
- 높은 의미적 일관성
- 인간이 읽을 수 있는 조각
- 블로그와 문서에 잘 작동합니다
단점
- 단락 길이가 다릅니다
- 큰 단락은 오버플로우할 수 있습니다
최적 대상
- 블로그
- 문서화
- 연구 논문
5. 겹치는 조각 분할
조각 분할의 주요 문제:
경계에서의 맥락 손실.
예시:
파트 1:
The API authentication uses JWT...
파트 2:
...tokens for secure communication.
중요한 의미는 두 파트 모두에 걸쳐 있습니다.
겹침이 이 문제를 해결합니다.
겹침은 어떻게 작동하나요
Chunk 1
──────────────
AAAA BBBB CCCC
Chunk 2
CCCC DDDD EEEE
알림:
CCCC
두 조각 모두에 나타납니다.
코드 예제
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=100
)
장점
- 더 나은 검색 연속성
- 경계 문제 감소
- 더 높은 답변 정확도
단점
- 더 많은 임베딩
- 더 큰 벡터 저장 공간
- 높아진 검색 비용
최적 대상
대부분의 생산용 RAG 시스템
보통 겹침율:
- 10–20%
6. 의미론적 청크링크
의미론적 청크링크는 크기 대신 의미를 사용합니다.
문서는 주제가 변경될 때 분할됩니다.
이는 훨씬 더 지능적입니다.
개념
대신에:
Every 500 tokens
우리는 다음을 기준으로 분할합니다:
Meaning shift
예시
문서:
Section A → Databases
Section B → Kubernetes
Section C → Security
의미적 청크 처리는 다음을 생성합니다:
Chunk 1 → Database topic
Chunk 2 → Kubernetes topic
Chunk 3 → Security topic
고수준 파이프라인
Text
↓
Sentence embeddings
↓
Similarity comparison
↓
Topic boundary detection
↓
Chunks
파이썬 예제 (개념적)
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity
문장 유사도가 분할 위치를 결정합니다.
장점
- 우수한 검색 품질
- 주제 인식
- 강력한 맥락 관련성
단점
- 계산 비용이 많이 듭니다.
- 더 많은 구현 노력이 필요합니다.
최고로 적합한 것은
- 기업 검색
- 법률 문서
- 지식 베이스
7. 구조 인식 청크 분할
일부 문서에는 이미 구조가 포함되어 있습니다.
예시:
- HTML 헤딩
- 마크다운 섹션
- 제목이 있는 PDF
- 코드 파일
이를 무시하는 대신 이를 사용합니다.
예시
마크다운:
# Authentication
JWT details...
# Rate Limiting
API throttling...
충분히:
Authentication section
Rate Limiting section
코드 예제
Markdown 헤더 스플리터:
from langchain.text_splitter import MarkdownHeaderTextSplitter
headers = [
("#", "Header1"),
("##", "Header2")
]
장점
- 높은 의미적 일관성
- 작성자 의도 사용
- 문서화에 탁월함
단점
- 깨끗한 형식에 의존
- 원시 텍스트에는 덜 효과적
최적 대상
- 개발자 문서
- 위키
- 기술 문서
8. 코드 청킹
소스 코드는 특별한 처리가 필요합니다.
500자마다 나누면 논리가 깨질 수 있습니다.
대신:
다음과 같이 나눕니다:
- 함수
- 클래스
- 모듈
- AST 노드
나쁜 청킹
def login():
...
중간에 잘라내기.
더 나은 청크
Entire login() function
Tree-sitter를 사용한 예제
import tree_sitter
AST 기반 파싱은 구문을 보존합니다.
장점
- 논리적 구조 유지
- 코드 검색 향상
- AI 코드 보조 도구에 강함
단점
- 언어별 도구
최적 대상
- 코드 코파일롯
- 저장소 검색
- 소프트웨어 문서화
청크 전략 비교
| 전략 | 품질 | 복잡성 | 최적 사용 |
|---|---|---|---|
| 고정 크기 | 낮음 | 낮음 | 프로토타입 |
| 재귀적 | 높음 | 낮음 | 일반 RAG |
| 문장 | 미디엄 | 낮음 | QA |
| 단락 | 미디엄 | 낮음 | 기사 |
| 겹침 | 높음 | 낮음 | 생산 RAG |
| 의미론적 | 매우 높음 | 높음 | 기업 |
| 구조 인식 | 높음 | 중간 | 문서 |
| 코드 청킹 | 매우 높음 | 높음 | 코드 AI |
실용적인 청킹 전략
많은 성공적인 RAG 시스템은 혼합 접근 방식을 사용합니다.
예시:
Structure-aware
+
Recursive splitting
+
10–20% overlap
파이프라인:
Document
↓
Heading Split
↓
Recursive Chunking
↓
Overlap
↓
Embeddings
↓
Vector DB
이는 일반적으로 다음 사이의 최선의 균형을 제공합니다:
- 관련성
- 비용
- 간단함
마지막 생각
청크링은 단순한 사전 처리가 아닙니다.
이 직접적으로 영향을 미칩니다:
- 검색 정확도
- 임베딩 품질
- 허구율
- 사용자 경험
유니버설한 최고 전략은 없습니다.
좋은 규칙:
- 재귀 + 겹침으로 시작합니다.
- 의미적 또는 구조 인지 청크링으로 이동합니다. 복잡성이 증가함에 따라
- 코드 인식 청킹을 사용하여 엔지니어링 시스템에 적용하세요
많은 경우, 청킹을 개선하는 것이 더 큰 LLM으로 전환하는 것보다 더 큰 이점을 제공합니다