Evaluating Chunking Strategies for Retrieval

Evaluating Chunking Strategies for Retrieval | Chroma Research

📘 개요: AI 애플리케이션을 위한 새로운 검색 평가의 필요성

AI 애플리케이션, 특히 검색 증강 생성(RAG)에서 문서 청킹은 핵심 전처리 단계입니다. 하지만 기존 정보 검색(IR) 벤치마크는 문서 전체의 순위나 관련성에 초점을 맞춰, LLM이 실제로 중요하게 여기는 토큰 수준의 효율성을 측정하지 못하는 한계가 있었습니다. LLM은 컨텍스트 창 내에서 관련 정보의 위치에 민감하지 않으며, 관련 정보가 여러 문서에 흩어져 있을 수 있기 때문입니다. 이러한 문제를 해결하기 위해 이 보고서는 토큰 수준에서 검색 성능을 평가하는 새로운 프레임워크를 제안합니다.

B) 🧪 새로운 평가 프레임워크 및 지표

이 연구는 AI 응용 환경에 특화된 새로운 검색 평가 프레임워크를 제안합니다.

• 생성형 평가 데이터셋: LLM을 활용하여 주어진 문서 코퍼스에서 사실 기반의 쿼리와 관련 원문 발췌문을 생성합니다. 이 방식은 특정 도메인에 맞는 평가 데이터셋을 생성할 수 있게 해주며, 생성된 데이터는 임베딩 모델의 학습 데이터에 포함되지 않아 편향을 방지합니다.
• 데이터 필터링: 생성된 데이터의 품질을 높이기 위해 두 단계의 필터링을 거칩니다. 먼저, 쿼리들을 임베딩하여 코사인 유사도가 높은 중복 쿼리를 제거합니다. 다음으로, 쿼리와 관련 발췌문 간의 코사인 유사도를 계산하여 관련성이 낮은 쌍을 제거합니다.
• 토큰 단위 평가 지표:
  • IoU (Intersection over Union): 검색된 토큰과 실제 관련 토큰의 중첩 정도를 측정하는 지표로, 자카드 유사도(Jaccard similarity)에 기반합니다. 이는 검색의 효율성을 나타냅니다.
  • 정밀도(Precision): 검색된 토큰 중 관련 토큰의 비율입니다.
  • 재현율(Recall): 전체 관련 토큰 중 검색된 토큰의 비율입니다.
  • PrecisionΩ: 모든 관련 청크가 검색되었다고 가정했을 때의 이론적인 최대 정밀도로, 완벽한 재현율 하에서의 토큰 효율성 상한선을 보여줍니다.

C) 📚 평가에 사용된 코퍼스

평가는 다양한 도메인과 데이터 정제 수준을 가진 5개의 코퍼스를 기반으로 진행되었으며, 총 328,208개의 토큰과 472개의 쿼리로 구성됩니다.

코퍼스	토큰 수	특징
State of the Union 2024	10,444	구조가 잘 짜인 명확한 연설문
Wikitext	26,649	위키피디아의 검증된 우수 문서
Chatlogs	7,727	ChatGPT 대화 원문 (JSON 형식 포함)
Finance	166,177	금융 보고서 기반의 질의응답 데이터
Pubmed	117,211	생명 과학 및 바이오메디컬 분야의 논문

D) 🧩 평가된 청킹 알고리즘

이 보고서는 널리 사용되는 청킹 알고리즘과 함께 이 연구에서 새롭게 제안하는 알고리즘들을 평가합니다. ★는 이 연구에서 개발한 새로운 알고리즘을 의미합니다.

알고리즘	방식	특징
RecursiveCharacterTextSplitter	문자 기반 분할	구분자(\n\n, ., 등)를 사용해 재귀적으로 분할하는 휴리스틱 방식입니다.
TokenTextSplitter	고정 길이 분할	의미를 고려하지 않고 지정된 토큰 수로 텍스트를 분할합니다.
KamradtSemanticChunker	의미 기반 분할	문장 임베딩의 코사인 거리 불연속성을 감지하여 청크 경계를 설정합니다.
★ KamradtModifiedChunker	Kamradt 방식 개선	사용자가 최대 청크 길이를 직접 설정할 수 있도록 이진 탐색으로 임계값을 조정합니다.
★ ClusterSemanticChunker	의미 유사성 최적화	동적 프로그래밍을 사용해 청크 내 조각들의 코사인 유사도 합을 전역적으로 최대화합니다.
★ LLMSemanticChunker	LLM 직접 프롬프팅	LLM에게 직접 텍스트를 분할하고 분할할 위치의 인덱스를 반환하도록 요청합니다.

