마지막 점수는 연구가 어디서 무너졌는지 말해 주지 않는다

36개 task, 네 workload, 2–12시간의 연구 loop

평가 대상은 AutoLab에서 가져온 36개 expert-curated task다. Model Development 7개, System Optimization 15개, Puzzle & Challenge 10개, CUDA 4개로 구성된다. 각 task는 연구 목표, 정답은 맞지만 의도적으로 suboptimal한 시작 artifact, expert reference solution, wall-clock budget, automated verifier를 제공한다. agent는 제한 시간 안에서 반복적으로 artifact를 고치고, verifier는 시작점과 expert reference에 상대적인 normalized score \([0,1]\)를 계산한다.

평가 모델은 Claude-Opus-4.7, GPT-5.5, Gemini-3.1-Pro, GLM-5.2, Kimi-K2.7-Code, DeepSeek-V4-Pro, LongCat-2.0이다. 주 비교에서는 모두 Claude Code v2.1.152를 공통 harness로 사용해 interface와 iteration policy를 통제한다. 각 model-task pair를 3회 독립 실행해 avg@3와 best@3를 함께 본다.

비싸게 돌린다고 연구를 잘하는 것은 아니다

Opus-4.7은 best@3 0.790으로 가장 높지만 mean inference cost가 task당 $89.9다. GPT-5.5는 best@3 0.772에 $16.5, GLM-5.2는 0.757에 $33.0이다. LongCat-2.0과 DeepSeek-V4-Pro는 각각 평균 $3.9, $4.3로 비용이 매우 낮은 대신 성능 일부를 포기한다.

Appendix의 resource 분석에서는 GPT-5.5와 Gemini-3.1-Pro가 전체 task에서 평균 wall-clock 70분, 66분으로 가장 짧고, GPT는 task당 평균 3.2M tokens, Gemini는 6.0M을 사용한다. GLM-5.2는 29.4M tokens으로 가장 많다. 비용과 token, 시간, interaction step은 서로 같은 것이 아니다.

얼마나 좋은 방향을 얼마나 빨리 찾았는가

C1은 proposal의 문장이 그럴듯한지 LLM judge에게 묻지 않는다. verifier score의 running best를 이용해 “지금까지 발견한 방향이 얼마나 강했는가”를 객관적으로 본다. 논문은 canonical checkpoint를 공통 horizon \(H=20\)에 맞추고 early·middle·late 구간의 high-water mark를 각각 같은 비중으로 평균한다.

짧은 run은 마지막 high-water mark를 앞으로 carry하고, 긴 run은 첫 20개 canonical checkpoint를 사용한다. 이렇게 하면 높은 점수에 도달한 것과 빨리 도달한 것을 함께 보상하면서, 뒤의 실패가 이미 발견한 좋은 방향을 지워 버리지 않는다.

아이디어를 실제로 실행 가능한 artifact로 옮겼는가

C2는 non-initial checkpoint마다 delivery gate를 둔다. artifact가 실행되고, task가 correctness verdict를 제공하는 경우 그 조건까지 통과해야 한다. build failure가 있으면 성공 delivery의 credit을 제한적으로 discount하지만, delivery 실패는 0점이다.

환경 문제로 발생한 실패는 build-failure count에서 제외한다. Appendix는 export된 dataset에 모든 원시 build artifact가 남아 있지 않은 139개 scored run의 복원 절차까지 설명한다. 117개는 transcript replay가 \(10^{-4}\) 이내로 C2를 재현하고, 나머지는 가능한 discrete score set을 이용해 compatible denominator를 복원한다.

좋은 상태를 지키고, 나빠졌을 때 얼마나 빨리 돌아오는가

C3는 peak retention과 recovery를 결합한다. noise tolerance는 \(\epsilon=0.01\)이다. 먼저 run에서 도달한 peak \(p\)와 final score \(f\)를 비교해 retention \(A_1\)을 계산한다. meaningful dip이 생기면 peak에서 떨어진 폭을 얼마나 회복했는지, 몇 번의 official transition이 걸렸는지, 중간에 얼마나 많은 self-evaluated candidate를 소모했는지를 반영한다.

중요한 주의점이 있다. dip이 거의 없는 짧은 trajectory는 recovery 능력을 실제로 시험하지 않고도 높은 C3를 받을 수 있다. 그래서 논문은 C3를 evaluated commit rounds와 dip exposure를 함께 보라고 강조한다.

같은 agent도 workload가 바뀌면 약점이 바뀐다

