RAG 청킹 전략: 리콜 데이터로 순위를 매긴 7가지 방법 (2026)

RAG 청킹 전략: 리콜 데이터로 순위를 매긴 7가지 방법 (2026)

RAG 청킹 전략은 쿼리가 단 한 번 실행되기도 전에 리트리버가 무엇을 찾을 수 있는지를 결정합니다. Chroma의 2024년 7월 연구는 text-embedding-3-large로 5개 코퍼스 전반에 걸쳐 472개 쿼리를 실행했고, 어떤 스플리터를 고르느냐에 따라 리콜이 약 5포인트 움직였습니다. 단순 토큰 스플리터는 86.7%, GPT-4o 기반 스플리터는 91.7%였죠(쿼리당 청크 5개 검색 기준). 프리시즌 변동은 훨씬 더 큽니다. 보고서 전체를 보면 1.5%에서 8.0%까지 벌어지는데, 이 정도면 청크 크기 선택은 품질로 포장된 비용 결정이나 다름없습니다. 그런데 검색 1페이지의 모든 가이드가 똑같은 일곱 가지 방법을 나열하면서도 어느 쪽이 더 잘 검색하는지는 보여주지 않습니다.

핵심 요약

• 청킹은 임베딩 전에 문서를 나누고, 분할 지점이 리트리버가 찾을 수 있는 것과 없는 것을 결정합니다.
• Chroma의 2024년 7월 472 쿼리 연구에서 리콜은 측정된 스플리터 간에 86.7%에서 91.7%까지 나왔습니다.
• 프리시전은 리콜보다 몇 배 더 크게 흔들리므로, 청크 크기는 사실상 토큰 비용 결정입니다.
• 512 토큰, 오버랩 10%로 시작해서 여러분 자신의 평가 세트에 맞춰 조정하세요.

어떤 RAG 청킹 전략을 써야 할까요? (순위)

펼쳐진 산문형 문서를 다루는 대부분의 팀에게는 리커시브 문자 청킹(recursive character chunking), 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의 메인 결과 테이블은 클러스터 청커의 최고 프리시전을 리콜 87.3%에서 8.0%로 잡고, 모든 스플리터의 프리시전 범위를 1.5%(KamradtSemanticChunker)에서 8.0%까지 펼쳐 놓습니다. 출처: Chroma Research, Evaluating Chunking Strategies

Anthropic의 "Introducing Contextual Retrieval" (2024년 9월 19일 공개)은 다른 각도에서 이 문제를 다룹니다. 이들의 기본 top-20 검색 실패율은 5.7%였습니다. 컨텍스트 임베딩만 추가해도 3.7%로 떨어졌고(35% 감소), 그 위에 컨텍스트 BM25를 얹어 2.9%(49%), 리랭킹으로 1.9%(67%)까지 내려갔습니다. Anthropic은 사용한 정확한 청크 크기나 오버랩을 공개하지 않으므로, 이 수치는 크기 수준이 아니라 방법 수준의 근거로 받아들이세요. 출처: Anthropic, Contextual Retrieval.

저희 해석: 산수에서 세 가지 결론이 나옵니다. 첫째, 스플리터 선택은 실제 리콜 값이고 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을 넣으면, 꼬리는 소리 잘린 채 잘려 나갑니다. 임베딩은 청크의 3분의 2만 표현합니다. 에러 로그도 없습니다.

그다음은 생성기 쪽입니다. Liu 등은 "Lost in the Middle" (arXiv 2307.03172, 2023)에서 관련 문서가 긴 컨텍스트 한가운데 놓이면 LLM 정확도가 20% 넘게 떨어진다는 것을 보였습니다. 1,000 토큰 청크 다섯 개를 검색하면 프롬프트에 5,000 토큰을 쏟아붓는 셈이고, 필요한 답변은 모델이 가장 못 읽는 위치에 놓일 수 있습니다. 더 작은 청크는 관련 구절을 모델이 잘 다루는 위치 가까이에 유지합니다.

도서관 색인이라고 생각해 보세요. "4.2절, 3문단: 환불 정책"이라고 적힌 카드는 여러분을 해당 페이지로 데려갑니다. "20세기 상거래에 관한 모든 것"이라고 적힌 카드는 건물로 데려갈 뿐입니다. 여러분의 임베딩이 그 카드입니다. RAG 애플리케이션을 처음부터 끝까지 구축하는 법에서 청킹이 파이프라인의 어디에 자리하는지 확인하고, 컨텍스트 엔지니어링 가이드에서 검색된 청크가 프롬프트 토큰이 되는 과정을 읽어 보세요. Pinecone의 청킹 가이드도 같은 트레이드오프를 벡터 데이터베이스 쪽에서 설명합니다.

