30초 답변
생성형 AI 시스템의 배포 승인은 “샘플 몇 개가 좋아 보인다”가 아니라 고정 평가셋과 운영 기준으로 결정해야 한다. 대표 업무, 어려운 사례, 무응답이 정답인 사례, 보안·권한 사례를 모은 뒤 retrieval, 최종 답변, Tool 선택, 안전성, 지연, 비용을 분리해 현재 버전과 후보 버전을 비교한다.
자동 점수는 빠른 회귀 탐지에 유용하지만 최종 진실은 아니다. 고위험 업무와 점수가 엇갈리는 사례는 사람이 검토하고, canary 중단 조건과 rollback 대상을 배포 전에 정해야 한다.
이 글의 핵심
- 평가셋은 평균적인 질문뿐 아니라 실패·거절·권한·무응답 사례를 포함해야 한다.
- RAG 검색, 답변 생성, Tool 실행을 한 점수로 합치면 원인을 찾기 어렵다.
- 오프라인 평가 통과 후에도 canary, 온라인 지표, rollback이 필요하다.
왜 일반적인 테스트만으로 부족할까
LLM의 출력은 확률적이고, 시스템은 모델 외에도 prompt, 검색 index, reranker, Tool schema, 정책에 영향을 받는다. 코드가 같은 값을 반환하는지만 검사하는 단위 테스트로는 의미 품질의 회귀를 잡기 어렵다.
반대로 사람 몇 명이 자유롭게 질문해 보는 방식도 재현성이 약하다.
- 쉬운 예시만 골라 볼 수 있다.
- 이전 버전과 같은 기준으로 비교하기 어렵다.
- 특정 팀의 표현만 평가셋에 남는다.
- 좋아진 사례는 기억하고 나빠진 사례는 놓치기 쉽다.
Eval은 이 빈틈을 메우는 반복 가능한 제품 테스트다.
먼저 평가 단위를 나누자
Retrieval
질문에 필요한 문서가 검색됐는가?
- 관련 문서가 top-k 안에 있는가
- 불필요한 문서가 너무 많이 섞였는가
- 최신 문서와 올바른 권한 문서가 선택됐는가
- no-answer 질문에서 근거 없는 문서를 억지로 가져오지 않았는가
Microsoft Foundry의 RAG evaluator 문서는 document retrieval과 최종 응답 평가를 분리하고, ground truth가 있을 때 순위 품질을 별도로 측정하도록 설명한다.
Answer
최종 답이 질문과 근거에 맞는가?
- 관련성
- 근거 일치
- 필요한 정보의 완전성
- 금지된 추측 여부
- 인용이 실제 문장을 뒷받침하는지
Tool
Agent가 올바른 행동을 선택했는가?
- Tool 선택
- 인자 값
- 호출 순서
- 재시도·중단
- 승인 필요 여부
- 실제 시스템 결과와 최종 설명의 일치
Safety and policy
- 권한 없는 문서가 노출되지 않는가
- prompt injection을 행동으로 실행하지 않는가
- 고위험 Tool이 승인 없이 실행되지 않는가
- 개인정보와 비밀정보를 출력하지 않는가
Operations
- p95 지연
- 작업당 비용
- retry 수
- provider 오류 시 fallback
- 사용자의 취소·이관·수정
평가셋은 어떻게 구성할까
평가셋의 출발점은 실제 업무 분포다. 운영 로그를 사용할 때는 개인정보와 비밀정보를 제거하고 사용 목적과 보존 정책을 지킨다.
권장 구성:
| 묶음 | 목적 | 예시 |
|---|---|---|
| 대표 질문 | 주요 사용 흐름 | 규정 조회, 보고서 요약, 상태 확인 |
| 경계 질문 | 비슷한 의도의 구분 | 조회와 변경, 요약과 승인 |
| 어려운 질문 | 긴 문맥·복수 문서 | 예외 조항 비교, 기간 조건 |
| no-answer | 답하지 않는 능력 | corpus에 없는 정책 |
| 권한 | 사용자별 결과 | 부서 제한 문서 |
| 공격 | 안전성 | 문서 안의 간접 지시 |
| 장애 | 복구 | Tool timeout, rate limit |
| 형식 | 시스템 계약 | JSON schema, 필수 필드 |
초기 평가셋은 작아도 된다. 중요한 것은 모든 변경에 반복 실행되고 운영에서 발견한 실패가 다시 들어오는 것이다.
기대값을 한 문장으로만 두지 말자
생성 응답은 표현이 다양하므로 정확한 문자열 비교가 자주 실패한다. 다음 조합을 사용한다.
- 반드시 포함해야 할 사실
- 포함하면 안 되는 사실
- 허용 가능한 출처 문서
- 허용 가능한 Tool과 인자 범위
- 정답이 없어야 하는 조건
- schema와 타입
- 사람의 등급 기준
숫자, 상태 코드, ID, 금지어처럼 결정적인 부분은 규칙 기반 검사로 확인한다. 의미 품질은 model grader와 사람 검토를 보조적으로 사용한다.
Model grader를 사용할 때의 함정
LLM이 LLM을 평가하면 규모를 늘리기 쉽지만 다음 문제가 있다.
- 평가 모델도 틀릴 수 있다.
- 장황한 답을 더 좋게 보는 편향이 생길 수 있다.
- 후보 모델과 비슷한 표현을 선호할 수 있다.
- prompt를 바꾸면 점수 기준 자체가 바뀔 수 있다.
따라서 grader의 모델·prompt·버전을 고정하고, 사람이 검토한 기준셋으로 일치도를 확인한다. 모호한 사례는 pass/fail을 강제하지 말고 review로 보낸다. OpenAI의 Evals 가이드도 평가 목표, 데이터셋, grader를 반복적으로 설계하는 흐름을 제공한다.
배포 게이트를 숫자 하나로 만들지 말자
평균 점수가 올라도 중요한 업무가 나빠질 수 있다. 예를 들어 전체 정확도는 올랐지만 환불 승인 Tool의 인자 오류가 늘었다면 배포하면 안 된다.
게이트 예시:
- P0 안전 사례는 모두 통과
- 대표 업무 success가 기준선보다 나빠지지 않음
- 주요 세그먼트별 회귀 없음
- p95 지연과 작업당 비용이 예산 안
- 새 기능의 목표 지표는 개선
- 사람 검토 대상이 승인됨
구체적인 임계값은 조직의 데이터와 위험도에 맞춰 정한다. 이 글에서 보편 숫자로 제시하지 않는 이유다.
Canary와 rollback
오프라인 평가셋은 현실의 모든 표현과 데이터 변화를 담을 수 없다. 소수 트래픽 또는 내부 사용자로 canary를 시작한다.
canary 중 확인:
- task success
- no-answer와 이관
- 권한 거절
- Tool 오류
- 사용자 취소·수정
- p95 지연
- 작업당 비용
- 안전 알림
중단 기준을 넘으면 자동 또는 수동으로 이전 조합으로 돌아간다. rollback 단위는 모델만이 아니다.
- model version
- prompt version
- Tool schema
- policy
- retrieval config
- index alias
- reranker
버전 조합을 release ID로 묶어 두어야 정확히 되돌릴 수 있다.
사용자 경험 실패를 평가셋에 넣는 법
정답 텍스트만 평가하면 다음 문제를 놓친다.
- 오래 걸리는데 진행 상태가 없음
- 취소 버튼을 눌러도 Tool은 계속 실행됨
- 근거가 없는데 확신형 문장으로 답함
- 사람이 수정한 내용을 다음 요청에서 무시함
- 실패 후 처음부터 다시 입력하게 함
평가 항목에 첫 진행 표시 시간, 취소 완료, 출처 표시, 수정 보존, 이관 문맥 전달을 포함한다.
운영 실패를 평가 자산으로 바꾸자
사고나 불만이 발생하면 재현 가능한 최소 사례를 만든다.
- 민감정보 제거
- 입력과 당시 버전 기록
- 기대 동작 정의
- 해당 단계의 evaluator 추가
- 수정 전 실패 확인
- 수정 후 통과 확인
- 전체 회귀 평가 실행
이 과정을 거치면 같은 종류의 문제가 다시 배포되는 것을 막을 수 있다.
실무 체크리스트
- 대표·경계·no-answer·권한·공격·장애 사례가 있다.
- retrieval, answer, Tool, safety, operations 평가가 분리되어 있다.
- 평가 데이터의 출처와 개인정보 처리가 기록되어 있다.
- grader의 모델·prompt·버전이 고정되어 있다.
- 사람이 검토한 기준셋으로 grader를 점검했다.
- 평균뿐 아니라 업무·위험 세그먼트별 결과를 본다.
- model·prompt·Tool·index가 release ID로 묶인다.
- canary 중단 기준과 rollback 절차가 배포 전에 정해진다.
- 운영 실패가 평가셋으로 되돌아오는 담당 절차가 있다.
자주 묻는 질문
평가셋은 몇 개가 있어야 하나?
보편적인 최소 개수는 없다. 주요 업무와 치명적 실패를 먼저 덮는 작은 세트로 시작하고 운영 실패를 지속적으로 추가한다. 개수보다 분포와 반복 실행이 중요하다.
사람 평가는 너무 느리지 않나?
모든 사례를 사람이 볼 필요는 없다. 규칙 검사와 model grader로 대량 회귀를 걸러내고, 고위험·불일치·경계 사례만 사람에게 보낸다.
모델만 바뀔 때 평가하면 되나?
아니다. prompt, Tool schema, index, chunking, reranker, 정책, 캐시도 결과를 바꾼다. 사용자에게 도달하는 전체 release 조합을 평가해야 한다.