기업용 검색 증강 생성(RAG) 시스템을 도입할 때 많은 팀이 성능을 좌우하는 요소를 ‘더 우수한 임베딩 모델’이나 ‘최신 LLM‘에서 찾습니다. 하지만 막상 사내 문서를 넣어보면 엉뚱한 답변이 튀어나오거나 문서의 핵심을 찾지 못하는 경우가 허다합니다.
임베딩 모델을 바꾸기 전에, 먼저 점검해야 할 진짜 원인은 따로 있습니다. 바로 LLM이 읽기 전에 사내 데이터를 어떻게 쪼개고 다듬었는가 하는 데이터 전처리 상태입니다.
임베딩 모델 교체에 시간과 비용을 쏟기 전에 반드시 확인해야 할 데이터 전처리 기준 4가지를 짚어봅니다. 관련해 RAG에서 인용이 안 맞을 때 원인, 벡터DB보다 먼저 확인할 5가지(청크·메타데이터·검색 쿼리) 글을 함께 참고하시면 검색 정확도를 높이는 데 큰 도움이 됩니다.
- 임베딩 성능을 의심하기 전, 문서 형태와 구조를 정돈하는 전처리가 우선되어야 합니다.
- 문서의 성격에 맞는 청킹 크기, 메타데이터 설계, 노이즈 제거 기준을 세워야 정확도가 높아집니다.
문서의 성격에 맞춘 청킹(Chunking) 단위와 전략 수립
텍스트를 무조건 일정한 글자 수로 잘라내는 방식은 기업용 RAG에서 가장 흔하게 저지르는 실수입니다. 예를 들어 500자 단위로 기계적으로 문서를 끊어버리면, 문장의 맥락이나 표의 중간이 잘려 나가 LLM이 의미를 오해하게 됩니다.
기술 매뉴얼, 계약서, 사내 규정 등 문서의 성격에 따라 텍스트를 나누는 단위를 다르게 가져가야 합니다.
검색 효율을 극대화하는 메타데이터 설계와 구조화
본문 텍스트만 임베딩 벡터로 변환해 저장하면, 방대한 사내 문서 속에서 원하는 정확한 버전을 찾아내기 어렵습니다. 문서가 언제 작성되었는지, 어떤 부서의 자료인지, 보안 등급은 어떻게 되는지 등의 맥락 정보가 빠져있기 때문입니다.
전처리 단계에서 문서 제목, 작성일, 카테고리, 버전 정보를 메타데이터로 함께 태깅해 두어야 합니다. 이렇게 하면 검색 단계에서 필터링을 거쳐 정확도 높은 조각만 골라낼 수 있어 환각 현상을 크게 줄일 수 있습니다.
표, 이미지, 비정형 텍스트 등 노이즈 제거 기준
기업용 문서에는 수많은 표(Table), 그래프, 불필요한 머리글·바닥글, 특수문자가 포함되어 있습니다. 이를 그대로 파싱해서 넣으면 임베딩 벡터가 오염되어 검색 성능이 급격히 떨어집니다.
표 데이터는 마크다운이나 JSON 형태의 구조화된 텍스트로 변환하고, 반복되는 사내 양식의 머리글이나 쪽번호 같은 노이즈는 전처리 과정에서 미리 제거해야 합니다. 데이터의 순수성을 높여야 모델이 문맥에 집중할 수 있습니다.
업데이트 주기와 버전 관리 프로세스 연계
데이터 전처리는 한 번 하고 끝나는 작업이 아닙니다. 사내 규정이 바뀌거나 신규 제품 매뉴얼이 추가될 때마다 기존 데이터와 어떻게 교체할 것인지 기준이 있어야 합니다.
오래된 정보와 최신 정보가 벡터DB에 뒤섞여 들어가면 RAG 시스템은 어떤 정보가 정답인지 혼란스러워합니다. 문서가 수정되었을 때 기존 청크가 깔끔하게 삭제되고 새 청크로 교체되는 파이프라인 정비가 전 단계에서 함께 고려되어야 합니다.
아무리 성능 좋은 임베딩 모델을 써도, 엉성하게 잘린 쓰레기 데이터가 들어가면 나오는 결과물 역시 쓸모없는 답변뿐입니다.
성공적인 RAG 구축을 위한 마무리 체크리스트
기업용 RAG의 성패는 화려한 모델 스펙보다 우리 회사의 데이터를 얼마나 정갈하게 정제했는가에 달려 있습니다. 모델을 탓하기 전에 아래 항목들을 차례대로 점검해 보세요.
- 문서의 구조적 특성(표, 조항 등)을 고려해 청킹을 나누고 있는가?
- 검색 정확도를 높일 수 있는 필수 메타데이터가 누락되지 않았는가?
- 문서 내 불필요한 반복 노이즈와 서식 오류를 사전에 정제했는가?
- 문서 업데이트 시 구버전 데이터가 깔끔하게 갱신되는가?
정확한 답변을 내는 AI 시스템을 만들고 싶다면, 모델 선택이라는 겉모습보다 데이터 전처리의 기초 체력을 다지는 데 먼저 집중해 보시길 바랍니다. 관련하여 LLM 답변 검증, 정확도 점수보다 먼저 확인할 4가지(환각 줄이는 테스트 설계) 글을 통해 전처리 이후의 검증 단계도 함께 점검해 보시는 것을 권장합니다.
