자신감 넘치는 거짓말쟁이 LLM 판사와 더 나은 검증기 만들기

URL: https://www.youtube.com/watch?v=xLxhT2ZI7UM
원문 제목: Your LLM Judge Is a Confident Liar: Building Better Verifiers — Browserbase
발행일: 2026-10-05
처리일: 2026-10-06
채널: latentspacepod (YouTube 표시 채널: AI Engineer)
길이: 21분 13초
행사: AI Engineer World's Fair 2026, San Francisco
협업 주체: Miguel González Fernández (Browserbase 에이전트 플랫폼 Tech Lead), Corby Rosset (Microsoft Research 연구자)

---

📌 핵심 질문 / LLM 판사의 판정을 어떻게 믿을 수 있는가

==웹 에이전트의 성공 여부를 판정하는 검증기(Verifier)가 틀리면 평가 점수뿐 아니라 강화학습 보상과 학습 데이터까지 오염되므로, 에이전트의 실제 행동·스크린샷·환경 제약을 분리해서 읽는 Universal Verifier가 필요하다.==

• 결정론적(Deterministic) 웹 평가 환경은 에이전트 능력이 향상될수록 유지 비용이 폭증하고 실제 웹의 개방성을 담지 못한다.
• 기존 LLM-as-a-judge는 에이전트의 유창한 주장과 실제 화면 상태를 혼동해 성공률을 부풀린다.
• 작업별 루브릭(Rubric), 기준별 관련 스크린샷 Top-K 증거, 비연쇄 오류 채점, 과정(Process)과 결과(Outcome)의 분리를 함께 적용해야 신뢰할 수 있는 신호가 나온다.

웹 에이전트 평가는 “무엇을 했는가”와 “사용자가 원하는 결과를 얻었는가”를 동시에 물어야 한다. Universal Verifier는 세부 기준별 과정 점수와 합리적 사용자가 보기에 작업이 끝났는지를 나타내는 결과 불리언(Boolean)을 별도로 계산하고, 사람 라벨과의 일치도로 설계를 검증한다. 잘못된 판사는 더 나은 에이전트를 훈련시키지 못하고 더 능숙하게 거짓말하는 에이전트를 만든다.

1. 문제의 출발점과 연구 배경

1.1. Browserbase와 Microsoft Research의 협업

1. Browserbase의 역할

   1. 웹 에이전트 배포 인프라: Browserbase는 웹에서 작동하는 에이전트를 배포하기 위한 인프라 회사다.
   2. 클라우드 브라우저와 런타임: 쉽게 접근할 수 있는 일부 웹만 다루는 것이 아니라 클라우드 브라우저와 에이전트형 웹 자동화에 필요한 런타임을 관리해 전체 웹을 에이전트에게 개방한다.
   3. 대규모 자동화의 관찰 지점: 브라우저 세션과 런타임을 직접 관리하므로 에이전트의 행동 궤적(Trajectory), 화면 상태, 실행 결과를 평가할 수 있다.

2. 발표자와 협업 목적

   1. Miguel González Fernández: Browserbase 에이전트 플랫폼의 Tech Lead로서 Stagehand 오픈소스 프레임워크의 변화와 모델 능력이 계속 향상되는지 확인할 평가(Eval)를 구축해 왔다.
   2. Corby Rosset: Microsoft Research 연구자로서 Browserbase와 협력해 신뢰할 수 있는 검증기를 만드는 연구를 수행했다.
   3. 연구 범위: 약 한 달 전에 공개한 연구는 평가(Evals), 강화학습 환경(RL Environments), LLM 판사(LLM Judge)를 검증기로 사용하는 방법을 제시한다.

1.2. 초기 평가와 결정론적 환경

1. 결정론적 평가의 출발

   1. 제한된 모델 능력: 초기에 모델 능력이 어느 정도 제한돼 있었기 때문에 많은 결정론적 환경을 설계할 수 있었다.
   2. 목표: 프레임워크에 도입한 변경과 에이전트 하니스(Agent Harness)의 개선이 모델 능력을 실제로 끌어올리는지 평가 점수의 상승(Hill Climbing)으로 확인했다.
   3. 검증 방식: 정해진 화면·정해진 경로·정해진 체크포인트를 통과했는지 확인하면 성공 여부를 자동 판정할 수 있었다.

