RAG 챗봇을 시연하면 대개 첫 반응은 좋습니다. 질문을 입력하자 문서에서 답을 찾아 자연스럽게 설명해 주기 때문입니다. 그런데 운영을 시작하면 평가가 엇갈립니다. 어떤 사람은 잘 된다고 하고, 어떤 사람은 못 믿겠다고 합니다.
이때 전체 답변에 점수 하나만 매기면 원인을 찾기 어렵습니다. 검색이 실패한 것인지, 문서는 찾았지만 엉뚱하게 읽은 것인지, 근거가 없는데도 답한 것인지가 모두 같은 오답으로 기록되기 때문입니다. 고칠 곳을 알려면 품질을 단계별로 나눠 봐야 합니다.
정답률 하나로는 부족하다
“100문제 중 몇 개를 맞혔나”는 최종 성과를 보여 주지만, 개선 방법까지 알려 주지는 않습니다. 예를 들어 같은 오답이라도 원인은 전혀 다를 수 있습니다.
- 필요한 문서가 저장소에 없었다.
- 문서는 있었지만 검색 결과 상위에 나오지 않았다.
- 올바른 문서를 찾았지만 답변이 조건이나 예외를 빠뜨렸다.
- 답을 알 수 없는 질문인데 그럴듯하게 만들어 냈다.
첫 번째는 문서 관리 문제이고, 두 번째는 검색 문제이며, 세 번째와 네 번째는 답변 생성 규칙의 문제입니다. 같은 모델을 바꾸는 것으로 네 가지가 모두 해결되지는 않습니다.
좋은 평가는 점수를 내는 데서 끝나지 않습니다. 점수가 낮을 때 어느 부품을 고쳐야 하는지 알려 줘야 합니다.
품질을 네 칸으로 나눠 본다
저희는 RAG를 점검할 때 결과를 다음 네 축으로 나눕니다. 각 항목은 0점 또는 1점처럼 단순하게 시작해도 충분합니다. 중요한 것은 모든 평가자가 같은 기준으로 판정할 수 있게 만드는 것입니다.
1. 검색 성공
정답에 필요한 문서 조각이 검색 결과 안에 들어왔는지를 봅니다. 답변 문장부터 읽지 말고 검색 결과를 먼저 확인해야 합니다. 필요한 근거가 없다면 이후 단계가 아무리 좋아도 맞힐 수 없습니다.
이 항목이 낮을 때는 문서 분할 크기, 제목과 본문의 결합 방식, 표와 첨부 파일의 추출 상태, 검색어 확장, 필터 조건을 살펴봅니다. 모델을 더 큰 것으로 바꾸기 전에 검색 결과부터 고치는 편이 효과적입니다.
2. 근거 충실성
답변의 핵심 주장이 검색된 문서 안에서 확인되는지를 봅니다. 출처 링크가 붙었다고 충실한 답변은 아닙니다. 링크한 문서에 실제로 그 내용이 있어야 합니다.
숫자, 날짜, 대상, 예외 조건처럼 업무 판단에 영향을 주는 표현은 특히 엄격하게 확인합니다. “신청할 수 있다”와 “특정 등급만 신청할 수 있다”는 업무상 전혀 다른 답변입니다.
3. 답변 완결성
근거는 맞지만 사용자가 필요한 내용을 빠뜨릴 수 있습니다. 환불 절차를 물었는데 가능 여부만 말하고 신청 경로나 준비 서류를 생략했다면 정확하지만 쓸모가 부족한 답변입니다.
평가표에는 질문별로 반드시 포함해야 할 핵심 항목을 두세 개 적어 둡니다. 문장 표현이 모범 답안과 달라도 핵심 항목이 들어 있으면 통과시킵니다. 이렇게 해야 특정 문구를 외우는 시스템이 아니라 실제로 도움이 되는 시스템을 평가할 수 있습니다.
4. 거절 정확성
자료에 답이 없을 때 모른다고 말하는 능력입니다. 운영에서는 이 항목이 정답률만큼 중요합니다. 확인할 수 없는 내용을 자신 있게 답하면 사용자는 이후의 올바른 답변도 믿지 않게 됩니다.
평가 질문의 일부는 의도적으로 답할 수 없게 만듭니다. 존재하지 않는 제도, 아직 확정되지 않은 일정, 권한 밖의 개인정보를 묻고 시스템이 근거 부족을 밝히는지 확인합니다. 다만 문서에 답이 있는데 무조건 거절하는 것도 실패이므로, 답해야 할 때 답하고 멈춰야 할 때 멈추는지를 함께 봐야 합니다.
평가 세트는 실제 질문으로 만든다
좋은 평가표보다 먼저 필요한 것은 좋은 질문 목록입니다. 제품 소개 문서에 있는 깔끔한 질문만 넣으면 결과가 실제보다 좋게 나옵니다. 운영 전에 다음 유형을 골고루 섞는 것이 좋습니다.
- 직접 질문: 문서 한 곳에 답이 명확하게 있는 기본 질문
- 조건 질문: 대상, 시점, 금액에 따라 답이 달라지는 질문
- 종합 질문: 두 개 이상의 문서를 함께 봐야 하는 질문
- 표현 변형: 약어, 현장 용어, 오탈자, 짧은 구어체가 섞인 질문
- 답 없음: 저장소의 문서만으로는 판단할 수 없는 질문
처음부터 수백 개를 만들 필요는 없습니다. 부서별로 자주 묻는 질문과 틀렸을 때 손실이 큰 질문을 모아 작은 평가 세트로 시작하고, 운영에서 발견된 실패 사례를 계속 추가합니다. 평가 세트는 한 번 만들고 끝나는 시험지가 아니라 장애 기록이 쌓이는 회귀 테스트에 가깝습니다.
실패를 기록할 때 원인 코드도 남긴다
점수 옆에 실패 원인을 한 칸 더 기록하면 개선 속도가 빨라집니다. 복잡한 분류 체계보다 다음 정도면 충분합니다.
MISSING_DOC— 필요한 원문이 없음RETRIEVAL— 원문은 있으나 검색하지 못함WRONG_EVIDENCE— 관련은 있지만 답이 아닌 근거를 선택함GENERATION— 근거는 맞지만 답변이 왜곡되거나 누락됨REFUSAL— 답할 수 없는데 답했거나, 답할 수 있는데 거절함
오답 20개 중 15개가 검색 문제라면 프롬프트를 바꾸는 작업은 우선순위가 아닙니다. 반대로 검색은 거의 성공하지만 예외 조건을 계속 빠뜨린다면 답변 지시문과 출력 형식을 손봐야 합니다. 원인 코드가 투자할 곳을 정해 줍니다.
평균 점수보다 위험 질문을 먼저 본다
전체 평균이 높아도 중요한 질문 하나가 계속 틀리면 배포하기 어렵습니다. 인사 규정, 계약 조건, 안전 절차처럼 잘못 답했을 때 영향이 큰 질문은 별도 그룹으로 관리해야 합니다.
그래서 배포 기준도 두 줄로 두는 편이 안전합니다. 하나는 전체 평가 세트의 통과율이고, 다른 하나는 위험 질문 그룹의 필수 통과 조건입니다. 평균이 좋아졌다는 이유로 치명적인 오답을 가리지 않게 됩니다.
변경할 때마다 같은 시험을 다시 돌린다
RAG는 한 부분을 개선하면 다른 부분이 나빠질 수 있습니다. 검색 결과를 많이 넣으면 필요한 근거를 찾을 가능성은 커지지만 관련 없는 문맥도 늘어납니다. 답변을 짧게 제한하면 읽기는 쉬워지지만 예외 조건을 놓칠 수 있습니다.
모델, 프롬프트, 문서 분할, 검색 방식 중 하나를 바꿀 때마다 같은 평가 세트를 다시 실행하고 네 항목을 비교합니다. 전체 점수만 보지 말고 어떤 유형이 좋아지고 나빠졌는지 확인해야 합니다. 이 기록이 있어야 “새 버전이 느낌상 낫다”가 아니라 배포 가능한 판단이 됩니다.
정리
RAG 품질을 높이는 첫 단계는 더 좋은 모델을 고르는 일이 아니라 실패를 분리해서 볼 수 있는 평가 체계를 만드는 일입니다.
- 실제 업무 질문과 답 없는 질문을 함께 모읍니다.
- 검색 성공, 근거 충실성, 답변 완결성, 거절 정확성을 따로 판정합니다.
- 오답에는 원인 코드를 붙여 고칠 부품을 찾습니다.
- 위험 질문은 평균과 별도의 배포 기준으로 관리합니다.
- 시스템을 바꿀 때마다 같은 평가를 반복합니다.
이 다섯 가지가 갖춰지면 RAG 개선은 감상평에서 엔지니어링으로 바뀝니다. 무엇이 나아졌고, 무엇이 여전히 위험하며, 다음 작업을 어디에 집중해야 하는지 설명할 수 있게 됩니다.
