When Agentic Executions Fail: Detecting and Localizing Runtime Faults from Telemetry
이 논문은 현재의 LLM 기반 방식들이 텔레메트리만으로는 다양한 운영 실패를 정확하게 탐지하고 국소화하는 데 어려움을 겪는다는 것을 입증하기 위해, 런타임 결함이 주입된 275개의 에이전트 실행 트레이스로 구성된 벤치마크 데이터셋인 AGENTCHAOSBENCH를 소개한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
현대적인 소프트웨어는 더 이상 컴퓨터에서 실행되는 단일 프로그램이 아닙니다. 그것은 종종 함께 협력하는 인공지능 에이전트들의 팀입니다. 한 에이전트는 여행을 계획하고, 다른 에이전트는 항공권을 예약하며, 세 번째 에이전트는 날씨를 확인하고, 이들이 서로 소통하며 지도나 달력 같은 외부 도구를 사용하는 디지털 워크포스를 상상해 보십시오. 이러한 시스템은 복잡한 연결망에 의존합니다. 에이전트들은 서로 대화하고, 거대 언어 모델에 조언을 구하며, 작업을 수행하기 위해 외부 도구를 호출하고, 해로운 말이나 행동을 하지 않도록 엄격한 안전 규칙을 따릅니다. 모든 것이 제대로 작동할 때, 이 팀은 올바른 답을 만들어냅니다. 하지만 무언가 잘못되면, 최종 결과가 틀리거나 시스템이 단순히 작동을 멈춰버려 사용자에게 왜 그런 일이 발생했는지 아무런 단서도 남기지 못할 수도 있습니다. 문제는 결과만 봐서는 무엇이 문제인지 알 수 없다는 점입니다. 시스템이 잘못된 결정을 내렸기 때문인지, 필요한 도구가 느렸기 때문인지, 아니면 안전 점검이 실수로 누락되었기 때문인지 알 수 없습니다. 이를 해결하기 위해 엔지니어들은 목적지가 아닌 전체 여정을 볼 수 있어야 합니다.
토론토 대학교의 연구진은 이 미스터리를 해결하는 데 도움을 줄 새로운 테스트 환경을 구축했습니다. 그들은 AgentChaosBench라는 벤치마크를 만들었는데, 이는 본질적으로 진단 도구가 문제를 찾아낼 수 있는지 확인하기 위해 의도적으로 이러한 AI 팀을 고장 내는 통제된 환경입니다. 연구진은 SQL 코드를 작성하고, 책 초안을 잡고, 소셜 미디어를 관리하며, 랜딩 페이지를 제작하고, 채용을 돕는 다섯 가지의 서로 다른 실제 응용 프로그램(시스템)을 가져와 열 가지의 서로 다른 실패 방식을 시뮬레이션했습니다. 이러한 실패에는 답변을 거부하는 도구, 응답이 너무 오래 걸리는 도구, 에이전트 사이에서 유실된 메시지, 그리고 우회된 안전 규칙 등이 포함되었습니다. 모든 고장 난 시나리오에 대해, 연구진은 동일한 시작 명령어를 사용하여 완벽하고 결함이 없는 버전의 동일한 작업도 실행했습니다. 이러한 쌍을 만듦으로써 그들은 정확히 무엇이 어디서 잘못되었는지 알 수 있었으며, 이를 통해 275개의 상세한 디지털 여정 기록을 생성했습니다.
그들 연구의 핵심은 자동화된 시스템이 실패한 실행 기록을 보고 원인을 올바르게 식-별할 수 있는지 확인하는 것이었습니다. 연구진은 정답을 알려줄 수 있는 어떤 라벨도 제거하여, 호출 타이밍, 메시지 내용, 각 단계의 상태와 같은 가공되지 않은 데이터만을 남겼습니다. 그런 다음 소규모 로컬 모델부터 가장 강력한 최첨단 모델에 이르기까지 다양한 인공지능 모델들에게 탐정 역할을 맡겼습니다. 이 모델들은 기록을 읽고, 어떤 유형의 결함이 발생했는지 파악하며, 시스템의 어느 부분이 책임이 있는지를 정확히 짚어내야 했습니다. 또한 연구진은 탐정에게 비교를 위한 완벽하고 결함 없는 실행본을 제공하는 것이 도움이 되는지도 테스트했습니다.
결과는 이 작업이 예상보다 훨씬 더 어렵다는 것을 보여주었습니다. 시를 쓰고 복잡한 논리 퍼즐을 풀 수 있는 가장 발전된 모델들조차 이러한 런타임 결함을 진단하는 데 상당한 어려움을 겪었습니다. 단일 기록을 보고 결함 유형을 식로는 식별하라는 요청을 받았을 때, 가장 뛰어난 모델조차 정답률이 25% 미만이었습니다. 작은 모델들의 경우 성공률은 더 낮았으며, 약 13~19% 수준으로 무작위 추측과 거의 차이가 없었습니다. 문제가 된 특정 구성 요소를 지목해야 할 때는 더욱 어려웠습니다. 모델들이 시스템의 올바른 부분을 찾아낸 경우는 약 31%에 불과했습니다. 결함 유형을 이름 붙이고 위치를 찾는 일을 동시에 수행하도록 요청했을 때, 가장 좋은 모델의 성공률은 단 25%로 떨어졌습니다.
연구는 일부 실패가 다른 실패보다 더 쉽게 포착된다는 것을 보여주었습니다. 명확한 오류 메시지를 반환하는 도구나 연결 시간 초과와 같이 뚜렷한 신호를 생성하는 오류는 더 자주 식별되었습니다. 그러나 가장 위험하고 미묘한 실패들은 거의 보이지 않는 상태로 남았습니다. 요청을 차단해야 할 상황에서 안전 규칙이 우회되어 요청이 진행된 경우, 모델들은 이를 알아차리는 데 거의 항상 실패했습니다. 마찬가지로, 도구의 응답이 손상되거나 시스템의 메모리 공간이 부족해진 경우에도 모델들은 이러한 문제를 정상적인 동작과 신뢰성 있게 구분하지 못했습니다. 연구진은 완벽한 참조 실행본을 비교 대상으로 제공하는 것이 도구가 비정상적으로 느리거나 시스템이 메모리를 너무 많이 사용하려고 하는 경우와 같은 사례에서는 도움이 된다는 것을 발견했습니다. 그러나 이러한 비교는 안전 우회나 데이터 손상 문제에는 도움이 되지 않았는데, 이는 손상된 출력물이 여전히 그럴듯해 보였고 안전 점검 역시 통과된 것처럼 보였기 때문입니다.
이 연구는 우리가 여러 AI 에이전트를 조정하는 정교한 시스템을 구축했지만, 그것들이 왜 실패하는지를 신뢰성 있게 이해할 수 있는 도구는 아직 구축하지 못했음을 입증합니다. 현재 세대의 진단 모델들은, 가장 크고 유능한 모델이라 할지라도, 고장 난 도구와 느린 네트워크, 건너뛴 안전 점검, 그리고 정상적인 작동 사이의 차이를 일관되게 구별할 수 없습니다. 연구진은 이러한 시스템을 고치는 데 있어 단순히 거대 언어 모델에게 로그를 읽게 하는 것을 넘어서는 새로운 방법이 필요하다고 결론지었습니다. 그들은 미래의 솔루션이 단순히 일반적인 지능에 의존하기보다는, 현재의 실행을 알려진 양호한 실행과 비교하거나 이러한 운영상의 결함을 찾기 위해 특별히 설계된 전문 도구에 의존해야 할 수도 있다고 제안합니다. 앞으로 나아가는 길은 디지털 기계 내부의 보이지 않는 균열이 전체 시스템을 붕괴시키기 전에 이를 볼 수 있는 더 나은 방법을 구축하는 데 있습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.