독립적이고 신뢰할 수 있는 제3자 평가(third party evaluations)는 안전 생태계(safety ecosystem)를 강화하는 데 __결정적인 역할__을 합니다. 이러한 평가는 프런티어 모델(frontier models)을 대상으로 수행되며, 핵심 역량 및 안전 완화(safety mitigations)에 대한 주장을 뒷받침하는 추가적인 증거를 제공합니다. 이 포스트에서 우리는 지금까지 배운 교훈을 공유하고, 프런티어 모델을 유효하게 평가할 수 있는 평가 설계 방식을 권장하며, 이것이 이 분야의 신흥 표준(emerging standards)을 형성하는 데 도움이 되기를 바랍니다.

이전에는 많은 평가가 모델을 챗봇(chatbots)처럼 취급했습니다. 즉, 평가자가 사용자가 질문을 던지는 것처럼 모델에 프롬프트(prompt)를 입력하면, 모델이 답변하고, 평가자가 그 출력을 판단하는 방식이었습니다. 오늘날의 프런티어 모델은 훨씬 더 많은 일을 할 수 있습니다. 도구(tools)를 사용할 수 있고, 여러 단계에 걸쳐 정보를 추적할 수 있으며, 더 큰 워크플로(workflow) 내에서 동작할 수 있습니다. 이는 성능이 모델뿐만 아니라 작업이 수행되는 환경과 모델의 행동을 용이하게 하는 설정(setup)에도 의존함을 의미합니다. 우리가 "하네스(harness)"라고 부르는 이 주변 설정은 도구 사용 방식, 정보 추적 방식, 또는 실수로부터의 회복 방식 등 시스템 성능의 핵심적인 측면을 변화시킬 수 있습니다.

이는 평가가 수행되어야 하는 방식과 독자들이 평가 보고서에서 무엇을 살펴봐야 하는지를 변화시킵니다. 우리의 관점에서 가장 유용한 보고서는 결과 자체 외에 다음 두 가지를 명시적으로 설명합니다. 첫째, 평가 설정이 어떤 주장을 테스트하기 위해 설계되었는지 명시해야 하며, 둘째, 평가 결과가 유효하다는 가용한 증거를 공유해야 합니다.

평가에서 테스트되는 주장(Claims)은 일반적으로 다음 세 가지 범주¹ 중 하나에 속합니다:

역량 도출 (Capability elicitation): 모델이 평가 대상이 되는 역량을 타당하게 생성할 수 있는가?
안전 장치 성능 (Safeguard performance): 테스트된 안전 장치(safeguards)가 평가 대상이 되는 행동이나 공격에 대해 얼마나 견고한가?
비교 (Comparison): 서로 다른 모델들이 동일한 조건 하에서 어떻게 성능을 보이는가?

또한 평가 보고서는 평가자가 결과의 유효성에 영향을 미칠 수 있는 효과들을 어떻게 확인했는지 설명해야 합니다. 여기에는 다음이 포함됩니다:

보상 해킹 (Reward hacking): 평가가 측정하고자 하는 행동을 실제로 보여주지 않고도 시스템이 점수를 얻을 수 있도록, 작업(task)이나 채점자(scorer)의 지름길을 악용하는 것.

거부 (Refusals): 테스트 중인 행동을 모호하게 만드는 방식으로 거부하는 것.

오염 (Contamination): 평가 작업, 정답, 또는 이와 유사한 변형들이 훈련 데이터에 포함되어 있었거나 브라우징 등을 통해 평가 과정에서 발견됨으로써 성능이 과도하게 높게 나타나는 것.

결함이 있는 문제 (Broken problems): 작업이 유효하지 않아 성능이 낮게 나타나는 것. 원인으로는 불공정한 채점(예: 정답을 맞히기 위해 명시되지 않은 구현 세부 사항이 필요한 경우)이나 해결 불가능한 환경(예: 중요한 파일 누락 또는 신뢰할 수 없는 도구) 등이 포함될 수 있습니다.

샌드배깅 (Sandbagging): 평가를 받고 있다는 사실을 인지했을 때 의도적으로 낮은 성능을 보이는 것.

