LLM 평가는 모델이나 LLM 기반 애플리케이션이 정해진 품질 기준을 얼마나 만족하는지 측정하는 과정이다. 일반적으로 테스트 케이스를 실행하고, 자동 또는 수동으로 채점하며, 시간에 따른 성능 변화를 추적한다.1
다만 평가 점수를 해석할 때 가장 먼저 기억해야 할 점이 있다. 그 점수는 모델 하나에서 곧바로 나오는 값이 아니다. 평가 하네스, 샌드박스와 하드웨어, 프롬프트, LLM, 채점기, 추론 엔진이나 API, 후처리와 집계 방식이 이어진 측정 파이프라인의 결과다.
그래서 “A 모델이 B 모델보다 높다”는 말은 실무적으로 종종 “A 모델을 포함한 측정 파이프라인이 B 파이프라인보다 높다”는 뜻에 가깝다. 모델 비교를 제대로 이해하려면 점수 자체보다 그 점수가 만들어진 경로를 함께 봐야 한다.
점수는 평가 파이프라인에서 만들어진다
평가 프레임워크는 프롬프트 전달, 출력 수집, 채점, 결과 집계를 표준화하는 구조다.2 이런 표준화가 없으면 같은 벤치마크를 사용하더라도 팀마다 다른 점수를 얻을 수 있다.
차이를 만드는 요소는 생각보다 작을 수 있다. 프롬프트 문구, few-shot 예시의 순서, 모델 호출 파라미터, 답변 추출 규칙, 공백 제거 같은 후처리만 달라져도 최종 점수는 흔들릴 수 있다. 채점 기준이나 집계 방식이 바뀌면 그 영향은 더 커진다.
따라서 평가 하네스는 단순한 래퍼나 실행 스크립트가 아니다. 모델을 공정하게 비교하고 변경의 영향을 추적하기 위해 설계, 버전 관리, 검증이 필요한 엔지니어링 대상이다.
모델 평가와 제품 평가는 구분해야 한다
모델 평가는 표준화된 과제에서 LLM의 원시 능력을 측정한다.1 반면 제품 평가는 시스템이 실제 사용자 문제를 해결하는지를 본다.1 두 평가는 모두 필요하지만, 답하려는 질문이 다르다.
예를 들어 모델 평가의 질문은 “이 모델이 특정 과제에서 얼마나 잘 답하는가?”에 가깝다. 제품 평가의 질문은 “우리 시스템이 사용자의 목표를 달성하게 했는가?”에 가깝다. RAG, 에이전트, 도구 호출, 정책 필터, UI 흐름이 포함된 서비스라면 최종 품질은 모델 성능만으로 설명되지 않는다.
따라서 벤치마크 점수를 제품 품질의 직접적인 대리 지표로 받아들이면 위험하다. 모델 자체의 능력을 보려는 평가인지, 실제 애플리케이션의 성공 여부를 보려는 평가인지 먼저 구분해야 한다.
오프라인 평가는 배포 전 변화의 영향을 본다
오프라인 평가는 배포 전에 선별된 데이터셋으로 프롬프트 변경, 모델 교체, 검색 수정의 영향을 측정한다.1 같은 테스트셋을 반복 실행할 수 있으므로 변경 전후를 비교하거나 CI에서 회귀를 잡는 데 유용하다.
하지만 오프라인 점수는 통제된 환경의 결과다. 실제 사용자는 테스트셋처럼 질문하지 않고, 운영 환경에서는 입력 분포와 장애 조건도 달라질 수 있다. 따라서 오프라인 평가는 “배포 전에 예상 가능한 문제를 줄이는 장치”로 이해하는 편이 정확하다.
즉, 오프라인 점수가 높다고 해서 실제 품질이 항상 높다고 단정할 수는 없다. 대신 변경이 품질 기준을 악화시키는지, 특정 과제에서 반복적으로 실패하는지, 이전 버전 대비 어떤 차이가 생겼는지를 확인하는 데 강점이 있다.
온라인 평가는 운영 품질을 확인한다
온라인 평가는 운영 환경의 실시간 트래픽 샘플에 대해 비동기적으로 품질 점수를 계산한다.1 실제 사용자의 입력과 실제 시스템 상태를 반영하므로 오프라인 평가가 놓치는 문제를 발견할 수 있다.
또한 온라인 평가는 품질 지표를 지연 시간, 오류율 같은 운영 지표와 함께 추적할 수 있다.1 이는 중요하다. 응답 품질이 조금 좋아졌더라도 지연 시간이 크게 늘거나 오류율이 높아진다면 제품 관점에서는 좋은 변경이 아닐 수 있기 때문이다.
실무에서는 오프라인 평가와 온라인 평가를 대체 관계로 보지 않는 편이 좋다. 오프라인 평가는 배포 전 회귀를 줄이고, 온라인 평가는 배포 후 실제 품질과 운영 영향을 확인한다.
전체 점수만 보면 원인을 놓친다
엔드투엔드 평가는 전체 시스템이 사용자의 목표를 달성했는지를 측정한다.1 사용자가 원하는 답을 얻었는지, 작업이 완료됐는지, 시스템이 최종적으로 유용했는지를 보는 데 적합하다.
반면 컴포넌트 수준 평가는 RAG 검색 품질이나 에이전트의 도구 선택 정확도처럼 시스템의 개별 구성요소를 분리해 측정한다.1 엔드투엔드 점수가 하락했을 때는 이런 컴포넌트 점수가 문제가 발생한 위치를 찾는 데 도움이 된다.1
따라서 전체 점수가 떨어졌을 때 바로 “모델이 나빠졌다”고 결론 내리면 안 된다. 검색 결과가 부정확했을 수도 있고, 프롬프트 변경이 답변 형식을 깨뜨렸을 수도 있으며, 채점기나 후처리 규칙이 바뀌었을 수도 있다. 좋은 평가는 순위표를 만드는 작업에 그치지 않고, 품질 저하의 원인을 찾는 디버깅 도구가 되어야 한다.
평가 점수를 읽는 실무 기준
LLM 평가 점수는 모델의 절대 성적표가 아니다. 데이터셋, 프롬프트, 실행 환경, 엔진/API, 채점기, 집계 방식이 합쳐져 만들어진 측정 결과다. 단일 계층의 작은 변화도 최종 점수에 영향을 줄 수 있다.
따라서 평가 결과를 비교할 때는 모델명만 보지 말고 다음을 함께 확인해야 한다.
어떤 데이터셋과 테스트 케이스를 사용했는가
프롬프트와 few-shot 예시는 동일한가
모델 호출 방식, 엔진/API, 실행 환경은 같은가
출력 정규화와 답변 추출 규칙은 어떻게 되어 있는가
채점 기준과 집계 방식은 무엇인가
오프라인 점수인지, 온라인 운영 지표와 함께 본 점수인지
엔드투엔드 평가인지, 컴포넌트 수준 평가인지
결론은 단순하다. LLM 평가를 신뢰하려면 평가 하네스를 엔지니어링 자산으로 다뤄야 한다. 평가 설정을 버전 관리하고, 오프라인·온라인 평가를 함께 운영하며, 전체 점수와 컴포넌트 점수를 나눠 보는 것이 실무적인 출발점이다.
1What is LLM evaluation? A practical guide to evals, metrics, and regression testing
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.