2022년식 청킹을 멈춰라 — 질의에 따라 달라지는 검색 해상도

자연스러운 한국어 제목: 2022년식 청킹을 멈춰라 — 질의에 따라 달라지는 검색 해상도

URL: https://www.youtube.com/watch?v=r9OwPx_HoV0
날짜: 2026-09-16 (YouTube 원본 업로드일)
채널: aiDotEngineer
발표: Yuval Belfer, AI21 Labs

---

메타데이터

• 원문 제목: Stop Chunking Like It's 2022 — Yuval Belfer, AI21 Labs
• 한국어 제목: 2022년식 청킹을 멈춰라 — 질의에 따라 달라지는 검색 해상도
• 출처: aiDotEngineer
• 주제: RAG(Retrieval-Augmented Generation) 검색, 청킹(chunking), 멀티스케일 인덱싱(multi-scale indexing), Reciprocal Rank Fusion(RRF)
• 분류: ai-llm
• Video ID: r9OwPx_HoV0
• 원본 업로드일: 2026-09-16
• 처리일: 2026-09-17
• 재생 시간: 약 18분

---

📌 핵심 질문 / 청크 크기 선택의 핵심 논점

==모든 질의에 최적인 단일 청크 크기는 존재하지 않으므로, 인덱싱 단계에서 하나를 고정하는 대신 여러 해상도를 함께 인덱싱하고 검색 시점에 순위를 융합해야 한다.==

• 작은 청크는 한 문장에 담긴 구체적 사실을 살리지만 문맥을 잃는다.
• 큰 청크는 장면·문서의 전체 맥락을 보존하지만 세부 사실이 임베딩 속에서 희석된다.
• 동일 코퍼스에서도 질의의 성격에 따라 최적 청크 크기가 달라지며, 오라클 실험에서 고정 전략 대비 약 20~40%의 recall 여지가 확인됐다.

청킹은 한 번 정하면 잊어도 되는 전처리 파라미터가 아니라, 검색 질의와 결합된 표현(representation) 설계 문제다. 질의를 아직 모르는 인덱싱 시점에는 최적 해상도를 선택할 정보가 없고, 질의를 아는 검색 시점에는 이미 청크 크기가 고정되어 있다. 동일 문서를 50·100·200·500·1,000·2,000 토큰 같은 여러 윈도 크기로 인덱싱하고, 각 검색 결과가 가리키는 부모 문서에 투표하게 만든 뒤 RRF로 합치면 이 정보 비대칭을 간단한 인프라 변경으로 완화할 수 있다.

1. 청킹을 다시 검색 인프라의 중심으로 보기

청킹 논쟁의 핵심은 RAG의 유행이나 에이전트의 유무가 아니라, 원문을 고정 길이 벡터 표현으로 압축하는 순간 어떤 정보가 사라지는가에 있다.

1.1. RAG가 죽었다는 선언과 남아 있는 검색 문제

1. 반복되는 RAG 사망 선언

   1. 유행의 교체: X와 LinkedIn에는 RAG가 죽었다는 말이 반복되고, MCP(Model Context Protocol)도 한동안 죽었다는 농담의 대상이 됐다.
   2. 새로운 구호: “Long live agentic retrieval”, “Long live agentic search”라는 구호가 등장했지만, RAG가 죽지 않았다고 말하는 사람조차 무언가를 죽은 것으로 선언해야 하는 분위기가 이어졌다.

2. 청킹을 희생양으로 삼는 이유

   1. 고정 청킹에 대한 반감: “청킹에 투자하지 말라”, “청킹은 끝났다”는 주장은 에이전트형 검색이 등장했기 때문에 힘을 얻었다.
   2. 도구의 한계: ls, find, 파일 검색 같은 에이전트 도구는 훌륭하지만, 데이터가 많고 질의 유형이 다양하면 모든 탐색 요구를 감당하지 못한다.

1.2. 두 단계로 나뉘는 RAG 파이프라인

