Чому ШІ-агент тупіє ще до кінця вікна — і як цим керувати

Коротко (TL;DR)

Контекстна інженерія — це дисципліна свідомого керування тим, що потрапляє в контекстне вікно агента на кожному кроці: що туди класти, що звідти прибирати і що зберігати назовні. На відміну від prompt engineering (як сформулювати один запит) ідеться про курування всього вікна протягом довгого завдання.

Навіщо це потрібно: модель починає помилятися задовго до того, як вікно заповниться. Це виміряне явище, а не відчуття — і саме воно робить керування контекстом, за словами інженерів Cognition, «завданням номер один» для того, хто будує агентів. Формулювання не випадкове: коли агент працює десятками кроків, якість кожного наступного рішення залежить не так від того, наскільки розумна модель, як від того, що саме лежить у неї перед очима цієї миті. Погано зібраний контекст перетворює навіть топову модель на джерело впевнених помилок, а грамотно зібраний витягує результат там, де сирий промпт давно захлинувся б. Тому контекстна інженерія — це не «просунутий промптинг», а окрема інженерна дисципліна зі своїми правилами.

Що важливо зрозуміти одразу:

• «Правило 40%» («тримай вікно заповненим менш ніж на 40%») — не факт від Anthropic, а корисна, але груба евристика конкретного практика. Реальна деградація залежить від типу завдання, а не від одного універсального відсотка.
• Є структурна рамка прийомів — WSCI (Write / Select / Compress / Isolate): що писати поза контекстом, що вибирати в нього, що стискати, що ізолювати.
• Контекст ламається не одним способом, а чотирма — і в кожного свій захист.

Це стаття про принципи, а не про кнопки. Конкретну механіку Claude Code (/compact, resume, шаблон handoff-документа) ми розбираємо в окремому матеріалі курсу про передавання контексту; тут — фреймворк, застосовний до будь-якого агента.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Context rot: що реально виміряно

Почнімо з факту, а не з анекдоту. Дослідники Chroma у звіті від 14 липня 2025 року прогнали 18 моделей і показали: точність падає нелінійно в міру зростання контексту навіть на простих завданнях. Це не «модель втомилася» — це відтворюваний ефект, названий context rot («гниття контексту»).

Генератор проти критика: як кілька ШІ ловлять баги, що пропускає один

«Готово» — це оцінка агента чи перевірки? TDD та eval-driven розробка зі ШІ

Як запускати кілька агентів Claude Code одночасно й не ловити конфлікти файлів

П’ять периметрів безпеки Claude Code: що реально налаштувати, а що вас здивує

Claude Code без інтерфейсу: headless-режим, Agent SDK і підводні камені автоматизації

Два висновки зі звіту варто запам’ятати. Перший: дистрактори (нерелевантні шматки у вікні) підсилюють деградацію — один відволікальний фрагмент знижує точність, а чотири дистрактори підсилюють падіння ще сильніше. Другий, контрінтуїтивний: моделі нерідко працюють краще на перемішаному, логічно незв’язному тексті, ніж на акуратно структурованому. Це натякає, що деградація пов’язана з механізмом уваги, а не з «розумінням змісту», і що інтуїція «додам більше зв’язного контексту — буде краще» часто хибна.

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

Чому так відбувається на рівні механізму. Модель обробляє вікно через механізм уваги, де кожен токен «дивиться» на всі інші. Що довше вікно, то більше конкурентних зв’язків і то сильніше розмивається сигнал: потрібний факт тоне серед тисяч нерелевантних. Саме тому ШІ-агент плутається у довгому діалозі задовго до того, як вікно фізично заповниться. Це не поломка, а фундаментальна властивість архітектури — і вона пояснює, чому навіть моделі з вікном на мільйон токенів не працюють однаково добре на всьому цьому обсязі. Заявлений розмір вікна каже, скільки тексту влізе, але не скільки модель реально втримає у фокусі.

Правило 40% і «Dumb Zone»: що доведено, а що ні

