생성형 AI 평가(Evaluation)와 LLM-as-a-Judge 기반 품질 관리
1. 개요
생성형 AI 평가는 모델·데이터·프롬프트·검색·도구가 결합된 시스템이 의도된 업무에서 정확성, 유용성, 안전성, 신뢰성 기준을 만족하는지 근거를 갖고 측정하고 개선하는 생애주기 활동이다.
생성형 AI는 같은 입력에도 출력이 달라질 수 있고, 문장 유창성이 사실 정확성과 일치하지 않는다. 따라서 몇 개의 시연 결과나 단일 벤치마크 점수만으로 서비스 적합성을 판단하면 환각, 편향, 정보 유출 같은 실패를 놓치기 쉽다. 기술사는 모델 점수보다 먼저 업무 목적, 허용 위험, 사용자와 실패 비용을 정의해야 한다. 이 기준이 있어야 정확도와 응답시간, 안전성 간의 상충을 명시적으로 결정할 수 있다.
평가 대상은 기초 모델만이 아니라 데이터셋, 프롬프트, 검색기, 생성기, 도구 호출, 사용자 인터페이스를 포함한 응용 시스템이다. 모델 교체나 지식베이스 갱신, 프롬프트 변경도 결과를 바꾸므로 같은 평가 사례를 반복 실행하고 버전별 결과를 비교해야 한다. 평가는 배포 승인 절차인 동시에 개발 피드백 루프이며, 운영 데이터에서 새 실패 사례를 찾아 다시 시험집합에 반영한다.
본 노트는 평가 목적과 데이터 설계, 정량·정성 지표, LLM-as-a-Judge, RAG·에이전트 평가, 운영 거버넌스를 논술형으로 정리한다. RAG 자체의 검색·생성 아키텍처는 [[rag]], 생애주기 운영은 [[llmops]]와 연계해 이해한다.
2. 평가 체계와 생애주기
가. 평가 체계의 구조
생성형 AI 서비스의 품질은 입력과 출력만 비교해 설명하기 어렵다. 입력 문맥의 품질, 검색 결과의 적합성, 프롬프트의 제약, 모델의 응답, 도구 실행 결과가 연쇄적으로 영향을 준다. 따라서 평가를 모델 수준, 구성요소 수준, 업무 시나리오 수준의 세 층위로 분해하고 다시 종단 간 품질로 통합한다.
flowchart LR
A[업무 목표와 위험 기준] --> B[평가 데이터셋]
B --> C[모델 평가]
B --> D[구성요소 평가]
C --> E[종단 간 시나리오 평가]
D --> E
E --> F[사람 검토와 승인]
F --> G[배포와 운영 관측]
G --> H[실패 사례 수집]
H --> B
업무 목표는 평가 기준의 출발점이다. 예를 들어 내부 규정 질의응답에서는 답변의 출처 근거성과 최신성이 중요하고, 코드 생성에서는 실행 성공과 보안 취약점이 핵심이다. 같은 모델이라도 사용 맥락과 피해 규모가 달라지면 필요한 시험 사례와 통과 기준이 달라진다.
평가 데이터셋은 입력, 기대 결과 또는 채점 기준, 위험 등급, 데이터 출처, 적용 시나리오를 구조화한다. 정답이 하나로 고정되는 분류 문제는 골드 라벨을 쓸 수 있지만, 요약·상담처럼 여러 답이 가능한 과제는 루브릭과 전문가 판정을 함께 둔다. 민감정보나 고객 대화가 포함되면 목적 제한, 접근 통제, 비식별화와 보유기간을 별도로 설계한다.
구성요소 평가는 오류가 발생한 지점을 좁혀 개선 선택지를 만든다. 검색이 원인인지 생성이 원인인지 구분하지 못하면 모델을 바꾸는 비용을 쓰고도 문제를 해결하지 못할 수 있다. 종단 간 평가는 사용자의 실제 요청에서 성공했는지, 실패 시 안전하게 거절하거나 사람에게 넘기는지 확인한다.
나. 평가 수행 절차
첫째, 평가 목적을 구체적인 업무 성공조건으로 표현한다. “좋은 답변” 대신 “정책 질문에 대해 근거 문서 조항을 인용하고, 근거가 없으면 답변을 보류한다”처럼 관찰 가능한 기준을 쓴다. 성공 기준에는 효과뿐 아니라 응답 지연, 비용, 사람 검토 비율, 허용 가능한 오류 위험을 포함한다.
둘째, 실제 사용분포를 반영하는 대표 데이터와 경계 사례를 함께 수집한다. 일반적인 요청뿐 아니라 모호한 질문, 다국어 입력, 오탈자, 장문 문맥, 상충 정보, 공격성 입력을 포함한다. 드물지만 피해가 큰 사례는 발생 빈도만으로 제외하지 않고 별도의 위험 기반 시험군으로 관리한다.
셋째, 지표와 채점 방식을 정하고 기준선 시스템을 측정한다. 모델, 프롬프트, 검색 설정, 임베딩, 데이터 스냅숏, 평가 코드와 난수 조건을 기록해야 결과를 재현할 수 있다. 점수의 평균뿐 아니라 신뢰구간, 하위 집단별 결과, 실패 유형 분포를 확인한다.
넷째, 오류를 분류한 뒤 개선 가설을 세우고 동일 평가집합과 독립 검증집합으로 재시험한다. 평가집합을 반복 튜닝에만 사용하면 그 사례에 과적합되어 새로운 사용자 입력에서 성능이 떨어질 수 있다. 검증집합은 고정된 회귀시험에, 운영에서 얻은 신규 사례는 별도 후보군에 두고 검토 후 편입한다.
다섯째, 배포 전 승인 기준과 운영 모니터링을 연결한다. 중대 위험 시험의 실패는 평균 점수로 상쇄하지 않도록 차단 기준을 둘 수 있다. 운영 중에는 응답 품질, 거절률, 검색 실패, 비용, 지연, 사용자 신고를 추적하고 분포 변화가 감지되면 재평가한다.
3. 평가 지표와 시험 데이터
가. 품질 차원의 분해
정확성은 결과가 사실 또는 정답 기준에 부합하는지를 본다. 정답 라벨이 명확한 과제에는 정확도, 정밀도, 재현율, F1, 완전 일치 등을 적용할 수 있다. 개방형 생성 결과에는 단어 중복률만 적용하지 말고, 사실성·관련성·완전성 등 업무 의미를 평가해야 한다.
근거성은 답변의 주장이 제공된 문서나 검증 가능한 근거로 뒷받침되는지 측정한다. RAG 응답이 문맥과 모순되지 않는지 보는 충실도 지표가 대표적이지만, 문맥 자체가 오래되었거나 잘못된 경우에는 답변도 잘못될 수 있다. 따라서 근거성 점수만으로 사실 정확성을 대체하지 않고 원문 출처와 최신성을 별도 점검한다.
유용성·관련성은 사용자의 의도에 직접 답하고 필요한 내용을 빠뜨리지 않았는지 본다. 안전성은 유해 출력, 개인정보 노출, 편향, 프롬프트 인젝션, 위험한 도구 실행을 평가한다. 운영 품질에는 성공률, p95 지연, 토큰 비용, 재시도율, 사람 이관율과 서비스 가용성을 포함한다.
나. 지표 선택과 해석
| 평가 영역 | 예시 지표 | 해석 시 유의점 |
|---|---|---|
| 정답성 | 정확도, F1, 완전 일치 | 클래스 불균형이면 정확도만으로 오판할 수 있음 |
| 검색 | 문맥 정밀도·재현율, 순위 지표 | 정답 문서 존재 여부와 검색 순위를 함께 봄 |
| 생성 | 관련성, 완전성, 충실도 | 단일 점수로 답변의 모든 품질을 대표하지 않음 |
| 안전 | 정책 위반률, 유해성, 누출률 | 심각도와 공격 유형별로 별도 집계 |
| 에이전트 | 도구 선택 정확도, 실행 성공률 | 인자 정확성, 권한, 부작용 통제를 확인 |
| 운영 | p95 지연, 비용/요청, 이관률 | 사용자 집단과 업무별 서비스 수준을 구분 |
검색 문맥 정밀도는 반환된 자료 중 질의와 관련된 비율을, 재현율은 관련 자료를 얼마나 놓치지 않았는지를 나타낸다. 정밀도를 높이면 불필요한 문맥을 줄일 수 있지만 중요한 근거를 누락할 수 있고, 재현율을 높이면 생성기가 다룰 잡음이 늘 수 있다. 따라서 top-k, 청킹 방식, 재랭커와 생성 프롬프트를 조합해 업무별 균형점을 찾는다.
정량 지표는 서로 상충할 수 있다. 예를 들어 간결성을 높이면 불필요한 장황함은 줄어도 절차의 중요한 단계를 빠뜨릴 수 있다. 지표 사전에는 정의, 측정 단위, 데이터 범위, 산식, 소유자, 통과 기준, 알려진 한계를 함께 기록한다.
시험집합은 실제 트래픽의 단순 복사본이 아니다. 개인정보와 저작권, 특정 고객이나 지역에 대한 편중을 확인하고, 입력 분포·언어·난이도·위험도를 층화해 표본을 구성한다. 합성 데이터는 희귀 사례를 보완할 수 있지만 생성 모델의 편향을 재현할 수 있으므로 전문가 검토와 실제 사례 대조가 필요하다.
4. LLM-as-a-Judge
가. 원리와 활용
LLM-as-a-Judge는 별도의 언어모델이 생성 응답을 루브릭, 기준 답안 또는 두 응답 간 비교에 따라 평가하는 방법이다. 사람이 모든 응답을 읽는 비용을 낮추고 대량의 개방형 결과를 일관된 형식으로 채점할 수 있다. 특히 답변의 관련성, 근거성, 설명의 완전성처럼 단순 문자열 비교로 포착하기 어려운 차원에 적용된다.
평가 입력은 질문, 시스템이 사용한 문맥, 생성 답변, 평가 기준, 선택적 정답과 정책을 분명히 구분해 제공한다. 출력은 자유 서술보다 등급, 통과/실패, 근거 문장 등 구조화된 스키마로 제한해 후속 분석을 쉽게 한다. 점수만 저장하지 말고 입력 버전, 평가자 모델·프롬프트, 채점 사유, 사람 판정과의 일치도도 보존한다.
sequenceDiagram
participant D as 평가 데이터
participant S as 대상 시스템
participant J as Judge 모델
participant H as 전문가 검토
D->>S: 질의와 고정 문맥
S-->>D: 생성 응답과 추적 정보
D->>J: 응답·루브릭·참조 근거
J-->>D: 점수·판정 근거
D->>H: 표본과 불일치 사례
H-->>D: 기준 라벨과 오류 분류
D->>S: 개선 요구와 회귀시험
나. 편향과 보정
Judge 역시 확률적 모델이므로 정답을 보장하지 않는다. 길고 세련된 답변을 선호하는 장황성 편향, 먼저 또는 나중에 놓인 답을 선호하는 위치 편향, 특정 표현 방식에 대한 편향이 발생할 수 있다. 자기 모델의 결과를 더 높게 평가하는 자기 선호나, 안전 정책과 업무 루브릭의 상충도 점검해야 한다.
보정은 소규모 전문가 라벨을 기준으로 시작한다. 표본별 판정 일치율과 함께 오탐·미탐, 등급별 혼동행렬, 집단별 불일치를 보고, 오류 패턴에 맞춰 평가 기준을 명확히 한다. 일치율이 높더라도 중요한 위험군에서 실패가 집중될 수 있으므로 집계 점수만으로 자동화를 승인하지 않는다.
쌍대 비교는 두 응답을 같은 기준으로 비교해 절대 점수의 눈금 차이를 줄인다. 순서 효과를 줄이려면 응답 순서를 바꾼 반복 평가나 눈가림 평가를 활용한다. 평가 문항과 답변 길이, 제공 문맥을 고정하고 모델 버전 및 샘플링 파라미터를 기록한다.
Judge는 사람 검토의 대체재가 아니라 확장 가능한 보조 평가자다. 고위험 의사결정, 법률·의료 판단, 차별 영향과 실제 피해 판정은 도메인 전문가 검토 및 이의제기 절차를 유지해야 한다. 자동 점수가 업무 목표에 잘못 정렬되면 팀이 점수만 올리는 방향으로 최적화할 수 있으므로 정기적인 기준 검토가 필요하다.
5. RAG·에이전트 시스템 평가
RAG 평가는 검색기와 생성기를 분리해 진단하고, 마지막에는 전체 응답의 유용성을 확인한다. 검색 단계에서는 관련 문서의 회수, 순위, 중복, 최신성과 접근권한 필터 적용을 평가한다. 생성 단계에서는 질문 관련성, 근거 충실도, 답변 완전성, 인용 정확성, 근거 없는 답변의 보류 여부를 평가한다.
예를 들어 사내 규정 상담에서 정확한 규정 조항을 검색했지만 적용 날짜를 잘못 해석하면 검색은 성공해도 시스템은 실패다. 반대로 답변이 문맥에 충실하더라도 검색된 문서가 폐기된 규정이면 근거성이 실제 정확성을 보장하지 않는다. 이 때문에 문서 버전, 시행일, 권한, 출처 식별자를 평가 데이터와 함께 유지한다.
에이전트 평가는 최종 문장뿐 아니라 중간 행동의 적절성도 대상으로 한다. 요청 분류, 계획 수립, 도구 선택, 인자 구성, 결과 해석, 승인 요청, 오류 복구와 종료 조건을 각각 시험한다. 외부 시스템에 쓰기 작업을 수행할 경우 잘못된 도구 호출의 영향 범위와 되돌리기 수단을 검증한다.
다중 단계 흐름은 성공률만으로 충분하지 않다. 불필요한 도구 호출 수, 토큰 및 비용, 완료 시간, 재시도, 순환 호출, 권한 초과 시도와 인간 이관을 함께 측정한다. 도구가 실패하거나 검색 근거가 부족할 때 안전하게 중단하는 것이 무리하게 완료하는 것보다 나은 경우가 있다.
6. 비교 및 적용 사례
| 방식 | 강점 | 한계와 적합한 용도 |
|---|---|---|
| 규칙·문자열 기반 | 빠르고 결정적이며 재현 쉬움 | 의미가 다양한 개방형 답변에는 취약 |
| 전통 정량 지표 | 대규모 비교와 추세 관찰에 유리 | 기준 답변·라벨 품질에 의존 |
| LLM Judge | 의미 기반 채점의 확장성 | 편향·비결정성, 사람 기준과의 보정 필요 |
| 전문가 평가 | 맥락·위험 판단의 깊이 | 비용과 속도, 평가자 간 편차 |
| 실제 운영 실험 | 실제 행동과 만족도 관측 | 위험 통제, 표본 편향과 인과 해석 주의 |
이 방법들은 대체 관계보다 상호 보완 관계다. 배포 전에는 자동 회귀시험과 전문가 표본 검토를 조합하고, 운영에서는 안전한 범위의 온라인 지표와 사용자 신고를 함께 본다. 어떤 결과도 하나의 숫자로 축약하기보다 품질·위험·비용의 균형으로 해석한다.
사례 1 — 사내 지식 검색에서는 최근 개정 규정과 폐기 문서를 섞은 질문을 넣어 검색 최신성과 출처 인용을 시험한다. 정답 조항을 찾지 못한 경우 임의 답변 대신 보류와 담당자 이관이 동작하는지 확인한다. 검색 재현율은 높지만 구문이 오래된 문서가 자주 노출되면 문서 수명주기와 재랭커를 개선한다.
사례 2 — 고객 상담에서는 환불·계약·개인정보 문의를 의도별로 층화하고 다국어, 모호한 표현, 공격 입력을 포함한다. 정책 준수, 답변 정확성, 상담원 이관률, 응답시간을 함께 보며, 위험도가 높은 환불 승인은 사람 승인으로 경계를 둔다. 실제 고객 의견은 품질 신호이지만 불만 표본만 모이면 전체 체감 품질을 과소평가할 수 있다.
사례 3 — 코드 생성 에이전트에서는 코드 문장 유사도보다 빌드·단위시험 성공, 보안 검사, 도구 인자 정확성, 저장소 변경 범위를 검증한다. 권한이 제한된 테스트 환경에서 실행하고 비밀정보 유출·위험한 명령·외부 의존 추가를 별도 점검한다. 정답 코드를 그대로 생성하지 않아도 테스트를 통과할 수 있어 실행 기반 평가와 전문가 코드 검토를 함께 둔다.
7. 심화: 벤치마크와 위험 기반 평가의 결합
공개 벤치마크는 모델 간 비교와 기본 역량 파악에 도움이 되지만 특정 조직의 사용 맥락을 대신하지 못한다. 벤치마크에서 높은 점수를 받은 모델도 현장 데이터, 용어, 권한 구조, 안전 요구에서 실패할 수 있다. 따라서 공개 기준선, 도메인 시험집합, 실제 사용 로그에서 선별한 회귀 사례를 함께 사용한다.
Stanford CRFM의 HELM은 모델을 여러 시나리오와 다수의 지표로 평가해 능력과 한계를 폭넓게 비교하려는 접근이다. HELM의 사례는 단일 정확도 점수 대신 시나리오와 평가 차원의 범위를 함께 설계해야 한다는 점을 보여준다. 다만 공개 벤치마크 점수를 그대로 업무 승인 임계치로 사용하는 것은 적절하지 않다.
NIST AI RMF의 생성형 AI 프로파일은 신뢰성 평가를 AI 생애주기의 위험관리와 연결하고, 평가 방법의 타당성과 실제 사용 맥락 적합성을 강조한다. 사전 시험에는 자동 평가와 인간 감독을 함께 쓰고, 의도한 환경과 유사한 데이터·조건에서 성능과 위험을 점검하도록 제안한다. 이 접근은 모델의 성능뿐 아니라 개인정보, 편향, 보안, 출처와 사회적 영향까지 평가 범위에 포함하도록 돕는다.
최근 실무에서는 모델 변경마다 평가를 반복하는 eval-driven development가 확산되고 있다. 평가 케이스는 프롬프트 실패를 발견할 때마다 보강하며, 지속적 통합 파이프라인에서 회귀시험과 배포 차단 기준을 적용한다. LLM Judge는 루브릭 기준으로 사람 라벨과의 일치도를 먼저 확인한 뒤 제한된 범위에서 자동화한다.
8. 고려사항 및 시사점
가. 업무·위험 기반 지표 설계: 모든 서비스에 동일한 점수표를 강제하지 말고 실패 비용과 사용자 영향을 기준으로 최소 통과 기준을 설정한다. 효율성 지표와 안전성 지표가 충돌하면 경영진과 업무 책임자가 수용 가능한 위험을 명시해야 한다.
나. 시험 데이터의 대표성 및 누출 방지: 실제 입력 분포, 언어·지역·사용자 집단과 경계 사례를 반영하되 개인정보와 지식재산을 보호한다. 학습 또는 프롬프트 튜닝에 쓰인 사례가 시험집합으로 새지 않도록 분리와 접근권한을 관리한다.
다. 측정의 타당성·재현성 확보: 모델·데이터·프롬프트·평가 코드의 버전을 묶어 보존하고, 표본 오차와 평가자 불일치를 보고한다. 불확실한 점수를 확정적 품질 증명처럼 공표하지 않고 결과의 범위와 한계를 함께 설명한다.
라. 사람과 자동 평가의 적정 결합: 저위험 반복 업무는 자동 채점을 확대할 수 있지만, 고위험·모호한 사례는 전문가 검토와 이의제기 경로를 유지한다. 평가 기준을 만든 사람과 실제 사용자, 영향을 받는 집단의 관점을 함께 반영한다.
마. Judge 거버넌스: 평가자 모델의 편향, 버전 변경, 비용, 데이터 처리 위치를 관리하고 정기적으로 사람 판정과 재보정한다. 평가자가 대상 모델과 같은 오류를 공유할 가능성을 고려해 독립 모델, 규칙 기반 검증, 외부 근거를 조합한다.
바. 운영 피드백과 책임성: 실패 신고와 인간 수정 결과를 분류해 평가 사례로 환류하고, 민감한 로그는 최소 수집·목적 제한한다. 평가 결과를 변경 승인, 롤백, 사용자 고지, 사고 대응과 연결해 품질 개선이 실제 운영 통제로 이어지게 한다.
생성형 AI 평가는 모델 성능을 과시하는 일회성 벤치마크가 아니라, 업무 가치와 허용 위험을 정렬하는 지속적 통제 체계다. 기술사는 데이터·측정·사람·운영 절차를 통합해 “무엇을 잘한다고 판단할 것인가”를 조직적으로 합의해야 한다.
참고자료
- OpenAI, Evaluation best practices: https://developers.openai.com/api/docs/guides/evaluation-best-practices
- Ragas, Available metrics: https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/
- Ragas, Align an LLM as a Judge: https://docs.ragas.io/en/stable/howtos/applications/align-llm-as-judge/
- Stanford CRFM, HELM: https://crfm.stanford.edu/helm/
- NIST, AI RMF Generative AI Profile (NIST AI 600-1, final July 2024 edition): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
한 줄 요약: 생성형 AI의 신뢰성은 실제 업무를 반영한 다층 평가, 사람 기준으로 보정된 자동 채점, 운영 실패의 지속적 환류로 확보한다.