평가 모범 사례

생성형 AI는 가변적입니다. 모델은 같은 입력에서도 때때로 다른 출력을 내기 때문에, 전통적인 소프트웨어 테스트 방식으로는 AI 아키텍처를 충분히 검증할 수 없습니다. Evaluations(evals)는 이러한 변동성에도 불구하고 AI 시스템을 테스트하는 방법입니다.

이 가이드는 evals 설계에 대한 높은 수준의 지침을 제공합니다. Evals API를 시작하려면 모델 성능 평가하기를 참고하세요.

OpenAI는 Evals 플랫폼을 폐지하고 있습니다. 기존 evals 콘텐츠는 전환 기간 동안 계속 사용할 수 있습니다. Evals는 2026년 10월 31일부터 기존 사용자에게 읽기 전용이 되며, 플랫폼은 2026년 11월 30일에 종료될 예정입니다. 현재 일정은 폐지 안내 페이지에서 확인하세요.

출처: 문서

본문

evals란 무엇인가요

Evals는 모델 성능을 측정하기 위한 구조화된 테스트입니다. AI 시스템의 비결정적 특성에도 불구하고 정확성·성능·신뢰성을 보장하는 데 도움이 됩니다. 또한 LLM 기반 애플리케이션의 성능을 _개선_하는 몇 안 되는 방법 중 하나입니다(파인튜닝을 통해).

evals의 유형

"evals"라는 단어는 몇 가지를 가리킬 수 있습니다:

MMLU와 HuggingFace의 리더보드에 나열된 것 같은, 모델을 개별적으로 비교하기 위한 산업 벤치마크
ROUGE, BERTScore 같은 표준 수치 점수 — 사용 사례에 맞는 evals를 설계할 때 사용할 수 있습니다.
LLM 애플리케이션의 성능을 측정하기 위해 구현하는 특정 테스트

이 가이드는 세 번째 유형, 즉 자신만의 evals 설계에 관한 것입니다.

evals 읽는 법

0과 1 사이의 수치 eval 점수를 자주 볼 것입니다. evals에는 점수보다 더 많은 것이 있습니다. 올바른 질문에 답하고 있는지 확인하기 위해 지표와 인간의 판단을 결합하세요.

Evals 팁

Eval 중심 개발을 채택하세요: 자주, 그리고 일찍 평가하세요. 모든 단계에서 범위가 정해진 테스트를 작성하세요.
작업별 evals를 설계하세요: 테스트가 실제 세계 분포에서 모델 능력을 반영하게 하세요.
모든 것을 기록하세요: 개발하면서 기록해 좋은 eval 사례를 로그에서 캐낼 수 있게 하세요.
가능하면 자동화하세요: 자동 점수를 허용하도록 평가를 구조화하세요.
여정이지 목적지가 아닙니다: 평가는 지속적인 과정입니다.
일치도를 유지하세요: 인간 피드백을 사용해 자동 점수를 보정하세요.

안티 패턴

지나치게 일반적인 지표: perplexity나 BLEU 점수 같은 학술적 지표에만 의존하는 것.
편향된 설계: 프로덕션 트래픽 패턴을 충실히 재현하지 않는 eval 데이터셋을 만드는 것.
분위기 기반 evals: "작동하는 것처럼 보인다"를 평가 전략으로 삼거나, 출시할 때까지 evals를 전혀 구현하지 않는 것.
인간 피드백 무시: 자동화된 지표를 인간 평가에 대해 보정하지 않는 것.

eval 프로세스 설계하기

eval 워크플로의 중요한 구성 요소는 몇 가지입니다:

eval 목표 정의. eval의 성공 기준은 무엇인가요?
데이터셋 수집. 목표에 대해 평가하는 데 어떤 데이터가 도움이 될까요? 합성 eval 데이터, 도메인별 eval 데이터, 구매한 eval 데이터, 인간이 선별한 eval 데이터, 프로덕션 데이터, 과거 데이터를 고려하세요.
eval 지표 정의. 성공 기준이 충족되었는지 어떻게 확인할까요?
evals 실행 및 비교. 작업 또는 시스템의 모델 성능을 반복하고 개선하세요.
지속적으로 평가. 모든 변경 사항에 대해 evals를 실행하는 지속 평가(CE)를 설정하고, 앱을 모니터링해 비결정성의 새 사례를 식별하며, 시간이 지나면서 eval 세트를 확장하세요.

