[논문 리뷰] RRSI: Regularized Recursive Self-Improvement of Agent Harnesses

• 메타정보
• TL;DR
• 소개 (Introduction)
• 핵심 기여 (Key Contributions)
• 관련 연구 / 배경 지식
  • 고정 backbone과 실행 프로그램의 변화
  • 적응적 평가 재사용과 benchmark 과적합
• 방법 / 아키텍처 상세
  • 1. Proposal과 selection의 두 제어 경로
  • 2. Cosine schedule과 독립 수정의 예산
  • 3. 수정 이력과 미탐색 구성요소의 구분
  • 4. 평가 전 leakage critic과 역사적 성능 하한
  • 5. Noise band별 비용 조건과 구조적 novelty
  • 6. 최근 기여와 구조적 pruning
• 학습 목표 / 손실 함수
  • 하네스 점수와 policy token 비용의 분리
  • 성능 하한·비용·guard의 비보상적 결합
• 학습 데이터와 파이프라인
  • Evolve·ID held-out·OOD의 역할
  • 모델 역할과 탐색 예산의 실제 설정
• 실험 결과
  • Benchmark별 verifier와 점수의 의미
  • Coding, workspace, engineering의 전이 결과
  • 동일 예산의 하네스 진화 방법 비교
  • 독립 policy 진화와 미경험 backbone의 직접 전이
• 결과 분석 / Ablation
  • Proposal·acceptance 규제의 상호보완성
  • 최종 하네스의 token·step 비용
  • 채택·거절 trajectory의 구체적 근거
• 한계와 비판적 평가
  • 유한한 피드백과 noise 보정의 범위
  • 묶음 수정의 귀속과 규제별 효과
  • 실행 비용·장기 진화·아키텍처 전이의 조건
• 시사점 / Takeaways
• 설치 및 사용법
• 참고 자료
• 더 읽어보기

메타정보

TL;DR

• RRSI는 모델 가중치를 고정하고 prompt·tool·memory·context·control flow를 반복 수정하는 하네스 진화의 과적합을 다룬다. 수정 가능한 구성요소는 열어 두고, 후보 제안과 채택 과정을 규제한다.
• Proposal에는 감소하는 수정 예산, 성공·실패의 이력, 미탐색 구성요소로의 탐색을 적용한다. Selection에는 benchmark leakage 검사, 역사적 최고 점수 기준의 성능 하한, 비용 조건과 구조적 pruning을 결합한다.
• Claude Opus 4.8 실험에서 SWE-bench Verified는 82.0→83.8, JobBench는 36.0→40.7, Frontier-Eng Medal Score는 17.7→22.0으로 개선된다. 마지막 수치는 성공률이 아니라 부분 credit을 포함한 점수다.
• Workspace의 OOD 평균은 초기 하네스 39.7, 무규제 진화 40.3, RRSI 43.6이다. Trial당 policy token은 무규제 3.80M에서 2.42M으로 약 36.3% 줄지만, 초기 하네스 1.56M보다 여전히 많다.
• 규제는 작은 점수 상승을 모두 거절하는 규칙이 아니다. Noise band 안에서는 비용 절감과 새로운 구조적 구성요소도 판단에 들어간다. 유한한 평가 집합, 묶음 수정의 효과 귀속, 장기 탐색의 불확실성은 남는다.

소개 (Introduction)

에이전트가 작업을 끝내기 전에 결과를 검사하지 않는다면 완료 직전 audit을 추가할 수 있다. 오래 걸리는 명령을 계속 기다리다 시간을 낭비한다면 polling 규칙을 바꿀 수 있다. 이런 수정은 모델을 다시 학습시키지 않아도 행동을 바꾼다. 문제는 실패 기록을 읽고 코드를 고치는 과정을 자동화한 뒤에도, 무엇을 개선으로 인정할지는 별도의 문제라는 점이다. 평가 과제에 맞춘 지시문을 길게 붙여 점수를 올리는 것과 새로운 과제에서도 유용한 실행 메커니즘을 만드는 것은 다르다.

같은 과제 집합을 수십 번 평가하면 이 차이가 더 커진다. 처음에는 실패 원인을 찾기 위해 보던 과제가 이후에는 후보를 선택하는 기준이 되고, 그 선택 결과가 다시 다음 후보의 입력이 된다. 특정 파일 이름이나 업무 표현을 기억할 수도 있고, 실제로는 차이가 없는 후보가 우연히 좋은 rollout을 얻어 살아남을 수도 있다. Critic이나 검증 단계를 계속 추가하면 점수가 오르더라도 더 많은 추론을 사용한 효과인지 구분해야 한다. 가중치를 고정했다는 사실만으로 이런 적응적 과적합이 사라지지는 않는다.

