Agent-as-a-Judge - 에이전트로 에이전트를 평가하기

Digest:

Context — 에이전트 시스템(여러 단계를 거쳐 도구를 쓰고 코드를 작성하는 LLM 기반 자율 시스템)이 실제 문제 해결에 투입되기 시작했지만, 평가 방법은 뒤처져 있다. 대표적 벤치마크 SWE-Bench(Yang et al., 2024a)는 최종 resolve rate만 보아 중간 과정에서 무슨 일이 일어나는지 알 수 없고(저자 비유: 객관식으로 학생을 평가하는 격), 인간이 직접 평가하면 신뢰도는 높지만 비용이 막대하다.

Insight — 에이전트는 인간처럼 단계별로 사고·행동하므로, 인간처럼 전체 사고·행동 궤적(trajectory)을 보는 풍부한 피드백으로 평가받아야 한다. 그래서 LLM이 LLM을 평가하는 LLM-as-a-Judge를 에이전트 차원으로 확장해, 에이전트가 에이전트를 평가하게 한다.

Solution — 인간 평가 과정을 모방한 8개 모듈 (graph·locate·read·search·retrieve·ask·memory· planning)로 구성된 Agent-as-a-Judge 프레임워크와, 55개 실세계 AI 개발 과제에 365개의 계층적 요구사항(requirement)과 125개의 선호(preference)를 단 DevAI 벤치마크를 제안한다. 요구사항은 의존 관계를 가진 유향 비순환 그래프(DAG)로 구성되어 이진 성공/실패보다 조밀한 피드백을 준다.

Evidence — DevAI에서 MetaGPT·GPT-Pilot·OpenHands 세 오픈소스 코드 에이전트를 평가한 결과, Agent-as-a-Judge는 인간 합의(consensus) 대비 정렬률(Alignment Rate)이 OpenHands에서 90.44%에 달해 LLM-as-a-Judge의 60.38%를 크게 앞섰고, 개별 인간 평가자(평균 85.70%)와 대등하거나 그 이상이었다. 비용은 인간 평가 86.5시간·약 1297.50 USD 대비 Agent-as-a-Judge는 30.58 USD·118.43분으로, **비용 2.29%·시간 2.36%**에 불과했다.

Implication — Agent-as-a-Judge는 에이전트의 자기개선(self-improvement)에 필요한 풍부하고 신뢰할 수 있는 중간 보상 신호를 제공하여, 과정 감독 보상 모델(PRM)과 평가자-피평가자 공진화 ‘플라이휠’의 토대가 될 수 있다. 다만 이는 개념 증명(proof-of-concept)이며 planning·memory 모듈은 오히려 성능을 해쳐 제외되었다.

섹션별 요약

Abstract

현대의 평가 기법은 에이전트 시스템에 부적합하다. 기존 접근은 (1) 최종 결과에만 집중하여 에이전트 시스템의 단계적 특성을 무시하거나, (2) 과도한 수작업을 요구한다. 이를 해결하기 위해 저자들은 에이전트 시스템으로 에이전트 시스템을 평가하는 Agent-as-a-Judge 프레임워크를 제안한다. 이는 LLM-as-a-Judge 프레임워크의 자연스러운 확장으로, 전체 문제 해결 과정에 걸쳐 중간 피드백(intermediate feedback)을 제공하는 에이전트 기능을 통합한다. 이 프레임워크를 코드 생성 과제에 적용하며, 기존 벤치마크의 문제를 극복하고 개념 증명 테스트베드를 제공하기 위해 55개의 현실적인 자동 AI 개발 과제로 구성된 새 벤치마크 DevAI를 제시한다. DevAI는 총 365개의 계층적 사용자 요구사항을 포함한 풍부한 수작업 주석을 담는다. 세 개의 인기 에이전트 시스템을 Agent-as-a-Judge로 벤치마킹한 결과, LLM-as-a-Judge를 압도적으로 능가하고 인간 평가 기준선만큼 신뢰할 수 있음을 확인했다.

저자 contribution

