EVA-Bench Data 2.0: 3개 도메인, 121개 도구, 213개 시나리오

음성 에이전트의 실패는 종종 매우 도메인 특화적입니다. 항공편 재예약 거래에서 영숫자 확인 코드를 완벽하게 처리하는 시스템이라도 HR 시스템의 복잡한 정책을 다룰 때는 어려움을 겪을 수 있습니다. 서로 다른 도메인은 에이전트가 다양한 어휘, 워크플로우 복잡성 및 사용자 기대치에 적응하는 능력을 테스트합니다. 따라서 이번 출시로 EVA-Bench는 하나의 엔터프라이즈 도메인에서 세 가지(항공사 고객 서비스 관리 (CSM), 엔터프라이즈 IT 서비스 관리 (ITSM), 헬스케어 HR 서비스 제공 (HRSD))로 확장되었습니다. 이 세 도메인은 총 121개의 도구를 아우르며 213개의 평가 시나리오를 구성하며, 이는 기존 출시 대비 약 4배 증가한 시나리오 커버리지를 의미합니다. 모든 시나리오는 세 가지 최첨단 모델(OpenAI GPT-5.4, Google Gemini 3.1 Pro, Anthropic Claude Opus 4.6)을 대상으로 해결 가능성 검증을 거쳤으므로, 이 벤치마크는 도전적이면서도 공정합니다. 세 데이터셋 모두 오픈 소스이며 다운로드가 가능합니다:

from datasets import load_dataset
# Airline Customer Service Management (CSM) — 50 scenarios
airline = load_dataset("ServiceNow-AI/eva-bench", "airline", split="test")
...

EVA-Bench는 여러 청중을 위해 구축되었습니다. 만약 음성 에이전트를 평가하고 있다면, 35개 이상의 고유한 워크플로우를 아우르는 다양한 현실적인 엔터프라이즈 시나리오에 대해 실행할 수 있습니다. 자체 평가 데이터셋을 구축하는 경우, 본 게시물은 종단 간(end-to-end) 생성 및 검증 프로세스를 충분히 자세하게 설명하여 실질적인 참고 자료가 될 것입니다. 각 도메인이 어떻게 설계되고 생성되었는지 안내하고 두 가지 새로운 추가 사항에 대해 깊이 있게 다룹니다. 또한 영어 전용 엔터프라이즈 배포를 넘어 벤치마크의 범위를 넓힐 예정인 향후 다국어 확장 기능도 미리 보여드립니다.

세 가지 도메인에 걸쳐 EVA-Bench 데이터셋 설계는 다섯 가지 원칙을 따랐습니다.

음성 우선 범위 (Voice-first scope). 모든 기업 워크플로우 (Enterprise workflow)가 음성 벤치마크에 포함되어야 하는 것은 아닙니다. 우리는 먼저 각 도메인 내에서 실제로 전화로 처리되는 작업이 무엇인지 식별한 다음, 해당 하위 집합에서 가장 일반적인 흐름을 선택했습니다. 이를 통해 시나리오가 현실적인 통화 패턴에 기반하도록 유지했습니다.

현실성 (Realism). 도구 스키마 (Tool schemas)는 실제 운영 플랫폼 (Production platform)에서 사용하는 API 유형을 모델로 설계되었습니다. 시나리오 정책은 실제 기업의 제약 사항에서 가져왔습니다. Healthcare HRSD 도메인의 경우, NPI 번호, FMLA, 보험 보장 범위 등을 포함하여 실제 미국 의료 정책 및 행정 시스템에 시나리오를 기반을 두었으며, 이를 통해 벤치마크가 실무자들이 실제 생활에서 접하는 도메인을 반영하도록 했습니다.

