청킹

청킹(Chunking)은 긴 문서나 데이터를 검색·임베딩·생성 단계에서 다룰 수 있는 작은 단위로 나누는 과정입니다. RAG에서는 각 조각이 검색 결과의 기본 단위가 되므로 크기뿐 아니라 문서 구조, 출처 경계, 메타데이터를 함께 설계해야 합니다.

자르는 기준은 문서와 질문에 따라 달라진다

토큰 기반 청킹은 정한 토큰 수에 맞춰 문서를 나눕니다. 구현과 처리량 예측이 쉽지만 문장이나 조항 중간이 끊길 수 있습니다. 문장·단락·제목 같은 문서 구조 기반 청킹은 사람이 만든 경계를 보존합니다. 의미 기반 청킹은 문장 사이의 주제 변화를 계산해 경계를 잡습니다. Microsoft의 RAG 청킹 안내는 문서 유형과 구조에 따라 접근법의 비용과 효과가 달라지므로 실제 자료로 비교하라고 권합니다.

모든 RAG에 맞는 고정 토큰 수는 없습니다. 짧은 FAQ는 질문과 답을 한 묶음으로 두는 편이 자연스럽고, 계약서는 조항 제목과 본문을 함께 보존해야 합니다. 코드에서는 함수와 클래스 경계가 중요하며, 회의 기록은 화자와 시간 구간이 검색 단서가 될 수 있습니다. 청크가 너무 작으면 답에 필요한 조건이 흩어지고, 너무 크면 관련 없는 내용이 함께 검색되어 정밀도가 낮아질 수 있습니다. 평가 질문에서 정답 근거가 어느 단위로 검색되는지 확인해 크기를 정해야 합니다.

겹침과 부모·자식 구조의 비용을 본다

오버랩은 앞 청크의 끝부분을 다음 청크에 반복해 경계에서 문맥이 끊기는 문제를 줄입니다. 하지만 겹침이 커지면 저장할 토큰과 임베딩 계산이 늘고, 거의 같은 청크가 검색 결과를 차지할 수 있습니다. 서로 다른 근거를 가져와야 할 자리에서 중복 결과가 늘어 생성 모델에 전달할 문맥을 낭비할 수도 있습니다. 고정 비율을 복사하기보다 문장 경계 손실과 검색 중복률을 함께 측정해야 합니다.

부모·자식 청킹은 작은 자식 청크로 세밀하게 검색하고, 답을 만들 때 그 청크가 속한 큰 부모 구간을 돌려주는 방식입니다. Amazon Bedrock의 청킹 문서는 자식 청크를 먼저 찾은 뒤 더 넓은 부모 청크로 바꾸는 계층형 방식을 설명합니다. 세밀한 검색과 넓은 문맥을 결합할 수 있지만, 여러 자식이 같은 부모로 합쳐지면 실제 반환 수가 줄고 큰 부모가 문맥 예산을 빠르게 쓸 수 있습니다.

예를 들어 제품 매뉴얼의 오류 코드 한 줄을 자식 청크로 찾고, 해결 절차 전체가 든 절을 부모 청크로 전달할 수 있습니다. 이때 제품명, 버전, 장 제목, 원본 URL, 접근 등급을 두 계층에 연결해야 합니다. Azure AI Search의 벡터 색인 설명은 청크 ID와 부모 ID, 제목, 본문, 벡터 필드를 함께 두는 예를 제시합니다. 메타데이터가 빠지면 같은 문구를 가진 다른 버전이나 다른 고객의 문서를 잘못 섞을 수 있습니다.

표와 모델별 입력 제한을 따로 처리한다

표를 단순히 행마다 잘라 내면 열 제목과 단위가 사라질 수 있습니다. 작은 표는 제목·헤더·관련 행을 한 단위로 보존하고, 큰 표는 각 조각에 열 이름과 표의 출처를 반복하는 방법을 검토합니다. 셀 병합, 각주, 페이지를 넘는 표는 파싱 단계에서 구조를 복원해야 합니다. 이미지나 도표를 설명문으로 바꿀 때도 원본 위치와 URL을 메타데이터로 남겨야 사용자가 근거를 확인할 수 있습니다.

청크는 먼저 임베딩 모델이 받을 수 있는 입력 길이 안에 있어야 합니다. 검색된 여러 청크를 질문과 지시문에 합친 최종 입력은 생성 모델의 컨텍스트 한도에도 맞아야 합니다. 두 한도는 서로 다른 모델과 단계의 제약입니다. Hugging Face의 잘라내기 문서는 토크나이저가 모델별 최대 입력 길이에 맞춰 자르는 설정을 설명합니다. 임베딩에 성공한 청크라고 여러 개를 생성 모델에 무제한 넣을 수 있는 것은 아닙니다.

검색 단위와 생성 단위도 같을 필요가 없습니다. 한 문장만 찾는 질의에는 작은 단위가 유리할 수 있고, 절차의 전후 조건을 설명하려면 주변 단락이 필요합니다. 청킹 평가는 청크 하나의 보기 좋은 모양보다 검색 재현율, 중복률, 출처 정확성, 최종 답의 근거 충실도를 함께 봐야 합니다. 문서 종류와 질문 유형이 바뀌면 같은 설정을 다시 평가해야 합니다.