Late Chunking이 실제로 무엇이고 무엇이 아닌가: 파트 II

Late Chunking: 장문 문맥 임베딩 모델을 사용한 문맥적 청크 임베딩

많은 사용 사례에서는 더 작은 텍스트 부분을 검색해야 하며, 밀집 벡터 기반 검색 시스템은 일반적으로 더 짧은 텍스트 세그먼트에서 더 나은 성능을 보입니다. 이는 임베딩에서 의미가 과도하게 압축될 가능성이 낮기 때문입니다. 따라서 실무자들은 종종 텍스트 문서를 더 작은 청크로 분할하여 각각 별도로 인코딩합니다. 하지만 이렇게 생성된 청크 임베딩은 주변 청크의 문맥 정보를 잃을 수 있어 최적이 아닌 표현이 될 수 있습니다. 본 논문에서는 late chunking이라는 새로운 방법을 소개합니다. 이 방법은 장문 문맥 임베딩 모델을 활용하여 먼저 긴 텍스트의 모든 토큰을 임베딩하고, transformer 모델 이후와 mean pooling 직전에 청킹을 적용합니다 - 따라서 이름에 'late'가 붙었습니다. 결과적으로 생성되는 청크 임베딩은 전체 문맥 정보를 포착하여 다양한 검색 작업에서 우수한 결과를 보여줍니다. 이 방법은 다양한 장문 문맥 임베딩 모델에 적용될 수 있을 만큼 일반적이며 추가 학습 없이도 작동합니다. late chunking의 효과를 더욱 높이기 위해, 우리는 임베딩 모델을 위한 전용 파인튜닝 접근 방식을 제안합니다.

arXiv.orgMichael Günther

긴 문서를 청킹할 때는 두 가지 문제가 있습니다. 첫 번째는 분기점 결정—즉, 문서를 어떻게 분할할 것인가 입니다. 고정된 토큰 길이, 고정된 문장 수, 또는 정규식이나 의미적 분할 모델과 같은 더 고급 기술을 고려할 수 있습니다. 정확한 청크 경계는 검색 결과의 가독성을 향상시킬 뿐만 아니라, RAG 시스템에서 LLM에 공급되는 청크가 정확하고 충분하도록—더도 말고 덜도 말고—보장합니다.

두 번째 문제는 각 청크 내의 문맥 손실입니다. 문서가 분할되면 대부분의 사람들이 다음 논리적 단계로 각 청크를 일괄 처리 방식으로 별도로 임베딩합니다. 하지만 이는 원래 문서의 전체적인 문맥 손실로 이어집니다. 많은 이전 연구들은 더 나은 경계 탐지가 의미적 표현을 개선한다고 주장하며 첫 번째 문제를 먼저 다루었습니다. 예를 들어, "의미적 청킹"은 임베딩 공간에서 코사인 유사도가 높은 문장들을 그룹화하여 의미 단위의 중단을 최소화합니다.

우리의 관점에서 보면, 이 두 가지 문제는 거의 직교하며 별도로 해결될 수 있습니다. 우선순위를 정해야 한다면, 두 번째 문제가 더 중요하다고 말할 수 있습니다.

tag문맥 손실을 위한 Late Chunking

Late chunking은 두 번째 문제부터 해결하기 시작합니다: 문맥의 손실. 이는 이상적인 분기점이나 의미적 경계를 찾는 것에 관한 것이 아닙니다. 여전히 정규식, 휴리스틱, 또는 다른 기술을 사용하여 긴 문서를 작은 청크로 나눠야 합니다. 하지만 분할된 각 청크를 바로 임베딩하는 대신, late chunking은 먼저 전체 문서를 하나의 문맥 윈도우에서 인코딩합니다(jina-embeddings-v3의 경우 8192-토큰). 그런 다음 경계 신호를 따라 각 청크에 대해 mean pooling을 적용합니다—이것이 late chunking에서 "late"라는 용어가 붙은 이유입니다.

tagLate Chunking은 부적절한 경계 신호에도 견고합니다

흥미로운 점은 실험에 따르면 late chunking이 완벽한 의미적 경계의 필요성을 제거한다는 것인데, 이는 위에서 언급한 첫 번째 문제를 부분적으로 해결합니다. 실제로 고정 토큰 경계에 적용된 late chunking은 의미적 경계 신호를 사용한 naive chunking보다 더 나은 성능을 보여줍니다. Late chunking과 함께 사용될 때 고정 길이 경계를 사용하는 것과 같은 단순한 분할 모델이 고급 경계 탐지 알고리즘과 비슷한 성능을 보입니다. 우리는 세 가지 다른 크기의 임베딩 모델을 테스트했고, 결과는 모든 테스트 데이터셋에서 이들 모두가 일관되게 late chunking의 혜택을 받는다는 것을 보여줍니다. 다만, 임베딩 모델 자체가 여전히 성능에 가장 중요한 요소입니다—late chunking을 사용하는 더 약한 모델이 그것을 사용하지 않는 더 강한 모델을 능가하는 경우는 단 한 번도 없었습니다.