에이전트 시스템으로 에이전트 시스템을 평가하는 Agent-as-a-Judge 프레임워크를 제안하여, LLM-as-a-Judge의 비용 효율성을 유지하면서 전체 과정에 걸친 풍부한 중간 피드백을 제공한다.
55개의 종합적 AI 개발 과제로 구성되며 태그, 개별 계층적 요구사항, 개별 선호를 동반한 DevAI 데이터셋을 공개한다.
세 개의 최상위 오픈소스 코드 생성 에이전트 프레임워크(MetaGPT, GPT-Pilot, OpenHands)를 DevAI에서 벤치마킹하여 더 종합적인 평가를 제공한다.
전통적 인간 개입 비용 없이 신뢰할 수 있는 보상 신호를 제공함으로써 에이전트 자기개선의 토대를 마련한다.

왜 이 연구를 하는가?

핵심 질문: 단계별로 사고·행동하는 에이전트 시스템을, 인간 평가의 막대한 비용 없이 인간만큼 신뢰성 있게(중간 피드백까지 포함하여) 평가할 수 있는가?

기존 접근법의 한계

한계	설명
최종 결과만 보는 벤치마크	SWE-Bench(Yang et al., 2024a)는 장기 자동 수리 과제를 최종 resolve rate로만 평가하여, resolve rate에 영향을 준 에이전트 내부의 사건을 짚어내지 못한다. HumanEval·MBPP(Austin et al., 2021)는 단순 프로그래밍 과제에 한정된다.
벤치마크 오버피팅 / Goodhart’s law	최근 연구는 LLM이 고급 에이전트 없이도 SWE-Bench 과제의 27% 이상을 풀 수 있음을 보였고(Xia et al., 2024), 특정 데이터셋에 과적합되면 실세계 일반화가 떨어진다.
인간 평가의 비용·불안정성	더 나은 인간 평가는 금지될 만큼 비싸며, 개별 평가자 간 불일치율이 약 10~30%에 이른다(Figure 4).

핵심 통찰

에이전트 시스템은 인간처럼 단계별로(step-by-step, Wooldridge, 1999) 행동하고 내부적으로 인간 유사 상징 통신을 하므로(Zhuge et al., 2023), 전체 사고·행동 궤적을 보는 풍부한 피드백으로 인간처럼 평가받아야 한다.
따라서 에이전트 시스템으로 에이전트 시스템을 평가해야 하며, 이는 LLM-as-a-Judge의 비용 효율성을 유지하면서 중간 피드백 능력을 더한 자연스러운 진화다.

Introduction

최근 멀티모달 에이전트 시스템은 작은 장난감 문제를 가끔 푸는 수준에서, 도전적인 실세계 문제에 정기적으로 투입되는 수준으로 발전했다. 그러나 평가 방법과 벤치마크는 이 속도를 따라잡지 못해 실질적 진보를 크게 늦추고 있다. 저자들은 그 원인을 비전통적 시스템인 에이전트의 중간 문제 해결 단계에 대한 피드백 부재로 본다.

전통적 방식의 에이전트 평가는 객관식 시험으로 학생을 평가하는 것과 같아, 상대적으로 신뢰성이 낮은 추정량이다(Park, 2010). 반면 인간으로 더 나은 평가를 하는 것은 비용이 막대하다. 이에 저자들은 LLM-as-a-Judge(Zheng et al., 2024; Fu et al., 2023; Chen et al., 2024b)에서 영감을 받아 에이전트가 에이전트를 평가하는 Agent-as-a-Judge를 제안한다(Figure 1). 이는 LLM-as-a-Judge의 비용 효율성을 유지하면서 에이전트 기능을 갖춰 전체 과정에 걸친 풍부한 중간 피드백을 제공하며, 코드 생성 시스템 평가 문제에 적용된다.

Figure 1은 세 평가 패러다임을 대조한다. LLM-as-a-Judge는 LLM이 LLM을 평가하고, Agent-as-a-Judge는 에이전트가 에이전트를 평가하며(워크스페이스·환경과 상호작용하여 실제 파일 생성 여부 등을 확인), Human-as-a-Judge는 숙련된 인간이 수작업으로 에이전트를 평가한다. 인간 평가는 정확하지만 단계별 확인에 너무 많은 시간이 들어 개발 병목이 된다.

Methods

저자들은 두 축으로 방법을 구성한다: (A) 평가 대상이 되는 DevAI 벤치마크, (B) 평가자인 Agent-as-a-Judge 프레임워크.