2. 능력 향상에 따른 확장 실패

   1. 정적 사이트 패치: 모델 능력이 좋아지자 평가를 결정론적으로 유지하기 위해 정적 사이트를 계속 패치하거나 새로 생성해야 했다.
   2. 긴 궤적과 체크포인트: 더 긴 행동 궤적을 만들고 수많은 중간 체크포인트를 배치해야 실제 성공을 확인할 수 있었다.
   3. 운영 부담: 에이전트 하니스와 모델이 좋아질수록 평가 환경을 유지하는 작업이 실제 모델 개선보다 앞서는 문제가 생겼다.

2. 웹 환경과 LLM 판사의 신뢰성 문제

2.1. 열린 웹은 하나의 정답 경로를 갖지 않는다

1. 웹 자동화가 결정론적으로 닫히지 않는 이유

   1. 여러 정답 경로: 같은 목표를 달성하는 방법이 하나가 아니므로 특정 클릭 순서만 정답으로 고정할 수 없다.
   2. 고정된 Ground Truth의 부재: 웹의 상태와 콘텐츠가 항상 같은 상태로 유지되지 않는다.
   3. 변경되는 제품과 페이지: 어제 확인하던 제품이나 서비스가 오늘 사라지거나 위치를 바꿀 수 있다.
   4. 환경 차단: CAPTCHA, 로그인 벽, 품절, 검색 결과 부재 같은 환경 오류는 에이전트가 성공을 증명할 결정론적 신호 자체를 얻지 못하게 한다.

2. LLM 판사로의 전환

   1. 확장 가능한 대안: 결정론적 평가가 막히자 많은 팀이 LLM 판사에게 에이전트 궤적을 보고 성공 여부를 판단하게 했다.
   2. 대표 벤치마크: 컴퓨터 사용에는 OSWorld가 있고, 웹 사용에는 Online-Mind2Web(OM2W)과 WebVoyager 같은 유사 벤치마크가 있다.
   3. 기존 검증기: 이들 벤치마크에는 LLM-as-a-judge 방식의 성공 판정기가 함께 제공된다.

2.2. 자신감 있는 오판과 “더 능숙한 거짓말쟁이”

1. 사람 검증자가 발견한 문제

   1. 높은 확신의 오답: 인간 전문가가 기존 판사의 판정을 다시 확인하자 여러 사례에서 판사가 매우 자신 있게 틀리고 있었다.
   2. 신뢰할 수 없는 결과: 판정이 틀리면 벤치마크 성공률과 모델 비교 결과를 믿을 수 없게 된다.
   3. 학습 신호의 오염: 판정 결과를 RL 보상, 하니스 개선 신호, 자동 연구(Auto-Research)에 사용하면 잘못된 행동이 보상된다.

2. 거짓말쟁이의 강화

   1. 훈련의 역효과: 틀린 판사에 맞춰 에이전트를 최적화하면 실제로 더 나은 에이전트가 아니라 더 그럴듯하게 성공을 주장하는 에이전트가 된다.
   2. 핵심 비유: “더 나은 에이전트를 훈련하는 것이 아니라 더 능숙한 거짓말쟁이를 훈련하는 셈”이라는 문제가 발생한다.

2.3. Fara 7B에서 드러난 검증기 격차

1. 동일 모델·동일 벤치마크 비교

   1. 에이전트: Microsoft의 웹 브라우저 에이전트 Fara 7B를 학습했다.
   2. 공식 판정: 같은 모델을 같은 WebVoyager 벤치마크에서 공식 WebVoyager 판정기(GPT-4o)로 평가하자 성공률이 74%로 나왔다.
   3. Universal Verifier 판정: 사람 라벨과 높은 일치도를 가진 새 검증기로 같은 궤적을 다시 보자 성공률은 38%가 됐다.

2. 74%와 38%의 의미

   1. 거대한 간극: 기존 검증기가 보고한 74%와 실제에 가까운 38% 사이에는 36%p의 차이가 있다.
   2. 문제의 본질: 에이전트 능력의 차이가 아니라 무엇을 성공으로 세는지에 대한 검증기 품질의 차이가 결과를 바꾼다.
   3. 연구 목표: 기존 판정과 실제 Ground Truth 사이의 간극을 줄이는 방법을 찾는 것이 Universal Verifier 연구의 출발점이다.

2.4. 기존 검증기의 구조적 약점