잘못된 경계에 대한 복원력이 있다고 해서 경계를 무시할 수 있다는 의미는 아닙니다—경계는 여전히 인간과 LLM의 가독성 모두에 중요합니다. 우리의 관점은 다음과 같습니다: 세그멘테이션을 최적화할 때, 즉 앞서 언급한 첫 번째 문제를 해결할 때, 의미/컨텍스트 손실에 대한 걱정 없이 가독성에만 집중할 수 있습니다. Late Chunking은 좋은 또는 나쁜 브레이크포인트에 모두 대응할 수 있으므로, 가독성만 신경 쓰면 됩니다.

tagLate Chunking은 양방향입니다

Late Chunking에 대한 또 다른 일반적인 오해는 조건부 청크 임베딩이 "앞을 보지 않고" 이전 청크에만 의존한다는 것입니다. 이는 잘못된 것입니다. Late Chunking의 조건부 의존성은 실제로 단방향이 아닌 양방향입니다. 이는 임베딩 모델—인코더 전용 트랜스포머—의 어텐션 행렬이 자기회귀 모델에서 사용되는 마스킹된 삼각 행렬과 달리 완전히 연결되어 있기 때문입니다. 공식적으로, 청크 $k$의 임베딩은 $v_k \sim Q(c_k | c_1, c_2, \cdots, c_{k-1})$가 아닌 $v_k \sim Q(c_k|D)$입니다. 여기서 $Q$는 언어 모델의 인수분해를 나타냅니다. 이는 또한 Late Chunking이 정확한 경계 배치에 의존하지 않는 이유를 설명합니다.

tagLate Chunking은 학습이 가능합니다

Late Chunking은 임베딩 모델에 대한 추가 학습을 필요로 하지 않습니다. 평균 풀링을 사용하는 모든 긴 컨텍스트 임베딩 모델에 적용될 수 있어 실무자들에게 매우 매력적입니다. 그러나 질의응답이나 쿼리-문서 검색과 같은 작업을 하고 있다면, 일부 미세조정을 통해 성능을 더욱 향상시킬 수 있습니다. 구체적으로, 학습 데이터는 다음을 포함하는 튜플로 구성됩니다:

• 쿼리 (예: 질문 또는 검색어)
• 쿼리에 대한 관련 정보를 포함하는 문서
• 문서 내에서 쿼리에 직접적으로 답하는 특정 텍스트 청크인 관련 구간

모델은 InfoNCE와 같은 대조 손실 함수를 사용하여 쿼리를 관련 구간과 쌍을 이루어 학습됩니다. 이를 통해 관련 구간이 임베딩 공간에서 쿼리와 긴밀하게 정렬되는 반면, 관련 없는 구간은 더 멀리 밀려납니다. 결과적으로 모델은 청크 임베딩을 생성할 때 문서의 가장 관련성 높은 부분에 집중하는 방법을 학습합니다. 자세한 내용은 우리의 연구 논문을 참조하시기 바랍니다.

tagLate Chunking vs. Contextual Retrieval

Introducing Contextual Retrieval

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

Late Chunking이 소개된 직후, Anthropic은 Contextual Retrieval이라는 별도의 전략을 소개했습니다. Anthropic의 방법은 컨텍스트 손실 문제를 해결하기 위한 브루트포스 접근 방식이며, 다음과 같이 작동합니다:

1. 각 청크는 전체 문서와 함께 LLM에 전송됩니다.
2. LLM은 각 청크에 관련 컨텍스트를 추가합니다.
3. 이는 더 풍부하고 정보가 많은 임베딩을 생성합니다.