다양성 (Variety). 단순히 동일한 작업을 반복하여 데이터셋을 확장하는 것은 평가 신호 (Evaluation signal)가 제한적입니다. 이를 방지하기 위해 우리는 각 도메인에 대한 특정 워크플로우를 정의하고 세 가지 시나리오 유형에 걸쳐 샘플링했습니다: 단일 의도 통화 (Single-intent calls), 단일 대화 내에서 최대 4개의 의도를 포함하는 다중 의도 통화 (Multi-intent calls), 그리고 통화자가 문제 해결 단계를 우회하거나, 긴급도를 잘못 분류하거나, 권한이 없는 기록에 접근하려고 시도하는 적대적 통화 (Adversarial calls)입니다. 단일 및 다중 의도 시나리오 내에는 사용자의 목표를 충족할 수 없는 사례도 포함했는데, 이는 실제 통화량이 모두 성공적인 경로 (Happy-path)로만 이루어지지 않기 때문이며, 우리의 경험상 모델은 성공적인 상호작용보다 충족할 수 없는 목표를 다룰 때 더 어려움을 겪는 경향이 있기 때문입니다.

인증 (Authentication). 이전 연구(EVA-Bench 및 τ-Voice)는 인증을 음성 에이전트 (Voice agents)의 가장 일관된 실패 지점 중 하나로 식별했습니다. EVA-Bench의 모든 도메인에는 인증 흐름이 포함되어 있으며, 구체적인 메커니즘은 작업에 맞춰 조정되었습니다. 예를 들어, OTP 기반의 권한 상승 (Elevation)은 모든 시나리오에 일률적으로 적용되는 것이 아니라, 실제 운영 시스템에서 요구되는 경우에만 나타납니다.

재현성 (Reproducibility). 재현 가능한 시나리오가 없다면, 점수 차이가 실제 능력의 격차를 반영하는 것인지 아니면 시나리오가 진행된 방식에서 비롯된 인위적인 결과물인지 알기 어렵습니다. 우리는 모든 시나리오가 정확히 하나의 올바른 해결 경로 (resolution path)를 갖도록 데이터셋을 설계했습니다. 사용자 목표 (User goal) 구성은 시뮬레이터가 일관되게 동작하는 데 필요한 정보와 지침을 항상 보유하도록 보장하며, 시나리오 생성 과정에서는 동일한 결과를 달성할 수 있는 여러 개의 유효한 행동 시퀀스 (action sequences)가 존재하는 모든 사례를 명시적으로 확인하고 제거합니다.

결합 생성 (Joint generation). 시나리오는 GPT-5.4를 백본 (backbone)으로 사용하는 그래프 기반 합성 데이터 생성 파이프라인인 SyGra를 사용하여 생성됩니다. 각 시나리오는 구성 요소들을 독립적으로 생성할 때 발생하는 불일치를 방지하기 위해, 함께 생성되는 세 가지의 결합된 일관적 구성 요소를 필요로 합니다:

사용자 목표 (User goal). 재현성을 위해서는 시나리오가 실행될 때마다 사용자 시뮬레이터가 동일하게 동작해야 합니다. 모호한 의도 표명은 이를 달성할 수 없습니다. 시뮬레이터는 실행할 때마다 서로 다른 판단을 내리게 되어 일관되지 않은 평가 신호를 생성할 것이기 때문입니다. 이를 제거하기 위해, 사용자 목표는 시뮬레이터가 마주칠 가능성이 있는 모든 상황을 다루는 결정 트리 (decision tree) 형태로 구조화되었습니다. 사용자 목표는 사용자가 요청해야 할 사항을 정확히 지정하며, 언제 거절할지, 언제 대안을 요청할지, 그리고 언제 수락할지를 정확히 명시하는 협상 시퀀스 (negotiation sequence)를 포함합니다. 대기 항공편을 수락할지 또는 대체 공항을 이용할지와 같은 일반적인 예외 사례 (edge cases)들은 시뮬레이터의 해석에 맡기지 않고 명시적인 지침으로 처리됩니다. 해결 조건 (resolution condition)은 구두 약속이 아닌 확인 번호나 케이스 ID (case ID)와 같이 완료된 행동의 증거를 요구하므로, 시뮬레이터는 행동이 실제로 확인될 때까지 통화를 유지합니다. 그 결과, 사용자는 즉흥적으로 행동하는 존재가 아니라 일관되고 현실적인 발신자처럼 동작하게 됩니다.

