평가 모범 사례

생성형 AI는 같은 입력에도 다른 출력을 내놓을 수 있습니다. 그래서 기존 소프트웨어 테스트 방식만으로는 AI 아키텍처를 충분히 검증하기 어렵습니다. 평가(evals)를 활용하면 이러한 변동성을 고려하면서 AI 시스템을 테스트할 수 있습니다.

이 가이드에서는 평가 설계의 기본 원칙을 설명합니다. Evals API를 처음 사용한다면 모델 성능 평가를 참고하세요.

평가란 무엇인가요?

평가는 모델의 성능을 측정하는 구조화된 테스트입니다. AI 시스템이 비결정적으로 동작하더라도 평가를 통해 정확도, 성능, 신뢰성을 확보할 수 있습니다. 또한 평가는 LLM 기반 애플리케이션의 성능을 개선하는 몇 안 되는 방법 중 하나로, 파인튜닝에 활용할 수 있습니다.

평가의 유형

“평가”는 문맥에 따라 다음을 가리킬 수 있습니다.

• MMLU나 HuggingFace 리더보드에 나열된 벤치마크처럼 모델 자체의 성능을 비교하는 업계 벤치마크
• ROUGE, BERTScore처럼 사용 사례에 맞는 평가를 설계할 때 활용할 수 있는 표준 정량 지표
• LLM 애플리케이션의 성능을 측정하기 위해 직접 구현하는 테스트

이 가이드에서는 세 번째 유형인 자체 평가 설계를 다룹니다.

평가 결과 해석하기

평가 점수는 흔히 0과 1 사이의 값으로 표시됩니다. 하지만 점수만으로 평가 결과를 충분히 해석하기는 어렵습니다. 지표와 사람의 판단을 함께 활용해 실제로 알고 싶은 것을 측정하고 있는지 확인하세요.

평가 절차 설계하기

평가 워크플로우의 주요 단계는 다음과 같습니다.

1. 평가 목표 정의. 평가의 성공 기준은 무엇인가요?
2. 데이터셋 수집. 목표 달성 여부를 평가하는 데 어떤 데이터가 필요한가요? 합성 평가 데이터, 도메인별 평가 데이터, 구매한 평가 데이터, 사람이 선별한 평가 데이터, 프로덕션 데이터, 과거 데이터를 고려하세요.
3. 평가 지표 정의. 성공 기준을 충족했는지 어떻게 확인할 것인가요?
4. 평가 실행 및 결과 비교. 평가와 개선을 반복해 작업이나 시스템에 필요한 모델 성능을 높이세요.
5. 지속적인 평가. 변경이 있을 때마다 평가를 실행하도록 지속적 평가(CE)를 설정하세요. 앱을 모니터링해 비결정적 동작이 나타나는 새로운 사례를 찾고 평가 사례를 꾸준히 늘리세요.

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

예시: 대화록 요약

LLM 기반 애플리케이션이 대화록을 얼마나 잘 요약하는지 테스트하려면 다음과 같이 평가를 설계할 수 있습니다.

1. 평가 목표 정의
   모델이 생성한 요약은 관련성과 정확성 면에서 기준 요약에 견줄 만해야 합니다.
2. 데이터셋 수집
   생성된 요약에 대한 사용자 피드백에서 수집한 프로덕션 데이터와 도메인 전문가(작가)가 만든 데이터셋을 함께 사용해 어떤 요약이 “좋은 요약”인지 판단하세요.
3. 평가 지표 정의
   평가용으로 따로 남겨 둔 대화록과 기준 요약 1,000쌍에서 구현한 시스템의 ROUGE-L 점수가 0.40 이상이고 G-Eval로 측정한 일관성 점수가 80% 이상이어야 합니다.
4. 평가 실행 및 결과 비교
   Evals API를 사용해 OpenAI 대시보드에서 평가를 만들고 실행하세요.
5. 지속적인 평가
   변경이 있을 때마다 평가를 실행하도록 지속적 평가(CE)를 설정하세요. 앱을 모니터링해 비결정적 동작이 나타나는 새로운 사례를 찾고 평가 사례를 꾸준히 늘리세요.

예시: 문서 기반 질의응답

LLM 기반 애플리케이션이 문서를 바탕으로 질문에 얼마나 잘 답하는지 테스트하려면 다음과 같이 평가를 설계할 수 있습니다.

1. 평가 목표 정의
   모델은 사용자 프롬프트를 바탕으로 추론할 때 필요한 컨텍스트를 찾아 활용하고, 사용자의 요구를 충족하는 정확한 답변을 제공해야 합니다.
