평가 체계 길잡이쉽게 + 깊게

오른쪽 작업창에서 만들어지고 있는 AI 에이전트 평가 체계를 처음 보는 사람도 이해하도록 정리했습니다. 각 상황이 무엇이고, 어떤 지표를 왜 보며, 바탕에 깔린 배경 개념과 앞으로의 방향이 무엇인지 — 비유로 쉽게, 실제 숫자·수식·DB 컬럼까지 깊게.

기준일 2026-06-16 · 근거: eval_ph1 trace DB(PostgreSQL) + eval_v2 research DB 실측 · 운영 대시보드 6종으로 연결

0 한눈에 — 우리가 하는 일

한 문장: AI 에이전트가 일을 얼마나 잘하는지 시험으로 재고, 모든 실행을 데이터베이스에 남기고, 한 번에 한 가지만 바꿔서 "그 변경이 진짜 효과가 있었는지"를 숫자로 증명한다.

쉽게 말하면 요리사(에이전트)에게 같은 요리를 시키고, 주방 CCTV(궤적)를 전부 녹화한 뒤, "소금을 조금 줄였더니 맛이 더 좋아졌나?"를 손님 평점(지표)으로 비교하는 실험실입니다. 감(感)이 아니라 기록과 숫자로 판정합니다.

지금 두 갈래의 작업이 동시에 진행됩니다. 둘 다 "측정 → 진단 → 1변수 개선 → 재검증"이라는 같은 규율을 씁니다.

A. eval_ph1 — 라이브 플라이휠

AutoGen 멀티에이전트 팀(Planner·Executor·Critic 등)을 GAIA·리서치·분석 벤치마크로 돌려 모든 이벤트를 trace DB에 기록. 팀 구성을 1변수씩 바꿔(EXP-65~68 등) 효과를 검증하는 가동 중인 개선 루프.

B. eval_v2 — 리서치-에이전트 평가 DB

리서치 에이전트(solo·pipeline·orchestrator·critic 4팀)의 실행을 정규화된 22테이블 DB에 보존하고, GLM-5.1 루브릭 채점 + 비용·실패·인용 충실도까지 자동 산출하는 차세대 관측 기반.

벤치마크 도메인
GAIA·리서치·분석

실험(EXP) 원장
13 채택·5 기각·2 보류

720

완료 run
(14,773 이벤트)

v2 DB 테이블
+ 3 뷰

~75%

권장 지표
구조적 커버

0/0

정합성 위반
(숫자 신뢰의 조건)

숫자는 2026-06-13~16 스냅샷. "0/0 정합성"은 아래 측정의 함정에서 설명합니다.

1 배경 개념 — 바탕부터

지표를 읽기 전에 알아야 할 6가지 토대. 각 항목은 "쉽게 말하면 → 깊게"의 순서입니다.

1.1 에이전트 평가 vs 모델 평가

쉽게 말하면 모델 평가는 "이 질문에 한 번에 답을 잘 쓰나?"(필기시험 한 문제). 에이전트 평가는 "여러 역할이 협업하며, 도구를 쓰고, 서로 검토해서 끝까지 임무를 완수하나?"(팀 프로젝트 전 과정)입니다.

모델 평가는 단일 응답 한 방을 본다. 에이전트 평가는 오케스트레이션 사슬 전체를 본다 — 계획(planner) → 실행/도구호출(executor) → 검토(critic) → 라우팅(누구에게 넘길지) → 재시도. 그래서 "어느 단계에서 깨졌는가"를 물을 수 있고, 그게 개선의 핵심 질문이 된다.

1.2 벤치마크 3종 — 무엇을, 왜 어렵게 재나

"벤치마크"는 표준 시험지다. 세 도메인은 서로 다른 능력을 겨눈다.

벤치마크	무엇을 재나	정답 방식 / 채점	왜 어려운가
GAIA L1·L2·L3	다단계 추론 + 도구 사용(파일·계산·웹)으로 정해진 정답 맞히기	gold 정답 존재 → exact-match(정규화 후 정확 일치, 숫자 허용오차·리스트 순서)	한 단계라도 틀리면 오답. "What color is Goldfinger?" → orange, white
multi-hop 리서치 hop 1~3	여러 문서를 연결해 추적(A→B→C)하고 출처를 대기	gold 출처 집합 → cite_f1(인용 정밀도·재현율의 조화평균)	비활성/함정 문서(decoy)에 낚이기 쉬움. "Vesta 운영팀 관리자?" → Lena Patel
open-ended 분석	정답이 없는 시장·기술 분석 리포트 작성 (예: 반도체 동향)	gold 없음 → format_valid(형식)로 success, 품질은 grounded% + 출처수로 별도 측정	그럴듯한 환각을 쓰기 쉬움. "정답"이 없어 채점 설계 자체가 도전

