롤업! 긴 텍스트 벡터 모델 청킹 전략 경연 대회

긴 텍스트 벡터 모델은 10페이지 분량의 텍스트를 하나의 벡터로 인코딩할 수 있어 강력해 보이지만 정말 실용적일까요?

많은 사람들이 이렇게 생각하죠... 꼭 그렇진 않죠.

바로 사용해도 되나요? 덩어리로 나눠서 사용해야 하나요? 어떻게 나누는 것이 가장 효율적일까요? 이 글에서는 긴 텍스트 벡터 모델을 위한 다양한 청킹 전략을 살펴보고 장단점을 분석하며 함정을 피할 수 있도록 도와드립니다.

긴 텍스트 벡터화의 문제

먼저, 전체 글을 하나의 벡터로 압축할 때 어떤 문제가 있는지 살펴봅시다.

문서 검색 시스템 구축의 예로, 하나의 문서에 여러 개의 주제가 포함될 수 있습니다. 예를 들어, ICML 2024 참석자 보고서의 이 블로그에는 컨퍼런스에 대한 소개와 Jina AI의 업무에 대한 프레젠테이션이 포함되어 있습니다(jina-clip-v1) 및 다른 연구 논문의 요약을 포함합니다. 전체 논문을 하나의 벡터로 만들면 이 벡터에는 세 가지 다른 주제의 정보가 혼합됩니다:

이로 인해 다음과 같은 문제가 발생할 수 있습니다:

1. 표현 희석

는 희석으로 인해 텍스트 벡터의 정밀도가 약해진다는 것을 나타냅니다. 블로그 게시물에 여러 주제가 포함되어 있지만그러나 사용자 검색 쿼리는 다음 중 하나에만 집중하는 경향이 있습니다.. 전체 기사를 하나의 벡터로 표현하는 것은 모든 주제 정보를 벡터 공간의 단일 점으로 압축하는 것과 같습니다. 모델의 입력에 더 많은 텍스트가 추가되면 이 벡터는 기사의 전체 주제를 점진적으로 나타내면서 특정 구절이나 주제에 대한 세부 정보가 희석됩니다. 이는 마치 여러 색소를 하나의 색으로 혼합하는 것과 같아서 사용자가 특정 색을 찾으려고 할 때 혼합된 색상에서 특정 색을 식별하기 어렵게 만듭니다.

2. 제한된 용량

모델에서 생성된 벡터 치수는 고정되어 있고 긴 텍스트에는 많은 정보가 포함되어 있어 변환 과정에서 필연적으로 정보 손실이 발생할 수밖에 없습니다. 마치 고화질 지도를 우표 크기로 압축하는 것과 같아서 많은 세부 정보가 보이지 않습니다.

3. 정보 손실

긴 텍스트 모델은 최대 8192개의 토큰만 처리할 수 있는 경우가 많으며, 더 나은 텍스트는 보통 뒤쪽에서 잘려야 하고, 핵심 정보가 문서 끝에 있는 경우 검색이 실패할 수 있습니다.

4. 세분화 요구 사항

질문과 답변 시스템과 같이 특정 텍스트 부분에 대해서만 벡터화를 수행해야 하는 애플리케이션도 있는데, 이 경우 벡터화를 위해 답을 포함하는 단락만 추출하면 됩니다. 이 경우에도 여전히 텍스트 청킹이 필요합니다.

긴 텍스트 처리 전략 3가지

실험을 시작하기 전에 개념적 혼란을 피하기 위해 먼저 세 가지 전략을 세분화하여 정의합니다:

1. 청크 금지:전체 텍스트를 단일 벡터로 직접 인코딩합니다.

2. 나이브 청크:먼저 텍스트를 여러 개의 텍스트 청크로 분할하고 개별적으로 벡터화합니다. 일반적으로 사용되는 방법에는 텍스트를 고정된 크기의 청크로 분할하는 고정 크기 청킹이 포함됩니다. 토큰 청크 수, 문장 기반 청킹: 문장으로 청킹, 의미 기반 청킹: 의미 정보에 따라 청킹합니다. 이 실험에서는 고정 크기 청크가 사용됩니다.

3. 늦은 청크:이는 텍스트를 쪼개기 전에 전체 텍스트를 읽는 새로운 방법이며 두 가지 주요 단계로 구성됩니다:

