RAG 전처리란 무엇인가: 답변 품질을 결정하는 문서 준비 과정 완전 정리

RAG 전처리란, 검색 증강 생성에 사용할 문서를 구조와 의미가 유지되도록 분석하고 정리해 검색 가능한 조각으로 만드는 사전 작업으로, 모델이 근거로 삼을 자료의 품질을 이 단계에서 결정하는 처리입니다.

RAG 전처리가 필요한 이유

모델을 바꿔도 답변이 나아지지 않는 경우가 있습니다.

생성형 AI를 도입한 기관에서 자주 나오는 이야기가 있습니다. 좋은 모델을 붙였는데 정작 업무 질문에는 엉뚱한 답이 돌아온다는 것입니다. 원인을 거슬러 올라가면 모델이 아니라 모델에게 준 자료에 있는 경우가 많습니다. 행정 문서와 매뉴얼, 법령이 PDF와 한글 워드프로세서 문서로 쌓여 있고, 이 파일들을 그대로 텍스트로 뽑아 넣었기 때문입니다.

문제는 텍스트만 뽑는 순간 구조가 사라진다는 데 있습니다. 반납 절차를 설명하는 문서에서 국비와 도비, 잔액과 이자가 다층 헤더로 갈라진 표를 문장 나열로 펼치면, 어떤 계정이 어느 조건에 해당하는지 알 수 없게 됩니다. 모델은 이 흐트러진 자료 위에서 그럴듯한 문장을 만들어 냅니다. 답변 품질이 낮은 원인은 대개 여기에 있습니다.

RAG 전처리의 정확한 정의: 텍스트 추출과 무엇이 다른가

텍스트 추출과 RAG 전처리, 세 가지 축의 차이

첫째, 대상이 다릅니다. 텍스트 추출은 문서에 적힌 글자를 대상으로 삼습니다. RAG 전처리는 글자에 더해 제목과 본문의 위계, 표의 행과 열, 그림과 설명의 관계, 각주와 본문의 연결까지를 대상으로 삼습니다. 문서를 읽는 것이 아니라 문서의 뼈대를 함께 옮기는 작업입니다.

둘째, 목표가 다릅니다. 텍스트 추출의 목표는 내용을 빠짐없이 꺼내는 것입니다. RAG 전처리의 목표는 나중에 질문이 들어왔을 때 정확히 그 대목이 검색되도록 자료를 배치하는 것입니다. 그래서 같은 문서라도 어떤 질문을 받을 것인지에 따라 조각을 나누는 방식이 달라집니다.

셋째, 성과지표가 다릅니다. 텍스트 추출은 문자 정확도로 측정합니다. RAG 전처리는 최종 답변의 정확도로 측정합니다. 한 국세 행정 검증에서는 33개 문서와 361개 문항으로 구성한 평가셋을 만들어 구조화와 검색 품질을 함께 확인했습니다. 전처리 단계만 따로 떼어 점수를 매기기 어렵기 때문에, 질문과 정답의 쌍을 미리 만들어 두는 절차가 사실상 필수입니다.

두 작업은 대체 관계가 아닙니다. 문자 인식이 부정확하면 아무리 잘 나눠도 잘못된 내용이 검색됩니다. 인식 위에 구조 복원을 올리고 그 위에 조각 나누기를 올리는 순서가 맞습니다.

답변 품질을 지키는 RAG 전처리의 6가지 조건

실제 구축에 들어가는 RAG 전처리의 6가지 조건

첫째, 구조를 보존한 형태로 변환해야 합니다. 제목과 절, 표, 목록, 그림 설명이 각각 무엇인지 표시가 남아 있어야 검색 단계에서 활용할 수 있습니다. 구조 요소를 태그로 구분해 마크업 형태와 구조화 데이터로 함께 생성해 두면 이후 선택지가 넓어집니다.

둘째, 조각의 경계를 문서의 논리 단위에 맞춰야 합니다. 글자 수만 기준으로 자르면 표가 중간에서 끊기고 조항이 두 조각으로 갈라집니다. 절 단위나 표 단위를 우선 경계로 삼고 길이는 그다음 조건으로 두는 편이 안전합니다.