2. 데이터셋 수집
   질문에 대한 사용자의 답변 만족도를 바탕으로 수집한 프로덕션 데이터, 도메인 전문가가 작성한 질문에 대해 미리 입력해 둔 정답, 로그에서 수집한 과거 데이터를 함께 사용하세요.
3. 평가 지표 정의
   컨텍스트 재현율은 0.85 이상, 컨텍스트 정밀도는 0.7 초과, 긍정적인 평가를 받은 답변의 비율은 70% 이상이어야 합니다.
4. 평가 실행 및 결과 비교
   Evals API를 사용해 OpenAI 대시보드에서 평가를 만들고 실행하세요.
5. 지속적인 평가
   변경이 있을 때마다 평가를 실행하도록 지속적 평가(CE)를 설정하세요. 앱을 모니터링해 비결정적 동작이 나타나는 새로운 사례를 찾고 평가 사례를 꾸준히 늘리세요.

평가가 필요한 지점 찾기

기본 아키텍처에서 여러 단계나 에이전트를 사용하는 아키텍처로 확장하면 시스템의 복잡도가 높아집니다. 흔히 쓰이는 아키텍처 패턴은 다음 네 가지입니다.

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

아래에서 각 아키텍처를 살펴보고 시스템의 어느 지점에서 비결정성이 발생하는지 확인하세요. 그 지점에 평가를 구현하면 됩니다.

단일 턴 모델 상호작용

이 아키텍처에서는 사용자가 모델에 입력을 제공하면 모델이 해당 입력과 개발자가 제공한 프롬프트를 함께 처리해 그에 맞는 출력을 생성합니다.

예시

온라인 쇼핑몰을 예로 들어 보겠습니다. 시스템 프롬프트는 고객의 질문을 분류하도록 모델에 지시합니다. 각 질문은 다음 범주 중 하나로 분류합니다.

• order_status
• return_policy
• technical_issue
• cancel_order
• other

일관되고 효율적인 사용자 경험을 제공하려면 모델이 사용자의 의도에 맞는 라벨만 반환해야 합니다. 고객이 “제 주문은 지금 어떤 상태인가요?”라고 물었다고 가정해 보세요.

워크플로우 아키텍처

더 복잡한 문제를 해결하다 보면 단일 턴 모델 상호작용에서 여러 모델 호출을 연결하는 다단계 워크플로우로 전환하게 될 수 있습니다. 워크플로우에서 새로운 유형의 비결정성이 생기지는 않지만, 그 안에서 모델과 여러 차례 상호작용하므로 각 상호작용을 개별적으로 평가할 수 있습니다.

예시

앞서처럼 고객이 주문 상태를 문의한다고 가정해 보세요. 워크플로우 아키텍처에서는 고객의 요청을 분류한 다음 아래 단계를 거쳐 처리합니다.

1. 주문 ID 추출
2. 주문 상세 정보 조회
3. 최종 답변을 생성할 모델에 주문 상세 정보 전달

이 워크플로우의 각 단계에는 모델이 따라야 하는 시스템 프롬프트가 있습니다. 모델은 이 지시에 따라 조회한 정보를 모두 담아 고객이 이해하기 쉬운 답변을 작성합니다.

단일 에이전트 아키텍처

워크플로우와 달리 에이전트는 상황에 맞게 판단해야 하는 비정형 문제를 해결합니다. 에이전트는 주어진 지시와 도구를 바탕으로 상황에 따라 사용할 도구를 선택합니다. 이 선택 과정에서 새로운 비결정성이 발생할 수 있습니다.

예시

앞의 고객 서비스 예시를 단일 에이전트 방식으로 바꿔 보겠습니다. 에이전트는 다음 세 가지 도구를 사용할 수 있습니다.

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

고객이 주문 상태를 문의하면 에이전트는 상황에 따라 도구를 호출할지, 고객에게 직접 답할지 결정합니다. 예를 들어 고객이 “제 주문은 지금 어떤 상태인가요?”라고 물으면 에이전트가 고객에게 주문 ID를 알려 달라고 요청할 수 있습니다. 이렇게 하면 대화가 더 자연스럽게 이어집니다.

다중 에이전트 아키텍처

