-
Notifications
You must be signed in to change notification settings - Fork 1
Benchmark
Docling HybridChunker(baseline)와 Evidence Chunker(EU)를 같은 조건(같은 임베더, 같은 파싱)에서 비교한 최종 결과.
전체 실험 과정은 Experiments에 별도로 정리되어 있다.
- 문서: 90개 PDF
- 문항: 2,725개 (cell_value / table_about / context_dependent)
- baseline: Docling
HybridChunker단독 - 임베더:
all-MiniLM-L6-v2
| 지표 | baseline | Evidence Chunker | 갭 |
|---|---|---|---|
| Recall | 0.574 | 0.625 | +5.1pp |
| EM | 0.314 | 0.569 | +25.5pp |
95% CI 반폭 ±1.88pp — EM 갭(+25.5pp)이 CI의 13배 이상이라 통계적으로 명확하다.
| 유형 | n | baseline EM | EU EM | 갭 | baseline Recall | EU Recall | 갭 |
|---|---|---|---|---|---|---|---|
| cell_value | 1727 | 0.415 | 0.669 | +25.4pp | 0.629 | 0.687 | +5.7pp |
| table_about | 462 | 0.290 | 0.450 | +16.0pp | 0.374 | 0.392 | +1.7pp |
| context_dependent | 536 | 0.009 | 0.351 | +34.1pp | 0.565 | 0.625 | +6.0pp |
context_dependent(정답이 표+설명 문단 결합에만 있는 유형, 이 프로젝트가 해결하려는 핵심 케이스)는 baseline이 사실상 전혀 풀지 못하고 있다. 청킹 단계에서 캡션·표·문단이 갈라지는 문제가 실측으로 가장 뚜렷하게 드러나는 지점이다.
큰 청크가 baseline의 한계를 상쇄할 수 있는지, 다중 벡터 색인만으로 충분한지, semantic chunking으로 대체 가능한지를 확인한다.
| 대조군 | R@1 | EM | 비고 |
|---|---|---|---|
| base (baseline, 기본 청크) | 0.574 | 0.314 | |
| base1024 (청크 1024토큰) | 0.418 | 0.301 | 청크를 키워도 EM은 오히려 하락 |
| base2048 (청크 2048토큰) | 0.304 | 0.274 | 무관한 텍스트가 섞여 임베딩이 흐려짐 |
| rowsplit (표만 행 단위 다중 색인) | 0.628 | 0.352 | 다중 벡터 색인 자체의 효과는 +3.8pp뿐 |
| semantic (LangChain SemanticChunker) | 0.121 | 0.145 | baseline보다도 성능이 좋지 않음 |
| EU (Evidence Chunker) | 0.625 | 0.569 |
rowsplit 대조군 기준으로, EM 개선분(+25.5pp) 중 다중 벡터 색인 자체의 기여는 +3.8pp이고 나머지 +21.7pp는 캡션+문맥 결합(EU 고유 구조)의 효과라고 볼 수 있다.
| 유형 | R@1 | R@5 | R@10 |
|---|---|---|---|
| base | 0.574 | 0.831 | 0.904 |
| rowsplit | 0.628 | 0.863 | 0.920 |
| semantic | 0.121 | 0.245 | 0.314 |
| EU (flat) | 0.636 | 0.771 | 0.821 |
| EU (max-pool) | 0.636 | 0.844 | 0.885 |
EU maxpool(같은 EU의 여러 유닛 중 최고 점수만 남기는 재랭킹)이 헤드라인 수치.
trade-off: max-pool 적용 후 R@5는 baseline 대비 여전히 우위(+1.4pp)지만, R@10은 baseline이 근소하게 앞선다(0.885 vs 0.904, −1.9pp). 자세한 원인 분석은 Limitations & Roadmap 참고.
bbox_threshold=300pt가 임의의 값이 아니라 실제로 의미 있는 경계인지 검증한다.
context_dependent 문항을 표-문단 거리(dist_pt) 기준으로 창 안/밖으로 나누어 검증한다.
| 구간 | n | baseline EM | EU EM |
|---|---|---|---|
| 창 안 (≤300pt) | 409 | 0.012 | 0.455 |
| 창 밖 (>300pt) | 127 | 0.000 | 0.016 |
창 안에서는 EU가 baseline을 +44.3pp 압도적으로 앞선다. 즉, 300pt 반경 안의 문단을 캡션·표와 묶는 구조가 실제로 문제를 해결한다.
창 밖에서는 EU도 거의 풀지 못한다(0.016). 이는 설계상 오류가 아닌 정답 근거가 애초에 300pt 밖에 있어 EU 설계상 수집 대상이 아니기 때문이다.
실제로 bbox_threshold를 100~1000pt로 스윕해도 통계적으로 유의미한 개선이 없었다. (Configuration의 bbox_threshold 참고)
| 기준 | 문서 수 | baseline EM | EU EM | 갭 |
|---|---|---|---|---|
| 전체 90개 문서 평균 (macro) | 90 | 0.320 | 0.629 | +30.9pp |
| 10문항 이상만 | 78 | 0.319 | 0.604 | +28.6pp |
micro(+25.5pp)와 macro(+30.9pp) 갭이 같은 방향이고, 소형 문서를 제외해도(+28.6pp) 안정적이다. 특정 대형/소형 문서 몇 개가 결과를 왜곡하는 것이 아니다.
| 구분 | 문항 수 | 비율 |
|---|---|---|
| 둘 다 정답 | 1181 | 43.3% |
| EU만 정답 | 521 | 19.1% |
| 둘 다 오답 | 641 | 23.5% |
| baseline만 정답 | 382 | 14.0% |
net 승수(521−382=139건, 5.1%p)가 Recall 갭(0.625−0.574=5.1pp)과 정확히 일치한다.
EU가 지는 382건 중 다수는 "EU wrong page"이다. 즉, 캡션·문맥 추출 실패가 아니라 문서 안에 구조적으로 비슷한 표가 여러 개 있어 검색 단계에서 틀린 표를 고른 경우다. 자세한 원인 분석은 Limitations & Roadmap #2 참고.