핵심 요약
기존의 LLM 에이전트 평가는 대화의 처음부터 끝까지 반복해서 실행하는 방식이라 비용이 많이 들고 희귀한 오류 상황을 발견하기 어렵다. 이 논문은 대화의 중간 지점에서 여러 갈래로 분기하는 트리 구조 평가 방식을 도입하여, 중복 계산을 줄이면서도 에이전트의 취약점을 더 효과적으로 찾아낸다.
왜 중요한가
기존의 LLM 에이전트 평가는 대화의 처음부터 끝까지 반복해서 실행하는 방식이라 비용이 많이 들고 희귀한 오류 상황을 발견하기 어렵다. 이 논문은 대화의 중간 지점에서 여러 갈래로 분기하는 트리 구조 평가 방식을 도입하여, 중복 계산을 줄이면서도 에이전트의 취약점을 더 효과적으로 찾아낸다.
핵심 기여
DIVERT 프레임워크 제안
대화형 에이전트 평가를 위해 선형적인 롤아웃 대신 스냅샷 기반의 분기 구조를 사용하는 DIVERT 프레임워크를 개발했다. 이를 통해 동일한 대화 접두사를 재사용하여 토큰 비용을 절감하고 평가 효율성을 높였다.
LLM 기반 Junction Chooser 도입
대화 궤적 내에서 에이전트의 행동 변화를 유도할 가능성이 가장 높은 임계 지점인 '분기점(Junction)'을 식별하기 위해 LLM 기반의 선택 메커니즘을 설계했다.
다양성 유도형 사용자 응답 생성
동일한 의도를 유지하면서도 의미적으로는 원본과 가장 상이한 사용자 응답을 생성하고 선택하는 기법을 통해 에이전트가 경험하지 못한 새로운 대화 경로를 탐색하도록 유도했다.
토큰 효율성 및 오류 발견 성능 입증
실험 결과, 동일한 토큰 예산 내에서 표준 방식보다 더 많은 고유 작업 실패 사례를 발견했으며, 에이전트 토큰 사용량을 약 19.6% 절감하는 성과를 거두었다.
핵심 아이디어 이해하기
기존의 에이전트 평가는 Monte Carlo Rollout 방식을 사용하여 매번 대화의 처음(Root)부터 끝까지 독립적으로 실행한다. 이는 마치 게임을 테스트할 때마다 오프닝 영상을 계속 다시 보는 것과 같아서, 초반의 로그인이나 단순 질의응답 과정에서 불필요한 연산 비용이 반복적으로 발생한다.
DIVERT는 대화의 상태를 저장하는 Snapshot 기능을 활용하여 이 문제를 해결한다. 대화의 특정 시점에서 에이전트의 내부 상태, 환경 변수, 대화 기록을 모두 저장해두었다가, 필요할 때 해당 지점부터 즉시 재개한다. 이는 Transformer 아키텍처에서 이전 토큰들의 연산 결과인 KV Cache를 재사용하는 원리와 유사하게 작동하여 중복 계산을 원천적으로 차단한다.
또한, 단순히 대화를 재개하는 것에 그치지 않고 '분기' 개념을 도입한다. Embedding 공간에서 원본 응답과 코사인 유사도가 가장 낮은 응답을 선택하여 에이전트를 새로운 상황에 노출시킨다. 결과적으로 선형적인 대화 구조를 트리 구조로 확장함으로써, 적은 비용으로도 에이전트가 대응하기 어려워하는 희귀한 실패 사례(Edge Cases)를 더 넓게 탐색할 수 있게 된다.
방법론
DIVERT 파이프라인은 초기 롤아웃 및 상태 캐싱, 분기점 선택, 다양성 유도 응답 생성, 스냅샷 기반 재실행의 4단계로 구성된다. 먼저 표준 시뮬레이션을 수행하며 각 단계의 전체 에이전트-환경 상태를 스냅샷으로 저장한다.
분기점 선택(Junction Selection) 단계에서는 LLM 기반의 Junction Chooser가 전체 대화 궤적 T를 입력받아 에이전트 행동 변화 ∆(Agent Behavior)를 최대화할 수 있는 사용자 턴 인덱스 i를 식별한다. [대화 텍스트와 도구 호출 기록 입력 → LLM의 카운터팩추얼 추론 수행 → 최적의 분기 지점 인덱스 출력 → 해당 지점에서 실험 재개 결정]
다양성 유도 응답 생성 단계에서는 선택된 지점에서 K개의 후보 응답을 생성한 후, sentence-transformers 모델인 all-MiniLM-L6-v2를 사용하여 원본 응답과의 유사도를 계산한다. [후보 응답 u_k와 원본 u_i를 임베딩 모델에 입력 → 코사인 유사도 연산 수행 → 가장 낮은 유사도 점수를 가진 후보 선택 → 의미적으로 가장 먼 대조군 생성]
마지막으로 저장된 state.pkl 파일을 로드하여 오케스트레이터 속성과 환경 도구 메모리를 동기화한 뒤, 선택된 변형 응답을 주입하여 대화를 이어간다. 이 과정에서 이전 턴들의 토큰을 다시 생성할 필요가 없으므로 토큰 소모량이 크게 줄어든다.
관련 Figure

