ПостЧи готовий агент чергувати замість тебе?

Чи готовий агент чергувати замість тебе? Продовжуємо гілку цікавих досліджень Чергування - це коли серед ночі тебе будить алерт, продакшн лежить, і треба шивдко зрозуміти, що саме зламалось і чому. Робота напряжна, виснажлива, давно хочеться віддати її агенту. Отже вирішили це перевірити - подивитись як таку задачу будуть вирішувати топові моделі 🔬 Як перевіряли Тестове оточення майже як продакшн - повноцінна архітектура з 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