E) 📊 주요 실험 결과 요약

실험은 OpenAI text-embedding-3-large 임베딩 모델을 사용하여 5개의 청크를 검색했을 때의 평균 점수를 기준으로 합니다.

• RecursiveCharacterTextSplitter (청크 크기 200, 오버랩 없음)는 재현율은 최고 수준이 아니었지만, 정밀도(7.0%)와 IoU(6.9%)에서 높은 성능을 보이며 전반적으로 안정적인 성능을 입증했습니다.
• OpenAI 기본 설정 (TokenTextSplitter, 청크 800, 오버랩 400)은 재현율은 평균 이하였고, 다른 모든 지표에서는 최하위 수준의 성능을 보였습니다.
• ★ **ClusterSemanticChunker**는 청크 크기 400에서 두 번째로 높은 재현율(91.3%)을 기록했고, 청크 크기 200에서는 가장 높은 정밀도(8.0%)와 IoU(8.0%)를 달성했습니다.
• ★ **LLMSemanticChunker**는 가장 높은 재현율(91.9%)을 기록했지만, 다른 지표는 평균 수준이었습니다.
• KamradtSemanticChunker의 기본 설정은 평균 이하의 성능을 보였으나, 수정된 ★ **KamradtModifiedChunker**는 재현율과 다른 지표 모두에서 성능이 향상되었습니다.

F) ⚠️ 한계 및 향후 과제

• 데이터셋 한계: LLM이 생성하는 질문 스타일이 단조로울 수 있으며, 평가 데이터셋의 규모와 도메인 다양성이 부족합니다.
• 시간 및 비용 미반영: LLMSemanticChunker와 같이 실행 시간이 오래 걸리는 알고리즘의 경우, 실제 적용 시 시간 비용을 고려해야 하지만 이 연구에서는 다루지 않았습니다.
• 관련 발췌문 누락 가능성: LLM이 생성하지 않은 다른 관련 발췌문이 코퍼스에 존재할 수 있는 가능성을 고려하지 않았습니다.

G) 🧠 결론

이 보고서는 AI 애플리케이션 환경에 맞는 새로운 검색 평가 프레임워크를 성공적으로 제안하고, 이를 통해 청킹 전략이 검색 성능에 미치는 영향을 정량적으로 분석했습니다. 특히, 새롭게 제안된 ClusterSemanticChunker와 LLMSemanticChunker는 의미 기반 접근법을 통해 높은 재현율을 달성하며 우수한 성능을 입증했습니다. 전체 코드는 GitHub에 공개되어 있어 재현성과 추가 연구를 위한 확장성을 제공합니다.

---

H) QnA

H.1) Precision, Recall, IoU 측정 방식 (예시 포함)

이 보고서에서 사용된 Precision, Recall, IoU 등의 지표는 토큰 수준에서 계산됩니다. 즉, 문서 전체나 문단이 아닌, 개별 토큰 하나하나의 일치 여부를 따집니다.

핵심 아이디어: LLM이 생성한 “정답” (관련 발췌문에 포함된 관련 토큰들)과, 청킹 후 검색 시스템이 반환한 “결과” (검색된 청크에서 나온 토큰들)를 비교합니다.

가정:

• 관련 토큰 집합 (te): 쿼리에 대해 “정답”이라고 판단되는 토큰들의 집합입니다. (예: “Atlanta의 함선에 사용된 갑옷의 주요 특징은 무엇이었습니까?” 라는 쿼리에 대한 정답 발췌문에서 ‘Atlanta’, ‘갑옷’, ‘주요 특징’, ‘3인치’, ‘두꺼웠다’ 등의 의미를 담고 있는 토큰들)
• 검색된 토큰 집합 (tr): 청킹된 문서를 검색했을 때, 시스템이 반환한 청크들에서 나온 토큰들의 집합입니다. (예: 검색 시스템이 반환한 청크에 ‘Atlanta’s hull received two inches of armor’ 와 같은 내용이 있다면, 이 문장의 토큰들)

측정 방법 (예시):

문서 코퍼스: “The battleship Atlanta’s hull armor was 3 inches thick. It was backed by oak. The upper portion of Atlanta’s hull received two inches of armor.” 쿼리: “What were the main characteristics of the armor used on the ship Atlanta?”

