Evals 프레임워크를 사용하여 LLM 응답 품질을 측정하는 방법

LLM 응답 품질을 측정하는 가장 신뢰할 수 있는 방법은 평가를 단일 점수가 아닌 반복 가능한 테스트 시스템으로 취급하는 것입니다. 애플리케이션에 맞는 "좋은" 응답의 의미를 정의하고, 대표적인 평가 데이터 세트를 구축하고, 확정적 검사와 모델 기반 및 사람의 판단을 결합하고, 모든 후보 변경 사항을 기준선과 비교하고, 배포 전에 범주별로 실패 사례를 검사하십시오.

이는 LLM이 겉보기에는 그럴듯해 보이지만 실제로는 잘못되었거나, 근거가 부족하거나, 불완전하거나, 안전하지 않거나, 지침과 일치하지 않는 답변을 내놓을 수 있기 때문에 중요합니다. 유용한 평가 프레임워크는 이러한 모호한 문제점들을 명확한 기준으로 전환하여 신속한 변경, 모델 업그레이드, 검색 방식 변경, 도구 업데이트 또는 안전 정책 개정 후에도 다시 실행할 수 있도록 합니다.

참고: 아래에 설명된 프레임워크 기능은 2026년 9월 13일 기준 공식 문서를 바탕으로 검증되었습니다. 이러한 도구는 빠르게 발전하므로 프레임워크 관련 코드를 프로덕션 환경에 배포하기 전에 최신 API를 확인하십시오.

무엇을 먼저 측정해야 할까요?

사용자에게 가장 중요한 실패 요인부터 시작하세요. 사실 기반 지원 봇의 경우 정확성과 정책 준수가 가장 중요할 수 있습니다. 검색 증강 생성(RAG)의 경우, 유창한 답변이라도 검색된 맥락에 의해 뒷받침되지 않는 사실을 만들어낼 수 있으므로 근거와 검색 품질이 중요합니다. 에이전트의 경우 최종 답변 품질만으로는 충분하지 않습니다. 도구 선택, 도구 인수, 작업 완료 및 불필요한 단계도 평가에 포함해야 할 수 있습니다.

이러한 요소들을 너무 일찍 하나의 수치로 평균화하지 마십시오. 스타일 면에서 2점을 얻더라도 심각한 정책 오류가 조금이라도 발생하는 후보 모델은 오히려 더 나쁜 릴리스가 될 수 있습니다. 중요한 요소들은 각각 별도의 게이트로 관리하십시오.

다양한 프레임워크에서 사용 가능한 4단계 평가 워크플로

1. 대표적인 평가 데이터셋 구축

데이터 세트에는 현실적인 입력값과 가능한 경우 예상되는 동작이 포함되어야 합니다. 일부 행에는 정확한 참조 답안이 있을 수 있지만, 다른 행에는 단일 "정답" 문장보다는 평가 기준표가 필요할 수 있습니다. 작업 유형, 고객 세그먼트, 언어, 난이도, 검색 조건 또는 안전 범주와 같은 메타데이터를 추가하여 나중에 결과를 분류할 수 있도록 하세요.

예를 들어 고객 지원 담당자를 생각해 보세요. 유용한 평가 세트에는 쉬운 FAQ 질문만 포함되어서는 안 됩니다. 모호한 요청, 정책 예외, 맥락이 부족한 경우, 적대적인 질문, 여러 차례에 걸친 후속 질문, 그리고 답변을 알 수 없다고 말하는 것이 올바른 경우 등도 포함되어야 합니다.

LangSmith의 현재 평가 지침에서는 정상적인 동작 방식을 보여주는 수동으로 선별된 예제 데이터셋부터 시작하여, 실제 운영 환경에서 발견된 과거 추적 데이터와 오류 데이터를 추가하여 데이터셋을 확장하는 것을 권장합니다. LangSmith 평가 시스템은 입력 데이터셋, 선택적 참조 출력 데이터셋, 그리고 메타데이터를 지원합니다. 자세한 내용은 LangSmith 평가 개념 문서를 참조하십시오 .

이 접근 방식이 적합한 경우는 거의 항상입니다. 실제 운영 환경에서 평가를 진행하더라도 회귀 테스트를 위해 안정적인 오프라인 데이터 세트가 필요합니다. 개방형 질문에 대한 기준 답안이 없는 경우, 평가 기준표, 필수 정보, 금지된 행동 또는 쌍별 선호도를 저장하는 것이 좋습니다.

