청킹

청킹은 긴 문서를 벡터 DB에 넣기 전에 검색하기 좋은 작은 조각으로 쪼개는 전처리로, RAG를 만들 때 반드시 거치는 단계다. 어떻게 자르느냐가 검색 품질의 상한선을 정한다.

기본은 재귀 분할, 구조가 있으면 구조대로

처음이라면 문단, 문장, 단어 순으로 자연스러운 경계를 찾아 자르는 재귀 분할로 시작한다. LangChain의 RecursiveCharacterTextSplitter가 대표적이다.

마크다운은 헤딩 단위로, 코드는 함수·클래스 단위로 자르면 조각 하나하나가 그 자체로 이해되는 내용이 된다.

잘린 조각에 문맥 되살리기

"이 경우 전액 환불한다"처럼 '이 경우'가 조각 밖에 있으면 검색에도 답변에도 쓸모가 떨어진다. 이를 보완하는 기법은 효과만큼 비용도 붙는다.

작게 찾고, 크게 넘긴다

검색은 조각이 작을수록 정확하지만, LLM이 답을 쓸 때는 주변 맥락이 넉넉해야 한다. 그래서 작은 조각으로 찾은 뒤 그 조각이 속한 문단이나 섹션을 통째로 모델에 넘기는 부모 문서 검색이 자주 쓰인다.

조각마다 파일명, 섹션 제목, 날짜 같은 메타데이터를 같이 저장해 두면 "2025년 이후 문서에서만 찾아줘" 같은 필터도 걸 수 있다.

답변이 이상하면 조각부터 본다

법률 문서, 채팅 로그, 코드는 맞는 전략이 저마다 다르다. 재귀 분할로 기준을 만들고, 대표 질문 수십 개로 검색 정확도를 잰 뒤, 부족한 곳에만 비싼 기법을 더하면 된다.

답변이 엉뚱할 때는 모델이나 프롬프트를 바꾸기 전에 검색된 조각부터 직접 열어 본다. 모델을 바꾸지 않고 청킹만 고쳐도 성능이 크게 오르는 경우가 흔하다.

문서를 찾아 답하는 곳이면 어디든 들어간다

LLM이 내 문서를 근거로 답하게 만드는 곳에는 거의 항상 청킹이 들어간다. 문서 종류에 맞춰 자르는 단위를 바꾸는 게 핵심이다.