Chunking

벡터 DB를 세팅했다면, 실무에서는 검색 성능을 끌어올리는 몇 가지 조정을 더한다. 그 첫 번째가 청킹(chunking) — knowledge base의 긴 문서를 작은 텍스트 조각(chunk)으로 나누는 작업이다.

 

1. 왜 청킹하는가

이유는 셋이다.

• 임베딩 한계 — 많은 임베딩 모델은 한 번에 벡터로 만들 수 있는 텍스트 양에 제한이 있다.
• search relevance 개선 — 청킹은 retriever의 검색 관련성 지표를 높일 수 있다.
• context window 절약 — 문서에서 가장 관련 있는 부분만 LLM에 보내도록 보장한다.

그림 1. 청킹의 세 이유 — 임베딩 토큰 한계, 관련성 개선, LLM에 관련 맥락만 전달.

 

 

2. 청킹하지 않으면

1,000권의 책으로 된 knowledge base를 생각해 보자. 청킹 없이 인덱싱하면 각 책이 하나의 벡터가 되어 1,000개의 벡터가 만들어진다. 문제는 책 한 권 전체의 의미를 벡터 하나로 압축한다는 점이다. 이 벡터는 특정 장·페이지의 주제를 선명히 담지 못하고 전체를 평균낸 표현이 된다.

그림 2. 청킹 없이 인덱싱하면 책 전체가 벡터 하나로 압축된다 — 세부 주제를 담지 못한다.

 

그 결과 검색 관련성이 낮고, 검색해도 책 한 권을 통째로 가져와 LLM의 context window를 순식간에 채운다.

그림 3. 청킹 없는 방식의 문제 — 평균화된 표현, 낮은 관련성, context window 낭비.

 

 

3. 어떤 단위로 쪼개나

그래서 보통 책을 페이지·문단·문장 수준의 작은 조각으로 청킹한다. 그러면 knowledge base가 1,000권의 책 대신 100만 개의 문단을 담게 될 수 있는데, 벡터 DB는 이 정도 벡터를 저장·검색하도록 쉽게 확장된다.

그림 4. 책을 페이지·문단·문장 단위로 나눈다 — 각 조각이 더 선명한 벡터가 된다.

 

 

 

 

4. chunk size의 균형

첫 고려사항은 chunk 크기다. 너무 크게(예: 장 단위) 만들면 책 전체를 벡터화할 때와 같은 문제가 생긴다 — 벡터 하나로 미묘한 의미를 못 담고 context window를 빠르게 채운다. 반대로 너무 작게(극단적으로 단어 단위) 만들면 주변 문장·문단의 맥락을 다 잃어 역시 관련성이 떨어진다. 문장 단위조차 너무 세밀할 수 있다. 정답은 없고, 벡터가 너무 많거나 너무 적은 맥락을 담지 않도록 균형을 찾는다.

그림 5. 너무 크면 맥락이 뭉개지고, 너무 작으면 맥락을 잃는다 — 적당한 크기의 균형이 필요하다.

 

 

 

5. 고정 크기 청킹 (Fixed-size)

가장 단순한 방법은 모든 chunk를 같은 크기로 정하는 것이다. 예를 들어 250자라면 1~250번째 문자가 chunk 1, 251~500이 chunk 2, 501~750이 chunk 3 … 문서 끝까지 이어진다.

그림 6. 고정 크기 청킹 — 문자 수를 정해 일정하게 자른다(예: 250자).

 

 

 

6. 겹침(Overlap)

고정 크기로 자르면 분할이 단어 중간이나 이어지는 생각의 한가운데에서 일어날 수 있다. 이를 chunk 간 겹침(overlap)으로 완화한다. 예를 들어 250자 chunk가 앞뒤와 25자씩 겹치게 하면 — chunk 1은 1~250, chunk 2는 226~475, chunk 3은 451~700 … 이런 식이다(여기선 10% overlap). 겹침 덕분에 chunk 가장자리 단어가 두 chunk에 모두 나타나, 관련 맥락과 함께 등장할 확률이 높아진다. 겹침을 늘리면 관련성엔 대체로 이롭지만, 중복 정보를 담은 벡터가 늘어나는 비용이 든다.

그림 7. 겹치는 청킹 — 경계의 단어가 두 chunk에 걸쳐 맥락 단절을 줄인다.

 

 

 

7. 재귀적 문자 분할 (Recursive Character Splitting)

더 동적인 전략이 recursive character text splitting이다. 특정 문자를 분할 기준으로 고른다 — 예컨대 문단 사이에 자주 오는 줄바꿈(newline). 이러면 chunk 크기가 가변적이 되어(위치에 따라 매우 크거나 작아질 수 있음), 대신 문서 구조를 반영해 관련 개념이 한 chunk 안에 함께 유지될 가능성이 커진다.

그림 8. 재귀적 문자 분할 — 줄바꿈 같은 문자를 기준으로 나눠 문서 구조를 살린다(가변 크기).

 

 

8. 문서 유형별 분할

knowledge base에 여러 종류의 문서가 있다면, 유형별로 다르게 나눌 수 있다. 예를 들어 HTML은 문단·헤더 태그 기준으로, Python 코드는 함수 정의 기준으로, 일반 텍스트는 줄바꿈 기준으로 나눈다.

그림 9. 문서 유형에 맞춰 분할 기준을 달리한다 — HTML은 태그, 코드는 함수 정의 등.

 

실전 시작점. 고민이 된다면, 약 500자 크기 · 50~100자 겹침의 고정 크기 청킹으로 시작하면 좋다. 이런 청킹은 직접 구현할 수도 있고, 도와주는 외부 라이브러리도 많다. 문서에 metadata가 있다면 각 chunk가 원본의 metadata를 상속하고(필요하면 위치 정보도) 갖게 하면 된다.

 

다음 글에서는 여기서 더 나아간 고급 청킹 기법 — 의미 단위로 나누는 방식 등 — 을 살펴본다.