1. LLM을 통한 “정답” 생성:

   • LLM이 위 문서와 쿼리를 보고, “Atlanta”, “함선”, “갑옷”, “주요 특징”, “3인치”, “두꺼웠다”, “상단 부분” 등의 토큰을 포함하는 관련 발췌문을 생성합니다.
   • 이 발췌문에서 **관련 토큰 집합 (te)**을 추출합니다. (간단화를 위해 여기서는 “Atlanta”, “함선”, “갑옷”, “주요”, “특징”, “3인치”, “두꺼웠다”, “상단”, “부분” 이라고 가정하겠습니다. 실제로는 더 많은 토큰이 될 것입니다.)
   • te = {"Atlanta", "함선", "갑옷", "주요", "특징", "3인치", "두꺼웠다", "상단", "부분"} (총 9개 토큰)

2. 청킹 후 검색 시스템의 “결과” 생성:

   • 만약 청킹 방식이 문장을 단위로 나누고, 검색 시스템이 첫 번째 문장과 세 번째 문장을 반환했다고 가정해 봅시다.
   • 검색된 청크: “The battleship Atlanta’s hull armor was 3 inches thick.” (A) + “The upper portion of Atlanta’s hull received two inches of armor.” (B)
   • 이 청크들에서 검색된 토큰 집합 (tr) 을 추출합니다. (간단화를 위해 “Atlanta”, “함선”, “갑옷”, “3인치”, “두꺼웠다”, “상단”, “부분”, “2인치” 라고 가정하겠습니다.)
   • tr = {"Atlanta", "함선", "갑옷", "3인치", "두꺼웠다", "상단", "부분", "2인치"} (총 8개 토큰)

3. 지표 계산:

   • 교집합 (te ∩ tr): 두 집합에 모두 있는 토큰들
     • te ∩ tr = {"Atlanta", "함선", "갑옷", "3인치", "두꺼웠다", "상단", "부분"} (총 7개 토큰)
   • 합집합 (te ∪ tr): 두 집합에 있는 모든 토큰들
     • te ∪ tr = {"Atlanta", "함선", "갑옷", "주요", "특징", "3인치", "두꺼웠다", "상단", "부분", "2인치"} (총 10개 토큰)
   • Precision (정밀도): |te ∩ tr| / |tr|
     • 7 / 8 = 0.875
     • 해석: 검색된 8개의 토큰 중 7개가 실제 관련 토큰이었습니다. (87.5%의 정확도)
   • Recall (재현율): |te ∩ tr| / |te|
     • 7 / 9 = 0.778
     • 해석: 실제 관련 토큰 9개 중 7개를 성공적으로 찾아냈습니다. (77.8%의 재현율)
   • IoU (Intersection over Union): |te ∩ tr| / |te ∪ tr|
     • 7 / 10 = 0.7
     • 해석: 전체 관련 토큰과 검색된 토큰의 합집합 중에서 겹치는 부분이 70%입니다. 이는 검색 결과의 전반적인 일치도를 보여줍니다. (분모를 |te| + |tr| - |te ∩ tr| 로 계산하는 것이 일반적이며, 이는 |te ∪ tr|과 같습니다.)
   • F1 Score: 2 * (Precision * Recall) / (Precision + Recall)
     • 2 * (0.875 * 0.778) / (0.875 + 0.778) ≈ 0.824
     • 해석: Precision과 Recall의 조화 평균으로, 두 지표를 종합적으로 평가합니다.

이처럼 각 토큰의 존재 여부를 정확히 파악하여 지표를 계산함으로써, LLM이 정보를 얼마나 정확하고 효율적으로 추출했는지를 토큰 수준에서 평가합니다.

---

H.2) KamradtModifiedChunker vs. ClusterSemanticChunker: 무엇이 다른가?

이 두 알고리즘은 모두 의미 기반 청킹을 시도하지만, 접근 방식과 최적화 목표에서 차이가 있습니다.

• KamradtSemanticChunker (기본):
  • 방식: 먼저 문장으로 텍스트를 분할한 후, 슬라이딩 윈도우 방식을 사용합니다. 윈도우를 이동하면서 각 윈도우(청크 조각)의 임베딩과 다음 윈도우 임베딩 간의 코사인 거리를 계산합니다. 이 거리가 특정 임계값(높은 거리)을 넘어서는 지점을 청크 경계로 판단합니다.
  • 특징: 탐욕적(Greedy) 접근 방식입니다. 즉, 각 단계에서 가장 가까운 경계를 찾으려고 합니다. 이는 구현이 비교적 간단하지만, 국소적인 최적해에 빠질 수 있습니다.
  • 한계: 기본 설정에서 임계값이 너무 높거나 낮으면 청크가 너무 크거나 작아질 수 있습니다.
