환경 구축을 통한 자기 진화형 추론 RL: 검증 가능한 환경 합성

LLM이 문제를 풀고 데이터를 생성하는 대신 실행 가능한 환경을 만들어 학습 신호를 제공하는 방향을 제시한다. 환경 단위의 재사용과 stable reward를 확보하면 정적 데이터 풀의 한계를 넘어 frontier를 지속적으로 확장할 수 있다. 핵심 아이디어는 solve–verify 비대칭성과 환경의 재사용이다.

출발점: zero-data reasoning RL은 정답의 보상을 고정 데이터에서만 얻는 구조가 일반화에 한계를 준다. EvoEnv는 이 한계를 넘기기 위해 문제 단위가 아닌 환경 단위로 학습 신호를 생성한다. 환경은 Ge(생성기), Πe(렌더러), Se(채점기)로 구성된 재사용 가능한 실행 코드 객체이며, 입력(seed, difficulty)에 따라 latent 인스턴스(z)와 정답(a)를 산출한다. solver는 렌더링된 프롬프트 x를 보고 y를 생성하고, Se를 통해 Re(y; σ, δ)를 얻는다. 이때 reward 소스는 실행 경로(y를 평가하는 코드)이며, 모델의 현재 샘플링 답변을 통해 보상이 바뀌지 않는다. 이 구조는 solve와 verify가 서로 다르게 구현되어 있어, 모델이 단순히 문제를 푼다고 해서 보상이 고정되지 않는다. 핵심 아이디어는 two complementary forms의 stable solve–verify asymmetry를 통해, 모델이 제안하는 해가 아니라 실행 가능한 코드가 보상을 결정한다는 점이다. 이를 통해 환경이 조금씩 바뀌더라도 보상 분포를 유지하고 frontier-calibration을 지속시킨다. 실험적으로 EvoEnv는 generator의 보상 구성요소(유효성·난이도)와 novelty 보상을 함께 사용해 pool의 다양성과 질을 높인다. 결과적으로 세 모델군에서 평균 점수의 개선이 확인되며, training score가 낮아지는 현상은 solver가 harder 환경에 직면하도록 만들고 frontier를 유지한다는 것을 보여준다. 마지막으로, generated-environment의 다변성은 RLVR 학습에서 문제 템플릿의 재현성보다 실제로 다양한 실행 가능한 환경을 제공함으로써 외부 벤치마크의 일반화에 기여한다.

단락 1: EvoEnv의 기본 아이디어는 하나의 정책이 generator와 solver의 역할을 교대로 수행하는 두 역할 공유 구조로, Candidate Environment가 네 가지 계약을 통과해야 활성 풀에 진입한다는 점이다. L1–L5 검증, semantic self-review, solver-relative difficulty calibration, novelty filtering이 핵심 절차다. 단락 2: 환경 인터페이스는 VerifiableEnvironment의 서브클래스로 구현되며, _generate(seed, difficulty)로 latent 인스턴스(z)와 정답(a)를 산출하고, _prompt_generate(z)로 NL 프롬프트 x를 생성하며, _process 및 scorer로 y의 채점 값을 반환한다. 예시로 SortingEnv가 제시되며, Ge, Πe, Se의 연결 구조를 보인다. 패턴: [Ge 입력] → [생성] → [Πe로 NL 프롬프트 생성] → [Solver가 y를 생성] → [Se가 y를 채점해 Re를 반환] → [정답과 일치 여부로 보상]. 단락 3: 학습 및 채용 규칙은 L5 후보에 대해 âm(e; πθ)를 8개의 calibration 인스턴스로 추정하고, 0 < âm < 1 조건으로 admission 판단을 수행한다. Qunc은 exp(−(âm − a⋆)²/(2σ²a)) 형태의 위험-보정 보상으로 난이도를 조정한다. a⋆는 0.3으로 설정되며, 이는 solver가 충분히 자주 성공하지만 충분히 다양성을 유지하도록 조정된다. Nt(e)는 prompt와 code 임베딩의 두 뷰의 이질성을 측정해novelty를 보정한다. 패널리티 기반의 Qval은 ℓ(e) 등급에 따라 다르게 적용되며, ℓ(e) ≥ 2일 때만 Nt의 보너스가 활성화된다. 단락 4: Pool admission은 At(e) 조건(I[ℓ(e)=5] ∧ I[review(e)=1] ∧ 0 < âm < 1 ∧ simt(e) < τgate)으로 결정되며, solver 그룹과 generator 그룹은 GRPO 객체를 통해 공동 최적화된다. 단락 5: 풀 관리에서는 pool rotation과 original-seed floor를 도입해 원 seed의 비율을 유지하고, retirement된 환경은 스텝 수만큼 solver 학습에 사용된 뒤 seed로 재활용된다. 샌드박스 실행은 보안적으로 격리되며, imports는 제한된다.