고정 크기와 리커시브 청킹 (여기서 시작)

고정 크기는 모든 것의 기준선이 되는 측정 대상이고, 리커시브는 실제로 배포하는 것입니다.

고정 크기 토큰 청킹

내용과 무관하게 N 토큰마다 자릅니다.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

정답인 경우: 헤더 구조가 없는 산문형 텍스트, 빠른 프로토타입, 그리고 모든 기준선 비교. 멍청한 방식이 아닙니다. 대조군입니다.

리커시브 문자 청킹

LangChain의 RecursiveCharacterTextSplitter는 구분자 계층에서 분할합니다. 먼저 \n\n(문단), 그다음 \n(줄), 그다음 . (문장), 그다음 (단어) 순서입니다. 각 청크는 들어맞는 가장 큰 자연 경계를 지키면서 chunk_size 아래로 유지됩니다.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

구분자 목록은 모든 경쟁사가 생략하는 부분입니다. 스플리터는 먼저 \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 연구는 그의 청커를 이름 그대로 벤치마크합니다.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

비용 계산은 아무도 먼저 말하지 않는 부분입니다. 시맨틱 청킹은 코퍼스를 두 번 임베딩합니다. 한 번은 문장 거리를 계산해 분기점을 찾는 데, 한 번은 결과 청크를 인덱싱용으로 임베딩하는 데 씁니다. OpenAI의 text-embedding-3-large 가격인 1M 토큰당 $0.13에서, 10M 토큰 코퍼스는 일반 인덱싱 시 $1.30, 시맨틱 청킹 시 $2.60이 듭니다. 쿼리 한 번 실행하기 전에 두 배를 지불하는 셈입니다.

그걸로 뭘 사나요? Chroma의 검색-5 행에서 클러스터 기반 시맨틱 청커는 같은 200 토큰 크기에서 리커시브의 88.5%, 7.0%에 karşı 리콜 89.0%, 프리시전 6.7%를 기록했습니다. 메인 결과 테이블에서 같은 청커는 연구 최고 프리시전인 8.0%를 리콜 87.3%에서 기록합니다. 어느 쪽이든 리콜은 반 포인트 차이이고, 프리시전 결과는 어떤 검색 설정을 읽느냐에 따라 부호가 뒤집히는데, 임베딩 청구서는 두 배입니다. 저희 결론: 시맨틱 청킹은 주제 다양성이 큰 코퍼스(뉴스 아카이브, 논문 모음)에서 값어치를 합니다. 고정 경계가 일상적으로 주제 한가운데를 자르기 때문이죠. 동질적인 코퍼스(제품 문서, 단일 지식 베이스)에는 리커시브가 절반 비용으로 품질의 95%를 가져다줍니다. Ollama로 임베딩 모델을 로컬에서 돌린다면 이중 임베딩 비용은 계산 시간으로 줄어듭니다.

문서 인식 청킹: Markdown, HTML, 코드

구조 인식 분할은 문자 개수 대신 문서 자신의 경계(헤더, 리스트 항목, 함수 정의)를 사용합니다. Markdown H2는 사람이 의도적으로 배치한 의미 경계입니다. 문자 스플리터는 이를 갈기갈기 찢습니다.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

코드의 경우 경계는 AST 노드입니다. LlamaIndex의 NodeParsers는 함수와 클래스 정의에서 끊는 언어 인식 스플리터를 제공합니다. 결정적인 디테일: import 블록과 감싸는 클래스 시그니처를 각 함수 청크에 붙여 두세요. import 없는 함수 본문은 임베딩할 수 없는 노이즈입니다. 그래서 둘 다 모든 청크 앞에 붙여야 임베딩이 함수의 역할과 의존성을 함께 잡아냅니다.

코드 RAG에 한정해서 말하면: AST 경계 분할, import 선행 첨부, 함수당 256-512 토큰, 오버랩 제로입니다.

레이트, 계층형, 에이전틱 청킹은 어떤가요?

이 세 가지는 "RAG 2.0" 이야기 뒤에 있는 고급 RAG 청킹 전략이고, 셋 다 SERP 커버리지 1/10 수준입니다.

