Agentic Abstention: 에이전트는 행동 대신 언제 중단해야 하는가

도구를 호출하면서 환경과 여러 차례 상호작용하는 에이전트는 단일턴 답변 시스템과 달리 중단 시점을 늦추거나 전혀 인식하지 못해 불필요한 비용과 오류를 초래한다. 이 논문은 그러한 순차적 중단 결정 문제를 정식화하고 28,000개가 넘는 과제를 통해 에이전트의 중단 능력을 대규모로 평가했다. 실험 결과는 단순한 능력 향상만으로는 해결되지 않는 시기적절한 중단의 중요성을 보여주며, 정책이 언제 중단해야 하는지를 학습하거나 컨텍스트로 보강하는 방법이 필요함을 입증했다.

에이전틱 절제 문제는 에이전트가 연속적 상호작용을 통해 점진적으로 정보를 획득하는 설정에서 발생한다. 전통적 LLM의 단일턴 abstention 문제는 '지금 답하거나 중단하라'는 한 번의 선택으로 정리되지만, 도구 사용 에이전트는 ACT(도구호출)를 반복할 수 있어 중단 시점이 뒤로 지연될 수 있다. 이로 인해 '초기 상태에서 해결 가능해 보이던' 과제가 상호작용을 통해 불가능하다는 사실이 드러날 때까지 에이전트가 계속 행동하는 현상이 발생한다.

본 논문은 이러한 순차적 의사결정 구조를 POMDP로 모델링해 관찰이 누적되는 과정과 정책의 히스토리 의존성 π(a_t|h_t)를 명확히 했다. POMDP 표기는 상태 s_t가 부분적으로 관찰 가능하고 관찰 o_t가 환경 함수 Ω에 의해 생성된다는 점을 수학적으로 표현한다. 이를 통해 '중단이 정당해지는 최초의 시점 w_i'라는 기준을 정의하고 AbsRec@K와 같은 시간 기반 성능 지표를 정량화할 수 있게 했다.

convolve의 직관은 과거 상호작용 궤적에서 어떤 관찰과 어떤 행동 조합이 중단을 정당화하거나 지연시켰는지 추출하는 것이다. 구체적으로, reflection 모델은 에피소드 궤적 τ^(k)를 입력으로 받아 어떤 관찰이 중단을 불러왔는지와 어떤 행동이 지연을 초래했는지 신호 y^(k)로 변환한다. curator는 이 신호들을 요약해 구조화된 플레이북을 만들고, 이후 에피소드의 시스템 컨텍스트에 플레이북을 포함시켜 모델이 동일한 상황에서 더 빠르게 중단 결정을 내리도록 돕는다.

전체 접근 방식은 세 가지 축으로 구성된다: 문제 정의 및 평가척도 설계, 데이터셋 구성, 그리고 컨텍스트 기반 학습 방법 convolve의 구현이다. 문제 정의 단계에서는 Agentic Abstention을 POMDP로 형식화하고 AbsRec@K, Timely Recall(AbsRec@w_i), AbsRec@10, SPL, 과도한 중단률(over-abstention) 등의 지표를 도입해 시기와 전체 복구력을 분리해서 측정했다. 이 지표들은 중단이 정당해지는 시점 이전의 조기 중단은 정답으로 간주하지 않는 평가 규칙을 포함해 실험적 일관성을 확보했다.

데이터 구성에서는 WebShop, Terminal-Bench 2.0, AbstentionBench에서 원본 인스턴스를 유지하거나 변형해 총 28,000개 이상의 인스턴스를 만들었다. Web 시나리오에서는 원본 500개를 보존하고 Request-based(문장 자체 불가해) 249개와 Environment-based(Missing Target) 251개를 추가해 1,000개 세트를 구성했다. Terminal에서는 원본 89개를 포함해 환경을 변경하거나 지시문을 재작성해 총 277개 인스턴트를 만들었고 QA에서는 AbstentionBench의 16개 데이터셋 하위집합을 사용해 27,073개 샘플을 준비했다.

convolve 파이프라인은 롤아웃 단계, 반성(reflection) 단계, 큐레이션 단계, 그리고 플레이북 인젝션 단계로 나뉜다. 각 트레이닝 에피소드에서 에이전트는 환경과 상호작용해 궤적 τ^(k)를 생성하고, reflection 모델이 τ^(k)로부터 중단 관련 신호 y^(k)를 추출한다. curator는 이 신호를 고정 섹션 구조로 정리해 플레이북을 업데이트하고, 이후 평가 단계에서는 해당 플레이북을 시스템 프롬프트에 추가해 모델 파라미터 변경 없이 중단 성능을 개선한다. 실험 설정에서는 convolve 학습에 20개의 예시 궤적을 사용하고 플레이북 버짓과 토크나이제이션 한도를 명시적으로 관리했다.

