Агентний ШІ зазвичай не створює резервну копію перед дією

Багато матеріалів, які я щодня переглядаю на Arxiv та в інших джерелах, доволі сухі навіть на смак зануди; тому я завжди шукаю публікації, що викликають у мене емоційний відгук — як у користувача, прихильника чи жертви ШІ.

Сьогодні мене аж пересмикнуло від нової академічної співпраці дослідників зі США: вони вивчали, наскільки агентні моделі ШІ передового рівня спалюють за собою мости, перш ніж завдати шкоди, — і роблять це швидше, ніж ви встигнете набрати «СТОП!» (підказка: тримайте це напоготові в буфері обміну).

Таке нещодавно трапилося і зі мною, якщо вирвати цей епізод із контексту нової статті: ChatGPT сліпо дотримався інструкцій, а мені навіть на думку не спало спершу створити копію всього віртуального середовища:

За мотивами нової статті — момент, від якого холоне всередині й який переживали багато хто з нас, установлюючи новітні фреймворки або навіть популярні дистрибутиви, що не зважають на нестандартне середовище, у якому їм, можливо, доведеться працювати. Джерело

У цьому жахливому й надто знайомому прикладі в робота є слушне виправдання: зазвичай ніхто не перевіряє всі можливі наслідки встановлення нової бібліотеки в крихкому й невблаганному фреймворку. Однак у новій статті стверджується, що, можливо, перевіряти їх усе-таки варто. І я, людина, яка й досі часто натискає CTRL+S навіть у середовищах автозбереження, налаштованих ігнорувати цю комбінацію клавіш (дякую, психологічна травмо від втрати даних у 1990-х), мушу з цим погодитися.

Безперечно, обачніша й обережніша поведінка стала б у пригоді Алексею Григор’єву, засновнику освітньої платформи DataTalks.Club: у березні минулого року його агент Claude Code під час перенесення сервера видалив робочу інфраструктуру та резервні копії, унаслідок чого було втрачено дані сайту за два з половиною роки.

Серед інших недавніх випадків агентської безвідповідальності такого штибу — агент Cursor, який у квітні видалив робочу базу даних і резервні копії компанії PocketOS, що надає програмне забезпечення для оренди автомобілів, через що клієнти не могли бронювати авто понад два дні; а також поштовий агент OpenClaw, який у лютому видаляв повідомлення з папки «Вхідні» дослідника Meta AI, попри неодноразові вказівки зупинитися.

Незалежно від того, чи є вони агентними, моделям великих мовних моделей передового рівня дуже складно діяти розсудливо й обережно — настільки, що розв’язання цієї проблеми стало окремим напрямом досліджень.

Зробімо крок назад

Автори нової статті* розробили багатоагентний плагін для агентних середовищ виконання, який може працювати паралельно з гостьовим ШІ та змушувати його створювати резервні копії, коли це потрібно:

Огляд проблеми з резервним копіюванням, розглянутої в дослідженні, та запропонованого рішення. У 205 сценаріях шість моделей ШІ передового рівня створювали резервні копії критично важливого стану лише у 15,2% завдань. Натомість система дослідників BackUpper охопила всі критично важливі дії; середня схожість відновлених даних з оригіналом становила 92,2% (нижче пояснюється, чому досягти 100% складно).

Один із найразючіших висновків нового дослідження — те, наскільки часто моделі передового рівня не створюють резервних копій перед потенційно небезпечними діями. Дослідники виявили, що GPT-5.6-Terra створювала резервні копії критично важливих даних лише у 4,4% випадків; GPT-5.6-Sol — лише у 5,9% перевірених випадків; а Gemini 3.7-Flash — лише у 2,4% випадків.

Навіть найкраща модель, Claude Opus-5, не створювала резервних копій критично важливих даних більш ніж у третині перевірених випадків.

У статті сказано^†:

«У середньому агенти на шести моделях передового рівня виконують 86,1% завдань, але створюють резервну копію стану перед діями, про які згодом шкодують, лише у 15,2% випадків. GPT 5.6-Sol у Codex робить це лише у 5,9% завдань, а DeepSeek V4-Pro у Hermes — лише у 2,9%.

