AI Evals 실무 가이드: LLM 답변 품질 평가 방법

AI Evals는 LLM 답변 품질을 “괜찮아 보인다”는 감으로 판단하지 않고, 질문 세트와 채점 기준으로 반복 측정하는 평가 체계다. AI 기능이 데모를 넘어 서비스가 되면 모델 교체, 프롬프트 수정, RAG 인덱스 변경, 도구 추가가 모두 품질 변화를 만든다. Evals는 이런 변화를 배포 전에 감지하는 AI 시대의 회귀 테스트다.

AI Evals 평가 파이프라인 개념도: 골든 데이터셋, 채점 기준, 회귀 테스트, LLM-as-judge, 품질 대시보드 — AI Evals는 LLM 답변 품질을 감으로 판단하지 않고 테스트셋, 채점 기준, 회귀 테스트, 사람 평가로 반복 측정하는 운영 체계다.

핵심 요약

AI Evals는 LLM 기능의 품질을 질문 세트와 기준표로 반복 측정하는 방법이다.
좋은 eval은 정답만 맞히는지보다 근거성, 일관성, 안전성, 비용, 지연 시간까지 본다.
RAG, AI 에이전트, 코딩 에이전트는 평가 기준이 서로 다르다.
작은 팀은 20~50개 대표 질문과 pass/fail 기준으로 시작해도 충분하다.

왜 AI 기능은 감으로 평가하면 안 되나

일반 소프트웨어는 함수 입력과 출력이 비교적 명확하다. 테스트가 통과하면 같은 입력에 같은 결과를 기대할 수 있다. 반면 LLM 기능은 모델 버전, 프롬프트, 컨텍스트, 검색 결과, temperature, 도구 호출 상태에 따라 답변이 달라진다. 한두 번 직접 질문해 보고 “괜찮다”고 판단하면 배포 후 다른 질문에서 깨질 가능성이 크다.

특히 RAG나 AI 에이전트는 실패 지점이 많다. 검색이 틀릴 수도 있고, 문서를 맞게 찾았지만 요약을 잘못할 수도 있고, 도구 호출 인자를 잘못 만들 수도 있고, 안전 정책을 우회할 수도 있다. 그래서 평가도 답변 문장 하나가 아니라 전체 실행 흐름을 봐야 한다.

AI Evals의 기본 구성

구성 요소	역할	예시
평가 질문	반복 실행할 입력	사용자 FAQ, 장애 로그 질문, 검색 질문
기대 결과	정답 또는 허용 기준	필수 포함 키워드, 금지 표현, 참조 문서
채점 기준	품질을 판단하는 rubric	정확성, 근거성, 완전성, 안전성
평가자	점수를 매기는 방식	규칙, 사람, LLM-as-judge
회귀 기준	배포 가능 여부	핵심 테스트 95% 통과, 안전 테스트 100% 통과

Golden dataset부터 만든다

AI Evals의 출발점은 golden dataset이다. 이것은 “우리 서비스가 반드시 잘 답해야 하는 대표 질문 모음”이다. 처음부터 수천 개를 만들 필요는 없다. 실제 사용자 질문, 고객 지원 이력, 운영 실패 사례, 개발자가 만든 엣지 케이스에서 20~50개를 골라 시작하면 된다.

자주 들어오는 대표 질문
비즈니스상 틀리면 안 되는 질문
검색 문서가 여러 개 필요한 질문
과거에 hallucination이 발생한 질문
정책상 답하면 안 되는 질문
모델이 헷갈리기 쉬운 동음이의어와 경계 조건

평가 방식 3가지: 규칙, 사람, LLM-as-judge

방식	장점	단점	잘 맞는 용도
Rule-based	빠르고 재현 가능하다	표현이 다양한 답변 평가에 약하다	금칙어, JSON schema, URL 포함 여부
Human review	맥락 판단이 정확하다	느리고 비용이 든다	핵심 정책, 고위험 답변, 샘플 검수
LLM-as-judge	대량 평가와 복합 기준에 유리하다	평가자 모델 편향과 불안정성이 있다	정확성, 근거성, 완전성의 초벌 채점

실무에서는 세 방식을 섞는 편이 좋다. 예를 들어 JSON 출력 형식은 rule-based로 확인하고, 답변 품질은 LLM-as-judge로 1차 평가하고, 실패 샘플은 사람이 검수한다. 중요한 고위험 항목은 자동 평가 점수가 높아도 사람 검수를 통과해야 한다.

RAG 평가에서 봐야 할 항목

RAG 평가는 일반 챗봇 평가와 다르다. 최종 답변만 맞아 보인다고 좋은 RAG가 아니다. 검색된 문서가 적절했는지, 답변이 문서 근거에 충실한지, 없는 내용을 만들지 않았는지까지 확인해야 한다.