몇 가지 예시를 살펴보겠습니다.

예시: 대본 요약

LLM 기반 애플리케이션의 대본 요약 능력을 테스트하려면 eval 설계는 다음과 같을 수 있습니다:

eval 목표 정의

모델은 관련성과 정확성에서 참조 요약과 경쟁할 수 있어야 합니다.
데이터셋 수집

프로덕션 데이터(생성된 요약에 대한 사용자 피드백에서 수집)와 도메인 전문가(작가)가 만든 데이터셋을 혼합해 "좋은" 요약을 판단하세요.
eval 지표 정의

보류된 1000개의 참조 대본 → 요약 세트에서 구현은 G-Eval을 사용해 ROUGE-L 점수 최소 0.40 이상, 일관성(coherence) 점수 최소 80%를 달성해야 합니다.
evals 실행 및 비교

Evals API를 사용해 OpenAI 대시보드에서 evals를 만들고 실행하세요.
지속적으로 평가

모든 변경 사항에 대해 evals를 실행하는 지속 평가(CE)를 설정하고, 앱을 모니터링해 비결정성의 새 사례를 식별하며, 시간이 지나면서 eval 세트를 확장하세요.

LLM은 옵션 간을 구별하는 데 더 능숙합니다. 따라서 평가는 개방형 생성 대신 쌍별 비교(pairwise comparisons), 분류, 특정 기준에 대한 채점 같은 작업에 집중해야 합니다. 평가 방법을 비교에서 LLM의 강점과 정렬하면 LLM 출력이나 모델 비교에 대한 더 신뢰할 수 있는 평가 결과가 나옵니다.

예시: 문서에 대한 Q&A

LLM 기반 애플리케이션의 문서 Q&A 능력을 테스트하려면 eval 설계는 다음과 같을 수 있습니다:

eval 목표 정의

모델은 정확한 답변을 제공하고, 필요에 따라 컨텍스트를 회상해 사용자 프롬프트를 추론하며, 사용자의 요구를 충족시키는 답변을 제공해야 합니다.
데이터셋 수집

프로덕션 데이터(질문에 제공된 답변에 대한 사용자 만족도에서 수집), 도메인 전문가가 만든 질문에 대한 하드코딩된 정답, 로그의 과거 데이터를 혼합해 사용하세요.
eval 지표 정의

컨텍스트 회상(context recall) 최소 0.85, 컨텍스트 정밀도(context precision) 0.7 초과, 긍정 평가 답변 70% 이상.
evals 실행 및 비교

Evals API를 사용해 OpenAI 대시보드에서 evals를 만들고 실행하세요.
지속적으로 평가

모든 변경 사항에 대해 evals를 실행하는 지속 평가(CE)를 설정하고, 앱을 모니터링해 비결정성의 새 사례를 식별하며, 시간이 지나면서 eval 세트를 확장하세요.

eval 데이터셋을 만들 때는 gpt-6-astra가 eval 예시와 엣지 케이스 수집에 유용합니다. 다양한 시나리오에 걸쳐 다양한 테스트 데이터 세트를 생성하는 데 사용하는 것을 고려하세요. 테스트 데이터에 일반 케이스, 엣지 케이스, 악의적(adversarial) 케이스가 포함되도록 하세요. 인간 전문 라벨러를 사용하세요.

evals가 필요한 위치 파악하기

단순한 아키텍처에서 더 복잡한 아키텍처로 이동할수록 복잡성이 증가합니다. 네 가지 일반적인 아키텍처 패턴은 다음과 같습니다:

단일 턴 모델 상호작용
워크플로
단일 에이전트
다중 에이전트

아래 각 아키텍처를 읽고 비결정성이 시스템에 어디서 들어오는지 파악하세요. 그곳에 evals를 구현해야 합니다.

단일 턴 모델 상호작용