1. 인덱싱 단계의 고정 결정

   1. 전처리: 대량의 데이터를 읽고 나눌 청크 크기를 결정한다.
   2. 저장: 나눈 청크를 임베딩해 Vector DB에 저장하고, 이후에는 선택한 크기를 바꾸기 어렵다.

2. 질의별로 조정 가능한 검색 단계

   1. 반복 최적화의 용이성: 실제 질의를 보면서 top-k 값을 조절할 수 있다.
   2. 검색 기법의 조합: hybrid search 같은 기법을 시도할 수 있어 인덱싱보다 훨씬 재미있고 즉각적인 최적화 대상으로 취급된다.

3. 잘못 놓인 최적화의 초점

   1. 검색 튜닝의 매력: 질의가 이미 존재하므로 결과를 보고 바로 바꿀 수 있다는 점이 검색 튜닝을 선호하게 만든다.
   2. 청킹의 인프라화: retrieval tuning이 사라질 대상이라면 이미 에이전트 검색이 그 역할을 상당 부분 대체했지만, 청킹은 여전히 데이터가 검색되는 방식을 결정하는 기반 인프라로 남는다.

2. 에이전트 검색만으로 해결되지 않는 규모의 문제

질의마다 도구를 호출하는 방식도 데이터 구조가 검색 친화적으로 정리되어 있지 않으면 불필요한 탐색과 토큰 소비를 만든다.

2.1. 비용·토큰·디렉터리 구조의 병목

1. 에이전트 검색의 비용

   1. 대규모 데이터의 부담: 데이터 규모가 커질수록 에이전트가 여러 파일과 디렉터리를 확인하는 비용이 커진다.
   2. 토큰 최대화(token maxing): 검색 결과를 많이 읽어 모델 컨텍스트에 넣는 방식은 비용을 키우며, 이 문제가 계속 논의되는 이유가 된다.

2. 정렬되지 않은 데이터의 문제

   1. 폴더 탐색의 한계: 원자료가 폴더와 디렉터리에 질의가 요구하는 집계 단위로 정리되어 있지 않으면, 도구가 있어도 한 번에 답을 찾지 못한다.
   2. 검색 이후의 집계: 각 위치에서 사실을 찾은 뒤 결과를 합쳐야 하므로, 단순한 관련 문서 검색보다 더 많은 호출과 컨텍스트가 필요하다.

2.2. FIFA 월드컵 디렉터리 비유

1. 데이터 배치

   1. 연도별 폴더: 1998년, 2002년처럼 각 FIFA 월드컵 대회를 하나의 디렉터리로 저장한다.
   2. 질의의 형태: “월드컵에서 가장 많이 우승한 팀은 어디인가?”라는 질문은 한 대회의 문서가 아니라 모든 대회의 결과를 가로질러야 한다.

2. 필요한 탐색과 답

   1. 전체 순회: 모든 폴더를 열어 우승 팀을 확인하고 횟수를 집계해야 한다.
   2. 최종 결과: 대화가 진행되는 시점의 기록 기준으로 브라질이 가장 많이 우승한 팀이라는 답이 나온다.

3. 비유가 드러내는 구조적 결함

   1. 도구와 인덱스의 차이: find나 ls가 존재해도 데이터의 의미 단위가 미리 연결되어 있지 않으면 질의가 요구하는 전역 답을 바로 반환하지 못한다.
   2. 검색 품질의 선행 조건: 더 영리한 에이전트보다 질의에 맞는 표현과 인덱스 구조를 먼저 준비해야 불필요한 순회가 줄어든다.

3. 고정 청킹이 만드는 손실

실무에서 자주 선택하는 512 또는 1,000 토큰은 평균적으로 괜찮아 보일 뿐, 모든 질문을 만족시키는 정답이 아니다.

3.1. 큰 청크와 작은 청크 사이의 교환

1. 큰 청크의 장점과 손실

   1. 전체 그림 보존: 한 청크 안에 넓은 문맥이 들어가므로 사건이나 설명의 전체 관계를 파악하기 쉽다.
   2. 세부 정보 희석: 하나의 고정 크기 임베딩에 다양한 정보가 몰리면서 특정 사실이 묻히고, 관련 없는 내용이 함께 검색될 수 있다.

