OpenAI는 프런티어 모델(frontier-model) 평가에 대해 더 넓은 관점을 가질 것을 촉구하고 있습니다. 벤치마크 결과는 테스트 대상인 모델뿐만 아니라, 모델을 테스트하는 데 사용되는 주변 시스템도 반영하기 때문입니다. OpenAI는 신뢰할 수 있는 제3자 평가를 위한 공식 플레이북에서 API 설정, 프롬프팅 (prompting), 도구 액세스 (tool access), 상태 관리 (state management), 컴퓨팅 예산 (compute budgets), 점수 산정 (scoring), 그리고 하네스 설계 (harness design)가 모델의 능력과 안전성에 대한 결론에 실질적인 영향을 미칠 수 있다고 밝혔습니다.

이러한 프레임워크는 평가가 고립된 텍스트 생성보다는 점점 더 **에이전트적이고 도구를 사용하는 시스템 (agentic, tool-using systems)**을 평가하게 됨에 따라 중요해지고 있습니다. 모델은 도구를 사용할 수 있거나, 상태를 유지 또는 압축하거나, 다른 프롬프트를 받거나, 다른 예산 하에서 작동할 때 서로 다른 성능을 보일 수 있습니다. OpenAI의 핵심 주장은 평가자가 이러한 선택 사항들을 가시화하고, 그 타당성을 테스트하며, 평가가 실제로 측정하는 바에 맞춰 주장을 보정해야 한다는 것입니다.

하네스가 결과의 일부인 이유

하네스(harness)는 모델을 둘러싼 평가 환경을 의미합니다. 여기에는 모델에 제공되는 프롬프트와 지침, 모델이 호출할 수 있는 도구, 상태 관리 방식, 계산 또는 시도 횟수에 대한 제한, 그리고 출력을 점수화하는 데 사용되는 메커니즘 등이 포함될 수 있습니다. 이러한 선택 사항들은 평가자가 관찰하는 행동에 영향을 미치기 때문에 단순히 구현 세부 사항에 불과한 것이 아닙니다.

OpenAI는 GPT-5.5 사이버 레인지(cyber-range) 작업의 맥락에서 이 문제를 강조하며, 압축(compaction) 및 기타 하네스 기능이 관찰된 성능을 실질적으로 변화시킬 수 있다고 설명합니다. 더 넓은 의미에서의 시사점은 특정 설정이 항상 옳다는 것이 아닙니다. 대신, 결과가 도출된 조건이 무엇인지, 그리고 그 조건이 제기된 주장과 부합하는지를 독자가 이해할 수 있도록 충분한 방법론적 맥락이 제공되어야 한다는 것입니다.

개발자들에게 이는 벤치마크 점수를 배포 환경 전반에 걸쳐 자동으로 전이되는 속성으로 취급해서는 안 된다는 실질적인 경고입니다. 프로덕션 시스템(Production systems)은 고유의 프롬프트(Prompts), 도구 권한(Tool permissions), 워크플로 제약 조건(Workflow constraints), 재시도 동작(Retry behavior), 그리고 리소스 제한(Resource limits)을 가지고 있습니다. 한 환경에서의 강력한 결과가 다른 환경에서의 성능을 설명하지 못할 수도 있습니다.

보편적 설정이 아닌, 보고 프레임워크

이 간행물은 모든 개발자가 채택해야 하는 고정된 하네스 설정의 공개 카탈로그를 약속하지 않습니다. 이는 서로 다른 작업과 리스크 모델 전반에 걸쳐 정당화하기 어려울 것이기 때문입니다. 이 문서의 강조점은 투명한 보고와 표준화된 관행에 있습니다. 즉, 평가자는 자신의 하네스, 예산, 도구, 점수 산정 방식(Scoring approach), 도출 방법(Elicitation method), 그리고 관련 유효성 검사(Validity checks)를 문서화해야 합니다.

OpenAI는 또한 벤치마크가 엄격해 보일 때조차 결론을 약화시킬 수 있는 평가 리스크를 식별합니다. 여기에는 보상 해킹(Reward hacking), 오염(Contamination), 거부(Refusals), 깨진 문제(Broken problems), 그리고 샌드배깅(Sandbagging)이 포함됩니다. 이러한 리스크를 보고함으로써 독자에게 단일 점수를 모델 동작의 완전한 설명으로 취급하게 하는 대신, 평가가 무엇을 뒷받침할 수 있는지에 대한 더 명확한 관점을 제공합니다.

이 접근 방식은 서로 관련되어 있지만 구별되는 세 가지 유형의 주장을 분리합니다:

