RAG 청킹 전략 비교: 리트리버가 답의 절반만 찾는 이유

검색 시스템이 대부분의 경우 답의 일부를 찾는다면, 아마 대시보드가 말하는 것보다 더 자주 실패하고 있을 것입니다. 청킹에 관한 10월 논문들과, 그 아이디어 다섯 개를 나란히 돌려 본 꼼꼼한 실험 하나는 같은 교훈을 가리킵니다. 문서를 어떻게 자르느냐가 무엇을 찾을 수 있는지를 결정하며, 가장 좋은 자르기 방식은 보낼 수 있는 컨텍스트의 양에 달려 있습니다.

청킹이 다시 주목받는 이유

검색 증강 생성(RAG)은 문서를 조각으로 자르고, 질문과 맞는 조각을 찾아 모델에 넘깁니다. 모델은 받은 것만 쓸 수 있습니다. The Bottleneck Is Retrieval, Not Reading(arXiv, 10월 18일)은 프런티어 모델 10개와 오픈 가중치 모델 3개를 시험했고, 모두에서 같은 패턴을 발견했습니다. 검색은 여러 사실이 필요한 질문에 필요한 청크 중 일부는 안정적으로 찾아내지만 전부는 찾지 못하며, 청킹은 한 구절을 다른 구절과 이어 주는 문서 수준의 맥락을 없애 버립니다.

10월의 논문 세 편이 이 문제를 서로 다른 방향에서 공략합니다.

QESChunker(10월 27일)는 청킹을 최적화 문제로 다룹니다. 예시 질문과 그에 답하는 문장이 주어지면, 검색 가능한 근거를 가장 많이 남기는 분할 지점을 고릅니다. 겹침이 없으면 동적 계획법으로 정확한 최적해를 찾고, 겹침이 있으면 문제가 NP-hard가 되며 탐욕적 방법으로 최적해에서 증명된 범위 안에 들어갑니다.

StrucChunk(10월 19일)는 저자가 이미 써 놓은 구조를 활용합니다. 조항을 가로질러 자르지 않고, "see Section 4.2" 같은 상호 참조를 색인 전에 해소하며, 키워드 검색(BM25)과 dense 임베딩을 결합합니다. 인도 형사소송법에 관한 질문 501개에서 Recall@5가 0.557에서 0.804로 올랐고, 저자들은 그 향상의 88%가 청킹만으로 이루어졌다고 봅니다.

SpectRAG(10월 27일)는 청크를 서로 독립적으로 다루지 않습니다. 인접성, 섹션 계층, 공유 개체, 인용을 바탕으로 청크 위에 가중 그래프를 만들고, 첫 검색 결과에서 그 그래프를 따라 관련성을 퍼뜨린 뒤, 고정된 토큰 예산 안에서 컨텍스트를 구성합니다.

실험 하나, 청커 다섯 개

Vishal Mysore는 누구나 다시 돌려 볼 수 있는 브라우저 실험실에서 이 아이디어들을 맞붙였습니다. 문서는 정책 매뉴얼처럼 쓰인 가상의 천문대 안내서로, 번호가 붙은 섹션, 정의, 상호 참조가 들어 있습니다. 검색은 BM25만 쓰므로 모든 수치가 결정적입니다. 각 청커에는 같은 제한이 주어집니다. 청크는 최대 450자, 컨텍스트 예산은 120단어입니다.

다섯 청커는 몇백 자마다 자르는 고정 윈도, 문장 전체를 채워 넣는 문장 윈도, StrucChunk 방식의 구조 인식 청커(번호 섹션마다 청크 하나, 제목 경로 첨부, 상호 참조된 정의 붙여 넣기), 그리고 정확한 버전과 겹침 버전의 QESChunker였습니다.

모든 청커가 모든 근거 문장을 어딘가에 온전히 보존했습니다. 차이는 올바른 조각을 찾아 예산 안에 넣을 수 있느냐에 있습니다.

결과가 말해 주는 것

부분 재현율은 실제보다 좋아 보이게 합니다. 모든 전략이 질문의 69~92%에서 근거 문장을 적어도 하나는 찾았습니다. 기본 청커들이 완전한 답을 구성한 경우는 4분의 1도 안 됐습니다. 부분 적중으로 평가하는 파이프라인은 여러 사실이 필요한 답 네 개 중 세 개가 근거의 절반으로 만들어지는 동안에도 건강해 보일 것입니다.

컨텍스트가 빠듯할 때는 작고 구조화된 청크가 이깁니다. 섹션 크기 청크는 평균 285자로 윈도의 약 400자보다 작아서, 윈도 하나가 들어갈 120단어에 두세 개가 들어갑니다. 40단어 예산에서는 구조 인식 청커만 10%를 넘었습니다. 300단어에서는 윈도 청커들이 따라잡았고, 400단어에서는 앞질렀으며, 구조 인식 청커는 77%에서 정체되었습니다. 예산이 넉넉하면 문서의 상당 부분을 보내게 되므로 거의 어떤 청커든 근거를 끌어옵니다.