셋째, 표를 별도로 처리해야 합니다. 표는 문장과 성질이 달라 같은 방식으로 잘라 넣으면 검색이 잘 되지 않습니다. 표 전체를 하나의 조각으로 유지하면서 그 표가 어떤 절에 속하는지를 함께 붙여 두는 구성이 실용적입니다.

넷째, 메타데이터를 함께 실어야 합니다. 문서 제목과 발행 기관, 시행일, 개정 이력, 원문 페이지 번호가 조각마다 붙어 있어야 답변에 근거를 제시할 수 있습니다. 근거를 제시하지 못하는 답변은 업무에서 사용되지 않습니다.

다섯째, 개인정보를 비식별화해야 합니다. 공공 데이터를 검색 용도로 옮길 때는 개인을 특정할 수 있는 항목을 가리거나 대체하는 처리가 전제 조건에 가깝습니다. 이 작업은 조각을 만들기 전에 수행해야 검색 색인에 원본 값이 남지 않습니다.

여섯째, 평가셋을 먼저 만들어야 합니다. 전처리 방식을 바꿨을 때 나아졌는지 나빠졌는지를 판단하려면 같은 질문으로 비교할 기준이 있어야 합니다. 문항 수백 개 규모의 평가셋을 초기에 구축해 두면 이후 개선이 측정 가능한 작업이 됩니다.

RAG 전처리의 실제 적용 방법

문서 자산을 먼저 분류합니다

프로젝트의 첫 작업은 변환이 아니라 대상 문서의 성격 파악입니다. 법령과 고시처럼 조항 구조가 뚜렷한 문서, 매뉴얼처럼 절과 항이 계층을 이루는 문서, 공문처럼 짧고 독립적인 문서, 신고 서식처럼 표가 본문인 문서는 각각 다른 방식으로 나누어야 합니다.

한 광역 지방자치단체의 구축 사례를 보면 행정 문서를 구조화한 뒤 텍스트와 표, 이미지로 나누고, 마크업과 구조화 데이터, 조각과 키워드를 함께 생성해 지식 저장소에 적재하는 흐름으로 설계되었습니다. 문서를 한 번 변환해 여러 산출물을 만들어 두면 이후 검색 방식이 바뀌어도 원본을 다시 처리하지 않아도 됩니다.

구조화와 조각 나누기를 분리합니다

구조화와 조각 나누기를 하나의 처리로 묶으면 조각 크기를 조정할 때마다 문서를 다시 분석해야 합니다. 두 단계를 나누어 두면 구조화 결과는 그대로 두고 조각 규칙만 바꿔 실험할 수 있습니다.

실제 구성에서는 문서를 변환해 구조 데이터로 만든 뒤 일정 길이 단위로 텍스트를 분할하고 결과를 정렬하는 방식이 쓰입니다. 이때 앞뒤 조각을 조금씩 겹치게 두면 문장이 경계에서 잘려 의미가 끊기는 문제를 줄일 수 있습니다.

국내 환경에서의 RAG 전처리

국내 공공 문서 자산의 상당 부분은 한글 워드프로세서 형식으로 쌓여 있습니다. 이 형식을 원본 그대로 처리할 수 있는지가 첫 관문이 됩니다. 다른 형식으로 변환하는 과정에서 표의 병합 정보가 손실되면 그 뒤 단계에서 회복할 방법이 없습니다.

문서 자체의 조건도 다릅니다. 공문과 매뉴얼, 법령, 보고서가 한 저장소에 섞여 있고, 관공서 서식 특유의 다층 표와 원문자 항목번호, 표를 침범한 도장이 함께 들어옵니다. 개정이 잦은 것도 국내 공공 문서의 특징이라, 최신본 관리와 변경 이력 추적을 전처리 단계의 요건으로 잡아 두는 편이 좋습니다.

여기에 더해 망분리 환경에서는 외부 임베딩 서비스 호출이 제한됩니다. 문서 변환부터 조각 생성, 임베딩까지 내부망에서 수행할 수 있는 구성인지 확인이 필요합니다.

원본과 조각을 연결해 둡니다

검색된 조각만으로 답변을 만들면 사용자가 근거를 확인할 방법이 없습니다. 조각마다 원본 파일과 페이지 번호, 문서 안의 위치를 함께 저장해 두면 답변에 출처를 붙일 수 있습니다.