1. 코드 전문전체 문서를 먼저 인코딩하여 각 토큰의 벡터 표현을 가져와 전체 컨텍스트 정보를 보존합니다.
2. 청크 풀링청크 경계에 따라 동일한 텍스트 블록의 토큰 벡터를 평균 풀링하여 각 텍스트 블록에 대한 벡터를 생성합니다. 각 토큰의 벡터는 전체 텍스트의 컨텍스트에서 생성되므로 늦은 분할을 통해 블록 간의 컨텍스트 정보를 보존할 수 있습니다.

늦은 분할 대 일반 분할

최대 입력 길이를 초과하는 모델(예: 8192 토큰), 우리는 롱 레이트 청킹를 사용하면 먼저 문서를 여러 개의 겹치는 매크로 블록으로 분할하고 각 블록의 길이가 모델의 처리 가능한 범위 내에 있는 사전 분할 단계가 후기 분할에 추가됩니다. 그런 다음 표준 후기 분할 전략(인코딩 및 풀링)이 각 매크로 블록 내부에 적용됩니다. 매크로블록 간의 중첩은 컨텍스트 정보의 연속성을 보장하기 위해 사용됩니다.

늦은 점수 특정 구현 코드: https://github.com/jina-ai/late-chunking在 노트북 경험: https://colab.research.google.com/drive/1iz3ACFs5aLV2O_ uZEjiR1aHGlXqj0HY7?usp=sharing

그렇다면 어떤 방법이 가장 좋을까요?

비교를 위해 5개의 데이터 세트에 대한 데이터 세트를 사용했습니다. jina-embeddings-v3 실험은 긴 텍스트를 모두 모델의 최대 입력 길이(8192토큰)로 잘라내고 각각 64토큰의 텍스트 블록으로 분할하는 방식으로 진행되었습니다.

5개의 테스트 데이터 세트는 5개의 서로 다른 검색 작업에도 해당합니다.

아래 그림은 서로 다른 작업에 대한 3가지 방법 간의 성능 차이를 보여 주며, 모든 경우에 가장 좋은 방법은 없으며 특정 작업에 따라 선택이 달라집니다.

청킹 없음 대 일반 청킹 대 후기 청킹

👩‍🏫 구체적인 사실을 찾아서 쉽게 정리하는 것이 좋습니다.

텍스트에서 구체적이고 지역화된 사실 정보를 추출해야 하는 경우(예: "누가 물건을 훔쳤나요?"), Qsum과 같은 데이터 세트가 더 효과적입니다. ), QMSum, NarrativeQA, 2WikiMultiHopQA와 같은 데이터 집합에서는 전체 문서를 벡터화하는 것보다 일반 청킹이 더 나은 성능을 발휘합니다. 답변은 일반적으로 텍스트의 특정 부분에 위치하기 때문에 일반 청킹은 다른 불필요한 정보에 방해받지 않고 답변이 포함된 텍스트 청크를 더 정확하게 찾을 수 있습니다.

그러나 일반 청크는 문맥이 단절되고 텍스트의 참조 관계와 참조를 올바르게 구문 분석하기 위한 전역 정보가 손실될 수 있습니다.

👩‍🏫 글은 주제에 일관성이 있고 늦게 작성할수록 좋습니다.

나중에 구분하는 것은 주제가 명확하고 글의 구조가 일관된 경우에 더 효과적입니다. 나중에 구분하면 문맥을 고려하기 때문에 긴 텍스트 내의 참조 관계를 포함하여 각 부분의 의미와 관련성을 더 잘 이해할 수 있습니다.

그러나 문서에 관련 없는 콘텐츠가 많으면 늦게 채점할 때 '노이즈'를 고려하여 성능 퇴보와 정확도 저하를 초래할 수 있습니다. 예를 들어, NarrativeQA와 2WikiMultiHopQA는 문서에 관련 없는 정보가 너무 많기 때문에 일반 청킹만큼 성능이 좋지 않습니다.

청크 크기가 영향을 주나요?

다음 그림은 청크 크기가 다른 여러 데이터 세트에 대한 일반 청크 및 후기 청크 방법의 성능을 보여줍니다:

청크 크기가 다른 일반 청크와 후기 청크의 성능 비교

그림에서 볼 수 있듯이 최적의 청크 크기는 실제로 특정 데이터 집합의 모양에 따라 달라집니다.

후기 분할 방법의 경우, 청크가 작을수록 컨텍스트 정보를 더 잘 포착하므로 더 잘 작동합니다. 특히, 데이터 세트에 주제와 관련이 없는 콘텐츠가 많은 경우(NarrativeQA 데이터 세트의 경우), 너무 많은 컨텍스트는 오히려 노이즈를 유발하고 성능을 저하시킬 수 있습니다.