함정분석 도메인은 정답이 없어서 "success=형식 통과"로만 정의한다. 즉 success가 높다고 내용이 좋은 게 아니다 — 내용 품질은 grounded%·출처수·recency 같은 다른 축으로 봐야 한다. (자세히는 1.6 그라운딩)

1.3 팀 구성과 토폴로지 — 누가 어떤 순서로 말하나

쉽게 말하면"토폴로지"는 회의 진행 방식이다. 한 명이 다 하나(solo), 컨베이어벨트처럼 차례로(pipeline), 사회자가 다음 발언자를 지목하나(selector/orchestrator), 마지막에 감수자가 검토하나(critic).

토폴로지	구성	특징	실제 팀
Solo	1 에이전트	도구 셋업 0, 가장 단순한 기준선	research-a-solo
Pipeline (round-robin)	Planner→Searcher→Writer (정해진 순서 반복)	역할 분담 명확, 예측 가능	research-b-pipeline
Orchestrator (selector)	Lead가 다음 발언자 동적 선택 + 병렬 Searcher 2 + Writer	리드가 분해·위임, 병렬 탐색	research-c-orchestrator
Critic	위 + Critic(누락 인용·모순 검증, Writer에 1회 수정 기회)	품질 게이트, 자기교정 루프	research-d-critic · GAIA v1-baseline

함정 — 구조를 더 얹는다고 좋아지지 않는다강한 모델 앞에서 토폴로지를 복잡하게 만드는 개입은 거의 다 실패했다. RoundRobin 토폴로지 전환은 성공률을 97%→7%로 무너뜨렸고(EXP-60), disambiguation 프롬프트는 80%→27%(EXP-63). "더 정교한 구조 ≠ 더 좋은 결과."

1.4 궤적(trajectory)과 이벤트 — 에이전트의 CCTV

한 번의 실행(run)은 순서가 매겨진 이벤트들의 사슬로 기록된다. 이게 "왜 됐/안 됐나"를 사후에 추적하는 유일한 근거다.

run_id ─► [agent_message] ─► [tool_call: web_search] ─► [tool_result: hits] ─► [agent_message: 합성] ─► [selector_decision: → critic] ─► [final_answer: "FINAL ANSWER: ..."] ─► [evaluator_score]

eval_ph1은 14,773개 이벤트를 저장(2026-06-14). eval_v2는 공급자별 다른 형식을 정규 trace_steps(generation·tool_call·tool_result·response·citation)로 통일하고, 한 실행 안에서만 ID가 유효하도록 이름공간을 부여한다(예: att-...:lead).

1.5 그레이더 — 누가 채점하나

종류	방식	장점 / 한계
결정적 채점 (deterministic)	코드로 비교: 정규화 후 exact-match, F1, 토큰/도구호출 카운트	재현 100%·공짜·빠름 / "맞다/틀리다"만, 뉘앙스 못 잼
LLM-judge 루브릭	강한 모델(GLM-5.1/Claude)이 근거팩(인용·도구호출)을 보고 항목별 0~1 채점	품질·근거성 평가 가능 / 비결정적·비용↑ → 보정(calibration) 필요

핵심 설계 — not_assessableLLM-judge는 근거(인용)가 0개면 0.5(중간점)을 주지 않고 not_assessable(평가불가)를 반환한다. "근거 없음"을 "평균 점수"로 위장하지 않는, 정직성 장치다.

1.6 그라운딩(grounding) — 진짜로 찾아봤나

쉽게 말하면stale(고인 지식)=웹 검색 없이 머릿속(학습 시점 2024)에서 답함. grounded(접지)=실제 web_search로 최신 근거를 찾아 답함. 시험을 오픈북으로 보느냐의 차이.

분석 도메인에서 그라운딩은 가장 중요한 품질 축이다. 그런데 여기에 두 개의 미묘한 지표가 있고, 이 둘의 차이가 곧 환각 위험이다:

grounded% — 실제로 검색해서 결과를 받았나(접지 여부). 견고한 사실 신호.
recency — 리포트 텍스트가 "2026" 같은 최신 시점을 언급했나. 약한 텍스트 신호 — 환각으로도 만들어질 수 있다.

함정 — recency ≠ grounded한 팀은 recency 0.84(최신처럼 보임)인데 grounded 0.0(실제론 검색이 차단돼 못 찾음)이었다. "최신인 척하지만 근거는 없는" 상태 = 환각 위험. 이 간극을 잡으려고 grounded%를 events의 web_search 호출/결과 기준으로 잰다 — 리포트 본문의 URL 개수로 재면 합성기의 인용 변덕에 휘둘린다(18회 검색하고도 출처 0인 사례 존재).

2 지표 — 무엇을 왜 보나

지표는 4가지 묶음으로 본다. 핵심 규칙: 품질과 비용은 언제나 같이 본다.

개선의 두 모양 ① dominant(우월): 품질↑ 이면서 비용↓ (예: EXP-66 — 토큰 −82%인데 grounded 유지). 무조건 채택.
② 트레이드오프: 능력↑ 대신 비용↑ (예: 검색을 켜서 정답률↑이지만 토큰↑). 가치 판단 필요.
그래서 pass@1만 보면 안 되고 tokens·latency·grounded%를 한 화면에 같이 놓는다.

2.1 전체 지표 사전

① 품질 (잘 맞혔나)

지표	정의 / 수식	출처(DB)	좋은 방향
success	GAIA·리서치=정규화 후 exact-match. 분석=format_valid	runs.success	↑ (같은 task 비교)
format_valid	"FINAL ANSWER" 형식을 지켰나 (실패의 종류 구분용)	runs.format_valid	↑
pass@k	k번 중 1번이라도 성공(pass_any) / 전부 성공(pass_all). pass@1과의 갭=불안정	mv_passk	↑, 갭↓
cite_f1 (리서치)	F1(예측 출처, gold 출처) = 정밀도·재현율 조화평균	v_research_grounding	↑

② 비용 (얼마나 들었나)

지표	정의 / 수식	출처(DB)	좋은 방향
total_tokens	input(근거 흡수)+output(생성). 곧 돈.	runs / attempts	↓ (품질 유지 시)
tokens_per_success	총토큰 ÷ 성공수 = 정답 1건당 비용	mv_batch_summary	↓
estimated_cost_usd	토큰 × 가격 스냅샷. GLM-5.1: in $1.40/M · cached $0.26/M · out $4.40/M	score_results(cost)	↓
latency · turns	한 판 벽시계 시간 · 발화 횟수(루프 낭비 탐지)	runs.latency_ms	↓

③ 행동 (어떻게 일했나)

지표	정의 / 수식	출처(DB)	좋은 방향
tool_call / tool_error	도구 호출수·에러수. error_rate = 에러÷호출 (실패점 위치)	mv_tool_summary	error→0
loop_rate	max_messages에 걸린 run ÷ 전체 = "수렴 못 함 %"	mv_batch_summary	↓
agent_count · parallel_worker_count	참여 에이전트 수 · 병렬 워커 수(오케스트레이션 형태)	score_results(process)	—

④ 근거 (믿을 만한가)

지표	정의 / 수식	출처(DB)	좋은 방향
grounded% ⭐	run당 검색 성공(결과≥1)했나. 호출이 아니라 성공 기준	v_analysis_grounded	↑ (최신성 목표 시)
recency	리포트가 현재 시점을 언급한 텍스트 신호(0~1). 환각 가능 — grounded와 별개 축	파생 계산	↑ (단, grounded와 함께)
citation_count	claim↔source 쌍 개수. 모든 인용은 실제 source_artifact로 연결(dangling 0)	citations	적정(양 아닌 질)

2.2 6축 종합 점수 (eval_v2) — 한 줄로 합산하기

v2는 위 지표들을 6개 축으로 묶고 가중합해 100점 만점의 "system score"를 만든다(가중치는 용례별로 다름 — 아래는 고객지원 예시).