청크 크기와 예산은 함께 정해야 합니다. 800자 청크에서 고정 윈도와 문장 윈도는 0%를 기록했습니다. 800자 윈도는 약 130단어로 120단어 예산보다 커서 청크가 하나도 들어가지 않았습니다. 한 사람이 청커를 조정하고 다른 사람이 프롬프트를 조정할 때 생기는 실패입니다.

수학적으로 최적인 청커가 꼴찌를 했습니다. QESChunker의 정확한 버전은 보류된 질문에서 15%를 기록했습니다. 근거 문장을 온전히 유지하는 것에 보상하는 자기 목적 함수에 대해서는 최적입니다. 규칙 하나를 온전히 유지하는 가장 싼 방법은 그 바로 앞에서 자르는 것이고, 안내서에서 규칙 바로 앞 줄은 그 제목입니다. 제목은 한 청크의 끝에, 규칙은 다음 청크의 시작에 놓였고, 그래서 제목을 키워드로 검색하면 엉뚱한 청크가 나왔습니다. 제목으로 시작하는 청크는 하나도 없었습니다. 교훈은 일반적입니다. 청커는 사용자가 적어 둔 것을 최적화하며, 온전한 근거와 찾을 수 있는 근거는 같지 않습니다. 겹침 버전은 훨씬 나았습니다. 보류된 질문에서 46%, 조정에 쓴 질문에서 83%였습니다. 이 차이는 예시 질문으로 학습하는 모든 청커에 대한 경고입니다. 색인이 사용자가 미리 떠올린 질문에 맞춰 만들어진다는 것입니다.

정의가 허브 역할을 하는 곳에서는 청크 그래프가 도움이 됩니다. 구조 인식 청킹을 그래프 검색으로 바꾸자 62%에서 69%로 올랐습니다. "Is flash photography allowed on the dome floor?"라는 질문에서 일반 BM25는 적색광 구역의 정의를 3위로 올렸고, 그러자 예산에 들어가지 않았습니다. 그래프 모드에서는 다른 두 섹션이 그 정의를 상호 참조하므로 관련성이 그쪽으로 흘러가 예산 안에 들어갔습니다. 상호 참조 해소를 끄자 향상이 사라졌습니다. 윈도 청커에서는 그래프가 도움이 되지 않았고, 문장 윈도에서는 점수가 23%에서 15%로 떨어졌습니다.

어떤 실패는 청킹 문제가 아닙니다. "My 8-year-old is coming. What rule applies on the terrace?"는 모든 방식에서 실패했습니다. 규칙에는 "children under 10"이라고 되어 있어 질문과 겹치는 단어가 없기 때문입니다. 이 간극을 메우려면 dense 또는 하이브리드 검색, 쿼리 재작성, 리랭커가 필요합니다.

파이프라인에서 바꿀 것

계약서, 정책, 매뉴얼, 사양서처럼 실제 구조가 있는 문서는 섹션 단위로 청킹하고, 제목 경로를 붙이고, 색인 시점에 상호 참조를 해소해 규칙이 의존하는 정의와 함께 다니게 하십시오. Docling과 Unstructured 같은 도구는 PDF에서 그 구조를 복원하고, Chonkie는 청킹 자체를 처리합니다.

부분 적중이 아니라 완전한 답을 측정하십시오. 근거의 절반으로 답한 여러 사실 질문은 맞아 보이는 틀린 답입니다. Ragas로 질문별 context recall을 채점할 수 있습니다.

청크 크기와 컨텍스트 예산은 같은 곳에서 정하고, 실제로 보내는 예산에서 테스트하십시오. 120단어에서 가장 좋았던 청커가 400단어에서는 가장 좋지 않았습니다.

지도 학습이나 그래프 기반 방법을 시도한다면, 그 목적 함수가 실제로 쓰는 리트리버와 맞는지 확인하십시오. 9월의 논문 두 편이 다른 각도에서 이를 뒷받침합니다. 54가지 구성을 비교한 연구는 파서와 청커 선택이 서로 영향을 주며 모든 곳에서 가장 좋은 리트리버는 없다는 것을 발견했고, 약 464,000편의 논문으로 파이프라인 여섯 개를 비교한 연구는 1단계 조정보다 리랭킹과 late interaction이 품질을 더 크게 바꾼다는 것을 발견했습니다. 적응형 검색 깊이에 관한 세 번째 논문은 질문 유형별로 가져올 청크 수를 정해, 쉬운 질문에서 F1이 36% 이상 좋아지고 토큰이 14% 줄었다고 보고합니다.

결론: 청킹은 무엇을 검색할 수 있는지를 정하고, 리트리버는 실제로 무엇이 검색되는지를 정합니다. 앞의 것은 구조로, 뒤의 것은 하이브리드 검색과 Cohere Rerank 5나 Jina Reranker v3.5 같은 리랭커로 고치고, 둘 다 답 전체가 도착하는지로 판단하십시오.