레이트 청킹

레이트 청킹은 Günther 등의 "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, 2024년 9월)에서 도입되었습니다. 먼저 긴 컨텍스트 모델로 문서 전체를 임베딩한 뒤 토큰 수준 임베딩을 청크 벡터로 풀링해서, 각 청크가 문서 전체의 맥락을 갖게 됩니다. 그래서 "월 $40이 들어"에서 "그것"이 무엇을 가리키는지 압니다. 초록은 태스크 전반에서 우수한 검색을 주장하지만 저희가 검증할 수 있는 헤드라인 수치는 공개하지 않았습니다. Weaviate의 글은 메커니즘을 설명하면서도 통제된 비교까지는 나아가지 않습니다. 근거 상태: 유망하지만 정량화되지 않음.

계층형 (부모-자식) 청킹

검색용으로는 작은 청크(256 토큰)를 인덱싱하고, 생성기에는 부모(1,024 토큰)를 반환합니다. 리트리버는 바늘을 찾고, 생성기는 주변 건초 더미를 받습니다. 인덱스 두 단계와 부모-자식 매핑을 유지 관리해야 합니다. 이 효과를 분리해 낸 공개 벤치마크는 아직 없습니다.

LLM 기반 / 에이전틱 청킹

Chroma 연구의 LLMSemanticChunker는 GPT-4o로 문서별 분할 지점을 결정합니다. 리콜 91.7%(최고), 프리시전 3.9%(최저). 인덱싱 시점에 문서당 LLM 호출을 지불하고(10,000개 문서 코퍼스 기준 약 $100), 생성기에 더 많은 노이즈를 먹입니다. 정말 불규칙한 코퍼스에만 남겨 두세요: 법률 서류, 추출 가능한 헤더가 없는 스캔 PDF 같은 경우입니다.

어떤 청크 크기가 임베딩 모델에 맞나요?

임베딩 모델의 최대 입력 토큰은 잘림 상한이지 권장값이 아닙니다. 8,192 토큰을 받는 모델이 512에서보다 8,192에서 더 잘 임베딩하지 않습니다. 품질은 상한에 한참 못 미쳐 희석으로 먼저 나빠집니다. 모델이 더 많은 토큰에 걸쳐 의미를 평균 내면서 벡터가 코퍼스 중심 쪽으로 흘러갑니다. 아래 권장 열은 Techsy의 해석이지 벤더사의 가이드가 아닙니다.

출처: OpenAI embeddings guide, Cohere embed docs, Voyage embeddings docs, BGE model card.

패턴: 하드 512 토큰 상한이 있는 모델(Cohere v3, BGE)은 512보다 훨씬 작은 청크를 요구합니다. 잘림이 소리 없이 일어나기 때문입니다. 600 토큰을 넣으면 마지막 88 토큰은 에러 로그도 없이 임베딩에서 사라집니다. 상한이 큰 모델(OpenAI, Voyage, Cohere v4)은 더 큰 청크를 허용은 하지만 보상하지는 않습니다. 모델의 최대 입력 길이는 잘림 한계이지 권장값이 아닙니다.

모델을 정하기 전에 저희 RAG용 최고 임베딩 모델 roundup, MTEB 점수가 실제로 측정하는 것, Voyage, OpenAI, Cohere 임베딩 나란히 비교를 함께 보세요.

영어가 아닌 문서는 어떻게 청킹하나요?

토크나이저는 언어 중립적이지 않습니다. Petrov 등은 "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023)에서 같은 텍스트를 언어 간 번역하면 토큰화 길이가 최대 15배까지 차이 날 수 있음을 보였습니다. 문자 수준, 바이트 수준 모델조차 일부 언어 쌍에서 4배 넘는 차이를 보입니다. 512 토큰 청크는 터키어, 아랍어, 일본어에서 영어보다 훨씬 적은 의미를 담습니다.

같은 문장을 tiktoken의 cl100k_base 인코딩(GPT-4의 토크나이저)으로 토큰화한 결과입니다.

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

수치는 tiktoken cl100k_base로 생성, 2026년 7월 30일.