Xia et al.의 RRSI는 이 반복 탐색 자체를 정규화(regularization)의 대상으로 삼는다. 어떤 도구나 memory를 만들 수 있는지 미리 좁히기보다, 한 번에 얼마나 바꿀지와 어떤 변화가 영구적으로 남을지를 제한한다. 이 리뷰는 arXiv v2의 본문·부록과 공개 코드의 구현을 기준으로 제안, 평가, 채택을 연결해 설명한다. 특히 evolve 점수와 전이 성능, policy token 비용과 전체 탐색 비용, 개별 모델에서의 재탐색과 미경험 모델로의 직접 전이를 구분한다.

핵심 기여 (Key Contributions)

• 하네스 진화의 일반화 문제. 반복적으로 재사용한 evolve set의 개선이 새로운 benchmark의 개선으로 이어지는지를 주요 평가 대상으로 설정한다.
• Proposal과 selection의 동시 규제. 수정 예산·이력·탐색 배분과 leakage·성능 하한·비용·pruning을 같은 진화 loop에 배치한다.
• 열린 수정 공간과 제한된 채택 경로. Prompt부터 subagent까지 수정하면서도 점수 상승만으로 후보가 살아남지 않도록 여러 조건을 적용한다.
• 서로 다른 verifier를 통한 전이 평가. Coding의 unit test, 업무의 rubric·선호 판단, engineering의 simulator에서 개선을 확인한다.
• 전이와 실행 비용의 공동 분석. 규제를 제거했을 때 evolve 점수가 더 오르면서 OOD 성능이 낮아지는 결과와, 최종 하네스의 token·step 비용을 함께 제시한다.

관련 연구 / 배경 지식

고정 backbone과 실행 프로그램의 변화

하네스(harness)는 모델 주변에서 입력 문맥을 만들고, 도구를 호출하고, 기억을 검색하고, 실패를 복구하며, 종료 여부를 판단하는 실행 프로그램이다. Agent를 정책 모델 $\pi$와 하네스 $H$의 조합으로 보면, RRSI가 바꾸는 것은 $H$다. 정책의 신경망 가중치는 그대로지만 읽는 정보와 행동을 조직하는 방식이 달라지므로 결과도 달라진다. 여기서 recursive self-improvement는 현재 시스템의 실행 피드백으로 다음 시스템의 하네스를 바꾸는 반복 과정이다. 모델이 자신의 가중치를 스스로 재학습하는 실험은 아니다.

Meta-Harness는 source code와 과거 평가 기록을 보는 proposer로 실행 프로그램을 탐색한다. AHE는 구성요소, 실행 경험, 수정 결과를 관찰 가능한 형태로 정리한다. TTHE는 평가 중 생성되는 실행 기록에서 하네스를 적응시킨다. RRSI는 이들과 수정 대상 상당수를 공유한다. 차이는 새로운 종류의 memory나 workflow 하나를 추가한 데 있기보다, 반복적인 점수 피드백이 검색을 어디로 밀어 가는지 통제하는 데 있다.

적응적 평가 재사용과 benchmark 과적합

일반적인 held-out 평가에서는 시스템을 고른 뒤 별도의 데이터를 한 번 측정한다. 하네스 진화에서는 같은 evolve set의 결과를 보고 후보를 만들고, 그 집합에서 다시 평가해 후보를 선택한다. 다음 round의 후보는 이전 점수를 이미 반영한다. 따라서 evolve set은 이름에 evaluation이 붙어 있더라도 탐색을 위한 학습 신호로 기능한다. 후보의 수와 수정 자유도가 커질수록, 이 집합에서만 통하는 변경이 살아남을 여지도 늘어난다.

Figure 1의 왼쪽은 workspace에서 evolve 개선과 OOD 개선의 상대 변화율을 비교한다. 아래쪽 영역은 기존 하네스보다 OOD 성능이 낮아진 경우다. 오른쪽의 prior는 네 비교 방법의 평균이며, 가장 강한 baseline 하나가 아니다. 이 그림의 메시지는 evolve 점수를 더 많이 올린 방법이 반드시 전이에서도 앞서지는 않는다는 것이다. 이 실험에서의 순위 역전을 모든 환경에서의 우열로 일반화할 수는 없지만, 진화 성능을 evolve 점수 하나로 평가하기 어렵다는 근거는 된다.

방법 / 아키텍처 상세

1. Proposal과 selection의 두 제어 경로

한 round는 현재 하네스의 실행 결과를 분석하는 것으로 시작한다. Analyst가 실패 피드백을 만들고, proposer가 현재 코드와 수정 이력, 예산, 탐색 지시, pruning 대상을 받아 후보를 제안한다. Critic의 사전 검사를 통과한 후보만 evolve set에서 평가한다. Selector는 측정 점수와 비용으로 채택 가능한 후보를 구성하고, 그중 가장 높은 점수의 후보를 다음 하네스로 선택한다. 통과한 후보가 없으면 현재 하네스를 유지한다.

