텍스트 청킹은 긴 문서를 작은 조각으로 잘라 지식 베이스에 저장하는 방식입니다. 책 한 권, 계약서, 도움말 전체를 모델에 통째로 넣는 대신 수백 자에서 천 자 정도의 덩어리로 나누고 각각 벡터화한 뒤, 질문이 오면 가장 관련 있는 조각만 꺼내 모델이 답하게 합니다. RAG 파이프라인에서 가장 눈에 띄지 않지만 답의 정확도를 가장 크게 좌우하는 단계입니다.
왜 통째로 넣으면 안 되나
문서 전체를 컨텍스트에 넣으면 세 가지 문제가 생깁니다. 창에 다 들어가지 않고, 들어가도 비용이 비싸며, 모델이 무관한 내용 속에서 답을 찾다 쉽게 샛길로 빠집니다. 조각으로 나누면 검색 단계에서 관련 단락만 골라낼 수 있어 비용과 노이즈가 함께 줄어듭니다. 대가는 문서가 인위적으로 찢어진다는 점이며, 앞뒤 연결은 자르는 방식이 지켜줘야 합니다.
흔한 세 가지 절단 방식
고정 글자 수로 자르는 방식이 가장 간단하지만 문장이나 표를 중간에서 끊기 쉽습니다. 단락과 제목을 따라 자르면 원문 구조에 맞아 설명서나 규정 문서에 적합합니다. 의미가 바뀔 때 자르는 방식은 효과가 좋지만 구현이 복잡합니다. 대부분의 도구는 이웃한 조각 사이에 겹침(overlap)을 남겨, 경계에서 잘린 맥락이 다음 조각의 시작 부분에 다시 나타나게 합니다.
너무 잘게, 너무 크게 자르면 각각 뭐가 문제인가
너무 잘게 자르면 한 조각 안의 정보가 완결되지 않습니다. '상여 한도가 얼마냐'고 물었는데 꺼내온 조각에는 '초과분은 부사장 승인이 필요하다'만 있고 핵심 숫자는 이전 조각에 있어, 모델은 얼버무리거나 숫자를 지어낼 수밖에 없습니다. 너무 크게 자르면 한 조각에 여러 주제가 섞여 벡터가 평균화돼 어느 것과도 닮지 않게 되고 검색 순위가 떨어집니다. 설령 꺼내와도 모델이 긴 단락 속에서 핵심을 스스로 찾아야 합니다.
세 가지 흔한 오해
첫째, 작을수록 정확한 것은 아닙니다. 얻는 것은 세밀한 위치 특정이고 잃는 것은 맥락입니다. 둘째, 겹침은 많을수록 좋은 게 아닙니다. 과하면 같은 내용이 여러 번 저장돼 상위 결과가 온통 비슷한 조각으로 채워지고 다른 관련 조각을 밀어냅니다. 셋째, 답이 나쁜 게 늘 모델 탓은 아닙니다. 지식 베이스의 답이 시원찮을 때는 모델을 바꾸기보다 자르는 방식과 조각 크기를 돌아보는 편이 더 효과적입니다.
보편적인 최적값은 없습니다. 조항이나 FAQ 문서는 작게, 서술형 긴 글은 크게 자르고 제목 구조를 남기세요. 판단 기준은 하나뿐입니다. 실제 질문으로 테스트해, 꺼내온 조각만으로 정답을 뒷받침할 수 있는지 확인하는 것입니다.
