평가 체계 만들기와 성능 검증

평가 없는 파인튜닝은 방향을 잃는다

파인튜닝을 하면 모델의 말투가 좋아 보이거나 답변이 더 길어질 수 있다. 그러나 그것이 실제 성능 향상을 뜻하지는 않는다. 평가 체계가 없으면 모델이 좋아졌는지, 특정 영역만 개선되고 다른 능력은 떨어졌는지 판단할 수 없다.

따라서 파인튜닝 프로젝트에는 학습만큼 평가가 중요하다. 좋은 평가는 "모델이 그럴듯하게 말하는가"가 아니라 "우리 업무에서 쓸 수 있는 수준인가"를 묻는다. 이 질문에 답하려면 정량 평가와 정성 평가를 함께 설계해야 한다.

무엇을 평가할 것인가

평가 항목은 태스크에 맞게 정해야 한다. 일반적으로는 다음 기준을 많이 사용한다.

• 정확성: 사실, 계산, 판단이 맞는가

• 관련성: 질문이나 지시와 직접 관련된 답을 했는가

• 완전성: 필요한 조건, 예외, 단계가 빠지지 않았는가

• 형식 준수: 지정된 JSON, 표, 문체, 길이, 금지 표현을 지켰는가

• 환각률: 근거 없는 사실을 만들어내지 않았는가

예를 들어 고객 상담 모델이라면 정답만 맞히는 것으로 부족하다. 고객의 상황을 반영해야 하고, 회사 정책을 벗어나면 안 되며, 답변 형식도 일정해야 한다. 반대로 코드 생성 모델이라면 설명의 자연스러움보다 실행 가능성, 테스트 통과 여부, 보안 문제가 더 중요하다.

골든셋으로 기준선을 만든다

평가의 출발점은 골든셋이다. 골든셋은 사람이 검수한 고품질 평가 데이터다. 입력, 기대 답변, 채점 기준이 함께 들어 있어야 한다. 학습 데이터와 겹치면 안 되며, 실제 운영에서 자주 만나는 사례와 실패하면 치명적인 사례를 모두 포함해야 한다.

골든셋은 너무 클 필요가 없다. 처음에는 50~200개 정도의 대표 사례로 시작해도 충분하다. 중요한 것은 다양성이다. 쉬운 질문, 모호한 질문, 정책 경계에 있는 질문, 거절해야 하는 질문, 형식을 엄격히 지켜야 하는 질문을 섞어야 한다.

이 골든셋으로 기본 모델, 기존 모델, 새 파인튜닝 모델을 같은 조건에서 비교한다. 프롬프트, 온도, 최대 토큰 수 같은 추론 설정도 고정해야 한다. 설정이 달라지면 모델 차이인지 실행 조건 차이인지 알 수 없다.

회귀 테스트와 블라인드 평가

새 모델이 평균 점수에서 좋아졌다고 해서 바로 배포해서는 안 된다. 기존에 잘하던 일을 못하게 되는 경우가 있다. 이를 막기 위해 회귀 테스트를 둔다. 회귀 테스트는 반드시 지켜야 하는 핵심 사례 모음이다. 정책 위반, 개인정보 노출, 잘못된 거절, 형식 오류처럼 운영 리스크가 큰 항목을 포함한다.

정성 평가는 블라인드 평가로 진행하는 것이 좋다. 평가자에게 어떤 답변이 기존 모델이고 어떤 답변이 새 모델인지 알려주지 않는다. 모델 이름을 가리면 선입견을 줄일 수 있다. 가능하면 두 명 이상이 평가하고, 의견이 갈리는 항목은 기준 문서를 보며 조정한다.

범용 지표보다 태스크 지표가 중요하다

BLEU, ROUGE, perplexity 같은 지표는 참고할 수 있지만, 실무 성능을 그대로 말해주지는 않는다. BLEU와 ROUGE는 주로 정답 문장과 얼마나 비슷한지 보는 지표다. 하지만 LLM 답변은 같은 의미를 여러 방식으로 표현할 수 있다. 문장이 다르다고 틀린 답은 아니다.

perplexity는 모델이 다음 토큰을 얼마나 자연스럽게 예측하는지 보는 지표에 가깝다. 낮을수록 언어적으로 매끄러울 수 있지만, 업무 지시를 잘 따르거나 사실 오류가 적다는 뜻은 아니다.

그래서 실무에서는 태스크별 지표를 직접 설계해야 한다. 예를 들어 문서 요약은 핵심 누락률과 왜곡률을 본다. 상담 답변은 정책 준수율과 해결률을 본다. 데이터 추출은 필드별 정확도와 JSON 파싱 성공률을 본다. 모델 평가는 결국 업무 품질 평가로 바뀌어야 한다.

LLM 평가자를 쓸 때의 주의점

LLM을 평가자로 쓰면 많은 답변을 빠르게 채점할 수 있다. 하지만 그대로 믿어서는 안 된다. LLM 평가자는 표현이 긴 답변을 더 좋게 보거나, 자신과 비슷한 문체를 선호하거나, 같은 답변에도 실행할 때마다 다른 점수를 줄 수 있다.

이를 줄이려면 평가 프롬프트에 기준을 명확히 적어야 한다. "좋음/나쁨"이 아니라 1~5점 기준과 감점 조건을 써야 한다. 가능하면 점수만 내지 말고 근거도 함께 생성하게 한다. 또한 일부 샘플은 사람이 다시 검수해 LLM 평가자의 편향을 확인한다.

재현성도 관리해야 한다. 평가에 사용한 모델 버전, 프롬프트, 추론 설정, 평가 날짜, 데이터 버전을 기록한다. 같은 모델을 다시 평가했을 때 비슷한 결과가 나와야 신뢰할 수 있다.

배포 판단은 점수가 아니라 기준으로 한다

마지막 단계는 배포 기준을 정하는 일이다. 예를 들어 "형식 준수율 98% 이상, 정책 위반 0건, 기존 모델 대비 상담 해결률 5% 이상 개선, 회귀 테스트 전 항목 통과"처럼 명확해야 한다.

모든 점수가 좋아질 필요는 없다. 중요한 것은 운영 목적에 맞는 핵심 지표가 개선되고, 치명적 리스크가 통제되는 것이다. 파인튜닝 모델의 성능 검증은 한 번의 시험이 아니라 반복 과정이다. 평가 결과를 보고 실패 유형을 모으고, 데이터를 보강하고, 다시 학습한다. 이 순환이 있어야 모델은 실험 결과물이 아니라 운영 가능한 제품이 된다.