우리는 긴 궤적(trajectories)에 걸쳐 작동하는 시스템의 경우 하네스(harness)의 역할이 특히 중요하다는 점을 관찰했습니다. 모델이 도구를 사용하고, 상태(state)를 유지하며, 여러 단계에 걸쳐 실수를 복구할 수 있을 때, 하네스는 관찰되는 성능 수준을 변화시킬 수 있으며, 심지어 평가 대상이 되는 능력이 평가 과정에서 나타날지 여부조차 결정할 수 있습니다. 예를 들어, 상태를 보존하고 실패한 동작을 재시도하는 하네스는, 더 단순한 하네스에서는 결코 완료하지 못했을 다단계 작업을 모델이 완수할 수 있게 해줄 수 있습니다.

아래 표에서는 평가자가 하고자 할 수 있는 세 가지 종류의 주장과, 각 종류의 주장에 필요하다고 판단되는 하네스를 구분하여 정리하였습니다.

| | | |
| :--- | :--- | :--- | :--- |
| 강력한 유도(Strong elicitation) 하의 능력: 시스템 A는 가장 강력하고 신뢰할 수 있는 성능을 끌어내도록 설계된 설정에서 유형 X의 작업을 완료할 수 있다. | 시스템이 가진 역량을 가진 사용자가 합리적으로 사용할 법한 하네스(Harness), 도구(Tools), 스캐폴딩(Scaffolding), 예산(Budget)을 포함하여, 해당 시스템에 대해 가장 강력하고 신뢰할 수 있는 유도(Elicitation) 설정을 사용한다. | 하네스 및 도구 설정, 유도 가이드라인, 허용된 예산/노력, 토큰/비용/시간, 그리고 해당 설정이 주장된 능력에 대한 신뢰할 수 있는 대리 지표(Proxy)인 이유. 서로 다른 최적화된 설정 하에서 시스템을 비교하는 경우, 이를 시스템 간 비교(System-to-system comparison) 또는 강력한 유도 비교(Strong-elicitation comparison)로 라벨링한다. |
| 통제된 비교(Controlled comparison): 시스템 A는 공유된 평가 설정 하에서 시스템 B보다 우수한 성능을 보인다. | 작업(Tasks), 점수 산정(Scoring), 예산을 고정한다. 비교 대상 시스템들에 대해 합리적인 최대 유도(Max elicitation)를 제공할 수 있도록, 공유된 하네스/도구 설정을 사용하거나 사전에 선택된 표준화된 하네스 세트를 사용한다. | 공유된 작업 세트, 도구, 점수 산정 방식, 하네스, 예산, 토큰 효율성/비용, 그리고 알려진 한계점. 코딩 에이전트(Coding-agent) 평가의 경우, Codex CLI와 같은 오픈 소스 하네스를 사용하면 시스템 전반에 걸쳐 고정된 에이전트 루프(Agent loop)와 도구 인터페이스를 제공할 수 있다. 최대 유도를 위한 이상적인 접근 방식은 각 작업과 시스템에 맞춤형 하네스(Bespoke harness)를 최적화하는 것이지만, 현재로서는 실무적으로 불가능하다. |
| 유도된 공격 하의 안전장치 견고성(Safeguard robustness under elicited attack): 시스템 A의 안전장치는 관련 모델 동작 또는 유도된 공격에 대해 충분하다. | 관련 적대적 모델(Adversary model) 하에서 가장 강력하고 신뢰할 수 있는 공격을 유도하도록 설계된 안전장치 테스트 설정을 사용한다. | 평가자가 관련 모델 동작을 어떻게 정의했는지, 테스트된 안전장치 구성, 유도 전략(Elicitation strategy), 이를 수행하기 위해 사용된 하네스, 그리고 허용된 예산 또는 노력. |

역량 주장(Capability claims)은 그 이면에 있는 유도(Elicitation)만큼만 강력합니다. 평가자는 작업과 평가를 통해 측정하려는 역량에 가장 적합한 하네스(Harness)를 선택해야 합니다. 표준화된 하네스는 동일한 조건에서 시스템을 비교하는 데는 적합할 수 있지만, 모델이 작업을 수행하는 데 도움이 되는 특정 하네스 기능을 제외할 경우 역량을 과소평가할 수 있습니다. 예를 들어, OpenAI의 사이버 레인지(Cyber ranges)에서 GPT-5.5의 성능은 하네스 선택이 길고 다단계의 도구 사용(Tool use)을 요구하는 작업에서 측정된 역량을 어떻게 실질적으로 변화시킬 수 있는지 보여줍니다. 상호작용이 길어짐에 따라 하네스가 작업 관련 문맥을 보존하기 위해 __압축(Compaction)__을 사용할 때 모델은 더 나은 성능을 보입니다. 이는 특정 모델의 경우, 압축을 생략한 하네스가 성능 유도(Elicitation)를 저해할 수 있음을 입증합니다.