2. 각 품질 차원에 적합한 평가자를 배정하십시오.

가장 효과적인 평가 시스템은 다양한 유형의 평가자를 혼합하여 구성하는데, 이는 모든 문제에 이상적인 평가자는 한 명도 없기 때문입니다.

• 확정적 검사는 요구 사항이 명확할 때 가장 효과적입니다. 예를 들어 유효한 JSON, 정확한 레이블, 필수 키, 숫자 허용 오차, 정규 표현식 규칙 또는 도구 호출에 승인된 인수가 사용되었는지 여부 등이 있습니다.
• 참조 기반 측정 방식은 알려진 답이 있을 때 도움이 될 수 있지만, 문자열 유사성만으로는 유효한 의역을 판별하기에는 너무 취약하고 어휘는 같지만 의미적으로 틀린 텍스트를 너무 쉽게 간과하는 경향이 있습니다.
• LLM을 심사위원으로 활용하는 것은 완성도, 관련성, 어조, 충실도 또는 개방형 답변이 평가 기준을 충족하는지 여부와 같은 기준을 평가하는 데 유용합니다.
• 쌍대 평가는 의미 있는 절대 점수를 부여하는 것보다 후보 A와 기준 B 중 어느 쪽이 더 나은지 결정하는 것이 더 쉬울 때 유용합니다.
• 자동 채점 시스템의 정확도를 높이고, 주관적이거나 중대한 사안을 해결하며, 평가 지표 자체가 사용자 가치를 제대로 반영하는지 확인하는 데 있어 인간의 검토는 여전히 중요합니다.

OpenAI의 현재 Evals API는 평가를 테스트 기준과 데이터 소스 스키마로 정의하며 재사용 가능한 채점기를 지원합니다. 채점기 API에는 결정론적 문자열 검사, 텍스트 유사성 채점기, 모델 기반 채점기가 포함되어 있습니다. 자세한 내용은 OpenAI Evals API 참조 및 OpenAI 채점기 참조를 확인하세요 . Google Cloud의 Vertex AI Gen AI 평가 서비스는 개별 및 쌍별 모델 기반 지표뿐만 아니라 계산 기반 지표도 지원합니다. 결과에는 인스턴스별 점수, 설명, 평균, 표준 편차, 쌍별 승률이 포함될 수 있습니다. Vertex AI 평가 결과 문서를 참조하세요 .

이 접근 방식이 적합한 경우는 다음과 같습니다. 기계 검증이 가능한 요구사항에는 결정론적 검사를 사용하고, 의미론적 품질에는 LLM 평가자를 활용하며, 의견 불일치가 비즈니스 또는 안전에 중대한 영향을 미치는 경우에는 사람의 의견을 활용합니다. RAG 시스템의 경우, Ragas는 컨텍스트 정밀도, 컨텍스트 재현율, 응답 관련성, 충실도와 같은 지표와 도구 호출 정확도 및 에이전트 목표 정확도를 포함한 에이전트/도구 사용 지표를 제공합니다. Ragas 지표 문서를 참조하십시오. DeepEval 또한 G-Eval 스타일 점수 계산을 포함하여 작업별 지표와 사용자 지정 LLM 평가자 평가를 제공합니다. DeepEval 지표 문서를 참조하십시오 .

3. 동일한 데이터셋을 사용하여 기준 모델과 후보 모델을 비교 분석합니다.

절대 점수도 유용하지만, 일반적으로 새 구성을 기존에 신뢰하는 버전과 비교하여 테스트할 때 릴리스 결정이 더 명확해집니다. 데이터 세트, 평가자 정의, 모델 매개변수 및 샘플링 설정을 최대한 안정적으로 유지한 다음 동일한 예제를 나란히 비교하십시오.

최소 세 단계의 결과를 추적하세요:

• 개별 사례별 점수: 어떤 프롬프트에서 점수가 향상되거나 하락했습니까?
• 슬라이스별 결과: 긴 문맥 질문, 특정 언어, 어려운 사례, 제품 범주 또는 적대적 입력에 따라 성능이 달라졌습니까?
• 종합 결과: 합격률, 평균 점수, 지연 시간, 토큰 사용량, 비용 및 심각한 실패 횟수는 어떻게 되었습니까?

