AI 평가

AI 모델이나 서비스를 미리 만든 시험지로 채점해 '좋아진 것 같다'는 느낌을 숫자로 바꾸는 작업이다. 프롬프트나 모델을 바꿀 때마다 같은 시험지를 다시 돌려 어디서 점수가 오르고 떨어졌는지 확인한다. 테스트 코드와 역할은 같지만, 같은 입력에도 출력이 달라지고 정답이 하나가 아닐 때가 많아 더 까다롭다.

채점 기준은 잘게 쪼갤수록 안정된다

LLM 심판(LLM-as-a-Judge)은 다른 LLM에게 채점 기준(루브릭)을 주고 점수를 매기게 하는 방식이다. '근거 문서에 뒷받침되는가', '질문에 실제로 답했는가', '금지된 표현을 썼는가'처럼 항목을 잘게 나눌수록 점수가 안정되고, '전반적으로 좋은가'처럼 뭉뚱그리면 점수가 널뛴다.

RAG라면 검색이 맞는 문서를 가져왔는지와, 그 문서로 맞는 답을 썼는지를 따로 잰다. 둘을 나눠야 어디를 고칠지 보인다.

심판도 편향이 있다

LLM 심판은 몇 가지 버릇이 있어서 점수를 그대로 믿으면 안 된다. 먼저 사람이 매긴 라벨 수십~수백 개와 대조해 얼마나 일치하는지 확인한 뒤에 쓴다.

작게 시작해 실패 사례로 키운다

평가가 가장 빛나는 순간은 회귀를 잡을 때다. 전체 점수는 올랐는데 특정 유형의 질문만 떨어지는 일이 흔하고, 평가가 없으면 이걸 사용자 항의로 알게 된다. 처음엔 실제 사용 사례에서 뽑은 수십 개 케이스로 시작하고, 운영 중 실패한 사례를 계속 시험지에 추가하면 같은 사고가 조용히 재발하지 않는다.

DeepEval, Langfuse, LangSmith 같은 도구로 평가를 CI/CD에 넣으면, 프롬프트를 바꿀 때마다 평가가 자동으로 돌고 점수가 기준 아래면 배포가 막힌다. 시험지 점수가 오른 뒤에는 일부 사용자에게만 새 버전을 내보내는 A/B 테스트와 피드백 수집으로 실제 반응까지 확인한다.

공개 벤치마크보다 내 데이터

공개 벤치마크 1등 모델이 내 서비스의 한국어 고객 문의에서도 1등이라는 보장은 없다. 유명 벤치마크는 문제가 학습 데이터에 섞여 점수가 부풀려지는 경우도 있다. 내 서비스 데이터로 만든 평가 세트가 진짜 자산이다.

무언가 바꾸기 전에 먼저 돌린다

가장 흔한 건 변경 전후 비교다. 프롬프트를 고치거나 모델을 갈아타기 전에 같은 평가 세트를 돌려서, 바꿔도 되는지를 감이 아니라 점수로 정한다.