(A) DevAI 벤치마크 — AI Developer Dataset. 전문 주석자가 만든 55개 실세계 AI 앱 개발 과제로 구성된다. 각 과제는 (1) AI 개발 과제를 기술하는 평문 사용자 쿼리, (2) 서로 의존 관계로 연결된 평문 요구사항 집합(총 365개), (3) 더 부드러운 기준인 선호(preference) 집합(총 125개)으로 정의된다. 요구사항은 종합 개발 과정의 마일스톤을 나타내며 유향 비순환 그래프(DAG)로 배열되어(He et al., 2021과 유사), 이진 성공 지표보다 조밀한 비희소(non-sparse) 피드백을 준다. 계층적 요구사항 덕분에 단순 암기로는 전체 과제를 풀 수 없다. 주제는 자동 AI 개발이며 지도학습·강화학습·컴퓨터비전·자연어처리·생성모델 등을 태그로 포괄한다(Figure 2). 과제는 현실적이되 계산적으로 저렴해 평가 비용을 낮춘다.

(B) Agent-as-a-Judge 프레임워크 (개념 증명). 인간 평가 과정을 모방해 8개의 상호작용 모듈을 설계했다.

graph — 파일·모듈·의존성을 포함한 프로젝트 전체 구조를 그래프로 구성하고, 코드 청크를 코드 스니펫으로 분해.
locate — 요구사항이 가리키는 특정 폴더/파일을 식별.
read — 단순 파싱을 넘어 코드·이미지·비디오·문서 등 33개 형식의 멀티모달 데이터를 읽고 이해, 다양한 데이터 스트림을 교차 검증.
search — 코드의 맥락적 이해를 제공해 관련 코드 스니펫과 숨은 의존성을 빠르게 검색.
retrieve — 긴 텍스트(궤적)에서 관련 구간을 식별·추출.
ask — 위 맥락을 바탕으로 주어진 요구사항이 충족되었는지 판정.
memory — 과거 판단 정보를 저장해 이전 평가 위에 쌓음.
planning — 현재 상태와 프로젝트 목표에 따라 다음 행동을 계획·순서화.

종합 ablation 결과 (1)graph, (2)locate, (3)read, (5)retrieve, (6)ask의 조합이 최고 성능을 냈다(Appendix K). planning은 의사결정이 불안정했고, memory는 이전 판단 오류가 연쇄 오류를 일으켜 오히려 해로웠으며, 현재 워크스페이스가 수백 줄 규모라 search 모듈의 이점을 충분히 살리지 못했다.

평가 설정: 평가는 black-box(궤적 데이터 접근 없이)와 gray-box(수작업으로 정성껏 수집한 궤적 데이터 사용, 실제로는 거의 접근 불가) 두 설정으로 수행된다.

발견 (Findings)

발견 1 — DevAI는 적절히 어렵다: 인간 평가 기준, 가장 잘한 두 방법(GPT-Pilot, OpenHands)도 요구사항의 약 29%만 충족(의존성 무시 시 약 44%)하며, 전체 요구사항을 다 만족한 과제는 단 1개뿐이었다(Table 2). DevAI가 현재·미래 방법에 상당하지만 적절한 난이도를 제공함을 보인다.
발견 2 — Agent-as-a-Judge가 LLM-as-a-Judge를 크게 능가: OpenHands 평가 시 Agent-as-a-Judge의 Alignment Rate는 black-box 90.44% / gray-box 92.07%로, LLM-as-a-Judge의 60.38% / 70.76%를 크게 앞섰다(Table 3). Requirements Met (I)의 Judge Shift는 Agent-as-a-Judge가 OpenHands에서 0.27%까지 낮은 반면 LLM-as-a-Judge는 최대 31.42%였다.
발견 3 — 인간 평가에 근접하거나 능가: Agent-as-a-Judge는 개별 인간 평가자 평균(85.70% 등)과 대등하고, PR 곡선 기준 OpenHands에서는 단일 인간 평가자보다도 우수했으며 다수결(majority vote)에 가장 근접했다(Figure 7). 일부 경우 인간 평가자를 거의 대체할 수 있다.
발견 4 — 인간 평가도 불완전: 개별 평가자 간 불일치율 약 10~30%, cn9o는 GPT-Pilot 평가에서 23.77% 오류를 냈으나, 세 명 다수결 적용 시 전체 오류율이 6.01%로 떨어졌다(Figure 5).
발견 5 — 모듈 누적 효과: ask만으로 65.03% → +graph 75.95% → +read 82.24% → +locate 90.44%로 상승, +retrieve는 OpenHands에선 추가 이득 없음(Table 4).

