AutoSciBench는 과학 에이전트 벤치마크를 스스로 어렵게 만든다

무엇인가

에이전트 성능이 빠르게 오르면서 기존 벤치마크는 포화되고, 특히 과학 도메인에서는 벤치마크를 만들고 갱신하는 데 막대한 시간과 노동, 도메인 전문성이 필요해 평가가 에이전트 발전 속도를 따라가지 못한다. 저자들은 이 격차를 "벤치마크 자체를 자동으로 생성하고, 에이전트가 발전하는 만큼 반복적으로 적응시킬 수 있는가"라는 질문으로 정식화한다. 논문은 과학 에이전트 평가가 일반 LLM 평가와 갈라지는 두 지점을 먼저 짚는다. 첫째, LLM 과제는 정답에 필요한 정보가 입력 컨텍스트나 모델의 파라메트릭 지식 안에 있지만, 에이전트 과제는 환경(데이터·도구)과의 상호작용을 통해 정보를 획득해야 하므로 계획·도구 실행·관찰·분석이 필요하다. 둘째, 코드나 웹 환경에서는 실행 오류나 상태 변화라는 명시적 피드백이 있어 실패를 진단하고 계획을 고칠 수 있지만, 과학 분석의 중간 산출물은 '정답인가'에 대한 피드백이 아니라 관심량이나 가설에 대한 증거일 뿐이다. 그래서 과학 에이전트 과제는 원시 데이터 재검토, 중간 결과 검증, 여러 분석 단계의 증거 통합 능력을 평가해야 한다.

어떻게 동작하나

AutoSciBench는 과제 구성을 두 층의 계획으로 나눈다. 상위 계획인 concept은 과학 도메인 d, 데이터 모달리티 m, 요구 연산 집합 O의 튜플 c=(d,m,O)로 표현되며, 무엇을 평가할지만 규정하고 구체적 인스턴스화는 남겨 둔다. 하위 계획인 recipe는 이 요구사항을 구체적인 질문·데이터 설계로 번역하면서, 어떤 정보를 질문에 직접 명시하고 어떤 정보를 solver가 분석을 통해 획득해야 하는지를 정한다. 초기 concept은 두 갈래 외부 소스에서 나온다. 하나는 기존 과학 에이전트 벤치마크의 시드 질문과 데이터 파일에서 도메인·모달리티·요구 연산을 추출하는 것이고, 다른 하나는 해당 분야 논문을 검색해 과학적 목표가 일련의 분석 단계로 해결되는 워크플로를 추출한 뒤, 연구별 세부를 추상화하고 반복되는 분석 단계와 결정 지점을 보존한 재사용 패턴으로 일반화하는 것이다.

무엇과 다른가

구현 단계에서 에이전트는 라운드 t의 concept c_t와 recipe r_t로부터 질문 q_t, 데이터 파일 집합 F_t, 정답 a_t로 이루어진 과제 Q_t를 만든다. 데이터를 확보·구성하고, 정답을 계산·검증하고, 해법 절차는 제시하지 않은 채 분석 대상·입력 파일·답 형식만 적은 질문을 작성한다. 그다음 K회의 독립 solver 시행을 돌려 궤적과 최종 답을 모으고, judge가 두 가지를 평가한다. 검증 가능성(질문과 데이터가 명확하고 재현 가능하게 채점할 수 있는 답을 뒷받침하는가)과 난이도(K회 시행에서 정답을 얼마나 안정적으로 도출하는지, 즉 경험적 solve rate)다. 궤적은 의도된 검증이나 증거 통합을 우회하는 지름길 경로와 오답을 만든 분석 오류를 드러내는 데도 쓰인다. 과제가 검증 가능하면서 동시에 어렵지 않으면 judge 피드백과 구성 기록을 바탕으로 recipe를 고치거나 concept 자체를 바꾼다. recipe 수정은 concept을 유지한 채 데이터와 질문 설계를 바꿔, 중간 출력을 그대로 쓰는 대신 추가 검증·해석·증거 통합을 요구하도록 만든다. concept 수정은 평가 목표 자체를 바꿔 이전 concept이 요구하지 않던 다른 형태의 추론과 연산을 요구하게 한다. 라운드마다 쌓이는 concept·recipe·구현 과제·구현 실패 기록·judge 판정은 그 실행의 refinement history가 된다.

어떻게 쓰나

정제는 한 concept 안에서 과제를 개선하지만, 거기서 얻은 교훈은 그 과제를 넘어 쓸모가 있다. AutoSciBench는 정제 이력을 재사용 가능한 경험으로 증류한다. concept에 대한 정제가 끝나면 에이전트가 여러 라운드의 구성·평가 기록을 검토해, 어떤 설계가 직접 답을 허용했는지, 어떤 수정이 solver 행동을 바꿨는지, 검증 가능성이나 난이도를 막은 미해결 문제가 무엇인지를 요약해 경험 카드를 만든다. 누적된 경험 카드가 경험 메모리를 이루고, 이후 concept 생성은 외부 소스 사전지식과 함께 이 메모리에서 고른 카드를 사용한다. 이미 생성한 concept 목록도 함께 제공해 중복 제안을 억제한다. 정제가 어렵고 검증 가능한 과제를 만들어냈든 그렇지 않았든 경험은 모두 보존된다.

전제와 한계

