Дослідники оприлюднили на arXiv у серпні 2026 року бенчмарк TraceBench — перший контрольований тест на те, чи здатні LLM-агенти самостійно знаходити першопричину аномалії у часовому ряді, наприклад раптовий стрибок затримки чи падіння success rate у моніторингу продакшн-системи. За даними arXiv, бенчмарк заповнює прогалину: досі не існувало стандартизованого способу порівняти, наскільки добре різні агенти справляються саме з розслідуванням інцидентів, а не лише з генерацією коду чи відповідями на запитання.
Задача звучить просто, але для агента вона нетривіальна: отримати граф метрик з аномалією, послідовно висувати гіпотези, перевіряти їх за додатковими даними (кореляції з іншими рядами, логами, релізами) і врешті назвати конкретну причину — а не просто описати симптом. Саме цей крок від «щось зламалось» до «зламалось через X» досі важко оцінити автоматично, бо правильних відповідей може бути кілька, а якість гіпотези важлива не менше за фінальний вердикт. У реальному моніторингу кожна хвилина, витрачена на хибну гіпотезу, продовжує простій сервісу, тож саме якість причинного ланцюжка — а не швидкість відповіді — визначає цінність такого агента.
Для команд, які будують AI-агентів для DevOps та SRE, це перший інструмент, що дозволяє виміряти прогрес не на слово, а на контрольованому наборі задач.
Що саме перевіряє TraceBench?
TraceBench ставить агента в позицію чергового інженера: перед ним часовий ряд з аномалією і доступ до додаткових сигналів, а завдання — визначити першопричину (root cause analysis, RCA), а не просто позначити ділянку графіка як «аномальну». RCA у моніторингу — це процес встановлення конкретної події чи компонента, що спричинили відхилення метрики від норми, на відміну від виявлення аномалій (anomaly detection), яке лише сигналізує про сам факт відхилення.
- Вхідні дані — синтетичні й реальні часові ряди з розміченою першопричиною
- Агент діє ітеративно: висуває гіпотезу, запитує додаткові дані, коригує висновок
- Оцінка контрольована — результат порівнюється з еталонною причиною, а не з довільним текстовим поясненням
Чому цю прогалину досі не закривали?
Більшість наявних бенчмарків для агентів перевіряють кодування, використання інструментів або відповіді на факти, але не специфічно розслідування інцидентів у часових рядах. SRE-задача вимагає одночасно розуміння числових патернів і покрокового причинного міркування, тому оцінка «зробив агент правильний висновок» довго лишалась не формалізованою — команди або тестували агентів на власних внутрішніх інцидентах, або взагалі не мали способу порівняти рішення між собою. Наслідок — команди платять за це підвищеним mean time to resolution (MTTR), коли покладаються на агента, що впевнено називає неправильну причину.
Кому це знадобиться на практиці?
Насамперед — командам, які вже будують або планують агентів для автоматичного розслідування інцидентів (incident response, on-call automation) поверх моніторингових систем на кшталт Prometheus, Datadog чи внутрішніх дашбордів. TraceBench дає їм відтворюваний орієнтир: замість «агент виглядає розумним у демо» — конкретний бал на стандартизованому наборі задач з RCA. Це стосується і постачальників observability-платформ, які вже вбудовують агентні функції розслідування у свої продукти й потребують об'єктивного способу довести, що ці функції справді працюють.
Це узгоджується з ширшим трендом на прикладні агентні навантаження в продакшн-операціях — наприклад, Uber уже фіксує зростання агентних запитів у 9,4 раза без пропорційного зростання бюджету, і саме такі задачі, як розслідування інцидентів, — природний наступний кандидат на автоматизацію.
Висновок AiiN
Наша теза: поява предметно-специфічних бенчмарків на кшталт TraceBench — ознака того, що ринок агентів переходить від загальних «universal assistant» тестів до вузьких, професійно орієнтованих оцінок, і саме вони, а не загальні лідерборди, визначатимуть, яких агентів команди реально впровадять у продакшн-DevOps. Якщо ви будуєте або оцінюєте агента для інцидент-менеджменту, TraceBench — розумна відправна точка для регресійного тестування якості RCA, а не лише latency чи uptime самого агента.
Що таке root cause analysis (RCA) у контексті AI-агентів?
RCA — це процес встановлення конкретної причини аномалії чи збою, на відміну від простого виявлення факту відхилення метрики. Для AI-агента це означає не лише розпізнати графік як «ненормальний», а пройти ланцюжок гіпотез і підтвердити ту, що реально пояснює причину.
Чим TraceBench відрізняється від звичайних бенчмарків для агентів?
Він сфокусований вузько на одній задачі — розслідуванні аномалій у часових рядах — і оцінює саме процес та фінальну причину, а не загальні навички кодування чи діалогу, які перевіряють більшість універсальних агентних бенчмарків.