비결정적 시스템의 경우, 한 번의 테스트 완료 결과가 모델을 대표한다고 가정하기보다는 변동성을 이해하기 위해 중요한 테스트를 충분히 반복 실행해야 합니다. 출시 결정이 중요한 경우, 평균값의 미미한 변화에만 의존하지 말고 동일한 예제에 대해 쌍대 비교를 수행하고 불확실성을 보고해야 합니다.

LangSmith는 버전 비교 및 ​​쌍별 평가자 비교를 위한 오프라인 실험을 지원하며, MLflow의 최신 GenAI 평가 스택은 평가 데이터 세트, 내장 및 사용자 지정 스코어러, LLM 심사자, 사람 피드백, 추적 및 프로덕션 모니터링을 지원합니다. LangSmith 평가 및 MLflow LLM 및 에이전트 평가를 참조하십시오 .

이 접근 방식은 모델, 시스템 프롬프트, 검색 파이프라인, 도구 구현 또는 디코딩 설정을 변경할 때마다 적용할 수 있습니다. 후보 항목은 단순히 하나의 집계 지표가 상승했다는 이유만으로 승격되어서는 안 되며, 주요 차원에서 릴리스 임계값을 충족하고 허용할 수 없는 슬라이스 수준의 회귀를 피해야 합니다.

4. 실패 사례를 분석하고, 평가 기준을 조정하며, 회귀 분석을 새로운 테스트로 전환하십시오.

평가 실행은 다음 단계에 변화를 줄 때만 가치가 있습니다. 실패를 심각도와 근본 원인별로 분류하세요. 근거도 점수가 낮은 이유는 정보 검색 능력 부족, 추측을 유도하는 질문, 너무 모호한 평가 기준표, 또는 잘못된 참고 답안 때문일 수 있습니다. 모델을 변경하기 전에 기본 예시들을 살펴보세요.

그런 다음 중요한 오류를 영구적인 회귀 테스트 사례로 승격시키십시오. 이렇게 하면 선순환 구조가 만들어집니다. 프로덕션 환경에서 오류가 발견되면 사람이 이를 확인하고, 해당 사례는 오프라인 데이터 세트에 추가되고, 수정 사항은 전체 테스트 스위트를 대상으로 테스트되며, 향후 릴리스에서는 동일한 문제가 다시 발생하지 않도록 차단됩니다.

LLM 심사자 또한 평가가 필요합니다. Google 문서에서는 심사자가 특정 사용 사례에 적합한지 평가하기 위해 모델 기반 측정 결과와 사람의 평가를 비교하는 방법을 명시적으로 설명합니다. OpenAI의 GDPval 작업 역시 전문가 쌍대 평가를 주요 기준으로 사용하며, 자동 평가는 전문가 판단을 대체하는 것이 아니라 근사치로 간주한다고 설명합니다. 심사자 모델 평가에 대한 Vertex AI 가이드라인 과 OpenAI의 GDPval 방법론을 참조하십시오 .

이 접근 방식이 적합한 경우는 중대한 오류의 경우와 LLM 심사자가 릴리스 게이트에 영향을 미치는 경우입니다. 사람이 직접 검토하여 심사자의 의견에 반복적으로 동의하지 않는 경우, 평가 기준을 수정하거나, 더 명확한 참조 자료를 제공하거나, 심사자 모델을 변경하거나, 해당 기준을 다시 사람 검토 단계로 옮기십시오.

LLM 판사의 자격은 얼마나 신뢰할 만할까요?

LLM 평가자는 인간 단독 검토로는 따라잡을 수 없는 규모의 개방형 출력물을 평가할 수 있기 때문에 강력한 도구입니다. G-Eval의 초기 연구에서는 연구 대상 요약 설정에서 기존 자동 평가 방식보다 인간 판단과의 상관관계가 훨씬 더 높다고 보고했습니다. 그러나 같은 논문에서 LLM 평가자가 LLM이 생성한 텍스트를 선호할 수 있다는 점도 경고했습니다. 자세한 내용은 G-Eval 원문을 참조하십시오 .

MT-Bench와 Chatbot Arena에서 진행된 별도의 연구에 따르면, 뛰어난 LLM 심사자는 인간의 선호도와 잘 부합하는 동시에 입장 편향, 장황함 편향, 자기 과시 편향, 추론 관련 편향까지 파악할 수 있는 것으로 나타났습니다. LLM을 심사자로 활용한 원본 연구를 참조하십시오 .