1. 모델과 입력의 한계

   1. 상대적으로 약한 판사: 기존 시스템은 o4-mini나 GPT-4o 같은 모델을 판사로 사용하지만, 모델 자체가 충분히 강하다는 사실만으로 신뢰성이 보장되지는 않는다.
   2. 루브릭 부재: 무엇을 어떻게 평가할지 명시하는 루브릭이 없으면 기준마다 정당한 점수를 배분하기 어렵다.
   3. 스크린샷 처리 실패: 모든 스크린샷을 한꺼번에 넣으면 컨텍스트 윈도우가 넘치고 판사가 길을 잃는다. 반대로 중요한 스크린샷을 고르지 않으면 결정적 증거를 놓친다.
   4. 행동 기록 누락: 일부 판정기는 에이전트의 최종 답변이나 전체 행동 이력을 충분히 보지 않는다.

2. Universal Verifier의 보완

   1. 기준 명시: 작업에 맞는 루브릭을 먼저 만든다.
   2. 기준별 증거 선택: 모든 화면을 무작정 읽는 대신 각 기준에 가장 관련성 높은 Top-K 스크린샷을 찾는다.
   3. 상태와 주장 대조: 에이전트가 했다고 주장한 일과 실제 환경 상태가 일치하는지 확인한다.
   4. 과정·결과 동시 출력: 부분 점수를 줄 수 있는 과정 점수와 최종 성공 여부를 나타내는 결과 불리언을 별도로 낸다.

3. Universal Verifier의 평가 파이프라인

3.1. 작업별 루브릭 생성

1. 예시 작업

   1. 목표: Seattle에서 Boston으로 가는 가장 저렴한 항공편을 예약한다.
   2. 기준 분해: 성공에 필요한 내용을 약 10개의 세부 기준으로 나눠 “성공이란 무엇인가”를 명시한다.
   3. 기준의 독립성: 각 기준은 서로 겹치지 않아야 하며, 한 기준의 실패가 다른 기준의 점수를 자동으로 훼손하지 않아야 한다.

2. 루브릭에서 점수까지

   1. 궤적 입력: 에이전트가 남긴 화면 캡처와 행동 기록을 루브릭에 따라 읽는다.
   2. 증거 랭킹: 각 기준을 판정하는 데 가장 관련 있는 스크린샷을 순위화하고 Top-K 증거 묶음을 만든다.
   3. 주장과 상태의 대조: 에이전트가 “예약했다”고 말했더라도 실제 화면에 예약 완료 상태가 있는지, 둘 사이에 모순이 있는지 확인한다.

3.2. 과정 점수와 결과 점수의 분리

1. Process Score

   1. 부분 성공 표현: 세부 기준별로 점수를 부여해 에이전트가 목표를 향해 얼마나 잘 실행했는지 표현한다.
   2. 환경과 독립된 실행 평가: 최종 결과가 막혔더라도 에이전트가 통제할 수 있는 단계에서 최선을 다했는지 확인한다.
   3. 설명 가능한 출력: 기준 목록과 각 기준의 충족 여부·근거를 함께 출력한다.

2. Outcome Boolean

   1. 최종 질문: 합리적인 사용자가 결과 화면을 보고 “내가 요청한 일이 끝났다”고 판단할지를 True/False로 답한다.
   2. 과정 점수와 다른 결론: 에이전트가 올바른 과정을 밟았어도 환경이 막아 사용자의 목표가 끝나지 않았다면 과정 점수는 높고 결과는 False일 수 있다.
   3. 예상 사용자 관점: 세부 기준의 점수와 실제 사용자가 얻은 결과를 섞지 않아 보상 신호의 의미를 보존한다.

3.3. 네 가지 설계 원칙

1. 요청한 것만 채점한다

   1. 작업에 없는 조건을 루브릭에 추가하지 않는다.
   2. 불필요한 기준은 실제로는 성공한 에이전트의 점수를 인위적으로 낮춘다.

2. 오류를 기준 사이에서 연쇄시키지 않는다

   1. 다단계 작업의 앞 단계 오류가 뒤 단계의 정답까지 자동으로 감점하지 않도록 기준을 독립시킨다.
   2. 잘못된 인물을 골랐더라도 그 인물의 순자산을 정확히 보고했다면, 인물 선택 기준만 감점하고 순자산 보고 기준은 별도로 평가한다.

3. Ground Truth 스크린샷을 반드시 본다

   1. 에이전트의 최종 설명은 환각일 수 있으므로 자기 보고를 실제 화면의 증거보다 우선하지 않는다.
   2. 중요한 상태 변화가 궤적 중간에 잠깐 나타났다가 사라질 수 있으므로 관련 화면을 기준별로 찾아본다.

4. 통제 가능·불가능한 실패를 분리한다

   1. 브라우저는 에이전트가 완전히 통제할 수 없는 환경이므로 환경의 차단과 에이전트의 실수를 같은 방식으로 벌하지 않는다.
   2. 과정 점수와 결과 점수를 분리해 최선의 실행과 목표 달성 여부를 동시에 보존한다.