Results

기초 통계 (Table 1): MetaGPT가 가장 저렴(평균 1.19 USD)하고 OpenHands가 가장 비쌈(6.38 USD). 개발 시간은 OpenHands가 평균 362.41s로 가장 짧고 GPT-Pilot이 1622.38s로 가장 김. DevAI 전체를 한 방법으로 평가하면 평균 약 210.65 USD·약 14시간 소요. 출력 토큰은 GPT-Pilot이 최다(59707), OpenHands는 입력 토큰 최다(1252482)·출력 토큰 최소(8457)로 내부 통신이 풍부함을 시사. 저장 코드 줄 수는 GPT-Pilot 273.33줄 vs MetaGPT 11.15줄.

인간 평가 (Table 2): Requirements Met (I/독립) — MetaGPT 22.13%, GPT-Pilot 44.80%, OpenHands 42.89%. Requirements Met (D/의존성 고려) — 각각 6.55%, 28.96%, 28.68%. Task Solve Rate — MetaGPT 0.00%, GPT-Pilot 1.81%, OpenHands 1.81%. 인간 평가는 1라운드 약 58시간 + 합의 도출 28.5시간이 들었다.

AI 평가자 정렬 (Table 3): Agent-as-a-Judge는 모든 과제, 특히 의존성 있는 과제에서 LLM-as-a-Judge를 일관되게 능가. gray-box에서 양쪽 모두 black-box보다 더 나은 결과. Alignment Rate (Majority Vote 인간) 자체는 MetaGPT 95.08%, GPT-Pilot 93.98%, OpenHands 94.26%로 인간 다수결이 최상.

비용 (Section 4.4): 인간 평가 총 86.5시간, 시급 15 USD 가정 시 약 1297.50 USD. Agent-as-a-Judge는 API 호출 30.58 USD·118.43분으로 인간 대비 비용 2.29%·시간 2.36%. LLM-as-a-Judge는 10.99분으로 더 빠르나 지능적 맥락 선택 부재로 29.63 USD가 들어 비용 절감 폭은 작음.

Discussion

Outlook 1 — 에이전트 자기개선을 위한 중간 피드백: Agent-as-a-Judge의 핵심 힘은 효과적·효율적 최적화에 필수인 중간 피드백을 제공한다는 점이다(Zhuge et al., 2024; Pan et al., 2024). 에이전트가 복잡한 다단계 문제 해결 중 실시간으로 문제를 식별·수정할 수 있게 하며, 이를 통해 에이전트 개선용 과정 감독 보상 모델(PRM; Lightman et al., 2023)을 구축할 기회를 연다.

Outlook 2 — 플라이휠 효과: Agent-as-a-Judge와 피평가 에이전트가 반복 피드백으로 함께 진화하는 상호 개선의 순환은 유망한 방향이며, Agent-as-a-Judge를 핵심 메커니즘으로 한 에이전트판 self-play 시스템이 출현할 수 있다고 가설한다(Zelikman et al., 2022; Chen et al., 2024e).

한계 (저자 인정)

완벽한 Agent-as-a-Judge가 목표가 아닌 개념 증명이며, 자동 프롬프트 최적화·워크플로 설계 같은 고급 에이전트 최적화는 향후 과제로 남김.
planning 모듈은 절차가 불안정, memory 모듈은 오류 연쇄로 오히려 해로워 제외됨. 현재 워크스페이스가 수백 줄 규모라 search 이점을 충분히 못 살림.
코드 생성(자동 AI 개발)이라는 단일 도메인, 55개 과제·세 에이전트에 한정된 검증.

독자 식별 가능한 추가 한계