실무 지침: 고정 512 토큰 청크 크기에서 터키어와 일본어 청크는 영어 청크가 담는 의미의 대략 37%만 담고, 아랍어 청크는 약 26%만 담습니다. 언어별로 문자 수나 문장 수 기준으로 청킹하거나, 토큰 예산을 비례해서 올리세요(터키어 약 1,400, 아랍어 약 2,000). CJK 언어에는 공백 단어 경계가 없어서 문자 스플리터가 다르게 동작합니다. 아랍어 형태론은 여러 문법 표지를 단일 토큰에 밀어 넣어 개수를 더 부풀립니다.

청킹 전략 고르는 의사결정 트리

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

빠른 처방 세 가지. 문서 챗봇: MarkdownHeaderTextSplitter에 512 토큰, 오버랩 제로, 메타데이터에 헤더 경로. 코드 검색 어시스턴트: 함수당 256-512 토큰의 AST 경계 분할, import 선행 첨부. 혼합 엔터프라이즈 코퍼스: 수집 시점에 문서 유형별로 라우팅하고 청크를 저장할 벡터 데이터베이스에 유형 메타데이터와 함께 저장해서 나중에 유형별 튜닝이 가능하게 하세요. 이 문서별 라우팅이 곧 RAG 애플리케이션에서 적응형 청킹의 전부입니다.

도구: LangChain vs LlamaIndex vs Chonkie

저희는 이 중 어떤 것도 팔지 않습니다. 이 키워드의 상위 3개 랭킹 페이지는 제품 CTA가 달린 벤더 블로그입니다.

출처: LangChain docs, LlamaIndex NodeParsers, Chonkie docs.

세 곳 모두 같은 핵심 알고리즘을 구현하므로, 파이프라인이 이미 쓰는 것을 기준으로 고르세요. 스플리터 너머의 더 넓은 RAG 도구 스택과 저장용 Qdrant, Chroma, pgvector 비교는 저희 클러스터 가이드를 참고하세요.

Techsy는 청킹에 어떻게 접근하나

클라이언트 RAG 구축에서 Techsy 팀은 512 토큰, 오버랩 10%로 시작하고, 클라이언트의 실제 지원 티켓에서 20-50문항 평가 세트를 만들기 전까지는 스플리터를 건드리지 않습니다. 평가 세트가 먼저입니다. 그다음 한 번에 변수 하나씩만 바꿉니다. 크기, 오버랩, 전략 순서로요. 같은 문항에서 전후 수치가 없는 스플리터 교체는 없습니다. 검색 파이프라인에 제2의 눈이 필요하다면 무료 상담을 받아 보세요.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축합니다. Techsy 팀이 프로덕션에서 실제로 쓰는 LLM 도구 스택에 대해 쓰며, 클라이언트 지식 베이스 구축 뒤의 RAG와 검색 작업도 다룹니다. LinkedIn에서 연결하세요.

자주 묻는 질문

RAG에서 청킹이란 무엇인가요?

청킹은 임베딩 전에 문서를 더 작은 세그먼트로 나누는 전처리 단계로, 리트리버가 쿼리를 파일 전체가 아니라 집중된 구절과 매칭할 수 있게 합니다. 분할 지점이 쿼리 시점에 시스템이 찾을 수 있는 것과 없는 것을 결정합니다.

RAG에 가장 좋은 청킹 전략은 무엇인가요?

일반 문서를 다루는 대부분의 프로덕션 시스템에는 512 토큰, 오버랩 10%의 리커시브 문자 청킹이 가장 강력한 기본값입니다. Chroma의 472 쿼리 연구(2024년 7월)에서 리콜 88.5%를 기록했는데, 가장 비싼 LLM 기반 방식에 3.2포인트 뒤진 수치로, 추가 비용은 제로였습니다.

RAG의 최적 청크 크기는 얼마인가요?

512 토큰으로 시작하세요. 임베딩 모델이 입력 512 토큰에서 막히거나(Cohere v3, BGE) 쿼리가 한 문장 답변을 기대한다면 256으로 내리세요. 평가 세트에서 여러 문단 답변이 조각나는 것이 보일 때만 1,024로 올리세요. 항상 여러분 자신의 질문에 맞춰 측정하세요.

청크 오버랩은 얼마나 써야 하나요?

청크 크기의 10-20% (512에서 50-100 토큰). 오버랩은 경계 문장이 고아가 되는 것을 막아 줍니다. 두 청크에 걸쳐 잘린 사실이 적어도 한쪽에는 완전하게 나타납니다. 20%를 넘기면 수익 체감을 감수하면서 코퍼스를 너무 많이 다시 임베딩합니다. 대부분의 팀은 10%에 정착하고 다시 돌아보지 않습니다.