실험은 컴퓨테이셔널 바이올로지, 재료과학, 임상 영상 세 분야에서 이뤄졌다. 시드 벤치마크는 각각 CompBioBench, MatTools, MedCTA이고, 분야마다 무작위로 고른 시드 질문 100개에서 사전 concept을 추론하고 해당 문헌에서 뽑은 분석 워크플로로 보완했다. 생성기로는 Claude Code CLI에 Claude Opus 4.8, Codex CLI에 GPT-5.6 Sol을 쓰고, 각 생성기가 정제 과정에서 solver 역할도 겸했다. 도메인당 50개 과제를 경험 기반 concept 생성 5회 반복(각 10개 concept)으로 만들고, concept마다 최대 10라운드(초기 구성 라운드 포함) 정제했다. 최종 벤치마크는 정제 실행마다 과제 하나를 골라 구성하되 난이도 평가가 높은 쪽을 우선했다. 결과적으로 생성 벤치마크는 사람이 만든 벤치마크 대비 평균 solver 정확도를 컴퓨테이셔널 바이올로지에서 22.4%p, 재료과학에서 25.5%p 떨어뜨렸다. 재료과학에서는 원본 벤치마크의 정확도가 천장 근처에 몰려 있던 반면 생성 벤치마크에서는 변별이 크게 나타났다. 품질 평가(검증 가능성·유용성·적합성을 1~5점으로 채점)에서는 세 도메인 모두 생성 벤치마크가 사람이 만든 벤치마크보다 높은 평균 점수를 받았다.

흥미로운 대비도 있다. Claude Opus 4.8이 생성한 벤치마크가 GPT-5.6 Sol이 생성한 벤치마크보다 평균 solver 정확도가 더 낮았는데(더 어려움), solver로서는 GPT-5.6 Sol이 Claude Opus 4.8보다 전반적으로 우수했다. 즉 더 잘 푸는 능력이 더 어려운 과제를 만드는 능력과 일치하지 않는다. 또한 생성기 이후에 나온 모델들은 생성 벤치마크에서 큰 폭으로 정확도가 올랐다. Opus 5.0은 Opus 4.8보다 19.5%p, GPT-6 Astra는 GPT-5.6 Sol보다 15.1%p 높았다. 절제 실험에서는 재료과학·Claude Opus 4.8 조건에서 경험 기반 concept 생성이 solver 성공률을 66.7%에서 35.0%로 낮추고, 어려운 과제 비율을 15.0%에서 50.0%로 끌어올렸다. recipe를 제거하거나 concept과 recipe를 모두 제거하면 정제 라운드가 진행돼도 solver 성공률이 더 높게 유지됐는데, 이는 인스턴스화된 과제를 직접 고치는 것보다 구조화된 계획을 수정하는 편이 난이도를 올리는 데 효과적임을 시사한다. 정성 사례도 하나 제시된다. 초기 과제는 서로 다른 UMI 시퀀스를 세면 원래 UMI 수가 복원됐지만, 수정 과제는 UMI 시퀀스 오류를 도입해 원래 UMI 간 차이와 오류로 인한 서열 변이를 읽기 지지도와 함께 구분해야 하도록 바꿨다. 수정 과제에서 세 번의 solver 시행 모두 에이전트가 서로 다른 UMI 시퀀스를 별개의 원래 UMI로 취급해 오답을 냈다.

실무 관점에서 이 논문이 주는 것은 도구라기보다 벤치마크 운영 방식이다. 사내 에이전트가 논문·실험 데이터·도구를 다루는 분석 파이프라인에 들어간다면, 고정된 평가셋은 몇 달 만에 포화된다. AutoSciBench의 구조는 그때 참고할 만한 레퍼런스 아키텍처다. 평가 목표를 concept으로, 질문·데이터 설계를 recipe로 분리해 두면 solver 피드백에 따라 어느 층을 고칠지 결정할 수 있고, 정제 이력을 경험 카드로 남기면 다음 평가셋 생성에 재사용할 수 있다. 도입 시 확인할 점은 세 가지다. judge가 LLM이라는 점, 생성기와 solver를 같은 모델로 돌렸다는 점, 그리고 '어려움'을 경험적 solve rate로 측정한다는 점이다. 난이도가 올라간 것이 실제 과학적 추론 요구가 늘어난 결과인지, 아니면 모호성이나 구현 결함이 늘어난 결과인지는 검증 가능성 점수와 궤적을 함께 봐야 판단할 수 있다.

논문은 별도의 한계 절을 두지 않았지만, 본문에서 확인되는 전제와 제약은 분명하다. 정제 루프에서 생성기와 solver를 같은 모델로 썼고, 다른 모델로도 난이도가 전이된다고 보고하지만 검증 범위는 세 도메인·도메인당 50개 과제, concept당 최대 10라운드로 제한된다. 품질 평가는 Claude Opus 4.8과 GPT-5.6 Sol 두 LLM judge가 수행하므로, 생성 파이프라인과 평가자가 같은 모델 계열에 겹친다는 점을 감안해야 한다. 초기 concept은 기존 벤치마크와 문헌에 의존하므로 시드 품질과 문헌 검색 범위가 결과의 상한을 정한다. 또한 저자들 스스로 생성기 이후에 나온 모델들이 생성 벤치마크에서 큰 폭으로 정확도를 올린 사례를 보고하는데, 이는 자동 생성 벤치마크도 결국 갱신을 멈추면 포화된다는 것을 보여준다.