수정 가능한 구성요소는 prompt, control flow, config, output plumbing, context management, client tool, skill, memory, subagent다. 이 목록에서 어느 종류를 수정할 수 없게 만드는 방식은 아니다. 예를 들어 prompt 개선도 범용적이고 비용 조건을 만족하면 채택할 수 있다. 반대로 새로운 subagent라는 구조적 변화도 benchmark를 암기하거나 비용에 비해 효과가 작으면 거절할 수 있다. 구성요소의 이름만으로 유용성을 결정하지 않는다는 점이 중요하다.

2. Cosine schedule과 독립 수정의 예산

후보 하나에 서로 무관한 변경을 많이 넣으면 특정 과제의 여러 특징을 동시에 맞출 수 있다. 성능이 올랐을 때 어느 수정이 기여했는지도 어려워진다. RRSI는 후보에 포함되는 독립적인 수정 수를 제한한다. 총 round 수 $T$, round index $t$에서의 예산은 다음과 같다.

초기에는 여러 관련 변경을 함께 시도하고, 후반에는 작은 변경으로 좁히려는 설계다. 후보의 atomic edit 선택을 binary vector $z_t$로 나타내면 $\lVert z_t\rVert_0\le b_t$라는 개수 제약이다. 이것은 전체 하네스의 구성요소 개수를 고정하거나 모델 가중치에 norm penalty를 더하는 방식과 다르다. 코드 줄 수가 아니라 효과를 구분해 설명할 수 있는 수정의 개수를 제한한다.

실제 끝점은 식과 round 범위를 함께 봐야 한다. 설정의 $b_{\min}=1$을 곧바로 마지막 후보의 수정 수 1이라고 읽으면 안 된다. 논문과 공개 구현은 $t=0,\ldots,T-1$을 사용하고 ceiling을 적용한다. Table 5의 세 설정을 공식 edit_budget으로 계산하면 마지막 round의 예산은 모두 2이며, $t=T$에서야 1이 된다. 따라서 이 실험의 후반 후보도 두 수정의 묶음일 수 있다. 감소하는 예산의 의미는 유지되지만 완전한 단일 수정 귀속을 가정할 수는 없다.

3. 수정 이력과 미탐색 구성요소의 구분

평가한 atomic edit마다 구성요소, 가설, source diff, 점수 변화, 비용 변화, 실제 채택 여부를 기록한다. 여러 수정이 한 후보에 들어 있으면 각 기록은 같은 후보의 측정값을 공유한다. 채택 조건을 통과했더라도 다른 후보에 밀려 round의 승자가 되지 못했다면 채택 표시는 0이다. 따라서 “허용 가능한 후보”와 “실제로 다음 시스템에 들어간 후보”는 구분된다.

이 이력은 이미 실패한 가설을 계속 다시 제안하는 일을 줄이고, prompt 수정만 반복하는 탐색 정체를 발견하는 데 사용된다. 직전 $w$ round의 점수 변화가 noise tolerance $\delta$를 넘지 못하면 탐색을 stalled로 판단한다. 이때 아직 측정된 수정을 한 번도 가진 적 없는 구성요소를 위한 탐색 후보 slot을 예약한다. 이것은 유망한 구조를 미리 정해 놓는 규칙이 아니라 제한된 후보 예산 일부를 다른 위치에 쓰는 규칙이다.

여기서 미탐색 상태와 뒤에서 쓰는 novelty는 다르다. 미탐색 집합은 과거에 측정한 적이 없는 구성요소다. Novelty는 이미 시도했더라도 승리한 수정에 아직 등장하지 않은 구조적 종류를 센다. 한 번 실패한 memory 후보는 더 이상 미탐색은 아니지만, memory가 한 번도 채택되지 않았다면 novelty credit을 받을 수 있다. 두 기준을 같은 “새로운 수정”으로 합치면 실제 탐색·채택 동작을 놓친다.

4. 평가 전 leakage critic과 역사적 성능 하한

Critic은 후보 diff에 task 이름, entity 이름, 특정 답이나 값, evolve benchmark에만 맞는 분기 등이 들어가는지 확인한다. 실행에 영향을 주지 않는 장식적 machinery도 검사 대상이다. 이 검사를 전체 평가보다 먼저 두어, 누출된 후보가 높은 점수를 얻고 다음 탐색의 근거가 되는 경로를 차단한다. 다만 LLM critic의 판단이 모든 형태의 간접 과적합을 찾아낸다는 보장은 없다.

평가 후에는 역사적 최고 evolve 점수 $S^\star$를 기준으로 다음 하한을 적용한다.

하한은 직전 하네스만을 기준으로 삼지 않는다. 매 round에서 작은 퇴행을 허용해 계속 내려가는 경로를 막기 위해 최고 점수를 보존한다. 동시에 $\delta$만큼의 변동은 허용한다. 그러므로 “현재 점수보다 무조건 높아야 한다”는 규칙도 아니다. 새 구조를 도입하거나 비용을 줄이는 후보가 약간 낮은 점수에서 살아남을 수 있지만, 역사적 최고에서 멀어지지는 못한다.