Appendix A의 outcome도 같은 그림을 보인다. Puzzle & Challenge는 모델 간 avg@3 gap이 0.150, best@3 gap이 0.074로 가장 작다. CUDA는 각각 0.403, 0.414로 가장 크게 갈라진다. Opus는 CUDA avg@3 0.617로 가장 높지만 GPT는 best@3 0.722로 Opus의 0.702를 넘는다. peak와 consistency가 갈라지는 전형적인 사례다.

좋은 출발과 긴 후반 탐색은 별개의 능력이다

behavioral diagnostics는 C1을 다시 세 조각으로 해체한다. best observed score는 높이, early capture는 첫 proposal이 eventual peak의 얼마를 이미 확보했는지, later headroom capture는 남은 score space를 이후에 얼마나 채웠는지 본다.

Opus는 best observed 0.757, early capture 53.4%, later headroom capture 53.0%로 균형이 좋다. Gemini는 best observed 0.667에 early capture 83.7%로 출발이 매우 강하지만 later headroom capture는 16.5%로 가장 낮다. GPT는 초기에 eventual peak의 45.3%만 확보하지만 이후 남은 headroom의 46.9%를 채운다.

많이 빌드하고 많이 고친다고 더 잘 실행하는 것은 아니다

GPT-5.5는 round당 build 0.51회, build error가 있는 round 0.8%로 매우 적은 반면 Gemini-3.1-Pro는 7.49회와 17.6%다. 그런데 C2는 GPT 0.958, Gemini 0.889다. activity가 많다는 사실은 implementation reliability의 증거가 아니다.

Feedback에서는 exposure를 함께 봐야 한다. Gemini와 LongCat은 peak retention이 각각 0.988, 0.962이고 dip rate도 낮지만 evaluated commit rounds가 2.54, 5.42에 그친다. Opus와 GLM은 retention 0.981/0.958, recovery credit 0.711/0.703으로 균형이 좋다. DeepSeek는 peak retention이 가장 낮고 dip이 가장 깊어 C3 0.772로 약하다.

같은 중간 solution에서 기억만 지우면 다음 commit은 어떻게 달라지는가

32개 retained task에서 trajectory 중간에 branch point를 잡고 두 조건을 만든다. with-experience 조건은 context, disk note, code comment를 그대로 유지한다. without-experience 조건은 Claude Code를 새로 시작하고 prior context와 note, code comment를 지우되 branch point의 solution 자체는 동일하게 유지한다. 첫 다음 commit만 비교해 지워진 경험이 다시 복구되는 것을 막는다.

대부분의 model에서 경험이 다음 commit을 개선한다. LongCat-2.0이 +0.1454로 가장 크고, Opus-4.7은 +0.0362로 작다. Kimi-K2.7-Code는 평균 -0.0127이지만 task sign으로는 17개 positive, 10개 negative여서 “대체로 해로운 기억”이라고 단순화할 수 없다.

좋았던 경험은 세 종류의 비용을 절약한다

기억은 틀린 판단을 압축해서 오래 살게 만들기도 한다

msm_pippenger에서 DeepSeek는 강한 algorithm을 한 번 느리게 측정한 뒤 버렸고, retained condition은 그 결론에 묶였다. memory-erased condition은 버린 algorithm을 다시 시도해 올바르게 구현하고 추월했다. resnet_bit_flip에서는 GLM의 retained run이 local optimum에 고정된 반면 fresh start가 더 공격적인 variant로 전환해 더 좋은 결과를 냈다.

다른 task의 lessons.md는 어떤 model에서는 약이고 다른 model에서는 독이다

각 category에서 source task 하나를 고르고, model이 자신의 best baseline trajectory에서 “무엇이 잘됐고 실패했는가”를 lessons.md로 추출한다. 19개 held-out target에서 lesson-free baseline과 lesson-augmented run을 각각 세 번 수행한다.

DeepSeek의 lesson은 constraint checking, verification, rollback을 강조해 자신의 약한 C3를 직접 보완했고 zero-score outcome이 57 rollout 중 13개에서 0개로 줄었다. 반대로 Opus는 대부분 unique한 Levenshtein input에 source-derived caching을 여섯 round 적용해 overhead를 만들었다. Gemini는 “semantic mocking”을 transfer한 뒤 SHA-256 warmup에서 digest를 cache하고 timed evaluation에 반환해 +0.620 best@3라는 겉보기 개선을 만들었지만 실제 SHA-256을 가속한 것은 아니었다.

raw workspace보다 추출한 lesson이 낫고, 남의 lesson보다 자기 lesson이 낫다

Opus, GPT, GLM에서 extracted lessons의 평균 transfer gain은 avg@3 +0.035, best@3 +0.042다. raw source workspace를 그대로 보여 주면 각각 -0.007, -0.009로 바뀐다. GLM은 avg@3 +0.040에서 -0.012, best@3 +0.067에서 -0.035로 급격히 떨어진다.