평가 항목	질문	실패 예시
Retrieval relevance	질문에 맞는 문서를 찾았는가	비슷하지만 다른 정책 문서를 가져옴
Context precision	불필요한 문서가 너무 많이 섞였는가	관련 없는 문서 때문에 답변이 흐려짐
Faithfulness	답변이 근거 문서에 충실한가	문서에 없는 조건을 만들어냄
Answer completeness	필수 정보를 빠뜨리지 않았는가	신청 자격은 말했지만 신청 기간을 누락
Citation quality	출처와 인용이 맞는가	다른 문서 URL을 근거로 표시

AI 에이전트 평가는 도구 실행까지 본다

AI 에이전트는 답변만 생성하지 않는다. 파일을 읽고, 코드를 수정하고, 터미널을 실행하고, 브라우저나 외부 API를 조작한다. 따라서 에이전트 eval은 최종 답변보다 실행 과정이 중요하다. 잘못된 도구를 호출했는지, 실패 후 복구했는지, 사용자 승인이 필요한 작업을 멋대로 실행하지 않았는지 확인해야 한다.

올바른 도구를 선택했는가
도구 인자를 안전하게 만들었는가
실패 로그를 보고 다른 전략으로 복구했는가
테스트를 실제로 실행했는가
권한이 필요한 작업에서 승인 절차를 지켰는가
최종 산출물이 요구사항을 만족하는가

작은 팀용 AI Evals 시작 순서

실제 사용자 질문과 실패 사례를 20~50개 모은다.
각 질문마다 반드시 포함할 내용과 금지할 내용을 적는다.
정확성, 근거성, 완전성, 안전성을 1~5점 rubric으로 만든다.
rule-based 체크와 LLM-as-judge 평가를 섞어 자동화한다.
배포 전 같은 eval을 실행해 이전 버전과 비교한다.
운영 중 나온 실패 사례를 다시 dataset에 추가한다.

평가 결과는 평균 점수만 보면 안 된다

평균 점수는 위험하다. 100개 중 95개가 좋아도, 나머지 5개가 결제, 의료, 법률, 보안, 개인정보 같은 고위험 질문이면 배포하면 안 된다. eval 결과는 전체 평균, 카테고리별 점수, 고위험 테스트 통과율, 실패 유형을 따로 봐야 한다.

지표	의미	주의점
Pass rate	전체 테스트 통과율	고위험 실패를 평균이 숨길 수 있다
Category score	질문 유형별 성능	RAG, 안전, 도구 실행을 분리해야 한다
Regression count	이전보다 나빠진 테스트 수	모델 교체 때 특히 중요하다
Cost per eval	평가 실행 비용	LLM-as-judge 남용을 막는다
Latency	응답 지연 시간	품질이 좋아도 서비스 UX를 해칠 수 있다

AI Evals 체크리스트

대표 질문 세트가 실제 사용자 질문을 반영하는가
정답 기준과 금지 기준이 문서화돼 있는가
RAG 검색 품질과 최종 답변 품질을 분리해 평가하는가
LLM-as-judge 결과를 사람 샘플 검수로 보정하는가
모델, 프롬프트, 인덱스 변경 전후를 비교하는가
고위험 질문은 별도 차단 기준을 두는가
실패 사례를 dataset에 계속 되돌리는가

FAQ

AI Evals는 무엇인가?

AI Evals는 LLM 애플리케이션의 답변 품질, 안정성, 근거성, 안전성을 테스트셋과 채점 기준으로 반복 측정하는 평가 체계다. 일반 소프트웨어 테스트처럼 AI 기능에도 회귀 테스트와 품질 기준을 두는 접근이다.

LLM-as-judge는 믿을 수 있는가?

LLM-as-judge는 빠르고 유연하지만 절대 기준은 아니다. 명확한 rubric, 샘플 검수, 사람 평가와의 일치도 확인, 모델 변경 시 재검증이 필요하다.

RAG 평가와 일반 챗봇 평가는 무엇이 다른가?

RAG 평가는 답변만 보지 않는다. 검색된 문서가 적절한지, 답변이 근거 문서에 충실한지, 인용이 맞는지, 없는 내용을 만들지 않았는지까지 함께 평가한다.

작은 팀도 AI Evals가 필요한가?

필요하다. 처음에는 20~50개의 대표 질문과 간단한 pass/fail 기준만 있어도 충분하다. 중요한 것은 배포 전 같은 질문을 반복 실행해 품질이 나빠졌는지 확인하는 습관이다.

AI Evals는 한 번 만들면 끝인가?

아니다. 사용자 질문, 실패 사례, 정책 변경, 모델 변경에 따라 계속 업데이트해야 한다. 실제 운영 로그에서 실패 사례를 골든 데이터셋으로 되돌리는 루프가 중요하다.

AI Evals 실무 가이드: LLM 답변 품질을 감으로 평가하지 않는 방법