축	무엇을 보나	계산 요지	가중치
Task	정답성	exact/answer match	0.25
Coordination	역할 준수 + 정보 전달 충실	role_adherence×0.5 + info_fidelity×0.5	0.15
Tool	도구 선택·인자 정확도	0.6×선택정확 + 0.4×인자충실	0.15
Efficiency	토큰·턴·지연 예산 대비	min(1, 예산/실제)들의 평균	0.20
Safety	환각·PII	기본 0.95, 위반 시 0.3 + 거부권(veto): 총점 ≤ 39	0.15
Alignment	톤·형식 적절성	LLM-judge (현재 보류)	0.10

Safety의 거부권(veto)안전 위반(환각·PII)이 잡히면 다른 축이 아무리 높아도 총점이 39점으로 강제 제한된다. "위험한데 똑똑한" 시스템이 합격선을 넘지 못하게 하는 안전장치.

리서치 전용으로는 Anthropic 공개 방법론 루브릭 v1.2.0(6항목: factual_accuracy·citation_accuracy·completeness·source_quality·tool_efficiency·overall_pass)을 GLM-5.1이 채점한다. 항목별 임계 0.7, 근거 0개면 not_assessable.

2.3 측정의 함정 4가지 — 이걸 모르면 숫자에 속는다

호출 ≠ 성공. "검색을 호출했다"와 "검색이 결과를 줬다"는 다르다. grounded%를 성공 기준으로 재정의(migration 010, 6/15)하자, 검색이 차단됐던 팀의 grounded가 100%처럼 보이던 게 0%로 드러났다 → 백엔드를 firecrawl로 교체해 진짜 접지.
N=1 ≠ 진실. 단발의 극적인 예시는 오도한다. 같은 2-hop을 3회씩 재니 "hop2 60→90%"는 N=1 노이즈였고, 실제 pass@1은 93%/97%(+4pp)였다. N회·pass@k가 진실이며 하니스는 자기 과거 결론까지 교정한다.
양 ≠ 질. "출처를 전부 인용하라"고 강제하자 출처가 15.7개로 폭증하고 오히려 grounded가 67%로 불안정해졌다(EXP-67 기각). "핵심 5~8개"로 바꾸자 4.7개·100%로 회복(EXP-68).
정합성(invariant) 0/0. "완료 run인데 success 비어있음=0", "tool_call인데 짝(result)이 없음=0"이어야 모든 숫자를 믿을 수 있다. 이 불변식이 깨지면 지표 전체가 의심 대상.

3 지금 무슨 일이 일어나고 있나 — 상황

오른쪽 작업창에서 진행 중인 실제 상태(2026-06-13~16 스냅샷).

3.1 eval_ph1 — 1차 하니스 완성, 개선 실험 가동

마일스톤 M1~M6 완료(스키마·팀빌더·로더/채점·러너·CLI·베이스라인). AC1~AC9 전부 검증, AC9 팀해시 가드(프롬프트 1글자만 바뀌어도 새 team_id) 적용.
GAIA L1 비웹 베이스라인 pass@1 100%(15 mock task). 실 GAIA 수집은 HF 토큰 게이팅으로 일시 보류(setup_gaia.py 준비됨).
EXP-65→68 그라운딩 플라이휠(반도체 분석)이 한 주의 하이라이트 — 아래 3.2에서 한 바퀴 전체를 봅니다.
EXP-139(GAIA L2, 보류): 웹 도구를 더해도 pass@1 정체 → "웹은 필요하지만 충분치 않다, 병목은 다단계 추론".
스키마 진화: migration 000~011. 010(6/15) grounded를 "호출"→"성공" 기준으로 재정의, 011(6/15) 실패 분류(taxonomy) 골격(Tier2 보류).
firecrawl MCP 실검색 백엔드 배치(DDG 키리스 대체).

3.2 eval_v2 — 리서치-에이전트 평가 DB + GLM 보강

리서치 4팀(solo·pipeline·orchestrator·critic, 모두 GLM-5.1 via Z.AI)을 정규화 DB(22테이블·3뷰)에 기록.
비용 회계 완료: ok 30/30건에 estimated_cost 채움 — solo 평균 $0.035 vs anthropic-style $0.095(병렬성 2.7배 배수).
실패 진단: 74개 failure_events(system_design·inter_agent·verification·tool·safety·contamination·cost 분류). 인용 무결성: dangling 참조 0.
메트릭 갭 분석(research 36): 권장 ~70지표 중 8 완전커버 · 16 부분 · 5 누락(누락은 전부 고급 LLM-judge) → 구조적으로 ~75% 지원. 부분 지표용 신규 컬럼(query_text·answer_format_valid·citation excerpt/freshness·verifier 추적 등) 추가.
OpenAI Deep Research는 키 부재로 명시적 scope-out(실패행을 만들지 않고 러너가 종료).