4. 루브릭·오류·환각을 다루는 구체적 사례

4.1. 좋은 루브릭과 나쁜 루브릭

1. Jakarta 호텔·커피숍 작업

   1. 요청: 특정 날짜에 Jakarta의 저렴한 호텔을 찾고, 호텔 주소로 가장 가까운 커피숍을 검색한 뒤 커피숍의 이름과 주소를 출력한다.
   2. 필수 기준: 저렴한 호텔 탐색, 호텔 주소 확인, 가장 가까운 커피숍 탐색, 커피숍 이름과 주소 출력이 요청에 직접 대응한다.

2. 유령 기준(Phantom Criterion)의 문제

   1. 나쁜 기준: 호텔 숙박의 총 가격을 보고하라는 항목을 추가한다.
   2. 요청과 무관: 총 가격은 원래 작업에서 요구되지 않았는데도 순진하게 생성된 루브릭에 들어갈 수 있다.
   3. 인위적 감점: 에이전트가 요청받지 않은 총 가격을 계산하지 않았다는 이유로 실제 수행 점수가 낮아진다.
   4. 원칙: “채점하기 쉬운 것”이나 “그럴듯한 부가 정보”가 아니라 사용자가 실제로 요청한 조건만 기준으로 만든다.

4.2. 연쇄 오류를 끊는 NSYNC·Backstreet Boys 사례

1. 다단계 질문

   1. 첫 기준: NSYNC와 Backstreet Boys 멤버 중 성(last name)이 가장 긴 사람을 찾는다.
   2. 둘째 기준: 선택한 사람의 순자산(net worth)을 보고한다.

2. 잘못된 선택과 독립 채점

   1. 에이전트의 실수: Timberlake의 성이 가장 길다고 판단했다.
   2. 실제 비교: Timberlake는 10글자이고 Kirkpatrick의 성이 더 길다.
   3. 연쇄 감점 금지: 사람을 잘못 선택한 첫 기준은 감점해야 하지만, 선택한 Timberlake의 순자산을 정확히 보고했다면 둘째 기준까지 감점하면 안 된다.
   4. 보상 신호의 정밀도: 오류가 발생한 지점을 정확히 고립해야 어느 능력을 개선해야 하는지 알 수 있다.

4.3. 6.2%와 2.8%를 가르는 미세한 환각

1. 이미지 캡셔닝 모델 사례

   1. 작업: 이미지 캡셔닝 모델에 관한 정보를 찾는다.
   2. 에이전트 주장: 모델의 CIDEr 점수가 6.2% 향상됐다고 보고했다.
   3. 실제 근거: 원 논문의 초록(Abstract)은 향상 폭이 2.8%라고 적고 있었다.

2. 환각 검출의 필요성

   1. 미세한 숫자 오류: 6.2%와 2.8%의 차이는 답변 전체를 읽을 때 쉽게 지나칠 수 있다.
   2. 사람의 놓침: 사람도 원 논문과 에이전트 답변을 세밀하게 대조하지 않으면 잡기 어렵다.
   3. 스크린샷·문서 대조: Universal Verifier는 에이전트가 무엇을 말했다는 사실보다 실제 증거가 무엇을 보여주는지 우선해 환각을 감점한다.

4.4. 통제 불가능한 품절과 통제 가능한 실수

1. Amazon 봉제 인형(plushy toy) 사례

   1. 에이전트 행동: Amazon에서 원하는 봉제 인형을 정확히 검색했다.
   2. 환경의 차단: 상품이 품절이라 다음 단계로 진행할 수 없었다.
   3. 과정 판정: 에이전트가 목표 달성을 위해 할 수 있는 일을 다 했다면 Process Score는 만점을 받을 수 있다.
   4. 결과 판정: 실제 구매가 이뤄지지 않았으므로 Outcome은 실패다.

2. 대안과 실패 원인 분류

   1. 대체 상품: 다른 경로로 비슷한 봉제 인형을 찾아 요청의 목적을 충족했다면 과정과 결과 모두 성공으로 볼 수 있다.
   2. 통제 가능 실수: 쓸 수 있는 필터를 사용하지 않거나 필요한 단계를 건너뛰거나 한 번 실패하고 바로 포기했다면 감점한다.
   3. 환각: 구매하지 못했는데 구매했다고 주장하면 통제 가능한 환각으로 감점한다.
   4. 실패 스키마: 가능한 실패 모드와 각 상황의 크레딧 배분을 미리 열거해 같은 유형을 일관되게 판정한다.