«Ці результати свідчать, що сучасні агенти мають обмежене розуміння потреби в резервному копіюванні й потребують спеціальних засобів підтримки резервного копіювання».

Розроблене авторами рішення під назвою BackUpper працює поруч з агентом як тіньовий процес у середовищі виконання: перевіряє, що той збирається зробити, і спершу створює резервну копію, якщо є ризик утратити щось корисне.

Для повсякденних операцій, як-от оновлення програмного забезпечення, система дотримується набору простих правил; у складніших ситуаціях вона залучає меншу модель ШІ, щоб визначити, що потрібно зберегти.

Під час тестування BackUpper охопив усі критично важливі дії, а відновлені дані на 92,2% відповідали оригіналу. Додаткові витрати становили $0.014 за завдання — у цьому контексті це небагато, але для передових великих мовних моделей, що обслуговують мільярди клієнтів, сума значна; можливо, саме тому ситуацію ймовірніше допоможе поліпшити зовнішній сервіс такого типу або вбудовування подібної функціональності в інструментарій, а не сподівання на виправлення від самих технологічних гігантів (які цілком можуть перекласти додаткові витрати на споживачів — через підвищення цін або інфляцію токенів).

За основу цього підходу взято RegretBench — тестовий набір із 205 завдань, створений на основі реальних випадків, коли люди втрачали дані, про збереження яких згодом шкодували. Він перевіряє, чи здатні агенти штучного інтелекту завчасно подбати про збереження цих даних, перш ніж вносити потенційно незворотні зміни. Випадки, що ввійшли до збірки, взято з онлайн-дискусій і звітів на таких платформах, як X.com, GitHub і Stack Overflow.

Схема перетворення реальних випадків на тестові сценарії в RegretBench. Кожен задокументований випадок відтворюють за допомогою дії, що спричинила втрату даних, реалістичного робочого середовища та послідовності інструкцій. У цьому прикладі оновлення ipykernel непомітно замінює наявну версію traitlets, тож агент може виконати завдання, але відновити початкову інсталяцію вже неможливо.

Хоча для тих, хто прагне досконалості, показник 92% може видатися невтішним, автори зазначають, що відновленню певних типів даних заважають технічні перешкоди:

«Розрив між відновленням ідеального стану та фактичним результатом зумовлений переважно двома причинами. Деякі поля, як-от ідентифікатори дописів, служби зазвичай генерують заново під час запису, і часто їх неможливо відтворити. Інші відмінності пов’язані з незначними метаданими, як-от позначками про прочитання електронних листів, які рідко трапляються у випадках втрати даних, про які шкодують».

У тестах після того, як шкода вже була завдана, вдалося відновити 33,8% подібності до початкового стану, тоді як без відновлення цей показник становив лише 14,3%.

У статті зазначено, що надалі обізнаність щодо резервного копіювання можна підвищити за допомогою навчання, а наступні версії BackUpper можна навчити пропускати дії з низьким рівнем ризику та поширити захист на агентів, які працюють із вебсайтами й комп’ютерами.

BackUpper підтримує Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness і OpenClaw; автори також відкрили доступ до коду програми та пов’язаного з нею набору даних (щоб отримати дозвіл на доступ до нього, потрібно заповнити форму); додаткову інформацію та дуже коротке й просте пояснювальне відео можна знайти на сайті проєкту.

Методика

Під час створення RegretBench навмисно виключили дані, уже захищені вбудованими системами резервного копіювання агентів, щоб перевірити, чи самі агенти розуміють, коли потрібно створювати резервну копію. Тестові сценарії підготували за допомогою Claude Opus-5 і GPT-5.6-Sol, а потім вручну перевірили, щоб переконатися, що вони працюють і точно відтворюють початкові випадки.

205 тестів RegretBench охоплюють п’ять сфер: операції в терміналі; бази даних; вебзастосунки; електронну пошту; і DevOps. Самі випадки походять переважно з платформ для розробки програмного забезпечення та підвищення продуктивності (44,4%); обговорень у соціальних мережах і спільнотах (39%); архівів і медіазвітів (16,6%):