주요 벤치마크 결과: Qwen3-4B-Instruct-2507에서 EvoEnv의 Avg는 49.2에서 53.1로 증가; Qwen3-4B-Thinking-2507에서 EvoEnv의 Avg는 72.4에서 74.8로 증가하는 상대 3.3%의 개선을 보임; Nemotron-Cascade에서 EvoEnv의 Avg는 71.0에서 73.2로 증가했다. 학습 다이나믹스: EvoEnv는 solver 학습 점수가 0.88에서 0.61로 감소하지만, held-out RLVE에서 50개 unseen 환경의 정확도는 72.4%에서 80.4%로 상승한다. 데이터 수준의 감사는 100스텝에서 840개의 accepted environments와 45개의 tag prototypes를 확보했고, generated tag의 주요 분포는 number theory(68.2%), modular(약 38%), sequence(약 38%) 등 다양성을 보여준다. Ablation 연구: w/o Quality는 평균 이득을 +0.5로 감소시키고, w/o Diversity는 +0.6으로 감소시켜 두 구성요소의 상호보완성이 필요함을 시사한다.

단락 1: EvoEnv 아키텍처는 generator와 solver를 단일 정책 πθ로 수행하는 이중 역할 구조이며, Candidate Environment는 네 가지 계약을 충족해야 활성 풀 Pt에 진입한다. L1–L5의 멀티레이어 검증과 semantic review, novelty gating, in-batch deduplication, 풀 회전을 통해 품질을 확보한다. 단락 2: VerifiableEnvironment 인터페이스는 Ge(seed, difficulty), Πe(z) 렌더링, Se(y, z, a)로 구성되며, SortingEnv의 예시는 Ge, Πe, Se의 연결을 명시한다. Sandbox 실행은 제한된 라이브러리, 30초 타임아웃 등의 안전 장치를 포함한다. 단락 3: Prior work 대비 차별점은 환경 단위의 재사용성과 frozen 실행 경로에서의 보상 결정, 정책과 보상 신호의 독립성이다. 단락 4: 학습 설정은 GRPO를 사용하고, Generator advantage는 wgen=0.3, Novelty embedding은 all-MiniLM-L6-v2를 사용하며, 8 calibration 인스턴스에서 âm를 측정한다. 단락 5: 데이터 레벨의 탐구는 seed 10개로 시작해 100스텝에서 840 환경, 45 태그 프로토타입을 확보했고, seed 간 다양성은 68.2%의 number theory, 38%의 modular 및 38%의 sequence 구조를 보인다. 단락 6: 평가와 안전성은 내부 Krev=3의 독립 리뷰를 거치며, any-reject 방식을 적용해 semantic 이슈를 걸러낸다.

환경 인터페이스의 범위는 결정론적 파이썬 실행에 맞춰져 있으며, 오픈-엔디드 판단이나 인간 선호 데이터가 필요한 설정에는 적용에 한계가 있다. 실행 코드 안전성은 샌드박스 기반으로 관리되지만, 더 강한 격리 및 모니터링이 필요할 수 있다. 정책-주도형 보상이 아닌 실행-근거 보상에 의존하므로, 외부 도구 사용이나 물리적 시뮬레이션 등으로의 확장은 추가 안전장치가 필요하다.