이런 유형의 아키텍처에서 사용자는 모델에 입력을 제공하고, 모델은 (제공된 개발자 프롬프트와 함께) 이러한 입력을 처리해 해당 출력을 생성합니다.

예시

예를 들어 온라인 소매 시나리오를 생각해 보세요. 시스템 프롬프트는 모델에게 고객 질문을 분류하도록 지시합니다:

order_status
return_policy
technical_issue
cancel_order
other

일관되고 효율적인 사용자 경험을 보장하려면 모델은 사용자 의도와 일치하는 라벨만 반환해야 합니다. 고객이 "What's the status of my order?"라고 물었다고 가정해 보세요.

도입되는 비결정성	평가할 해당 영역	예시 eval 질문
개발자와 사용자가 제공한 입력	지침 준수: 모델이 제공된 지침을 정확히 이해하고 따르는가? 지침 준수: 모델이 상충하는 사용자 프롬프트보다 시스템 프롬프트를 우선시하는가?	모델이 분류(triage) 작업에 집중하는가, 아니면 사용자 질문에 흔들리는가?
모델이 생성한 출력	기능적 정확성: 모델의 출력이 의도한 작업이나 목표를 수행하기에 정확하고 관련성이 있으며 충분히 철저한가?	모델의 의도 판단이 기대하는 의도와 정확히 일치하는가?

워크플로 아키텍처

더 복잡한 문제를 풀려고 하면 단일 턴 모델 상호작용에서 여러 모델 호출을 연결하는 다단계 워크플로로 전환할 가능성이 높습니다. 워크플로는 새로운 비결정성 요소를 도입하지 않지만, 개별적으로 평가할 수 있는 여러 기본 모델 상호작용을 포함합니다.

예시

고객이 주문 상태를 묻는 이전과 같은 예를 들어보겠습니다. 워크플로 아키텍처는 고객 요청을 분류하고 단계별 프로세스로 라우팅합니다:

주문 ID 추출
주문 세부 정보 조회
최종 응답을 위해 주문 세부 정보를 모델에 제공

이 워크플로의 각 단계에는 모델이 따라야 할 자체 시스템 프롬프트가 있으며, 모든 가져온 데이터를 친근한 출력으로 정리합니다.

도입되는 비결정성	평가할 해당 영역	예시 eval 질문
개발자와 사용자가 제공한 입력	지침 준수: 모델이 제공된 지침을 정확히 이해하고 따르는가? 지침 준수: 모델이 상충하는 사용자 프롬프트보다 시스템 프롬프트를 우선시하는가?	모델이 분류 작업에 집중하는가, 아니면 사용자 질문에 흔들리는가? 모델이 주문 ID를 추출하려 시도하라는 지침을 따르는가? 최종 응답에 주문 상태, 예상 도착 날짜, 운송 추적 번호가 포함되는가?
모델이 생성한 출력	기능적 정확성: 모델의 출력이 의도한 작업이나 목표를 수행하기에 정확하고 관련성이 있으며 충분히 철저한가?	모델의 의도 판단이 기대하는 의도와 정확히 일치하는가? 최종 응답에 올바른 주문 상태, 예상 도착 날짜, 운송 추적 번호가 있는가?

단일 에이전트 아키텍처

워크플로와 달리 에이전트는 유연한 의사 결정이 필요한 비구조적 문제를 해결합니다. 에이전트는 지침과 도구 세트를 가지며 사용할 도구를 동적으로 선택합니다. 이는 비결정성의 새로운 기회를 도입합니다.

도구는 모델이 실행할 수 있는 개발자가 정의한 코드 조각입니다. 이는 작은 헬퍼 함수부터 기존 서비스에 대한 API 호출까지 다양합니다. 예를 들어 check_order_status(order_id)는 도구일 수 있으며, order_id 인자를 받아 주문 상태를 확인하는 API를 호출합니다.

예시

고객 서비스 예시를 단일 에이전트로 바꿔 보겠습니다. 에이전트는 세 가지 서로 다른 도구에 접근할 수 있습니다:

주문 조회 도구
비밀번호 재설정 도구
제품 FAQ 도구