• ★ KamradtModifiedChunker (수정 버전):
  • 개선점: KamradtSemanticChunker의 탐욕적 방식은 그대로 유지하되, 사용자가 원하는 최대 청크 길이를 직접 지정할 수 있도록 했습니다.
  • 작동 방식: KamradtSemanticChunker의 임계값 탐지 방식을 사용하지만, 탐지된 경계가 최대 길이를 넘으면 이진 탐색과 같은 방법을 사용하여 임계값을 조정합니다. 목표는 의미적 경계를 최대한 유지하면서도 지정된 최대 길이를 넘지 않는 것입니다.
  • 핵심: 사용자 제어력 강화. 의미 기반 분할의 장점을 살리면서도, 길이 제약을 통해 RAG 시스템의 입력 제한에 맞추기 용이합니다.
• ★ ClusterSemanticChunker (새로운 제안):
  • 목표: Kamradt 방식의 탐욕적 한계를 극복하고, 의미적 유사성을 전역적으로 최적화하는 것입니다.
  • 방식:
    1. 원본 텍스트를 작은 조각(예: 50 토큰 단위)으로 먼저 분할하고 각 조각의 임베딩을 계산합니다.
    2. 이 조각들을 사용하여 동적 프로그래밍(Dynamic Programming) 기법을 적용합니다.
    3. 동적 프로그래밍은 텍스트를 일련의 청크로 분할할 때, 모든 청크 내의 조각들 간 코사인 유사도 합을 최대화하는 방향으로 최적의 분할 지점을 찾습니다.
  • 핵심: 전역 최적화. 전체 문서를 보고 가장 의미적으로 뭉쳐있는 청크들을 만들어냅니다. 이는 “가장 자연스러운 의미 단위”를 찾으려는 시도입니다.
  • 단점: 전체 코퍼스의 통계를 바탕으로 최적화를 수행하므로, 데이터가 추가되면 청크를 다시 계산해야 하는 부담이 있습니다. KamradtModifiedChunker보다 계산 비용이 높을 수 있습니다.

간단히 말해:

• Kamradt Modified: “의미가 끊어지는 곳을 찾고, 너무 길어지지 않게 조절하자.” (사용자 정의 길이 제약 + 의미 기반)
• Cluster Semantic: “문서 전체에서 가장 의미적으로 똘똘 뭉쳐 있는 덩어리들을 만들자.” (전역 최적화 + 의미 기반)

---

H.3) 일반적으로 청크를 어떻게 하면 좋을까? (연구 결과 기반)

이 연구의 결과를 종합해 볼 때, “정답”은 없지만 몇 가지 경향과 추천 사항을 도출할 수 있습니다.

1. 기존 방법론의 한계 인지:

   • TokenTextSplitter (고정 길이, OpenAI 기본값)는 의외로 성능이 낮았습니다. 이는 의미나 구조를 전혀 고려하지 않기 때문으로 보입니다.
   • RecursiveCharacterTextSplitter의 기본 구분자(\n\n, \n, 등)만으로는 짧고 관련 없는 청크가 생성되어 성능이 저하될 수 있습니다. 이를 개선하기 위해 . ? ! 등을 추가하는 것이 좋습니다.

2. 의미 기반 청킹의 중요성:

   • Kamradt, ClusterSemantic, LLMChunker와 같이 의미를 고려하는 전략들이 전반적으로 더 좋은 성능을 보이는 경향이 있습니다. LLM은 문맥을 이해하는 데 뛰어나므로, 의미 단위로 잘 나뉜 정보를 제공할 때 더 효율적입니다.

3. 실험 결과 기반 추천:

   • RecursiveCharacterTextSplitter (개선된 구분자 사용): 적절한 청크 크기(연구에서는 200 토큰)와 오버랩 없음 설정에서 안정적이고 준수한 성능을 보였습니다. 구현이 간단하고 빠르다는 장점이 있습니다.
   • ClusterSemanticChunker: 의미적 유사성을 전역적으로 최적화하여 매우 높은 PrecisionΩ와 IoU를 달성했습니다. 의미적 응집성이 중요한 경우 좋은 선택이 될 수 있습니다. 청크 크기 200에서 뛰어난 성능을 보였습니다.
   • LLMSemanticChunker: 가장 높은 재현율을 기록했습니다. 이는 관련 정보가 흩어져 있더라도 최대한 많이 찾아내려는 경우 유리합니다. LLM에게 직접 맡기는 방식은 개념적으로 흥미롭지만, 비용이나 속도 이슈는 고려해야 합니다.