초기 시나리오 데이터베이스 (Initial scenario database). 에이전트가 시나리오 동안 쿼리(query)하고 수정할 백엔드 상태입니다. 예약 ID, 계정 상세 정보, 인증 자격 증명(authentication credentials)과 같이 사용자 목표(user goal)에서 참조되는 모든 엔티티가 데이터베이스에 존재하고 일관성을 유지하도록 사용자 목표와 함께 공동 생성됩니다.

예상되는 최종 데이터베이스 상태 (Expected final database state, ground truth). 에이전트 지침(agent instructions), 사용자 목표, 초기 시나리오 데이터베이스에 대해 생성 LLM (generation LLM)을 실행하여 전체 액션 트레이스(action trace)를 생성함으로써 예상되는 결과를 도출합니다. LLM이 쓰기 도구 호출(write tool calls)을 실행함에 따라 데이터베이스는 점진적으로 업데이트되며, 결과적으로 나타나는 최종 상태(terminal state)가 평가 중 검증기(verifiers)가 대조 확인하는 정답(ground truth)이 됩니다.

이 세 가지 구성 요소는 서로 깊게 상호 의존적이기 때문에 공동 생성(Joint generation)이 필수적입니다. 독립적인 생성은 사용자 목표에는 참조되어 있지만 시나리오 데이터베이스에는 존재하지 않는 케이스 ID와 같은 잠재적인 불일치(silent inconsistencies)를 유발할 수 있으며, 이는 평가 신호를 완전히 오염시킬 수 있습니다. 일관성을 강제하기 위해, 각 생성 시도 후에 다단계 검증 루프(multi-stage validation loop)를 실행하며, 실패가 발생하면 모든 검사 통과 시까지 재시도하도록 생성 단계로 피드백을 전달합니다. 검증은 다음 세 단계로 진행됩니다.

• 구조적 검사 (A structural check)는 Pydantic 스키마(schema)를 기준으로 시나리오 데이터베이스를 검증하여 타입 오류(type errors)와 누락된 필드를 잡아냅니다.
• LLM 기반 검증기 (LLM-based validator)는 시나리오 전반의 일관성을 더 총체적으로 확인합니다. 즉, 목표에 명시된 사용자 대상 상세 정보가 데이터베이스 기록과 일치하는지, 상호 참조(cross-references)가 내부적으로 유효한지, 인증 데이터가 올바르게 구성되었는지 등을 확인합니다.
• LLM 기반 트레이스 검증 단계 (LLM-based trace verification pass)는 전체 대화 트레이스(conversation trace)를 정책 준수 여부, 올바른 액션 순서, 모든 필수 최종 액션의 완료 여부, 그리고 비결정론(non-determinism)을 유발할 수 있는 대안적인 쓰기 경로의 부재 여부에 대해 검사합니다.

SyGra 생성 이후, 모든 시나리오는 여러 차운의 수동 검토(manual review)를 거쳤습니다. 검토자들은 다음 사항을 확인했습니다: (1) 도메인 내 시나리오 전반에 걸쳐 정책(policies)이 일관되게 적용되었는지, (2) 사용자 목표(user goals)가 단 하나의 정확한 해결책만을 허용할 만큼 충분히 구체적인지, (3) 기대되는 최종 상태(expected final states)가 사용자 목표 및 초기 데이터베이스(initial database)와 내부적으로 일치하는지, (4) 적대적 시나리오(adversarial scenarios)가 명확하게 식별 가능한 정책 위반을 포함하여 올바르게 지정되었는지 여부입니다. 모호하거나 일관되지 않은 기록은 수정되거나 폐기되었습니다.