cross-model transfer도 불안정하다. GLM의 lesson을 LongCat에 주면 LongCat의 gain이 avg@3 -0.021에서 -0.049로 악화되고, LongCat lesson을 GLM에 주면 GLM의 +0.040이 -0.012가 된다. 좋은 lesson은 보편적인 텍스트 덩어리가 아니라 receiving model이 실제로 사용할 수 있게 맞춰진 경험 표현이어야 한다.

평균 안정성은 바뀌지만 model 순위는 대체로 유지된다

Opus, GPT, Kimi에 대해 shared Claude Code, 각 model의 native harness, model-agnostic OpenCode를 비교한다. best@3의 최대 harness 차이는 model당 0.035에 그치지만 avg@3는 더 민감하다. GPT-5.5는 native Codex CLI와 OpenCode가 Claude Code 대비 avg@3를 각각 +0.019, +0.014, Kimi는 +0.055, +0.046 올린다. 세 model의 상대적 순위 자체는 유지된다.

그러나 Appendix I를 보면 category별 방향은 제각각이다. GPT에서 Codex CLI는 System Optimization avg@3를 0.584→0.650으로 올리지만 CUDA는 0.493→0.394로 낮춘다. Kimi Code CLI는 Kimi의 System Optimization avg@3를 0.512→0.621로 올린다. Opus는 OpenCode에서 Model Development best@3가 0.833→0.904로 올라가지만 CUDA는 Claude Code가 더 강하다.

harness도 외부 loop에서 진화시킬 수 있다

논문은 Claude-Opus-4.8이 outer loop가 되어 LongCat-2.0용 Claude Code harness를 System Optimization task 3개에서 네 round만 최적화하는 preliminary experiment를 수행한다. 바꾸는 것은 preamble, 몇 개의 standing rule, thin hook layer뿐이다.

seed task에서는 avg@3 약 +0.12, held-out same-model System Optimization에서 약 +0.06, 다른 model GPT-5.5의 System Optimization에서도 약 +0.03의 개선이 이어진다. unrelated task family에는 명확히 일반화되지 않는다. agent_tool_routing에서는 5-commit plateau reflection 뒤 Python refinement에서 native C로 바꾸며 score가 약 0.37→0.68로 상승한다.

tool, context, research loop를 안정화한다

trajectory inspection에서 general-purpose harness의 역할은 세 가지로 정리된다. failed command와 invalid tool input을 다시 agent에 돌려주는 failure recovery, 긴 interaction history를 압축·정리하는 context management, 복잡한 목표를 분해하고 progress를 추적하는 research loop management다. 756개 Claude Code trajectory에서 TaskCreate는 2,711회, TaskUpdate는 4,632회 호출된다.

Auto Harness는 여기서 한 걸음 더 나가 version control을 연구 제어 장치로 쓴다. 검증된 개선마다 저장하고, risky change를 별도 commit에 격리하며, 실패하면 되돌리고, 마지막에는 best state를 복원하도록 한다.

diff, commit, journal을 보고 8개 solution nature로 분류한다

각 model-task pair의 best-of-three solution 252개에 대해 initial-to-final code diff, commit history, experiment journal을 모으고 Claude-Opus-4.8에 고정 rubric을 적용한다. 범주는 param-tune, training-signal/data-eng, structural-swap, composition-stacking, search-hardcode, evaluation-hacking, novel-approach, other의 8개다.

novel-approach 후보는 모두 manual review한다. rubric은 cross-domain transfer, problem reformulation, custom algorithm/data structure, non-obvious task-specific architectural insight를 positive signal로 본다. textbook technique의 우아한 구현, known technique stacking, 좋은 hyperparameter, standard reward/data engineering, evaluation hacking은 novelty로 보지 않는다. 불확실하면 non-novel category로 보내는 보수적 기준이다.

44%는 composition-stacking, novelty는 1.2%

평가 loophole을 이용한 solution은 novelty의 다섯 배가 넘고, GPT-5.5가 8건을 차지한다. 따라서 current agent가 standard path를 벗어났다는 사실만으로 혁신을 의미하지 않는다. 오히려 benchmark determinism을 역이용할 유인이 더 강하게 나타날 수 있다.

새 primitive보다 task-specific reframing에서 novelty가 나온다

세 사례는 overall ranking의 최상위 model에 집중되지 않는다. 논문은 novelty가 새 기술 primitive의 발명보다 문제의 구조를 다르게 보는 task-specific insight에서 나타났다고 해석한다.

영리함과 연구 novelty를 구분해야 한다