4. 고려 사항:

   • 청크 크기: 너무 작으면 관련 정보가 쪼개져서 검색 효율이 떨어지고, 너무 크면 하나의 청크 안에 너무 많은 불필요한 정보가 포함되어 비용이나 정확도에 문제가 생길 수 있습니다. 연구에서는 200 ~ 400 토큰 범위가 여러 전략에서 좋은 성능을 보였습니다.
   • 오버랩(Overlap): 청크 간에 일부 텍스트를 겹치게 하면, 의미가 청크 경계에 걸쳐 있을 때 정보를 놓치는 것을 방지할 수 있습니다. 이 연구에서는 오버랩 없이도 좋은 성능을 보인 경우가 많았지만, 실제 적용 시에는 상황에 따라 오버랩을 추가하는 것을 고려할 수 있습니다.
   • 도메인 특성: 금융, 의료 등 특정 도메인에서는 고유의 용어나 구조가 있을 수 있으므로, 해당 도메인에 특화된 청킹 전략이 필요할 수 있습니다.

결론적으로, “가장 좋은” 청킹 전략은 없습니다. 연구 결과로는 ClusterSemanticChunker나 LLMSemanticChunker가 뛰어난 성능을 보였지만, RecursiveCharacterTextSplitter 또한 개선된 설정 하에서 합리적인 성능을 제공합니다. 실제 적용 시에는 데이터 특성, RAG 시스템의 요구사항(정밀도 vs. 재현율), 그리고 계산 비용 등을 종합적으로 고려하여 선택해야 합니다.

---

H.4) 평가 데이터셋 생성 시 Corpus 전체를 봐야 하는가?

네, 일반적으로 평가 데이터셋을 생성하려면 해당 평가의 기반이 되는 Corpus 전체를 이해하고 활용해야 합니다.

그 이유는 다음과 같습니다.

1. LLM의 정보 생성 범위: LLM이 쿼리와 관련 발췌문을 생성할 때, 주어진 Corpus의 모든 정보를 참조할 수 있어야 합니다. 만약 Corpus의 일부만 LLM에게 제공한다면, LLM은 해당 부분에만 국한된 쿼리나 발췌문만 생성하게 되어 평가의 대표성을 잃게 됩니다.
2. 발췌문의 정확성 보장: LLM은 제공된 Corpus 내의 텍스트를 기반으로 정확히 일치하는 발췌문을 생성해야 합니다. Corpus 전체를 봐야 LLM이 “사실 기반”이고 “원본과 일치하는” 발췌문을 제대로 찾아낼 수 있습니다.
3. 다양한 쿼리 생성: Corpus 전체를 훑어보면서 LLM은 더 다양하고 복잡한 쿼리를 생성할 수 있습니다. 예를 들어, 여러 섹션에 걸쳐 있는 정보에 대한 쿼리, 특정 사건의 원인과 결과에 대한 쿼리 등이 가능해집니다.
4. 필터링의 정확성: 생성된 쿼리와 발췌문의 유사도를 계산하여 필터링하는 과정에서도 Corpus 전체의 맥락을 이해하는 것이 중요합니다.

하지만, “모든 Corpus를 다 본다”는 것이 반드시 “동시에 메모리에 로드한다”는 뜻은 아닙니다.

• Chunking & Sampling: 실제로 LLM에게 Corpus 전체를 한 번에 제공하기는 어렵습니다. 따라서 Corpus를 작은 청크로 분할하거나, LLM에게 쿼리와 발췌문 생성을 지시할 때 Corpus 내의 여러 부분을 샘플링하여 제공하는 방식으로 진행될 수 있습니다.
• Prompt Engineering: LLM에게 제공하는 프롬프트에 “다음 문서를 참고하여…” 와 같이 명확하게 지시하고, 필요한 경우 문서의 특정 부분을 발췌하여 함께 제공하는 방식으로 Corpus 전체의 정보를 활용하게 합니다.

이 연구에서도 “LLM에게 문서 코퍼스를 제공하고…” 라고 명시되어 있으며, 이 코퍼스가 평가 데이터셋 생성의 근거가 됩니다. 따라서 평가 프레임워크의 시작점으로서 Corpus 전체의 정보가 LLM에게 가용해야 한다는 의미로 이해하시면 됩니다.