5. 사람 라벨로 검증기를 검증하기

5.1. Ground Labels 수집 플랫폼

1. 실험 설계

   1. 목표: Universal Verifier의 정확도가 실제로 상승했는지 확인하려고 인간 전문가 실험을 설계했다.
   2. 플랫폼 구축: 에이전트 행동의 전체 증거 궤적과 결과를 사람에게 보여주고 사람이 판단할 수 있는 데이터 수집 플랫폼을 만들었다.
   3. 공개 데이터: 사람이 만든 Ground Label을 CUAVerifierBench로 공개해 다른 연구자가 학습과 검증에 사용할 수 있게 했다.

2. 사람과 검증기의 비교 절차

   1. 1단계: 인간 검증자에게 에이전트의 전체 증거 궤적과 모든 행동의 결과를 보여준다.
   2. 2단계: 인간이 증거를 보고 성공 여부를 판정한다.
   3. 3단계: 같은 인간에게 Universal Verifier의 판정도 보여주고 자신의 판단과 동의하는지 또는 동의하지 않는지 답하게 한다.
   4. 4단계: 사람 라벨과의 일치도를 이용해 프롬프트·코드·루브릭을 개선한다.

5.2. 오탐 감소와 Cohen's Kappa

1. False Positive 억제

   1. 기존 상태: 기존 판정기의 False Positive가 거의 절반에 이르는 사례가 있었다.
   2. 개선 결과: Universal Verifier는 False Positive를 거의 0에 가깝게 낮췄다.
   3. 논문 보강 수치: 연구 논문은 WebVoyager 기준 False Positive가 45% 이상, WebJudge가 22% 이상이었고, 설계 원칙을 결합한 검증기가 이를 1~8% 수준으로 낮췄다고 보고한다.

2. 사람과 사람의 일치도에 맞춘 검증기

   1. 측정 지표: Cohen's Kappa(κ)는 두 판정 집합이 우연한 일치를 넘어 얼마나 동의하는지 측정한다.
   2. 비교: 작업마다 두 명의 인간 주석자가 서로 얼마나 동의하는지와 Universal Verifier가 인간 라벨과 얼마나 동의하는지를 비교했다.
   3. 결과: Universal Verifier의 κ는 0.58이었고, 사람과 사람 사이의 일치도와 비슷한 수준이었다.
   4. 의미: 인간 한 명을 절대적 정답으로 가정하기보다 사람끼리 합의할 수 있는 수준을 목표로 삼아 검증기의 품질을 현실적으로 측정했다.

3. 사람의 누락을 되짚은 검증기

   1. 역전된 역할: 어느 시점부터 Universal Verifier가 인간 주석자가 놓친 내용을 찾아 인간을 교정하기 시작했다.
   2. 중요한 조건: 사람 라벨에 무조건 맞추는 것이 아니라 화면 증거·루브릭·오류 구조를 통해 사람의 오판도 드러낼 수 있어야 한다.

5.3. 더 좋은 검증기가 더 좋은 학습 데이터를 만든다

1. 고정된 데이터 규모 실험

   1. 비교 조건: 학습 궤적의 개수를 고정하고 검증기만 바꿨다.
   2. 규모: 3,000개 또는 9,000개의 training trajectory를 준비했다.
   3. 필터링: Universal Verifier의 Process Score를 기준으로 성공적인 궤적만 골라 SFT 데이터로 사용했다.

2. 모델 품질의 차이

   1. 3,000개 비교: Universal Verifier로 필터링한 3,000개 궤적으로 학습한 모델이 낮은 품질의 baseline verifier로 고른 데이터보다 훨씬 높은 품질을 보였다.
   2. 큰 규모에서도 유지: 9,000개로 규모를 키워도 같은 경향이 유지됐다.
   3. 연결 고리: 검증기 품질 향상 → 고품질 데이터 선별 → SFT 모델 품질 향상이라는 연쇄가 성립했다.
   4. 생산 환경의 증거: 인간과의 일치도만이 아니라 실제 모델 학습 결과에서도 Universal Verifier가 신뢰할 수 있는지 확인했다.

6. Auto-Research가 검증기를 만들 수 있는가

6.1. 3주간의 인간 설계와 비교 실험

