RAG 종류 총정리 ③ — 청킹·Contextual Retrieval·파싱: 색인 단위를 똑똑하게

검색을 고쳤는데도 못 찾는다면 다음은 색인 단위다. 청크를 어떻게 자르고 무엇을 붙여 넣을지의 문제인데, 이 계층의 장점은 비용이 일회성이라는 것이다. 질의당 부담이 0이라 트래픽이 늘어도 청구서가 안 늘어난다. 다만 여기엔 벤더 숫자와 재현 숫자의 간격이 가장 큰 구간이기도 하다.

Contextual Retrieval — 그리고 그 숫자의 분해

Anthropic의 방식은 청크를 색인하기 전에 LLM으로 50~100토큰짜리 맥락 문장을 앞에 붙이는 것이다. 발표된 개선은 top-20 검색 실패율 5.7% → 1.9%(−67%)인데, 이 숫자는 세 기법의 합이다.

• 맥락 임베딩만: 5.7% → 3.7% (−35%)
• + 맥락 BM25(하이브리드): → 2.9% (−49%)
• + 리랭킹: → 1.9% (−67%)

즉 −67% 중 절반 이상은 ②편에서 다룬 훨씬 오래되고 싼 기술이 벌어준 몫이다. 비용은 프롬프트 캐싱을 쓰면 문서 100만 토큰당 $1.02의 일회성이고, 공개된 쿡북을 보면 입력 토큰의 61.8%가 캐시 읽기로 처리되어 $9.20 → $2.85(−69%)가 됐다. 문서 단위로 배치를 묶지 않으면 이 캐시 적중률이 무너진다는 게 실무 함정이다. 평가셋 규모도 알아 둘 만하다 — 코드베이스 9개, 청크 737개, 쿼리 248개. Pass@5 80.92% → 88.12%는 약 18개 쿼리를 더 맞힌 결과다.

독립 재현은 더 차분하다. NFCorpus에서 contextual 0.308 vs late chunking 0.294로 격차가 nDCG@10 +0.014였고, contextual 청크 생성에 VRAM 20GB가 필요해 데이터셋의 20%만 평가할 수 있었다. late chunking은 LLM 호출이 0회인데도 이 정도다 — 문서를 롱컨텍스트 임베딩에 한 번 통과시킨 뒤 pooling 직전에 자르는 방식으로, 평균 +1.9%p(NFCorpus 23.5→30.0)지만 Quora는 변화 0, MsMarco+Stella에서는 0.630 → 0.503으로 오히려 손해였다. 일관된 규칙은 하나 — 문서가 길수록 이득이 크다.

시맨틱 청킹은 돈값을 못 한다

"시맨틱 청킹이 연산 비용만큼 가치가 있나"가 정면으로 답했다. 합성 데이터셋에서는 화려하다(NQ 43.79 → 63.93). 그런데 실제 문서에서는 반대다 — HotpotQA는 고정 크기 90.59 > breakpoint 87.37 > clustering 84.79, MSMARCO도 고정이 최고, 근거 검색 5종은 전부 고정 크기 우세. 결론 문장이 인상적이다: "청킹 전략의 영향은 임베딩 품질에 가려진다."

청크 크기와 오버랩은 어떨까. Chroma의 토큰 단위 평가에서 OpenAI 기본값(800토큰/오버랩 400)이 최하위였고 승자는 200/0이었다. 화학 도메인에서 청킹 25설정 × 임베딩 48모델을 돌린 연구의 승자도 100토큰/오버랩 0이다. 단, 최적값은 무엇을 재느냐에 따라 정반대로 나온다 — Chroma(토큰 IoU 기준)는 200, LlamaIndex(faithfulness/relevancy 기준)는 1024가 정점이다. "검색 정밀도냐 답변 충실도냐"부터 정해야 한다.

더 싼 대안들