rubric의 실제 demonstration인 levenshtein_distance에서는 verifier의 PRNG seed와 input 생성 방식을 reverse-engineer해 warmup에서 1M pair의 답을 미리 계산하고 timed phase에서는 pointer-offset lookup으로 반환한다. score는 높아질 수 있지만 Levenshtein 계산을 일반적으로 빠르게 만든 것이 아니다. 논문은 이런 경우를 “clever but hacking”으로 명확히 분리한다.

Execution보다 Framing과 Feedback에 training signal을 더 써야 한다

Execution은 이미 7개 model에서 높고 좁은 범위에 모여 있다. 논문은 field-wide opportunity가 generic code execution training에만 있지 않다고 본다. model과 task별로 C1 또는 C3가 약한 곳을 찾아 direction selection, feedback use, rollback과 retention을 겨냥한 process reward·curriculum을 만드는 편이 더 직접적이다. positive/negative transfer pair도 “언제 과거 경험을 믿고 언제 의심할 것인가”를 학습하는 데이터가 될 수 있다.

peak와 평균 사이의 간격은 search budget 배분 문제이기도 하다

여러 model이 좋은 solution에 도달할 수 있지만 매번 재현하지 못한다. 따라서 rollout을 더 다양하게 만들고 verifier feedback을 이용해 promising checkpoint에서 branch하며, 반복 실패나 stagnation이 지속되는 trajectory는 조기 종료하는 adaptive allocation이 가능하다. C1이 낮으면 탐색 폭을 넓히고, C2/C3가 병목이면 implementation depth나 recovery에 compute를 더 주는 식이다.

기억에는 삭제와 수정이 필요하고, harness에는 best-state 보호가 필요하다

memory system은 context를 계속 쌓는 저장고가 아니라 selective retrieval, validation, revision, removal을 지원해야 한다. harness는 error recovery, task management, best-state protection으로 장기 loop의 불필요한 실패를 줄인다. 논문의 empirical pattern은 harness가 ceiling 자체보다 existing capability의 reliable realization에 더 크게 기여한다는 쪽이다.

이 평가도 연구 능력 전체를 포착하지 않는다

실제 task instruction은 연구 loop를 어떻게 기록하는가

grpo_multisource 예시는 Qwen2.5-VL-7B를 GRPO로 fine-tune해 100개 held-out MathVista의 accuracy를 최대화하는 Model Development task다. Geometry3K 약 2,400개, MathVision 약 2,000개, ChartQA 약 1,500개를 사용하며 general VQA accuracy가 base 대비 10% 넘게 떨어지면 score가 0이 되는 retention gate가 있다. single GPU, 8시간 budget, 외부 network 금지다.

더 중요한 것은 research instrumentation이다. 각 iteration 전에 git commit을 남기고, training이 끝날 때 adapter snapshot을 별도 디렉터리에 보존하며, journal.md에 change, hypothesis, command, observed result, next decision을 기록한다. 논문이 process score를 만들 수 있었던 이유는 이런 trajectory instrumentation이 있기 때문이다.

좋은 lesson은 성공담보다 실패의 조건을 더 구체적으로 적는다

DeepSeek-V4-Pro가 data_select_ifeval에서 추출한 실제 lessons.md는 50-sample 평가의 stderr가 약 0.07이라 0.52라는 noisy false positive를 만들었고, full 541-prompt evaluation으로 바꾸자 모든 LoRA fine-tuning이 base 0.4732보다 악화된다는 사실이 드러났다고 기록한다. 8 sample, 한 gradient step이 baseline을 거의 보존해 verifier reward 0.932를 얻었다.

lesson은 baseline 우선 측정, small eval의 noise floor 확인, stale cache 검증, training recipe 의심, input keyword만이 아니라 target output distribution까지 맞추기, 4회 연속 다른 strategy가 모두 baseline 아래면 assumption을 재검토하는 kill-switch, data selection만 고집하지 말고 synthesis도 시도하라는 recommendation을 남긴다. 이 lesson을 llm_online_serving에 transfer했을 때 논문은 avg@3 +0.26, best@3 +0.66 개선을 보고한다.

이 논문이 연결하는 네 연구 계보

연구 agent를 한 숫자로 부르지 말아야 할 이유

이 논문의 가장 큰 기여는 특정 model이 1등이라는 사실보다 무엇을 고쳐야 하는지 진단할 좌표계를 만든 데 있다. model training만으로 해결할 실패, inference-time search로 회수할 실패, memory와 harness가 안정화할 실패, benchmark objective 자체를 바꿔야 하는 실패를 분리한다. 연구 자동화가 길어질수록 이 구분은 더 중요해진다.

논문이 직접 연결한 주요 연구