2. 작은 청크의 장점과 손실

   1. 구체성 보존: 짧은 문장이나 단일 사실이 청크 안에서 선명하게 남아 특정 질의와 잘 맞는다.
   2. 맥락 상실: 주변 문장과 사건의 연결이 끊겨 답이 여러 문장이나 장면에 흩어져 있을 때 의미를 복원하지 못한다.

3. 손실 압축으로서의 청킹

   1. 고정 차원 임베딩의 압축: 청크가 커지면 고정 차원의 벡터가 더 많은 종류의 정보를 압축해야 하므로 세부 신호를 잃는다.
   2. 어느 선택도 완전하지 않음: 청크를 크게 하든 작게 하든 정보의 한 부분을 포기하게 되며, 청킹 자체가 lossy compression(손실 압축)이 된다.

3.2. “데이터셋에 맞춰 튜닝하면 된다”는 반론

1. 평균 성능의 함정

   1. 데이터셋별 최적화의 유혹: 특정 코퍼스에서 좋은 청크 크기를 찾고 그 데이터에 맞춰 시스템을 최적화했다고 생각하기 쉽다.
   2. 질의 분포의 변화: 같은 코퍼스라도 에이전트, 업무 흐름, 사용자가 던지는 질문이 달라지면 필요한 정보 해상도가 달라진다.

2. 벤치마크와 실제 RAG의 차이

   1. 과적합 직관: 모델을 벤치마크에 과적합하기 쉬운 것처럼, 평균 지표 하나로 청크 크기를 고르면 특정 질문군의 실패를 감춘다.
   2. 단일 데이터셋으로 해결되지 않음: 여러 종류의 에이전트와 시스템, 워크플로를 경험해도 “이 데이터에는 이 크기”라는 결론만으로는 질의별 차이를 없앨 수 없다.

3.3. 청크 크기는 질의 의존적이다

1. 정보 비대칭

   1. 인덱싱 시점: 청크 크기를 통제할 수 있지만 미래의 질의를 알 수 없어 각 질문에 맞춘 선택을 할 수 없다.
   2. 검색 시점: 질의를 알고 있지만 데이터베이스가 이미 고정되어 있어, 매번 원점으로 돌아가 전처리와 임베딩을 다시 할 수 없다.

2. 가설

   1. 질의별 해상도: 구체적 단일 사실을 찾는 질문과 장면 전체의 관계를 묻는 질문은 서로 다른 크기의 창(window)을 선호한다.
   2. 남겨진 성능: 고정 크기를 평균에 맞추는 일은 많은 개별 질의에서 최적보다 낮은 recall을 받아들이는 일이며, 여러 크기를 선택할 수 있다면 상당한 성능 여지가 남아 있다.

4. 실험: 같은 코퍼스, 서로 다른 최적 청크

오라클 실험은 질의별 최적 크기를 실제 시스템으로 예측하려는 것이 아니라, 고정 크기 전략이 놓치는 상한선을 측정하는 통제 실험이다.

4.1. 여섯 가지 윈도 크기로 복제한 인덱스

1. 실험 구성

   1. 동일 코퍼스 복제: 데이터셋 하나를 여러 번 복제하고 각 복제본에 서로 다른 sliding-window 청크 크기를 적용한다.
   2. 윈도 크기: 50, 100, 200, 500, 1,000, 2,000 토큰처럼 여섯 가지 해상도의 데이터베이스를 따로 만든다.

2. 검증한 데이터셋

   1. QMSum: 회의록에서 특정 논의 지점을 묻는 질의응답 데이터셋이다.
   2. NarrativeQA: 소설과 이야기의 줄거리·인물 관계를 묻는 질의응답 데이터셋으로, 세부와 연결된 맥락을 함께 요구한다.
   3. Seinfeld custom dataset: Seinfeld 대본에 대한 trivia 질문으로, “nothing에 대한 trivia”라는 농담을 담은 사내 제작 데이터셋이다.

