RAG 청킹, 시맨틱보다 문서별 검증이 먼저

RAG 청킹은 고정 크기를 기준선으로 두고, 문서 구조에 따라 재귀형과 시맨틱 방식을 후보에 더해 같은 질문으로 검증하는 편이 합리적이다. 청크 크기도 함께 시험하되 임베딩 모델과 검색 설정은 고정해야 분할 방식의 영향을 구분할 수 있다. Azure의 청킹 설계 가이드는 문서 유형과 구조, 품질·비용·처리량 요구에 맞춰 배포 전에 방식을 비교하도록 권한다.

시맨틱 청킹이 항상 앞서는 것은 아니다. 긴 학술 논문을 대상으로 한 청킹 방식 비교 연구에서는 시험한 구성의 클러스터 기반 시맨틱 청킹이 고정 크기나 재귀형보다 일관되게 우수하지 않았고, 질문 유형에 따라서도 결과가 달랐다. 연구에 사용된 자동 평가의 근거성 지표에는 누락이 많았으므로, 이 결과를 다른 문서군의 성능 순위로 옮기기보다 자체 질문과 원문 근거로 판단해야 한다.

문서 구조로 시험할 방식을 좁힌다

먼저 답이 원문에서 어떤 형태로 나타나는지 살핀다. 제목과 소제목이 범위를 정하는지, 표의 머리글과 셀이 함께 있어야 뜻이 통하는지, 답을 이루는 조건이 여러 문단에 흩어져 있는지 표본에 표시한다. PDF에서 추출한 텍스트라면 페이지 머리말과 줄바꿈이 본문에 섞였는지도 확인한다. 추출 과정에서 표의 열 순서가 무너졌다면 분할 방식을 바꾸기 전에 원문 추출부터 고쳐야 한다.

고정 크기는 같은 길이 제한을 적용하기 쉬워 출발점으로 적합하다. 자유로운 서술이나 짧은 메모에서는 그 단순함이 운영상 이점이 될 수 있다. 다만 길이만 보고 끊으면 문장 중간이나 표의 머리글과 값 사이에 경계가 생길 수 있다. 중요한 것은 경계가 보기 어색한지가 아니라 그 때문에 필요한 근거를 검색하지 못하는지다.

제목, 문단, 문장 같은 경계가 살아 있는 문서에는 재귀형을 후보로 둔다. 큰 단위가 제한 길이를 넘을 때 더 작은 단위로 내려가며 나누는 방식이라, 가능한 범위에서 문단이나 문장을 함께 보존할 수 있다. 한국어 문서에서는 제목 번호와 본문, 표 제목과 표 본문이 추출본에서도 연결돼 있는지 확인해야 한다. 구분 문자만 남고 구조가 깨진 문서라면 재귀형도 의도한 경계에서 멈추지 못한다.

시맨틱 방식은 한 절 안에서 주제가 자주 바뀌거나 같은 주제의 설명이 여러 곳에 흩어진 문서를 시험할 때 후보가 된다. 반면 조항 번호나 표의 행처럼 위치와 형식이 답의 일부라면 의미상 비슷한 문장을 묶는 것만으로 관계가 보존되지는 않는다. 이 경우 주제별 청크와 구조별 청크가 각각 어떤 질문에서 근거를 놓치는지 비교해야 한다. 추가 처리에 드는 시간과 비용도 같은 선택표에 올린다.

크기와 겹침을 방식과 함께 시험한다

분할 방식의 이름만 비교하면 크기의 효과를 놓친다. 작은 청크는 특정 구절을 찾기 쉬워도 정의와 예외 조건을 다른 조각으로 밀어낼 수 있다. 큰 청크는 주변 맥락을 함께 담지만 질문과 관계없는 내용까지 검색 결과에 실을 수 있다. 각 방식에서 여러 크기를 시험하고, 가장 좋은 한 조합만 고르기 전에 크기별 변화를 확인한다.

길이는 서비스에서 실제 사용하는 토크나이저로 잰다. 한국어의 글자 수나 띄어쓰기 단위는 모델 입력 토큰 수와 같지 않다. 조사, 영문 제품명, 숫자와 표 기호가 섞인 문서에서는 눈으로 비슷해 보이는 문단도 토큰 길이가 달라진다. 후보 크기를 정할 때는 문서 전체 길이뿐 아니라 답을 완성하는 문단과 표 행의 길이도 살핀다.

겹침은 경계에서 잘린 문맥을 다음 청크로 이어 줄 수 있다. 대신 같은 문장이 여러 청크에 복제되므로 색인량이 늘고, 반환 결과가 비슷한 내용으로 채워질 수 있다. 겹침을 적용한 후보에는 비율과 실제 중복량을 기록한다. 검색 결과에서 서로 다른 근거를 가져올 여지가 줄어드는지도 함께 본다.

반환 청크 개수와 생성 모델에 전달하는 총 토큰 수는 모두 기록해야 한다. 큰 청크와 작은 청크에 같은 개수 제한을 주면 큰 청크 쪽이 더 많은 원문을 전달받는다. 총 토큰 수만 맞추면 이번에는 답을 뒷받침할 수 있는 근거 조각의 수가 달라진다. 비교 기준을 명시하고 두 수치를 함께 제시해야 실제 서비스의 입력 예산에 맞는 선택을 할 수 있다.

