실증적 성능 평가
코드 예제로 바로 가려면 evals 쿡북을 확인하세요.
Claude를 최적화하여 작업에서 가능한 최고의 정확도를 제공하는 것은 경험적 과학이자 지속적인 개선 과정입니다. 프롬프트 변경이 Claude의 성능을 향상시켰는지 확인하려는 경우, 서로 다른 Claude 모델을 테스트하는 경우 또는 사용 사례가 프로덕션 준비가 되었는지 평가하는 경우, 잘 설계된 평가 시스템은 성공에 매우 중요합니다.
이 가이드에서는 프롬프트 개발 수명 주기, 다양한 유형의 평가(evals), 장단점을 살펴보고 사용 사례에 가장 적합한 평가를 선택하는 방법에 대한 지침을 제공합니다.
평가 사용 방법
LLM로 작업할 때 평가는 전체 프로덕션 수명 주기의 필수적인 부분이 되어야 합니다. 평가는 진행 상황을 추적하고, 문제를 식별하며, 데이터 기반 결정을 내리는 데 사용할 수 있는 정량적 성능 측정 기준을 제공합니다. 다음은 프로덕션 수명 주기의 다양한 단계에서 평가가 어떻게 적용되는지 보여줍니다:
- 프롬프트 엔지니어링: 프롬프트 엔지니어링 프로세스는 프롬프트를 작성하는 것이 아니라 엄격한 평가 세트를 구축하는 것부터 시작해야 합니다. 이러한 평가는 프롬프트의 효과를 측정하는 기반이 되며 시간이 지남에 따라 반복하고 개선하는 데 도움이 됩니다.
- 개발: Claude를 사용하여 애플리케이션이나 워크플로를 개발할 때 프롬프트 엔지니어링 단계에서 설계한 평가를 사용하여 프롬프트 자체가 변경되지 않은 경우에도 프롬프트의 성능을 정기적으로 테스트하세요. 프롬프트 외부 및 다운스트림의 워크플로 부분이 모델 성능에 영향을 줄 수 있습니다. 이를 통해 초기에 문제를 발견하고 워크플로가 예상대로 수행되고 있는지 확인할 수 있습니다.
- 최종 테스트: 애플리케이션이나 워크플로를 프로덕션에 배포하기 전에 개발 단계에서 사용하지 않은 평가 세트를 하나 이상 만드세요. 이 보류된 평가 세트는 프롬프트의 실제 성능을 평가하고 개발 중에 사용된 평가에 과적합되지 않았는지 확인하는 데 도움이 됩니다.
- 프로덕션: 애플리케이션이나 워크플로가 프로덕션에 배포되면 평가를 계속 사용하여 성능을 모니터링하고 잠재적인 문제를 식별하세요. 또한 평가를 사용하여 다양한 Claude 모델이나 프롬프트 버전의 성능을 비교하고 업데이트 및 개선에 대한 데이터 기반 결정을 내릴 수 있습니다.
프로덕션 수명 주기 전반에 걸쳐 평가를 통합함으로써 프롬프트가 최적으로 수행되고 애플리케이션이나 워크플로가 최상의 결과를 제공하도록 할 수 있습니다.
평가의 구성 요소
평가에는 일반적으로 네 가지 부분이 있습니다:
- 입력 프롬프트: 모델에 입력되는 프롬프트입니다. Claude는 이 프롬프트를 기반으로 완성(출력이라고도 함)을 생성합니다. 평가를 설계할 때 입력 열에는 테스트 시점에 프롬프트 템플릿에 입력되는 가변 입력 세트가 포함되는 경우가 많습니다.
- 출력: 입력 프롬프트를 평가 중인 모델에 실행하여 생성된 텍스트입니다.
- 정답: 모델 출력과 비교되는 올바른 답변입니다. 정답은 필수적인 정확한 일치일 수도 있고, 채점자(사람 또는 LLM)에게 점수 비교 기준을 제공하기 위한 완벽한 답변의 예시일 수도 있습니다.
- 점수: 아래에서 설명하는 채점 방법 중 하나에 의해 생성되는 숫자 값으로, 모델이 질문에 얼마나 잘 수행했는지를 나타냅니다.
평가 채점 방법
평가에서 시간이 많이 걸리고 비용이 많이 드는 두 가지 측면은 질문 및 정답 쌍을 작성하는 것과 채점하는 것입니다. 질문과 정답을 작성하는 것은 일반적으로 일회성 고정 비용이지만, 채점은 평가를 자주 다시 실행할 때마다 발생하는 비용입니다. 따라서 빠르고 저렴하게 채점할 수 있는 평가를 구축하는 것이 설계 선택의 중심이 되어야 합니다.
평가를 채점하는 일반적인 방법은 세 가지가 있습니다:
- 코드 기반 채점: 표준 코드(주로 문자열 일치 및 정규 표현식)를 사용하여 모델의 출력을 채점하는 것을 포함합니다. 일반적인 버전으로는 답변과 정확히 일치하는지 확인하거나 문자열에 일부 핵심 구문이 포함되어 있는지 확인하는 것이 있습니다. 이는 평가가 이를 허용하는 경우 가장 좋은 채점 방법이며, 빠르고 매우 신뢰할 수 있습니다. 그러나 많은 평가에서는 이러한 스타일의 채점을 허용하지 않습니다.
- 사람 채점: 사람이 모델이 생성한 답변을 보고 정답과 비교하여 점수를 부여합니다. 이는 거의 모든 작업에 사용할 수 있는 가장 유능한 채점 방법이지만, 특히 대규모 평가를 구축한 경우 매우 느리고 비용이 많이 듭니다. 가능하면 사람 채점이 필요한 평가를 설계하는 것을 대부분 피해야 합니다.
- 모델 기반 채점: Claude는 자체 채점 능력이 뛰어나며 창의적인 글쓰기의 어조 분석이나 자유 형식 질문 답변의 정확성과 같이 과거에는 사람이 필요했을 수 있는 다양한 작업을 채점하는 데 사용할 수 있습니다. 이는 Claude에 대한 채점자 프롬프트를 작성하여 수행할 수 있습니다.
평가 유형
Claude의 작업 수행 능력을 측정하는 데 사용할 수 있는 여러 유형의 평가가 있습니다. 각 유형에는 고유한 장단점이 있습니다.
| 평가 유형 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 객관식 문항 (MCQ) | 답안 중 하나 이상이 정답인 폐쇄형 문항 | - 자동화하기 쉬움- 주제에 대한 일반적인 지식 평가- 명확한 정답 키- 정확한 모습을 알기 쉬움 | - 테스트가 공개된 경우 잠재적인 학습 누출- 더 복잡하거나 개방형 작업 평가에 제한적 |
| 정확한 일치 (EM) | 모델의 답변이 정답과 정확히 동일한 문자열인지 확인 | - 자동화하기 쉬움- 특정 지식이나 작업 평가에서 높은 정밀도- 정확한 모습을 알기 쉬움 | - 더 복잡하거나 개방형 작업 평가에 제한적- 정답의 변형을 포착하지 못할 수 있음 |
| 문자열 일치 | 모델의 답변에 정답 문자열이 포함되어 있는지 확인 | - 자동화하기 쉬움- 모델 출력에서 특정 정보의 존재 평가 | - 모델 응답의 전체 맥락이나 의미를 포착하지 못할 수 있음- 거짓 양성 또는 음성을 초래할 수 있음 |
| 개방형 답변 (OA) | 여러 가지 가능한 해결책이 있거나 평가하기 위해 다단계 프로세스가 필요한 개방형 질문 | - 고급 지식, 암묵적 지식 또는 정성적 개방형 성능 평가에 적합- 사람 또는 모델에 의해 채점될 수 있음 | - 자동화하기 더 어려움- 채점을 위한 명확한 기준 필요- 모델 기반 채점이 사람 채점보다 정확도가 떨어질 수 있음 |
평가 설계를 위한 모범 사례
특정 사용 사례에 대한 평가를 설계할 때는 다음과 같은 모범 사례를 염두에 두세요:
- 작업별 평가: 가능한 경우 평가를 작업에 맞게 구체화하고 평가의 분포가 실제 질문 및 질문 난이도의 분포를 나타내도록 하세요.
- 모델 기반 채점 테스트: 모델 기반 채점자가 작업을 잘 채점할 수 있는지 알 수 있는 유일한 방법은 직접 시도해 보고 일부 샘플을 읽어 작업이 적합한 후보인지 확인하는 것입니다.
- 가능한 경우 자동화: 종종 영리한 설계를 통해 평가를 자동화할 수 있습니다. 작업에 충실하면서도 자동 채점이 가능하도록 질문을 구조화하세요. 질문을 객관식으로 재구성하는 것이 일반적인 전술입니다.
- 품질보다 양을 우선시: 일반적으로 매우 적은 양의 고품질 질문보다는 더 많은 양의 낮은 품질 질문을 선호하세요.
- 평가 쿡북 사용: 평가 쿡북에서는 지침과 복사할 수 있는 코드를 포함하여 사람과 모델이 채점하는 다양한 유형의 평가에 대한 구현 예제를 제공합니다.
이러한 모범 사례를 따르고 사용 사례에 적합한 평가 유형을 선택함으로써 Claude의 성능을 효과적으로 측정하고 프롬프트와 워크플로를 개선하기 위한 데이터 기반 결정을 내릴 수 있습니다.