에이전트 벤치마크의 '사용자'는 두 번째 모델이며, 성공적인 실행 중 24.4%가 사용자 자신의 스크립트를 위반했습니다

이러한 벤치마크 중 하나에는 대화 시작 시 "참고로 저는 John Smith입니다. 제 번호는 555-123-2002입니다."라고 말하는 사용자 프록시가 있습니다. 이 과제는 에이전트가 계정에 접근하기 전에 신원 확인 정보를 요청하는지 테스트하기 위해 존재했습니다. 그런데 이 프록시가 질문받지도 않았는데 첫 번째 턴에 자발적으로 그 정보를 제공했습니다.

에이전트는 만점 보상을 받았습니다. 하지만 과제가 측정하도록 설계된 것은 전혀 측정되지 않았습니다.

이 예시는 Ashish Jain과 Armaan Sandhu가 tau-bench 계열에 평가 레이어를 결합한 논문 UserProxyBench에 나와 있습니다. 저는 이 논문을 읽고 있는데, 코드 리뷰 평가에서 계속 마주치는 실패 모드를 지적하고 있기 때문입니다: 시뮬레이션된 참여자가 측정 도구의 일부가 되며, 거의 아무도 이를 점수화하지 않습니다.

설정

대화형 에이전트 벤치마크는 점점 더 두 번째 언어 모델을 사용자 자리에 배치하고 있습니다. 이 모델은 에이전트가 어떤 정보를 언제 받는지 제어합니다. 이것이 바로 다중 턴(multi-turn) 과제를 가능하게 하는 방식입니다. 같은 패턴이 학습 과정으로 새어나오고 있는데, 여기서 시뮬레이션된 사용자가 RL 루프 안에 앉아 각 롤아웃(rollout)에서 정책(policy)이 무엇을 보게 할지 결정합니다.

UserProxyBench는 그 사용자가 맡은 임무를 수행했는지 측정합니다. 이들은 이를 사용자 충실도 점수(User Fidelity Score)라고 부르는데, 프록시가 자체적인 사적 사용자 청사진(private user blueprint)에 있는 모든 적용 가능한 기준을 만족하는 에피소드의 비율입니다. 평가 기준(rubrics)은 Claude Opus 4.8에서 나오며, 과제당 4개에서 8개의 원자적 기준이 있고, 점수화가 시작되기 전에 다른 모델(GPT-5.6-Sol)에 의해 근거성(grounding)과 달성 가능성(achievability)을 검토받습니다. 총 네 가지 기업 도메인(통신, 항공, 소매, 은행)에 걸쳐 2,141개의 기준이 있습니다. 375개 과제입니다. 에이전트는 GPT-5.5로 고정되었고, 사용자 자리에서는 일곱 개의 다른 프록시가 순환하며 각 과제당 한 번의 롤아웃을 수행합니다.

기준들은 네 가지 계열(groundedness, premature disclosure, goal deviation, missed information)에 속합니다. 총 19개의 실패 모드가 있으며, 그중 18개가 실제로 이 세트 어딘가에서 발생합니다. 예외인 자기 모순(self-contradiction)은 기준이 없어 점수가 없습니다. 이는 분류 체계가 채워 넣기식(padded)이 아니라는 것을 의미하므로 주목할 만합니다.

수치 분석

사용자 프록시만 교체하고 에이전트는 고정한 채로 평균 과제 보상(mean task reward)은 15.2 포인트 변동합니다. 벤치마크가 점수를 매기지 않는 구성 요소 때문에 결과가 달라지는 경우입니다.

성공적인 에피소드 중 24.4%에서 사용자 명세 위반(user-specification violation)이 발견되었습니다. 통과한 실행의 거의 4분의 1에 달하는 경우에서 사용자가 스스로의 계약을 어겼습니다.

