AI eval은 AI 결과가 좋아졌는지 감으로 판단하지 않기 위한 검증 흐름입니다. 프롬프트를 바꾼 뒤 예시 몇 개가 좋아 보인다고 바로 성공으로 보면 위험합니다. 중요한 것은 같은 테스트셋과 같은 기준으로 변경 전후를 비교하고, 실패 유형을 다시 개선에 반영하는 것입니다.
특히 프롬프트, 모델, RAG context, tool 호출 정책을 자주 바꾸는 서비스라면 AI eval은 선택이 아니라 운영 장치에 가깝습니다. 이전에 정리한 LLM 평가셋 글과 이어서 보면 좋습니다.
AI eval이 필요한 이유
LLM 결과는 그럴듯해 보이는 순간이 많습니다. 하지만 제품에서는 그럴듯함보다 일관성이 중요합니다. 어제는 맞던 답이 오늘 프롬프트 수정 뒤 틀릴 수 있고, 일반 질문은 좋아졌지만 edge case가 망가질 수 있습니다.
- 프롬프트 변경이 실제로 개선인지 확인한다
- 모델 업그레이드나 교체 때 회귀를 잡는다
- RAG 검색 결과와 답변 품질을 분리해서 본다
- 안전 정책, 금지 표현, 형식 준수를 확인한다
- 실패 유형을 다음 개선 작업으로 연결한다
OpenAI eval 가이드도 eval을 모델 출력이 지정한 style과 content criteria를 만족하는지 테스트하는 과정으로 설명합니다.
프롬프트가 좋아졌다는 말은 무엇을 뜻할까
프롬프트가 좋아졌다는 말은 막연합니다. 더 친절한가, 더 짧은가, 더 정확한가, 금지 조건을 더 잘 지키는가, 원하는 JSON 형식을 더 잘 맞추는가가 모두 다릅니다. 그래서 eval을 만들 때는 먼저 좋은 결과의 기준을 나눠야 합니다.
- 정확성: 사실이나 계산이 맞는가
- 형식: JSON, 표, bullet, tone 규칙을 지키는가
- 완전성: 필요한 항목을 빠뜨리지 않았는가
- 안전성: 금지된 주장이나 권유를 하지 않는가
- 일관성: 비슷한 입력에서 비슷한 기준으로 답하는가
이 기준이 없으면 프롬프트 평가는 결국 취향 평가가 됩니다. 반대로 기준이 있으면 여러 사람이 봐도 비슷한 결론에 가까워질 수 있습니다.
AI eval의 기본 구조
실무에서 가장 단순한 eval은 입력, 기대 기준, 실제 출력, 판정 결과로 구성됩니다. 처음부터 거창한 플랫폼이 없어도 CSV나 JSON 파일로 시작할 수 있습니다.
{
"input": "환불 정책을 3줄로 요약해줘",
"expected": {
"must_include": ["환불 가능 기간", "예외 조건", "문의 채널"],
"must_not_include": ["법률 자문처럼 단정"]
},
"rubric": "필수 항목을 포함하고, 과장 없이 사용자가 다음 행동을 알 수 있어야 한다"
}OpenAI 가이드는 task를 설명하고, test input으로 eval을 실행한 뒤, 결과를 분석해서 prompt를 반복 개선하는 흐름을 제시합니다. 이 구조는 특정 도구에 묶인 방식이라기보다 LLM 제품 개발의 기본 습관에 가깝습니다.
점수보다 실패 유형을 봐야 한다
eval 점수는 필요하지만, 점수만 보면 개선 방향을 놓치기 쉽습니다. 80점에서 86점으로 올랐다는 말보다 어떤 유형의 실패가 줄었고 어떤 유형이 새로 생겼는지가 더 중요합니다.
- 정답은 맞지만 설명이 너무 길다
- 형식은 맞지만 핵심 조건을 누락한다
- 일반 질문은 좋아졌지만 예외 상황에서 틀린다
- 근거가 없는 내용을 자신 있게 말한다
- 이전 프롬프트가 잘 처리하던 케이스가 회귀했다
그래서 eval 결과는 평균 점수와 함께 실패 샘플을 꼭 같이 봐야 합니다. 실제 개선은 실패 사례를 읽고 프롬프트, retrieval, tool policy, post-processing 중 어디를 고칠지 결정하는 과정에서 나옵니다.
프롬프트 변경 전후 비교 방법
프롬프트를 바꿀 때는 최소한 같은 입력으로 이전 버전과 새 버전을 나란히 돌려야 합니다. 가능하면 모델, temperature, retrieval 설정, tool 사용 조건도 고정합니다. 그래야 개선 원인을 프롬프트 변경으로 좁혀 볼 수 있습니다.
eval run
- prompt_version: support-summary-v3
- baseline: support-summary-v2
- dataset: support-tickets-120
- criteria: accuracy, required_fields, tone, safety
- compare: pass_rate, regression_cases, new_failure_cases이렇게 기록을 남기면 나중에 문제가 생겼을 때 어느 변경이 영향을 줬는지 추적하기 쉬워집니다.
주의할 점: eval도 유지보수 대상이다
eval은 한 번 만들고 끝나는 문서가 아닙니다. 제품이 바뀌면 좋은 답의 기준도 바뀝니다. 사용자 질문이 달라지고, 정책이 바뀌고, 모델이 바뀌면 평가셋도 같이 관리해야 합니다.
또한 OpenAI 문서 기준으로 Evals platform 자체는 deprecation 일정이 공지되어 있습니다. 따라서 특정 UI나 플랫폼 이름보다 데이터셋, 기준, 실행 기록, 실패 분석이라는 원칙을 중심으로 설계하는 편이 안전합니다.
정리
AI eval은 프롬프트를 잘 쓰기 위한 부가 작업이 아닙니다. 프롬프트, 모델, RAG, tool use가 바뀌어도 품질을 설명하고 유지하기 위한 운영 장치입니다.
작게 시작하려면 실제 입력 30개, 필수 기준 3개, 실패 유형 기록부터 만들면 됩니다. 그 다음에 자동 채점과 회귀 테스트를 붙여도 늦지 않습니다.
