• 목록

RAG를 구현할 때 문서를 몇 글자씩 나눌지부터 정하는 경우가 많습니다. 그러나 같은 길이로 잘라도 어떤 조각에는 질문의 답과 조건이 함께 남고 다른 조각에는 결론만 떨어져 나올 수 있습니다.

문서 분할을 검색 단위와 문맥 보존의 관점에서 이해하는 방법을 정리합니다.

AI 생성 삽화 · 실사풍 연출 이미지입니다. 실제 고객 현장이나 실제 작업 결과를 촬영한 사진이 아닙니다.

핵심 정리
청크는 검색과 모델 입력에 활용할 문서 조각입니다. 길이뿐 아니라 제목·조건·표의 관계를 살펴보고, 실제 질문에서 필요한 근거를 함께 찾는지 평가해야 합니다.

1. 문서 전체와 검색 단위를 구분합니다

RAG에서는 질문과 관련된 자료를 찾아 모델에 제공하는 흐름을 구성합니다. 원본 문서가 길거나 여러 주제를 담으면 작은 단위로 나누어 검색 대상으로 삼을 수 있습니다.

이때 청크는 원본을 대신하는 새로운 정답이 아니라 원본의 일부입니다. 가상의 사내 안내문에 휴가 신청, 장비 대여, 방문자 등록이 함께 들어 있다면 한 질문에 필요한 부분을 찾기 위해 주제별 단위를 검토할 수 있습니다.

반대로 짧은 안내문을 지나치게 잘게 나누면 질문을 이해하는 데 필요한 조건이 떨어질 수 있습니다. 먼저 문서의 어떤 구조를 검색 단위로 사용할지 정하고 그다음 길이 제한을 적용하는 순서로 생각해 보면 좋습니다.

파일 하나가 항상 청크 하나여야 하는 것도 아니고, 문장 하나가 항상 가장 좋은 단위인 것도 아닙니다.

2. 제목과 예외 조건이 함께 남는지 봅니다

직접 만든 가상 규정에 일반 장비는 당일 반납하며 외부 행사 장비는 별도 승인 기간을 따른다는 내용이 있다고 생각해 보겠습니다. 당일 반납이라는 문장만 검색되고 예외 조건이 빠지면 모델은 질문자의 상황을 잘못 해석할 수 있습니다.

이 예시는 실제 기관의 규정이 아니라 문장 사이 관계를 설명하기 위한 것입니다. 분할 결과를 볼 때는 조각의 첫 문장이 무엇을 가리키는지와 그 조건이 같은 조각에 있는지 확인합니다.

제목을 붙이거나 관련 구역을 함께 검색하는 방식 등을 검토할 수 있지만 모든 문서를 같은 방식으로 처리할 필요는 없습니다. 표에서는 열 제목과 행의 관계가 유지되는지도 살펴봅니다.

숫자만 남은 행은 원래 어떤 항목의 수치인지 알기 어려우므로 추출된 텍스트 자체가 이해 가능한지부터 확인해야 합니다.

3. 글자 수와 토큰 수를 같은 값으로 보지 않습니다

Azure AI Search 문서는 분할 시 문서 특성과 사용자 질문, 사용하는 모델의 입력 조건을 함께 고려하도록 설명합니다. 글자 수로 자른 길이와 모델이 세는 토큰 수는 일치하지 않을 수 있습니다.

또한 임베딩에 넣는 한 청크의 길이와 최종 답변을 만들 때 사용하는 전체 문맥의 길이는 별도로 계산해야 합니다. 검색 결과를 여러 개 넣으면 각 조각은 짧아도 합계가 커질 수 있기 때문입니다.

학습용 설정표에는 분할 단위, 최대 길이를 측정하는 방식, 검색 결과 개수, 모델에 전달하는 다른 문구를 나누어 적어 볼 수 있습니다. 특정 예제의 숫자를 그대로 가져오기 전에 사용하는 모델과 도구의 현재 제한을 확인해야 합니다.

입력 한도에 들어간다는 사실은 기술적으로 처리 가능하다는 조건이며 답변에 가장 적절한 문맥이라는 뜻은 아닙니다.

4. 겹치는 구간의 이점과 비용을 함께 봅니다

인접한 청크의 일부 내용을 겹치게 두면 경계에서 끊어진 문맥을 이어 주는 데 도움이 될 수 있습니다. Azure 문서도 overlap을 문맥 유지 방법으로 설명하지만 적절한 크기는 자료와 용도에 따라 달라집니다.

직접 만든 가상 실험에서 같은 문장이 여러 청크에 반복되어 상위 검색 결과를 채웠다고 생각해 보겠습니다. 검색 결과 개수는 충분해 보여도 서로 다른 근거는 적을 수 있습니다.

겹침을 늘린 뒤에는 경계에 있던 답을 더 잘 찾는지뿐 아니라 중복 결과가 늘었는지도 확인합니다. 저장량이나 모델에 전달하는 텍스트의 중복도 함께 살펴볼 수 있습니다.

겹침이 없는 구성이 언제나 잘못된 것도 아니며 크게 설정할수록 좋은 것도 아닙니다. 문서 구조와 실제 질문을 기준으로 변경 효과를 비교하는 것이 중요합니다.

