LLM 답변 품질 평가 방법, katsubee 골든셋 43케이스 운영 기록과 한계

• katsubee는 골든셋 회귀 eval, 정기 eval, 일반 질의 수집 세 가지 경로로 답변 품질을 점검합니다.
• 골든셋은 43케이스이며, 규칙 검사와 LLM 판정 점수를 모두 넘어야 통과로 처리합니다.
• 채팅 모델이 판정도 맡기 때문에 절대 점수보다 기준선 대비 변화를 보고, 프롬프트로 품질을 올리려는 시도 두 번은 효과를 입증하지 못했습니다.

katsubee·katsubox 소개 글부터 이어 온 개선 시리즈의 여섯 번째 글입니다. 앞의 글들은 검색 품질이 주제였고, 이번에는 답변 자체의 품질을 어떤 절차로 확인하는지, 그 절차가 어느 지점에서 막히는지를 적습니다.

변경 전후를 같은 질문으로 비교해야 하는 이유

로컬 모델을 교체하거나 시스템 프롬프트를 손볼 때마다 답변은 달라질 수 있습니다. 몇 개 질문을 눈으로 확인하는 정도로는 어느 질문에서 품질이 떨어졌는지 놓치기 쉽습니다.

그래서 변경 전과 후에 같은 질문 묶음을 돌려 결과를 견주는 회귀 eval을 만들었습니다. 이 eval은 실제 채팅 API를 호출합니다. GPU를 쓰는 작업이라 CI에는 넣지 않았고, 운영 호스트나 Ollama가 연결된 스택에서 직접 실행합니다.

시간도 꽤 듭니다. 36케이스를 3회씩 돌리면 격리 스택 기준으로 약 31분이 걸립니다.

골든셋 구성과 43케이스까지 늘어난 과정

골든셋의 케이스는 일반, 시사, RAG, 첨부, 도구, 다턴, 형식, 모름·거절, 오작동 회귀, 검색 카테고리로 나뉩니다. 9월 23일에 21개로 출발해 9월 27일에 36개가 되었고, 10월 21일 기준으로 43개입니다.

늘리는 원칙은 단순합니다. 버그를 고칠 때마다 재발을 막는 케이스를 하나씩 추가하고, 그 케이스에는 근거가 된 티켓 번호를 함께 남깁니다.

RAG 케이스는 평가 전용 계정으로 실행

RAG 케이스 7개는 평가 전용 계정에서 돌아갑니다. 실행할 때마다 임시 프로젝트를 만들고, 가상 문서 세 개를 올립니다. 현행 안내서, 폐지된 2024년판, IT FAQ입니다.

번호가 헷갈리거나 낡은 규정이 섞여 있는 문서를 대상으로 검색 정밀도를 확인하는 구성입니다. 실행이 끝나면 대화와 프로젝트를 모두 지웁니다.

통과 기준은 규칙 검사와 판정 점수의 이중 조건

먼저 규칙 검사가 있습니다. 이 단계는 결정적으로 동작하며 다음 항목을 확인합니다.

• 도구 호출 JSON이나 추론 마커가 답변에 그대로 노출되는지
• 코드 블록 안에 한글이 섞여 글자가 깨지는지
• 본문의 한글 비율
• 케이스별로 반드시 들어가야 하거나 없어야 하는 문구
• 출처 칩에 근거 문서가 들어 있는지

그 위에 LLM 판정이 얹힙니다. gemma4:26b가 루브릭에 따라 정확성, 근거, 지시 준수, 종합 네 항목을 1점부터 5점까지 매깁니다.

케이스가 통과하려면 규칙 검사를 전부 넘기고, 종합 점수가 3 이상이며, 정확성과 근거도 각각 3 이상이어야 합니다. 기준별 조건을 따로 둔 이유는 종합 점수만 후하게 나오는 경우를 걸러 내기 위해서입니다.

정기 eval과 일반 질의 수집으로 보완

골든셋은 사람이 만든 고정 질문 모음이어서 새로운 유형의 실패는 찾지 못합니다. 이를 보완하려고 두 가지 작업을 더 돌립니다.

