IBM·아티피셜 애널리시스 ITBench-AA, 프런티어 모델 모두 50% 미만 기록
Artificial Analysis와 IBM Software Innovation Lab이 5월 27일 에이전트 기반 엔터프라이즈 IT 작업을 평가하는 새 벤치마크 시리즈 ITBench-AA를 공개했다. 첫 영역은 사이트 신뢰성 엔지니어링(SRE)이며, 평가에 참여한 모든 프런티어 모델이 50% 미만 점수에 그쳐 ITBench-AA SRE는 현재 가장 포화되지 않은 에이전트 벤치마크 가운데 하나로 자리 잡았다.
IBM이 엔터프라이즈 IT 운영 전문성을 바탕으로 ITBench 데이터셋을 만들었고, Artificial Analysis가 지난 6개월간 IBM과 협업해 프런티어 AI 평가용 구현을 개발했다. 시리즈는 SRE에서 시작해 재무 운영(FinOps)과 최고정보보안책임자(CISO) 작업으로 확장될 예정이다.
ITBench-AA SRE는 총 59개 SRE 작업으로 구성된다. 40개는 공개 작업, 19개는 새로 만든 보류(held-out) 작업이다. 각 작업은 알림, 이벤트, 트레이스, 메트릭, 로그, 애플리케이션 토폴로지를 포함한 Kubernetes 사고 스냅샷을 제공하며, 모델은 사고를 일으킨 최소한의 독립적인 근본 원인 Kubernetes 엔티티를 찾아내야 한다. 결함은 리소스 쿼터 고갈, 롤아웃 실패, 커넥션 풀 고갈, 네트워크 분할 등 인프라·서비스·애플리케이션·카오스 주입 유형을 포함한다.
평가는 Artificial Analysis의 오픈소스 Stirrup 레퍼런스 하니스 위에서 진행되며, 모델은 샌드박스 파일 시스템에 셸로 접근한다. 작업당 100턴 제한, 3회 반복이 적용되고, 점수는 풀 리콜 조건의 평균 정밀도(average precision at full recall)로 계산된다. 모든 모델이 동일한 하니스(Stirrup)에서 돌아 모델 간 공정 비교가 가능하다.
Claude Opus 4.7(Adaptive Reasoning, Max Effort)이 47%로 리더보드 1위를 차지했고, GPT-5.5(xhigh)가 46%, Qwen3.7 Max가 42%로 뒤를 이었다. 오픈 가중치 부문에서는 GLM-5.1(Reasoning)이 40%로 선두에 섰으며, 사실상 Gemini 3.5 Flash(high)와 동률을 이뤘다. DeepSeek V4 Pro(Reasoning, Max Effort)는 38%, Gemma 4 31B(Reasoning)는 37%로 Gemini 3.1 Pro Preview의 30%를 앞섰다.
더 긴 추론 궤적이 더 높은 정확도를 보장하지 않는다는 점도 드러났다. GPT-5.5(xhigh)는 작업당 평균 31턴으로 46%를 기록한 반면, Gemini 3.1 Pro Preview는 평균 83턴을 쓰고도 30%에 머물렀다. 과도하게 조사하는 모델은 상류의 결함 주입 메커니즘이나 동반 증상을 거짓 양성으로 제출하는 경향을 보였다.
채점 방식상 모델이 정답 근본 원인 가운데 하나라도 놓치면 해당 회차 점수가 0이 되고, 모두 식별한 경우에만 정밀도(true positives ÷ (true positives + false positives))가 점수가 된다. 헤드라인 점수는 59개 작업 × 3회 반복 평균이다. 정답 외 엔티티(예: chaos-mesh 컨트롤러나 동반 증상)를 추가하면 거짓 양성으로 처리돼 점수가 깎인다.
오픈 가중치 모델들이 비용 프런티어를 차지했다. Gemma 4 31B(Reasoning)는 작업당 0.14달러에 37%로 Gemini 3.1 Pro Preview(2.23달러, 30%)를 점수와 비용 양쪽에서 앞섰다. GLM-5.1(Reasoning)은 1.23달러에 40%로 Gemini 3.5 Flash(high, 1.70달러)와 점수가 같으면서 비용은 더 낮았다. 1위 Claude Opus 4.7(Adaptive Reasoning, Max Effort)은 작업당 5.38달러로 가장 비싼 모델이었다.
한 공개 SRE 작업에서는 에이전트가 프런트엔드 경로의 사용자 장애를 발견한 뒤 알림으로 사고 구간을 잡고, 트레이스·로그로 프런트엔드 트래픽 실패를 좁힌 다음, 토폴로지와 Kubernetes 매니페스트를 통해 프런트엔드를 차단하는 네트워크 정책을 찾아냈다. 정답 근본 원인 엔티티는 otel-demo/NetworkPolicy/frontend-block-all-ports였다.