Продовжуємо гілку цікавих досліджень
Чергування - це коли серед ночі тебе будить алерт, продакшн лежить, і треба шивдко зрозуміти, що саме зламалось і чому. Робота напряжна, виснажлива, давно хочеться віддати її агенту. Отже вирішили це перевірити - подивитись як таку задачу будуть вирішувати топові моделі
🔬 Як перевіряли
Тестове оточення майже як продакшн - повноцінна архітектура з 19 мікросервісів з метриками, логами, трейсами (Prometheus, Jaeger, OpenSearch через Grafana) і повним доступом до коду. Баги теж докинули цілком реальні: на основі feature flags, які вмикають за розкладом, тож збої виглядають як природні
Складність кожної задачі вимірювали так:
• наскільки конкретний звіт користувача - Easy, Medium чи Hard (рівні складності самих задач)
• скільки часу минуло до виявлення - від 15 хвилин до 24 годин
• скільки поломок співпало одночасно - 5 сценаріїв: ізольована / незалежні / конфліктні / каскадні / послідовні
📊 Що саме міряли
RCA тут - це root cause analysis, пошук причини поломки, міряли три штуки:
• RCA Accuracy - чи назвав агент УСІ справжні причини
• RCA Depth - наскільки глибоко докопався, шкала від 0 до 3
• Hallucination Rate - як часто вигадав причину, якої взагалі не було
Еталонні відповіді складали і затверджували самі SRE (інженери що відповідають за надійність софта). Оцінки спершу виставляв LLM-суддя, потім люди переоцінили вручну і майже повністю з ним зійшлися
🎯 Що вийшло
Найкращий агент знаходить справжню причину приблизно в одному випадку з чотирьох на середніх інцидентах і в одному з десяти на важких. І це топова модель, найкраща з тестованих (Opus 4.7, Sonnet 4.6, GPT-5.5, GLM-5, DeepSeek-V4-Pro)
А найслабша модель (DeepSeek-V4-Pro) у 40% звітів впевнено вигадувала причину, якої в системі взагалі нема.
❗️ Чому Hard такий важкий
Один і той самий інцидент переписали в три версії, просто ВИДАЛЯЮЧИ слова. На Hard агент бачить лише «users are reporting site issues», і все. Через таку розмитість на кожен інцидент стає більше причин, які треба перебрати.
Також окремий парадокс з кодом. Якщо забрати у агента доступ до коду, то результати сильно погіршуються, отже телеметрії недостатньо, треба лізти в код і читати. Але сам Opus на читання коду витрачає лише 16% своїх дій, а на телеметрію - 72%
Автори попереджають, що навіть ці цифри оптимістичні:
Every dimension along which ORCA-bench simplifies real production points in the same direction: real oncall is harder.
Висновок
Зазвичай всі дивляться на SWE-bench, котрий показує, що агент вміє полагодити вже знайдений баг. Але oncall - це коли ще ніхто не знає, що зламалось, дані розкидані, і падає кілька речей одразу. Поки що тут тупить будь-яка модель. Тож якщо мрієш віддати агенту нічні чергування - мрій :)
Але напрямок правильний, і бенчмарк нарешті міряє те, що дійсно болить
Youtube | Instagram