• 능력 도출 (Capability elicitation): 평가가 모델의 관련 성능을 성공적으로 끌어내는지 여부.
• 안전 장치 성능 (Safeguard performance): 테스트된 조건 하에서 시스템의 보호 기능이 어떻게 작동하는지에 관한 것.
• 비교 (Comparisons): 하나의 모델이나 설정을 다른 것과 비교하여 판단할 때 주의가 필요한 부분.

그러한 구분은 제3자 평가(third-party evaluations)의 유용성을 향상시킬 수 있습니다. 최대 능력을 이끌어내도록 설계된 테스트가 반드시 일반적인 제품 동작에 대한 평가와 동일한 것은 아닙니다. 마찬가지로, 비교(comparison)는 시스템이 테스트된 환경의 일관성과 공개 여부에 따라 해석 가능성이 결정됩니다.

평가자에 대한 OpenAI의 명시적 약속

OpenAI는 이 플레이북을 프런티어 모델(frontier-model)의 평가 및 보고에 대한 투명성과 표준을 개선하기 위한 광범위한 노력의 일환으로 자리매김하고 있습니다. 회사는 Codex를 공통 기준선(common baseline)으로 사용할 것이며, 적절한 경우 추론 흔적(reasoning traces)과 같은 중간 산출물(intermediate artifacts)을 제공할 것이라고 밝혔습니다.

이러한 약속은 더 재현 가능한(reproducible) 평가 작업을 지향하지만, 동시에 중요한 구현 세부 사항들은 열어두고 있습니다. 이 간행물은 단일한 보편적 하네스(universal harness)를 설정하거나, 모든 산출물을 모든 맥락에서 공유할 수 있다고 규정하지 않습니다. 명시된 방향은 평가자들에게 더 강력한 가이드라인, 공통 참조점, 그리고 적절한 경우 더 많은 문서를 제공하는 것입니다.

AI 제품을 구축하는 팀에게 즉각적인 교훈은 평가 구성(evaluation configuration)을 시스템 설계의 일부로 취급해야 한다는 것입니다. 내부 테스트는 결과를 생성한 프롬프트(prompts), 도구(tools), 예산(budgets), 상태 동작(state behavior) 및 점수 산정 로직(scoring logic)을 기록해야 합니다. 새로운 모델을 평가하는 조직은 외부 벤치마크(external benchmark)를 사용하여 조달, 안전 또는 배포 결정을 내리기 전에 해당 벤치마크가 이러한 세부 사항을 보고하는지 확인할 수도 있습니다.

모델 평가를 프로덕션 워크플로(production workflows)로 전환해야 하는 조직은 실제 운영 환경의 제약 조건을 고려한 AI 아키텍처, 자동화 설계 및 구현에 대해 Scalevise와 협력할 수 있습니다.

자주 묻는 질문 (Frequently Asked Questions)

왜 OpenAI는 하네스(harness) 설계가 모델 평가에 영향을 미친다고 말하나요?

하네스(harness)는 프롬프트(prompts), 도구(tools), 상태 관리(state management), 예산(budgets), 그리고 점수 산정(scoring)을 포함하여 모델 주변의 조건들을 제어합니다. 이러한 조건들은 평가자가 관찰하는 성능 및 안전성 결과에 영향을 미칠 수 있습니다.

평가자는 모델 테스트에 대해 무엇을 공개해야 합니까?

OpenAI는 하네스(harness), 예산(budget), 도구(tools), 점수 산정(scoring), 유도 방식(elicitation approach), 그리고 관련 유효성 리스크(validity risks)를 포함한 평가 설정(evaluation setup)을 문서화할 것을 권장합니다.

OpenAI가 권장하는 단일한 하네스 설정 세트가 있습니까?

아니요. 이 간행물은 공개적이고 보편적인 고정된 하네스 설정 세트보다는 투명한 보고, 평가자 가이드라인, 그리고 표준화된 관행을 강조합니다.

OpenAI가 식별한 평가의 유효성 리스크(validity risks)는 무엇입니까?

플레이북은 결과 해석 방식에 영향을 미칠 수 있는 리스크로 보상 해킹(reward hacking), 오염(contamination), 거부(refusals), 깨진 문제(broken problems), 그리고 샌드배깅(sandbagging)을 식별합니다.

결론

OpenAI의 플레이북은 모델 평가를 모델 자체와 그 주변에 구축된 환경 모두에 대한 측정으로 재정의합니다. 하네스(harness) 선택, 유효성 검사(validity checks), 그리고 주장 유형(claim types)에 대한 더 명확한 공개를 요구함으로써, 이 회사는 제3자 평가가 실제 배포 결정에 더 해석 가능하고, 비교 가능하며, 유용한 결과로 이어지도록 추진하고 있습니다.