‘인간 합의’를 사실상 정답(ground truth) 대용으로 쓰지만, 저자도 인정하듯 합의 후에도 오차가 남아 정렬률 상한이 인간 편향에 의해 결정될 수 있다.
Judge Shift·Alignment Rate는 클래스 불균형(요구사항 충족이 드묾)에 취약해 음성 다수 예측으로 부풀려질 수 있다(저자가 PR 곡선으로 보완하나 부분적).
gray-box의 궤적 데이터는 수작업 수집으로 실제 환경에서 거의 접근 불가하다고 저자 스스로 밝혀, gray-box 우위의 실용성이 제한적.

이론적 의의

평가의 단위를 결과에서 과정으로 이동: 이진 resolve rate 대신 DAG 구조의 계층적 요구사항으로 평가하여, 에이전트의 어디서 무너지는지를 드러내는 조밀한 보상 신호 개념을 정식화한다.
LLM-as-a-Judge → Agent-as-a-Judge의 연속선: 판정자가 환경과 상호작용하며 실제 산출물(파일 생성·실행 결과)을 검증하는 능동적 판정 패러다임을 제시, 판정자의 ‘에이전트성’이 정렬 정확도를 끌어올림을 실증.
PRM·self-play의 토대: 신뢰 가능한 중간 보상은 과정 감독 보상 모델과 평가자-피평가자 공진화의 전제 조건이며, 본 연구는 그 실현 가능성의 첫 증거를 제공.

Discussion Points

논쟁점: 인간 합의를 정답 대용으로 삼은 Alignment Rate가 진짜 평가 품질을 측정하는가, 아니면 인간 편향에의 모방을 보상하는가? 합의 자체에 잔여 오차가 있다면 90%대 정렬률의 의미가 약해진다.
검증할 가정: “판정자의 에이전트 기능(워크스페이스 상호작용)이 정렬을 높인다”는 주장은 모듈 ablation(Table 4)에 의존한다. 다만 OpenHands 단일 대상이므로, 다양한 피평가 에이전트·도메인에서 graph/locate/read의 기여가 재현되는지 통제 실험이 필요하다.
후속연구: (1) memory·planning을 안정화해 장기·대규모 코드베이스로 확장, (2) Agent-as-a-Judge를 PRM으로 연결한 실제 자기개선 루프 실증, (3) 코드 생성 외 도메인(웹·로보틱스·과학)으로 일반화 검증.

실험 결과 상세

Table 2 — Human-as-a-Judge (consensus, white-box)

Metric	MetaGPT	GPT-Pilot	OpenHands
Requirements Met (I, 독립)	22.13%	44.80%	42.89%
Requirements Met (D, 의존성)	6.55%	28.96%	28.68%
Self-Termination	41.81%	5.45%	54.54%
Task Solve Rate	0.00%	1.81%	1.81%

Table 3 — AI Judge Alignment Rate (인간 합의 대비, ↑)

Judge / 설정	MetaGPT	GPT-Pilot	OpenHands
LLM-as-a-Judge (gray-box)	68.86%	71.85%	70.76%
Agent-as-a-Judge (gray-box)	92.07%	86.61%	90.16%
LLM-as-a-Judge (black-box)	84.15%	65.30%	60.38%
Agent-as-a-Judge (black-box)	88.52%	83.88%	90.44%
개별 인간 평균	89.34%	84.88%	85.70%
인간 Majority Vote	95.08%	93.98%	94.26%

Table 3 (발췌) — Judge Shift (괄호=인간 합의 대비 절대 편차, 낮을수록 정렬)

Metric	LLM-as-a-Judge (OpenHands, black-box)	Agent-as-a-Judge (OpenHands, black-box)
Requirements Met (I)	11.47% (31.42%)	42.62% (0.27%)
Requirements Met (D)	2.18% (26.50%)	26.50% (2.17%)
Task Solve Rate	0.0% (1.81%)	1.81% (0.00%)

Table 4 — 모듈 누적 Ablation (OpenHands 판정, Alignment Rate)

구성	+ ask	+ graph	+ read	+ locate	+ retrieve
Alignment Rate	65.03%	75.95%	82.24%	90.44%	90.16%

Table 1 (발췌) — AI Developer 기초 통계

Metric	MetaGPT	GPT-Pilot	OpenHands
평균 비용	$1.19	$3.92	$6.38
평균 시간(s)	(중간)	1622.38	362.41
저장 코드 줄 수	11.15	273.33	(입력 토큰 최다)

