late chunking

기존의 문제(Naive Chunking)

기존 RAG를 잘 활용하기 위해서는 full text가 아닌 개별적인 chunking 단위로 나누어야 했다. 이에 따라 임베딩을 거쳐 단순 키워드 기반 검색이 아니라 의미 기반 semantic search를 하기 위해서는 이 각각의 청크에 대해서 임베딩을 생성해야 했다. 하지만 이러한 청킹 방식의 문제점은 조각 낸 것들에 대해서만 임베딩을 생성하기 때문에 전체 맥락에 대해서는 알지 못한다는 것이다.

특히 영어를 통해서는 더 잘 이해할 수 있다.

위 사진을 본 각 대명사들이 무엇을 지칭하는지 생각해보면 가장 최상단의 Berlin을 지칭하지만, 각 청크들에게 이 Berlin에 대한 정보가 없기 때문에 Its, The city가 베를린을 지칭하는 것인지 모르게 되고 이는 결국 검색의 품질을 떨어뜨린다.

따라서 이를 해결하기 위한 몇 가지 방법론이 제기되었는데, 아예 긴 context를 가진 임베딩 모델을 사용해보는 방법도 있었지만 연구 결과 검색에 대한 품질은 조금 더 잘게 나뉘어져 있는 청킹들에 대한 검색 결과가 좋았다고 한다. 따라서 이 작은 청킹 단위를 유지하면서도 추가적으로 품질을 더 높일 수 있는 방법들에 대해서 고민하게 되었는데, Late Chunking이 바로 그런 방법론들 중 하나이다.

Late Chunking

왜 Late Chunking 방식이라고 이름을 지었는지는 그들이 어떻게 이 문제를 해결하려 했는지에 대해 이해한다면 이름 또한 이해할 수 있다.

Late Chunking 접근 방식은 먼저 임베딩 모델의 트랜스포머 레이어를 전체 텍스트 또는 가능한 한 많은 부분에 적용한다. 이는 전체 텍스트의 정보를 포함하는 각 토큰에 대한 벡터 시퀀스를 생성할 것이다. 이후 이 토큰 벡터 시퀀스의 각 청크에 평균 풀링이 적용되어 전체 텍스트의 문맥을 고려한 각 청크의 임베딩이 생성된다.

평균 풀링 (Mean Pooling): 여러 개의 토큰 벡터를 하나의 대표 벡터(조각 임베딩)로 만들기 위해 산술 평균을 구하는 연산

독립적이고 동일하게 분포된 청크 임베딩을 생성하는 단순 인코딩 접근 방식과 달리, late chunking은 각 임베딩이 이전 임베딩에 “조건화된” 청크 임베딩 세트를 생성하여 각 청크에 대해 더 많은 문맥 정보를 담아 인코딩할 수 있게 하는 것이다. 따라서 처음부터 각 청크들에 대해서 바로 임베딩을 생성하기 보다는, 긴 문서에 대해 먼저 임베딩 세트를 생성한 다음에 각 청크에 대한 임베딩들을 생성할 때 이러한 문맥 정보를 고려하면서 임베딩하면서 정보들을 더 담을 수 있도록 했기 때문에 실제로 chunking들에 대한 임베딩 생성은 naive한 버전보다 늦어진다. 그렇기에 late chunking인 것

Contexture Chunking + LateChunking?

contexture chunking은 기존의 fixed sized chunking보다 조금 더 발전한 단계를 도입해 다시금 문서를 어느정도 문맥을 담은 chunking을 생성하고 이를 임베딩 모델에 넣어 임베딩을 뽑아낸다. 일정한 토큰 수마다 칼같이 잘라서 청킹을 하는 fixed sized chunking은 결국 문장 간에 문장이 끊길 수도 있고 이에 대해서 각 임베딩을 생성할 때도 좋지 못한 결과가 나올 확률이 높기 때문에 보완하기 위해 쓴 방법.

llm에게 body를 주고, 문맥에 맞게 각 문단들을 나누고, 그 단위로 청킹을 한다. 그렇지만 이 방식은 만약에 어떠한 청크의 body가 A/B/C로 나뉘어 졌다면, 다음 청크에 이 C가 이어질 가능성이 있다. 그렇기에 마지막 남은 C에 대해서는 다음 청크의 앞부분에 붙여넣고 다시 llm에게 문맥상 chunking을 할 수 있도록 한다. 이렇게 어느정도 작은 단위로 chunking을 하는 방식에 대해서는 보완이 된 상태이다.

그렇지만 문제는 비유하자면 지역 변수는 잘 알게 되었지만 전역 변수는 잘 모른다는 것. 전체적인 문서의 맥락을 고려할 필요가 있기 때문에 임베딩을 생성하는 과정에서도 보완하면 더 품질이 올라갈 것이라는 가설을 두고 해당 late chunking을 생각해보았다.