실질적인 결론은 "LLM 심사자를 절대 사용하지 말라"가 아닙니다. 오히려 심사자를 보정해야 한다는 것입니다. 사람이 직접 라벨링한 샘플을 구축하고, 일치도를 측정하고, 불일치 범주를 검토하고, 위치 효과가 있을 가능성이 있는 경우 쌍별 테스트에서 답변 순서를 무작위화하거나 교환하고, 모호한 심사자 안내가 모든 릴리스 결정을 묵묵히 좌우하지 않도록 해야 합니다.

어떤 평가 프레임워크를 선택해야 할까요?

프레임워크 선택보다 평가 설계가 더 중요합니다. 정교한 플랫폼에서 취약한 평가 스위트를 구축할 수도 있고, 몇 개의 스크립트로 강력한 평가 스위트를 구축할 수도 있습니다. 테스트를 재현 가능하고, 버전 관리가 잘 되며, 검사하기 쉽고, 중요한 변경 사항이 발생하기 전에 쉽게 실행할 수 있는 도구를 우선적으로 고려하십시오.

실용적인 출시 평가표

제작 보조 담당자에게 유용한 릴리스 결정은 하나의 종합 점수 대신 일련의 게이트로 표현될 수 있습니다. 예를 들어, 선별된 안전 세트에서 심각한 안전 실패가 없어야 하고, 작업 정확도에서 통계적으로 의미 있는 회귀가 없어야 하며, RAG 질문에 대한 최소한의 근거성 통과율을 충족해야 하고, 모든 스키마 사례에서 유효한 구조화된 출력을 제공해야 하며, 지연 시간이나 비용이 운영 예산 범위 내에 있어야 합니다. 정확한 임계값은 위험 허용 수준과 사용자 요구 사항에 따라 결정되어야 하며, LLM을 "충분히 좋은" 것으로 판단하는 보편적인 백분율은 없습니다.

또한 점수 산출의 근거가 되는 원본 예시들을 보존해야 합니다. 예를 들어 릴리스 버전이 0.84에서 0.86으로 변경되더라도 어떤 두 가지 사례가 변경되었는지, 그리고 그 변경 사항이 중요한지 여부를 파악해야 합니다. 실제로 팀은 추적성이 없는 인상적인 대시보드 평균 점수보다 명확하게 분류된 소수의 실패 사례를 통해 더 많은 것을 배울 수 있습니다.

흔히 저지르는 평가 실수

• 정상적인 경로만 테스트하는 대신 , 모호성, 예외 상황, 프롬프트 주입 시도, 누락된 컨텍스트 및 알려진 과거 실패 사례를 추가하십시오.
• 정확한 일치 항목은 주관식 답변에 사용하고, 정확성이 정말 필요한 경우에만 사용하세요.
• 보정 없이 LLM 심사위원을 신뢰하기: 사람의 평가 결과와 비교하고 불일치 사항을 검토하십시오.
• 평균치를 최적화하면서 심각한 실패는 숨기는 방법: 안전, 정책 및 기타 중요한 요소들을 명확한 관문으로 유지하십시오.
• 모델 비교 중 데이터셋 변경 시: 비교 세트를 고정하거나 버전을 관리하여 결과 해석이 가능하도록 하십시오.
• 생산 편차 무시: 오프라인 평가는 릴리스를 보호하고, 온라인 평가 및 샘플링된 사람 검토는 새로운 사용자 행동과 새로운 오류 모드를 드러냅니다.

결론적으로

LLM 응답 품질 측정은 단순한 분위기 점검이 아니라 엔지니어링 분야입니다. 대표적인 데이터셋으로 시작하여 작업별 품질 기준을 정의하고, 계산 가능한 요구사항에는 확정적 검사를 적용하고, 의미 판단이 필요한 경우에는 LLM 평가 도구를 사용하고, 이러한 평가 도구를 사람과 비교하여 보정하고, 안정적인 기준선과 후보 변경 사항을 비교해야 합니다. 그리고 모든 중요한 실제 실패 사례를 향후 회귀 테스트로 활용해야 합니다.

이러한 과정을 따르면 평가 프레임워크는 단순한 보고 대시보드 이상의 역할을 하게 됩니다. 즉, 프롬프트, 모델, 검색 변경 또는 에이전트 업데이트가 실제로 제품을 개선했는지 여부를 알려주는 품질 관리 시스템이 되는 것입니다.