비용 비교 (Section 4.4)

평가자	시간	비용	인간 대비
Human-as-a-Judge	86.5 h	~$1297.50	기준
Agent-as-a-Judge	118.43 min	$30.58	비용 2.29% / 시간 2.36%
LLM-as-a-Judge	10.99 min	$29.63	더 빠르나 비용 절감 폭 작음

프레임워크 다이어그램

graph TB
    subgraph DEVAI["DevAI 벤치마크 (55 과제)"]
        Q["사용자 쿼리 (평문)"]
        REQ["요구사항 365개<br/>DAG 의존 구조"]
        PREF["선호 125개<br/>(softer)"]
    end

    subgraph DEVELOPER["피평가 AI Developer 에이전트"]
        D1["MetaGPT"]
        D2["GPT-Pilot"]
        D3["OpenHands"]
        WS["생성 워크스페이스<br/>(코드·파일·궤적)"]
    end

    subgraph JUDGE["Agent-as-a-Judge (8 모듈, 핵심 5개 사용)"]
        G["graph<br/>프로젝트 구조"]
        L["locate<br/>관련 파일 식별"]
        R["read<br/>33형식 멀티모달"]
        RT["retrieve<br/>궤적 구간 추출"]
        SR["search (보조)"]
        AK["ask<br/>요구사항 충족 판정"]
        MEM["memory (제외)"]
        PL["planning (제외)"]
    end

    OUT["요구사항별 충족/미충족 판정<br/>+ 중간 피드백"]
    HUMAN["Human-as-a-Judge<br/>합의 (정렬 기준선)"]

    Q --> D1 & D2 & D3
    REQ --> JUDGE
    D1 & D2 & D3 --> WS
    WS --> G --> L --> R --> RT --> AK
    SR -.보조.-> AK
    MEM -.오류연쇄로 제외.-> AK
    PL -.불안정으로 제외.-> AK
    AK --> OUT
    OUT -. Alignment Rate .-> HUMAN

재현성 및 신뢰도 평가

항목	등급	비고
코드 공개	✅	github.com/metauto-ai/agent-as-a-judge 공개(논문 명시)
데이터 공개	✅	DevAI 데이터셋 huggingface.co/devai-benchmark 공개, 55과제·365요구사항·125선호
하이퍼파라미터/설정	⚠️	1800초 타임아웃, 세 에이전트 선정 기준(GitHub 30,000+ stars) 명시; 판정 LLM 백본·프롬프트 세부는 부록 의존
실험 환경	⚠️	API 호출 기반(모델 버전·API 단가 가정), GPU 명세 비핵심; 인간 평가는 익명 3인(231a, 38bb, cn9o)
통계적 신뢰도	⚠️	365 요구사항 단위 집계이나 시드 반복·신뢰구간 없음; 클래스 불균형은 PR 곡선으로 부분 보완; 인간 합의를 정답 대용으로 사용
종합 등급	B	코드·데이터 공개로 재현 진입장벽 낮음. 단일 도메인·세 에이전트 한정, 정답 부재(인간 합의 대용)·통계 처리 미흡으로 완전 검증은 제한

주장별 신뢰도

주장	근거	신뢰도
Agent-as-a-Judge가 LLM-as-a-Judge 대비 정렬률 크게 우위(OpenHands 90.44% vs 60.38%)	Table 3 직접 대조	🟢
인간 평가 대비 비용 2.29%·시간 2.36%	Section 4.4 (86.5h· $1297.50 v s$ 30.58·118.43min)	🟢
모듈 누적이 정렬률을 단조 상승시킴(65.03%→90.44%)	Table 4 ablation, 단 OpenHands 단일 대상	🟡
DevAI가 적절한 난이도(최고 방법도 ~29% 요구사항, 전체해결 1과제)	Table 2 인간 합의	🟢
일부 경우 Agent-as-a-Judge가 단일 인간 평가자를 능가	Figure 7 PR 곡선(OpenHands), 정성 주장	🟡
memory·planning이 해로움	Appendix K ablation, 본문 정성 서술	🟡
인간 합의가 신뢰할 정답 근사	다수결 오류 6.01%·앙상블 논거, 단 잔여 오차 인정	🟡