고객이 주문 상태를 물으면 에이전트는 동적으로 도구를 호출할지 또는 고객에게 응답할지 결정합니다. 예를 들어 고객이 "What is my order status?"라고 물으면 에이전트는 고객에게 주문 ID를 요청해 후속 조치할 수 있습니다. 이는 더 자연스러운 사용자 경험을 만드는 데 도움이 됩니다.

비결정성	평가할 해당 영역	예시 eval 질문
개발자와 사용자가 제공한 입력	지침 준수: 모델이 제공된 지침을 정확히 이해하고 따르는가? 지침 준수: 모델이 상충하는 사용자 프롬프트보다 시스템 프롬프트를 우선시하는가?	모델이 분류 작업에 집중하는가, 아니면 사용자 질문에 흔들리는가? 모델이 주문 ID를 추출하려 시도하라는 지침을 따르는가?
모델이 생성한 출력	기능적 정확성: 모델의 출력이 의도한 작업이나 목표를 수행하기에 정확하고 관련성이 있으며 충분히 철저한가?	모델의 의도 판단이 기대하는 의도와 정확히 일치하는가?
모델이 선택한 도구	도구 선택: 에이전트가 사용할 올바른 도구를 선택할 수 있는지 테스트하는 평가. 데이터 정밀도: 에이전트가 올바른 인자로 도구를 호출하는지 검증하는 평가. 일반적으로 이 인자들은 대화 기록에서 추출되므로 이 추출이 올바른지 검증하는 것이 목표입니다.	사용자가 주문 상태를 물을 때 모델이 주문 조회 도구를 호출하도록 올바르게 권장하는가? 모델이 사용자가 제공한 주문 ID를 조회 도구로 올바르게 추출하는가?

다중 에이전트 아키텍처

단일 에이전트 아키텍처에 도구와 작업을 추가하면 모델이 지침을 따르거나 호출할 올바른 도구를 선택하는 데 어려움을 겪을 수 있습니다. 다중 에이전트 아키텍처는 서로 다른 영역을 전문으로 하는 여러 개별 에이전트를 만들어 도움을 줍니다. 여러 에이전트 간의 이런 분류와 전달(handoff)은 비결정성의 새로운 기회를 도입합니다.

다중 에이전트 아키텍처 사용 결정은 evals에 기반해야 합니다. 다중 에이전트 아키텍처로 시작하면 프로덕션 출시 시간을 늦출 수 있는 불필요한 복잡성이 추가됩니다.

예시

단일 에이전트 예시를 다중 에이전트 아키텍처로 나누면 네 개의 개별 에이전트가 있습니다:

분류 에이전트
주문 에이전트
계정 관리 에이전트
영업 에이전트

고객이 주문 상태를 물으면 분류 에이전트는 주문을 조회하기 위해 대화를 주문 에이전트에 전달할 수 있습니다. 고객이 주제를 바꿔 제품에 대해 묻는다면 주문 에이전트는 요청을 분류 에이전트로 되돌려 보내고, 분류 에이전트는 제품 정보를 가져오기 위해 영업 에이전트로 전달합니다.