Джерела реальних випадків, використаних у RegretBench, поділено на три категорії. 

Оцінили шість передових моделей: Claude Opus-5 і Claude Sonnet-5 у Claude Code; GPT-5.6-Sol і GPT-5.6-Terra у Codex; а також Gemini 3.7-Flash і DeepSeek V4-Pro у Hermes.

У всіх випадках використовували стандартні налаштування міркування, а автоматичний захист резервного копіювання обмежили знімками робочого простору — це давало змогу зарахувати будь-які інші резервні копії як результат власних рішень агентів.

Для оцінювання результатів залучили двох суддів на основі ШІ, обидва працювали на Claude Sonnet-5. Частку успішно виконаних завдань (PR) обчислювали як частку завдань, у яких було виконано кожен запит користувача. Під час оцінювання резервного копіювання кожну зміну поза робочим простором (OOW) перевіряли, щоб з’ясувати, чи було заздалегідь збережено достатньо інформації для відновлення.

Використовували такі показники резервного копіювання: Regret Moment Backup Rate (RMBR), що відображає конкретні дії, пов’язані із задокументованими випадками втрати даних; і частка резервного копіювання поза робочим простором (OWBR), що охоплює всі зміни за межами робочої директорії агента.

Оцінки системи оцінювання резервного копіювання також зіставили з людськими анотаціями; збіг становив 95,3%.

Результати

Щоб з’ясувати, чи була низька обізнаність щодо резервного копіювання зумовлена моделями ШІ або фреймворками, на яких вони працюють, Claude Opus-5, GPT-5.6-Sol і DeepSeek V4-Pro спочатку перевірили на 60 завданнях RegretBench у Claude Code, Codex і Hermes.

Частка завдань, у яких резервну копію критично важливих даних було створено, мало відрізнялася залежно від фреймворку, що вказує на те, що основною причиною були самі моделі. Також дослідили зв’язок між загальними можливостями ШІ та обізнаністю щодо резервного копіювання, використавши GPT-5.4, GPT-5.5 і GPT-5.6-Sol.

Попри послідовне вдосконалення загальних можливостей, відповідного зростання обізнаності щодо резервного копіювання не виявили:

Результати тестування шести моделей ШІ на RegretBench. Ліворуч: частка виконаних завдань у порівнянні з часткою критично важливих дій, резервні копії яких було створено заздалегідь; це свідчить про високий рівень успішності, але низьку обізнаність щодо резервного копіювання в більшості моделей. Праворуч: середня кількість викликів інструментів на завдання; операції резервного копіювання позначено синім. Claude Opus-5 показала найвищий рівень резервного копіювання, але на нього припало 8,9% викликів інструментів.

Також дослідили зв’язок між загальними можливостями ШІ та обізнаністю щодо резервного копіювання, використавши GPT-5.4, GPT-5.5 і GPT-5.6-Sol. Попри послідовне вдосконалення загальних можливостей, відповідного зростання обізнаності щодо резервного копіювання не виявили.

BackUpper

BackUpper використовує чотири рівні захисту, кожен із різними витратами ресурсів: рівень 1 замінює команди, що можуть призвести до втрати даних, на оборотні альтернативи, наприклад переміщення файлів до кошика; рівень 2 доповнює операції командами резервного копіювання, як-от збереженням версій пакетів перед оновленням; рівень 3 створює знімки файлів робочого простору, яких стосуються зміни; рівень 4 використовує субагента GPT-5.6-Luna, щоб визначати й зберігати дані, яких можуть торкнутися складніші операції.

Коли BackUpper було ввімкнено, усі дії, що змінювали стан, було охоплено в усіх шести моделях; без нього середній рівень резервного копіювання становив 15,2% для критично важливих дій і 17,4% для інших змін:

Охоплення резервним копіюванням і результати відновлення за допомогою BackUpper. Ліворуч: сині та помаранчеві стовпчики показують для кожної моделі рівень резервного копіювання критично важливих дій та інших змін поза робочим простором. Темно-зелені пунктирні контури позначають точність відновлення; світло-зелені крапкові контури показують 100% охоплення резервним копіюванням із BackUpper. Праворуч: порівнюється точність відновлення у п’яти категоріях інструментів із BackUpper (зелений); відновлення після цього за допомогою Claude Opus-5 (фіолетовий); і без відновлення (сірий). У всіх випадках найвищої точності досяг BackUpper.

Людські рецензенти також підтвердили успішність 94% резервних копій, які автоматизований оцінювач визнав успішними.

Початковий стан було відновлено із середньою подібністю 92,2% — проти 33,8% у Claude Opus-5 і 14,3% без відновлення (див. зображення вище). Решту розбіжностей здебільшого пояснювали повторно згенерованими ідентифікаторами та незначними метаданими, зокрема позначками про прочитання електронних листів, як зазначалося раніше.

Зробити самостійно..?

Коли агентам надавали докладні інструкції зі створення власних резервних копій, захищеними були 81,4% критично важливих дій — проти 100% із BackUpper. Три чверті невдалих спроб пояснювалися тим, що резервні копії містили недостатньо інформації для відновлення.

Рівень резервного копіювання в п’яти підходах, перевірених на 205 завданнях із використанням шести моделей ШІ. На лівій діаграмі показано резервні копії, створені до дій, про які згодом шкодували; на правій — захист інших змін поза робочим простором. BackUpper забезпечив повне охоплення в обох категоріях, тоді як докладні інструкції з резервного копіювання для агентів дали показники 81,4% і 80,5%.

Завдяки кешуванню промптів вартість резервного копіювання зменшилася з $0,344 до $0,014 на завдання, а затримка — на 31,7%. Токенів потрібно було в сім разів менше, переважно тому, що рутинні операції виконувалися без допомоги ШІ.

У 40 додаткових завданнях із Terminal-Bench 4 і DeepSWE за допомогою GPT-5.6-Sol і Claude Opus-5 було досягнуто 100% покриття резервним копіюванням без зниження частки виконаних завдань.

Було оцінено три вибіркові політики резервного копіювання: Високий вплив — для суттєвих змін; Поза запитом — для змін, що виходять за межі вказівок користувача; і Людська праця — для матеріалів, створених людьми. У цьому випадку середній показник F1 за оцінками людей становив 84,5%.

Також перевірили, чи здатен BackUpper навчатися багаторазово застосовувати правила резервного копіювання. Після виконання ще 30 завдань у терміналі частка покриття на основі правил зросла з 14,9% до 31,2%, що зменшило залежність від субагента GPT-5.6-Luna.

Висновок

З огляду на мою професію, я мав би раніше перейти до експериментів з агентними системами; однак очевидно ще доальфа-стан самообмеження агентів відлякував мене аж до кількох тижнів тому, коли я нарешті вирішив дати Codex волю у віртуальній машині Windows.

Навіть працюючи у віртуальній машині, я дуже ретельно формулюю свої вказівки, знаючи, що Astra схильна безоглядно кидатися вперед і лише вибачатися, коли втрачені дані чи зіпсований код уже неможливо відновити. До частини фреймворку Python, який я там розробляю, належить інкрементальна функція «зберегти .7z у мережеву папку» одним клацанням миші: вона стискає весь фреймворк і створює його резервну копію. Я запускаю її часто.

Агентний ШІ лише починає свій шлях; без прискіпливої та невтомної уваги до деталей усе зводиться до принципу «скористайся — і втратиш». Не лише підходи до резервного копіювання в агентних системах ще не формалізовано — їх навіть не сформульовано.

* Під назвою «Резервне копіювання, перш ніж пошкодуєте: оцінювання обізнаності про резервне копіювання та його автоматизація в агентів для програмування».

^† Виділення в цитатах належить авторам, а не мені; усі гіперпосилання я додав на основі внутрішньотекстових посилань авторів.

Уперше опубліковано в четвер, 22 жовтня 2026 року