1. 인간 연구 루프

   1. 기간: Miguel과 Corby는 약 3주 동안 Universal Verifier를 만들었다.
   2. 작업: 프롬프트를 조정하고 코드를 작성하며 사람 라벨과 일치하는지를 확인했다.
   3. 실험 수: 약 30개의 실험을 반복해 검증기의 품질을 올렸다. 연구 논문에는 전문가 설계 과정이 32회 실험으로 정리돼 있다.
   4. 평가축: 그래프의 Y축은 개별 검증기와 인간 라벨의 일치도를 나타내는 Cohen's Kappa였다.

2. Auto-Research 비교군

   1. 청색 선: Miguel과 Corby가 만드는 Universal Verifier의 성능이다.
   2. 적색·녹색 선: 인간이 작성한 코드와 프롬프트를 제거한 뒤 Auto-Research 루프가 처음부터 검증기를 만들도록 한 조건과, 인간의 발견을 일부 주입한 조건이다.
   3. 핵심 질문: 인간의 직관과 구조적 설계를 모두 제거해도 AI가 같은 품질·충실도의 검증기를 재현할 수 있는지 확인했다.

6.2. 하루 만에 도달한 70%와 남은 인간의 역할

1. 속도와 품질

   1. 속도: 인간 팀이 약 3주 걸린 작업을 Auto-Research는 약 하루 만에 수행했다.
   2. 실험량: 하루 동안 인간 팀과 같은 수의 실험을 실행했다.
   3. 품질: 인간 검증기가 얻은 사람과의 일치도 중 약 70% 수준에 도달했다.
   4. 한계: 인간 설계 검증기와의 품질 격차가 남아 모든 설계 전략을 스스로 발견하지는 못했다.

2. 가장 강한 조합

   1. 인간 개입의 필요: Auto-Research는 실험과 지표 최적화를 빠르게 하지만, 핵심 구조를 바꾸는 설계 직관에는 여전히 인간의 개입이 필요하다.
   2. 사전 지식 주입: 인간이 3주 동안 발견한 원칙을 녹색 조건에 미리 주자 Auto-Research 검증기는 이전에 도달하지 못했던 더 높은 비율의 일치도를 기록했다.
   3. 모델 조건: 당시 결과는 Opus 4.6으로 얻었고 Fable에서는 아직 시험하지 않았다.
   4. 연구 논문의 해석: Auto-Research 에이전트는 전문가 품질의 약 70%를 약 5%의 시간에 얻었지만, 인간의 핵심 전략 발견과 자동화된 미세 조정은 서로 보완적이다.

6.3. 모델보다 검증기도 중요하다

1. 핵심 교훈
   1. 검증기의 독립적 가치: Auto-Research는 모델뿐 아니라 검증기 자체도 만들 수 있다.
   2. 평가의 우선순위: 좋은 모델을 만드는 일만큼 좋은 검증기를 만드는 일이 중요하다.
   3. 실전 조합: 인간의 문제 구조화·설계 직관과 자동 연구의 대량 실험·미세 조정을 결합하는 방식이 가장 강력한 레시피다.

7. 공개 코드와 새로운 벤치마크

7.1. 공개된 연구 자산

1. 논문과 코드

   1. 논문: The Art of Building Verifiers for Computer Use Agents라는 제목의 연구를 arXiv 프리프린트로 공개했다.
   2. Microsoft 저장소: microsoft/fara 저장소에 CUAVerifierBench의 Golden Label과 실험 실행 코드가 있다.
   3. 관련 도구: Browserbase의 Stagehand와 연구 결과를 함께 확인할 수 있다.

2. 재현 가능한 검증

   1. 표준 데이터: 사람 라벨이 공개돼 새로운 검증기를 같은 기준으로 평가할 수 있다.
   2. 실험 루프: 후보 루브릭·프롬프트·코드의 변화가 인간과의 일치도를 높이는지 즉시 확인할 수 있다.

7.2. 포화된 평가를 넘어서는 CUAVerifierBench

1. 기존 벤치마크의 포화

   1. 지원 업무: 연구팀은 여러 랩이 모델 개선을 위해 정량 신호를 얻도록 돕고 있다.
   2. 훈련 분포와의 중첩: 오픈소스 벤치마크의 테스트 데이터가 이미 학습 데이터 분포에 들어간 듯한 상황이 생겼다.
   3. 신호 약화: 모델이 실제로 강해졌는지, 단지 테스트를 본 것인지 구분하기 어려워졌다.

2. 새 벤치마크의 역할

   1. 더 큰 성공 격차: 새 벤치마크는 완전한 성공까지 가장 큰 간극을 보여준다.
   2. 일상적 진단 도구: 모델 능력이 어디까지 강하고 무엇이 부족한지 매일 확인하는 기준으로 사용한다.
   3. 개선 방향: 단순 순위보다 어떤 실패가 남았는지 확인하고 그 간극을 줄이는 데 정량 신호를 사용한다.