3. 추가 비교 대상

   1. FinanceBench: 금융 문서 질의를 포함한 데이터셋에서도 동일한 멀티스케일 경향을 확인했다.
   2. 공통점: 회의 대화, 서사적 이야기, TV 대본, 금융 자료처럼 정보가 배치되는 방식이 다른 코퍼스에서 질문별 차이가 반복됐다.

4.2. Seinfeld의 반대되는 두 질문

1. 짧은 사실 질의

   1. 질문: “Jerry가 가장 좋아하는 교회의 이름은 무엇인가?”라는 매우 구체적인 질문은 답이 한정된 문장에 들어 있을 가능성이 높다.
   2. 결과: 100토큰 청크를 사용하면 정답 문서가 1위에 오르지만, 더 큰 윈도에서는 50위 아래로 밀린다.

2. 장면에 걸친 맥락 질의

   1. 질문: “Jerry가 자신의 nemesis이자 pure evil이라고 부르는 사람은 누구인가?”라는 질문의 답은 한 문장에 고립되지 않고 장면에 걸쳐 나타난다.
   2. 결과: 정답은 Newman이지만 작은 청크만 쓰면 해당 맥락을 회수하지 못하고, 더 넓은 문맥을 가진 표현이 필요하다.

3. 실험이 고정 크기에 주는 반례

   1. 같은 데이터: 두 질문은 동일한 Seinfeld 코퍼스와 동일한 검색 시스템을 사용한다.
   2. 반대되는 요구: 한 질문에서 100토큰이 1위였던 사실이 다른 질문에서도 통하지 않으며, 질의가 최적 청크 크기를 결정한다.

4.3. 오라클 곡선과 20~40%의 성능 여지

1. 오라클 구성

   1. 질의별 선택: 각 질문에 대해 여섯 인덱스 중 가장 높은 recall을 낸 결과를 사후적으로 선택한다.
   2. 현실적 시스템이 아님: 정답을 미리 알고 고르는 방식이므로 바로 배포할 수 있는 알고리즘이 아니라 가능한 상한선을 보여주는 장치다.

2. 그래프 읽기

   1. 축의 의미: y축은 recall로 높을수록 좋고, x축은 검색한 청크 수 K이며 recall@K를 비교한다.
   2. 선의 의미: 파란색 선은 각 고정 청크 크기의 성능이고, 주황색 선은 질의별 최적 결과만 고른 오라클이다.

3. 핵심 결과

   1. 지배적인 하나가 없음: 여러 파란색 선이 서로 교차하므로 모든 데이터와 K에서 다른 크기를 압도하는 단일 크기가 없다.
   2. 상당한 격차: 오라클과 고정 크기 선 사이의 간격은 단순한 청킹 전략만으로 약 20~40%에 이르며, 512나 1,000 같은 임의의 선택이 치르는 비용을 드러낸다.

5. 멀티스케일 인덱싱과 RRF

최적 크기를 질의별로 예측하려고 복잡한 분류기를 만들기보다, 여러 표현을 미리 보유하고 검색 시점에 증거를 합치는 편이 단순하다.

5.1. 인덱싱과 검색의 병렬화

1. 멀티스케일 인덱싱

   1. 여러 해상도 저장: 동일 데이터베이스를 윈도 크기별로 복제하고 각 크기에서 별도의 인덱스를 만든다.
   2. 단순한 전처리: 학습된 청킹 모델이나 특별한 전처리 없이 sliding-window 청킹을 반복한다.

2. 질의 시점의 병렬 검색

   1. 전체 인덱스 호출: n개의 윈도 크기를 저장했다면 질의마다 n개의 검색 호출을 실행하며, 여섯 크기를 썼다면 여섯 검색 호출이 발생한다.
   2. 동시 처리: 각 검색을 병렬로 수행하면 호출 수가 늘어도 순차 실행처럼 지연 시간이 누적되지 않는다.

3. 선택 시점의 이동

   1. 기존 방식: 인덱싱 때 하나의 크기를 고르고 검색 때 그 결정을 그대로 사용한다.
   2. 새 방식: 인덱싱 때 여러 크기를 보존하고, 질의 정보가 존재하는 검색 단계에서 모든 해상도의 신호를 조합한다.