왼쪽의 표준 방식은 매번 처음부터 대화를 시작해 중복 계산이 발생하지만, 오른쪽의 DIVERT는 중간 지점(Junction)에서 스냅샷을 찍고 여러 갈래로 나누어 탐색함으로써 효율성을 높이는 구조를 보여준다. 특히 다양성 가이드 응답 생성을 통해 에이전트의 실패 사례를 더 잘 찾아냄을 시각화했다.
표준 롤아웃 평가 방식과 DIVERT의 분기 기반 평가 방식을 비교한 다이어그램이다.
주요 결과
τ-bench(Airline, Retail, Telecom) 벤치마크 실험 결과, DIVERT는 모든 도메인에서 표준 선형 롤아웃보다 높은 효율성을 보였다. GPT-OSS-120B 모델 기준, 100K 토큰당 발견된 오류 수(Err/100K)가 기존 13.6에서 DIVERT 적용 시 16.2로 향상되었다.
실패 사례 커버리지 측면에서도 우수한 성능을 보였다. 동일한 수의 전체 궤적을 생성했을 때, DIVERT는 표준 방식보다 더 많은 고유 작업(Unique Tasks)에서 에이전트의 결함을 찾아냈다. 특히 분기 수를 늘릴수록 커버리지가 단조 증가하는 경향을 보여, 단순 반복보다 지능적인 분기가 에이전트의 취약점 노출에 효과적임을 입증했다.
비용 분석 결과, 에이전트 토큰 사용량은 19.6%, 사용자 및 프레임워크 토큰은 평균 563.56개 감소했다. 분기점 선택과 응답 생성에 드는 추가 오버헤드는 전체 평가 비용의 0.2% 미만으로 매우 미미한 수준으로 나타났다.
관련 Figure

분기(Split) 수가 많아질수록 동일한 토큰 비용에서 더 많은 실패 사례를 빠르게 발견하며, 그래프의 기울기가 더 가파르게 상승하는 것을 확인할 수 있다. 이는 DIVERT가 단순 반복보다 훨씬 효율적으로 에이전트의 약점을 찾아낸다는 실험적 근거가 된다.
Airline 도메인에서 토큰 비용 대비 발견된 고유 작업 실패 수를 나타낸 그래프이다.
기술 상세
DIVERT는 에이전트 궤적의 트리 구조적 특성을 활용한다. 상태 직렬화(Serialization)를 위해 state.pkl(전체 오케스트레이터 상태)과 metadata.json(계층적 분기 추적용) 파일을 생성하며, 이를 통해 도구 호출의 부수 효과(Side Effects)와 환경 변화를 완벽하게 복원한다.
분기 전략은 '의도 보존(Intent Preservation)'과 '다양성 극대화' 사이의 균형을 맞춘다. LLM-as-a-judge를 통한 사후 분석 결과, DIVERT가 생성한 변형 응답의 의도 누락률(25.27%)이 원본 시뮬레이터(28.12%)보다 낮게 나타나, 단순히 무작위적인 변화가 아닌 목표 지향적인 변형임을 확인했다.
구현 측면에서는 vLLM과 같은 추론 엔진의 KV Cache 재사용 구조와 결합될 때 최적의 성능을 발휘할 수 있도록 설계되었다. 논문은 공유 접두사(Shared Prefix) 비율이 기존 0.5% 수준에서 DIVERT 적용 시 최대 58.35%까지 증가함을 수치로 제시하여 시스템 레벨의 최적화 가능성을 시사한다.
한계점
현재 DIVERT는 사용자 응답의 텍스트 변형에 집중하고 있으며, 도구 출력이나 환경 역학(Environment Dynamics) 자체를 직접적으로 변형하여 분기하는 기능은 향후 과제로 남겨두고 있다. 또한 유사도 계산에 사용된 코사인 유사도 외에 퍼플렉시티(Perplexity) 등 다른 지표의 활용 가능성에 대한 추가 연구가 필요하다.
실무 활용
LLM 에이전트의 신뢰성을 검증해야 하는 기업이나 연구소에서 평가 비용을 획기적으로 줄이면서도 검증의 깊이를 더하는 데 즉시 활용 가능하다.
- 고객 서비스용 AI 챗봇의 정책 준수 여부 및 예외 상황 대응 능력 자동 테스트
- 복잡한 API 호출을 수행하는 에이전트의 도구 사용 안정성 대규모 벤치마킹
- 에이전트 업데이트 시 이전 버전과의 성능 비교 및 회귀 테스트 비용 최적화
코드 공개 여부: 공개
코드 저장소 보기키워드
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.