Звідси народилася популярна евристика. «Dumb Zone» і «правило 40%» — ідея тримати заповнення вікна нижче за 40%, бо після 40–60% якість просідає. Важливо точно назвати джерело: це формулювання практика Dex Horthy (HumanLayer), а не виміряний факт і не офіційна позиція Anthropic. Корисне як орієнтир, але не закон природи.

Ба більше, її прямо критикують. Розбір на agentpatterns.ai під назвою «правило 50% надто просте» показує, що деградація — це радше абсолютний токен-поріг, залежний від типу завдання, ніж універсальний відсоток. Різні бенчмарки дають різну картину:

Ключовий висновок: retrieval-завдання (знайти факт) тримаються майже до межі вікна, а reasoning-завдання (міркувати, пов’язувати) руйнуються на 10–20% ефективного вікна. Тому «одне число на всі випадки» вводить в оману. Корисніше знати: що більше міркувань потребує завдання, то раніше варто чистити контекст. Заявлений розмір вікна конкретної моделі — це верхня межа, а не робочий обсяг.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Різні моделі й геть мають різне ефективне вікно за однакового заявленого — це варто враховувати, порівнюючи моделі під своє завдання: цифра «1 мільйон токенів» на вітрині й обсяг, на якому модель реально міркує без провалів, можуть відрізнятися в рази. Практичний висновок для вайб-кодера: не довіряйте маркетинговому розміру вікна наосліп. Перш ніж покладатися на те, що агент «утримає весь проєкт у голові», перевірте на своєму завданні, де саме в нього починає сипатися якість, — і будуйте робочий процес навколо цього реального порога, а не заявленого.

Чотири способи, якими ламається контекст

Дрю Бройніг систематизував (22 червня 2025 року) чотири режими відмови контексту — і це зручніше, ніж загальне «модель заплуталася»:

• Poisoning (отруєння). У контекст потрапила помилка чи галюцинація і закріпилася — модель посилається на неї знову і знову. Задокументований приклад — агент, що застряг у грі Pokémon із хибною «метою» в контексті.
• Distraction (відволікання). Вікно розпухло, і модель тоне в нерелевантних деталях замість суті.
• Confusion (плутанина). Зайві інструменти й дані збивають вибір дії — на Berkeley function-calling leaderboard видно, як надлишок доступних інструментів роняє точність викликів.
• Clash (конфлікт). У вікні шматки, що суперечать один одному. В експериментах Microsoft і Salesforce «посічені» (sharded) промпти з розсинхроном давали падіння якості до 39%.

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

Сенс таксономії практичний: у кожної відмови свій захист. Отруєння лікується скиданням контексту, відволікання — стисканням, плутанина — скороченням набору інструментів, конфлікт — вичищенням суперечностей. Діагноз визначає ліки — і це набагато продуктивніше, ніж універсальне «модель тупить, додам деталей у промпт» (яке насправді часто посилює відволікання).

Фреймворк WSCI: чотири важелі

Щоб прийоми не були розрізненими порадами, LangChain запропонував рамку з чотирьох категорій — WSCI:

1. Write (писати назовні). Виносьте інформацію з вікна у зовнішнє сховище — нотатки, файли, базу знань проєкту — і підтягуйте в міру потреби, а не тримайте все в контексті.
2. Select (вибирати). На кожному кроці кладіть у вікно тільки те, що потрібно саме зараз, а не «все, що може знадобитися».
3. Compress (стискати). Згортайте історію в саммарі, відкидайте відпрацьовані результати інструментів.
4. Isolate (ізолювати). Розносьте підзавдання по окремих контекстах (суб-агентах), щоб шум одного не заражав інший.

Ці чотири важелі і є інженерія контексту «по-дорослому»: не «тримай нижче за 40%», а свідомо вирішуй для кожного шматка — винести, вибрати, стиснути чи ізолювати.