5. Noise band별 비용 조건과 구조적 novelty

현재 하네스 대비 점수 차이 $\Delta S$와 상대 token 변화 $\Delta C$를 계산한다. 점수는 0–1 fraction이고 비용 변화는 현재 비용을 분모로 쓴다. $\Delta S>\delta$인 후보에는 점수 상승에 비례한 비용 허용량을 적용한다. Noise band를 넘지 못하면 다른 규칙을 사용한다.

첫 분기에서는 큰 개선에 더 많은 token을 허용한다. 두 번째에서는 비용 감소가 양의 credit이 되고, 이전 승리 경로에 없던 structural component도 credit을 받는다. Novelty $\nu_t$는 client tool, skill, memory, subagent의 서로 다른 종류만 센다. Prompt나 context management 수정에는 이 보너스가 없다. 같은 종류의 새 skill을 계속 추가한다고 매번 새로운 구조적 종류로 보상하는 규칙은 아니다.

Coding에서는 $w_s=0$이므로 noise band 안의 점수 상승 자체가 채택 근거가 되지 않는다. Workspace와 engineering에서는 양의 $w_s$를 쓴다. 이 조건들을 통과한 후보 사이에서 최종 승자를 고르는 기준은 다시 측정 점수다. Shaped score는 마지막 순위 점수가 아니라 채택 자격을 결정하는 조건이다. Engineering에는 valid-output rate가 3%p 넘게 떨어지거나 no-submission rate가 2%p 넘게 오르면 거절하는 추가 guard도 있다.

6. 최근 기여와 구조적 pruning

수정 예산은 새 update를 작게 만들지만, 이미 넣은 machinery를 제거하지는 않는다. RRSI는 구성요소별 최근 측정된 점수 변화의 최댓값을 보고, pruning window 안에서 양의 기여가 없으면 삭제 대상으로 표시한다. 최근 평가가 전혀 없으면 최댓값을 음의 무한대로 취급한다. 삭제 대상과 그 구성요소에 연결된 과거 채택 기록을 proposer에 전달해 후속 후보에서 불필요한 구조를 제거하도록 한다.

이 과정은 selector가 즉시 모든 코드를 지우는 자동 삭제가 아니다. 삭제안도 후보로 만들어 평가·선택을 거친다. 또한 묶음 수정에 같은 점수 변화를 배분하므로 구성요소별 기여 기록이 인과 효과의 독립적인 측정은 아니다. 더 작은 후보는 이 모호함을 줄이지만 없애지는 않는다. 논문이 사용하는 L0·Lasso·Ridge 표현도 이러한 개수 제한, 구조 제거, 자원 증가 억제의 역할에 대한 비유다. 실제 L1 또는 L2 norm을 최소화하는 연속 최적화 문제로 해석해서는 안 된다.

학습 목표 / 손실 함수

하네스 점수와 policy token 비용의 분리

RRSI에는 backbone을 업데이트하는 SFT나 RL loss가 없다. 과제 $x$와 실행 trajectory $\tau$에 대해 verifier reward $r(x,\tau)$와 policy token 수 $c(\tau)$를 측정하고, 그 피드백으로 실행 프로그램을 탐색한다. 논문의 기대 성능과 기대 비용은 다음과 같다.

실제로는 유한한 과제와 반복 trial로 이 값을 추정한다. Coding과 engineering의 진화 지표는 성공 여부를 평균한다. Harvey LAB에서는 각 trial의 통과 criterion 비율에 criterion 수를 가중해, 전체 rubric criterion 중 통과 비율을 계산한다. 긴 rubric을 가진 과제가 짧은 rubric보다 더 큰 가중치를 갖는다. 모든 benchmark를 동일한 task-level 성공률로 바꿔 평균하는 것은 아니다.

성능 하한·비용·guard의 비보상적 결합

선택은 성능과 비용을 하나의 고정 scalar loss로 합쳐 가장 작은 값을 고르는 방식이 아니다. Leakage 검사를 통과해야 하고, 최고 점수 기준의 하한을 만족해야 하며, 해당 noise 분기의 비용 조건과 domain guard도 만족해야 한다. 그 뒤에야 점수로 후보를 비교한다. 성능 하한 아래의 후보는 아무리 저렴해도 채택할 수 없고, engineering의 실행 유효성이 크게 떨어지는 후보는 평균 pass rate 상승으로 이를 상쇄할 수 없다.

이 설계는 검색이 보상 하나를 편법으로 올리는 경로를 줄인다. 대신 어떤 비용 증가를 허용할지, 어떤 정도의 점수 변화를 noise로 볼지에 관한 선택이 필요하다. 특히 $\beta_1$에는 fraction 단위의 점수 차이를 넣어야 한다. 화면에 표시된 percentage-point 값을 그대로 넣으면 허용 비용을 크게 잘못 계산하게 된다. 규칙을 재현할 때 지표의 단위까지 함께 옮겨야 하는 이유다.

