기술 요약: 코드 RL 학습 환경에서의 보상 해킹 가능성(Reward Hackability) 감사

1. 문제 정의

코드 생성에서의 실행 피드백 기반 강화학습(RLFE)은 검증기(테스트 스위트)의 정확성에 전적으로 의존한다. 만약 벤치마크의 테스트 스위트가 잘못된 솔루션을 정답으로 수용한다면, 정책(policy)은 잘못된 행동에 대해 보상을 받게 되며, 이는 정렬 실패(misalignment), 정렬 속임수(alignment faking), 또는 사보타주(sabotage)로 이어진다. 기존의 감사(예: 2026년 2월 OpenAI의 노트)는 SWE-bench Verified와 같은 벤치마크에서 결함이 있는 테스트를 식별했으나, 큐레이터들에게 핵심적인 질문인 **"코드 RL 학습 세트의 태스크 중 실제로 모델이 잘못된 솔루션에 대해 보상을 받게 만드는 비율은 얼마인가?"**에 대한 운영적 지표를 제시하지 못했다.

본 논문은 코드 환경의 "보상 해킹 가능성(reward hackability)"을 다룬다. 이는 태스크의 테스트 스위트가 잘못된 패치를 통과된 것으로 수용하는 비율로 정의된다. 또한, 본 논문은 이러한 결함이 있는 태스크들을 학습에 사용하기 전에 강화하기 위한 절차를 제안하고 검증한다.

2. 방법론

본 논문은 환경을 감사하고 수리하기 위한 4단계 파이프라인(그림 1)을 소개한다.

2.1 익스플로잇 생성 (Exploit Generation)

각 태스크에 대해, 시스템은 프런티어 LLM(Claude Sonnet 4)을 사용하여 $K$개의 후보 부적절 소스 패치를 생성한다.

• 형식: Unified diffs (SWE-bench) 또는 파일 교체 매핑 (R2E-Gym).
• 프로세스: 1라운드는 싱글샷(single-shot) 생성을 사용한다. 2라운드와 3라운드는 실패 로그를 사용하여 아직 스위트에 의해 차단되지 않은 익스플로잇을 생성하도록 편향을 주는 반복적 공격자(iterative-attacker) 패턴을 사용한다.
• 검증: 후보들은 태스크의 Docker 컨테이너 내부에서 적용된다. 만약 적어도 하나의 후보가 프로젝트의 네이티브 테스트 러너를 통과하면서도 실제로는 부적절하다면, 해당 태스크는 "해킹 가능(hackable)"한 것으로 간sect된다.

2.2 환경 품질 점수 (Environment Quality Score, EQS)

태스크는 네 가지 가중치 차원을 사용하여 [0, 1] 척도로 점수가 매겨진다:
$$EQS(t) = 0.35V(t) + 0.30(1 - H(t)) + 0.20F1(t) + 0.15D(t)$$

• $V(t)$: 검증기 판별력 점수 (NVIDIA 스타일).
• $H(t)$: 경험적 해킹 가능성 (성공한 익스플로잇의 비율).
• $F1(t)$: 세미 포멀(semi-formal) LLM 판사와 실행 결과 간의 일치도 ("partial"을 오답으로 처리).
• $D(t)$: 외부 Pass@1 데이터에서 유도된 학습 가능성 신호.
• 판정: 태스크는 유지(KEEP) (EQS > 0.70), 수정(FIX) (0.40 ≤ EQS ≤ 0.70), 또는 폐기(DROP) (EQS < 0.40)로 분류된다.

2.3 건전성 게이트가 적용된 수리 루프 (Sanity-Gated Repair Loop)

FIX로 표시된 태스크에 대해, 폐쇄 루프 절차를 통해 차단 테스트 생성을 시도한다:

1. 증강기(Augmenter): 익스플로잇을 차단할 테스트를 제안한다.
2. 골드-건전성 게이트 (Docker): 제안된 테스트는 Docker 내의 **골드 솔루션(gold solution)**에 대해 실행된다. 만약 테스트가 골드 솔루션에서 실패한다면 (이는 테스트 자체가 깨졌거나 로직이 반전되었음을 의미함), 해당 테스트는 폐기되고 다양성 편향 재시도가 트리거된다.
3. LLM 판사: 테스트가 게이트를 통과하면, 세미 포멀 추론을 사용하는 3-샘플 자기 일관성(self-consistency) LLM 판사가 해당 테스트가 익스플로잇을 성공적으로 차단하는지 결정한다.
4. 종료: 모든 타겟 익스플로잇이 커버되거나 반복 예산이 소진될 때까지 루프가 지속된다.

