평가 — 체감이 아니라 숫자로 판단하기

한 줄 요약

LLM 애플리케이션의 개선은 평가 집합 없이는 판단할 수 없고, 환각은 없앨 수 있는 버그가 아니라 관리해야 하는 위험이다.

왜 이게 필요했나

프롬프트를 고쳤더니 좋아진 것 같다. 정말 그런가. 열 번 돌려 보고 판단한다면 그것은 표본 열 개짜리 실험이고, 고친 프롬프트가 다른 유형의 입력을 망가뜨렸는지는 알 수 없다.

전통적인 소프트웨어에는 테스트가 있었다. 입력에 대한 기대 출력이 정해져 있으니 같은지 비교하면 된다. LLM 은 출력이 매번 조금씩 다르고 "맞다"의 기준도 하나가 아니다. 그래서 평가 방법 자체를 설계해야 한다.

어떻게 동작하나

평가는 세 층으로 나눠 생각하면 정리된다.

1층. 결정적으로 검사할 수 있는 것. 출력이 유효한 JSON 인가, 필수 필드가 있는가, 숫자 범위를 지키는가, 금지어가 들어갔는가. 이런 검사는 값싸고 확실하므로 가장 먼저 자동화한다. 형식 오류의 상당 부분이 여기서 잡힌다.

2층. 정답이 있는 것. 분류나 추출처럼 기대 출력이 정해진 과제는 정확도와 F1 으로 잴 수 있다. RAG 의 검색 단계도 여기 속한다. 정답 문서 목록만 있으면 Recall@K 와 MRR 이 나온다. 가장 값싸게 개선 여지를 찾을 수 있는 층이 여기다.

3층. 판단이 필요한 것. 답변이 충실한가, 도움이 되는가, 어조가 적절한가. 사람이 평가하는 것이 기준이지만 비싸고 느리므로 모델을 판정자로 쓰는 방법이 널리 쓰인다. 주의할 점이 있다. 모델 판정은 길이가 긴 답변을 선호하는 편향이 있고, 자기 자신이 만든 답에 후한 경향도 보고된다. 그래서 사람 평가와 상관관계를 한 번은 확인하고, 판정 기준을 구체적인 체크리스트로 쪼개는 편이 안정적이다.

환각은 두 종류로 나누면 대응이 갈린다.

• 외재적 환각 — 컨텍스트에 없는 내용을 지어냈다. 충실도 검사로 잡을 수 있고, 근거 문장을 표시하게 하거나 임계값 미만이면 거절하게 해서 줄인다.
• 내재적 환각 — 컨텍스트에 있는 내용을 잘못 요약하거나 뒤집었다. 이쪽이 더 위험하다. 출처가 붙어 있어 오히려 신뢰를 얻기 때문이다.

현장에서 만나는 모습

평가 집합은 완벽할 필요가 없다. 50개짜리라도 있는 것이 없는 것보다 훨씬 낫다. 실제 사용자 질문 중 실패한 것들을 모아 두는 것에서 시작하면 된다. 그리고 사고가 날 때마다 그 케이스를 평가 집합에 추가하면, 시간이 지날수록 회귀 테스트로서의 가치가 커진다.

비용도 관리 대상이다. 평가를 매 커밋마다 전부 돌리면 비싸므로, 값싼 1층 검사는 항상 돌리고 비싼 3층 평가는 배포 전에만 돌리는 식으로 나눈다.

마지막으로 온도 설정을 짚어 둘 만하다. 평가할 때는 온도를 낮춰 변동을 줄이는 편이 비교에 유리하다. 다만 운영 설정과 다르다면 그 차이를 감안해야 하고, 운영에서 온도가 높다면 여러 번 돌려 분산까지 보는 편이 정확하다.

이어지는 퀴즈에서 확인할 것

무엇을 어떤 층에서 재야 하는지, 모델 판정의 편향을 어떻게 다뤄야 하는지 판단할 수 있는지 확인한다.