도입 가능성 생각해보기

앞서 설명한 Late Chunking은 개념적으로는 괜찮아 보일 수도 있지만, 우리 상황을 고려했을 때 애매했던 부분들이 있다.

문맥 윈도우(Context Window)의 물리적, 절대적 한계

문서의 페이지 분량을 토큰으로 고려해 볼 때 기업들이 사용하는 문서들 중에는 참고로 사용하는 하나의 문서만 하더라도 1000페이지가 넘는 것들이 많다. 국제 표준과 같은 문서들은 모든 항목에 대해서 명시해놓기 때문이다. 이런 것들을 토큰으로 바꾼다면 수십만 토큰이 될 수 있다.

그에 비해 paper 내에서 테스트를 위해 사용한 Jina AI의 모델들(jina-embeddings-v2-base-en 혹은 jina-embeddings-v3)조차 모델의 context가 8,192 토큰으로 작을 뿐만 아니라 테스트도 10페이지 내외의 결과를 기준으로 테스트했다.

그러다 보니 100페이지가 훌쩍 넘는 계약서의 전체 문맥을 보존하기 위해 모델에 입력하려 해도, max token은 약 30000대가 최대인 모델들이 많다. 그런데 문서를 통채로..?

결국 100페이지를 처리하기 위해 문서를 다시 일정 토큰 단위로 잘라야 한다면, 그 절단면 사이에서 문맥 단절이 또다시 발생하게 되어 Late Chunking의 도입 취지가 무색해진다. 그럼 왜 쓰지..?

트랜스포머 2차 시간 복잡도가 유발하는 연산 및 메모리 오버헤드

백번 양보해서 어떻게 어떻게 100,000 토큰의 문맥 창을 억지로 확보했다고 가정하더라도, 컴퓨팅 자원의 벽에 가로막히게 된다. 기본적으로 트랜스포머 모델의 셀프 어텐션 메커니즘은 시퀀스 길이 n^2에 비례하는 연산량과 메모리(VRAM)를 요구한다.

Lost in the Middle

100,000 토큰에 달하는 방대한 텍스트가 어텐션 레이어를 통과할 경우, 문서의 시작과 끝 부분의 정보는 상대적으로 잘 포착되지만 문서의 중간 텍스트(예: 40페이지~60페이지 구간)에 위치한 핵심 정보에 대한 가중치는 희석되어 의미적 중요성을 상실하는 ‘Lost in the middle’ 현상이 발생한다.

결론

개념상으로는 괜찮은 논문 같지만, 10페이지짜리 문서를 가지고 했다는 점에서 한계가 있는 것 같다. 대부분 RAG로 해결하려는 문제는 단순 특정 문서 한두페이지가 아닌, 수백페이지를 더 효율적으로 찾기 위해 AI를 도입해서 문제를 풀려고 했던 점인데 이러한 부분들을 관과하고 작성된 논문이 아닐까 생각한다.

만약에 무조건 써야 한다면, 이 late chunking 방식을 그대로 사용하는 것이 아닌, 방대한 문서를 기준으로 생각했을 때 다른 방식을 섞어 사용해야 할 것으로 보인다.

예를 들어, Anthropic에서 제안한 contextual retrieval과 같이, 해당 정보를 미리 물려놓고 임베딩을 생성하는 방식 등이 있을 수 있을 것 같다.

Contextual Retrieval in AI Systems

앤트로픽도 RAG 솔루션을 구축함에 있어서 이러한 청크들에 대한 맥락 정보가 없다는 점을 주목했다. 이에 Contextual Retrieval이라는걸 제안했는데, 각 청크를 벡터로 변환하기 전에, 해당 청크가 전체 문서에서 어떤 위치에 있고 각 청크가 전체 문서에서 어떤 의미인지 설명하는 짧은 문구(약 50~100 토큰)를 청크 앞에 붙인다.

<document> 
{{WHOLE_DOCUMENT}} 
</document> 
Here is the chunk we want to situate within the whole document 
<chunk> 
{{CHUNK_CONTENT}} 
</chunk> 
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else. 

이런 식으로 각 청크들에 대한 context를 각각 만드는데, 전체 문서는 프롬프트 캐싱을 통해 비용을 최소화 시키면서도 의미 기반 검색이 더 잘 될 수 있도록 한다는 방식이다.

해당 기술은 1M 컨텍스트 윈도우 사용하는 모델로 미리 돌려놓고 프롬프트 캐싱 한 다음에 각 청크들에 대해서 돌리면 어느정도 1000페이지가 되는 문서들도 가능할 정도의 context window를 가질 뿐만 아니라 프롬프트 캐싱도 가능해서 비용적 절감이 가능해 보여 보다 현실적인 대안으로도 생각해볼 수 있었다.