LLM Evals

LLM 앱은 같은 요청에도 결과가 조금씩 흔들릴 수 있고, 한두 개 예시가 잘 되더라도 실제 운영 데이터에서는 전혀 다른 실패가 나올 수 있습니다. 수동 확인만으로 품질을 판단하면, 평균적으로는 좋아 보여도 특정 사용자군이나 특정 문서군에서 크게 망가지는 회귀를 놓치기 쉽습니다.

초기에는 '몇 개 질문 던져 보고 괜찮으면 배포'하는 방식이 많았습니다. 하지만 프롬프트 수정, 모델 교체, RAG 튜닝이 잦아지면서 회귀를 막을 공통 기준이 필요해졌고, LLM용 eval이 소프트웨어 테스트의 빈자리를 채우기 시작했습니다.

보통은 대표 질문 세트와 기대 기준을 먼저 정의합니다. 그다음 후보 시스템의 결과를 모아 exact match, 규칙 검사, model judge(모델이 채점자 역할을 맡는 방식), 사람 라벨 같은 방법으로 채점하고, 전체 점수뿐 아니라 어떤 slice(특정 질문군)에서 깨졌는지 분석합니다. 중요한 것은 화려한 단일 점수가 아니라 실제 운영 실패 유형을 얼마나 잘 반영한 셋을 만들었느냐입니다.

evals, observability, guardrails는 모두 실패를 다루지만 시점이 다릅니다. 배포 전에 변경 전후를 비교하려면 evals를 보고, 운영 중 왜 실패했는지를 보려면 observability를 보고, 런타임에서 바로 막아야 하면 guardrails를 봐야 합니다. eval 점수가 좋아도 운영 데이터가 바뀌면 새 실패가 생길 수 있다는 점이 한계입니다.

실무에서는 프롬프트 수정, retrieval 변경, 모델 라우팅, 안전 정책 변경 전에 최소한의 회귀 셋을 돌립니다. 이때 평균 점수 하나보다 '어떤 질문군(slice)에서 특히 무너지는가'를 보는 편이 더 실용적입니다. 운영에서 발견한 나쁜 사례를 계속 eval 셋으로 편입해야 테스트가 살아 있는 자산이 됩니다.