5.2. 청크 순위를 문서 투표로 바꾸기

1. 직접 순위 비교가 불가능한 이유

   1. 서로 다른 단위: 50토큰 청크와 2,000토큰 청크는 담은 정보량과 후보 분할 방식이 달라 청크 자체의 순위를 곧바로 비교하기 어렵다.
   2. 유사도 점수의 비호환성: 크기별 인덱스의 embedding similarity score는 동일한 척도로 보정되지 않으므로 절대값을 합산하면 불안정하다.

2. 부모 문서로 정규화

   1. 검색 단위 확장: 각 인덱스에서 청크가 검색되면 그 청크가 속한 전체 문서를 함께 반환한다.
   2. 비교 가능한 후보: 크기는 달라도 모든 결과가 동일한 부모 문서 ID를 가리키게 만들면 크기별 순위를 문서 수준에서 비교할 수 있다.

3. 투표로서의 검색

   1. 청크의 표: 관련 청크 하나가 부모 문서에 한 표를 주고, 높은 순위의 청크일수록 더 큰 표의 가치를 갖는다.
   2. 일관된 문서의 승리: 한 크기에서 여러 번 포착되거나 여러 크기에서 반복적으로 상위에 오른 문서가 최종 순위에서 올라간다.

5.3. Reciprocal Rank Fusion의 역할

1. RRF 선택 이유

   1. 순위 기반 결합: 절대 유사도 점수 대신 각 목록에서의 순위만 사용해 서로 다른 인덱스의 점수 보정을 요구하지 않는다.
   2. 모델 불문 방식: 별도 학습 모델이 아니라 짧은 스크립트로 구현되는 model-agnostic rank aggregation이다.

2. 개념적 산식

   1. 문서 점수: 문서 (d)의 점수는 모든 윈도 크기에서 그 문서에 속한 검색 청크의 역순위 투표를 합산한다.
   2. 표현식: (S_d = \sum_{w\in W}\sum_{i\in I_w} \frac{1}{r_{iw}+1})로 쓸 수 있으며, (W)는 윈도 크기 집합, (I_w)는 윈도 (w)에서 회수된 문서 (d)의 청크 집합, (r_{iw})는 해당 청크의 순위다.

3. 오라클과 실제 방식의 차이

   1. 오라클: 정답을 보고 질문마다 최적 윈도를 고른다.
   2. RRF: 정답을 모르는 실제 검색에서 모든 윈도의 순위 신호를 투표로 합쳐 오라클의 이점을 근사한다.

6. 결과, 비용, 그리고 구현 판단

멀티스케일 방식은 청킹이나 임베딩 모델을 새로 학습하지 않고도 고정 크기 기준을 꾸준히 넘었으며, 비용은 주로 저장 공간으로 이동한다.

6.1. 네 데이터셋에서 확인된 개선

1. 고정 크기 기준과의 비교

   1. 행과 열: 결과 히트맵의 각 행은 50·100·200 등 청크 크기이고, 각 열은 recall@1부터 recall@10까지의 값이다.
   2. 결합 방식의 행: 모든 크기를 검색한 뒤 RRF로 결합한 방식이 별도의 마지막 행으로 표시된다.

2. 성능 패턴

   1. 전반적 우위: recall@K가 무엇이든 RRF 결합 방식이 고정 크기 행보다 계속 높은 결과를 보인다.
   2. 비자명한 조합: 단순히 여러 검색 결과를 모으는 것만으로 끝나지 않고, 서로 다른 청크 순위를 부모 문서 기준으로 올바르게 결합했을 때 품질이 올라간다.

3. 데이터셋 범위

   1. 네 종류의 평가: QMSum, NarrativeQA, Seinfeld, FinanceBench에서 멀티스케일 결과가 최선의 고정 크기와 같거나 이를 넘었다.
   2. 개선 폭: 많은 조건에서 약 20~30~40% 수준의 개선이 나타났고, 별도로 언급되지 않은 MTEB 계열 평가에서도 데이터셋에 따라 10~40%의 개선을 확인했다.

6.2. 추가 메모리와 거의 없는 지연 증가