단일 에이전트 아키텍처에 도구와 작업을 추가하다 보면 모델이 지시를 따르거나 호출할 도구를 올바르게 선택하는 데 어려움을 겪을 수 있습니다. 다중 에이전트 아키텍처에서는 서로 다른 영역을 전담하는 에이전트를 여러 개 두어 이 문제를 완화합니다. 여러 에이전트가 요청을 분류하고 서로 인계하는 과정에서 새로운 비결정성이 발생할 수 있습니다.

예시

단일 에이전트 예시를 다중 에이전트 아키텍처로 나누면 다음 네 에이전트가 각각의 역할을 맡습니다.

1. 요청 분류 에이전트
2. 주문 에이전트
3. 계정 관리 에이전트
4. 판매 에이전트

고객이 주문 상태를 문의하면 요청 분류 에이전트가 주문 에이전트에 대화를 넘겨 주문을 조회하도록 할 수 있습니다. 고객이 화제를 바꿔 제품에 관해 질문하면 주문 에이전트는 요청을 다시 요청 분류 에이전트에 넘겨야 합니다. 그러면 요청 분류 에이전트가 판매 에이전트에 요청을 넘겨 제품 정보를 조회하도록 합니다.

다양한 유형의 평가기 만들고 조합하기

자체 평가를 설계할 때는 여러 유형의 평가기 중에서 선택할 수 있습니다. 평가기에 어떤 역할을 맡길지 생각하면 유형을 선택하는 데 도움이 됩니다.

지표 기반 평가

정량 평가는 결과를 필터링하거나 순위를 매기는 데 사용할 수 있는 점수를 제공합니다. 이 점수는 자동 회귀 테스트의 기준으로 활용하기 좋습니다.

• 예시: 완전 일치, 문자열 일치, ROUGE/BLEU 점수, 함수 호출 정확도, 실행 기반 평가(예: text2sql에서처럼 결과를 실행해 기능이나 동작을 평가하는 방식)
• 한계: 특정 사용 사례에 잘 맞지 않거나 미묘한 차이를 놓칠 수 있습니다.

사람에 의한 평가

사람이 직접 판단하면 평가 품질이 가장 높지만 시간과 비용이 많이 듭니다.

• 예시: 시스템 출력을 훑어보며 품질이 좋아졌는지 나빠졌는지 파악합니다. 또는 직원, 계약직 인력, 외부 라벨링 업체가 시스템 출력의 품질을 판단하는 무작위 블라인드 테스트를 설계합니다. 예를 들어 몇 개의 후보 출력에 순위를 매기거나 각각에 1~5점을 줄 수 있습니다.
• 한계: 전문가마다 판단이 다를 수 있고 비용과 시간이 많이 듭니다.
• 권장 사항:
  • 사람이 여러 차례 상세히 검토한 결과를 바탕으로 평가표를 다듬으세요.
  • 점수 기준을 말로만 설명하지 말고 점수대별 예시를 보여 주세요(예: 10점 만점에서 1점, 3점, 8점에 해당하는 출력).
  • 점수와 함께 통과 여부를 가르는 기준도 명시하세요.
  • 여러 검토자의 판단을 종합하려면 투표로 의견을 모을 수 있습니다.

LLM을 평가자로 활용하는 방법과 모델 기반 채점기

모델로 출력을 평가하면 사람이 직접 평가할 때보다 비용이 적게 들고 평가 규모를 늘리기도 쉽습니다. 평가 능력이 뛰어난 LLM이 필요하다면 gpt-6-astra부터 사용해 보세요. 비용이나 지연 시간을 최적화하기 전에 평가 결과가 사람이 부여한 라벨과 일치하는지 검증하세요.

• 예시:
  • 쌍대 비교: 평가 모델에 두 답변을 제시하고 구체적인 기준에 따라 어느 쪽이 더 나은지 판단하도록 합니다.
  • 개별 답변 채점: 평가 모델이 하나의 답변을 독립적으로 평가하고 미리 정한 품질 지표에 따라 점수나 등급을 부여합니다.
  • 기준 답변을 활용한 채점: 평가 모델에 기준이 되는 답변이나 모범 답안을 제공하고 이를 기준으로 주어진 답변을 평가하도록 합니다.