Розберімо на побутовому прикладі. Ви просите агента доопрацювати модуль оплати у великому проєкті. Наївний підхід — вивалити у вікно весь код проєкту «щоб він усе бачив». Підхід за WSCI: довідник з API платіжного провайдера лишається у зовнішньому файлі, звідки агент підтягне потрібну сторінку (Write); у вікно кладемо тільки файли модуля оплати і пов’язані тести, а не весь репозиторій (Select); історію попередніх ітерацій згортаємо в коротке «що вже зроблено і чому» (Compress); а дослідження, скажімо, сумісності зі сторонньою бібліотекою доручаємо суб-агентові, який поверне висновок у пару абзаців (Isolate). Результат — вікно зайняте суттю завдання, а не шумом, і модель тримає фокус.

Progressive disclosure і ціна ізоляції

Окремо про Isolate, бо це найпотужніший і найбільш недооцінений важіль. Progressive disclosure (пошарове розкриття) — принцип, за якого агент не завантажує все одразу, а розкриває контекст у міру навігації: посилання на документи замість вставляння їх цілком, виклик суб-агента замість @-імпорту всіх файлів. За даними Anthropic, суб-агент може дослідити десятки тисяч токенів, а повернути батьківському агентові стиснуту вижимку на 1000–2000 токенів — батьківське вікно лишається чистим.

Але в ізоляції є ціна, і про неї прямо каже сама Anthropic. Мульти-агентна система дала приріст якості близько 90% — але ціною в рази більше токенів: звичайні агенти витрачають приблизно в 4 рази більше токенів, ніж чат, а мульти-агентні системи — приблизно в 15 разів більше. Ба більше, близько 80% розкиду результату пояснюється просто обсягом витрачених токенів, а не хитрістю архітектури. Іншими словами, «розумна» мульти-агентність місцями еквівалентна «витратити більше токенів» — і в скільки це обходиться на реальних числах, варто прикинути заздалегідь.

Є і зворотний бік, який майже не обговорюють. Cognition наводить приклад: два суб-агенти, працюючи ізольовано, ухвалили неявно конфліктні рішення (у кейсі з грою — різні візуальні стилі), і на збиранні це вилізло. Ізоляція прибирає шум, але створює ризик розузгодження — суб-агенти не бачать рішень один одного.

Звідси практичне правило вибору: ізолюйте те, що справді самостійне (зібрати дані, перевірити факт, прогнати тест), і тримайте в одному контексті те, що потребує узгодженості (єдиний стиль, спільна архітектура, наскрізні рішення). Progressive disclosure — не «завжди дроби на суб-агентів», а «розкривай рівно стільки контексту, скільки потрібно поточному кроку». Посилання на документ замість його вставляння, виклик суб-агента замість завантаження всіх файлів — це спосіб платити увагою моделі тільки за те, що реально в роботі просто зараз. Економія вікна тут прямо конвертується в якість відповіді.

Свіжий контекст між стадіями

Довге завдання корисно різати на стадії з context reset між ними: не тягти всю історію з початку в кінець, а на межі стадії починати з чистого вікна плюс короткий передавальний документ (handoff) із суттю зробленого. Це той самий принцип, що стоїть за агресивними циклами на кшталт Ralph Loop із сусіднього уроку PRO-серії: лишатися в «розумній зоні» вікна через скидання, а не через накопичення.

Конкретну механіку цього в Claude Code — команду /compact, resume і формат самого handoff-документа — розібрано в окремому матеріалі курсу про передавання контексту; тут важливий принцип: свіже вікно на кожній стадії майже завжди працює краще, ніж одне розпухле на все завдання.

Хороший handoff — це не «скопіюй усю історію в нове вікно», а коротка вижимка: що за завдання, що вже зроблено, які ухвалено рішення і чому, що лишилося. Кілька абзаців замість тисяч токенів історії. Парадокс у тому, що агент на свіжому вікні з грамотною вижимкою зазвичай працює краще, ніж той самий агент, який дотягнув усе листування з самого початку: він не відволікається на відпрацьовані деталі й не ризикує зациклитися на ранній помилці. До речі, офіційного числового порога, за якого Claude Code сам стискає контекст, Anthropic не публікує — сторонні оцінки розходяться, тож покладатися на конкретний відсоток не варто.

Ризики і слабкі місця підходу

У самої дисципліни контекстної інженерії теж є ціна і підводні камені:

Ризик наївного правила. Якщо ви механічно чистите контекст на 40%, але завдання — це retrieval по великому документу, ви викидаєте потрібне на рівному місці: такі завдання тримають точність майже до межі вікна. І навпаки, на важкому reasoning навіть 30% вікна може виявитися забагато. Правило 40% — це будильник «пора замислитися про чистку», а не автопілот. Інженер із команди Manus пропонує рахувати бюджет контексту заздалегідь: за його спостереженням, для вікна на мільйон токенів деградація нерідко починається вже близько 256K токенів — це дані однієї команди, незалежно не переперевірені, але як орієнтир корисні.

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

Ризик втрати інформації під час стискання. Агресивний Compress економить вікно, але може викинути деталь, яка знадобиться через три кроки. Стискання — це ставка на те, що ви правильно вгадали, що важливо, а що ні; іноді вгадати не вдається.

Залежність цифр від моделі та бенчмарка. Усі наведені пороги (16% у RULER, 10–20% на reasoning, ~256K у Manus) отримані на конкретних моделях і завданнях і не переносяться один в один на ваше. Це орієнтири напрямку, а не константи. Перевіряйте на своєму навантаженні, а не беріть чуже число за істину.

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

Як це пов’язано з рештою курсу

Щоб не плутати рівні:

• Базове поняття «що таке контекстне вікно» — окрема пояснялка для новачка; тут ми на нього спираємося, але з нуля не розбираємо.
• Механіка Claude Code (/compact, resume, handoff-шаблон) — окремий матеріал про передавання контексту між сесіями.
• Довга пам’ять проєкту між довільними сесіями — це про накопичення знань, інший рівень, ніж вікно однієї сесії.
• Ralph Loop — прикладний приклад дисципліни «лишайся в розумній зоні» через агресивний reset.

Контекстна інженерія — це парасолька над усіма ними: принцип, який кожен із цих інструментів застосовує по-своєму.

FAQ

Чим контекстна інженерія відрізняється від prompt engineering? Prompt engineering — як сформулювати один запит. Контекстна інженерія — як керувати всім вікном протягом довгого завдання: що в нього класти, що прибирати, що зберігати назовні. Друге важливіше для агентів, які працюють багатьма кроками.

Чи правда, що треба тримати вікно заповненим нижче за 40%? Це корисна евристика практика Dex Horthy, а не доведений факт Anthropic. Реальна межа залежить від типу завдання: reasoning деградує вже на 10–20% вікна, retrieval тримається майже до межі. Використовуйте 40% як сигнал «пора подумати про чистку», а не як жорсткий поріг.

Що таке context rot? Виміряне явище (дослідження Chroma, 18 моделей): точність падає нелінійно в міру зростання контексту навіть на простих завданнях. Простіше кажучи — що більше у вікні, то гірше модель працює з тим, що там уже є.

Чи варто завжди дробити завдання на суб-агентів? Ні. Ізоляція контексту підвищує якість, але коштує в 4–15 разів більше токенів і створює ризик, що суб-агенти ухвалять конфліктні рішення. Дробіть там, де підзавдання справді незалежні, а не за замовчуванням.

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

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

Що робити насамперед? Застосуйте WSCI: винесіть довідкові дані у зовнішні файли (Write), кладіть у вікно тільки потрібне зараз (Select), згортайте історію в саммарі (Compress) і розносьте незалежні підзавдання (Isolate). Це дає більше, ніж гонитва за конкретним відсотком заповнення, і працює однаково на будь-якій моделі та в будь-якому агентному інструменті, а не тільки в одному конкретному.