시맨틱 청킹이 고정 크기 청킹보다 나은가요?

근소한 차이로, 임베딩 비용은 두 배입니다. Chroma의 2024년 7월 벤치마크에서 클러스터 기반 시맨틱 청커는 같은 토큰 크기에서 리콜 89.0%, 프리시전 6.7%였고, 리커시브는 리콜 88.5%, 프리시전 7.0%였습니다. 최고 프리시전 8.0% 결과는 다른 검색 설정에서 나온 것입니다. 주제 다양성이 큰 코퍼스에는 가치가 있고, 동질적인 문서 세트에는 정당화하기 어렵습니다.

청크 크기는 임베딩 모델에 따라 달라지나요?

네. 입력 상한이 512 토큰인 모델(BGE, Cohere v3)은 512보다 훨씬 작은 청크가 필요한데, 잘림이 소리 없이 일어나기 때문입니다. 8,192 이상 상한인 모델은 더 큰 청크를 허용은 하지만 보상하지는 않습니다. 임베딩 품질은 상한 전에 희석으로 나빠집니다. 모델별 시작점은 위의 매칭 테이블을 보세요.

RAG 시스템용으로 코드는 어떻게 청킹하나요?

토큰 개수가 아니라 AST 경계(함수와 클래스 정의)에서 분할하세요. 각 청크를 함수당 256-512 토큰으로 유지하고, 파일의 import 블록과 감싸는 클래스 시그니처를 앞에 붙이세요. 함수는 자기 완결적 단위이므로 오버랩은 제로로 합니다. LlamaIndex의 CodeSplitter와 LangChain의 언어 인식 스플리터 모두 이를 처리합니다.

레이트 청킹이란 무엇인가요?

레이트 청킹은 먼저 긴 컨텍스트 모델로 문서 전체를 임베딩한 뒤 토큰 수준 임베딩을 청크 벡터로 풀링합니다. 각 청크 임베딩이 문서 전체의 맥락을 담아서 "'그것'이 무엇을 가리키지?" 문제를 해결합니다. Günther 등이 도입했습니다 (arXiv 2409.04701, 2024년 9월). 아직 이득을 정량화한 공개 직접 비교 벤치마크는 없습니다.

영어 외 언어로 된 문서는 어떻게 청킹하나요?

토큰 개수는 언어 중립적이지 않습니다. 같은 문장이 터키어와 일본어에서는 영어보다 2.7배, 아랍어에서는 3.9배 더 많은 토큰을 차지했습니다(tiktoken cl100k_base). 고정 512 토큰 예산은 비영어 청크에 소리 없이 더 적은 의미만 부여합니다. 언어별로 문자 수나 문장 수로 청킹하거나 예산을 비례해서 올리세요.

청킹이 실제로 효과가 있는지 어떻게 알 수 있나요?

스플리터를 건드리기 전에 실제 사용자 쿼리에서 20-50문항 평가 세트를 만드세요. 현재 청크를 상대로 hit@5와 MRR을 점수화하세요. 변수 하나(크기, 오버랩, 전략)를 바꾸고, 다시 실행하고, 비교하세요. 평가 세트가 없으면 감으로 튜닝하는 겁니다. 시작에는 스무 문항이면 충분합니다.

결론

• 리커시브 문자 청킹, 512 토큰, 오버랩 10%로 시작하세요. 산문형 텍스트에 맞는 기본값입니다.
• 누군가 측정한 네 스플리터 계열 전반에서 Chroma의 472 쿼리는 리콜을 약 5포인트, 프리시전을 그 몇 배로 움직입니다. 프리시전과 비용부터 튜닝하세요.
• 청크 크기를 임베딩 모델의 입력 상한에 맞추세요. 512 토큰 상한 모델은 512 미만 청크를 요구합니다.
• 스플리터를 다시 조정하기 전에 청크를 맥락으로 풍부하게 만드세요 (Anthropic의 실패율 5.7%에서 3.7% 하락).
• 평가 세트를 먼저 만드세요. 전후 수치 없는 모든 스플리터 결정은 추측입니다.

청킹 선택을 감싸는 전체 파이프라인은 RAG 애플리케이션 처음부터 끝까지 구축하기를 참고하세요. 아직도 검색과 파인튜닝 사이에서 고민 중이신가요? RAG vs 파인튜닝에서 각각이 이기는 상황을 정리했습니다.