1. 저장 비용

   1. 복제의 대가: 여러 윈도 크기의 청크를 모두 임베딩하고 저장해야 하므로 메모리 사용량이 대략 2~5배 늘어난다.
   2. 고정된 상수 배수: 실험에서 관찰된 증가는 데이터가 무한히 폭증하는 형태가 아니라 선택한 윈도 수에 대응하는 추가 인덱스 비용이다.

2. 검색 지연

   1. 병렬 실행: 여러 인덱스의 검색을 동시에 처리하면 호출 수 증가가 순차 지연으로 그대로 이어지지 않는다.
   2. 가벼운 융합: RRF는 순위 목록을 더하는 단순 계산이라 추가 처리 시간이 매우 작다.

3. 비용의 성격

   1. 지불하는 것: 메모리와 인덱싱 저장 공간을 더 쓴다.
   2. 얻는 것: 모델 재학습, 임베딩 모델 교체, 질의 분류기 도입 없이 검색 recall의 20~40% 여지를 회수한다.

6.3. 한계와 다음 실험

1. 윈도 수와 크기 선택

   1. 현재 선택의 임의성: 50, 100, 200, 500, 1,000, 2,000 같은 값은 실험에 유용했지만 보편적으로 계산된 최적 목록은 아니다.
   2. 필요한 자동화: 코퍼스와 질의 분포를 바탕으로 몇 개의 크기를 어떤 간격으로 저장할지 결정하는 방법이 필요하다.

2. RRF를 넘어서는 결합

   1. 현재의 선택: 여러 결합 방법을 비교한 결과 RRF가 가장 잘 작동해 사용했다.
   2. 열린 가능성: RRF가 최종 해법이라는 뜻은 아니며, 서로 다른 해상도의 증거를 더 잘 조합하는 방법을 탐색할 수 있다.

3. 실무 적용 순서

   1. 먼저 측정: 단일 512 또는 1,000 토큰 기준을 당연한 기본값으로 두지 말고 질의별 recall@K를 확인한다.
   2. 그다음 확장: 저장 공간을 감당할 수 있다면 여러 윈도로 별도 인덱스를 만들고 병렬 검색과 RRF를 적용해 고정 기준 및 오라클 간의 격차를 측정한다.

주요 발언 모음

“청킹은 죽지 않았다.”

“검색에 올바른 청크 크기란 없고, 올바른 크기는 질의의 속성이다.”

“청킹은 본질적으로 손실 압축이다. 무엇을 하든 무언가를 잃는다.”

“에이전트는 검색을 죽이지 않았다. 아무것도 죽지 않았다. 그저 인프라일 뿐이다.”

“2022년의 인프라라는 나쁜 부분이 남아 있다.”

“정교한 무언가 없이도 RAG 시스템의 recall을 20~40% 높일 수 있다.”

핵심 데이터 & 수치

• 18분: 전체 발표 길이는 약 1,080초다.
• 6개 윈도: 동일 코퍼스를 50, 100, 200, 500, 1,000, 2,000 토큰 규모로 나눠 별도 인덱스를 구성했다.
• 100토큰 대 50위 이하: Jerry의 선호 교회 이름 질의는 100토큰에서 1위였지만 더 큰 윈도에서는 50위 아래로 밀렸다.
• 20~40%: 질의별 최적 청크를 고르는 오라클과 단일 고정 크기 사이의 recall 격차다.
• 10~40%: 별도로 언급된 MTEB 계열 결과에서 데이터셋에 따라 나타난 개선 폭이다.
• 2~5배: 모든 윈도 크기의 인덱스를 보관할 때 늘어나는 메모리 비용이다.
• 거의 0에 가까운 지연 증가: 병렬 검색과 가벼운 RRF 계산으로 검색 지연은 크게 늘지 않는다.

결론 및 시사점