8. Q&A: 브라우저를 넘어 데스크톱으로

8.1. Enterprise Desktop Task로의 확장

1. 질문

   1. Universal Verifier를 웹 작업 외의 다른 종류의 작업에도 사용했는지 질문이 나왔다.
   2. 노트북에서 실행하는 데스크톱 작업과 엔터프라이즈 업무 흐름에도 같은 원칙을 적용할 수 있는지가 핵심이었다.

2. Microsoft의 다음 단계

   1. 데스크톱 검증기: Microsoft는 현재 데스크톱 작업용 버전을 만들고 있다.
   2. 새 벤치마크: 웹 데이터뿐 아니라 엔터프라이즈 스타일 데스크톱 데이터로 구성된 새 벤치마크 공개를 준비한다.
   3. 추가 증거: 데스크톱에는 브라우저 화면 외에도 터미널, 텔레메트리(Telemetry), 로그가 있으므로 검증기가 더 많은 정보를 읽는다.
   4. 동일한 핵심: 작업별 루브릭, 증거 중심 판정, 과정·결과 분리라는 핵심은 유지하면서 관찰 가능한 증거의 종류를 확장한다.

9. Q&A: 인간 라벨 과적합을 피하는 방법

9.1. 홀드아웃 라벨 설계

1. 과적합 우려

   1. 질문: 검증기를 인간 라벨에 반복적으로 맞추면 그 라벨 세트에만 과적합하는 문제가 생기지 않는지 질문이 나왔다.
   2. 핵심 원칙: 검증기를 만든 데이터와 최종 성능을 보고할 데이터를 분리해야 한다.

2. 150개 궤적 분할

   1. 전체 규모: 150개의 trajectory를 두 세트로 나눴다.
   2. 개발 세트 50개: 약 50개는 Miguel이 직접 라벨링했고 30회 실험의 Hill Climbing에 사용했다.
   3. 홀드아웃 100개: 나머지 100개는 인간 주석자가 돈을 받고 라벨링했으며, 각 trajectory에 두 명의 주석자가 겹치도록 2x overlap을 적용했다.
   4. 최종 보고: 검증기 구축이 끝난 뒤 두 명의 인간이 각각 홀드아웃 trajectory를 라벨링했고 그 결과를 CUAVerifierBench로 공개했다.

3. 과적합에 대한 결론

   1. 2/3 이상 미사용: 전체 라벨의 최소 3분의 2를 검증기 반복 개선에 사용하지 않고 보류했다.
   2. 최종 수치의 독립성: 홀드아웃 라벨에는 구축 중 반복적으로 맞추지 않았으므로 보고된 사람 일치도가 개발 세트 암기 결과일 가능성이 낮다.
   3. Gold Standard: 가장 엄격한 기준은 인간을 고용하고 검증 작업을 직접 훈련한 뒤, 시스템의 판단이 인간의 판단과 일치하는지 확인하는 것이다.

9.2. 마무리

1. 남은 과제

   1. 벤치마크 확장: 더 많은 작업·환경·데스크톱 시나리오를 함께 만들 연구자와 사용자를 요청했다.
   2. 검증기의 지속 개선: 새로운 환경이 추가될 때도 과정과 결과, 통제 가능성과 통제 불가능성을 분리해야 한다.

2. 폐회

   1. 행사 마무리: 남은 Expo를 즐기기를 바라며 참석자에게 감사 인사를 전했다.
   2. 핵심 잔상: 모델의 성능을 높이는 일과 그 성능을 제대로 측정하는 검증기를 만드는 일은 분리할 수 없다.

주요 발언 모음

“The web is very open-ended. There’s not just one path to correctness.”
“웹은 매우 개방적이며, 정답으로 가는 경로가 하나만 있는 것이 아니다.”

“You’re not really training a better agent. You’re just training a more competent liar.”
“더 나은 에이전트를 훈련하는 것이 아니라 더 능숙한 거짓말쟁이를 훈련하는 셈이다.”

“You have to look at the ground truth state.”
“Ground Truth 상태를 반드시 봐야 한다.”

“The official judge said the agent succeeded 74% of the time. A better verifier said 38%.”
“공식 판사는 에이전트가 74% 성공했다고 했지만, 더 나은 검증기는 38%라고 했다.”

