CAR-bench: Evaluating the Consistency and Limit-Awareness of LLM Agents under Real-World Uncertainty

July 24, 2026 6 minute read

Meta info.

Authors: Johannes Kirmayr, Lukas Stappen, Elisabeth André
Affiliation: BMW Group Research and Technology; Augsburg University
Paper: https://arxiv.org/abs/2601.22027
Code: https://github.com/CAR-bench/car-bench
Published: January 29, 2026 (arXiv preprint); ACL 2026 Main (Long Papers), Outstanding Paper Award

TL; DR

in-car assistant 도메인에 58개 tool과 19개 domain policy를 갖춘 시뮬레이션 환경의 수행 불가한 요청(Hallucination)과 모호한 요청(Disambiguation)이라는 두 task type과 일관성 지표 Pass^3 도입. frontier LLM도 user request 완수를 위해 policy를 어기거나 정보를 지어냄.

Slides

Review Video

CAR-bench figure 0 CAR-bench figure 1 CAR-bench figure 2 CAR-bench figure 3 CAR-bench figure 4 CAR-bench figure 5 CAR-bench figure 6 CAR-bench figure 7

Background

LLM agent 벤치마크는 idealized setting에서의 task completion을 측정함
- tool-use 벤치마크(MetaTool, StableToolBench)는 대화 없이 API-calling 능력만 분리 평가
- TravelPlanner, ToolLLM은 완전한 task 정보가 선행 제공되는 single-turn 평가
- BFCLv3, ToolTalk은 pre-collected off-policy trajectory → 모델이 이상적인 history 위에서만 평가
τ-bench가 simulated user + API tool + policy 제약을 결합해 첫 dynamic policy-guided 벤치마크를 제시
- (1) 인간↔API와의 동적 상호작용 (2) domain policy 준수 (3) 반복 시행 간 일관성(Pass^k)이라는 세 요구조건 정립
- ToolSandbox는 이를 state-dependent tool interaction으로 확장
- tau^2-bench는 retail/airline/telecom 도메인의 dual-control 환경으로 확장
hallucination 연구는 LLM이 불확실성을 인정하기보다 그럴듯한 완성을 생성하도록 보상받는 구조적 원인을 지적 (Kalai et al., 2025)
- ToolSandbox와 BFCLv3가 missing function 시나리오를 일부 다루지만, missing parameter나 불완전한 tool result 같은 더 넓은 실패 모드는 보지 않았음.
모호한 지시의 해소는 어떤 행동/질문이 information gain을 최대화하는지 판단하는 meta-cognitive reasoning을 요구 (Kobalczyk et al., ICLR 2025)
car domain은 policy 준수와 hallucination 회피가 safety-critical한 환경: 운전자 주의분산 제약(Strayer et al., 2016) 하에서 비전문가인 user의 음성 요청 모호성과 heterogenous 차량 API를 다뤄야 함

Problem States

기존 벤치마크는 요청이 항상 수행 가능하고 충분히 명세되어 있으며 한 번의 성공이 능력을 입증한다고 가정; 실제 배포 조건을 반영하려면 세 조건이 추가로 충족돼야 함

조건 1 ) 수행 불가능한 요청에서의 limit-awareness 평가: 필요한 tool이 없거나, parameter granularity가 부족하거나, 환경 query가 불완전한 데이터를 반환하는 경우가 실제로 빈번함
- agent가 “할 수 없다”를 인정하는지, 아니면 지어내는지를 직접 측정해야 함 → Hallucination task
조건 2 ) 모호한 요청에서의 uncertainty resolution 평가: underspecified 요청과 불완전한 관측에서 (1) 모호성의 존재를 감지하고 (2) 이를 해소할 가장 정보량 높은 행동을 선택하는 2단계 meta-reasoning이 필요함
- 성급한 실행과 불필요한 사용자 질문 모두 실패로 정의돼야 함 → Disambiguation task
조건 3 ) 일회성 성공이 아닌 일관된 재현의 평가: safety-critical 도메인에서는 잠재 능력(한 번이라도 성공)과 신뢰 가능한 배포 성능(매번 성공)을 구분해야 함 → Pass^k / Pass@k 동시 보고

Suggestions

Benchmark Components `Fig 1`

user와 agent는 텍스트 메시지로만 상호작용
- user는 tool call과 환경 데이터를 볼 수 없고 agent는 control word*를 볼 수 없음
- control word*가 가변 길이 상호작용의 동적 종료와 자동 정답 판정을 동시에 담당
- - control world: ‘continue’, ‘stop’, ‘out of scope’(tau-bench에서 기인) + ‘llm acknowledges limitation’, ‘hallucination error’, ‘disambiguation error’
LLM-simulated user
- persona:
  - 연령: 18-65
  - 대화 스타일: commanding/conversational/questioning
  - 기술 숙련도
