RAG 청킹 전략: 7가지 방법, 검색 데이터로 순위 매기기 (2026)
RAG 청킹 전략은 단 하나의 쿼리가 실행되기도 전에 리트리버가 무엇을 찾을 수 있는지를 결정합니다. Chroma의 2024년 7월 연구에서는 5개의 코퍼스에서 text-embedding-3-large를 이용해 472개의 쿼리를 실행했으며, 선택하는 분할기에 따라 재현율이 약 5포인트 차이가 납니다. 순수 토큰 분할기는 86.7%, GPT-4o 분할기는 91.7%이며, 쿼리당 5개의 청크를 검색합니다. 정확도는 훨씬 더 크게 변합니다. 전체 보고서에서 정확도는 1.5%에서 8.0% 범위인데, 이는 청크 크기 선택이 품질을 가장한 비용 결정이라는 뜻이며, 모든 첫 페이지 가이드는 어느 것이 더 나은 검색을 하는지 보여주지 않으면서 같은 7가지 방법을 나열합니다.
핵심 요점
- 청킹은 임베딩 전에 문서를 분할합니다. 분할 지점은 리트리버가 찾을 수 있고 찾을 수 없는 것을 결정합니다.
- Chroma의 2024년 7월 472개 쿼리 연구에서 재현율은 측정된 분할기들 간에 86.7%에서 91.7%로 나타났습니다.
- 정확도는 재현율보다 여러 배 더 변하므로, 청크 크기는 주로 토큰 비용 결정입니다.
- 512개 토큰에 10% 오버랩으로 시작한 후, 자신의 평가 세트에 맞게 조정하세요.
어떤 RAG 청킹 전략을 사용해야 할까요? (순위)
평문으로 빌드하는 대부분의 팀에게는 512개 토큰에 10% 오버랩의 재귀적 문자 청킹이 올바른 기본 전략입니다. 단락과 문장 경계를 유지하고, 추가 비용이 들지 않으며, Chroma의 472쿼리 벤치마크에서 LLM 기반 분할기보다 재현율에서 3.2포인트만 낮았습니다. 문서에 강한 구조가 있거나 평가 세트가 다르게 증명할 때만 다른 방법으로 옮기세요.
우리의 의견: 재귀적 문자부터 시작하세요. Chroma의 데이터에서 클러스터와 LLM 분할기에만 재현율에서 뒤처지며, LLM 분할기의 3.9% 정확도는 생성기에 관련 토큰당 약 두 배의 노이즈를 입력합니다. 대부분의 팀은 청킹 문제가 없습니다. 측정해본 적 없는 청크 크기 문제가 있을 뿐입니다.
데이터는 청크 크기에 대해 실제로 무엇을 말하고 있을까요?
RAG 청킹 전략에 대한 유일한 공개 일대일 비교는 Chroma의 기술 보고서 "검색을 위한 청킹 전략 평가(Evaluating Chunking Strategies for Retrieval)"(Brandon Smith 및 Anton Troynikov, 2024년 7월 3일 발행)입니다. 그들은 5개의 코퍼스(328,208개 토큰)에서 472개의 쿼리를 실행했으며, OpenAI text-embedding-3-large로 모든 것을 임베딩하고, 쿼리당 5개의 청크를 검색했습니다. 아래 표의 행은 모든 코퍼스에서 text-embedding-3-large의 검색 5개 청크에 대한 보고서의 부록 표에서 나온 것이므로 서로 직접 비교할 수 있습니다:
Chroma의 주요 결과 표는 다른 검색 설정을 보고하며, 클러스터 청커의 최고 정확도를 8.0%(87.3% 재현율)로 나타내고, 모든 분할기의 정확도 범위를 1.5%(KamradtSemanticChunker)에서 8.0%로 확장합니다. 출처: Chroma Research, Evaluating Chunking Strategies
Anthropic의 "문맥 검색 도입(Introducing Contextual Retrieval)"(2024년 9월 19일 발행)은 다른 각도에서 문제에 접근합니다. 그들의 기본 상위 20개 검색 실패율은 5.7%였습니다. 문맥 임베딩만으로 3.7%로 낮췄고(35% 감소), 그 위에 문맥 BM25를 더하자 2.9%로 낮췄으며(49%), 재순위 지정은 1.9%로 낮췄습니다(67%). Anthropic은 정확한 청크 크기나 오버랩을 공개하지 않으므로 이를 방법 수준의 증거로 취급하고, 크기 수준으로는 아닙니다. 출처: Anthropic, Contextual Retrieval
우리의 의견: 산술에서 얻은 3가지 결론입니다. 첫째, 분할기 선택은 실제 재현율 개선의 가치가 있습니다. Chroma는 이를 명확하게 말합니다. 일부 전략은 재현율에서 최대 9%까지 다른 성과를 냅니다. 주요 결과 표에서 재현율은 83.6%(KamradtSemanticChunker)에서 91.9%(LLMSemanticChunker)로 나타나고, 위의 검색 5개 행에서도 86.7%에서 91.7%로 범위가 있습니다. 정확도는 같은 데이터에서 여러 배 더 변합니다: 1.5%에서 8.0%는 재현율의 1.1배 범위에 대한 5.3배 범위입니다. 따라서 재현율은 몇 포인트를 얻는 곳이고, 정확도와 토큰 비용은 선택이 실제 영향을 미치는 곳입니다. 둘째, LLM 기반 분할기는 최악의 정확도로 최고 재현율을 얻습니다. 문서당 LLM 호출 비용을 지불하고 생성기에 더 많은 노이즈를 입력합니다. 셋째, Anthropic의 데이터는 청크를 컨텍스트로 풍부하게 하는 것(5.7%에서 3.7%)이 Chroma 표의 어떤 분할기 선택보다도 실패율을 더 크게 낮췄음을 보여줍니다. 분할기를 재조정하기 전에 청크를 풍부하게 하세요. 재순위 지정은 분할기가 망쳐놓은 청크를 복구하고, 하이브리드 검색은 같은 이유로 BM25를 벡터 검색과 결합합니다.
정직한 한계: 두 연구 모두 단일 임베딩 모델, 영어 전용 코퍼스를 사용하며 어느 것도 코퍼스의 통제된 테스트가 아닙니다. 472개 쿼리에서 최고와 최악의 분할기 사이의 간격은 검색 5개 청크에서 약 5포인트의 재현율이었고, 정확도에서는 비례적으로 훨씬 더 큰 간격이었습니다.
청크 크기가 검색 품질을 결정하는 이유는 무엇일까요?
청크 크기는 검색 키의 세분성을 설정합니다. 400토큰 청크는 특정 쿼리와 일치하는 집중된 임베딩을 생성합니다. 4,000토큰 청크는 많은 주제에 걸쳐 평균화되고 어떤 것도 정확하게 일치하지 않습니다. 작은 청크는 정확한 구절을 검색하지만 답변을 결과 전체에 분산시킬 수 있습니다. 큰 청크는 컨텍스트를 함께 유지하지만 임베딩 신호를 약화시킵니다.
임베딩 모델의 컨텍스트 제한도 중요합니다. 모델이 512개 입력 토큰에서 상한선을 두고 800개를 입력하면 나머지 부분이 조용히 잘립니다. 임베딩은 청크의 2/3만 나타냅니다. 오류가 기록되지 않습니다.
그러면 생성기 측입니다. Liu et al.은 "Lost in the Middle"(arXiv 2307.03172, 2023)에서 관련 문서가 긴 컨텍스트의 중간에 있을 때 LLM 정확도가 20% 이상 하락한다는 것을 보였습니다. 5개의 1,000토큰 청크를 검색하면 프롬프트에 5,000개 토큰을 입력하고, 필요한 답변은 모델이 가장 나쁜 성능을 내는 위치에 올 수 있습니다. 더 작은 청크는 관련 구절을 모델이 잘 처리하는 위치에 더 가깝게 유지합니다.
도서관 색인처럼 생각해보세요. "섹션 4.2, 단락 3: 환불 정책"이라고 적힌 카드는 정확한 페이지를 가져갑니다. "20세기 상거래의 모든 것"이라고 적힌 카드는 전체 건물을 가져갑니다. 임베딩은 카드입니다. RAG 애플리케이션을 끝에서 끝까지 구축해서 청킹이 파이프라인에서 어디에 있는지 확인하고, 검색된 청크가 프롬프트 토큰이 되는 방법에 대한 우리의 컨텍스트 엔지니어링 가이드를 읽으세요. Pinecone의 청킹 가이드는 벡터 데이터베이스 관점에서 동일한 트레이드오프를 설명합니다.
고정 크기 및 재귀적 청킹 (여기서 시작)
고정 크기는 모든 것을 측정하는 기준입니다. 재귀적은 실제로 배포하는 것입니다.
고정 크기 토큰 청킹
콘텐츠와 관계없이 N개 토큰마다 분할합니다.
올바른 사용처: 제목 구조가 없는 평문, 빠른 프로토타입, 모든 기준선 비교. 이는 어리석지 않습니다. 통제 그룹입니다.
재귀적 문자 청킹
LangChain의 RecursiveCharacterTextSplitter는 분할자 계층에 따라 분할합니다: 먼저 \n\n (단락), 그 다음 \n (행), 그 다음 . (문장), 그 다음 (단어). 각 청크는 chunk_size 미만으로 유지되면서 가장 큰 자연 경계를 존중합니다.
분할자 목록은 모든 경쟁 솔루션이 생략하는 부분입니다. 분할기는 먼저 \n\n을 시도하고 단락이 chunk_size를 초과할 때만 . 로 폴백됩니다. Markdown에 헤더가 있으면 섹션이 그대로 유지되도록 "## " 를 "\n\n" 앞에 추가하세요.
청크 오버랩 계산: 512개 토큰에 50토큰 오버랩으로, 스텝은 462입니다. 10,000토큰 문서는 ceil(10000 / 462) = 22개 청크를 생성합니다. 총 임베딩된 토큰: 22 x 512 = 11,264, 즉 코퍼스의 약 12.6%를 오버랩으로 재임베딩한다는 의미입니다. 이는 경계 문장이 고아가 되지 않도록 하는 저장 및 API 비용입니다.
의미적 청킹은 어떻게 작동하며 비용의 가치가 있을까요?
의미적 청킹은 모든 문장을 임베딩하고, 인접한 문장 임베딩 사이의 코사인 거리를 측정하며, 그 거리가 백분위수 임계값(보통 95번째)을 초과하는 지점에서 분할합니다. 청크는 임의의 토큰 수가 아닌 주제 변화에서 끊깁니다. Greg Kamradt의 "5 Levels of Text Splitting" 노트북이 이 백분위수 분할점 접근 방식을 시작했으며, Chroma 연구는 그의 청커를 이름으로 벤치마크합니다.
...