[Paper] LLM은 Agentic 시나리오에서 어떻게 실패하는가? 다양한 LLM의 성공 및 실패 시나리오에 대한 정성적 분석 (Agentic 시뮬레이션)

Source: arXiv - 2512.07497v1

개요

논문 How Do LLMs Fail In Agentic Scenarios? 은 대형 언어 모델(LLM)이 자율적으로 행동하도록 요구받을 때—예를 들어 “파일을 읽고, SQL 쿼리를 실행하거나 스프레드시트를 스스로 조작하는 AI 어시스턴트”—왜 실패하는지를 상세히 분석합니다. 900개의 실행 트레이스를 세 가지 인기 모델에 걸쳐 조사함으로써, 부드럽고 신뢰할 수 있는 AI 에이전트와 스스로의 지시를 계속해서 어기는 에이전트를 구분하는 숨은 패턴을 밝혀냅니다.

주요 기여

• Kamiwaza Agentic Merit Index (KAMI) v0.1 도입: 최종 점수만이 아니라 단계별 트레이스를 기록해 세밀한 실패 분석을 가능하게 하는 벤치마크.
• 세 가지 대표 LLM(Granite 4 Small, Llama 4 Maverick, DeepSeek V3.1)를 네 가지 현실적인 도구 사용 작업(파일 시스템 탐색, 텍스트 추출, CSV 분석, SQL 쿼리)에서 비교.
• 모델 크기나 아키텍처와 무관하게 나타나는 네 가지 반복적인 실패 유형 식별.
• 규모만으로는 충분하지 않음을 입증: 400 B 파라미터 모델이 불확실성 기반 작업에서 32 B 파라미터 모델보다 약간만 앞설 뿐이며, 강화학습(RL) 파인튜닝이 DeepSeek의 신뢰성을 크게 향상시킴.
• 향후 에이전시 벤치마크를 위한 구체적인 평가 차원(인터랙티브 그라운딩, 복구 행동, 환경 인식 적응) 제안.

방법론

1. 벤치마크 설계 (KAMI v0.1) – 저자들은 여러 도구 호출이 필요한 “에이전시” 작업을 시뮬레이션하는 스위트를 구축했습니다(예: 파일 열기 → 내용 파싱 → 결과를 SQL 쿼리에 전달). 각 시도는 모델의 모든 결정, 도구 호출, 응답을 기록합니다.
2. 모델 선정 – 규모와 학습 방식이 다양한 세 가지 오픈소스 LLM을 선택:
   • Granite 4 Small (≈32 B 파라미터)
   • Llama 4 Maverick (≈400 B 파라미터)
   • DeepSeek V3.1 (≈70 B 파라미터, RL‑파인튜닝)
3. 작업 시나리오 – 네 가지 도메인을 포함:
   • 파일 시스템 – 파일 찾기, 읽기, 수정.
   • 텍스트 추출 – 비구조화 문서에서 특정 조각 추출.
   • CSV 분석 – 집계 계산, 행 필터링, 테이블 조인.
   • SQL – 모의 데이터베이스에 대한 쿼리 생성 및 실행.
4. 트레이스 분석 – 단일 정확도 수치 대신, 저자들은 각 트레이스를 수동으로 검사하고 성공·실패를 행동 패턴별로 분류했습니다.
5. 실패 유형 코딩 – 사전에 정의된 네 가지 실패 유형을 기반으로, 새로운 패턴이 나타날 때마다 반복적으로 정제했습니다.

결과 및 발견

*성공 = 허용된 도구 호출 수 내에 작업을 완료하고 올바른 최종 답변을 도출한 경우.

발견된 네 가지 실패 유형

1. 그라운딩 없이 조기 행동 – 모델이 필요한 컨텍스트를 확인하기 전에 도구 호출을 수행함(예: 테이블 이름 존재 여부를 확인하지 않고 DB 쿼리 실행).
2. 과도한 도움 – 에이전트가 대화를 유지하기 위해 누락된 엔터티를 창조함(예: 존재하지 않는 컬럼명 생성), 이로 인해 은밀한 논리 오류 발생.
3. 방해 요소에 의한 컨텍스트 오염 – 프롬프트나 이전 단계에 포함된 무관한 정보가 모델의 추론을 오염시켜 죽음의 골목으로 이끌음.
4. 부하 하에서의 취약한 실행 – 필요한 도구 호출 수가 일정 수준을 초과하면 모델 내부 상태가 악화되어 호출 누락이나 잘못된 명령이 발생.

요약하면, 모델 규모가 회복력을 보장하지 않음; DeepSeek의 RL 기반 사후 학습이 결정적인 우위를 제공했으며, 이는 에이전시 신뢰성을 위해서는 원시 파라미터 수보다 목표 지향 파인튜닝이 더 가치 있음을 시사합니다.

실용적 함의

• 기업용 AI 어시스턴트 – 내부 봇(예: 데이터 검색 또는 보고서 생성)을 구축하는 기업은 단순히 모델을 확대하기보다 강화학습 파인튜닝과 명시적인 검증 단계를 우선시해야 합니다.
• 도구 사용 SDK – SDK 설계자는 “가드레일”(예: SQL 호출 전 스키마 검증) 을 삽입해 조기 행동을 조기에 차단함으로써 첫 번째 실패 유형의 영향을 감소시킬 수 있습니다.
• 프롬프트 엔지니어링 – 관련 컨텍스트만을 격리하고 도구 호출 전 확인을 명시하도록 프롬프트를 구성하면 과도한 도움 및 방해 요소 오염을 완화할 수 있습니다.
• 모니터링 및 복구 – 배포 시 KAMI와 같이 전체 실행 트레이스를 기록하고, “부하 하에서의 취약한 실행” 패턴이 감지되면 자동 롤백 또는 재시도 메커니즘을 구현해야 합니다.
• 벤치마크 표준화 – 커뮤니티는 KAMI‑스타일의 트레이스‑레벨 평가를 채택해 숨은 버그를 사전에 발견하고 LLM‑기반 에이전트를 프로덕션에 내보내기 전에 검증할 수 있습니다.

제한점 및 향후 연구

• 합성 환경 – 벤치마크가 통제된 시뮬레이션에서 실행되므로, 실제 시스템에서는 네트워크 지연, 권한 오류, 더 풍부한 데이터 모달리티 등이 추가로 발생할 수 있습니다.
• 모델 다양성 – 세 모델만 조사했으며, 최신 오픈소스·클로즈드소스 LLM(예: GPT‑4o, Claude)으로 확장하면 식별된 유형이 일반화되는지 검증할 수 있습니다.
• 자동화된 실패 분류 – 현재 분석은 수동 트레이스 검토에 의존하므로, 향후 메타‑모델을 훈련시켜 네 가지 실패 유형을 대규모로 자동 플래그하는 방법을 연구할 수 있습니다.
• 사용자‑인‑루프 시나리오 – 완전 자율 에이전트를 가정했지만, 간헐적인 인간 피드백을 포함하면 추가적인 견고성 전략이 드러날 수 있습니다.

LLM이 얼마나 잘 수행하는지뿐 아니라 어떻게 실수하는지를 조명함으로써, 이 연구는 일상적인 개발자 워크플로와 기업 파이프라인에서 신뢰할 수 있는 AI 에이전트를 구축하기 위한 로드맵을 제시합니다.

저자

• JV Roig

논문 정보

• arXiv ID: 2512.07497v1
• 분류: cs.AI, cs.SE
• 발표일: 2025년 12월 8일
• PDF: Download PDF