У міру того як компанії масово переходять від простих чат-ботів до автономних AI-агентів, на перший план виходить малопомітна, але критична проблема: як саме модель бачить інформацію на кожному кроці. У своєму курсі про context engineering старша applied scientist Twitch/Amazon Марина Вісс розбирає, чому агенти, які чудово працюють на перших кроках, раптом «тупішають» на 15–20-му, і чому справа майже ніколи не в самій моделі, а в тому, як заповнене її контекстне вікно.
Цей матеріал зосереджується на межах контекстних вікон LLM, ефекті «lost in the middle» та тому, як сім різних типів інформації конкурують за обмежену «оперативну пам’ять» агента — і без правильного проєктування буквально знищують його продуктивність.
Коли проблема не в моделі: як виглядає ранній розвал агента
Типовий сценарій для розробників агентів уже став майже кліше. На старті все виглядає обнадійливо: агент коректно обирає інструменти, логічно міркує, тримається заданої цілі. Але після десятка-другого кроків поведінка змінюється. Він починає забувати початковий запит користувача, викликає інструменти, які не мають сенсу, або генерує відверто слабкі відповіді.
Інтуїтивна реакція — звинуватити модель: «GPT/Claude/Gemini не тягне довгі ланцюжки міркувань». Однак у практичних системах частіше винен не сам LLM, а те, що йому підсовують у контекст. Кожен крок агента — це нові токени: системні інструкції, визначення інструментів, результати викликів, витягнуті документи, історія діалогу, внутрішній стан. Усе це бездумно додається до промпту, поки контекстне вікно не перетворюється на смітник.
У цей момент починається те, що в інженерних блогах називають context drop: модель формально ще «бачить» усі токени, але її здатність витягувати з них потрібні залежності різко падає. Ззовні це виглядає як деградація моделі, хоча насправді це деградація інформаційного середовища, в якому вона працює.
Контекст як RAM: чому «200K токенів» — це не те, чим здається
LangChain пропонує корисну аналогію: розглядати LLM як CPU, а його контекстне вікно — як RAM. Модель виконує «обчислення», а контекст — це робоча пам’ять, де одночасно живе все, що вона може врахувати при наступному кроці. Як і в комп’ютері, коли RAM забита, система не просто перестає запускати нові програми — вона починає повільно й помилково працювати з уже відкритими.
Ключовий момент: контекстне вікно має не лише жорстку верхню межу (наприклад, 200 тисяч токенів), а й зону поступового погіршення якості задовго до цієї межі.
Дослідження Chroma, на яке посилається Вісс, стало одним із найяскравіших сигналів для інженерів. Команда оцінила 18 frontier-моделей — GPT‑4.1, Claude 4, Gemini 2.5, Qwen 3 та інші — на завданнях, де поступово збільшували довжину вхідного тексту. Висновок виявився неприємним, але однозначним: усі без винятку моделі демонструють деградацію продуктивності в міру зростання довжини інпуту, навіть коли той далеко не доходить до заявленої межі контексту.
Показовий приклад: модель із номінальним вікном у 200 тисяч токенів починає помітно «просідати» вже приблизно на 50 тисячах. Ніякого різкого обриву на останньому токені немає — натомість спостерігається плавний, але невблаганний спад точності.
Це підтверджують і інженерні матеріали Anthropic: контекстна деградація — це градієнт, а не прірва. Чим більше токенів у вікні, тим гірше модель відстежує всі потрібні взаємозв’язки.
Технічна причина лежить у самій природі трансформерів. Кожен токен «уважно дивиться» на кожен інший, формуючи квадратичну кількість парних взаємодій. У міру зростання контексту модель змушена розмазувати свою «увагу» по дедалі більшій кількості пар, і точність представлення окремих залежностей падає. Це схоже на людину, якій доручили одночасно стежити не за трьома, а за трьома сотнями об’єктів: щось неминуче випаде з поля зору.
Для практичних агентів це означає, що розробники не можуть сприймати заявлене «200K context window» як робочий об’єм пам’яті. Реальний «комфортний» діапазон значно менший, і кожен зайвий блок тексту в промпті безпосередньо знижує якість міркувань.
«Lost in the middle»: як інструкції зникають у середині промпту
Навіть якби моделі однаково добре працювали з будь-якою довжиною контексту, залишалася б ще одна фундаментальна проблема — розподіл уваги всередині цього вікна. Дослідження, на які посилається Вісс, описують ефект, що отримав назву «lost in the middle».
Якщо побудувати криву того, наскільки добре LLM пам’ятає інформацію залежно від її позиції в контексті, виходить U-подібний графік. Дані на початку промпту модель відтворює відносно добре. Дані в кінці — теж, адже вони свіжі й безпосередньо передують відповіді. А от інформація в середині контексту виявляється в «сліпій зоні».
У дослідженні, яке цитує Вісс, виміряли падіння точності, коли релевантний фрагмент переносили з початку в середину контексту. Різниця перевищила 30 відсоткових пунктів. Тобто одна й та сама інформація, просто зміщена всередину промпту, стає для моделі суттєво менш доступною.
Для агентів це має прямі наслідки. Уявімо багатокроковий сценарій, де початкові інструкції користувача й системний промпт опиняються на самому початку, а потім до них додаються десятки тисяч токенів результатів інструментів, витягнутих документів і проміжних відповідей. Через деякий час початкові правила й цілі виявляються десь посередині гігантського промпту — саме там, де модель найгірше їх «бачить».
Формально інструкції все ще в контексті. Але з погляду фактичної уваги моделі вони майже зникають. Звідси й типова поведінка: агент раптом перестає дотримуватися раніше чітко заданих обмежень, забуває про кінцеву мету, починає діяти суперечливо. Це не «капризи» моделі, а наслідок того, що критично важлива інформація опинилася в найневдалішій позиції.
Сім типів інформації, які воюють за місце в контексті агента
Щоб зрозуміти, чому «просто додати все в промпт» — погана стратегія, варто розкласти контекст агента на складові. Вісс виділяє сім категорій інформації, які одночасно претендують на обмежений об’єм вікна.
По-перше, системний промпт. Це не просто фраза «ти корисний асистент». У агентних системах він часто описує всю архітектуру поведінки: роль агента, його стиль міркувань, правила безпеки, пріоритети, стратегії розв’язання задач, іноді навіть контрольні потоки на кшталт «спочатку сплануй, потім обери інструмент, потім оціни результат». Системний промпт задає «особистість» і операційну логіку агента, тому його не можна безкарно обрізати.
Друга категорія — визначення інструментів. Кожен доступний агенту тул має бути описаний у промпті: що він робить, які параметри приймає, у яких випадках його варто викликати. Це схеми функцій, без яких модель не зможе коректно обирати й викликати інструменти. У складних системах таких тулів може бути десятки, і кожен опис займає помітну кількість токенів.
Третя — результати викликів інструментів. Кожен HTTP-запит, кожен запуск коду, кожне читання файлу повертає дані, які додаються до контексту. Одна сторінка з вебу легко може важити 5–10 тисяч токенів. Читання великого файлу дає схожі об’єми. Якщо агент активно працює з кодом, логами чи документами, ці результати дуже швидко заповнюють вікно.
Четверта категорія — витягнуті знання з RAG. Це документи з векторних баз, результати пошуку, відповіді зовнішніх API, які система підтягує, щоб допомогти агенту. Кожен такий фрагмент — ще кілька сотень чи тисяч токенів. У класичних RAG-пайплайнах це вже проблема, але в агентних системах, де витяг може відбуватися на кожному кроці, об’єм росте ще швидше.
П’ята — історія діалогу. Усе, що сказав користувач, усе, що відповів агент, включно з проміжними міркуваннями й поясненнями, за замовчуванням додається до контексту. Кожен новий крок лінійно збільшує цю частину промпту. Якщо не застосовувати агресивне скорочення чи резюмування, історія дуже швидко витісняє інші важливі елементи.
Шоста категорія — пам’ять. Це як короткострокові відомості поточної сесії (наприклад, уточнені вподобання користувача), так і довгострокові факти з попередніх взаємодій: минулі задачі, результати, стабільні преференції. Частина цієї пам’яті може зберігатися поза контекстом, але щойно її витягують для поточного кроку, вона теж займає місце у вікні.
Нарешті, сьома — стан агента. Це його поточний план, список підзадач, маркери прогресу, нотатки на кшталт «ми вже перевірили ці три гіпотези, залишилася четверта». У складних довготривалих задачах такий «скретчпад» критично важливий, щоб агент не ходив по колу й не повторював ті самі дії.
Усі ці сім категорій одночасно претендують на один і той самий ресурс — токени контекстного вікна. Коли розробник просто «запихає все, що може знадобитися», він не лише наближає модель до зони довжинової деградації, а й створює ідеальні умови для ефекту «lost in the middle». Щось важливе неминуче опиниться в середині промпту й стане практично невидимим для моделі.
Чому стратегія «запхати більше в контекст» працює проти вас
На перших прототипах агентів часто використовується наївний підхід: якщо модель щось забуває або робить помилки, треба просто дати їй більше інформації. Додати повні логи інструментів, не обрізати історію діалогу, підвантажити більше документів із RAG. Здається логічним: чим більше даних, тим краще модель зможе міркувати.
Однак у реальних системах це майже завжди дає протилежний ефект. По-перше, зростає загальна довжина промпту, і модель потрапляє в зону, де Chroma фіксує стабільну деградацію якості. Навіть якщо до формальної межі ще далеко, точність відповідей уже помітно гірша.
По-друге, збільшується ризик того, що ключові інструкції або релевантні факти опиняться в середині контексту, де спрацьовує «lost in the middle». Наприклад, якщо системний промпт і початкове формулювання задачі залишаються на самому початку, а потім до них додаються десятки тисяч токенів результатів інструментів, то на певному етапі ці інструкції зміщуються в середину вікна. Формально вони ще там, але модель поводиться так, ніби їх немає.
По-третє, надлишок несортованої інформації ускладнює для моделі виділення справді важливих сигналів. Коли в промпті одночасно присутні десятки визначень інструментів, великі шматки історії діалогу, кілька витягнутих документів і довгі логи, модель змушена розподіляти увагу між усім цим. У результаті вона може обрати не той тул, спиратися на застарілу інформацію або ігнорувати свіжі результати.
Саме тому Вісс пов’язує ранні симптоми провалу агентів — забуті цілі користувача, безглузді виклики інструментів, різке падіння якості відповідей після багатьох кроків — не з «втомою» моделі, а з перевантаженим або погано структурованим контекстом. Модель робить те, що може, з тим, що бачить. Якщо те, що вона бачить, — хаотичний, надмірний і погано організований набір токенів, результат буде відповідним.
Як моделі, оптимізовані під агентів, борються з контекстним хаосом
Навіть найкраще спроєктований контекст не скасовує того факту, що деякі моделі краще пристосовані до довгих, багатокрокових сценаріїв, ніж інші. Вісс наводить як приклад Kimi K2.6 — відкриту LLM, яку позиціонують саме як модель для агентних задач.
K2.6 досягла state-of-the-art результатів на бенчмарку SweBench Pro, орієнтованому на складні задачі в області коду. Але ще показовіший реальний кейс: агент на базі цієї моделі автономно працював 13 годин, зробив понад тисячу викликів інструментів, змінив чотири тисячі рядків коду й майже утричі збільшив пропускну здатність уже оптимізованої кодової бази.
З погляду контексту тут важливі дві речі. По-перше, K2.6 досягає тих самих результатів приблизно на 35 кроків менше, ніж попередня версія. Менше зайвих викликів інструментів — менше «сміття» в контекстному вікні, менше шансів потрапити в зону довжинової деградації й загубити важливі інструкції в середині промпту.
По-друге, Kimi пропонує так званий «роїй» агентів: до 300 субагентів, які можуть працювати паралельно, кожен зі своїм власним контекстним вікном. Замість того щоб один агент намагався тримати в голові все — від високорівневого плану до деталей кожного файлу, — система розподіляє роботу між спеціалізованими агентами з окремими, чистими контекстами. Це ще один спосіб обійти обмеження єдиного великого вікна: розбити задачу на підзадачі, кожна з яких поміщається в «здоровий» діапазон довжини.
Ці приклади показують, що боротьба з контекстним хаосом — це не лише питання інженерії промптів, а й вибору моделей та архітектур, які мінімізують непотрібні кроки й уникають надмірного накопичення інформації в одному промпті.
Висновок: контекст — це не сховище, а керований ресурс
У міру того як, за прогнозом Gartner, до кінця 2026 року до 40% корпоративних застосунків інтегрують задачоорієнтованих AI-агентів, стає очевидно: успіх таких систем визначається не лише якістю базової моделі, а й тим, як саме організовано її контекст.
Дослідження Chroma показують, що жодна з провідних LLM не є «байдужою» до довжини інпуту: продуктивність падає задовго до формальної межі вікна. Ефект «lost in the middle» демонструє, що позиція інформації всередині промпту критично важлива, а не лише її наявність. Сім категорій даних — від системного промпту до стану агента — постійно борються за місце в цьому обмеженому просторі.
Наївна стратегія «додати все, що може знадобитися» не просто не допомагає, а й прямо шкодить: посилює довжинову деградацію, ховає ключові інструкції в середині контексту й ускладнює моделі виділення релевантних сигналів. Ранні симптоми провалу агентів — забуті цілі, дивні інструментальні виклики, падіння якості після багатьох кроків — у більшості випадків є наслідком саме цього перевантаження.
Для інженерів це означає, що контекст треба розглядати не як бездонне сховище, а як дефіцитний ресурс, який потрібно ретельно планувати, структурувати й захищати від «засмічення». Лише в такому режимі LLM зможуть реалізувати свій потенціал у довготривалих, складних агентних сценаріях — без того, щоб «ламатися» на 20-му кроці.
Джерело
Context Engineering for AI Agents: Complete Course — YouTube