높은 성공률이 더 좋습니다

다른 발표된 평가²들 또한 하네스와 예산(Budget)의 선택이 평가 결과에 변화를 준다는 것을 보여줍니다. 테스트 시간 연산량(Test-time compute)을 늘리는 것은 평가가 유도하는 역량을 크게 변화시킬 수 있으며, 특히 많은 사이버 작업과 같이 성공 여부를 확인하기 쉬운 도메인에서 더욱 그러합니다. UK AISI의 사이버 레인지 평가(새 창에서 열기)에서는 예산을 1,000만 토큰에서 1억 토큰으로 늘렸을 때 성능이 최대 59% 향상되었으며, 테스트된 가장 높은 예산에서도 성능은 여전히 상승 중이었습니다. 이를 상세히 기술하는 것은 평가의 해석 가능성(Interpretable)을 높여줍니다. 즉, 결과가 테스트된 유도 설정에 어떻게 의존하는지를 독자에게 보여줍니다. 추가 예산에 따라 성능이 여전히 향상되고 있다면, 해당 점수는 측정된 역량의 상한선(Ceiling)이 아니라 해당 하네스와 예산 하에서의 성능으로 기술되어야 합니다. 역량은 한 번에 깔끔하게 측정될 수 있는 고정된 양이라기보다 자원 의존적(Resource-dependent)인 경우가 많습니다. 반복된 시도를 통해 성공을 측정할 수 있는 경우, 보고서는 단순히 고정된 토큰 예산에서의 성공률뿐만 아니라 성공적인 해결당 예상 비용(Expected cost per successful solve)도 고려해야 합니다.

이는 심각도(severity)를 더 쉽게 해석할 수 있게 해줍니다. 반복적인 시도 비용이 관련 위협 모델(threat model) 범위 내에 있다면, 낮은 성공률이라도 실질적으로 의미가 있을 수 있습니다. 능력 주장(capability claims)의 경우, 피할 수 있는 미달 유도(under-elicitation)는 측정 실패에 해당합니다. 만약 하네스(harness)나 예산이 시스템이 원래 생성할 수 있는 행동을 보여주는 것을 방해한다면, 그 점수는 주장된 능력을 측정하는 것이 아닙니다. 평가자가 가능한 한 최대한으로 유도를 시도했음에도 성능이 계속 향상되고 있다면, 보고서는 이를 명확히 명시해야 하며 해당 결과가 하한선 추정치(lower-bound estimate)일 뿐임을 분명히 해야 합니다.

