RAG PoC 평가 방법: 정답률·출처·권한을 함께 검증하기

RAG PoC는 데모에서 자연스러운 답변이 나오는지를 보는 것으로 끝내기 어렵습니다. 실무자가 필요한 정보를 찾았는지, 답변이 문서 내용과 맞는지, 원문을 확인할 수 있는지, 허용된 자료만 사용했는지를 나눠 평가해야 합니다.

먼저 하나의 업무와 대표 문서를 정하세요. “계약서를 잘 분석하는 AI”처럼 넓은 목표보다 “현재 계약과 변경 합의서에서 납기 조건을 찾고 원문 위치를 확인한다”는 목표가 평가 질문을 만들기 쉽습니다.

질문을 만들기 전에 기대 결과를 적으세요

업무 담당자가 실제로 묻는 질문을 모으고, 각 질문에 사용할 문서와 기대 답변을 표시합니다. 답변 문구를 그대로 외우게 하는 평가보다 반드시 포함할 정보와 빠지면 안 되는 조건을 적는 편이 유용합니다.

예시 질문은 다음처럼 나눌 수 있습니다.

이 표는 평가를 준비하는 예시입니다. 실제 파일명과 질문은 담당자가 사용하는 표현으로 바꾸세요.

답이 틀렸을 때 관련 문서를 찾지 못한 것인지, 찾은 문서를 잘못 해석한 것인지 나눠야 다음 조치를 정할 수 있습니다. 관련 문서가 검색 결과에 없으면 수집, 문서 분할, 검색 조건을 살펴봅니다. 문서는 찾았지만 답이 틀리면 문맥과 생성 결과를 점검합니다.

Microsoft의 RAG 평가 가이드도 단계별 평가와 전체 결과 평가를 함께 다룹니다. PoC에서는 복잡한 지표를 모두 도입하기보다 실패를 재현하고 원인을 구분할 수 있는 기록부터 마련하세요.

각 질문에 다음 칸을 만들면 공급사와 업무 담당자가 같은 결과를 확인할 수 있습니다.

정답률을 계산하려면 통과의 의미부터 합의해야 합니다. 필수 정보를 모두 포함해야 통과인지, 일부 누락을 별도로 분류할지 정하세요. 권한 밖 정보 노출처럼 별도로 막아야 하는 실패는 평균 점수에 섞지 않는 편이 판단하기 쉽습니다.

업무에 따라 허용할 오류가 다릅니다. 초안 작성은 사람이 수정할 수 있지만, 사양 수치를 잘못 전달하는 결과는 다른 확인 절차가 필요합니다. 따라서 검색·답변·인용·권한의 기준을 업무별로 정합니다.

예시로 중요한 수치에는 정확한 단위와 원문 위치를 요구하고, 문서에 없는 질문에는 답변 보류를 요구할 수 있습니다. 특정 합격률을 모든 조직의 기준으로 제시하기보다, 오류의 영향과 검토자의 역할을 기준으로 결정하세요.

초기 문서로 한 번 성공한 뒤에도 같은 질문을 반복해 보세요. 답변 표현이 바뀌더라도 필요한 정보와 원문 연결은 유지되는지 확인합니다. 그다음 문서 수정, 삭제, 권한 변경을 각각 적용해 결과를 다시 기록하세요.

문서 갱신 점검에서는 변경 종류별 시험 순서를 다룹니다. 파일 형식과 저장소가 다양하다면 NAS 연결 준비에서 대표 문서를 선정하는 방법도 확인할 수 있습니다.

마지막에는 질문별 실패를 묶어 무엇을 수정하고 무엇을 사람의 검토로 처리할지 정합니다. 문서 품질 문제, 검색 문제, 답변 문제, 권한 문제, 운영 문제를 나누면 후속 작업의 담당자를 정하기 쉽습니다.

Wissly를 검토한다면 Enterprise 상담에 첫 업무, 대표 문서 형식, 평가할 질문과 보안 조건을 전달하세요. 도입 범위가 정해진 뒤에는 동일한 평가표를 업데이트와 운영 점검에도 재사용할 수 있습니다.