가장 지배적인 실패 유형은 성급한 정보 공개입니다. 모든 프록시는 동일한 명시적 지침을 받았습니다: '정보를 점진적으로 공개하십시오. 에이전트가 특정 정보를 요청하기 전까지 기다리십시오.' 하지만 그들은 그렇게 하지 않았습니다.

7개의 프록시에 걸친 평균 UFS(Mean UFS)는 .599에서 .864 사이입니다. Gemini-3.5-Flash가 .864로 가장 잘 작동했으며, GPT-5.4-mini는 .599로 최악이고 에이전트 보상에서도 (.644) 최악인데, 이 경우는 두 수치가 우연히 일치하는 경우입니다. Sonnet-4-6은 충실도(fidelity)에서 .778을 기록하고 보상에서는 .784를 기록하여, 어떤 열을 읽느냐에 따라 순위가 바뀝니다.

다른 두 가지 실패 사례는 첫 번째 사례만큼 구체적입니다. Gemma-26B의 미실행 액션 주장: '좋아요, 시도해 볼게요. 어디 보자... 지금 비행기 모드를 끕니다. 잠시만요... 네, 좀 기다렸어요.' 토글 호출은 전혀 일어나지 않았고 장치 상태는 여전히 비행기 모드였습니다. 그리고 조작된 장치 상태: 마지막 관련 도구 결과가 실패였음에도 불구하고 '오! 작동했어요! 작은 막대가 움직임을 마치고 전송되었다고 합니다!' 였습니다. 이 두 사례 모두 통과한 에피소드에서 발생했습니다.

보상이 포착하지 못하는 실패

이것이 평가(evals)를 실행할 때 중요한 부분입니다.

성공적인 에피소드를 분석했을 때, 정보를 과도하게 공개하는 프록시는 고정된 에이전트가 7개 전체에서 일관되게 도구 호출을 1.06번 적게 하고 질문을 0.26개 적게 하도록 만듭니다. 보상은 동일합니다. 작업량이 줄어든 것입니다. 사용자가 정보 수집의 절반을 대신 처리했기 때문에, 에이전트는 훨씬 쉬운 작업을 수행하면서도 똑같이 유능해 보입니다.

7개의 프록시가 완료한 374개 태스크 전반에 걸쳐 평균 에이전트 턴(agent turns)은 UFS와 r = .955의 상관관계를 보였습니다. 태스크 리워드(Task reward)는 r = .594로 상관합니다. 평가하는 상호작용이 설계한 상호작용인지 알고 싶다면, 피델리티 스코어(fidelity score)가 이를 추적하며 리워드는 대체로 그렇지 않습니다.

이는 제가 LLM 심사관(LLM judges)을 사용하면서 계속 겪는 문제와 같은 모양입니다. 채점하는 주체가 또 다른 모델인데 최종 점수만 보면, 상관관계 오류들이 깔끔해 보이는 숫자 안에 숨어 있습니다. 사용자 좌석(user seat)은 이런 일이 발생할 수 있는 또 다른 장소입니다. 저는 AI 코드 리뷰 벤치마크에서 오프라인 대 온라인 분할(offline vs online split)에 대해 글을 썼는데, 이것이 다른 방향에서 도달하는 동일한 주장입니다.

AI 코드 리뷰 평가에 대한 의미

제가 읽은 대부분의 코드 리뷰 벤치마크는 인간 주석 처리된 정답(ground truth)을 가진 실제 PR(Pull Request) 코퍼스(corpus)를 사용하기 때문에, '사용자'가 데이터셋이 되어 오작동할 수 없습니다. 이것은 정말 큰 장점이며, 제가 사람들에게 데모보다는 코퍼스로 돌아갈 것을 계속 주장하는 이유입니다.

상호작용 평가로 넘어가는 순간, 다시 시뮬레이터(simulator)를 구축하는 것입니다. 에이전트가 명확히 하는 질문을 하거나, 재실행을 요청하거나, 합성 PR 작성자(synthetic PR author)와 범위를 협상하는 모든 하네스(harness) 안에는 사용자 프록시가 존재합니다. 리뷰어 측면의 경우도 마찬가지입니다. 만약 리뷰어가 심어진 버그를 잡아내는지 테스트한다면, 그 질문에 응답하는 'PR 작성자'는 모델이며, 그 행동은 변수입니다.