안전 장치 테스트(Safeguard testing)는 맞춤형 하네스(custom harnesses)를 포함하여 공격자가 사용할 수 있는 자원을 고려하지 않을 경우, 공격의 성공 가능성과 그 심각성을 과소평가할 수 있습니다. UK AISI의 GPT-5.5 사이버 평가(UK AISI's GPT-5.5 cyber evaluation)(새 창에서 열기)에서, 전문가 레드팀(red teaming)은 OpenAI가 제공한 악의적인 쿼리 전반에 걸쳐, 멀티턴 에이전트(multi-turn agentic) 설정에서도 위반적인 사이버 콘텐츠를 유도하는 범용 탈옥(universal jailbreak)을 발견했습니다. 그들은 모델의 공격 성능을 강화하기 위해 Codex를 사용하여 맞춤형 하네스를 제작했습니다. 이 하네스는 상호작용 내에 재사용 가능한 안전 장치 우회(safeguard-bypass) 패턴을 삽입하고, 턴과 블록 전반에 걸쳐 해당 패턴을 유지하며, OpenAI가 제공한 악의적인 사이버 쿼리에 이를 적용했습니다. 안전 장치 테스트는 적대자(adversary)와 일치해야 합니다. 만약 주장이 전문가의 오용에 대한 견고성(robustness)에 관한 것이라면, 테스트는 해당 전략을 유지하고 재사용하는 데 필요한 모든 하네스를 포함하여, 정의된 예산 하에서 가장 강력하고 신뢰할 수 있는 엔드 투 엔드(end-to-end) 공격 전략을 평가해야 합니다. 그렇지 않으면 결과가 잘못 보정(miscalibration)될 위험이 있습니다. 즉, 단순한 프롬프팅에 대한 저항력이라는 더 좁은 범위의 주장만을 뒷받침할 수 있고, 유도 방법이 실행 단계(operationalized)에 들어갔을 때 공격이 얼마나 심각해지는지와 성공 확률을 모두 놓칠 수 있으며, 예산이 너무 많이 배정될 경우 문제가 얼마나 발생하기 쉽거나 심각한지를 과장할 수도 있습니다.

표준화된 하네스 (harness) 비교가 필요한 시점과 장소가 있겠지만, 평가자는 일관된 하네스 세트를 사용하는 것이 왜 적절한지, 그리고 그것이 어떤 주장을 뒷받침할 수 있는지에 대해 명확히 밝혀야 합니다. METR의 시간 지평 평가 (time-horizon evaluation)(opens in a new window)는 더 넓고 적절하게 고정된 평가 설정의 한 예입니다. 이는 평가 대상 시스템 전반에 걸쳐 비교 가능한 결과를 생성하도록 설계되었습니다. METR은 공통된 결과물, 즉 AI 에이전트가 특정 신뢰 수준에서 성공할 것으로 예측되는 인간 작업의 전형적인 지속 시간을 정의합니다. METR은 함께 보고되는 추정치 배치 내에서 공유된 작업 세트, 점수 산정 방식, 피팅 방식 (fitting method), 그리고 Triframe 및 ReAct(opens in a new window)와 같은 소수의 재사용 가능한 스캐폴드 (scaffolds)를 적용합니다. METR이 작업 세트를 확장하고 평가 인프라를 Vivaria라는 프레임워크에서 Inspect라는 프레임워크로 옮겼을 때, 해당 변경 사항을 보고하였으며 (Time Horizon 1.1 업데이트(opens in a new window)), 새로운 평가 설정 하에서 모델들을 재평가했습니다. 이것이 일관된 하네스 세트를 포함한 표준화된 평가 설정의 가치입니다. 즉, 점수의 차이가 측정 설정의 변화가 아니라, 비교 대상 시스템 간의 실제 차이를 반영한다는 점을 독자들이 신뢰할 수 있게 해줍니다.

우리는 제3자 평가 보고서가 다음 사항들을 명시할 것을 권장합니다: 평가 설정이 어떤 종류의 주장을 뒷받침하기 위한 것인지 명시할 것; 테스트된 내용이 해당 광범위한 주장을 얼마나 밀접하게 반영하는지 설명할 것; 결과에 영향을 미친 하네스 선택 사항을 설명할 것; 평가 사이에 이러한 선택 사항이 언제 변경되었는지 상세히 기술할 것; 그리고 결과가 어떻게 도출되었는지와 해당 주장에 얼마나 잘 일반화되는지를 보여주는 뒷받침 근거를 포함할 것.

모델의 능력이 향상됨에 따라, 평가 점수(evaluation scores)를 오해하기가 더 쉬워지고 있습니다. 실제 능력과 비교했을 때, 모델이 평가받고 있다는 사실을 인지하고 전략적으로 성능을 낮게 발휘한다면 평가 점수는 인위적으로 낮아질 수 있습니다. 반대로 모델이 작업(task), 프롬프트(prompt), 채점자(scorer), 또는 하네스(harness)의 지름길(shortcut)을 악용한다면 점수는 부풀려질 수 있습니다. 또한 오염(contamination, 모델이 작업을 해결하지 않고도 이미 답을 알고 있거나 찾아낼 수 있는 상태)이나, 모호하고, 잘못 채점되었거나, 해결 불가능하거나, 의도치 않은 지름길에 취약한 "결함이 있는(broken)" 문제들에 의해 점수가 왜곡될 수도 있습니다. 따라서 평가 보고서는 독자가 점수가 의도된 동작을 반영하는지 판단할 수 있도록, 헤드라인 점수와 함께 이러한 위험 요소들에 대한 논의를 반드시 병행해야 합니다.

하네스(Harnesses), 예산(budgets), 도구(tools), 채점 규칙(scoring rules), 모니터(monitors), 그리고 검토 절차(review procedures)는 모두 에이전트가 의도된 작업을 수행하고 있는지, 작업을 회피하고 있는지, 암기하고 있는지, 혹은 우회 경로를 찾고 있는지에 영향을 미칩니다. 신뢰할 수 있는 보고서는 이러한 확인 사항들을 가시화합니다. 즉, 평가자는 평가가 실행될 때마다 이러한 동작들이 나타나는지 샘플을 검토해야 합니다.

보상 해킹 (Reward hacking)