단순한 청킹(Naive Chunking)을 버려라: Spring AI에서의 Late Chunking RAG

단순한 텍스트 청킹(Naive text chunking)은 임베딩 모델(Embedding model)이 텍스트를 확인하기도 전에 임의의 토큰 경계에서 문맥을 잘라버림으로써 RAG 파이프라인을 망가뜨립니다. Late Chunking은 먼저 전체 문서에 대해 긴 문맥 트랜스포머(Long-context transformer)를 실행한 다음, 완전히 문맥화된 토큰 상태(Token states)로부터 청크 벡터(Chunk vectors)를 직접 풀링(Pooling)함으로써 이러한 구조적 결함을 해결합니다.

대부분의 개발자가 실수하는 이유

• 임베딩 전에 Spring AI의 TokenTextSplitter를 사용하여 문서를 고립된 512-토큰 슬라이스로 분할함으로써, 문서 수준의 의미론(Semantics)과 문단 간 참조를 완전히 파괴합니다.
• 손실된 문맥을 복구하기 위해 무거운 LLM 문맥 요약(Contextual-summarization) 호출을 추가하거나 비대한 청크 중첩(Chunk overlaps)을 사용하여, 구조적 이득 없이 API 비용과 쿼리 지연 시간(Latency)만 증가시킵니다.
• 실제 근본 원인은 임베딩 전 경계에서의 문맥 저하(Context degradation)임에도 불구하고, 검색 성능의 원인을 벡터 데이터베이스(Vector database)의 거리 측정 방식(Distance metrics) 탓으로 돌립니다.

올바른 방법

Late Chunking은 벡터 공간을 청크 경계로 나누기 _전_에 전체 문서의 문맥을 토큰 수준의 표현(Token-level representations)으로 인코딩합니다.

• 확장된 Spring AI EmbeddingModel 파이프라인을 통해 원본 전체 길이의 문서를 긴 문맥 트랜스포머(예: 8k 토큰 윈도우를 가진 jina-embeddings-v3)에 전달합니다.
• 단일 순전파(Forward pass)를 통해 전체 문서에 대한 트랜스포머의 마지막 레이어에서 원본 문맥화된 토큰 임베딩(Contextualized token embeddings)을 추출합니다.
• 각 대상 텍스트 범위(Text span)의 토큰 오프셋 경계에 엄격하게 속하는 토큰 벡터들을 평균 풀링(Mean-pooling)하여 최종 청크 임베딩을 계산합니다.
• 다운스트림 유사도 검색(Similarity retrieval) 로직에 변경 사항 없이 문맥화된 벡터를 PgVectorStore 또는 QdrantVectorStore에 저장합니다.

코드 보기

@Service
public class LateChunkingService {
    private final LongContextEmbeddingModel embeddingModel; // 8k+ 문맥 트랜스포머를 래핑함
...

핵심 요약

• 조기 청킹 (Early chunking)은 벡터화 (vectorization) 전에 문서의 문맥을 제거하지만, 후기 청킹 (late chunking)은 먼저 전역적 의미 (global semantics)를 포착한 후 나중에 임베딩 (embeddings)을 분할합니다.
• 이를 통해 LLM 토큰 오버헤드 (token overhead)의 중복을 제거하는 동시에, 여러 페이지로 구성된 기업용 문서 전반에 걸쳐 검색 정밀도 (retrieval precision)를 획기적으로 높일 수 있습니다.
• Spring AI 구현 시 임베딩 추출 (embedding extraction) 및 풀링 (pooling) 단계만 조정하면 되며, 벡터 스토어 (vector store) 스키마는 100% 그대로 유지됩니다.

저는 시니어 역할을 준비하면서 javalld.com을 구축했습니다 — 단순한 이론이 아닌, 실행 추적 (execution traces)이 포함된 완전한 LLD 문제를 다룹니다.