만약 그렇게 점수를 매긴다면, 프록시(proxy)는 별도의 열이 필요합니다. 단순히 '에이전트가 문제를 해결했는지'가 아니라 '시뮬레이션된 대응자가 주어진 역할을 수행했는지'를 확인해야 합니다. 논문의 judge-free probe에서 제가 가장 먼저 참고할 세부 사항은 다음과 같습니다. 통신 분야에서는 658개의 모든 궤적(trajectories)을 골드 사용자 작성 행동과 비교하여 54개의 누락된 작성을 발견했습니다. 이 중 23개는 적용 가능한 모든 루브릭 기준을 통과했고, 20개는 직접적으로 관련된 하나의 기준을 통과했습니다. LLM으로 판단하는 루브릭은 기계적인 검사가 공짜로 잡아낸 것을 놓쳤습니다. 골드 행동이 존재하는 경우에는 결정론적(Deterministic) 검사를 하고, 그렇지 않은 경우에만 모델이 판단합니다.

페르소나 프롬프팅이 통제력을 보장하지는 않는다

여기에 함께 알아두면 좋을 발견 사항이 있습니다. Persona Following Is Not Selective Control이라는 논문은 8개의 블랙박스 LLM을 감사(audit)했으며, 페르소나 프롬프트의 한 속성을 변경하는 것만으로도 프롬프트에서 언급하지 않은 속성에 대한 답변이 바뀌는 것을 발견했습니다. 사용자를 더 위험 추구적이라고 묘사하면 그 사람의 색상 선택이 바뀝니다. 이들은 이를 특성 조건부 완성(trait-conditioned completion)이라고 부르는데, 모델은 페르소나를 그 사람에 대한 증거로 간주하고 추론된 프로필을 명시되지 않은 영역까지 확장합니다.

그다음 연구진은 비대상 속성을 중립으로 선언하는 것이 이를 해결하는지 테스트했습니다. 그렇지 않았습니다. 대상 속성은 모델이 선언된 상태를 올바르게 보고할 때조차 51%에서 81%의 항목에 걸쳐 여전히 새어 나왔습니다. 따라서 '우리는 시뮬레이터에게 상세한 페르소나를 프롬프팅했다'는 것이 그 페르소나가 유일하게 방향을 결정하는 요소라는 증거가 될 수 없습니다. 방향성 선언은 단순히 지침을 따름으로써 통과될 수 있으며, 이것이 바로 실패를 확인하기 위해 중립 상태(neutral state)가 필요한 정확한 이유입니다.

제가 상호작용 평가 보고서에서 원하고 싶은 것

에이전트뿐만 아니라 시뮬레이터 자체도 점수화하세요. 보상(reward) 옆에 충실도 수치(fidelity number)를 함께 게시해야 합니다.

• 골드 액션(gold actions)이 존재하는 경우 결정론적 프로브(deterministic probes)를 사용하고, 어떤 기준이 모델에 의해 판단되었는지 명시하세요.
• 프록시(proxy)의 이름과 버전을 명시하세요. 목록에 없는 구성 요소에서 나온 15.2점의 보상 변동은 아무도 재현할 수 없는 결과입니다.
• 측정 도구를 고정하세요. 제가 리뷰어 도구에서 모델 고정(model pinning)을 중요하게 생각하는 이유도 같습니다: 만약 도구 하단의 모델이 버전 업데이트 없이 변경될 수 있다면, 여러분의 전후 비교는 벤더의 배포 일정을 측정하고 있는 것입니다. 자체 호스팅 및 BYOK(Bring Your Own Key) 설정은 모델을 고정할 수 있게 해주어 리뷰어가 유일하게 변수로 작용합니다. CodeRabbit의 표준 플랜은 BYOK가 없는 고정된 벤더 모델을 번들로 제공하는 반면, Kodus는 모든 플랜에서 BYOK를 사용하며 토큰 추가 비용이 없어 모델 자체가 움직이는 목표물이 아닌 설정 파일의 한 줄에 존재합니다. 서로 다른 설계 선택은 서로 다른 재현성 이야기를 만듭니다.