학습 데이터와 파이프라인

Evolve·ID held-out·OOD의 역할

학습 데이터에 해당하는 것은 가중치 학습 corpus가 아니라 후보를 제안하고 고르는 evolve set이다. Coding은 Terminal-Bench 2.1의 89개 task 전체, engineering은 proprietary simulator 없이 실행 가능한 EngDesign 61개 task 전체에서 진화한다. 두 환경은 별도의 ID held-out을 두지 않는다. Workspace는 Harvey LAB 160개 task를 한 번만 120개 evolve와 40개 ID held-out으로 나누어 분할을 고정한다. Harvey LAB은 25개 법률 실무 분야의 문서 작업을 포함한다.

각 domain에서 별도의 하네스를 진화시키고, 그 결과를 해당 domain의 다른 benchmark로 그대로 가져간다. 하나의 최종 하네스를 coding·법률·engineering 모두에 공통으로 적용한 실험은 아니다. Held-out과 OOD 결과는 후보 선택이나 hyperparameter 조정에 쓰지 않는다. 기준 하네스와 후보는 같은 평가 시기, 도구 환경, judge와 trial 수를 사용해 비교한다.

모델 역할과 탐색 예산의 실제 설정

주 실험의 frozen policy, proposer, analyst, leakage critic은 Claude Opus 4.8이다. Harvey LAB의 criterion judge는 Gemini 3.5 Flash다. 정책 모델, 후보를 만드는 모델, 결과물을 채점하는 모델의 역할을 구분해야 한다. Coding에서 Gemini 3.5 Flash를 policy로 쓰는 추가 실험은 별도의 진화 run이며, 주 실험의 하네스를 단순히 그 모델로 바꿔 실행한 결과가 아니다.

Coding과 workspace는 20 rounds, engineering은 40 rounds다. 과제당 평가 trial 수는 각각 2, 2, 4이고, 공개 설정은 round당 후보 2개를 사용한다. Noise tolerance는 0.017, 0.004, 0.020이다. Stall window는 모두 3, pruning window는 4, 4, 5이다. 초기 수정 예산은 4, 3, 4로 시작한다. Coding의 기준 평가 한 번만 해도 89×2=178 trials, engineering은 61×4=244 trials가 필요하다.

Table 5의 비용 조건은 coding·workspace의 $\beta_0=0.10$, engineering의 0.15, $\beta_1$은 44.5, 35.4, 24.4다. Noise band의 세 weight는 공개 rrsi.json에서 coding이 (0, 15, 0.5), workspace가 (1414, 15, 0.5), engineering이 (244, 2, 0.5)로 확인된다. 큰 숫자는 점수를 fraction 단위로 넣기 때문이다. 논문은 변경하지 않은 초기 하네스의 반복 평가에서 noise를 보정했다고 설명한다. 이는 baseline에서 관측한 경험적 허용도이며, 모든 미래 후보에 대한 통계적 유의성을 보증하는 검정은 아니다.

Policy token 수는 최종 시스템을 과제에 실행할 때의 비용 proxy다. Proposer·analyst·critic 호출, 여러 후보의 전체 evolve 평가, 환경 구축까지 합친 탐색 총비용과는 다르다. 논문은 최종 하네스의 실행 비용을 자세히 비교하지만, 사용자가 같은 탐색을 처음부터 반복할 때 지불할 전체 달러 비용이나 wall-clock을 그 표에서 얻을 수는 없다.

실험 결과

Benchmark별 verifier와 점수의 의미

Figure 3의 막대는 모두 0–100 표기지만 같은 지표가 아니다. 부록 A의 정의를 기준으로 읽어야 개선이 실제로 무엇을 의미하는지 알 수 있다.

GDPval은 Qwen3.6-35B-A3B, Claude Sonnet 4.6, Gemini 3.1 Pro의 판단을 사용하고 결과물 순서를 바꾸어 position bias를 줄인다. 52.3이라는 값은 이 비교 설정에서 인간 전문가 결과물보다 선호된 비율이지, 업무의 52.3%를 완전히 해결했다는 뜻이 아니다. Harvey LAB과 JobBench도 rubric 기반 부분 점수다. APEX-Agents는 전체 480 task를 분모로 유지하고 missing rollout을 실패로 센다. 인프라 문제로 어려운 task가 빠져 점수가 좋아 보이는 경로를 줄이는 처리다.

Coding, workspace, engineering의 전이 결과