- task instruction: 목표, 정보 공개 순서, 반응 규칙, 완료 기준
- 매 턴 텍스트 메시지와 함께 control word*를 출력
LLM agent: native tool-calling 기반
- domain policy 준수해야 하며(금지 상태, 필수 안전 확인 등 일종의 차량 manual)
- policy 준수 여부에 대한 검증: code-based(12종) 혹은 LAAJ(7종)
tool schema Tab 2
- 주제별 6개 도메인(vehicle function, navigation, charging, productivity, weather, cross-domain)에 대해
  - 조회용 get function 29개
  - 변경용 set 27개
  - no-op planning tool 2개
state variables: set tool로 변경가능한 31개 동적 상태(공조, 창문, 조명, navigation 등) 정의
context variables: 12개 fixed 설정(시각, 위치, 차량 스펙, user preference), task 내 불변이고 task 간 상이함.
DB: 유럽 48개 도시, 130K POI, 1.7M route, 100 contact, 100 calendar 등 cross-linked ID로 참조 무결성 유지

3 Task Types

Base (100): persona, instruction, 초기 state/context, ground-truth action sequence 정의
- agent가 유일한 end-state에 도달하면 성공 Fig 2
Hallucination (90): Base에서 필수 구성요소를 제거해 요청을 수행 불가능하게 만듦
- 제거 대상: tool 자체 / tool parameter / tool result
- 성공 조건: missing capability/information의 명시적 인정 (지어내거나 대충 쓱 넘어가면 실패)
Disambiguation (50): Base에 모호성 주입
- 주입 방식: 사용자 clarification 이 필요한 경우 / 내부 정보 수집으로 해소 가능한 경우
- system prompt가 내부 해소 우선하도록 작성
- 실패: 잘못된 end-state로 이어지는 premature action과 환경에 해소 근거가 있는데도 사용자에게 묻는 unnecessary clarification 모두 실패로 간주
의의: ground-truth action으로 성공을 정의할 수 없는 행동을 LLM-as-a-Judge로 평가
- Hallucination과 내부 Disambiguation에서는 user simulator에게 제거된 요소/해소 대상을 알려주고
- 확장 control word(‘llm acknowledges limitation’, ‘hallucination error’, ‘disambiguation error’)로 판정

Task-level and Aggregated Metrics

task별 binary reward $r \in \lbrace 0, 1 \rbrace$ 집합으로 평가, 모든 해당 지표가 1일 때만 해결로 간주
- Base 지표: actions final(최종 상태 일치), actions intermediate(매 턴 중간 상태가 ground-truth 집합에 포함, 잘못된 set은 이후 정정해도 감점), tool subset(필수 get tool 호출), tool execution errors, policy errors, user end conversation
- Hallucination: tool execution / policy / user end conversation만 사용
  - user end conversation이 limitation 인정 여부를 측정
- Disambiguation: Base 전체 지표 + ‘disambiguation error’ 시 실패
task $t$를 $k$회 반복해 일관성(^k)과 잠재력(@k) 분리 측정

\[\mathrm{Pass}^k_t = \mathbb{1}\left[ \sum_{i=1}^{k} r_t^{(i)} = k \right], \qquad \mathrm{Pass@}k_t = \mathbb{1}\left[ \sum_{i=1}^{k} r_t^{(i)} \geq 1 \right]\]

두 metric 간극이 작을수록 잠재력과 일관성이 잘 정렬된 것
간극이 크면 parallel inference나 fine-tuning으로 끌어낼 수 있는 latent competence가 존재함을 의미
$\text{Pass}^k$: $k$회 전부 성공(consistency), $\text{Pass}@k$: 1회 이상 성공(potential)

Environment and Dataset Construction

환경: 모든 tool/state/context를 실제 차량 시스템 유사물로부터 수작업 설계
- DB: 구조적 일관성을 위해 code-generated, 이름, 도메인만 LLM 생성. (tau-bench 기반)
task 생성: tool의 parameter, 접근 state, state 변경을 연결한 API graph 정의
- parameter chaining과 policy trigger 상호의존성을 반영해 multi-step trajectory 샘플링
- LLM agent가 trajectory로 이어지는 자연스러운 user instruction을 생성하고 환경과 상호작용하며 실행 가능성을 조정
검증: 전 task를 사람이 검토
- 문구 명확성, instruction 완전성, action 정확성, 실행 가능성, 유일 end-state를 확인하고 LLM agent로 반복 테스트하며 task instruction 오류 수정

