동료심사 전 사전논문 · 비공개 검수본. 작은 모델의 내부 표현으로 큰 모델에 작업을 넘길 시점을 판단하는 연구다. 아래 성능·비용은 논문의 특정 벤치마크 구성 결과이며 현재 서비스 가격이나 이 블로그 운영 비용을 측정한 값이 아니다.
선정 기록과 원문 열람 범위
기준일 2026-10-19 KST, 순위 3, 점수 86/100, EARLY_SIGNAL. arXiv v1의 방법·관련 실험·부록 선택 구간과 기존 검수 메모를 대조했다. 전체 도판·코드 실행과 독립 재현은 미완료다.
#기록 필드
- rank: 3
- contentId:
2026-10-19-leash-agent-escalation - status:
BACKLOG_CANDIDATE - title:
LEASH: Uncertainty-Aware Weak-to-Strong Escalation and Oversight for Computer-Use Agents - normalizedTitle:
leash uncertainty aware weak to strong escalation and oversight for computer use agents - date:
2026-10-15T17:40:12Z - venue:
arXiv preprint (cs.AI) - DOI: 확인되지 않음
- arxivId:
2610.22280 - officialUrl:
https://arxiv.org/abs/2610.22280 - evidenceGrade:
EARLY_SIGNAL - score:
86 = 18+14+19+18+8+9, 감점 0. 사전논문임을 확정 결과로 확대하지 않는다. - oneSentenceConclusion: 약한 에이전트의 hidden state를 과거 성공·실패 궤적과 비교해 강한 모델 호출과 사후 감시를 결정하는 training-free routing 신호를 제안했다.
- whyItMatters: 매 단계 최상위 모델을 쓰는 비용과 작은 모델 단독 운용의 실패 사이를 다룬다.
- keyDifference: 초기 routing, 실행 중 escalation, handoff 뒤 shadow observer를 같은 latent uncertainty로 연결한다.
- strongestEvidence: 저자 초록은 OSWorld 네 backbone에서 같은 escalation rate의 random routing보다 6.55~11.94 percentage points 높았다고 보고한다.
- metrics: Qwen3.5-35B-A3B 조합 73.66% success, $0.4117/task; 항상 Claude Opus 5 사용 72.90%와 비교해 비용 19.2% 감소라는 저자 보고.
- limitations: 동료심사 전, OSWorld 중심, 비용 산정과 모델 버전·task 구성의 외부 검증 미확인, hidden-state 접근 가능한 weak model 필요, 도메인 이동 시 불확실성 전이 미검증.
- conflictsOfInterest: 확인되지 않음
- codeAvailable: 초록 페이지에서 확인되지 않음
- dataAvailable: OSWorld 사용 외 신규 데이터 공개는 확인되지 않음
- sourceLocators: arXiv v1 §3 방법, §4 실험과 구성요소 비교, Appendix A–B의 참조 자료·보정·비용 설정; 제출 시각은 서지정보.
- revisitTriggers: peer review, 독립 재현, 코드·trajectory 공개, 다른 컴퓨터 환경 검증, 비용 기준 감사.
#한 문장 결론
LEASH는 “작은 모델이 망설일 때 큰 모델을 부른다”를 내부 표현 기반으로 구현했지만, 아직 OSWorld에서 저자들이 평가한 동료심사 전 결과다. 별도 감시 모델을 새로 학습시키지 않는다는 뜻이지, 준비 데이터나 보정 과정이 없다는 뜻은 아니다.
#중요성·차이
컴퓨터 사용 에이전트는 작업이 길어질수록 작은 실수가 누적된다. 항상 강한 API 모델을 쓰면 비싸고, 작은 오픈 모델만 쓰면 실패율이 높다. 기존 random escalation과 달리 LEASH는 약한 모델의 현재 표현이 과거 실패 궤적에 얼마나 가까운지를 보고 상향 여부를 정한다. 인계 뒤에도 약한 모델을 shadow observer로 남겨 강한 black-box 에이전트를 감시한다.
#점수는 ‘실패 확률’이 아니다
숨은 상태(hidden state)는 모델이 입력과 실행 이력을 처리하며 만든 내부 숫자 벡터다. LEASH는 과거 성공·실패 실행의 벡터를 따로 모아 비교 기준을 만든다. §3.2 식 2–3을 아래처럼 기호를 줄여 읽을 수 있다. 원문의 채널 첨자 c는 생략했지만, 실제로는 최초 질문과 실행 행동의 기준 자료를 따로 사용한다.
z는 기준 자료로 표준화한 현재 벡터, μy는 성공 또는 실패 집단의 중심이다. Σλ는 두 집단이 공유하는 공분산 추정치에 양의 정규화 항을 더한 행렬이다. 역행렬은 벡터의 각 방향이 얼마나 흔하게 변하는지를 거리 계산에 반영한다. 이 표현과 점수는 무차원이다. 실패 중심까지 더 가깝다면 두 번째 거리가 작아져 u가 커지는 방향이다. u가 0.8이라고 해서 실패 확률 80%라는 뜻은 아니다. 모든 기준에서 멀리 떨어진 새 환경을 이 상대 점수 하나로 충분히 판별한다고도 보장하지 않는다.
공분산은 여러 숫자가 각각 얼마나 흔들리고 함께 변하는지를 기록한 것이다. 이를 반영하는 이유는 “숫자 차이가 크다”와 “평소와 비교해 이례적이다”가 같지 않기 때문이다. 가상 계산 예제로 한 방향만 남겨 보자. 중심에서의 차이가 2이고 분산이 4라면 제곱거리는 2²/4=1이다. 같은 차이 2라도 분산이 1이면 제곱거리는 4가 된다. 평소 변동이 작은 방향의 같은 차이를 더 이례적으로 세는 것이다. 이는 식을 읽기 위한 단순화이며 논문의 실제 벡터·측정값이 아니다. 실제 다차원 계산에서는 방향 사이의 상관도 함께 반영하므로 각 숫자를 따로 나누는 것만으로 끝나지 않는다.
§3.3은 기준 실행의 작업별 최대 행동 점수로 임계값을 정한다. 어느 한 단계만 기준을 넘어도 작업을 인계하므로, 단계를 각각 독립 표본처럼 세는 것과 다르다. 보정 자료에서 겨냥한 상향 비율과 실제 평가에서 관측한 비율도 일치한다고 보장하지 않는다.
확인 질문: 긴 작업에서 단계별 상위 10%만 넘기면 전체 작업의 10%만 상향될까? 해설: 아니다. 한 작업 안에서 기준을 넘을 기회가 여러 번 생긴다. 그래서 논문은 개별 단계가 아닌 작업별 최대값으로 기준을 맞춘다. 10%는 이 질문을 위한 가상 비율이지 논문 성능값이 아니다.
#이론은 어디까지 보장할까
§5의 명제는 작업을 시작할 때 한 번 넘길지 정하는 경우만 다룬다. 성공·실패 집단의 표현이 공통 공분산을 가진 정규분포를 따르고, 정해진 비율만큼 정확히 인계한다는 가정이 있다. 전체 성공률의 최적화에는 점수가 높을수록 인계의 이득도 작아지지 않는다는 조건이 추가된다. 작은 모델과 큰 모델이 함께 어려워하는 작업에서는 실패 위험이 높아도 인계 이득은 작을 수 있다. 실행 중 인계와 Shadow 전체가 최적이라는 증명은 아니다.
보정 자료를 나누는 단위도 중요하다. 부록 A.2–A.3은 같은 작업의 모든 단계를 같은 묶음에 두는 교차검증을 쓴다. 한 작업의 닮은 단계들을 학습·검증 양쪽에 흩으면 새 작업을 구별하는 능력을 과대평가할 수 있기 때문이다. 숨은 상태를 재사용한다는 말이 이런 자료 분리 검사를 생략해도 된다는 뜻은 아니다.
#수치와 비교조건
평가는 OSWorld 262개 작업을 사용했다. 성공·실패 궤적을 담은 별도 참조 자료와 임계값 보정이 필요하며, shadow 임계값 설정에는 평가 작업과 분리된 99개 작업의 자료가 쓰였다. 약한 모델의 표현이 과거 실패와 닮았는지 판단하려면 비교할 이력이 먼저 있어야 한다.
LEASH에서는 Claude Opus 5가 계획·하위목표 확인을 맡는 Manager로도 동작한다. ‘항상 Opus’ 기준선에는 이 Manager 구성이 없으므로 모델 하나의 우열이 아닌 시스템 구성 비교다. 비용은 OpenRouter 기준 단가로 토큰 사용량을 환산한 추정치이며, LEASH의 Manager·강약 모델·shadow 호출을 포함한다. 실제 결제액이나 로컬 하드웨어 운영비를 측정한 값은 아니다.
6.55~11.94 포인트 향상은 같은 escalation rate의 무작위 상향과 비교한 값이다. 73.66%와 72.90%는 각각 특정 Qwen·Claude 구성의 OSWorld 성공률이며 일반적인 “동등 성능”으로 확대하면 안 된다. $0.4117/task와 19.2% 비용 감소도 논문의 가격·호출·작업 정의에 묶인 수치다.
#감시 모델이 행동을 대신하는 것은 아니다
부록 A.4·B.1에서 작은 모델의 shadow 호출은 큰 모델 실행 세 단계마다 이뤄진다. 이때 작은 모델이 제안한 행동은 실제로 실행되지 않는다. 내부 표현으로 점수를 얻고, 필요하면 큰 모델에게 현재 전략을 다시 검토하라는 중립 메시지를 전달한다. 따라서 두 모델의 행동을 투표로 고르거나 작은 모델의 지시로 큰 모델을 강제 교정하는 방식과 다르다.
개입 횟수에도 제한이 있다. 한 작업에서 최대 여섯 번이며, 큰 모델의 행동을 바꾼 개입이 두 번이면 추가 개입을 막는다. 감시는 무제한 재시도나 모든 오류의 차단을 뜻하지 않는다.
또 runtime AUROC는 Manager가 붙인 하위목표 구간의 성공·실패를 얼마나 잘 가르는지 평가한다. 이를 개별 마우스 클릭 하나의 정답 확률로 읽을 수는 없다.
확인 질문: 작은 모델이 위험하다고 판단하면 그 모델의 대안 행동을 바로 실행할까? 아니다. 이 연구에서는 큰 모델이 제어권을 유지하며 다시 판단한다.
#한계·반대 증거
#‘같은 호출 비율’과 ‘같은 비용’은 다르다
Table 1의 Qwen 구성에서 무작위 상향은 작업의 64.4%를 넘겨 성공률 61.72%, 추정 비용 $0.3768이었다. LEASH는 64.1%를 넘겨 73.66%, $0.4117이었다. 상향 비율이 비슷한 비교에서 성공률은 높지만 비용도 더 든다. 이를 ‘무작위 상향보다 모든 면에서 싸고 좋다’고 요약하면 틀린다. 앞의 19.2% 비용 절감은 항상 강한 모델을 쓰는 다른 기준선과의 비교다.
논문은 실행 중 점수를 계산할 때 기존 행동 생성의 숨은 상태를 재사용한다고 설명한다. 그렇다고 전체 감시가 무료인 것은 아니다. 최초 판단과 인계 뒤 감시는 작은 모델 호출이 필요하고, 개입은 강한 모델의 추가 계산을 유발할 수 있다(부록 B.4). 같은 작업 수·상향 비율·모델 가격 중 무엇을 고정한 비교인지 확인해야 비용 주장을 옮길 수 있다.
확인 질문: 큰 모델을 부른 작업 비율이 같다면 비용도 같을까? 아니다. 호출 횟수와 입력·출력 길이, 관리자·감시·재검토 계산이 다를 수 있다. 이 연구에서 ‘작업을 넘긴 비율’과 ‘전체 토큰 비용’은 별도 지표다.
본문의 구성요소 제거 실험에서 특정 Qwen 구성에 shadow 감시를 더하면 성공률이 67.94%에서 73.66%로 변했고, 추정 비용은 작업당 $0.4050에서 $0.4117로 증가했다. 이 비교는 해당 설정 안의 효과이지 다른 환경의 효과를 보장하지 않는다. weak model hidden state가 필요하므로 폐쇄형 모델끼리의 routing에는 바로 적용되지 않는다. OSWorld에서 실패와 닮은 표현이 다른 UI·언어·권한 환경에서도 불확실성을 뜻한다는 보장도 없다. 전체 수식·그림의 대응표, 독립 재현과 현장 운영 검증은 남아 있다.
#code/data와 재검토
공개 본문·관련 부록은 대조했지만 공식 코드 저장소의 공개 범위·라이선스·실행 환경은 별도 감사하지 않았다. 저장소와 실행 근거 확인, 독립된 동일 예산 비교, 다른 컴퓨터 벤치마크 결과, 동료심사 또는 중요한 반박이 나오면 재검토한다.
#출처
- Wang et al., arXiv:2610.22280, submitted 2026-10-15 17:40:12 UTC