728x90
728x90
https://arxiv.org/abs/2409.04701
Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models
Many use cases require retrieving smaller portions of text, and dense vector-based retrieval systems often perform better with shorter text segments, as the semantics are less likely to be over-compressed in the embeddings. Consequently, practitioners ofte
arxiv.org
| 논문의 목적 | 문서를 청크 단위로 나눠 임베딩할 때 발생하는 문맥 손실 문제를 해결하기 위해, 새로운 방법론인 Late Chunking 제안. |
| Late Chunking 정의 | 문서 전체를 한 번에 임베딩하여 모든 토큰이 문서의 전체 문맥을 반영하도록 처리한 후, 청크를 나눠 임베딩 벡터를 생성하는 방식. |
| 기존 방식의 한계 | - Naive Chunking은 문서를 미리 나눠 각 청크를 독립적으로 임베딩하여 문맥 손실 발생. - 청크 간 참조 관계나 긴 문맥 정보 반영 불가능. |
| Late Chunking 방식 | 1. 문서 전체를 Transformer 모델에 입력하여 모든 토큰의 임베딩 생성. 2. 생성된 토큰 임베딩을 기준으로 청크 경계에 따라 평균(mean pooling) 처리하여 청크 임베딩 생성. |
| Long Late Chunking | - 긴 문서가 모델의 최대 토큰 길이를 초과할 경우, 문서를 매크로 청크로 나누고 오버랩 토큰(Overlap Tokens)을 추가해 문맥 손실을 방지. |
| 주요 실험 결과 | - BeIR 데이터셋에서 Naive Chunking 대비 nDCG@10 점수 3% 이상 향상. - 긴 문서 처리에서도 Long Late Chunking 방식으로 문맥 손실 최소화. |
| Span Pooling 학습 | Late Chunking을 위한 맞춤형 학습 방식 제안: - 특정 문서 구간(span)을 지정하여 문맥 정보를 더 잘 반영하도록 학습. - 기존 Mean Pooling 방식보다 소폭 성능 향상. |
| 비교 실험 | Anthropic의 Contextual Embedding 방식과 성능이 유사하지만, LLM 호출 없이 더 효율적으로 작동. |
| Late Chunking의 장점 | - 문맥 보존: 문서 전체를 고려해 청크 간 문맥 손실 방지. - 추가 학습 불필요: 대부분의 Transformer 모델에 바로 적용 가능. - 검색 성능 향상: 정보 검색, 질의응답에서 효과적. |
| Late Chunking의 한계 | - 문서 전체를 처리해야 하므로 메모리와 계산 비용 증가. - 매우 긴 문서에서는 추가적인 최적화 필요. |
| 향후 연구 방향 | 1. 긴 문서 처리 최적화를 위한 효율적 Transformer 구조 활용. 2. 더 다양한 도메인 및 데이터셋에서 성능 검증. 3. Span Pooling 학습 데이터 확장. |
| 결론 | Late Chunking은 문맥을 보존하여 Naive Chunking 대비 높은 성능을 제공하며, 정보 검색 및 NLP 응용에서의 효율적이고 실용적인 방법으로 자리잡을 가능성이 높음. |
더보기
이 Figure는 문맥 손실(Context Loss) 문제를 시각적으로 보여주기 위해 작성된 예시입니다.
1. Figure의 구성
- 상단 (전체 문서):
- "Berlin"에 관한 Wikipedia 문서 전체가 제공됩니다.
- 문서에는 "Berlin"이라는 단어가 처음에만 등장하며, 이후 "its", "the city" 등 참조어들이 사용됩니다.
- 하단 (청크 분할):
- 문서가 특정 규칙에 따라 세 개의 청크로 나뉘었습니다.
- 청크 1: 첫 번째 문장 ("Berlin is the capital and largest city of Germany...")
- 청크 2: 두 번째 문장 ("Its more than 3.85 million inhabitants...")
- 청크 3: 세 번째 문장 ("The city is also one of the states of Germany...")
- 빨간색 화살표는 "its"와 "the city"가 실제로 "Berlin"을 참조하고 있다는 것을 나타냅니다.
2. 이 Figure의 메시지
문맥 손실 문제
- Naive Chunking에서는 문서를 청크 단위로 나누고 각 청크를 독립적으로 처리합니다.
- 이 과정에서:
- 청크 2의 "its"가 "Berlin"을 참조하지만, Naive Chunking은 해당 문맥을 포함하지 않으므로 "its"가 무엇을 지칭하는지 알지 못합니다.
- 청크 3의 "the city" 또한 "Berlin"을 참조하지만, 청크 3에 "Berlin"이라는 단어가 없으므로 모델이 문맥을 제대로 이해하지 못합니다.
- 결과적으로, 모델은 "its"와 "the city"가 무엇을 참조하는지 제대로 알 수 없어 잘못된 임베딩이 생성됩니다.
Late Chunking의 필요성
- Late Chunking은 문서 전체를 한 번에 임베딩하여 모든 토큰이 문서 전체 문맥을 반영하도록 처리합니다.
- 이 방법을 사용하면:
- "its"와 "the city"가 문서 내에서 "Berlin"을 참조하고 있음을 모델이 이해할 수 있습니다.
- 따라서 각 청크가 독립적으로 처리되더라도 문맥이 보존되어, 더 높은 품질의 임베딩이 생성됩니다.
3. 추가 설명
유사도 비교
- 논문에서는 실제로 Naive Chunking과 Late Chunking을 비교하며, 청크 내 텍스트와 "Berlin"의 임베딩 유사도를 분석합니다.
- Naive Chunking:
- 청크 2와 청크 3의 유사도가 낮음.
- "its"와 "the city"가 "Berlin"과 연결되지 못함.
- Late Chunking:
- 청크 2와 청크 3에서도 높은 유사도를 유지.
- 이는 문맥 정보가 유지되었기 때문입니다.
4. 요약
이 Figure는 Naive Chunking의 한계를 강조하고, Late Chunking이 문맥 보존을 통해 더 나은 임베딩 품질을 제공할 수 있음을 시각적으로 설명합니다. 즉, "its"와 "the city" 같은 참조 표현이 적절히 연결되기 위해서는 문서 전체의 문맥을 반영한 임베딩 생성이 필수적임을 보여줍니다.
더보기
이 Figure는 Naive Chunking(좌측)과 Late Chunking(우측)의 차이점을 시각적으로 보여줍니다.
1. Naive Chunking (좌측)
과정
- 문서 청크화 (Chunking):
- 긴 문서를 미리 청크 단위로 나눕니다(예: 문장, 단락 또는 고정된 토큰 수 기준).
- 나눠진 각 청크(Chunk1, Chunk2, ChunkN)는 독립적인 텍스트로 취급됩니다.
- 임베딩 모델 처리:
- 각 청크를 Transformer 기반 임베딩 모델에 독립적으로 입력합니다.
- 문맥을 반영하지 못한 채 독립적(i.i.d., Independent and Identically Distributed)인 임베딩 벡터가 생성됩니다.
- Pooling:
- 각 청크에 대해 생성된 토큰 임베딩을 평균화하여(Mean Pooling) 청크 임베딩 벡터를 만듭니다.
한계
- 문맥 손실:
- 각 청크는 독립적으로 처리되므로 다른 청크의 문맥을 반영하지 못합니다.
- 결과적으로 "the city"나 "its"와 같은 참조 표현의 의미를 제대로 반영하지 못해 임베딩 품질이 저하됩니다.
2. Late Chunking (우측)
과정
- 문서 전체 임베딩:
- 긴 문서를 Transformer 모델에 한 번에 입력하여 모든 토큰 임베딩을 생성합니다.
- 이 과정에서 각 토큰은 문서 전체의 문맥을 반영합니다.
- 청크화:
- 문서 전체의 토큰 임베딩을 기준으로 청크 단위를 정의합니다.
- 청크1, 청크2, 청크N 등으로 나누고, 각 청크에 포함된 토큰 임베딩을 기준으로 Mean Pooling을 수행합니다.
- Pooling:
- 청크화된 임베딩에서 평균화 과정을 거쳐 최종적으로 문맥이 반영된 청크 임베딩(Conditional Embedding) 벡터를 생성합니다.
장점
- 문맥 유지:
- 청크 간 관계와 문서 전체의 문맥 정보를 반영한 임베딩 벡터를 생성.
- "its"와 "the city" 같은 참조 표현이 무엇을 가리키는지 모델이 알 수 있음.
- 더 높은 성능:
- 정보 검색, 질의응답 등에서 더 정확한 결과를 제공합니다.
3. Naive Chunking과 Late Chunking의 주요 차이
| 항목 | Naive Chunking | Late Chunking |
| 문서 처리 방식 | 문서를 미리 나눠 각 청크를 독립적으로 처리. | 문서를 전체로 처리한 뒤 청크를 나눔. |
| 문맥 반영 | 각 청크가 다른 청크의 문맥을 반영하지 못함. | 모든 청크가 문서 전체 문맥을 반영. |
| 임베딩 품질 | 독립적인(i.i.d.) 청크 임베딩 생성 → 문맥 손실 발생. | 문맥이 반영된(Conditional) 임베딩 생성 → 품질 향상. |
| 계산량 | 청크 단위로 모델 호출 → 계산량 분산. | 문서 전체를 한 번에 처리 → 긴 문서일수록 계산량 증가. |
| 적합한 응용 분야 | 문맥이 중요하지 않은 단순 검색 작업. | 문맥이 중요한 정보 검색, 질의응답, 긴 문서 임베딩 작업. |
4. 요약
이 Figure는 Naive Chunking과 Late Chunking의 문맥 처리 방식 차이를 강조합니다.
- Naive Chunking은 문서를 미리 나눠 처리하여 문맥 단절 문제가 발생하지만,
- Late Chunking은 문서를 한 번에 처리한 뒤 청크화하여 문맥 보존과 임베딩 품질 향상을 제공합니다.
이 방식은 검색과 같은 NLP 응용에서 더 높은 정확도와 효율성을 보장하는 방법론으로 제안됩니다.
더보기
이 두 개의 Figure는 Naive Chunking과 Late Chunking의 성능을 서로 비교한 결과를 보여주며, 특히 청크 크기에 따른 정보 검색 성능 변화를 나타냅니다. 또한, Long Late Chunking이 긴 문서를 처리할 때의 효과도 설명하고 있습니다.
Figure 3: Retrieval Results with Different Chunk Sizes
- 설명:
- 다양한 데이터셋(NFCorpus, NarrativeQA 등)에 대해 Naive Chunking과 Late Chunking을 비교하며, 청크 크기(4 ~ 512 토큰)에 따른 nDCG@10(검색 성능 지표)의 변화를 보여줍니다.
- nDCG@10(Normalized Discounted Cumulative Gain at rank 10)은 검색된 문서의 순위 품질을 측정하는 지표로, 값이 클수록 더 높은 검색 성능을 의미합니다.
- 결과 해석:
- Late Chunking의 우수성:
- 거의 모든 데이터셋에서 Late Chunking이 Naive Chunking보다 높은 nDCG@10 값을 기록.
- 특히 작은 청크 크기(4, 8, 16)에서 Naive Chunking 대비 큰 성능 향상.
- 예: NFCorpus, QMSum에서 청크 크기가 작을수록 Late Chunking의 성능 차이가 더욱 두드러짐.
- 청크 크기에 따른 성능 변화:
- 청크 크기가 클수록(Large Chunk Size, 예: 256, 512), Naive Chunking과 Late Chunking의 성능 차이가 줄어드는 경향.
- 이는 큰 청크가 자체적으로 더 많은 문맥 정보를 포함하므로 문맥 손실이 덜 발생하기 때문.
- 데이터셋 의존성:
- Needle-8192 및 Passkey-8192와 같은 데이터셋에서는 Late Chunking이 큰 차이를 보이지 않음.
- 이들 데이터셋은 문서 내에서 특정 세부 정보를 찾는 작업이 중심이며, 문맥 정보가 큰 영향을 미치지 않는 경우가 많음.
- Late Chunking의 우수성:
Figure 4: Retrieval Results with Long Late Chunking for Different Chunk Sizes
- 설명:
- 긴 문서를 다룰 때, Long Late Chunking의 성능을 보여줍니다.
- 다양한 데이터셋(WikiMultiHopQA, SummScreenFD, QMSum)에 대해 Naive Chunking과 Long Late Chunking을 비교하며 청크 크기(8 ~ 512)에 따른 nDCG@10 변화를 확인.
- 결과 해석:
- 긴 문서 처리에서 Long Late Chunking의 효과:
- 긴 문서를 Long Late Chunking 방식으로 처리할 경우, Naive Chunking 대비 성능이 대체로 향상됨.
- 특히 SummScreenFD와 QMSum 같은 데이터셋에서 Late Chunking이 크게 우세.
- 청크 크기에 따른 패턴:
- 작은 청크 크기(8, 16, 32)일수록 Long Late Chunking의 성능이 더욱 뛰어나며, 청크 크기가 커질수록 두 방식의 성능 차이가 감소.
- SummScreenFD 데이터셋에서는 청크 크기가 클수록 성능이 조금씩 증가.
- 데이터셋 간 차이:
- WikiMultiHopQA에서는 Naive와 Late 간의 성능 차이가 상대적으로 작으며, QMSum과 같은 데이터셋에서 차이가 더 크다.
- 이는 데이터셋마다 문맥 정보의 중요도가 다르기 때문.
- 긴 문서 처리에서 Long Late Chunking의 효과:
Figure의 핵심 요약
| 항목 | Figure 3 (일반 청크) | Figure 4 (긴 문서 청크) |
| 목적 | Naive vs Late Chunking 비교 | Naive vs Long Late Chunking 비교 |
| 성능 비교 결과 | Late Chunking이 작은 청크 크기에서 월등한 성능 제공. | 긴 문서에서도 Long Late Chunking이 우세. |
| 청크 크기 영향 | 작은 청크 크기에서 성능 차이가 크게 나타남. | 작은 청크 크기에서 성능 차이가 더욱 두드러짐. |
| 데이터셋 의존성 | 문맥 중요성이 높은 데이터셋에서 Late의 성능이 우세. | 긴 문맥 활용이 중요한 SummScreenFD, QMSum에서 우세. |
전체적인 결론
- Late Chunking:
- 문맥 정보를 보존하여, 특히 작은 청크 크기에서 더 높은 검색 성능을 제공합니다.
- Long Late Chunking:
- 긴 문서에서도 문맥 손실을 최소화하여 높은 성능을 보이며, Naive Chunking보다 효율적입니다.
- 실용성:
- 청크 크기와 데이터셋의 특성에 따라 성능 차이가 있지만, 전반적으로 문맥 정보를 보존하는 Late Chunking 방식이 더 나은 검색 품질을 제공합니다.
Late Chunking이란?
- 기존의 naive chunking 방식(텍스트를 미리 나누고 각각 독립적으로 임베딩 생성)과 달리, Late Chunking은 전체 문서의 문맥을 활용해 문서 전체를 임베딩한 후, 필요한 부분(청크)을 나중에 나눕니다.
- 이 방법은 청크 간 상호 문맥 정보를 유지하여 임베딩 품질을 향상시킵니다.
주요 이점
- 문맥 보존: "Berlin" 예제에서처럼 문맥이 없는 경우보다 훨씬 높은 유사도 점수를 유지.
- 추가 학습 없이 사용 가능: 대부분의 임베딩 모델에 적용 가능하며, 추가 학습 없이도 성능이 향상됩니다.
- 유연성: Transformer 기반의 모든 긴 문맥 지원 모델에서 사용 가능.
성능 비교
- BeIR 등의 벤치마크 실험에서 Naive Chunking보다 nDCG 점수가 평균적으로 3% 이상 개선.
- 작은 청크 크기일수록 Late Chunking의 성능 향상이 두드러졌습니다.
확장된 Long Late Chunking
- 문서가 모델의 최대 토큰 길이를 초과할 때 이를 해결하기 위한 방법:
- 문서를 매크로 청크로 나누고 오버랩 토큰을 추가하여 문맥 손실 최소화.
한계 및 트레이닝 제안
- 모델 학습 없이도 성능 향상을 보이지만, 특정 작업에 대해 Span Pooling 방식을 도입한 추가 학습으로 더 나은 성능 확보 가능.
이 기술은 검색 및 정보 검색(IR) 작업에서 특히 유용하며, 긴 문맥을 효과적으로 활용하는 NLP 모델 설계에 새로운 가능성을 제공합니다
Late Chunking 방법론
Late Chunking은 텍스트 임베딩 모델에서 긴 문맥을 활용하면서 청크 간 문맥 손실 문제를 해결하는 전략입니다. 이 방법은 두 가지 주요 단계를 포함합니다:
1. 문서 전체를 임베딩
- 텍스트 전체를 긴 문맥을 지원하는 모델(예: Jina-Embeddings, Longformer 등)로 처리하여 토큰 임베딩 벡터를 생성합니다.
- 토큰 임베딩 벡터는 문서의 모든 문맥을 반영하며, 각각의 토큰이 문서 전체의 정보를 포함하도록 설계됩니다.
2. 사후 청크화 (Post-Chunking)
- 문서를 청크(chunk) 단위로 나누는 기존 방식과 달리, 토큰 임베딩 벡터가 생성된 후 청크를 나눕니다.
- 이때 청크의 크기와 경계는 문서의 자연적 경계(예: 문장, 단락)나 고정된 토큰 수(예: 256 토큰)로 설정됩니다.
- 각 청크의 벡터는 청크에 포함된 토큰 임베딩의 평균(mean pooling)으로 계산됩니다.
알고리즘 (의사 코드)
입력: 긴 텍스트 문서 T, 청크 크기 S
출력: 청크 임베딩 e1, e2, ..., en
1. 문서를 토큰화하여 토큰 시퀀스 τ1, τ2, ..., τm 생성.
2. Transformer 기반 임베딩 모델에 토큰 시퀀스 입력 → 토큰 임베딩 벡터 ϑ1, ϑ2, ..., ϑm 생성.
3. 청크 경계 설정 (고정된 토큰 크기 또는 자연 경계).
4. 각 청크에 대해:
a. 청크 경계에 해당하는 토큰 임베딩을 선택.
b. 선택된 토큰 임베딩의 평균(mean pooling) → 청크 임베딩 생성.
예시: "Berlin" 문서
문서 내용:
Berlin is the capital and largest city of Germany, both by area and by population.
Its more than 3.85 million inhabitants make it the European Union's most populous city.
The city is also one of the states of Germany, and is the third smallest state in the country.
Naive Chunking과 Late Chunking 비교
| Chunking 방식 | 과정 | 문맥 손실 여부 |
| Naive Chunking | 문서를 "Berlin is...", "Its more than...", "The city is..."로 분할 후 각각 독립적으로 임베딩 | "Its"와 "The city"가 무엇을 참조하는지 모델이 알지 못함. 따라서 Berlin과 관련성을 제대로 반영하지 못함. |
| Late Chunking | 문서 전체를 임베딩하여 각 토큰이 전체 문맥을 포함한 후, "Berlin is...", "Its more than...", "The city is..."로 나눔 | "Its"와 "The city"가 "Berlin"을 참조하고 있음을 모델이 이해. 각 청크가 전체 문맥에 기반한 임베딩을 생성함. |
결과
- Naive Chunking: "Its more than..."의 청크 임베딩은 "Berlin"과 낮은 유사도 점수를 보임.
- Late Chunking: "Its more than..."의 청크 임베딩이 "Berlin"과 높은 유사도 점수를 유지.
Long Late Chunking: 긴 문서 처리
긴 문서가 모델의 최대 토큰 길이를 초과하면, 문서를 매크로 청크로 나눠 처리합니다.
방법
- 문서를 l_max 길이의 매크로 청크로 분할.
- 매크로 청크 간 오버랩 토큰(Overlap Tokens)을 추가하여 문맥 연결.
- 각 매크로 청크에 대해 Late Chunking 수행.
예시: 논문 검색
- 논문이 20,000 토큰이고, 모델이 한 번에 처리할 수 있는 길이가 8,192 토큰이라면:
- l_max = 8,192, 오버랩 토큰 = 512로 설정.
- 매크로 청크를 생성하며, 청크 경계에서 일부 문맥을 공유.
실무 적용 시나리오
- 검색 및 정보 검색(IR)
- 사용자가 "유럽의 인구가 가장 많은 도시"를 검색할 때, Late Chunking을 활용하면 문서 전반의 문맥을 반영해 더욱 정확한 청크를 반환할 수 있습니다.
- QA 시스템
- 질문: "ACME Corp의 2023년 2분기 매출 성장률은?"
- 답변을 포함한 문서의 청크를 정확히 반환하고, Late Chunking으로 회사명을 포함한 문맥을 유지하여 임베딩 품질 향상.
- 긴 문맥 활용
- 법률 문서나 논문과 같은 대규모 텍스트 데이터에서도 정확도를 높임.
결론
Late Chunking은 긴 문맥을 효과적으로 활용해 검색, 질의응답 등 다양한 NLP 응용 분야에서 성능을 크게 향상시킵니다. 기존 방식의 한계를 보완하며, 추가 학습 없이도 성과를 낼 수 있는 실용적인 접근법입니다.
그런데 문서를 토큰화하고 그 길이대로 임베딩 벡터가 나오면 사실그게 언어 모델 인풋으로 평상시에 사용되는 것과 뭐가 다른 거야?
좋은 질문입니다! Late Chunking에서 사용하는 임베딩 생성 방식과 일반적인 언어 모델의 입력 처리 방식은 겉보기에는 유사해 보일 수 있습니다. 그러나 핵심적인 차이점은 목적과 활용 방식에 있습니다. 이를 비교하면서 설명드리겠습니다.
1. 일반적인 언어 모델 입력 처리
과정
- 텍스트를 토큰화하여 정수 인덱스 시퀀스로 변환.
- 이 시퀀스가 Transformer 모델로 입력되어 각 토큰에 대해 토큰 임베딩 생성.
- 최종적으로 각 토큰에 대한 임베딩을 반환하거나, 특정 작업(예: 분류, 예측)을 위해 이를 추가로 처리.
특징
- 목적: 주로 다음 토큰 예측, 분류, 생성 등 문장 단위의 작업 수행.
- 토큰 중심: 각 토큰은 자신이 위치한 문맥에서의 정보만 반영하며, 모델은 토큰별 임베딩을 독립적으로 활용.
- 전체 시퀀스의 임베딩이 필요하지 않을 수도 있음: 필요한 경우 [CLS] 토큰의 임베딩 또는 다른 집약 방식을 사용.
2. Late Chunking에서의 처리 방식
과정
- 문서 전체를 토큰화하고, 이를 모델에 입력하여 각 토큰에 대한 임베딩 벡터 생성.
- 문서 전체를 한 번에 처리하므로, 각 토큰 임베딩은 전체 문서의 문맥을 반영.
- 이후 특정 청크(예: 문장, 단락 등)로 나누고, 청크에 속한 토큰 임베딩을 평균(mean pooling)하여 청크 단위의 벡터 생성.
특징
- 목적: 문서 내 특정 구간(청크)의 표현을 생성하여, 검색 또는 문맥 유지에 활용.
- 문서 중심: 청크의 임베딩은 청크 자체뿐 아니라 문서 전체의 문맥 정보를 포함.
- 청크 임베딩 활용: 각 청크가 독립적인 문맥 벡터로 사용되며, 이를 통해 검색, 질의응답 등에서 더 높은 성능을 달성.
핵심 차이점
| 구분 | 일반 언어 모델 처리 | Late Chunking |
| 문맥 범위 | 주어진 토큰의 주변 문맥 (로컬 문맥) | 전체 문서의 문맥 (글로벌 문맥) |
| 목적 | 특정 작업(생성, 분류, 예측 등)을 위한 토큰 단위 처리 | 검색/질의응답에서 청크 단위 표현 생성 |
| 임베딩의 활용 방식 | 토큰 단위로 결과 반환 (특정 작업에 따라 사용 방식 다양) | 청크 단위로 임베딩 벡터를 생성 후, 검색/유사도 계산에 사용 |
| 청크 경계 고려 여부 | 입력 처리 과정에서는 별도로 고려하지 않음 | 청크화 과정에서 경계를 정의하고 이를 기반으로 임베딩 벡터를 생성 |
| 평균화 처리 | 토큰 임베딩의 평균은 일반적으로 사용하지 않거나 선택적 | 청크 임베딩을 위해 필수적으로 토큰 임베딩을 평균화(mean pooling) 처리 |
Late Chunking의 차별화된 점
Late Chunking은 단순히 모델의 인풋을 문서 전체로 확장하는 것 이상의 기능을 수행합니다:
- 청크화 이후 처리:
- 일반 언어 모델은 토큰 임베딩을 바로 반환하지만, Late Chunking은 특정 청크 단위를 정의하여 이를 기반으로 추가적인 표현(임베딩 벡터)을 생성합니다.
- 검색/질의응답 최적화:
- 생성된 청크 임베딩은 문서 내 특정 문맥을 정확히 표현하므로, 검색 및 유사도 계산에서 더 높은 성능을 보입니다.
- 글로벌 문맥 활용:
- 일반적인 처리 방식은 입력된 범위 내의 정보만 반영하지만, Late Chunking은 문서 전체의 정보를 반영하여 보다 풍부한 문맥을 유지합니다.
예시: 검색 작업
기존 모델 활용 (Naive 방식):
- 사용자는 "2023년 ACME Corp의 매출 성장"을 검색합니다.
- 문서가 미리 문장 단위로 나뉘어 저장되었다면, "It highlighted a 3% revenue growth..." 같은 문장은 회사명과 연결되지 않아 검색 결과에서 누락될 수 있음.
Late Chunking 활용:
- 문서 전체를 임베딩하여 "It"이나 "the company" 같은 단어가 "ACME Corp"와 연결된 문맥임을 반영.
- 청크 임베딩 생성 시 이러한 문맥 정보가 유지되므로, 검색에서 누락되지 않고 높은 유사도로 반환 가능.
따라서, Late Chunking은 언어 모델의 기존 활용 방식과 달리, 텍스트 검색과 같은 작업에서 문서 전체 문맥을 반영하여 특정 구간(청크)에 대한 표현을 효율적으로 생성하고 활용할 수 있는 전략적 차별점을 제공합니다.
그럼 결국 임베딩을 생성하기 위해서는 Transformer 구조를 한번은 거쳐야 하는 것인데 리소스를 기존에 비해 많이 잡아 먹겠네?
맞습니다. Late Chunking 방식은 문서 전체를 Transformer 모델에 입력한 뒤, 모든 토큰에 대한 임베딩을 생성해야 하므로, 리소스(메모리, 연산량)를 기존의 Naive Chunking 방식보다 더 많이 소모할 가능성이 있습니다. 이를 좀 더 구체적으로 분석해 보겠습니다.
1. 리소스 소모의 주요 원인
1) 문서 전체를 처리
- Naive Chunking: 미리 문서를 청크 단위로 나눠 각각 독립적으로 모델에 입력합니다.
- 문맥을 유지하지 않지만, 각 청크가 독립적으로 모델을 호출하므로 계산량이 분산됩니다.
- Late Chunking: 문서 전체를 한 번에 입력하여 모든 토큰의 임베딩을 생성합니다.
- 문맥을 유지하지만, 긴 입력 시퀀스를 한 번에 처리해야 하므로 계산량과 메모리 사용량이 증가합니다.
2) Transformer의 연산 복잡도
- Transformer의 Self-Attention 연산은 입력 토큰 길이에 대해 O(n²)의 복잡도를 가지며, 입력 길이가 길수록 메모리와 계산 시간이 크게 증가합니다.
- 예: 문서 길이가 2배로 늘어나면, Attention 연산의 계산량은 4배 증가.
3) 추가적인 후처리
- 문서 전체에서 청크를 나누고, 각 청크의 토큰 임베딩을 평균화(mean pooling)하는 추가 작업이 필요합니다.
- 이 작업은 Transformer 연산에 비하면 가볍지만, 대규모 데이터를 다룰 경우 병목이 될 수 있습니다.
2. Late Chunking이 가져오는 장점으로 인한 보상
1) 문맥 보존으로 성능 향상
- Late Chunking은 문맥을 유지하여 생성된 임베딩의 품질이 높아지고, 검색 및 질의응답 성능이 향상됩니다.
- 따라서 리소스 소모 증가가 성능 향상으로 보상될 수 있습니다.
2) 청크 간 중복 처리 감소
- Naive Chunking은 청크를 독립적으로 처리하기 위해 청크 간 중복된 토큰을 포함하는 경우가 많습니다(예: Overlapping Chunks). Late Chunking은 중복 없이 전체 문서를 한 번 처리하므로, 긴 문서일수록 계산량이 상대적으로 줄어드는 경우가 있을 수 있습니다.
3. 리소스 소모를 줄이기 위한 최적화 방안
Late Chunking의 리소스 소모 문제를 완화할 수 있는 몇 가지 전략이 있습니다:
1) Long Late Chunking
- 긴 문서를 최대 토큰 길이(l_max)를 기준으로 나눠 처리하는 방식.
- 각 매크로 청크에 오버랩 토큰을 추가하여 문맥을 유지하면서도 모델의 최대 입력 길이를 초과하지 않도록 제한합니다.
- 예: 최대 입력 길이 8192 토큰, 오버랩 512 토큰을 사용.
2) Efficient Transformer 구조 사용
- 기존 Transformer 구조는 긴 입력에서 비효율적이므로, 다음과 같은 최적화된 모델을 사용하는 방안이 있습니다:
- Longformer: Sparse Attention을 통해 긴 문서를 처리.
- BigBird: Global, Local, Random Attention을 조합하여 긴 입력 처리 최적화.
- Reformer: Attention 계산을 효율적으로 수행하기 위해 Locality-Sensitive Hashing(LSH)을 사용.
3) Chunk 경계 최적화
- 문서 내에서 의미적으로 중요한 경계를 자동으로 찾는 Semantic Chunking을 적용하여, 불필요한 계산을 줄이고 의미적으로 풍부한 청크를 생성합니다.
4) 계산 병렬화
- GPU/TPU를 활용하여 토큰 임베딩 계산을 병렬화하고, 대규모 배치(batch)를 사용해 효율적으로 처리.
5) 사전 생성된 임베딩 활용
- 문서 전체를 처리한 후 생성된 토큰 임베딩을 저장해 두고, 검색 시 재활용.
- 문서가 변하지 않는다면, 반복적인 모델 호출을 피할 수 있음.
4. Late Chunking의 실용적 고려사항
Late Chunking은 긴 문맥을 처리할 필요가 있는 특정 작업에서 효과적입니다. 하지만, 모든 경우에 적합하지는 않으며, 아래와 같은 기준으로 판단해야 합니다:
적합한 경우
- 긴 문서에서 특정 문맥(청크) 기반 검색이나 질의응답이 중요한 경우.
- 높은 품질의 임베딩 생성이 우선시되는 경우.
덜 적합한 경우
- 실시간 처리 속도가 중요한 경우.
- 짧은 문서에서 이미 충분히 좋은 성능을 내는 경우.
결론
Late Chunking은 리소스를 더 많이 소모할 수 있지만, 성능 향상이라는 이점을 제공하여 고도화된 검색 및 정보 검색 시스템에 적합합니다. 리소스 최적화를 위한 다양한 전략을 병행한다면, 성능과 효율성 간 균형을 맞출 수 있을 것입니다.
논문의 결과, 결론, 및 마무리
1. 주요 결과
논문은 Late Chunking이 기존의 Naive Chunking 방식에 비해 다양한 정보 검색 및 임베딩 작업에서 우수한 성능을 보여준다고 보고합니다. 주요 결과는 다음과 같습니다:
1) Retrieval Task에서의 성능 향상
- BeIR 데이터셋 실험에서 Naive Chunking 대비 성능 지표(nDCG@10)가 전반적으로 개선됨.
- 예: 문장을 기준으로 나눌 경우, 평균적으로 약 3.63% 상대적 성능 향상.
- 특히 작은 청크 크기일수록 Late Chunking의 이점이 더 두드러짐.
- 이는 작은 청크에서 문맥 정보를 보존하는 효과가 극대화되기 때문.
2) Long Late Chunking으로 긴 문서 처리
- 긴 문서가 모델의 최대 토큰 길이를 초과하는 경우, Long Late Chunking 방식으로 추가적인 문맥 손실 없이 성능을 유지.
- 긴 문서를 다룰 때 Naive 방식보다 더 높은 nDCG 점수를 달성.
- Overlapping 토큰을 사용한 문맥 보존 전략이 유효함을 입증.
3) Span Pooling 학습으로 추가적인 성능 향상
- Late Chunking은 추가 학습 없이도 성능 향상을 보여주지만, Span Pooling 기반 학습을 통해 더 나은 성능을 달성.
- TriviaQA와 FEVER 데이터셋으로 학습 시, 기존 Mean Pooling 방식 대비 소폭 성능 향상 관찰.
- 특히 문서 내 특정 구간을 찾는 작업에서 효과적임.
4) 다른 접근법과의 비교
- Anthropic의 Contextual Embedding 방식과 비교 시, Late Chunking은 비슷한 성능을 보이지만 추가적인 LLM 호출 없이 효율적으로 작동.
- 따라서 실용성과 성능 모두를 갖춘 방법임.
2. 결론
1) Late Chunking의 효과
Late Chunking은 기존 Naive Chunking 방식의 한계를 극복하며, 긴 문맥 정보를 활용해 더 높은 품질의 임베딩을 생성합니다.
- 문맥 손실 문제를 해결하여 검색 및 정보 검색(IR) 작업에서 성능을 향상.
- 긴 문서를 다룰 때에도 문맥 보존을 통해 정확한 검색 및 질의응답 성능 제공.
2) 실용적 적용 가능성
- Late Chunking은 Transformer 기반 모델에서 적용 가능하며, 추가 학습 없이도 바로 활용 가능.
- 다양한 청크 크기와 경계 설정에 유연하게 적용되어 실용적인 선택지를 제공.
3. 마무리 및 기여
이 논문은 다음과 같은 기여를 합니다:
- Late Chunking 기법 제안: 문서 임베딩의 성능을 높이기 위한 새로운 아키텍처 변경.
- Long Late Chunking 방식 도입: 긴 문서 처리에서의 효율적인 방법론.
- Span Pooling 학습 제안: Late Chunking을 위한 맞춤형 학습 방법.
- 종합적 평가: 다양한 데이터셋에서 Late Chunking의 성능을 입증하고, 한계와 적용 범위를 명확히 정의.
4. 향후 연구 방향
- 다양한 데이터셋에서의 테스트:
- 문서 길이와 도메인(예: 법률, 의학 등)에 따라 Late Chunking의 성능을 추가적으로 검증.
- 효율성 개선:
- Transformer 연산 비용을 줄이기 위해 효율적인 모델(예: Longformer, BigBird 등)과 Late Chunking의 결합 연구.
- 더 다양한 학습 데이터 활용:
- Span Pooling 학습을 위한 대규모, 다도메인 데이터셋 확장.
Late Chunking은 기존의 Naive Chunking 방식을 대체할 수 있는 실용적이며 고성능의 방법론으로, 정보 검색, 질의응답, 긴 문서 처리 등 다양한 NLP 응용 분야에 적용 가능성을 보여줍니다.
문서를 매크로 청크로 나누고, 오버랩 토큰을 추가해 문맥 손실을 방지한 다는 것이 무슨 말이야?
MaxToken을 넘으면 모델 Input으로 주어지지 못하니까 매크로 청킹을 통해 특정 규칙에 따라 청킹을 진행하고, 그 자른 부분에 오버랩토큰을 통해 이 전 문맥과 이 후 문맥을 조금씩 넣어주는 거야...?
맞습니다! Long Late Chunking은 모델의 최대 토큰 길이(MaxToken) 제한을 극복하기 위해, 문서를 매크로 청크로 나누고, 오버랩 토큰(Overlap Tokens)을 추가하여 문맥 손실을 최소화하는 방식입니다.
1. 왜 매크로 청크가 필요한가?
Transformer 모델은 입력 가능한 토큰의 최대 길이가 정해져 있습니다(MaxToken, 예: 4096 또는 8192 토큰). 하지만 문서 길이가 이 제한을 초과하면 다음과 같은 문제가 발생합니다:
- 긴 문서의 처리 불가: 문서가 MaxToken보다 길면 입력으로 전달할 수 없으므로 문서 전체를 모델에 임베딩할 수 없음.
- 문맥 손실: 문서를 잘라서 처리하면, 청크 경계에서 문맥이 단절될 위험이 있음.
이를 해결하기 위해 매크로 청크(Macro Chunk) 개념이 도입됩니다.
2. 매크로 청크와 오버랩 토큰의 개념
매크로 청크
- 문서를 MaxToken 길이 이내로 자른 덩어리(청크)를 매크로 청크라고 합니다.
- 각 매크로 청크는 문서의 한 부분만 포함하지만, 문맥 단절을 방지하기 위해 오버랩 토큰을 추가합니다.
오버랩 토큰
- 매크로 청크 간에 일부 공통된 토큰(Overlap)을 포함하여 문맥 연결성을 유지합니다.
- 예를 들어:
- 매크로 청크 1: 토큰 1 ~ 8192 + 오버랩 1 ~ 512 (8192 토큰 + 512 오버랩)
- 매크로 청크 2: 토큰 7681 ~ 8192 + 8193 ~ 16384 + 오버랩 8193 ~ 8704 (8192 토큰 + 512 오버랩)
- 이렇게 오버랩 토큰을 통해, 이전 청크와 다음 청크 간 문맥 연결을 보장합니다.
3. 동작 방식
Long Late Chunking의 구체적인 과정을 단계별로 정리하면 다음과 같습니다:
- 문서를 토큰화:
- 문서를 토큰으로 변환하고, 총 토큰 수(TotalTokens)를 계산합니다.
- 예: 문서가 20,000 토큰이라면, TotalTokens = 20,000.
- 매크로 청크 분할:
- MaxToken 길이를 기준으로 문서를 나누되, 각 청크에 오버랩 토큰(OverlapTokens)을 추가.
- OverlapTokens는 두 청크 사이에 문맥 정보를 공유하기 위한 부분.
- 예: MaxToken = 8192, OverlapTokens = 512로 설정.
- 모델 임베딩 생성:
- 각 매크로 청크를 Transformer 모델에 입력하여 토큰 임베딩을 생성.
- 청크 경계에 추가된 오버랩 토큰은 이전/다음 청크의 문맥을 보존.
- Late Chunking 수행:
- 매크로 청크에서 필요한 작은 청크를 다시 나누고(mean pooling), 최종적으로 청크 임베딩 벡터를 생성.
4. 예시
문서 내용 (20,000 토큰 길이):
토큰 1, 토큰 2, ..., 토큰 20,000
분할 방식 (MaxToken = 8192, Overlap = 512):
| 매크로 청크 | 포함된 토큰 범위 | 오버랩 토큰 |
| 매크로 청크 1 | 1 ~ 8192 | 8193 ~ 8704 |
| 매크로 청크 2 | 7681 ~ 16384 | 16385 ~ 16896 |
| 매크로 청크 3 | 15361 ~ 20000 | 없음 |
결과:
- 매크로 청크 1과 매크로 청크 2 사이에 7681 ~ 8704 토큰이 겹치므로, 모델은 이전 문맥을 유지.
- 매크로 청크 3에서는 마지막 부분이라 오버랩이 필요 없음.
5. 효과
- 문맥 손실 방지: 오버랩 토큰을 통해 청크 간 단절 문제 해결.
- 긴 문서 처리 가능: 최대 토큰 길이 제한 내에서 문서를 효율적으로 처리.
- Late Chunking의 이점 유지: 각 매크로 청크가 문서 전체의 문맥을 반영한 임베딩을 생성.
6. 장단점
장점:
- 긴 문서 처리 가능.
- 오버랩 토큰을 통해 문맥 단절 최소화.
- 모델의 성능(예: 검색 정확도) 유지.
단점:
- 계산 비용 증가:
- 오버랩 토큰 추가로 인해 총 입력 길이가 증가.
- 메모리 사용량 증가:
- 긴 문서를 매크로 청크 단위로 여러 번 처리하므로 메모리 소모량이 늘어남.
결론
맞게 이해하셨듯, Long Late Chunking은 모델의 입력 한계를 넘는 긴 문서를 다룰 때, 매크로 청크와 오버랩 토큰을 활용해 문맥 단절 문제를 해결하고, 임베딩 품질을 높이는 전략입니다. 이는 Naive 방식으로 처리하기 어려운 작업에 적합하며, 긴 문맥 활용이 중요한 NLP 응용 분야(예: 법률, 의학, 검색)에서 큰 장점을 제공합니다.
728x90