에이전트 평가는 언제 끝나는가: 결과 확정성과 실행 간 분리
When Is an Agent Evaluation Over? Outcome Finality and Cross-Unit Separation
TL;DR Highlight
에이전트 평가에서 종료 시점 점수만 믿으면, 지연된 쓰기와 공유 상태로 결과가 뒤바뀐다
Who Should Read
에이전트 벤치마크나 자체 평가 파이프라인을 돌리며 점수가 흔들려 고민인 개발자
Core Mechanics
- 종료 시점이 곧 결과 확정은 아니다
- 평가는 에이전트가 멈추는 순간 상태를 채점하는 경우가 많다.
- 그 시점에도 도구 호출이 돌고 있을 수 있어서 채점 후 결과가 바뀔 수 있다.
- 확정성과 분리는 서로 별개 조건이다
- 결과 확정성(finality)은 이후 이벤트가 결과를 못 바꾸는 상태를 뜻한다.
- 실행 간 분리(separation)는 앞선 실행이 뒤 실행의 조건을 못 바꾸는 상태를 뜻한다.
- 하나만 충족하고 다른 하나는 깨져 있을 수 있다.
- 공유 상태면 앞 실행이 뒤 실행 점수를 바꾼다
- 지연된 쓰기가 다음 실행의 초기값을 덮어쓰면 별개 시행이라고 볼 수 없다.
- pass^k 같은 지표는 독립 시행을 전제하므로 해석이 깨진다.
- 증거가 없으면 확정 라벨을 붙이지 않는다
- 남은 효과가 라벨을 바꿀 수 있으면 성공/실패 대신 unresolved로 보고한다.
- 실행 간 연결이 남으면 연결을 모델링하거나 묶어서 한 단위로 센다.
- 공개 프로토콜 문서는 미완료 작업 설명이 부실하다
- 10개 프로토콜 중 리셋 또는 의도적 유지는 대부분 명시돼 있다.
Evidence
- 스냅샷 채점은 지연 쓰기를 놓쳤다
- 고정 트레이스 재생에서 지연이 0이 아닌 150건은 모두 종료 시점과 최종 라벨이 달랐다.
- 스냅샷 채점은 200건 중 성공 50건, 대기 후 채점(reconciliation)은 200건 중 200건이었다.
- 검증된 취소는 150건을 실패로 만들었다
- 대기 중이던 150건을 취소 확인 후 채점하니 모두 실패 라벨이 붙었다.
- 동기 쓰기 대조군은 세 채점 정책 600건에서 불일치가 0건이었다.
- 공유 상태에서 150/200쌍이 노출됐다
- 네임스페이스, 검증된 리셋, 쓰기 없는 대조군은 각각 200쌍 중 노출 0건이었다.
- B의 평균 점수는 네임스페이스 대비 공유 상태에서 0.75 낮았다.
- B를 A보다 먼저 실행하면 노출이 150/200에서 0/200으로 줄었다.
- 10개 공개 프로토콜 문서 검토 결과
- 리셋 또는 유지는 명시 8개, 부분 2개였다.
- 미완료·하위 작업은 명시 0개, 부분 2개, 미보고 6개, 해당없음 2개였다.
- 별개 채점의 근거는 명시 3개, 부분 7개였다.
How to Apply
- 평가 하네스에 종료 후 대기 점검 넣기
- 채점 직전에 남은 프로세스, 큐, 비동기 쓰기가 있는지 확인하고 끝날 때까지 기다리거나 취소 확인 후 채점하라.
- 확인이 안 되면 그 케이스는 성공/실패 대신 unresolved로 기록하라.
- 실행마다 상태를 네임스페이스로 격리하기
- 공유 DB, 서비스, 자격증명, 파일 경로에 실행 ID 접두사를 붙여라.
- 리셋을 쓴다면 초기값을 복원했는지 시작 전에 읽어서 검증하라.
- open-effects 기록 남기기
- 도구 래퍼에서 비동기 작업 시작 시 작업, 핸들, 종료 시점 상태, 다른 실행으로 번질 경로를 로그에 추가하라.
- 기록이 비어 있어도 효과가 없다는 증명은 아니므로 시스템 수준 점검을 병행하라.
- 연결된 실행은 한 단위로 집계하기
- 격리가 불가능하면 연결된 실행 쌍을 한 분석 단위로 묶어 불확실성을 계산하라.
- 이 경우 pass^k의 독립 시행 가정을 쓰지 마라.
Try It
# Claude나 ChatGPT에 붙여넣는 프롬프트 (논문 방법의 간이 버전: 평가 설계 점검)
나는 LLM 에이전트 평가 파이프라인을 운영한다. 아래 설명을 바탕으로 '결과 확정성'과 '실행 간 분리'를 각각 점검해줘.
[평가 설명]
{{평가 설정: 무엇을 성공으로 보는지, 언제 종료하는지, 어떤 도구와 서비스를 쓰는지, 실행 사이에 무엇을 리셋하는지}}
[요청]
1. 종료 후에도 남을 수 있는 작업(비동기 쓰기, 백그라운드 프로세스, 큐, 콜백)을 나열해줘.
2. 실행 간에 남을 수 있는 자원(자격증명, 파일, 공유 DB, 메모리, 외부 계정)을 나열해줘.
3. 각 항목마다 '작업 / 담당 시스템 / 핸들 / 종료 시점 상태 / 가능한 이후 상태 / 다른 실행으로 번지는 경로'를 표로 만들어줘.
4. 각 항목에 대해 라벨을 확정할 근거가 있는지, 없다면 기다리기, 취소 후 확인, unresolved 보고 중 무엇이 맞는지 알려줘.
5. 격리나 리셋이 실제로 작동했는지 검증하는 방법도 하나씩 제안해줘.
이어서 해 볼 것: 표에서 근거가 없는 항목 하나를 골라 실제 하네스에 점검 코드를 추가해봐.Terminology
관련 논문
The Judge Can Debias Itself: LLM-as-a-Judge가 스스로 편향을 고치게 하는 법
심사 프롬프트에 편향 경고를 넣거나 스스로 비판시켰더니 21개 중 20개 조합에서 정확도가 올랐다
미국 노동시간의 90%는 AI 벤치마크가 제대로 다루지 못하는 일이다
벤치마크 29개를 직업 과제에 매핑했더니 노동시간 90%가 커버 밖
Postgres 19, AI 코드 리뷰가 버그를 너무 많이 찾아 출시 연기
LLM 코드 리뷰가 버그를 쏟아내 Postgres 19가 11월로 밀리고 기능 8~10개가 빠졌다
StarSkirmish Bench v0.2: LLM이 1시간 만에 짜는 StarCraft 봇 대결
LLM에게 1시간 동안 StarCraft 봇을 짜게 했더니 GPT-6 Astra가 1위
그럴듯한 설명 하나면 멀티모달 LLM 심사위원도 속는다 (JUPE 벤치마크)
정답은 그대로 두고 설명만 붙였더니 MLLM 심사위원의 오답 거절률이 12.7~13.8%p 떨어졌다
신경망은 이미 깔끔하다: polysemanticity의 원인 재해석
뉴런을 직접 들여다봤더니 대부분 한 가지 역할이 있었다는 주장
Linus Torvalds의 첫 LLM 보조 패치 시리즈
Linus가 LLM으로 folio 조회 패치 10개를 만들어 read() 벤치가 10배 빨라졌다
Original Abstract (Expand)
Agent evaluations commonly score the state observed when a run stops and count the run as one trial. Interpreting that score as a final result from a separate trial requires outcome finality and cross-unit separation. Outcome finality requires that later events cannot change the claimed result, while cross-unit separation requires that earlier runs cannot change the relevant conditions of later ones. The endpoint establishes neither condition by itself, and the two can hold independently. Waiting for a delayed outcome may settle the label even though its state remains available to another run. Isolation may prevent carryover even though the scored outcome remains unresolved. We develop a completion argument that identifies the evidence needed for each decision. A final success or failure label is justified only when every relevant effect is resolved or bounded tightly enough to fix the outcome. Any remaining uncertainty must be reported. First, in a controlled replay with fixed agent actions, we find that endpoint and terminal labels differ for every nonzero-delay operation and that a delayed write changes the next run's score under shared state but has no such effect after namespacing or verified reset. Second, in a review of ten public protocols, we find that reset or deliberate retention is documented explicitly more often than unfinished operations or evidence for separate scoring. Finally, we propose an open-effects record for operations and resources that may remain relevant after the endpoint, their status, and their possible effects on the scored outcome or another run.