전반적으로 에이전트의 중단 능력은 시기 문제로 인해 여전히 어려움을 보였다. Web 시나리오에서 대부분의 모델은 AbsRec@10에서 0.5 미만의 성능을 보였고 AbsRec@1(시기적절한 중단)은 대체로 0.0–0.3 범위에 몰려 있었다. Terminal 시나리오에서는 동일한 베이스 모델이라도 스캐폴드 차이로 성능 편차가 크게 나타나 Codex CLI가 Terminus 2보다 월등히 높은 AbsRec@10(약 0.38 대 0.18)을 기록했다.

세부 실험에서는 모델 규모, reasoning 모드, 스캐폴드가 서로 다른 방식으로 중단 성능에 영향을 미쳤다. 모델 규모는 주로 전체 중단 복구력(AbsRec@10)을 개선했지만 시기적절한 중단(AbsRec@1)은 거의 개선하지 못했다. reasoning을 늘리면 일부 경우에 AbsRec@1이 개선되었으나 AbsRec@10은 감소하는 등 타협이 관찰되었고, Web 시나리오에서는 상호작용이 길어질수록 과도한 중단율이 커지는 현상이 확인되었다.

convolve의 적용은 시기적절한 중단을 크게 개선했다. WebShop 실험에서 Llama-3.3-70B의 AbsRec@1은 베이스 26.7%에서 convolve 적용 후 57.4%로 상승했고 AbsRec@10은 83.2%에서 100.0%로 상승했다. 이 개선은 단지 20개의 트레이닝 궤적로도 가능했으며, 작은 모델이 만든 플레이북이 더 큰 모델로 전이되어 유의미한 성능 향상을 제공할 수 있음을 보였다.

아키텍처 관점에서 논문은 에이전트 상호작용을 POMDP ℳ=(𝒮,𝒜,𝒪,T,Ω,R)로 정의했고 행동 집합을 {ANSWER, ABSTAIN, ACT}로 제한했다. 입력으로 초기 지시 x와 누적 관찰 o_1...o_t를 포함하는 히스토리 h_t를 사용하며 정책 π(a_t|h_t)가 히스토리 기반 확률 분포로 행동을 선택한다. 평가 지표는 각 인스턴스에 대해 중단이 정당해지는 최초 시점 w_i를 주어 AbsRec@K를 계산하도록 설계되었다.

convolve의 수학적·알고리즘적 구성은 에피소드 롤아웃 τ^(k)=(x^(k),o_1^(k),a_1^(k),...,o_Tk^(k),a_Tk^(k))을 생성한 뒤 reflection 함수 φ(τ^(k))로부터 에피소드 수준의 신호 y^(k)를 생성하는 단계로 이루어진다. 이어서 업데이트 연산자 𝒰(c^(k),τ^(k),y^(k))가 기존 컨텍스트 c^(k)에 새로운 플레이북 항목을 추가해 c^(k+1)을 만든다. 플레이북은 고정 섹션 구조를 가지며 curator는 reflection 출력의 요약을 정형화된 추가 연산으로 삽입한다.

구현 세부사항으로는 playbook·reflection·curator의 토큰 제한과 truncation 전략이 명시되어 있다. 롤아웃과 reflection 모델은 최대 1024 토큰을, curator는 512 토큰을 사용했고 플레이북 예산은 80,000 토큰으로 설정되었다. 컨텍스트 오버플로를 피하기 위해 curator 입력은 결정론적으로 6,000 토큰으로 잘라 처리하고 최근 reflection에는 최대 1,200 토큰을 예약했다. 학습은 오프라인으로 한 epoch 동안 수행했고 에피소드당 최대 두 번의 reflection/update 라운드를 허용했다.

데이터 분할과 실험 설계에서 WebShop의 abstention 전용 하위집합을 사용해 500개 중 20개를 convolve 학습에, 8개를 검증에, 101개를 평가용 held-out으로 배치했다. 분할은 시나리오별(stratified)로 이루어져 동일 기반의 변형이 서로 다른 집합에 섞이지 않도록 그룹화했다. 이런 구성은 플레이북이 과적합되지 않고 일반화되는지 평가하는 목적을 가진다.

논문은 평가 범위를 WebShop, Terminal-Bench 2.0, 그리고 AbstentionBench에서 파생된 시나리오로 제한해 모든 종류의 에이전트 환경을 포괄하지는 못했다. 연구진은 다양한 스캐폴드와 모델 조합을 선택적으로 평가했으며 모든 모델·스캐폴드 조합을 실험에 포함시키지 않았기 때문에 특정 조합에서의 일반화 가능성은 추가 검증이 필요하다. 또한 본 작업에서는 보상 최적화(reward optimization)를 목표로 삼지 않았고 POMDP에서의 보상 함수 최적화는 다루지 않아 강화학습 기반 접근과의 비교는 이루어지지 않았다.