이 연결은 업무에서 특히 중요합니다. 행정 담당자가 정책 정보를 조회할 때 필요한 것은 답변 문장만이 아니라 그 근거가 어느 지침 몇 쪽에 있는지입니다. 원문을 열어 확인할 수 있어야 답변을 근거로 결재를 올릴 수 있습니다.

구현할 때는 조각을 만들 때 부여한 식별자를 색인과 원본 저장소 양쪽에서 함께 쓰는 방식이 단순합니다. 나중에 원본이 교체되어도 어느 조각이 영향을 받는지 추적할 수 있습니다.

문서가 개정되면 조각도 갱신합니다

공공과 금융의 문서 자산은 개정이 잦습니다. 지침이 바뀌고 서식이 개정되며 법령이 시행일에 맞춰 갈립니다. 원본이 바뀌었는데 색인이 그대로면 모델은 폐지된 규정을 근거로 답변합니다.

그래서 전처리 파이프라인에는 갱신 경로가 함께 있어야 합니다. 새 버전이 들어오면 해당 문서의 조각을 찾아 교체하고, 이전 버전은 삭제하거나 시행 기간을 표시해 검색 대상에서 제외합니다. 문서에 시행일과 폐지일을 메타데이터로 붙여 두면 이 처리가 자동으로 가능해집니다.

전체를 다시 처리하는 방식은 문서량이 늘어날수록 감당하기 어려워집니다. 변경된 문서만 골라 처리하는 구조를 처음부터 잡아 두시기 바랍니다.

검색 실패 사례를 모아 되먹입니다

전처리 품질은 한 번에 완성되지 않습니다. 실제 질문이 들어오기 시작하면 예상하지 못한 실패가 드러납니다.

가장 흔한 유형은 세 가지입니다. 질문에 쓰인 표현과 문서의 표현이 달라 검색되지 않는 경우, 관련 내용이 여러 조각에 흩어져 하나만 검색되는 경우, 표에 담긴 정보가 문장 형태의 질문과 맞지 않는 경우입니다.

이런 실패 사례를 모아 두면 대응 방향이 보입니다. 표현 차이는 조각에 키워드를 함께 붙여 해결하고, 흩어진 내용은 조각 경계를 다시 잡아 해결하며, 표는 요약 문장을 함께 저장해 해결합니다. 실패 사례가 쌓일수록 평가셋도 두꺼워지므로, 개선의 근거와 측정 기준이 함께 자라납니다.

자주 묻는 질문

대개 아닙니다. 원인이 전처리 단계에서 문서 구조가 훼손된 데 있는 경우가 많습니다. 먼저 검색된 조각이 질문과 맞는지부터 확인하시는 편이 빠릅니다.

문서 성격에 따라 다릅니다. 길이보다 경계가 중요하므로 절이나 표 단위를 먼저 정하고 길이는 그 안에서 조정하시기 바랍니다.

가능합니다. 표를 문장으로 펼치지 않고 구조를 유지한 채 하나의 조각으로 두면서 소속 절 정보를 함께 붙이는 방식이 효과적입니다.

가능합니다. 다만 변환 과정에서 표 구조가 손실되기 쉬우므로 원본 형식을 그대로 처리할 수 있는지 확인하시기 바랍니다.

조각을 만들기 전에 비식별화 처리를 먼저 수행합니다. 색인이 만들어진 뒤에 처리하면 원본 값이 검색 결과에 남을 수 있습니다.

아닙니다. 변경된 문서의 조각만 찾아 교체하는 구조로 설계하면 됩니다. 문서에 시행일과 폐지일을 메타데이터로 붙여 두면 이전 버전을 검색 대상에서 자동으로 제외할 수 있습니다.

가능하지만 표에는 요약 문장을 함께 저장하시는 편이 좋습니다. 표는 문장 형태의 질문과 형식이 달라 그대로 두면 검색되지 않는 경우가 있습니다.

질문과 정답으로 구성한 평가셋을 만들어 측정합니다. 한 검증 사례에서는 33개 문서에 대해 361개 문항을 준비해 구조화와 검색 품질을 함께 확인했습니다.

관련 용어