비결정성	평가할 해당 영역	예시 eval 질문
개발자와 사용자가 제공한 입력	지침 준수: 모델이 제공된 지침을 정확히 이해하고 따르는가? 지침 준수: 모델이 상충하는 사용자 프롬프트보다 시스템 프롬프트를 우선시하는가?	모델이 분류 작업에 집중하는가, 아니면 사용자 질문에 흔들리는가? `lookup_order` 호출이 반환되었다고 가정할 때, 주문 에이전트가 추적 번호와 배송 날짜를 반환하는가(정확하지 않아도 됨)?
모델이 생성한 출력	기능적 정확성: 모델의 출력이 의도한 작업이나 목표를 수행하기에 정확하고 관련성이 있으며 충분히 철저한가?	모델의 의도 판단이 기대하는 의도와 정확히 일치하는가? `lookup_order` 호출이 반환되었다고 가정할 때, 주문 에이전트가 응답에 올바른 추적 번호와 배송 날짜를 제공하는가? 주문 에이전트가 반품을 처리하기 전에 고객에게 반품 사유를 묻도록 시스템 지침을 따르는가?
모델이 선택한 도구	도구 선택: 에이전트가 사용할 올바른 도구를 선택할 수 있는지 테스트하는 평가. 데이터 정밀도: 에이전트가 올바른 인자로 도구를 호출하는지 검증하는 평가. 일반적으로 이 인자들은 대화 기록에서 추출되므로 이 추출이 올바른지 검증하는 것이 목표입니다.	주문 에이전트가 주문 조회 도구를 올바르게 호출하는가? 주문 에이전트가 `refund_order` 도구를 올바르게 호출하는가? 주문 에이전트가 올바른 주문 ID로 주문 조회 도구를 호출하는가? 계정 에이전트가 올바른 계정 ID로 `reset_password` 도구를 올바르게 호출하는가?
에이전트 전달	에이전트 전달 정확도: 각 에이전트가 다른 에이전트로 분류하기 위한 판단 경계를 적절히 인식할 수 있는지 테스트하는 평가	사용자가 주문 상태를 물을 때 분류 에이전트가 주문 에이전트로 올바르게 넘겨주는가? 사용자가 최신 제품에 대해 이야기하도록 주제를 바꾸면 주문 에이전트가 분류 에이전트로 제어권을 되돌려주는가?

다양한 유형의 평가자 만들기 및 결합하기

자신만의 evals를 설계할 때 선택할 수 있는 몇 가지 구체적인 평가자 유형이 있습니다. 또 다른 관점은 평가자가 어떤 역할을 하길 원하는지 생각하는 것입니다.

지표 기반 evals

정량적 evals는 결과를 필터링하고 순위를 매길 수 있는 수치 점수를 제공합니다. 자동화된 회귀 테스트에 유용한 벤치마크를 제공합니다.

예시: 정확히 일치(Exact match), 문자열 일치, ROUGE/BLEU 채점, 함수 호출 정확도, 실행 가능한 evals(기능이나 동작을 평가하기 위해 실행 — 예: text2sql)
과제: 특정 사용 사례에 맞춰지지 않을 수 있고, 미묘한 차이를 놓칠 수 있습니다.

인간 평가

인간 판단 평가는 최고 품질을 제공하지만 느리고 비용이 많이 듭니다.

예시: 시스템 출력을 훑어 더 좋아졌는지 나빠졌는지 감을 잡기; 직원·계약자·외부 라벨링 기관이 시스템 출력의 품질을 판단하는 무작위·블라인드 테스트 만들기(예: 가능한 출력의 작은 세트에 순위를 매기거나 각각 1-5 점수 부여)
과제: 인간 전문가 간 의견 불일치, 비용이 큼, 느림
권장사항:
- 스코어카드를 정제하기 위해 여러 차례의 상세한 인간 검토를 수행하세요.
- 서로 다른 점수 수준(예: 10점 중 1, 3, 8)의 예시를 제공해 "보여주기보다 말하기" 정책을 구현하세요.
- 수치 점수 외에도 통과/실패 임계값을 포함하세요.
- 여러 검토자를 집계하는 간단한 방법은 합의 투표(consensus votes)를 취하는 것입니다.

LLM-as-a-judge와 모델 그레이더

모델을 사용해 출력을 판단하는 것은 인간 평가보다 실행 비용이 더 낮고 확장성이 더 높습니다. 강력한 LLM 판사가 필요할 때는 gpt-6-astra부터 시작한 뒤, 비용이나 지연 시간을 최적화하기 전에 인간 라벨과의 일치를 검증하세요.

