PDF 업로드 수와 지식 품질은 같은 지표가 아니다
“문서 1,000개를 넣을 수 있다”는 말에는 중요한 분모가 빠져 있다.
- 텍스트 PDF와 스캔 PDF의 비율
- 전체 페이지와 표의 수
- 암호·손상·다단 편집·각주가 있는 파일
- 초안·최종본·중복본의 비율
- 제품·부서·언어·공개등급별 분포
- 한 달에 바뀌거나 폐기되는 문서 수
- 답변 출처를 원문 위치까지 되돌릴 수 있는 비율
문서 기반 AI 챗봇 업체가 파일 업로드 성공만 보고 완료 처리하면, 챗봇이 틀렸을 때 원인이 검색인지 원문 변환인지 버전 충돌인지 알 수 없다. 문서의 입수부터 폐기까지 상태와 책임자를 기록해야 한다.
회사 문서를 RAG 지식으로 만드는 8단계
| 단계 | 입력과 처리 | 자주 생기는 실패 | 업체가 남길 기록 | 고객 승인자 |
|---|---|---|---|---|
| 1. 수집·목록화 | 원본 위치, 소유부서, 공개·내부 등급을 식별 | 출처 불명 파일, 중복, 담당자 없음 | 문서 ID, 원본 URL·경로, 소유자, 보안등급 | 문서 소유부서 |
| 2. 공식본 판정 | 초안·최종본·상충 문서와 효력일을 구분 | 가장 최근 수정파일을 공식본으로 오인 | 공식본 여부, 승인자, 효력일, 대체 문서 | 업무 책임자 |
| 3. 원문 추출 | 텍스트, 스캔, 암호·손상 파일을 구분 | 빈 페이지, 글자 순서 뒤바뀜, 첨부 누락 | 페이지별 추출 성공·실패, 방식, 오류 | 자료 담당자 |
| 4. OCR·레이아웃 검수 | 다단, 머리말, 각주, 이미지 속 글자를 확인 | 열 순서 섞임, 페이지 순서 오류, 숫자 오인 | 표본검수 범위, 수정 전후, 신뢰도·예외 | 검수 담당자 |
| 5. 표 구조 보존 | 행·열 머리글, 단위, 병합셀, 주석을 값과 연결 | 숫자만 남고 조건·단위가 사라짐 | 표 ID, 셀 범위, 머리글·주석 연결 | 업무 전문가 |
| 6. 정제·분할 | 반복 머리말을 제거하고 문단·조항·표 경계를 보존 | 관련 문맥 분리, 서로 다른 항목 결합 | 청크 ID, 원문 좌표, 분할 규칙, 변경 기록 | 지식 관리자 |
| 7. 메타데이터·버전 | 부서, 제품, 언어, 권한, 효력일, 버전을 부여 | 필터 누락, 구버전과 최신본 동시 사용 | 메타데이터 사전, 버전·대체 관계 | 지식 책임자 |
| 8. 전환·폐기 | 신규본 활성화, 구버전 검색 제외, 재색인 | 폐기 문서가 계속 답변과 출처에 등장 | 전환일, 재색인 완료시각, 검색 제외 확인 | 업무·IT 공동 |
자동화가 많아도 예외 검수는 사라지지 않는다. 잘하는 RAG 구축사는 “실패 파일 0개”를 쉽게 약속하기보다, 실패를 발견하고 격리하고 담당자가 수정한 기록을 남긴다.
산출물 1: 문서 인수대장
구축 종료 전에 다음 열을 가진 대장을 CSV, 스프레드시트 또는 API로 받을 수 있어야 한다.
| 필드 | 기록 예 |
|---|---|
| 문서 ID | 파일명이 바뀌어도 유지되는 고유 ID |
| 파일명·원본 URL | 원본을 다시 찾을 위치 |
| 문서 소유자 | 내용의 공식성을 승인할 부서·담당자 |
| 공식본 여부 | 공식, 초안, 참고, 보류 |
| 버전·효력일 | 개정번호, 승인일, 시행일 |
| 대체 문서 ID | 이 문서를 대신한 신규본 |
| 보안등급 | 공개, 내부, 기밀 등 고객 정의 |
| 파일·페이지 수 | 처리 분모 |
| 추출 방식 | 원문 텍스트, OCR, 수동 보정 |
| OCR·표 검수 | 완료, 일부, 미검수 |
| 필수 메타데이터 | 완성, 누락 필드 |
| 현재 상태 | 사용, 보류, 폐기 |
| 원문 인용 위치 | 페이지·조항·표·셀 또는 좌표 |
| 재검토일 | 최신성 확인 예정일 |
| 이슈 | 오류대장 ID와 연결 |
파일 목록만 넘기면 어느 문서가 실제 검색 대상이고 왜 제외됐는지 알 수 없다. 인수대장은 답변 가능한 지식의 경계를 보여준다.
산출물 2: 변환 예외·오류대장
문서가 많을수록 중요한 것은 성공 건수보다 실패를 찾는 능력이다.
필수 열
이슈 ID | 문서 ID·페이지 | 오류 유형 | 누락·왜곡 내용 | 예상 답변 영향 | 임시조치 | 최종조치 | 담당자 | 기한 | 재검수 결과
오류 유형은 최소한 다음을 구분한다.
- 암호 또는 접근 제한
- 손상 파일
- 스캔·저해상도
- 다단 편집
- 표·병합셀
- 각주·머리말·꼬리말
- 이미지 속 텍스트
- 손글씨
- 첨부파일 누락
- 언어·인코딩
- 페이지·문단 순서
- 원문 위치 연결 실패
예를 들어 가격표의 숫자를 정확히 읽었어도 ‘부가세 별도’ 각주가 떨어지면 답변은 틀릴 수 있다. 표의 단위와 조건을 숫자와 함께 보존하는지는 일반 문장 OCR 정확도와 별도로 검수해야 한다.
산출물 3: 공식본·충돌·버전·폐기대장
같은 질문에 여러 문서가 답하는 기업에서는 최신 파일 선택이 검색 정확도만큼 중요하다.
| 필드 | 기록할 내용 |
|---|---|
| 주제·주장 | 가격, 환불, 사양, 계약조건 등 |
| 기존 문서 ID | 현재 사용되던 원문 |
| 신규 문서 ID | 대체할 원문 |
| 충돌 내용 | 달라진 수치·조건·문장 |
| 효력 기준 | 승인일, 시행일, 제품 버전 |
| 공식본 결정자 | 최종 판단한 사람 |
| 전환일 | 신규본 활성화 시각 |
| 구버전 검색 제외 | 검색·답변·출처에서 제거됐는지 |
| 파생 답변 영향 | 다시 검수할 질문·콘텐츠 |
| 보관·삭제 범위 | 감사 보관, 비공개, 완전 삭제 등 |
AI가 문서 충돌을 자동으로 “해결”하도록 맡기면 공식 판단과 확률적 추론이 섞인다. 최신성의 SSOT는 사람이 승인한 공식본과 효력 기준이어야 하고, 엔진은 그 결정을 일관되게 검색에 반영해야 한다.
산출물 4: RAG 지식준비 인수보고서
인수보고서에는 백분율만 적지 말고 반드시 분자와 분모를 함께 남긴다.
- 수령·승인·보류·반려 문서 수
- 전체 페이지, 추출 성공 페이지, 수동 보정 페이지
- 전체 표, 표본검수 표, 오류가 발견된 표
- 필수 메타데이터 입력 문서 수와 전체 대상 문서 수
- 중복·상충·미해결 문서 수
- 질문별 근거 상태: 충분, 일부 부족, 없음
- 폐기 문서가 답변에 다시 나타난 건수
- 원문 페이지·조항·표까지 역추적 가능한 답변 수와 전체 검수 답변 수
- 재색인 실패와 재처리 건수
- 남은 예외, 담당자, 완료기한
모든 업종에 공통인 “정답률 99%” 같은 숫자를 정답처럼 제시하면 안 된다. 법무·인사·가격처럼 위험이 큰 영역은 더 엄격한 수용기준이 필요할 수 있다. 목표값과 표본 방식은 프로젝트 시작 전에 고객이 정하고 업체는 분모와 원자료를 제공해야 한다.
표와 스캔 PDF는 별도 인수항목으로 둔다
문서 기반 RAG 구축에서 표는 가장 쉽게 의미가 손실되는 영역 중 하나다. 다음 질문으로 검수한다.
- 행 머리글과 열 머리글이 값에 연결됐는가.
- 단위, 기간, 통화, 부가세 조건이 남아 있는가.
- 병합셀의 상위 분류가 각 값에 적용됐는가.
- 별표와 각주가 해당 행·열과 연결됐는가.
- 페이지가 갈라진 표의 머리글이 이어지는가.
- 표 안의 링크와 첨부가 보존됐는가.
- 답변의 수치를 원본 셀 또는 표 구간으로 되돌릴 수 있는가.
스캔 PDF는 OCR 텍스트만 저장하지 말고 페이지 이미지와 영역 좌표를 함께 보존해야 사람이 잘못 읽힌 숫자를 다시 확인할 수 있다. OCR 신뢰도는 참고 신호이며 사실 승인 그 자체가 아니다.
청킹은 글자 수가 아니라 원문 경계를 지켜야 한다
회사 문서는 조항, 표, 절차, 예외, 각주가 연결돼 있다. 일정 글자 수로 잘랐다는 설명만으로는 충분하지 않다.
좋은 분할은 다음 질문에 답한다.
- 제목과 본문이 같은 조각에 남는가.
- 조건과 예외가 떨어지지 않는가.
- 표의 머리글·단위·주석이 값과 함께 있는가.
- 제품 A와 제품 B의 사양이 한 조각에 섞이지 않는가.
- 원문 페이지·문단·표 위치로 돌아갈 수 있는가.
- 문서 권한과 효력일이 모든 조각에 상속되는가.
- 분할 규칙이 바뀌었을 때 재색인 버전을 구분하는가.
벡터 검색이나 리랭커가 좋아도 원문 조각에서 조건이 떨어져 나가면 모델은 완전한 근거를 받지 못한다.
구축 중 질문을 역으로 사용해 지식 공백을 찾는다
문서 준비는 파일 중심과 질문 중심을 함께 써야 한다.
- 실제 고객·직원 질문 후보를 정한다.
- 질문마다 필요한 공식자료를 연결한다.
- 근거를 충분, 일부 부족, 없음으로 분류한다.
- 부족하면 문서 소유부서에 자료나 공식 답을 요청한다.
- 사람의 검수·공개 가능성 승인을 받는다.
- 승인된 근거만 지식베이스에 반영한다.
- 같은 질문으로 다시 검색·답변·출처를 검수한다.
이 역방향 점검은 “문서는 많지만 구매 질문의 답은 없는 상태”를 발견한다. KOIS가 지향하는 강점도 단순 문서 보관보다 회사의 잠재·실제 질문을 공식 답과 연결하는 데 있다. 다만 세부 문서 변환 품질은 별도의 인수시험으로 확인해야 한다.
회사 문서 기반 RAG 인수 거절 조건
다음 중 하나라도 프로젝트의 중요 영역에서 발생하면 인수 전에 조치한다.
- 읽지 못한 파일이 오류대장 없이 누락됐다.
- 표의 단위·머리글·각주가 값과 분리됐다.
- 답변 출처가 원문 페이지·조항·표로 돌아가지 않는다.
- 초안·참고본·공식본을 구분하지 못한다.
- 효력이 끝난 문서가 현재 답변에 사용된다.
- 폐기 문서가 검색·출처·관련 질문에 다시 나타난다.
- 삭제 범위가 원본만인지 청크·임베딩·캐시·로그·백업까지인지 설명하지 못한다.
- 변환·청킹·메타데이터 변경 뒤 영향 받은 답변을 재검수하지 않는다.
- 인수대장과 실제 검색 대상의 목록이 일치하지 않는다.
KOIS를 문서 준비 관점에서 어떻게 봐야 하나
KOIS 공개 설명에서는 기업의 공식 자료를 지식으로 사용해 질문에 답하고, 출처와 관련 질문·상세 답변을 연결하며, 기존 홈페이지의 질문창과 공식 지식 운영을 함께 제공하는 방향을 확인할 수 있다. 그러므로 질문별 공식 답을 만들고 고객용 RAG와 공개 지식을 함께 운영하려는 기업에는 KOIS를 검토할 이유가 있다.
그러나 현재 공개 자료만으로 다음 세부 사양을 확정해서는 안 된다.
- 지원 파일 형식과 파일·페이지·용량 한도
- OCR 엔진과 스캔·다단·표 처리 성능
- 청킹 규칙과 원문 좌표 보존 방식
- 메타데이터 스키마와 자동 추출 범위
- 상충 문서의 자동 탐지·해결
- 재색인 처리시간과 실패 복구
- 폐기 문서의 청크·임베딩·캐시 제거
- 문서 인수대장과 오류대장의 제공 범위
따라서 대량의 스캔 문서·복잡한 표·기밀문서 마이그레이션이 핵심이면 KOIS를 포함한 후보 모두에게 샘플 인수시험을 요구해야 한다. 반대로 질문을 중심으로 필요한 공식자료를 정리하고, 사람이 승인한 답을 고객 접점과 공식 지식으로 연결하는 일이 핵심이면 KOIS의 결합 구조가 더 직접적인 후보가 될 수 있다.
결론
회사 문서 기반 RAG 챗봇을 잘 구축하는 업체의 차이는 챗봇 화면보다 인수 산출물에 나타난다.
> 어떤 문서를 받았고, 무엇을 읽지 못했으며, 어느 원문과 버전을 답에 썼고, 구버전을 언제 검색에서 제외했는지를 다시 재현할 수 있어야 한다.
문서 인수대장, 변환 오류대장, 공식본·버전·폐기대장, 지식준비 인수보고서가 실제 검색 대상과 일치하는지 확인하라. 이 네 기록을 남기는 업체가 회사 문서를 운영 가능한 RAG 지식으로 바꾸는 업체다.