느낌으로 모델을 바꾸면 생기는 일

한 줄 요약

평가 하네스 없이 모델이나 프롬프트를 바꾸는 것은 테스트 없이 리팩터링하는 것과 같다. 좋아졌다는 느낌과 실제로 좋아진 것은 다르다.

왜 이게 필요했나

새 모델이 나왔습니다. 몇 개 물어보니 답이 더 낫습니다. 바꿉니다. 2주 뒤 특정 유형의 질문에서 품질이 떨어졌다는 문의가 들어옵니다. 되돌릴지 판단해야 하는데, 근거가 없습니다.

이 상황이 반복되는 이유는 LLM 출력이 결정적이지 않고 평가 기준이 주관적이기 때문입니다. 단위 테스트처럼 "정확히 이 값"을 기대할 수 없는 경우가 많습니다.

그래도 잴 수는 있습니다. 완벽하지 않아도 회귀를 잡을 만큼은 됩니다.

어떻게 동작하나

평가 하네스의 구성 요소는 넷입니다.

평가셋. 실제 트래픽에서 뽑은 대표 질문들과 기대 결과입니다. 30~100건이면 회귀 감지에 충분히 시작할 수 있습니다. 중요한 것은 실제 분포를 반영하는 것입니다 — 잘 되는 케이스만 모으면 회귀를 못 잡습니다.

채점기. 유형에 따라 다릅니다. 구조화된 출력(JSON, 분류, 추출)은 정확 일치로 잽니다. 자유 서술은 키워드 포함이나 정규식으로 부분 점수를 줍니다. 더 복잡한 것은 LLM 을 심판으로 쓰는 방법이 있지만, 심판 자체가 흔들리므로 기준 프롬프트를 고정하고 심판 모델도 버전을 고정해야 합니다.

기준선. 현재 운영 중인 조합의 점수를 저장해 둡니다. 이것 없이는 비교할 대상이 없습니다.

게이트. 새 조합의 점수가 기준선보다 일정 폭 이상 낮으면 실패로 판정합니다. 임계는 노이즈보다 커야 합니다 — 3퍼센트포인트 정도가 출발점이고, 평가셋이 작으면 더 커야 합니다.

현장에서 만나는 모습

품질만 재면 안 됩니다. 지연과 비용도 같은 하네스에서 함께 재야 합니다. 품질이 2% 좋아졌는데 지연이 두 배가 되고 비용이 세 배가 됐다면 그것은 개선이 아닙니다. 세 축을 함께 봐야 판단이 됩니다.

그리고 하네스를 CI 에 넣는 것이 결정적입니다. 프롬프트 변경 PR 에서 자동으로 돌고 회귀면 머지가 막히면, 사람이 기억할 필요가 없어집니다. 프롬프트를 코드처럼 다루는 것의 실제 의미가 이것입니다.

평가셋은 살아 있어야 합니다. 사용자 문의로 발견된 실패 케이스를 평가셋에 추가하는 루프를 만들면, 같은 실패가 두 번 나지 않습니다. 회귀 테스트의 원리와 같습니다.

다음 실습에서 할 것

평가셋을 불러 러너를 만들고, 정확 일치와 부분 점수 채점기를 각각 구현하고, 지연 SLO 위반을 세고, 기준선을 저장한 뒤 회귀를 판정하고, 마지막에 CI 게이트 스크립트로 만듭니다.