예시:
- 쌍별 비교: 판사 모델에게 두 응답을 제시하고 특정 기준에 따라 어느 것이 더 나은지 판단하게 합니다.
- 단일 답변 채점: 판사 모델이 단일 응답을 개별적으로 평가하고, 미리 정의된 품질 지표에 따라 점수나 등급을 부여합니다.
- 참조 기반 채점: 판사 모델에게 참조 또는 "gold standard" 답변을 제공해 주어진 응답을 평가할 벤치마크로 사용하게 합니다.
과제: 위치 편향(position bias, 응답 순서), 장황함 편향(verbosity bias, 더 긴 응답 선호)
권장사항:
- 더 높은 신뢰성을 위해 쌍별 비교 또는 통과/실패를 사용하세요.
- 가능하면 가장 유능한 모델로 채점하세요. gpt-6-astra부터 시작한 뒤, 전문 추론 모델이 루브릭이나 참조 답변 세트에서 더 잘 수행하는지 검증하세요.
- LLM은 일반적으로 더 긴 응답을 선호하므로 응답 길이를 제어하세요.
- 채점 전에 추론과 chain-of-thought를 추가하면 eval 성능이 향상됩니다.
- LLM 판사가 더 빠르고, 저렴하며, 인간 어노테이션과 지속적으로 일치하는 지점에 도달하면 확장하세요.
- 작업의 무결성을 유지하면서 자동 채점을 허용하도록 질문을 구조화하세요 — 일반적인 접근 방식은 질문을 객관식 형식으로 재구성하는 것입니다.
- eval 루브릭이 명확하고 상세한지 확인하세요.

완벽한 전략은 없습니다. LLM-as-Judge의 품질은 문제 컨텍스트에 따라 달라지며, 전문 인간 어노테이터를 사용해 정답 라벨을 제공하는 것은 비용이 많이 들고 시간이 걸립니다.

엣지 케이스 처리

평가가 각 아키텍처의 기본적이고 행복한 경로(happy-path) 시나리오를 다뤄야 하지만, 실제 세계 AI 시스템은 시스템 성능을 시험하는 엣지 케이스를 자주 만납니다. 이러한 엣지 케이스를 평가하는 것은 신뢰성과 좋은 사용자 경험을 보장하는 데 중요합니다.

이러한 엣지 케이스는 몇 가지 범주로 나뉩니다:

입력 변동성

사용자가 모델에 입력을 제공하므로 시스템은 사용자가 상호작용하는 다양한 방식을 처리할 수 있을 만큼 유연해야 합니다. 예:

비영어 또는 다국어 입력
입력 텍스트가 아닌 형식(예: XML, JSON, Markdown, CSV)
입력 모달리티(예: 이미지)

지침 준수와 기능적 정확성에 대한 evals는 사용자가 시도할 수 있는 입력을 수용해야 합니다.

컨텍스트 복잡성

많은 LLM 기반 애플리케이션은 요청의 컨텍스트를 제대로 이해하지 못해 실패합니다. 이 컨텍스트는 사용자로부터, 또는 과거 대화 기록의 노이즈에서 올 수 있습니다.

예시는 다음과 같습니다:

단일 요청에 여러 질문이나 의도가 있는 경우
오타와 철자 오류
컨텍스트가 거의 없는 짧은 요청(예: 사용자가 그냥 "returns"라고만 말하는 경우)
긴 컨텍스트 또는 오래 지속되는 대화
모호한 속성 이름으로 데이터를 반환하는 도구 호출(예: "on"이 주문 번호인 "on: 123")
때로는 잘못된 인자로 이어지는 여러 도구 호출
때로는 순환 전달로 이어지는 여러 에이전트 전달

개인화 및 커스터마이징

AI는 사용자별 요청에 적응해 UX를 개선하지만, 이 유연성은 많은 엣지 케이스를 도입합니다. 특별히 지원하고 차단하려는 사용 사례에 대한 evals를 명확히 정의하세요:

모델이 다른 일을 하도록 하는 탈옥(jailbreak) 시도
형식 요청(예: JSON으로 형식화하거나 글머리 기호 사용)
사용자 프롬프트가 시스템 프롬프트와 충돌하는 경우

evals로 성능 개선하기

evals가 성능을 일관되게 측정하는 성숙도에 도달하면, evals 데이터를 사용해 애플리케이션 성능을 개선하는 방향으로 전환하세요.

데이터 플라이휠을 만들려면 강화 파인튜닝에 대해 자세히 알아보세요.

기타 자료

더 많은 아이디어는 예제 코드와 서드파티 리소스 링크가 있는 OpenAI Cookbook을 방문하거나, evals 도구에 대해 자세히 알아보세요:

더 알아보기 (Learn more)

평가 모범 사례 원문