“Building verifiers is as important as building the models themselves.”
“검증기를 만드는 일은 모델 자체를 만드는 일만큼 중요하다.”

핵심 데이터 & 수치

• 영상 길이: 21분 13초다.
• Fara 7B 검증 격차: WebVoyager 공식 GPT-4o 판정은 74%, Universal Verifier 판정은 38%로 36%p 차이다.
• 기준 분해 예시: Seattle–Boston 최저가 항공편 작업은 약 10개 기준의 루브릭으로 분해한다.
• 환각 숫자: 이미지 캡셔닝 모델의 실제 CIDEr 향상은 2.8%인데 에이전트는 6.2%라고 주장했다.
• 오탐 개선: 기존 False Positive가 거의 절반에 이르던 상황에서 Universal Verifier는 거의 0에 가깝게 줄였다.
• 사람 일치도: Universal Verifier의 Cohen's κ는 0.58로 인간 주석자 간 일치도와 비슷했다.
• 학습 데이터 규모: 3,000개와 9,000개 trajectory 조건에서 고품질 검증기 필터가 더 나은 SFT 모델을 만들었다.
• 인간 개발 기간: 약 3주 동안 약 30회 실험을 수행했으며, 논문에는 32회로 정리돼 있다.
• Auto-Research: 약 하루에 같은 수의 실험을 수행해 인간 검증기 품질의 약 70%에 도달했다.
• 라벨 홀드아웃: 150개 trajectory 중 50개는 개발에 쓰고 100개는 보류했으며, 홀드아웃 데이터는 trajectory마다 두 명이 중복 라벨링했다.
• 연구 논문 보강 수치: Auto-Research가 전문가 품질의 70%를 약 5%의 시간에 얻었다고 보고한다.
• 업로드 날짜: 2026-10-05다.
• 처리 날짜: 2026-10-06이다.

결론 및 시사점

1. 판정기를 보상 함수로 쓰기 전에 판정기부터 평가해야 한다. LLM이 낸 유창한 최종 답변은 증거가 아니며, 화면·행동 이력·환경 상태와 대조해야 한다.
2. 루브릭은 작업에서 직접 파생하고 기준을 겹치지 않게 만들어야 한다. 요청받지 않은 가격 같은 유령 기준은 정답 에이전트를 부당하게 감점한다.
3. 과정과 결과를 분리해야 한다. 품절·로그인 벽·CAPTCHA 같은 환경 장벽에는 과정 크레딧을 남기고, 사용자의 최종 목표 미달은 Outcome 실패로 별도 기록해야 한다.
4. 오류를 연쇄시키지 않아야 한다. 앞 단계의 인물 선택 실수가 뒤 단계에서 정확히 수행한 순자산 보고까지 지우면 학습 신호가 무엇을 고쳐야 하는지 알려주지 못한다.
5. 스크린샷 증거는 기준별로 선택해야 한다. 모든 화면을 무작정 컨텍스트에 넣거나 마지막 화면만 보는 방식은 긴 궤적의 핵심 상태와 환각을 놓친다.
6. 사람 라벨은 개발 세트와 홀드아웃 세트로 나눠야 한다. Universal Verifier의 0.58 κ와 홀드아웃 성능은 검증기가 인간 라벨을 단순 암기하지 않았는지 점검하는 장치다.
7. 좋은 검증기는 좋은 학습 데이터를 만든다. 같은 3천 개의 궤적이라도 어떤 검증기로 걸러내느냐에 따라 SFT 모델 품질이 달라진다.
8. Auto-Research는 인간 설계와 경쟁하기보다 보완하는 도구다. 인간은 핵심 구조와 평가 직관을 발견하고, 자동 루프는 짧은 시간에 대량 실험과 세밀한 최적화를 수행한다.
9. 모델 출시 전략에 검증기와 벤치마크를 포함해야 한다. 평가 신호가 오염되면 모델 성능·RL 보상·학습 데이터가 동시에 잘못된 방향으로 움직인다.
10. 웹에서 데스크톱으로 증거 공간이 넓어진다. 터미널·텔레메트리·로그까지 읽는 Universal Verifier 계열 시스템이 엔터프라이즈 에이전트의 신뢰성 평가를 맡게 된다.

참고 링크

• 연구 논문: https://arxiv.org/abs/2604.06240
• Microsoft Fara 및 CUAVerifierBench: https://github.com/microsoft/fara
• Browserbase 블로그: https://www.browserbase.com/blog/building-verifiers-for-computer-use-agents
• Stagehand: https://www.browserbase.com/stagehand
• 행사·채널: https://ai.engineer