5. 원본으로 돌아갈 정보를 남깁니다

검색된 조각만 보관하면 나중에 어느 문서의 어떤 버전에서 나온 내용인지 확인하기 어려울 수 있습니다. 청크에 원본 문서 식별자와 제목, 구역 위치, 갱신 정보 등을 연결하는 방식을 설계하면 근거를 다시 확인하기 좋습니다.

예를 들어 가상 안내문의 개정 전후 내용이 함께 검색된다면 모델의 문장 표현을 고치기 전에 어떤 버전이 검색 대상에 남아 있는지 확인해야 합니다. 청크 번호 하나만으로 원본 위치가 안정적으로 유지되는지도 검토합니다.

문서 앞부분에 문단이 추가되면 단순 순번의 의미가 달라질 수 있기 때문입니다. 모든 메타데이터를 답변에 노출할 필요는 없지만 운영자가 출처와 갱신 상태를 추적할 수 있어야 합니다.

접근 권한이 필요한 문서라면 검색 단계에서 그 조건을 어떻게 적용하는지도 별도 설계 대상입니다.

6. 검색 실패와 답변 실패를 나누어 평가합니다

최종 답변이 틀렸다는 결과만으로 청크가 너무 크거나 작다고 결론 내리기 어렵습니다. 먼저 필요한 근거가 검색 결과에 들어왔는지 보고, 들어왔다면 모델이 그 근거를 올바르게 사용했는지 나눠 확인합니다.

가상의 평가 질문 묶음에는 단순 사실 질문과 예외 조건 질문, 여러 구역을 함께 봐야 하는 질문을 섞어 볼 수 있습니다. 각 질문 옆에 기대하는 원본 구역을 기록하면 분할 변경 전후를 비교하기 편합니다.

같은 자료와 질문을 유지한 채 분할 전략을 하나씩 바꾸면 원인을 좁히는 데 도움이 됩니다. 특정 질문 하나가 좋아졌다는 이유로 전체 구성을 교체하기보다 다른 유형에서 빠지는 근거가 없는지도 확인합니다.

이 과정에서 사용하는 점수와 합격 기준은 서비스 목적에 맞게 정해야 하며 보편적인 정답 수치를 가정하지 않습니다.

7. 분할 설정과 문서 갱신을 함께 관리합니다

실무에서 청크 크기는 한 번 정하고 잊는 값이 아닙니다. 문서 구조가 바뀌거나 질문 유형이 달라지면 분할 결과와 평가도 다시 확인할 수 있어야 합니다.

설정 기록에는 사용한 추출 방식과 분할 규칙, 메타데이터 구성, 평가 질문의 버전을 남기는 편이 좋습니다. 학습 프로젝트라면 청크 원문을 몇 개 직접 열어 읽는 것부터 시작해도 됩니다.

사람이 읽어도 대상과 조건을 알 수 없는 조각이라면 검색 점수만으로 문제를 이해하기 어렵습니다. 다만 사람이 자연스럽게 읽힌다는 조건 하나가 검색 성능을 보장하지는 않으므로 실제 질의 평가를 함께 진행합니다.

RAG의 문서 분할은 숫자 하나를 고르는 작업보다 질문에 필요한 근거가 어떤 단위로 발견되고 원본까지 추적되는지 설계하는 과정으로 이해하는 것이 좋습니다. 비교 실험의 결과표에는 최종 점수뿐 아니라 대표적인 실패 질문과 검색된 원문을 남겨 봅니다.

예외 조항이 빠졌는지, 제목이 없어 대상을 혼동했는지, 같은 내용만 반복 검색되었는지를 짧게 적습니다. 그러면 다음 변경이 청크 길이 조정인지 문서 추출 개선인지 구분하기 쉬워집니다.

원본 표 자체가 깨진 상태라면 분할 수치만 바꾸어도 필요한 관계를 되살리기 어렵습니다. 입력 문서의 품질과 분할 전략을 따로 기록하는 이유입니다.

8. 자주 묻는 질문

Q1. 청크 크기에 공통으로 쓰는 정답이 있나요?

문서 구조와 질문, 사용하는 모델에 따라 달라집니다. 도구의 예제값은 출발점으로 볼 수 있지만 실제 자료로 비교 평가해야 합니다.

Q2. 청크를 작게 만들면 검색이 항상 정확해지나요?

조건이나 제목이 분리되어 의미를 잃을 수 있습니다. 필요한 근거를 찾는지와 문맥이 충분한지를 함께 확인해야 합니다.

Q3. 겹침을 많이 넣으면 안전한가요?

경계의 문맥을 보존할 수 있지만 중복 결과가 늘 수 있습니다. 서로 다른 근거를 얼마나 확보하는지까지 비교하는 편이 좋습니다.

Q4. 답변이 틀리면 분할부터 바꿔야 하나요?

필요한 근거가 검색되었는지 먼저 확인합니다. 검색 결과에 근거가 있는데 답변에서 잘못 사용했다면 다른 단계도 살펴봐야 합니다.

참고 자료

• Microsoft Learn: Chunk documents in Azure AI Search