Coding에서는 Terminal-Bench 2.1이 74.2→80.2로 +6.0%p, SWE-bench Verified가 82.0→83.8로 +1.8%p다. 전자는 직접 선택에 쓰인 터미널 task이고 후자는 repository issue의 patch를 검증하는 미경험 환경이다. Evolve에서의 개선 전체가 그대로 옮겨지지는 않지만, 다른 task 구조에서도 이득이 남는다. 이렇게 두 결과를 나란히 보는 것이 진화 과정의 재사용 가능성을 판단하는 핵심이다.

Workspace에서는 Harvey LAB evolve가 89.4→90.5로 +1.1%p, ID held-out이 86.9→89.2로 +2.3%p다. OOD 결과는 JobBench 36.0→40.7, GDPval 48.8→52.3, APEX-Agents 34.2→37.9로 각각 +4.7, +3.5, +3.7 points다. 서로 다른 세 점수의 단순 평균은 39.7→43.6이다. 이 평균은 통합 성공률이 아니라 benchmark별 점수를 같은 비중으로 요약한 값이다. JobBench의 +4.7은 상대적으로 약 13.1%의 개선이지만, +13.1 points와는 다르다.

Engineering의 EngDesign pass rate는 50.0→54.9로 +4.9%p, Frontier-Eng Medal Score는 17.7→22.0으로 +4.3 points다. Medal Score는 고정 v1 snapshot의 상위 feasible 결과를 기준으로 gold 1, silver 0.67, bronze 0.33의 credit을 주고 task별 평균을 낸다. 저자는 47개 task를 분모로 보고하며, 환경 구축 제약 아래 38개 task가 credit에 기여할 수 있다고 설명한다. Evolve set과 겹치는 EngDesign domain은 OOD 평가에서 제외한다. 두 arm에는 동일한 평가 조건을 적용한다.

Simulator에서의 전이는 특정 LLM judge가 좋아하는 문체만 학습했다는 설명으로 모든 개선을 설명하기 어렵게 만든다. 그렇다고 engineering 결과만으로 업무 benchmark의 judge bias까지 사라졌다고 결론 내릴 수는 없다. 또한 verifier가 deterministic이어도 agent가 만드는 설계는 확률적이므로 반복 실행의 변동은 남는다. 채점의 변동과 정책의 변동을 구분해야 한다.

동일 예산의 하네스 진화 방법 비교

Table 1은 같은 초기 하네스, frozen policy, evolve set, 후보 예산에서 Meta-Harness·AHE·TTHE·HarnessX를 비교한다. Meta-Harness의 Harvey LAB evolve 점수 93.0은 RRSI 90.5보다 높다. 하지만 ID held-out에서는 둘 다 89.2이고, OOD 세 환경에서는 RRSI가 모두 앞선다. TTHE의 OOD 평균은 약 38.0으로 초기 약 39.7보다 낮아진다. 이 경우 evolve 개선을 시스템의 일반적인 능력 향상으로 읽으면 결론이 반대가 된다.

이 결과는 해당 공통 설정에서의 비교다. 각 선행 논문의 원래 실험 전체를 재현한 leaderboard 비교와는 구분해야 한다. 특히 TTHE의 원래 문제 설정은 gold label 없이 실행 기록의 proxy 신호로 평가 중 적응하는 것이다. RRSI 논문에 정렬된 후보 예산과 환경에서의 결과가 그 방법의 모든 사용 상황을 대표하지는 않는다. 다만 후보를 같은 기준에서 선택할 때 어떤 종류의 규제가 전이를 도울 수 있는지 보여 주는 통제 비교라는 의미가 있다.

독립 policy 진화와 미경험 backbone의 직접 전이

Gemini 3.5 Flash로 coding 진화를 별도로 수행하면 Terminal-Bench 2.1은 64.6→78.7, SWE-bench Verified는 76.8→79.0이다. 각각 +14.1%p, +2.2%p다. Abstract의 최대 14.1 points는 이 추가 policy 실험에서 나온 값이며, Claude 주 실험의 Terminal-Bench 개선 6.0과 섞으면 안 된다. 두 모델에서 진화·전이 패턴이 반복된다는 근거지만, 같은 하네스가 모든 모델에 공통으로 최적이라는 주장은 아니다.

별도의 cross-model 실험은 Gemini 3.5 Flash로 만든 최종 하네스를 수정 없이 Gemini 3.1 Flash Lite에 적용한다. Terminal-Bench 2.1은 11.2→14.6으로 +3.4%p, 상대적으로 약 30.4% 개선된다. 큰 상대 변화율은 낮은 시작 점수와 함께 읽어야 한다. 최종 절대 점수는 여전히 14.6이며, 이 실험은 미경험 backbone에서 같은 evolve benchmark를 평가한 것이다. 미경험 모델과 미경험 benchmark의 두 변화를 동시에 검증한 결과는 아니다.

결과 분석 / Ablation

Proposal·acceptance 규제의 상호보완성

