katsubee 답변 품질 측정, 골든셋과 한계

• katsubee는 답변 품질을 골든셋 회귀 eval, 정기 eval, 일반 질의 수집 세 갈래로 잰다.
• 골든셋은 43케이스이고, 통과는 규칙 검사와 LLM 판정 점수를 모두 넘어야 한다.
• 채팅 모델이 판정도 맡아서 절대 점수보다 기준선 대비 변화를 보고, 프롬프트로 품질을 올리려던 시도는 두 번 모두 효과가 입증되지 않았다.

이 글은 katsubee·katsubox 소개 글에서 이어지는 개선 시리즈의 여섯 번째 글이다. 앞선 글들이 검색 품질을 다뤘다면, 이번에는 답변 자체의 품질을 어떻게 재고 있고 그 방법이 어디서 한계에 부딪히는지 정리한다.

모델이나 프롬프트를 바꿀 때 무엇이 나빠졌는지 알아야 한다

로컬 모델은 바꾸거나 시스템 프롬프트를 고칠 때마다 답이 달라질 수 있다. 눈으로 몇 개 확인하는 것으로는 어떤 질문에서 나빠졌는지 놓치기 쉽다. 그래서 변경 전후에 같은 질문 묶음을 돌려 비교하는 회귀 eval을 만들었다.
실제 채팅 API를 호출하는 방식이라 GPU를 쓴다. 이 때문에 CI에는 넣지 않고 운영 호스트나 Ollama가 붙은 스택에서 돌린다. 36케이스를 3회씩 돌리면 격리 스택에서 약 31분이 걸린다.

골든셋은 43케이스까지 늘었다

케이스는 일반, 시사, RAG, 첨부, 도구, 다턴, 형식, 모름·거절, 오작동 회귀, 검색 카테고리로 나뉜다. 9월 23일 21개로 시작해 9월 27일 36개, 10월 21일 43개가 됐다. 버그를 고칠 때마다 재발 방지 케이스를 하나씩 넣었고, 케이스에는 근거가 된 티켓 번호를 남긴다.

RAG 케이스 7개는 평가 전용 계정으로 돈다. 실행할 때마다 임시 프로젝트를 만들어 가상 문서 3개(현행 안내서, 폐지된 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를 비밀번호처럼 답하는 RAG 케이스도 같았다. 운영 jar로 12회 돌리자 6회 통과였고, 지식 머리말에 값이 없으면 없다고 답하라는 문구를 넣은 두 버전은 0/12와 4/12여서 기준선을 넘지 못해 되돌렸다. 프롬프트 문구만으로는 gemma4의 출처 밖 단정이 줄지 않았다.

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

측정 방법의 한계

가장 큰 한계는 채팅 모델과 판정 모델이 같다는 점이다. 호스트에 범용 모델이 gemma4 하나뿐이고 두 번째 모델을 올리면 스왑 한도를 넘는다. 자기 평가 편향이 있으니 절대 점수보다 기준선 대비 변화를 본다. 판정자는 출처 제목만 보기 때문에 본문에 실제로 있던 수치를 지어낸 것으로 오판할 수 있다.
답변이 매번 달라지는 문제도 있다. 한 번 돌리면 가끔 실패하는 케이스가 오탐 회귀를 만든다. 그래서 기준선과 판정용 실행은 3회 반복해 과반이 통과하면 통과로 치고 점수는 중앙값을 쓴다. 반복 시도가 같은 문맥으로 연달아 가서 독립이 아닐 수 있다는 점도 기록돼 있다.

다음 개선

우선순위는 두 가지다. 먼저 판정자에게 검색 스니펫을 함께 넘겨서 본문에 있는 수치를 지어낸 것으로 오판하지 않게 한다. 다음으로 프롬프트가 아니라 코드로 막는 방법을 본다. 답변 속 숫자가 도구 결과 본문에 있는지 검사해 없으면 재생성하거나 경고하는 가드다.