왜 청크 자체를?

청킹 존재 이유는 둘

임베딩 모델 토큰 한도. 한도 넘는 거 다 silent truncate.
문서 통째로 임베딩하면 너무 많은 주제가 한 벡터로 평균 내짐. '결제' 다루는 10페이지 문서가 trial signup, 환불 정책, dunning 이메일, tax compliance 다 건드릴 수 있어. 다 한 점으로 임베딩하면 그 주제들의 평균 — 어떤 구체적 답에서도 멀어.

retrieval vs context tradeoff

청크 작을수록 → retrieval 정밀, hit 당 context 적음. 청크 클수록 → context 풍부, 매칭 noisy, 청크가 주제 경계 가로지를 확률 높음. 대부분 KB 의 sweet spot 은 200–800 토큰 + 10–20% overlap. 출발점이지 법칙 아냐 — 본인 코퍼스로 측정해.

splitter 4 패밀리

고정 크기 — N 글자/토큰마다. 멍청하지만 안정적.
재귀 글자 — 문단, 문장, 단어 순서로 시도. LangChain 기본값.
구조-aware — Markdown 헤딩, HTML 태그, 코드 AST. 논리 경계 보존.
시맨틱 — 문장 임베딩 후 평균 drift 시작점에서 새 청크. 최고 품질, 최저 속도, 최저 투명도.

Code

고정 크기 글자 split (가장 단순한 베이스라인)·python

def fixed_chunks(text: str, size: int = 1200, overlap: int = 200):
    chunks = []
    start = 0
    while start < len(text):
        end = start + size
        chunks.append(text[start:end])
        start = end - overlap
    return chunks

chunks = fixed_chunks(open('handbook.md').read())
print(f'{len(chunks)} chunks, avg {sum(len(c) for c in chunks)//len(chunks)} chars')

청킹 존재 이유는 둘

retrieval vs context tradeoff

splitter 4 패밀리

Code

External links

Exercise

Progress

댓글 0