하나는 수요일 05:10에 골든셋을 정기 실행해 추이를 쌓는 작업입니다. 회귀나 오류가 나오면 macOS 알림이 뜹니다. 다른 하나는 매일 새벽 04:00에 코딩, 상식, 뉴스, 번역, 검색 5개 카테고리에서 LLM이 새 질문을 만들어 실제 채팅으로 보내는 작업입니다. 답변과 출처, 지연 시간, 자동 검사 결과가 기록으로 남습니다.

정기 eval 결과

10월 14일에는 40/42로 평균 4.86이었고, 10월 21일에는 41/43으로 평균 4.98이었습니다. 실패한 케이스는 날마다 달랐습니다. 14일에는 환율과 국제 이슈 케이스가, 21일에는 날씨 근거와 정치 뉴스 케이스가 걸렸습니다.

일반 질의 수집 결과

일반 질의는 10월 12일부터 25일까지 195건이 쌓였습니다. 카테고리당 39건이고 오류는 0건입니다. 자동 플래그는 6건이었으며 전부 웹 출처가 없다는 항목이었습니다. 내역은 뉴스 5건, 검색 1건입니다. 최신 정보를 가져오는 경로가 약하다는 신호로 읽힙니다.

프롬프트 보정 시도, 두 번 모두 효과 없음

수집한 질문 가운데 점수가 낮았던 뉴스·검색 6건을 골든셋에 넣었습니다. 그리고 근거가 불분명하면 단정하지 말라는 내용의 시스템 프롬프트를 운영에 반영했습니다.

6건을 3회씩 돌려 비교했더니 통과는 2/6으로, 프롬프트를 넣기 전과 같았습니다. 규칙 4개를 더 붙인 버전도 2/6이어서 반영하지 않았습니다.

방문객 SSID 케이스

방문객 SSID를 비밀번호처럼 답하는 RAG 케이스에서도 결과는 비슷했습니다. 운영 jar로 12회 돌렸을 때 6회가 통과했습니다. 지식 머리말에 값이 없으면 없다고 답하라는 문구를 넣은 두 버전은 각각 0/12와 4/12가 나와 기준선을 넘지 못했고, 둘 다 되돌렸습니다. 프롬프트 문구만으로는 gemma4가 출처에 없는 내용을 단정하는 빈도가 줄지 않았습니다.

이 케이스는 불안정 케이스로 표시해서 회귀 비교 대상에서 뺐습니다. 배포를 막지는 않고 리포트에 경고로만 남습니다. 약 50% 확률로 SSID를 비밀번호라고 답하는 문제는 그대로 남아 있습니다. 게이트가 더는 이 문제를 잡지 못한다는 사실도 숨기지 않고 기록해 두었습니다.

측정 방법이 가진 한계

가장 큰 한계는 채팅 모델과 판정 모델이 같다는 점입니다. 호스트에 올려 둔 범용 모델이 gemma4 하나뿐이고, 두 번째 모델을 올리면 스왑 한도를 넘습니다. 자기 평가 편향이 생길 수 있으므로 절대 점수는 믿지 않고 기준선 대비 변화를 봅니다.

판정자가 출처의 제목만 본다는 약점도 있습니다. 본문에 실제로 있던 수치를 지어낸 것으로 오판할 수 있습니다.

답변이 매번 달라지는 것도 문제입니다. 한 번만 돌리면 가끔 실패하는 케이스가 오탐 회귀로 잡힙니다. 그래서 기준선과 판정용 실행은 3회 반복하고, 과반이 통과하면 통과로 처리하며, 점수는 중앙값을 씁니다. 다만 반복 시도가 같은 문맥에서 연달아 나가기 때문에 서로 독립이 아닐 수 있다는 점도 함께 기록해 두었습니다.

다음에 손볼 부분

우선순위는 두 가지입니다. 첫째, 판정자에게 검색 스니펫을 함께 넘겨서 본문에 있는 수치를 지어낸 것으로 오판하는 일을 줄입니다.

둘째는 프롬프트 대신 코드로 막는 방법입니다. 답변에 나온 숫자가 도구 결과 본문에 있는지 검사하고, 없으면 재생성하거나 경고를 띄우는 가드를 검토할 예정입니다.