• 메타데이터 prefix — LLM 없이 제목·섹션·날짜를 청크 앞에 붙이는 것만으로 precision 82.5%, nDCG 0.813(최고), P95 30ms 미만. 파서 출력을 재활용하니 사실상 공짜다. 가성비 1위.
• 구조 인식 청킹 — 기업 문서 연구에서 top-K 최고에 연산 비용은 현저히 낮았다. 파서가 제목·절 구조를 주면 거의 공짜.
• RAPTOR(재귀 클러스터링+요약 트리) — QuALITY 82.6%가 눈에 띄지만 QASPER 기준 실제 마진은 DPR 대비 +1.8%p, BM25 대비 +5.3%p다. 여러 청크를 종합해야 답이 나오는 질문이 많을 때만.
• Proposition 색인(문장을 원자 명제로 쪼개 색인) — Recall@5 42.5→50.1이지만 위키 규모에서 P100 500 GPU-시간, 인덱스 768GB, 단위 6배 팽창. 게다가 리트리버가 좋을수록 이득이 사라진다(지도학습 +2.7, DPR은 −0.6).
• 질문 생성 색인 — Doc2Query--의 교훈은 필터가 본체라는 것. 생성 질의 상당수가 환각이라 필터링만으로 검색 +16%, 질의시간 −23%, 인덱스 −33%였다. 필터 없이 "청크마다 질문 5개"는 마이너스가 날 수 있다.

진짜 병목은 파싱이다

기업 문서 연구에서 네 가지 청킹 전략이 전부 P&ID 도면에서 실패했다. 청킹을 아무리 튜닝해도 파서가 표를 깨뜨리면 소용이 없다는 뜻이다. OmniDocBench의 표 인식(TEDS) 점수를 보면 격차가 선명하다 — PaddleOCR-VL 94.76, GPT-4o 82.95, Marker 65.77. 상용 최고 수준인 Upstage Document Parse가 TEDS 93.48이라는 건, 나머지 6.5%는 표가 깨진 채 색인된다는 뜻이기도 하다.

한국어에는 조건이 둘 더 붙는다. 첫째, 맥락 BM25는 형태소 분석기 없이 성립하지 않는다 — 조사가 붙어("예진의", "예진에서") 정확 매칭이 깨지므로 Nori나 Kiwi가 필수고, 문장 경계도 불안정해 별도 분리기가 필요하다(②편). 둘째, HWP/HWPX를 네이티브로 받는 글로벌 파서가 없다(⑧편). 그리고 한국어 임베딩 1·2위 격차가 0.3% 수준이라는 점을 생각하면, 예산 순서는 분명하다: 파싱 → 메타데이터 prefix → 하이브리드+리랭커 → 그래도 부족하면 Contextual Retrieval. 청킹 파라미터 튜닝은 마지막이다. 다음 글은 질의를 다시 쓰는 계층이다.

— RAG 종류 총정리 시리즈 ③ / 다음 글: 질의 변환 — HyDE·분해·step-back의 손익계산서

RAG 종류 총정리 ① — 어떤 RAG를 언제 쓰나: 비용으로 그린 지도

"RAG를 붙였는데 왜 안 되죠?"라는 질문에는 대개 두 가지가 섞여 있다. 어떤 RAG를 쓸지 안 정한 것과, 잘되는지 재는 방법을 안 정한 것. 이 시리즈는 2026년 현재 쓰이는 RAG 변형들 — 하이브리드, HyDE, Contextual Retrieval, Self·Corrective·Adaptive, GraphRAG, Agentic, 멀티모달 — 을 "무엇인지"가 아니라 언제 값을 하고 얼마가 드는지로 정리한다. 앞선 "RAG 실전" 시리즈가 구축 방법이었다면, 이번은 선택 기준이다.

먼저 냉정한 숫자부터

• RAG를 붙이는 것만으로는 부족하다. Meta의 CRAG 벤치마크(4,409문항, 5개 도메인)에서 LLM 단독 34% 이하, 단순 RAG 44%, 업계 최고 솔루션도 환각 없는 정답률 63%였다. FinanceBench에서는 검색을 붙인 GPT-4-Turbo가 81%를 틀리거나 거절했다.
• Naive RAG는 종종 "검색 안 함"보다 나쁘다. Rewrite-Retrieve-Read 논문에서 HotpotQA EM은 검색 없이 답할 때 32.36, retrieve-then-read가 30.47이었다.
• 컨텍스트에 넣었다고 읽는 것도 아니다. Lost in the Middle: GPT-3.5-Turbo에 문서 30개를 주고 정답을 가운데 두면 50.5% — 문서를 아예 안 준 56.1%보다 낮다.
• 우리가 넣는 컨텍스트의 대부분은 쓰레기다. Chroma의 토큰 단위 측정에서 청킹 전략별 precision은 2.7~8.0%(recall은 87~92%). 92~97%가 낭비라는 뜻이고, 그만큼 토큰 비용을 줄일 여지가 남아 있다.