3.3 플라이휠 한 바퀴 실전 — EXP-65→68 (stale → web → 최적화)

분석 도메인 "반도체 동향" 한 태스크에서 1변수씩 네 번 돌린 기록. "켜고(65) → 싸게(66) → 과욕(67 기각) → 질로 회복(68)".

버전	grounded%	토큰	지연(s)	출처수	판정
v2 stale (도구 0)	0%	29.4k	280	0	베이스라인
v3 grounded (검색 켬)	100%	97.1k	602	4.7	EXP-65 트레이드오프
v4 lite (과검색 제거)	100%	17.8k	209	2.3	EXP-66 dominant
v5 cited (전부 인용)	67%	28.6k	306	15.7	EXP-67 역행·기각
v6 dedup+cap (핵심 5~8)	100%	21.3k	177	4.7	EXP-68 회복

교훈: 검색을 켜는 건 GAIA형 트레이드오프(능력↑·비용↑)였지만, 과검색 제거(66)는 dominant였다. 인용은 양이 아니라 질 — "전부 인용"은 비용 역행·grounding 불안정을 부른다.

왜 좋아졌나 — 궤적으로 본 분기점 (리서치 decoy 함정)

v1 ❌ 비활성 함정 문서에 낚임

🔧 search(Vesta) ✅ Team Dunes 🔧 search(team) → decoy "disbanded" 🔧 search(mgr) → decoy "Nadia Bauer, retired advisor" → 오답

v2 ✅ status-aware 검색이 decoy 강등

🔧 search(Vesta) ✅ Team Dunes 🔧 search(Dunes mgr) ✅ person_03 "Lena Patel, Engineering Mgr, manages Team Dunes" → 정답

분기점: v1 검색은 비활성 함정을 상위 노출 → 추종. v2는 demote_inactive로 첫 결과가 활성 정답. (단, EXP-70 재측정 결과 이 v1 실패는 저확률 tail이었음 — pass@1 93% vs 97% → 함정 ②의 사례)

4 방향 — 어디로 가나

개선 루프를 굴리는 규율과, 그 위에서의 다음 목적지.

4.1 플라이휠의 규율 (이게 핵심 자산)

① 배치 실행 cli.py run --team T --batch B (runs/events 기록) ↓ ② 메트릭 관측 success · tokens · latency · grounded% · tool_error ↓ ③ 진단 "어느 스테이지에서 깨지나?" → 가설 1개 ↓ ④ 1변수 개입 새 team_id (프롬프트 1글자만 바뀌어도) ── AC9 가드 ↓ ⑤ 재실행 같은 task, temp=0, k회 반복 (노이즈 제거) ↓ ⑥ 델타 판정 회귀 0 + 목표지표↑ → promoted / 아니면 rejected → 원장 기록

규율 4가지 ① 1변수 개입(효과를 한 원인에 귀속) · ② temp=0(노이즈 제거) · ③ 회귀 가드(pass만 보지 않고 regressed 동시 확인) · ④ 원장 기록(모든 EXP를 promoted/rejected/inconclusive로 영구 보존).

4.2 다음 목적지

트랙	다음 단계
신뢰도	같은 10태스크를 k≥3 반복 실행 → pass@k·인용 분산·비용↔품질 상관 측정 (단발 결론 제거)
실데이터	실 GAIA L1/L2 + firecrawl 그라운딩 베이스라인 확보(HF 토큰 해소 후)
품질 채점	Tier2 LLM-judge 실패 분류(MAST: 형식·역량·의미불일치) + 루브릭 v1.2.0 인간 보정
확장	멀티모델·멀티검색공급자 비교, aggregate_cells 집계 materialize, 합성 FK 무결성 강제
운영	일일 백업(tar.zst 14일), 실패 1회 자동 재시도, PII 마스킹 저장(결정적 해시 재현)

하드가드 — 넓히되 깨지 않는다범위는 사용자 지시로 넓혔지만(분석 도메인·Grafana·개선실험 당김), Tier-3 금지선은 유지한다: LLM-judge 실패라벨·claim/evidence·verifier 혼동행렬은 스키마만 두고 미구현. 분석 채점기도 결정적(LLM-judge 아님)으로 유지.