최종 점검 단계로, 우리는 오디오 파이프라인(audio pipeline)을 우회하고 대화 전사본(conversation transcripts)을 직접 제공하는 방식으로 각 시나리오의 텍스트 전용 버전에 대해 세 가지 프런티어 모델(frontier models)인 OpenAI GPT-5.4, Google Gemini 3.1 Pro, Anthropic Claude Opus 4.6을 실행했습니다. 어떤 모델이라도 작업 완료(task completion) 점수가 0점을 기록한 모든 시나리오에 대해, 우리는 해당 실패가 실제 모델의 오류인지 아니면 데이터셋의 문제(모호한 정책, 불충분하게 지정된 사용자 목표, 도구 실행기(tool executor)의 버그, 또는 초기 상태와 기대되는 데이터베이스 상태 간의 불일치)인지를 수동으로 조사했습니다. 데이터셋 문제가 확인된 기록은 수정되거나 제거되었습니다. 선택된 모든 샘플은 최소 하나 이상의 프런티어 모델로 해결 가능했습니다.

우리는 음성 에이전트(voice agents)의 서로 다른 난이도 축을 겨냥하여 선정된 세 가지 기업 도메인 데이터셋을 생성했습니다. 세 가지 모두 음성을 통한 구조화된 고유 명사(named entities)(예: 확인 코드 및 직원 식별자)의 정확한 전사(transcription)를 요구하지만, 주요 도전 과제와 도구의 수는 서로 다릅니다.

아래에서는 우리의 두 가지 새로운 데이터셋인 Enterprise ITSM 및 Healthcare HRSD에 대해 심층적으로 살펴봅니다.

영어 전용 평가는 음성 에이전트가 다른 언어에서 실제로 어떻게 작동할지에 대해 제한적인 통찰만을 제공합니다. 음성 인식 정확도(Speech recognition accuracy), 전사 충실도(Transcription fidelity), 대화 유창성(Conversational fluency)은 각각 언어별로 저하될 수 있으며, 이는 영어에서 성능이 뛰어난 음성 에이전트가 다른 언어 환경에 배포되었을 때 완전히 실패할 수 있음을 의미합니다. 실무자들에게 다국어 배포에 대한 실질적인 통찰을 제공하기 위해, 우리는 더 많은 언어에 대한 지원을 추가하고 있으며, 단순히 대화 언어뿐만 아니라 각 대상 언어와 문화에 맞춰 평가 파이프라인을 조정하고 있습니다:

• 시나리오에서 참조되는 장소의 이름
• 사용자의 이름 및 이메일 주소
• 현지화된 전화번호

영어 시나리오	프랑스어 시나리오
발화: "Hi, I'm locked out and need help getting back into my account."	발화: "Bonjour, mon compte est bloqué et j’ai besoin d’aide pour y accéder à nouveau."
...

이를 통해 사용자 시뮬레이터(User simulator)는 선택한 언어로 실제와 같은 경험을 제공할 수 있습니다. 데이터셋을 넘어, 우리는 언어 전반에 걸쳐 신뢰할 수 있는 평가를 구축하기 위해 메트릭(Metrics)과 심판(Judges) 또한 업데이트하고 있습니다.

EVA-Bench는 MIT 라이선스 하에 완전한 오픈 소스로 제공됩니다. 데이터셋, 평가 프레임워크, 리더보드(Leaderboard)는 모두 공개되어 있습니다. HuggingFace 데이터셋 페이지에서 데이터셋을 다운로드하고 개별 레코드를 탐색할 수 있습니다. Hugging Face의 datasets 라이브러리를 사용하여 직접 로드할 수 있습니다:

from datasets import load_dataset
# Airline Customer Service Management (CSM) — 50 scenarios
airline = load_dataset("ServiceNow-AI/eva-bench", "airline", split="test")
...

각 레코드에는 구조화된 사용자 목표(User goal), 초기 시나리오 데이터베이스, 그리고 정답(Ground truth)인 최종 예상 데이터베이스 상태가 포함되어 있습니다. 이는 완전한 봇 대 봇(Bot-to-bot) 평가를 실행하는 데 필요한 모든 것입니다. 설정 지침, 코드 및 기여 가이드는 GitHub 저장소를 참조하십시오.

EVA-Bench: 음성 에이전트 평가를 위한 새로운 End-to-end 프레임워크