• 한계: 위치 편향(답변을 제시한 순서에 영향을 받음)과 장황성 편향(더 긴 답변을 선호함)이 나타날 수 있습니다.
• 권장 사항:
  • 평가의 신뢰성을 높이려면 쌍대 비교나 통과 여부 판정을 사용하세요.
  • 가능하면 성능이 가장 뛰어난 모델로 채점하세요. 먼저 gpt-6-astra로 채점한 다음, 특화된 추론 모델이 해당 채점 기준이나 기준 답변 세트에서 더 나은 성능을 보이는지 검증하세요.
  • LLM은 대체로 긴 답변을 선호하므로 답변 길이가 평가에 미치는 영향을 통제하세요.
  • 채점 전에 추론하고 그 추론 과정을 제시하도록 하세요. 먼저 추론하면 평가 성능이 향상됩니다.
  • LLM 평가자가 사람보다 빠르고 비용이 적게 들면서도 사람이 부여한 라벨과 일관되게 같은 판단을 내리면 평가 규모를 확대하세요.
  • 평가하려는 작업의 취지를 유지하면서 자동 채점이 가능하도록 질문을 구성하세요. 질문을 객관식으로 바꾸는 방법이 흔히 쓰입니다.
  • 채점 기준을 명확하고 구체적으로 작성하세요.

어떤 전략에도 한계는 있습니다. LLM을 평가자로 활용할 때는 문제의 맥락에 따라 평가 품질이 달라지고, 전문가가 직접 정답 라벨을 작성하려면 비용과 시간이 많이 듭니다.

경계 사례 다루기

평가에는 각 아키텍처에서 주요 작업이 정상적으로 처리되는 시나리오가 포함되어야 합니다. 실제 환경에서는 AI 시스템이 제 성능을 내기 어려운 경계 사례도 자주 발생합니다. 신뢰성과 좋은 사용자 경험을 확보하려면 이런 사례도 평가해야 합니다.

경계 사례는 몇 가지 유형으로 나눌 수 있습니다.

입력의 다양성

모델에 입력을 제공하는 주체는 사용자이므로 시스템은 다음과 같은 다양한 입력 방식에 유연하게 대응해야 합니다.

• 영어 이외의 언어로 작성되거나 여러 언어가 섞인 입력
• 일반 텍스트 이외의 형식(예: XML, JSON, Markdown, CSV)
• 다양한 입력 모달리티(예: 이미지)

지시 준수와 기능적 정확성을 평가할 때는 사용자가 실제로 시도할 만한 입력을 포함하세요.

복잡한 컨텍스트

많은 LLM 기반 애플리케이션은 요청의 컨텍스트를 제대로 이해하지 못해 작업에 실패합니다. 사용자가 제공한 컨텍스트 자체가 복잡할 수도 있고, 이전 대화 기록에 불필요한 정보가 섞여 있을 수도 있습니다.

예를 들면 다음과 같습니다.

• 한 요청에 여러 질문이나 의도가 담긴 경우
• 오타나 철자 오류가 있는 경우
• 컨텍스트가 거의 없는 짧은 요청(예: 사용자가 “반품”이라고만 입력한 경우)
• 컨텍스트가 길거나 대화가 오래 이어지는 경우
• 도구 호출로 반환된 데이터의 속성 이름이 모호한 경우(예: "on: 123"에서 “on”이 주문 번호를 의미하는 경우)
• 도구를 여러 번 호출하는 경우. 이 과정에서 잘못된 인수를 전달할 수 있습니다.
• 에이전트 간 인계가 여러 번 일어나는 경우. 요청이 이전 에이전트로 되돌아가 인계가 반복될 수 있습니다.

개인화 및 맞춤 설정

AI는 사용자별 요청에 맞게 동작해 사용자 경험을 개선하지만, 이러한 유연성 때문에 다양한 경계 사례가 발생합니다. 어떤 사용 사례를 지원하고 어떤 사례를 차단할지 구체적으로 정하고 각각에 대한 평가를 명확히 정의하세요.

• 모델이 의도와 다른 행동을 하도록 유도하는 탈옥 시도
• 출력 형식에 관한 요청(예: JSON 형식이나 글머리 기호 목록으로 작성해 달라는 요청)
• 사용자 프롬프트가 시스템 프롬프트와 충돌하는 경우

평가를 활용해 성능 개선하기

평가 체계가 충분히 성숙해 성능을 일관되게 측정할 수 있게 되면 평가 데이터를 활용해 애플리케이션 성능을 개선하세요.

기타 자료

더 많은 아이디어가 필요하다면 예제 코드와 외부 자료 링크를 제공하는 OpenAI Cookbook을 살펴보세요. 평가 도구에 관한 자세한 내용은 다음 자료를 참고하세요.

• 모델 성능 평가
• 요약 작업을 평가하는 방법
• 파인튜닝
• 채점기
• Evals API 레퍼런스