A Vocabulary for Multi-Agent Automated Research Systems

이 논문은 multi-agent 연구 자동화 시스템들이 여러 설계를 동시에 바꿔 어느 선택이 성능을 바꿨는지 가리기 어려운 문제를, 시스템을 여덟 요소의 tuple로 적는 공통 vocabulary를 정의하는 방법으로 다뤘다.

이 논문은 한마디로 multi-agent 연구 자동화(autoresearch) 시스템의 설계를 agent, operation, 통신, capability, 공유 상태, control policy, 초기화, evaluator 여덟 요소의 tuple로 적게 하는 개념 논문이다. operation 목록(무엇을 할 수 있나)과 capability 할당(누가 할 수 있나)을 나누고, evaluator를 시스템의 한 요소로 넣어 보고된 성능 향상이 탐색에서 왔는지 evaluator의 허점에서 왔는지 구별하게 했다. 시스템에 taste(좋은 연구를 알아보는 감각)가 부족하다는 불만은 점수를 보기 전에 새로운 시도를 내놓는 비율(generative taste)과 proxy 점수와 실제 품질의 차이(evaluative taste)로 나눴다. 저자는 AIRA2(ML 연구 benchmark용 autoresearcher), AlphaEvolve, Glia, AI Scientist-v2 등 시스템 10개를 이 틀로 옮겨 적어, 각 시스템이 직접 정하는 요소는 몇 개뿐이라는 것을 보였다.

핵심 요약

• 문제: 최근 multi-agent LLM 시스템은 선행 연구 읽기, 아이디어 제안, 코드 작성, 실험, 결과 해석을 끝까지 자동화하지만, 시스템끼리는 통신 구조, 실행 사이 기억, 초기화, evaluator 같은 여러 설계가 동시에 다르다. 그래서 multi-agent 시스템이나 autoresearcher가 더 낫다는 주장은 어느 설계가 바뀌었는지 알기 전까지 모호하고, 이런 시스템을 같은 말로 기술할 공통 언어도 없었다.
• 입력과 출력: 연구 자동화 시스템의 설명(논문)을 받아 그 설계를 문제 tuple과 시스템 tuple의 요소로 옮겨 적고, 시스템이 직접 정한 요소(set)와 기본값으로 둔 요소(generic)를 표시한 지도를 낸다. 한 번의 실행은 입력 과제에서 반환 산출물까지의 trajectory로 기록하며, agent, operation, 초기화가 확률적일 수 있어 같은 과제를 반복 실행하면 trajectory 분포가 나온다. 논문 종류는 이 vocabulary를 정의하고 기존 시스템 10개에 적용한 사례 분석을 붙인 개념 논문이다.
• 방법: 시스템은 agent 집합, operation 목록(tool, skill, MCP(Model Context Protocol) server 호출 등), 통신 구조, capability 할당, 공유 상태, control policy, 초기화, evaluator의 여덟 요소 tuple로 적는다. 공유 상태는 한 실행 동안 유지되다 끝나면 지워지는 상태, agent가 다루는 외부 환경, 실행 사이에 이어지는 상태로 나누고, control policy는 다음에 누가 무엇을 할지 정하는 routing, 실행을 끝내는 stopping, 실행 중 구조를 바꾸는 meta-control(spawn, kill, grant, revoke, consolidate 등), 무작위성을 정하는 exploration 항으로 나눈다. trajectory의 각 단계 행동은 operation 호출, message, 구조 변경, 종료로 나눠, 언제 소통하고 언제 agent를 늘릴지를 policy의 선택 문제로 다룬다.
• 주장: 저자는 시스템을 예산 안에서 proxy evaluator 점수를 최대로 하는 탐색으로 보고, 같은 agent와 tool도 Best-of-N처럼 탐색을 늘리면 다른 요소는 그대로 둔 채 점수가 오를 수 있다고 짚었다. 많은 trajectory를 순위 매길수록 evaluator가 실제 품질을 부풀린 trajectory가 맨 위에 오기 쉬워지는 overfitting tax를 정의하고, MLR-Bench가 감사한 coding agent 과제 10개 중 8개(약 80%)에서 조작되거나 무효인 결과가 나온 보고를 근거로 들었다. taste는 점수를 보기 전에 새 trajectory를 내놓는 비율인 generative taste와 proxy 점수와 실제 품질의 차이인 evaluative taste로 나누고, 더 강한 generator를 인정하기 전에 evaluator integrity(점수를 실제 품질에 가깝게 붙잡아 두는 구조적 보호)부터 높이라고 제안했다.
• 사례 적용: AIRA2, AlphaEvolve, Glia, AAR(Automated Alignment Researcher), AI Scientist-v2, MetaGPT, EvoX, ml-intern, SimpleTES, Engram을 tuple로 옮겨, 예를 들어 Glia의 핵심은 Supervisor의 operation 집합을 비워 둔 capability 할당이고 AIRA2는 실행 사이 population 저장소와 meta-control을 정한다고 정리했다. 이 지도에서 실행 중 capability를 바꾸는 시스템은 없었고, 모든 시스템이 exploration 항을 기본 temperature로 두었으며, control policy를 실행 중 다시 쓰는 시스템은 EvoX 하나였다. 저자의 GitHub 저장소 BardiyaAk/multi-agent-research-vocabulary는 README 기준으로 여덟 요소 tuple 설명, 사례 10개의 구조 그림과 비교 표를 담은 정적 project page와, 비교 자료의 원본 tools/coords.json과 이를 변환하는 tools/build-data.py를 공개한다.
• 한계: 저자는 각 시스템을 해당 논문의 설명 그대로 옮겨 적었으므로 이 표시는 서술용 지도이고 검증된 측정과 구별된다고 밝혔다. 표시된 요소는 그 논문이 직접 정한 요소를 뜻하고, 그 요소가 성능을 올렸다는 근거와는 구별된다. generative taste는 novelty 척도가 마련되기 전까지 정성적 개념으로 두었고, 실제 품질은 일반적으로 계산할 수 없어 측정값보다 설계 목표로 남는다고 적었다.

논문 링크

외부 연구를 정리한 자료입니다. HDATF가 발표한 논문이나 제품 성능을 측정한 결과는 아닙니다.