Late Chunking

Late chunking은 더 작은 섹션의 임베딩을 생성하기 전에 긴 문서를 인코딩하여 주변 컨텍스트를 보존하는 문서 임베딩 기술입니다. 텍스트를 먼저 분할하고 각 청크를 독립적으로 임베딩하는 대신, 롱컨텍스트 모델을 사용하여 컨텍스트 인식 토큰 표현을 생성한 다음 각 청크에 속하는 토큰들을 별도의 벡터로 풀링(pooling)합니다. 결과 embeddings는 더 넓은 문서의 정보를 담은 채 검색에 적합한 상태를 유지합니다.

Late Chunking 작동 방식#

기존 검색 파이프라인은 일반적으로 분할, 인코딩, 저장 순서를 따릅니다. 이는 효율적이지만, 고립된 청크는 무엇을 가리키는지 명시하지 않은 채 "그 구성 요소", "이 결과" 또는 "실패함"과 같은 구문을 포함할 수 있습니다.

Late chunking은 이 순서를 변경합니다:

1. 문서는 tokens로 분할되며, 원하는 청크 경계가 기록됩니다.
2. 완전한 토큰 시퀀스 또는 모델의 context window에 맞는 가장 큰 부분이 롱컨텍스트 transformer를 통과합니다.
3. 모델의 attention mechanism을 통해 각 토큰 표현은 해당 컨텍스트 내의 다른 토큰 정보를 통합합니다.
4. 토큰 벡터는 기록된 경계에 따라 그룹화되고 결합되며, 일반적으로 평균 풀링(mean pooling)을 통해 청크당 하나의 임베딩을 생성합니다.

핵심적인 차이는 타이밍에 있습니다. 경계는 여전히 존재하지만, 컨텍스트 인코딩 이전이 아니라 이후에 적용됩니다. Jina AI explanation of late chunking은 이 두 가지 처리 순서의 시각적 비교를 제공합니다.

컨텍스트 보존이 중요한 이유#

청킹은 문서가 모델 제한에 맞도록 돕고 검색 시스템이 정확한 구절을 검색할 수 있게 합니다. Microsoft’s document chunking guidance는 하나의 벡터로 전체 대형 문서를 표현하는 것이 너무 많은 아이디어를 단일 표현으로 압축할 수 있음을 지적합니다.

그러나 더 작은 청크는 컨텍스트 손실의 위험을 증가시킵니다. 다음 인접한 구절들을 고려해 보세요:

• “XR-12 펌프는 냉각 매니폴드 옆에 설치됩니다.”
• “10,000시간 작동 후 교체해야 합니다.”

독립적으로 임베딩된 경우 두 번째 구절은 "그것(it)"이 무엇을 의미하는지 식별하지 못합니다. Late chunking을 사용하면 토큰 표현이 이미 "XR-12 펌프"에 주목했기 때문에, 이 구절은 "XR-12 펌프는 언제 교체해야 합니까?"와 같은 쿼리에 훨씬 더 유용해집니다.

Late chunking은 선택된 구절이 언어 모델에 기반 컨텍스트를 제공하는 retrieval-augmented generation과 특히 관련이 있습니다. 더 넓은 범위의 Google Cloud RAG overview는 검색이 임베딩, 벡터 검색, 기반 생성(grounded generation)을 어떻게 연결하는지 설명합니다.

관련 청킹 및 검색 방법#

Late chunking은 유사한 이름을 가진 여러 기술과는 다른 문제를 해결합니다:

• **Semantic chunking**은 의미 변화에 따라 경계를 선택합니다. Late chunking은 컨텍스트 인코딩이 발생하는 시점을 결정하므로 두 기술을 결합할 수 있습니다.
• **Contextual retrieval**은 색인화하기 전에 추가 설명 텍스트나 메타데이터로 청크를 보강합니다. 반면 late chunking은 토큰 표현을 통해 암시적으로 컨텍스트를 전송합니다.
• **청크 오버랩(Chunk overlap)**은 인접한 경계 근처의 텍스트를 반복합니다. 지역적 단서는 보존할 수 있지만 색인 크기가 커지고 중복 결과가 생성될 수 있습니다. Cohere’s chunking strategy guide에서는 청크 크기와 오버랩이 검색에 미치는 영향을 논의합니다.
• Late interaction은 여러 토큰 수준 벡터를 저장하고 검색 중에 비교합니다. Late chunking은 일반적으로 청크당 하나의 풀링된 벡터를 저장하므로 기존 vector database와 호환됩니다.

리랭커(reranker) 역시 동등하다기보다는 상호 보완적인 관계입니다. Google Cloud ranking workflow에서 볼 수 있듯이 초기 검색 후 검색된 후보들의 순서를 재조정합니다.

실제 구현#

일부 임베딩 API는 late chunking을 직접 지원합니다. 다음 요청은 한 문서의 정렬된 구절들을 Jina Embedding API로 전송하고 각 구절에 대해 하나의 컨텍스트 임베딩을 반환합니다:

import os

import requests

chunks = [
    "The XR-12 pump is installed beside the cooling manifold.",
    "It must be replaced after 10,000 operating hours.",
]

payload = {
    "model": "jina-embeddings-v3",
    "task": "retrieval.passage",
    "late_chunking": True,
    "input": chunks,
}
headers = {"Authorization": f"Bearer {os.environ['JINA_API_KEY']}"}

response = requests.post(
    "https://api.jina.ai/v1/embeddings",
    headers=headers,
    json=payload,
    timeout=30,
)
response.raise_for_status()
print(len(response.json()["data"]))

출력 개수는 입력 청크 수와 일치하지만, 각 벡터는 공유된 문서 컨텍스트를 반영합니다. 대체 관리형 워크플로에서는 탄력적인 Elastic의 late chunking implementation for vector search에서 시연된 것과 같이 전체 토큰 시퀀스를 인코딩하고 그 이후에 스팬을 풀링합니다.

실제 활용 사례 및 지침#

두 가지 실무 사례는 이 컨텍스트가 중요한 이유를 보여줍니다:

• 기술 지식 어시스턴트: 제품 매뉴얼은 부품을 한 번 소개한 후 나중에 간접적으로 언급하는 경우가 많습니다. Late chunking은 지원 시스템이 유사한 일반적인 언어를 포함하는 다른 구절 대신 올바른 유지보수 단계를 검색하도록 돕습니다.
• 컴퓨터 비전 보고서 검색: computer vision and RAG workflow는 감지 결과, 검사 노트, 캡션, 유지보수 기록을 결합할 수 있습니다. Ultralytics YOLO26이 장비나 결함을 감지한 후, late chunking은 관련 텍스트 보고서 전반의 검색 성능을 향상시킬 수 있습니다. 시각적 기록은 image similarity search workflow를 사용하여 탐색할 수도 있습니다.

문서에 교차 참조, 대명사, 정의 또는 서사적 의존성이 포함된 경우 late chunking을 사용하세요. 관련 청크를 문서 순서대로 유지하고, 임베딩 모델의 컨텍스트 제한을 준수하며, 제목과 소스 메타데이터를 유지하고, 현실적인 쿼리로 검색 성능을 평가하세요. 더 많은 토큰이 함께 처리되기 때문에 인코딩 비용이 증가하므로 짧고 독립적인 레코드의 경우 독립적인 청크 임베딩이 여전히 선호될 수 있습니다.