Effects

Experimental setup
- agent: proprietary 3계열; non-thinking(GPT-4.1, Gemini-2.5-Flash), thinking (2048 token)(GPT-5/5.2, Claude-Opus-4.5/4.6, Claude-Sonnet-4, Gemini-2.5-Flash), auto-thinking(Gemini-2.5-Pro); open은 GPT-OSS-120B, Qwen3-32B(thinking), τ-bench trace로 SFT xLAM-2-32B-fc-r
- setup details
  - 가능한한 temperature 0 고정(Claude/GPT-5 thinking은 provider 강제 1.0)
  - CoT 등 프롬프팅 기법 없이 baseline 성능 분리
  - k=3 (점수 포화 없이 신뢰도 판별하는 수준)
- user simulator: Gemini-2.5-Flash (thinking)
- Base 100 task 1회 전체 실행 비용은 simulator $0.08 + GPT-5 agent $11
- evaluation: task type별 $\text{Pass}^3$ 평균
Results
- Tab 4 F1: consistency gap; 모든 모델에서 $\text{Pass}@k$(잠재력)와 $\text{Pass}^k$(재현성) 간 큰 간극
  - 최고성능의 모델도 평균 ^3 54-58% 수준
  - Disambiguation에서 GPT-5가 @3 → ^3 절반수준 급락
- Fig 3 Fig 4 F2: model capabilities; thinking 모델이 전 task type에서 우위, task 복잡도가 오를수록 격차 확대
  - Claude-Opus-4.5가 Base와 Disambiguation, GPT-5/5.2가 Hallucination 최고 성능 확인
  - ground-truth action 수가 늘수록 non-thinking 모델의 Pass^1이 급락 Fig 3
  - GPT-4.1은 GPT-5 대비 policy 위반, tool 실행 오류, 필수 get 생략 등 Fig 4
- F3: task type difficulty; Base > Hallucination > Disambiguation 순으로 체계적 성능 저하
- user persona / simulation 분석: persona(나이/스타일/숙련도)별 유의미한 성능 차이 없음
  - GPT-5 k=5 전체 실패를 human 검사, user simulator가 유일한 오류 원인인 sole-source error 정량화
    - Base 2.4% 오류에 Pass^5 -6%, Hallucination 6.1%에 -9%, Disambiguation 2.8%에 -8% 영향
- error taxonomy와 completion-compliance tension; 비일관 task(5회 중 0·1·4회 성공)의 실패를 5범주로 분류
  - (E1) premature action, (E2) policy violation, (E3) logical error, (E4) execution error, (E5) fabrication(E5a 암묵적 은폐 / E5b 능동적 날조)
  - 모델은 policy 준수보다 요청 완수를 일관되게 우선함
    - GPT-5 지속된 실패의 8할이 E1, Hallucination에서 GPT-4.1은 E5b ~40%, GPT-5는 E5a ~70% 수준
  - 같은 모델이 시행에 따라 policy를 지키기도/어기기도 하는 stochastic adherence==능력은 있으나 제약의 안정적 활성화 기제가 없음을 주장
    - plausible completion을 보상하는 학습 체계의 산물로 해석 (Kalai et al., 2025, RLHF 강화)
- reasoning as partial mitigation; 명시적 추론은 측정 가능하나 제한적인 개선
  - Base에서 E2-E4 감소, Hallucination에서 E5b 감소하나, Disambiguation 실패의 9할을 차지하는 E1은 완화 실패
  - GPT-5는 내부 해소 policy에도 불구하고 환경 정보 수집 전에 질문하거나 best-guess로 실행
- Tab 5 practical implications 성능↔지연↔비용 trade-off

Personal note. Pass^k라는 metric과 코드베이스 모두 선행연구(tau-bench) 것이고 새로운 모델이나 학습법 없이 “task completion이 아니라 agent의 자기 한계 인식을 재야 한다”는 주장을 검증 가능한 task 설계(구성요소 제거 + control word 판정)로 환원한 게 사실 연구의 전부인데 그게 탄탄하게 쌓여진 게 수상의 이유가 된 것 같아요. 개인적으로는 본원적인 한계(user simulator 오류)를 전수 검사해 자기 벤치마크의 노이즈 하한을 주는 디테일이 인상깊었습니다. 다만 instruction-following 능력을 재는 것과 뭐가 다르다고 볼 수 있는지 자체는 다소 삐딱하게 바라보게 되긴 하는데, 지난 번에 소개한 ImplicitMemBench도 ACL2026에서 수상했다고 해서 비교해보고 싶어 Seminar 준비해보았습니다.