1. 고정 청크 크기를 평균 성능 하나로 정당화하면 질의별 정보 해상도 차이 때문에 개별 질문의 recall을 체계적으로 잃는다.
2. 검색 품질의 병목은 더 영리한 에이전트를 붙이는 것만으로 해소되지 않으며, 데이터가 어떤 단위로 인덱싱되어 있는지가 선행 조건이다.
3. 멀티스케일 인덱싱은 동일 코퍼스의 여러 표현을 저장하고, 질의가 존재하는 검색 시점으로 해상도 선택을 미루는 설계다.
4. 부모 문서 단위의 RRF는 크기가 다른 청크의 비호환 점수를 직접 합산하지 않고, 순위 기반 투표로 공통 문서 후보를 만든다.
5. 추가 메모리 2~5배를 감수할 수 있는 RAG라면 모델 재학습 없이 20~40%의 검색 성능 여지를 검증할 가치가 있다.
6. 우선 기존 질의 로그에서 좁은 사실 질의와 넓은 맥락 질의를 분리하고, 각 그룹의 최적 청크 크기가 실제로 다른지 recall@K로 측정해야 한다.

---

핵심 요약 (20줄)

RAG의 성능을 좌우하는 청킹은 2022년에 끝난 전처리가 아니라 질의와 결합된 표현 설계 문제다.

에이전트 검색 도구가 좋아져도 데이터가 질의에 맞는 단위로 인덱싱되지 않으면 대규모 탐색 비용이 커진다.

인덱싱 단계에서는 미래의 질문을 모르고 검색 단계에서는 청크 크기가 이미 고정되어 있다는 정보 비대칭이 존재한다.

큰 청크는 전체 맥락을 보존하지만 세부 사실을 희석하고 작은 청크는 구체성을 보존하지만 주변 맥락을 끊는다.

고정 차원의 임베딩은 청크 안의 다양한 정보를 압축하므로 청킹은 어떤 선택에서도 일부 정보를 잃는 손실 압축이다.

동일한 코퍼스라도 질문의 성격에 따라 최적 청크 크기가 달라져 하나의 전역 최적값을 정할 수 없다.

FIFA 월드컵을 연도별 폴더에 저장하면 최다 우승 팀을 찾기 위해 모든 폴더를 순회하고 결과를 집계해야 한다.

Seinfeld의 구체적 사실 질의는 작은 청크에서 강하고 장면 전체를 요구하는 질의는 큰 청크에서 강하다.

Jerry가 좋아하는 교회의 이름을 묻는 질의는 100토큰 청크에서 1위였지만 큰 윈도에서는 50위 아래로 밀렸다.

Jerry가 nemesis이자 pure evil이라고 부르는 인물을 묻는 질의는 장면 맥락이 필요하며 정답은 Newman이다.

QMSum, NarrativeQA, Seinfeld, FinanceBench처럼 정보 구조가 다른 데이터셋에서도 질의별 청크 크기 차이가 반복됐다.

여섯 가지 청크 크기로 동일 코퍼스를 복제한 오라클 실험은 고정 크기 선택보다 20~40% 높은 recall 여지를 보여줬다.

오라클은 정답을 알고 최적 크기를 고르는 상한선이므로 실제 시스템에서는 그대로 사용할 수 없다.

멀티스케일 인덱싱은 여러 윈도 크기로 별도 인덱스를 만들고 검색 시 모든 인덱스를 병렬 호출한다.

크기가 다른 청크의 순위와 유사도 점수는 직접 비교하기 어려워 각 청크를 부모 문서의 투표로 변환한다.

Reciprocal Rank Fusion은 절대 점수 보정 없이 순위의 역수 기반 투표를 합쳐 최종 문서 순위를 계산한다.

RRF 결합은 고정 청크 기준보다 여러 데이터셋과 recall@K 조건에서 같거나 높은 결과를 냈다.

여러 인덱스를 저장하면 메모리가 약 2~5배 늘지만 병렬 검색과 가벼운 RRF 계산으로 지연 증가는 작다.

향후에는 코퍼스별로 필요한 윈도 수와 크기를 자동 결정하고 RRF보다 나은 결합 방식을 찾아야 한다.

단일 512 또는 1,000 토큰을 당연한 기본값으로 두지 말고 질의별 성능을 측정한 뒤 멀티스케일 검색을 검증해야 한다.