질문과 정답 근거를 먼저 고정한다

평가 질문은 후보 청크를 만든 뒤에 고르지 않는다. 실제 이용자가 물을 법한 질문과 해당 답을 뒷받침하는 원문 구간을 먼저 모아야 특정 방식에 유리한 문항만 남는 일을 줄일 수 있다. Azure의 RAG 준비 가이드도 질문, 이를 다루는 원문 맥락, 유효한 답을 함께 수집해 청킹과 검색 평가에 쓰도록 제안한다.

질문에는 한 문단으로 답할 수 있는 경우뿐 아니라 제목을 알아야 범위가 정해지는 경우, 표의 머리글과 값을 함께 읽어야 하는 경우, 떨어진 문단의 조건을 결합해야 하는 경우를 넣는다. 답이 문서에 없는 질문도 별도로 둔다. 검색기가 비슷한 문단을 가져왔다는 이유만으로 답변이 단정적으로 생성되는지 확인할 수 있기 때문이다. 각 문항에는 필요한 원문 구간과 문서 유형을 함께 표시한다.

한국어 서비스에서는 실제 질의의 표현 차이도 반영한다. 사용자가 공식 용어 대신 약칭을 쓰거나 조사와 어순을 바꿔 묻는다면 그 형태를 질문 세트에 포함한다. 다만 같은 근거를 묻는 문장의 표현만 여러 번 바꾸면 한 주제가 전체 평가를 지배할 수 있다. 질문 유형별 결과를 읽을 수 있도록 문항의 출처와 범주를 남긴다.

모든 후보에는 같은 원문 추출본, 질문, 임베딩 모델과 검색 방식을 적용한다. 재순위화 여부와 생성 모델의 답변 지시도 고정한다. 한 후보에만 제목 메타데이터나 요약문을 붙이면 차이가 청킹에서 왔는지 알기 어렵다. 전처리 또는 검색 설정을 개선하려면 그 변경을 별도 실험으로 기록한다.

검색된 근거와 생성된 답을 따로 채점한다

검색 단계에서는 미리 표시한 정답 근거가 정해 둔 반환 범위 안에 들어왔는지 본다. 여러 원문 구간을 결합해야 답할 수 있다면 일부만 검색된 경우를 완전한 성공으로 세지 않는다. 후보마다 청크 경계가 달라도 채점 기준은 청크의 모양이 아니라 같은 원문 구간이어야 한다. 그래야 크고 작은 청크가 공통된 기준에서 비교된다.

답변 단계에서는 검색 성공과 근거성을 분리한다. 필요한 문단이 반환돼도 생성 모델이 예외 조건을 빼거나 표의 값을 다른 항목에 붙일 수 있다. 같은 답변 설정으로 생성한 결과에서 핵심 주장마다 원문 근거가 있는지, 근거 밖의 내용을 단정했는지 확인한다. 자동 점수는 검토할 사례를 추리는 데 활용하되, 채택을 좌우하는 질문은 원문과 답변을 직접 대조하는 편이 안전하다.

실패 원인도 검색 결과를 따라 구분한다. 정답 구간이 색인에서 빠졌다면 추출이나 전처리부터 살펴야 한다. 색인에는 있지만 반환되지 않았다면 분할 경계와 크기, 임베딩과 검색 설정을 차례로 점검한다. 필요한 근거가 반환됐는데 답이 틀렸다면 생성 단계의 문제일 수 있다. 이 구분이 있어야 청킹을 바꿔도 해결되지 않을 오류 때문에 색인을 다시 만드는 일을 피할 수 있다.

품질과 색인 비용을 같은 선택표에 놓는다

최종 선택표에는 문서 유형별 근거 검색 성공률, 답변 근거성, 청크 수, 색인에 투입한 토큰 수, 처리 시간과 갱신 비용을 함께 놓는다. 시맨틱 방식이 일부 질문을 개선해도 추가 처리 비용이나 지연 시간이 허용 범위를 넘으면 전체 문서에 적용하기 어렵다. 특정 문서군에서만 안정적인 개선이 확인된다면 그 문서군에 다른 방식을 적용하는 선택도 가능하다.

채택 기준은 결과를 보기 전에 정한다. 반드시 찾아야 할 근거, 허용 가능한 답변 오류, 색인 갱신 시간과 예산을 먼저 정해 두면 작은 점수 차이에 과도한 의미를 부여하지 않게 된다. 점수가 비슷하다면 구현과 유지보수가 쉬운 구성을 택할 수 있다. 청킹 정책을 바꿀 때는 기존 색인과 평가 결과의 버전을 구분해 변경 전후를 비교한다.

새 문서 양식이나 질문 유형이 들어오면 기존 평가 질문에 그 사례를 추가해 다시 시험한다. 이때 고정 크기 기준선을 유지하면 복잡한 설정의 이점이 새 문서에서도 남아 있는지 확인할 수 있다. 선택의 기준은 방식의 이름이 아니라 필요한 근거를 안정적으로 찾는지, 그 품질을 유지하는 비용을 감당할 수 있는지다.

함께 읽기: