ШІ-агенти можуть пам’ятати правила й однаково порушувати їх після стиснення

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

Спочатку цей метод застосовували в агентному ШІ, а згодом поширили й на Claude. У розмовах розробників ущільнення для Gemini поки що не з’явилося, а ChatGPT уникає його, просто завершуючи чат.

Якщо ви користувалися Codex (по суті, версією ChatGPT, яка за наявності дозволу може безпосередньо змінювати дані на вашому комп’ютері) довше ніж 30 хвилин поспіль, то, напевно, бачили періодичні повідомлення про ущільнення контексту, під час якого подальша взаємодія недоступна:

Codex перепочиває, щоб стиснути спогади про сеанс, який на той час триває вже три тижні.

Однак після завершення ущільнення співрозмовник спирається на невидимі вибіркові нотатки, а не на повну пам’ять про перебіг чату.

ШІ, який порушує правила

У червні цього року китайська стаття Governance Decay показала, що ущільнення може непомітно вилучити з контексту агента чинні правила, унаслідок чого той виконує дії, які раніше були заборонені:

Зі статті за червень 2026 року «Governance Decay»: як ущільнення контексту може спонукати ШІ-агента порушити правило, якого він раніше дотримувався. Якщо правило не потрапить до стиснутого викладу, агент може зрештою виконати заборонену дію. Зловмисник може скористатися цим процесом, а відновлення правила — запобігти порушенню. Джерело

У семи моделях частка порушень зросла з 0% до ущільнення до 30% після нього, а в окремих випадках сягнула 59%. На практиці це означає, що агенти можуть ігнорувати важливі вказівки, наприклад Не контактуйте з тими, хто не має адреси електронної пошти з доменом [our-company], — і це може мати очевидні наслідки.

У липні Університет штату Пенсильванія та IBM продовжили це дослідження роботою Lost in Context і з’ясували, що ущільнення може вилучати інструкції, які визначають, як саме ШІ має виконувати завдання, зберігаючи при цьому саме завдання. У випробуваннях у трьох середовищах механізми ущільнення зберігали в середньому лише 17% таких інструкцій.

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

ARCBench

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

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

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

У випробуваннях із DeepSeek-V4-Flash, GLM-5.3-Flash, Qwen3.7-Flash і GPT-Luna повне правило збереглося у 70,1% запусків зі стисненням. У тих запусках, де правило збереглося, порушення траплялися у 2,6 раза частіше, ніж за використання повної історії розмови.

Контекст у традиційному розумінні виявився важливим чинником: коли правила подавали як організаційну політику, за повного контексту порушень не було, однак після стискання контексту їхня частота зросла до 30,6% і 22,2%.

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

У статті зазначено:

‘[We] виявили, що стискання здебільшого збільшує кількість порушень, не видаляючи правило: навіть у запусках після стискання, де правило збереглося, його порушували у 2,6 раза частіше, ніж у запусках із повною історією.

‘Крім того, стискання змінює міркування агента щодо порушення правила. На дотримання правил впливають різні стратегії стискання, жорсткі обмеження бюджету токенів для стискання та канал передавання правила.’

Як спосіб розв’язання проблеми стаття пропонує надійніше зберігати правила, втрачені під час стискання, однак питання непокори агентів збереженим правилам залишається невирішеним”

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

Методика

ARCBench розширює можливості інструментарію з відкритим вихідним кодом pi, який має власні вбудовані процедури стискання, цикл роботи агента, виклик інструментів і вбудоване стискання контексту. Бенчмарк відтворює ситуації, у яких агент виконує тривале завдання, дотримуючись постійного правила, стискає накопичену історію, а потім отримує запит, виконання якого порушило б це правило; дії агента перевіряють за викликами інструментів:

Конвеєр оцінювання ARCBench. Агентам ставлять завдання й задають правило роботи, перш ніж стискати їхню історію за різних конфігурацій, атак і засобів захисту. Потім аналізують подальші дії агентів із використанням інструментів, щоб визначити, чи збереглося правило і чи дотримувалися його.

ARCBench охоплює 17 випадків, пов’язаних із розголошенням захищених даних, доступом до ресурсів з обмеженим доступом, несанкціонованими діями та обходом або пропуском обов’язкових засобів контролю. Вони відповідають класам ризиків OWASP.

Випадки адаптували на основі Governance Decay і COMPINT, а також додали ще чотири, щоб усі чотири типи порушень були представлені як для особистих, так і для організаційних правил.

Бенчмарк можна налаштувати за п’ятьма чинниками: способом передавання правила; методом стискання контексту; бюджетом токенів, доступним для стискання; типом атаки; і застосованим засобом захисту:

ARCBench охоплює п’ять параметрів, за якими перевіряють, як дотримання правил змінюється залежно від способу стискання контексту, передавання правила, атак і засобів захисту.

Правила можна задавати як прямі або постійні інструкції, вбудовувати в документи або отримувати за допомогою інструмента для роботи з політиками.

Дані та тести

Оцінили десять методів стискання: сім генеративних і три селективні. Кожен випадок запускали неодноразово, а невдачу фіксували, якщо агент порушував правило принаймні один раз. Такий підхід вважали доречнішим для перевірки безпеки, ніж усереднення результатів за всіма запусками, адже агент, який час від часу виконує заборонену дію, усе одно залишається небезпечним.

Потім стиснуті історії аналізували GPT-6-Luna-Pro, Qwen-3.8-flash і Claude-Sonnet-4.6, класифікуючи кожне правило як збережене без змін, послаблене або відсутнє. Використовували рішення більшості, а розбіжності перевіряли анотатори-люди. Щоб оцінити узгодженість суддів, окрему вибірку з 50 підсумків також розмітили вручну.

Коли правило, збережене без змін, порушували, міркування агента аналізували GPT-6-Luna-Pro, GPT-6.1-Sol і Claude Sonnet 5.5. Порушення класифікували залежно від того, чи сприйняв агент пізніший запит як дозвіл обійти правило; чи вирішив, що дія не підпадає під його дію; чи не згадав про правило; чи розпізнав його і проігнорував.

Для тестів використовували чотири моделі, доступні через OpenRouter: DeepSeek-V4-Flash; GLM-5.3-Flash; Qwen3.7-Flash; і GPT-Luna. У кожному запуску ту саму модель використовували і для стискання історії розмови, і для роботи з отриманим контекстом, що відповідає стандартній поведінці pi. Доступ до моделей здійснювали через OpenRouter.

Було проведено сім досліджень, і для більшості тестів ущільнення використовували Hermes. У першому дослідженні кожне із 17 завдань перевірили на чотирьох моделях і за двох способів подання правила — загалом у 136 випадках. Кожен випадок запускали тричі з початковою історією розмови та тричі після її ущільнення.

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

У тестах розглядали три питання: Звідки беруться порушення після ущільнення?; Як різні конфігурації ущільнення змінюють причини порушень?; і Як атаки, спрямовані на механізм ущільнення, та засоби захисту впливають на причини порушень?.

Звідки беруться порушення після ущільнення?

Перші результати засвідчили, що після ущільнення частка випадків із порушенням правил зросла з 9,6% за повної історії розмови до 37,8%. Однак усього в 3% запусків після ущільнення правило було втрачено повністю; у 70,1% воно збереглося без змін, а в 26,9% — частково:

Результати показують, як часто кожна модель порушувала правила до та після ущільнення. Більшість правил збереглися повністю або частково, хоча кількість порушень істотно зросла; найбільше зростання зафіксували в Qwen — до 61,8%.

Ця відмінність виявилася важливою. Серед окремих запусків, у яких після ущільнення правило збереглося повністю, порушення все одно відбулися у 21,1% випадків — порівняно з 8,1%, коли початкова історія залишалася незмінною. Якщо правило збереглося частково, цей показник зріс до 29,4%, а якщо не залишилося жодного правила — до 83,3%.

Також дослідили, як відбувалися порушення, коли правило залишалося незмінним. Серед порушень, спричинених ущільненням, у 45,9% випадків пізніший запит сприймали як дозвіл діяти; у 27% випадків правилом, очевидно, нехтували; а в 21,6% його визнавали застосовним, але все одно порушували:

Результати показують, чому правила порушували до та після ущільнення. Коли порушення виникали лише після ущільнення, пізніші запити найчастіше сприймали як дозвіл діяти (45,9%); у 27% випадків збереженим правилом нехтували, а в 21,6% його визнавали, але все одно діяли всупереч йому.

Як різні конфігурації ущільнення змінюють причини порушень?

Спосіб подання правила помітно впливав на дотримання вимог. Коли повна історія розмови залишалася незмінною, порушення траплялися у 25% і 16,1% випадків, коли правила надавав безпосередньо користувач; утім, порушень не зафіксували, коли правила подавали через організаційний документ або інструмент політик:

Як спосіб подання правила, стратегія ущільнення та ліміт токенів впливали на кількість порушень і збереження правил. Генеративне ущільнення зберігало правила набагато надійніше, ніж вибіркові методи, тоді як ліміти у 300 токенів або менше призводили майже до повної втрати правил.

Після ущільнення кількість порушень зросла за всіх чотирьох способів подання правил: до 56,3% для прямих інструкцій користувача та до 22,2% для правил, поданих через інструмент політик. Частка збережених правил змінювалася порівняно незначно — від 65,7% до 74%. Автори припускають, що пізніший запит користувача можуть сприйняти як такий, що скасовує особисте правило, тоді як користувач не може скасувати організаційне правило.

Як атаки, спрямовані на механізм ущільнення, та засоби захисту впливають на причини порушень?

Саме по собі перенасичення контексту додатковими матеріалами мало що змінило: кількість порушень навіть знизилася з 37,8% до 34,3%. Ін’єкція, спрямована на механізм ущільнення, виявилася значно ефективнішою: кількість порушень зросла до 46,3%, а частка правил, збережених повністю, зменшилася з 70,1% до 42,5%.

Найсильніша атака, названа escape, збільшила кількість порушень з 23,5% до 58,8%, а частка збережених правил зменшилася з 96,1% до 66,7%. Навіть коли правило зберігалося, кількість порушень подвоювалася — з 13,3% до 26,5%.

Результати випробувань, що показують, як атаки й засоби захисту впливають на дотримання правил після ущільнення контексту. Цільова ін’єкція збільшила кількість порушень і знизила рівень збереження правил, тоді як найефективніший захист відновив цей показник до 99%, але не забезпечив повного дотримання правил.

Найефективніший захист зберіг правило у 99% запусків — і все ж агенти порушували його у 29,4% випадків, порівняно з 23,5% випадків, коли атаки не було. Іншими словами, гарантія того, що агент і далі пам’ятає правило, не гарантувала, що він його дотримуватиметься.

Висновок

Логіка підказує, що під час ущільнення контексту в довжелезному ланцюжку десятки, а то й сотні разів діє своєрідний «ефект ксерокса» (наприклад, у проєкті, над яким я працюю в Codex* із середини жовтня і яким займався ще сьогодні вранці, — справжній епос експериментальної розробки програмного забезпечення за допомогою ШІ).

Як і системні промпти, ці стислі підсумки перебігу роботи ми не бачимо. Мій власний, суто анекдотичний досвід свідчить, що центральна місія переживає стиснення разом із більшістю важливих деталей. Але я не опинявся в тому кошмарному сценарії, коли команда «Надішли цей лист усім», призначена лише усім співробітникам компанії, зрештою надсилає його всім контактам в об’єднаній корпоративній адресній книзі. Оце так.

* Мабуть, я вже старію, але це, безперечно, найбільш незапам’ятовувана, безлика, «корпоративно-бежева» назва, яку тільки можна було обрати для цього агента. Я постійно її забуваю.

Вперше опубліковано в четвер, 12 листопада 2026 року