비용 측면도 현실이며, 논문 역시 이를 숨기지 않습니다. 일곱 개의 프록시는 시뮬레이션당 사용자 측 비용이 0.0063에서 0.1841에 이르기까지 다양합니다. Qwen3.6-35B, Gemma-31B, 그리고 GPT-5.4-mini는 비용-UFS 평면(cost-UFS plane)에서 엄격하게 지배된다고 표시되었는데, 이는 더 저렴한 것이 충실도 면에서 더 높은 점수를 얻는다는 의미입니다. 따라서 '충실도 기준을 통과하는 가장 저렴한 프록시를 선택하라'는 슬로건이 아니라 적용할 수 있는 규칙입니다.

저자들이 자신들의 작업에 대해 제시한 주의사항

UFS는 LLM 기반으로 평가되며, Claude Opus 4.8은 루브릭을 작성하고 트랙젝토리(trajectories)를 채점합니다. 검증자(verifier)만이 다른 모델입니다. 그들은 토론에서 이를 언급하며 10개 과제와 50개 기준에 대한 단일 평가자 수동 감사(single-rater manual audit)를 지적했습니다. 과제당 한 번의 배포가 이루어집니다. 서비스 가격은 시간에 따라 달라집니다. 이것은 정직한 제한 사항 섹션이며, 제가 작성한 셀프 리뷰 맹점 게시물이 경고하는 정확한 설정입니다: 생성기(generator)와 채점기가 같은 모델인 것은 알려진 상관관계 위험이며, 평가자 없는 탐색(judge-free probe)에서 54개의 놓친 작성물(missed writes)을 발견했다는 점은 그 효과가 여기서도 살아있음을 시사합니다. 괜찮습니다. 이 논문의 요점은 측정 격차(measurement gap)에 있으며, 그 격차는 충실도 수치 자체에 두 번째 평가자가 필요한지 여부와 관계없이 실재합니다.

불편한 버전

UC Berkeley에서 공동 저술하고 COLM에서 발표된 또 다른 연구가 돌고 있는데, 이 연구는 AI 지원이 10분 동안 사람들의 어려운 문제 해결 지속성(persistence)을 측정 가능한 수준으로 감소시켰다는 것을 발견했습니다 https://vcresearch.berkeley.edu/news/using-ai-just-10-minutes-erodes-your-ability-persist-hard-things. 3개의 무작위 실험에 참여한 1,222명의 참가자가 대상이었습니다. 여기서의 틀은 '생산적인 고군분투(productive struggle)'가 제거되는 것입니다.

저는 이 글을 읽고 나서 1.06-fewer-tool-calls 결과를 읽었는데, 그들은 다른 규모에서 같은 이야기를 하는 것 같습니다. 어려운 부분을 외부화하는 것은 측정해야 할 것이 남아있지 않을 때까지는 잘 작동합니다. 벤치마크의 경우, 남은 것은 조용히 쉬워진 과제에 대한 합격 점수이며, 아무도 보상(reward) 열에서 그것을 알아차릴 수 없습니다.

이 모든 것이 대화형 평가(interactive evals)가 망가졌다는 것을 의미하지는 않습니다. 이는 사용자 좌석(user seat)이 하중을 지탱하는 부분이며, 대부분의 사람들이 수치를 발표하는 장치에서는 측정되지 않는다는 것을 의미합니다. 점수를 매기고, 이름을 붙이고, 고정하고, 충실도 수치를 보상 수치가 있는 곳에 배치해야 합니다. 왜냐하면 독자들이 그곳을 보고 있기 때문입니다.