일반 청크의 경우, 청크가 클수록 포함된 정보가 더 포괄적이고 손실이 적기 때문에 더 효과적일 때가 있습니다. 하지만 청크가 너무 크고 정보가 너무 복잡하면 검색의 정확도가 떨어질 수 있습니다. 따라서 최적의 청크 크기는 특정 데이터 집합과 작업에 맞게 조정해야 하며, 정답은 없습니다.

다양한 청킹 전략의 장단점을 이해한 후 올바른 청킹 전략을 선택하려면 어떻게 해야 할까요?

1. 전체 텍스트 벡터화(청크 없이)는 어디에 적합한가요?

• 테마는 단수이며, 핵심 정보가 처음에 집중되어 있습니다:예를 들어, 구조화된 뉴스 기사에서 핵심 정보는 헤드라인과 첫 문단에 있는 경우가 많습니다. 이 경우 전체 텍스트 벡터화를 직접 사용하면 모델이 핵심 정보를 캡처할 수 있기 때문에 일반적으로 좋은 결과를 얻을 수 있습니다.
• 일반적으로 모델에 가능한 한 많은 텍스트 콘텐츠를 넣어도 검색 결과에 영향을 미치지 않습니다. 그러나 긴 텍스트 모델은 시작 부분(제목, 소개 등)에 더 많은 주의를 기울이는 경향이 있으며 중간 및 끝 부분의 정보는 무시될 수 있습니다. 따라서 핵심 정보가 문서의 중간이나 끝에 있는 경우 이 방법은 훨씬 덜 효과적입니다.
• 자세한 실험 결과는 여기에 나와 있습니다:https://jina.ai/news/still-need-chunking-when-long-context-models-can-do-it-all

2. 나이브 청크는 어디에 적합한가요?

• 다양한 주제, 특정 정보를 검색해야 하는 경우텍스트에 두 개 이상의 주제가 포함되어 있거나 사용자 쿼리가 텍스트의 특정 사실을 대상으로 하는 경우 일반 청크가 좋은 선택입니다. 정보 희석을 효과적으로 방지하고 특정 정보 검색의 정확도를 높일 수 있습니다.
• 현지화된 텍스트 스니펫 표시 필요검색 엔진과 마찬가지로 검색어와 관련된 텍스트 스니펫을 결과에 표시해야 하므로 청킹 전략이 필요합니다.
• 또한 청크는 더 많은 텍스트 블록을 벡터화해야 하므로 저장 공간과 처리 시간에 영향을 미칩니다.

3. 늦은 청크는 어디에 적합할까요?

• 주제 일관성, 맥락 정보에 대한 필요성에세이, 긴 보고서 등과 같이 일관된 주제가 있는 긴 텍스트의 경우, 후반 분할 방법을 사용하면 문맥 정보를 효과적으로 유지하여 텍스트의 전체적인 의미를 더 잘 이해할 수 있습니다. 특히 독해나 긴 텍스트의 의미 일치와 같이 텍스트의 여러 부분 간의 관계를 이해해야 하는 작업에 적합합니다.
• 로컬 디테일과 글로벌 의미의 균형 필요후기 분할 방법은 작은 청크 크기에서 로컬 세부 정보와 글로벌 의미의 균형을 효과적으로 맞출 수 있으며, 많은 경우 다른 두 방법보다 더 나은 결과를 얻을 수 있습니다. 그러나 문서에 관련 없는 내용이 많은 경우 이러한 관련 없는 정보를 고려하기 때문에 늦게 분할하는 것이 효과에 영향을 미친다는 점에 유의해야 합니다.

평결에 도달하기

긴 텍스트 벡터화 전략의 선택은 정답이 없는 복잡한 문제이며, 앞서 언급한 텍스트 길이, 주제 수, 주요 정보의 위치 등 데이터의 특성과 검색 목표를 고려해야 합니다.

이 백서에서는 다양한 청킹 전략에 대한 비교 분석 프레임워크를 제공하고 실험 결과를 통해 몇 가지 참고 자료를 제공하고자 합니다. 실제 적용 시에는 더 많은 실험을 비교하여 시나리오에 가장 적합한 전략을 선택할 수 있습니다.

긴 텍스트 벡터화에 관심이 있는 경우jina-embeddings-v3고급 긴 텍스트 처리 기능, 다국어 지원, 늦은 채점 기능을 제공하는 이 앱은 한 번 사용해 볼 가치가 있습니다.