Proposal 규제를 빼면 evolve는 90.5→90.7로 조금 오르지만 OOD 평균은 43.6→41.9로 1.7 points 낮아지고 token은 2.42M→2.69M이다. Acceptance 규제를 빼면 evolve 91.5, OOD 41.0, token 3.59M으로 바뀐다. 후자의 token 증가는 RRSI 대비 약 48.3%다. 제안을 어디에 얼마나 할지 제한하는 것과, 제안된 결과 중 무엇을 남길지 제한하는 것 모두 전이와 관련된다.

둘 다 제거한 무규제 진화는 evolve 92.8로 가장 높지만 OOD는 40.3에 머무르고 3.80M tokens를 쓴다. 초기 39.7에서 얻은 전이 이득이 작은 반면 계산량은 크게 늘어난다. 이 결과에서 규제의 의미는 evolve 최고점을 더 올리는 것이 아니라, 그 점수를 덜 얻더라도 다른 환경에서 유지되는 개선을 고르는 데 있다. 다만 두 그룹 단위 ablation만으로 critic·history·schedule·pruning 각각의 독립 기여를 분리할 수는 없다.

최종 하네스의 token·step 비용

Table 2 기준으로 RRSI의 token 절감률은 $(3.80-2.42)/3.80$이므로 약 36.3%다. Abstract의 30% 절감 요약보다 구체적인 표의 값을 사용한 계산이다. 하지만 비교 분모가 무규제 진화라는 점을 빠뜨리면 안 된다. 초기 하네스 1.56M에 비하면 RRSI의 2.42M은 약 55.1% 많다. RRSI가 계산을 전혀 늘리지 않고 모든 성능을 얻은 결과는 아니다.

Step에서도 초기 하네스는 21.2, RRSI는 26.3이다. 비교 진화 방법은 TTHE 27.3, Meta-Harness 28.7, HarnessX 29.5, AHE 34.6이다. 최종 진화 하네스들 중 RRSI가 짧고 저렴하지만 초기보다 더 많은 작업을 한다. Figure 4의 가로축 비용은 Harvey LAB evolve에서 측정한 값이고 세로축은 다른 세 benchmark의 OOD 평균이다. 각 OOD benchmark에서 비용까지 함께 측정한 전체 운영 frontier로 확대 해석해서는 안 된다.

채택·거절 trajectory의 구체적 근거

Coding R0-A는 완료 전 제한된 verification audit과 오래 걸리는 작업의 non-blocking polling 지침을 추가해 +3.93 points로 채택된다. 비슷한 R0-B는 +1.69 points지만 token이 26.1% 늘어 거절된다. Coding의 $\delta=0.017$과 $w_s=0$을 함께 보면 작은 점수 상승만으로 비용 증가를 정당화하지 못하는 사례다. 겉으로 비슷한 “검증을 추가하자”도 측정된 변화와 실제 비용에 따라 결과가 다르다.

R8-B는 제출 전 원래 task instruction을 다시 확인하도록 고정해 비용을 13.6% 줄였지만 점수가 2.81 points 떨어져 성능 하한으로 거절된다. 저렴하다는 이유만으로 퇴행을 받아들이지 않는 예다. 반대로 engineering R2는 작업 디렉터리 오류에 제한된 recovery hint를 추가해 122/244→128/244 passes, token +1.6%로 채택된다. 이는 개별 task의 답을 저장하는 것보다 일반적인 도구 실패 복구가 유용할 수 있음을 보여 준다. 대표 사례이므로 전체 진화에서 이런 변화가 얼마나 자주 나타났는지의 빈도 추정은 아니다.

한계와 비판적 평가

유한한 피드백과 noise 보정의 범위

저자가 인정하듯 효과는 evolve set의 품질, 규제 hyperparameter와 탐색 예산에 의존한다. 동일한 유한 집합을 재사용한다는 근본 조건은 유지된다. Critic은 명시적인 task-specific 내용을 줄이지만 일반적인 규칙처럼 보이는 과적합이나 judge의 선호를 모두 검출할 수는 없다. 초기 하네스에서 측정한 noise tolerance도 진화한 하네스의 분산이 같다는 보장은 아니다. 반복 trial과 보수적인 하한은 유용한 방어지만 적응적 탐색 전체의 통계적 유의성 보증을 대신하지 않는다.

묶음 수정의 귀속과 규제별 효과

여러 atomic edit이 하나의 후보에 들어 있으면 모두 같은 점수 차이를 받는다. 그중 하나가 성능을 올리고 다른 하나가 낮추어도 기록만으로 분리하기 어렵다. 이 문제는 pruning의 최근 기여 판단에도 연결된다. Schedule의 실제 마지막 예산이 2라는 점까지 고려하면, 후반의 attribution이 완전히 단일 수정 수준으로 정리된다고 가정할 수 없다. Component 단위 counterfactual 평가나 더 세분된 ablation이 있다면 어떤 규제가 어떤 메커니즘을 보존했는지 더 강하게 설명할 수 있다.