우리의 관점에서 이는 본질적으로 컨텍스트 보강으로, LLM을 사용하여 전역 컨텍스트를 각 청크에 명시적으로 하드코딩하는 것이며, 비용, 시간, 저장공간 측면에서 비용이 많이 듭니다. 또한 LLM이 컨텍스트를 효과적으로 풍부하게 하기 위해 정확하고 읽기 쉬운 청크에 의존하기 때문에, 이 접근 방식이 청크 경계에 대해 복원력이 있는지는 불분명합니다. 반면에 Late Chunking은 위에서 입증된 것처럼 경계 큐에 대해 매우 강한 복원력을 가집니다. 임베딩 크기는 동일하게 유지되므로 추가 저장공간이 필요하지 않습니다. 임베딩 모델의 전체 컨텍스트 길이를 활용하지만, 보강을 생성하기 위해 LLM을 사용하는 것보다 여전히 훨씬 빠릅니다. 우리 연구 논문의 정성적 연구에서, Anthropic의 컨텍스트 검색이 Late Chunking과 유사한 성능을 보인다는 것을 보여줍니다. 하지만 Late Chunking은 인코더 전용 트랜스포머의 고유한 메커니즘을 활용하여 더 저수준의, 일반적이고 자연스러운 해결책을 제공합니다.

tag어떤 임베딩 모델이 Late Chunking을 지원하나요?

Late Chunking은 jina-embeddings-v3나 v2에만 국한되지 않습니다. 평균 풀링을 사용하는 모든 긴 컨텍스트 임베딩 모델에 적용할 수 있는 꽤 일반적인 접근 방식입니다. 예를 들어, 이 포스트에서는 nomic-v1도 이를 지원한다는 것을 보여줍니다. 모든 임베딩 제공자가 자신들의 솔루션에서 Late Chunking 지원을 구현하는 것을 환영합니다.

모델 사용자로서, 새로운 임베딩 모델이나 API를 평가할 때 Late Chunking을 지원할 수 있는지 확인하기 위해 다음 단계를 따를 수 있습니다:

1. 단일 출력: 모델/API가 토큰 수준의 임베딩이 아닌 문장당 하나의 최종 임베딩만 제공합니까? 만약 그렇다면, 후기 청킹을 지원할 수 없을 가능성이 높습니다(특히 웹 API의 경우).
2. 긴 컨텍스트 지원: 모델/API가 최소 8192 토큰의 컨텍스트를 처리할 수 있습니까? 그렇지 않다면, 후기 청킹은 적용할 수 없습니다—더 정확히 말하면, 짧은 컨텍스트 모델에 후기 청킹을 적용하는 것은 의미가 없습니다. 만약 지원한다면, 단순히 지원한다고 주장하는 것이 아니라 실제로 긴 컨텍스트에서 잘 작동하는지 확인하세요. 이러한 정보는 일반적으로 LongMTEB나 다른 긴 컨텍스트 벤치마크에 대한 평가와 같이 모델의 기술 보고서에서 찾을 수 있습니다.
3. 평균 풀링: 풀링 전에 토큰 수준 임베딩을 제공하는 자체 호스팅 모델이나 API의 경우, 기본 풀링 방법이 평균 풀링인지 확인하세요. CLS나 최대 풀링을 사용하는 모델은 후기 청킹과 호환되지 않습니다.

요약하자면, 임베딩 모델이 긴 컨텍스트를 지원하고 기본적으로 평균 풀링을 사용한다면 후기 청킹을 쉽게 지원할 수 있습니다. 구현 세부사항과 추가 논의를 위해 우리의 GitHub 저장소를 확인하세요.

tag결론

그렇다면, 후기 청킹이란 무엇일까요? 후기 청킹은 긴 컨텍스트 임베딩 모델을 사용하여 청크 임베딩을 생성하는 간단한 방법입니다. 이는 빠르고, 경계 신호에 강하며, 매우 효과적입니다. 이는 단순한 휴리스틱이나 과도한 엔지니어링이 아닌, 트랜스포머 메커니즘에 대한 깊은 이해를 바탕으로 한 신중한 설계입니다.

오늘날 LLM을 둘러싼 과대 선전은 부인할 수 없습니다. 많은 경우, BERT와 같은 작은 모델로 효율적으로 해결할 수 있는 문제들이 더 크고 복잡한 솔루션의 매력으로 인해 LLM에 맡겨지고 있습니다. 대형 LLM 제공업체들이 자신들의 모델 채택을 추진하고, 임베딩 제공업체들이 임베딩을 옹호하는 것은 놀라운 일이 아닙니다 — 둘 다 자신들의 상업적 강점을 활용하고 있는 것입니다. 하지만 결국에는 과대 선전이 아닌, 실제로 무엇이 작동하는지가 중요합니다. 커뮤니티, 업계, 그리고 가장 중요하게는 시간이 어떤 접근 방식이 진정으로 더 간단하고, 효율적이며, 지속 가능한지 보여줄 것입니다.

우리의 연구 논문을 꼭 읽어보시고, 다양한 시나리오에서 후기 청킹을 벤치마크하고 여러분의 피드백을 공유해 주시기 바랍니다.