축	Agent-as-a-Judge (본 논문, 2024)	LLM-as-a-Judge / MT-Bench (Zheng et al. 2024, base)	SWE-Bench (Yang/Jimenez et al. 2024, alternative)	MLAgentBench (Huang et al. 2024, alternative)	ChatEval (Chan et al. 2023, related)
핵심 접근	에이전트가 워크스페이스·환경과 상호작용하며 8개 모듈(graph/locate/read/retrieve/ask)로 요구사항별 판정	단일 LLM이 응답을 점수화/비교 판정	실제 GitHub 이슈 패치의 단위테스트 통과(resolve rate)로 자동 채점	미리 정의된 ML 과제의 최종 성능 지표로 에이전트 채점	다수 LLM의 다중 에이전트 토론으로 응답 평가
문제 정의	단계적 에이전트의 과정·중간 피드백 평가	LLM 출력 품질의 자동 판정	자동 소프트웨어 수리 능력	ML 연구 자동화 능력	대화·응답 평가 신뢰도 향상
데이터	DevAI 55과제·365요구사항·125선호(DAG)	MT-Bench/Chatbot Arena 대화	실세계 GitHub 이슈·PR	한정된 잘 알려진 ML 과제	대화 평가 셋
핵심 결과	OpenHands 정렬률 90.44%, 인간 대비 비용 2.29%	LLM 판정이 인간 선호와 높은 일치(GPT-4 judge)	LLM이 advanced agent 없이 27%+ 해결(Xia 2024)	최종 성능 중심 채점 보고	다중 에이전트가 단일 LLM 판정보다 인간 일치↑
규모	3 에이전트 × 365 요구사항	모델 다수·수천 비교	2k+ 이슈	과제 수십	대화 수백
한계	단일 도메인·개념증명, 인간 합의 대용 정답	최종 출력만, 위치/장황함 편향	최종 resolve만·과정 불투명·오버피팅	일반화·적응성 미평가, 오버피팅 위험	LLM만 평가·trivial 에이전트, 전통 평가 세팅
코드 공개	✅	✅	✅	✅	✅

원자적 인사이트 (Zettelkasten)

💡 판정자에게 ‘에이전트성’을 주면 정렬이 올라간다

출처: 본 논문 (Zhuge et al., 2024) · 유형: 실험적

판정을 LLM 한 번의 추론이 아니라, 워크스페이스를 읽고 파일을 찾고 멀티모달 산출물을 검증하는 에이전트 행위로 바꾸면 인간 합의와의 정렬률이 크게 오른다. OpenHands 평가에서 Agent-as-a-Judge는 90.44%를 기록해 LLM-as-a-Judge 60.38%를 30%p 이상 앞섰고, 모듈을 ask→graph→read→locate로 누적할수록 65.03%→90.44%로 단조 상승했다. 즉 ‘무엇을 보고 판단하는가’(근거 수집의 능동성)가 판정 품질을 좌우한다.
연결: LLM-as-a-Judge · Process Reward Model

💡 결과 채점에서 과정 채점으로 — DAG 요구사항의 조밀한 보상

출처: 본 논문 · 유형: 개념적

이진 성공/실패(resolve rate)는 에이전트가 어디서 무너지는지 알려주지 않는다. DevAI는 한 과제를 의존 관계를 가진 요구사항 DAG(총 365개)로 분해해, 부분 충족 정도를 비희소 신호로 측정한다. 그 결과 최고 방법도 요구사항의 약 29%만 충족하지만 그 분포가 에이전트의 실패 지점을 드러내며, 이는 강화학습의 희소 보상 문제를 보조 보상으로 푸는 발상과 같은 맥락이다.
연결: SWE-Bench · Sparse Reward · Process Reward Model

💡 인간 평가도 정답이 아니다 — 다수결로 6%까지 줄이기

출처: 본 논문 · 유형: 실패-한계

흔히 인간 평가를 정답으로 가정하지만, 복잡한 다단계 과제에서는 개별 평가자도 10~30% 불일치하고 한 평가자는 GPT-Pilot에서 23.77% 오류를 냈다. 세 평가자 다수결을 적용하면 합의 대비 오류율이 6.01%로 떨어진다(앙상블 분류기 성질). 평가의 신뢰성을 논할 때 ‘인간 기준선’조차 단일 측정으로 쓰면 위험하며, 토론 라운드나 5명 이상 패널 같은 보정이 필요하다.
연결: Inter-Annotator Agreement · Ensemble Methods