실행 비용·장기 진화·아키텍처 전이의 조건

Token은 비용을 비교할 공통 proxy이지만 API의 입력·출력·cache 가격, tool 실행, latency를 모두 표현하지 않는다. 최종 하네스가 저렴해도 그 하네스를 찾는 비용은 크다. 운영 관점에서는 탐색 비용을 몇 번의 배포 실행으로 회수하는지가 필요하다. 논문의 세 domain과 policy 추가 실험은 범위를 넓히지만, 20·40 rounds 이후의 장기 안정성이나 완전히 다른 tool ecosystem까지 보증하지 않는다. Frozen backbone을 전제로 하므로 가중치 학습과 하네스 진화를 동시에 진행할 때의 상호작용도 별도의 질문이다.

시사점 / Takeaways

• 진화 점수와 실제 전이의 분리. 선택에 쓰인 과제의 점수 상승을 새 환경에서의 능력 향상으로 바로 해석하지 않고, 하네스를 고정한 OOD 평가를 함께 봐야 한다.
• 제안보다 영구 상태의 채택 기준. 좋은 후보를 많이 만드는 것뿐 아니라 누출, 작은 퇴행의 누적, 설명되지 않는 계산 증가가 남지 않도록 해야 한다.
• 실패 기록과 구조적 탐색의 결합. 성공한 수정만 기억하면 실패한 가설을 반복하거나 prompt 변경에 갇히기 쉽다. 측정된 실패와 미탐색 위치도 다음 제안의 자원이다.
• 효율 비교의 정확한 분모. RRSI는 진화 방법들보다 저렴하지만 초기 하네스보다 비싸다. 최종 실행과 탐색 총비용, 평균 benchmark 점수와 성공률도 나누어 판단해야 한다.
• 정규화 비유와 구현의 구분. L0·Lasso·Ridge라는 이름보다 실제 round 범위, ceiling, noise 분기, novelty의 정의와 guard가 시스템의 동작을 결정한다.

설치 및 사용법

공식 저장소의 search core는 Python 3.10 이상을 요구한다. 다음은 README와 dependency manifest를 대조한 설치·로컬 core 검사 예다. test_core.py는 API나 benchmark를 호출하지 않는다.

git clone https://github.com/google-research/rrsi.git
cd rrsi
python3 -m venv .venv
. .venv/bin/activate
pip install -e ".[dev]"
python3 tests/test_core.py

Coding benchmark runner는 공식 안내대로 별도 환경에 Harbor를 설치하고 Docker를 준비한다. Vertex AI project, 사용할 모델에 대한 접근, 인증도 필요하다. 아래 smoke부터 실제 모델 호출이 발생하며, baseline과 run은 다수의 trial을 실행한다.

python3 -m venv domains/coding/.venv
domains/coding/.venv/bin/pip install "harbor>=0.18"
gcloud auth application-default login
export VERTEX_PROJECT="your-project-id" VERTEXAI_PROJECT="your-project-id"
export VERTEX_LOCATION=global VERTEXAI_LOCATION=global
export RRSI_VERTEX_PROJECTS="your-project-id"
python3 rrsi.py --domain coding smoke
python3 rrsi.py --domain coding baseline
python3 rrsi.py --domain coding run

설정은 domains/coding/rrsi.json, 실행 기록은 runs/coding/에 있다. Workspace와 engineering은 [agentic] 의존성과 별도 benchmark·tool gateway 설정이 필요하므로 각 domain README를 따라야 한다. 여기서는 공식 core 검사 8개와 schedule 끝점 계산을 실행했으며, 유료 policy rollout과 전체 benchmark 재현은 수행하지 않았다.

참고 자료

• 논문: RRSI, arXiv:2609.24972, 본문·부록의 v2 기준.
• 코드: google-research/rrsi, Apache-2.0.
• 구현 확인: commit be50316e1db05914068a973f322770ef08ed7ba1의 schedule.py, selection.py, domain별 rrsi.json.
• 프로젝트: Regularized RSI, 후보·critic·채택 결과와 diff의 round별 explorer.
• 그림·표 출처: Xia et al.의 RRSI 원문. 논문의 arXiv 비독점 배포 라이선스와 코드 라이선스는 별개.

더 읽어보기

• Meta-Harness: End-to-End Optimization of Model Harnesses (Lee et al., 2026): 코드·점수·이전 실행 기록을 보는 proposer 기반 하네스 탐색.
• Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses (Lin et al., 2026): 구성요소·경험·수정 결과를 관찰 가능한 증거로 조직하는 진화 loop.
• TTHE: Test-Time Harness Evolution (Nie et al., 2026): Gold label 없이 평가 중 실행 기록으로 프로그램을 적응시키는 접근.
• Evo-Bench: Can Language Models Improve Agent Harness? (Huang et al., 2026): 진화 환경과 분리된 평가를 통해 하네스 개선을 측정하는 benchmark.