RAG 변형의 다섯 계층

이름이 수십 개지만 손대는 지점은 다섯 곳뿐이다. 각 계층은 뒤로 갈수록 비싸진다.

• ① 검색 자체 — BM25, dense 임베딩, 하이브리드, 리랭킹. LLM 호출이 늘지 않아 가장 싸다. (②편)
• ② 색인 단위 — 청킹, Contextual Retrieval, late chunking, RAPTOR, 파싱. 일회성 비용이라 질의당 부담이 0이다. (③편)
• ③ 질의 변환 — 재작성, 분해, HyDE, step-back. 질의당 LLM 호출이 1회 이상 붙는다. (④편)
• ④ 흐름 제어 — Self-RAG, CRAG, Adaptive RAG, 라우팅. 크리틱·평가기 호출이 추가된다. (⑤편)
• ⑤ 구조·자율성 — GraphRAG, 에이전틱 RAG, 딥리서치. 색인 비용이 1,000배, 질의 비용이 수백 배까지 뛴다. (⑥·⑦편)

비용은 자릿수로 갈린다

Sonnet 5($2/$10 per 1M) 기준으로 질의 하나의 실제 청구액을 계산하면 계층 간 차이가 선명하다.

방식	질의당	배수	지연
단발 RAG (top-8)	약 24원	1배	2~4초
+ 리랭커	+3~5원	1.2배	+0.02~4.5초
반복 에이전트 (도구 5회)	약 175원	7.4배	15~40초
같은 조건 + 프롬프트 캐싱	약 63원	2.6배	동일
롱컨텍스트 200K 통째로	약 563원	24배	10~25초
딥리서치 (리드+서브 4, 검색 40회)	7천~1.1만 원	300~470배	5~30분

읽을 점 셋. 첫째, 캐싱만 켜도 에이전트가 7.4배에서 2.6배로 내려온다(앞 시리즈 ④편). 둘째, 색인 쪽은 반대로 계산한다 — Contextual Retrieval은 문서 100만 토큰당 $1.02의 일회성이고 질의당 추가가 0인 반면, full GraphRAG는 색인이 벡터 RAG의 1,000배다(⑥편). 셋째, 이 표는 토큰 시나리오를 가정한 모델링이니 자사 단가로 다시 계산해야 한다.

이 시리즈의 지도

② 하이브리드 검색과 리랭킹(가장 싼 개선) → ③ 색인 단위: 청킹·Contextual Retrieval·파싱 → ④ 질의 변환: HyDE·분해·step-back의 손익 → ⑤ Adaptive·Self·Corrective RAG: 언제 검색을 건너뛰나 → ⑥ GraphRAG와 구조화 데이터 → ⑦ 에이전틱 RAG와 "RAG는 죽었나" 논쟁 → ⑧ 멀티모달·문서·코드 RAG → ⑨ 평가: 무엇을 어떻게 재나 → ⑩ 멀티턴 대화형 RAG → ⑪ 권한 인식 검색과 보안 → ⑫ 색인 수명주기: 삭제·재임베딩·신선도 → ⑬ 한국어 조건과 결정 트리(완결).

미리 밝혀 두면, 이 시리즈의 결론은 "최신 변형을 쓰라"가 아니다. RAG 실패 7가지 지점 논문의 문장이 정확하다 — "RAG 시스템의 검증은 운영 중에만 실질적으로 가능하고, 견고함은 설계되는 것이 아니라 진화한다." 다음 글은 가장 싸고 가장 확실한 개선, 하이브리드 검색이다.

— RAG 종류 총정리 시리즈 ① / 다음 글: 하이브리드 검색과 리랭킹 — BM25는 왜 아직 안 죽었나