💡 더 많은 모듈이 항상 낫지는 않다 — memory·planning의 역효과

출처: 본 논문 · 유형: 실패-한계

인간 평가를 모방해 8개 모듈을 설계했지만, planning은 의사결정이 불안정했고 memory는 과거 판단 오류가 현재 판단으로 연쇄 전파되어 오히려 성능을 떨어뜨려 둘 다 제외되었다. 최종 최적 조합은 graph·locate·read·retrieve·ask 5개였다. 자율 시스템 설계에서 ‘능력 추가’가 노이즈·오류 전파를 키워 순효과를 음으로 만들 수 있음을 보여준다.
연결: Error Propagation · Agent Architecture

핵심 용어 정리

용어	정의
Agent-as-a-Judge	워크스페이스·환경과 상호작용하는 에이전트가 다른 에이전트를 요구사항별로 평가하며 중간 피드백을 제공하는 본 논문의 프레임워크.
LLM-as-a-Judge	LLM이 다른 LLM의 출력을 점수화/비교 판정하는 기존 패러다임. Agent-as-a-Judge의 출발점.
DevAI	55개 실세계 AI 개발 과제·365 계층적 요구사항·125 선호로 구성된 본 논문의 코드 생성 평가 벤치마크.
요구사항 (requirement)	개발 과정의 마일스톤을 나타내는 평가 단위. 서로 의존 관계(DAG)로 연결되어 비희소 피드백을 준다.
선호 (preference)	충족이 필수는 아닌 더 부드러운(softer) 평가 기준. 총 125개.
Alignment Rate	AI 판정이 인간 합의 평가와 동일한 요구사항 비율(365개 기준). 높을수록 인간에 정렬.
Judge Shift	인간 합의 결과 대비 평가자의 절대 편차. 낮을수록 정렬.
black-box / gray-box	궤적 데이터 접근 없이 평가(black) vs 수작업 수집 궤적을 사용(gray, 실환경 접근 어려움).
Human-as-a-Judge	숙련 인간이 수작업으로 에이전트를 평가하는 패러다임. 본 논문에선 3인 합의를 정렬 기준선으로 사용.
PRM (Process Reward Model)	최종 결과가 아닌 과정 단계마다 보상을 주는 모델. Agent-as-a-Judge가 토대를 제공한다고 주장.

BibTeX

@article{zhuge2024agentasajudge,
  title={Agent-as-a-Judge: Evaluate Agents with Agents},
  author={Zhuge, Mingchen and Zhao, Changsheng and Ashley, Dylan R. and Wang, Wenyi and Khizbullin, Dmitrii and Xiong, Yunyang and Liu, Zechun and Chang, Ernie and Krishnamoorthi, Raghuraman and Tian, Yuandong and Shi, Yangyang and Chandra, Vikas and Schmidhuber, J{\"u}rgen},
  journal={arXiv preprint arXiv:2410.10934},
  year={2024},
  url={https://arxiv.org/abs/2410.10934},
  eprint={2410.10934},
  archivePrefix={arXiv},
  primaryClass={cs.AI}
}

Agent-as-a-Judge - 에이전트로 에이전트를 평가하기

Agent-as-a-Judge - 에이전트로 에이전트를 평가하기

섹션별 요약

Abstract

왜 이 연구를 하는가?

Introduction

Methods

발견 (Findings)

Results

Discussion

이론적 의의

실험 결과 상세

프레임워크 다이어그램

재현성 및 신뢰도 평가

관련 연구 비교 매트릭스

원자적 인사이트 (Zettelkasten)

💡 판정자에게 ‘에이전트성’을 주면 정렬이 올라간다

💡 결과 채점에서 과정 채점으로 — DAG 요구사항의 조밀한 보상

💡 인간 평가도 정답이 아니다 — 다수결로 6%까지 줄이기

💡 더 많은 모듈이 항상 낫지는 않다 — memory·planning의 역효과

핵심 용어 정리

관련 연구

태그

BibTeX