RAG가 오답을 말하는 건 모델 때문이 아니라 문서부터입니다

정본 표시·적용일·담당자를 문서에 붙이는 정리 순서

이 글의 목차

“올해 남은 연차를 이월할 수 있나요?”라는 질문에 AI가 오전에는 가능, 오후에는 불가라고 답했습니다. 검색 결과를 열어 보니 2024년 규정, 2025년 개정 초안, 현재 확정본이 서로 다른 파일명으로 함께 들어 있었습니다.

RAG는 검색 실패보다 문서 충돌이 먼저 나타납니다. 모델을 바꾸기 전에 문서부터 정리해야 하는 이유입니다.

RAG 전 문서 정리 6가지 기준

  1. 정본 표시 — 같은 주제 파일이 여러 개면 ‘현재 기준(공식 기준)‘을 표시하고 참고자료와 등급을 분리
  2. 적용일자 기록 — 작성일이 아니라 실제 적용일을 기재하고, 대체된 문서에는 ‘대체됨’과 새 경로 표시
  3. 담당자 명시 — 내용 관리 담당자와 적용 대상(전 직원·부서·사업) 구분
  4. 공개 문서 분리 — 개인정보·인사·계약·비공개 회의자료를 공개 문서와 분리
  5. 파일명 정비 — ‘최종본’·‘회의자료’ 같은 이름 대신 주제·결론이 드러나는 이름
  6. 모르는 질문 기록 — 근거가 없거나 담당자 확인이 필요한 질문을 미리 문서에 남김 (AI가 멈춰야 할 조건)

파일명·폴더 규칙의 실무

  • 프로젝트명_문서종류_날짜_버전 형식
  • 대주제 → 소주제 폴더 구조, 깊이 3~4단계 제한
  • 공유 폴더 전체에 동일 규칙 적용

RAG 반입 전에 중복·만료·소유자·버전 규칙을 정리하는 순서 개념 이미지: 중복 문서, 만료 문서, 소유자 없는 문서, 버전 규칙을 순서대로 정리하는 작업서입니다.

테스트 질문은 세 종류를 함께

  • 구버전과 신버전 답이 다른 질문 → 최신 근거를 고르는가
  • 부서 간 규칙이 다른 질문 → 적용 범위를 명시하는가
  • 문서에 답이 없는 질문 → 담당자 확인으로 회부하는가

출처가 있다는 사실과, 그 출처를 지금 적용해도 된다는 판단은 다릅니다. 좋은 테스트는 정답뿐 아니라 그 답이 나온 문서까지 되돌아갈 수 있어야 합니다.

정리 전후를 측정합니다

  • 정답률(%) = 올바른 정본을 찾은 답변 수 ÷ 전체 질문 수 × 100
  • 잘못된 버전을 고른 횟수
  • 출처를 찾지 못한 횟수
  • 사람이 다시 확인한 이유

정리 후에도 ‘거창한 지식관리 체계’를 만들 필요는 없습니다. 많이 묻는 업무 하나의 문서 묶음부터 정본을 표시해 보세요. Core Company는 그 묶음을 기준으로 정리 규칙과 테스트 질문을 함께 설계해 드리겠습니다.

인사·계약·개인정보 문서의 접근과 보존은 최신 법령과 사내 정책을 확인해야 합니다.

CORE COMPANY / READINESS

이 기준을 우리 환경에 대입해 보세요

현재 운영 흐름을 먼저 확인하면 필요한 기술 범위를 줄일 수 있습니다.

도입 진단 문의

출처

  1. RAG 구축 전 문서 정리, 담당자가 먼저 해야 할 6가지 (luventa_official)
    확인일
    자료 유형
    네이버 블로그
  2. 회사 문서 관리, 직장인을 위한 문서 정리·파일 관리 팁 (cloudike2013)
    확인일
    자료 유형
    네이버 블로그

변경 이력

이 글의 수정과 검수 기록
날짜변경 내용검수자
V11: 네이버 블로그 리서치 2건 기반 재작성 — RAG 전 문서 정리 6기준·테스트 질문 구성 적용, 클라우드 제품 홍보 프레임 제거기술 책임자

작성과 검수

작성
Core Company
기술 검토
기술 책임자 검토 대기
AI 활용 공개
초안의 구조와 문장 정리에 AI 보조를 사용했으며, 공개 전 기술 책임자가 사실·적용 조건·연락 수단을 검토해야 합니다.

CORE COMPANY / READINESS

우리 환경에도 적용할 수 있을까요?

현재 운영 방식과 필요한 범위를 먼저 정리해 드립니다.

도입 진단 문의