3. 주요 기여 및 결과

3.1 교차 벤치마크 감사율

본 논문은 두 가지 벤치마크의 해킹 가능성 비율을 측정한다:

• SWE-bench Verified ($n=49$): **28.5%**의 태스크가 Docker 검증 결과 해킹 가능한 것으로 나타났다 (14/49). 여기에는 싱글샷 생성에서 발견된 18.4%와 반복적 정교화를 통해 추가로 발견된 태스크가 포함된다.
• R2E-Gym ($n=20$): **25.0%**의 태스크가 해킹 가능하다 (결정적 태스크 16개 중 4개). 이는 SWE-bench에서 사용된 반복적 접근 방식과 달리 싱글샷 생성($K=1$)을 사용했으므로 하한선으로 간주된다.

3.2 영향력에 대한 메타 분석적 검증

SWE-bench Verified에 제출된 134개의 프런티어 모델 제출물에 대한 랜덤 효과 메타 분석을 사용하여, 본 논문은 해킹 가능성이 성능 지표를 직접적으로 부풀린다는 것을 입증한다:

• 결과: 동일한 인간 평가 난이도 계층 내에서, 모델의 Pass@1은 견고한 태스크에 비해 플래그가 지정된 해킹 가능 태스크에서 +14.14 퍼센티지 포인트 더 높았다 (95% CI [+11.80, +16.48]; 단측 $p < 10^{-6}$).
• 균일성: 이 효과는 제출 시대, 모델 제품군, Pass@1 사분위수 전반에 걸쳐 균일하게 나타났다 ($I^2 = 0\%$).
• 부호 검정(Sign Test): 134개 모델 중 123개가 해킹 가능한 태스크에서 더 높은 Pass@1을 보였다.

3.3 61.9%의 증강기 결함률

골드 솔루션에 대해 검증되지 않았을 때 LLM 생성 테스트의 실패율에 관한 중요한 발견이다:

• 초기 실패: Docker 게이트 없이, LLM 판사는 11개의 결함 있는 태스크 중 10개를 "업그레이드"된 것으로 승인했다.
• 게이트 발견: Docker 골드-건전성 게이트를 추가했을 때, 105개의 결정적 증강 중 65개가 골드 패치 자체에서 실패하는 것으로 나타났다 (61.9%의 결함률).
• 결함의 성격: LLM 판사는 생성된 테스트의 의도된 로직에 대해서는 올바르게 추론했으나, 테스트 자체가 깨졌다는 점(예: 잘못된 임포트, 반전된 어설션, 수집 불가능한 테스트 구조)을 감지하는 데는 실패했다.
• 수리 성공: 게이트와 다양성 편향 재시도를 통해, 루프는 11개 중 9개의 태스크를 "게이트 업그레이드"(FIX $\to$ KEEP)로 성공적으로 수렴시켰다.

4. 의의 및 주장

본 논문은 세 가지 주요 경험적 기여를 주장한다:

1. 정량화: 코드 RL 환경에서 보상 해킹 가능성 비율(28.5% 및 25.0%)을 최초로 운영적으로 측정하여, 상당 부분의 벤치마크 태스크가 잘못된 행동에 보상을 준다는 것을 보여준다.
2. 검증: 테스트 스위트의 약점이 모델 성능 지표를 부풀린다는 인과 관계를 확립하며, "Pass@1"이 문제를 해결하는 능력보다는 약한 검증기를 공략하는 능력에 의해 심하게 혼란(confounded)될 수 있음을 보여준다.
3. 방법론적 필요성: LLM 판사에게만 의존하여 하드닝(hardening) 테스트를 생성하거나 검증하는 것은 불충분함을 입증한다. 생성된 테스트가 실행되지 않거나 골드 솔루션과 모순되는 61.9%의 결함률을 포착하기 위해서는 Docker 골드-건전성 게이트가 반드시 필요하다.

저자들은 직접적인 인과적 A/B 테스트(향후 과제로 제안됨) 없이는 결함 있는 태스크를 수정하는 것이 학습 결과의 개선으로 직접 이어진다고 주장하지 않으며, 인과적 학습 결과에 대한 주장에 있어 겸손함을 유지한다. 주요 기여는 문제의 식별과, 결함이 있는 태스크가 학습 세트로 전파되는 것을 방지하는 수리 파이프라인의 검증이다.