Промпт-інженерія питає: «як сформулювати інструкції?». Контекстна інженерія ставить ширше запитання: з усього, що модель могла б побачити на цьому кроці, що вона має побачити? Для одного виклику чату різниця невелика. Для агента, що працює п'ятдесят кроків, читає файли, викликає інструменти й накопичує результати, — це різниця між системою, яка залишається гострою, і тією, що поволі губить нитку. У гайді пояснюємо, чому контекст — дефіцитний ресурс, і які техніки тримають його сфокусованим.
Чому «просто візьмемо велике вікно контексту» не працює
Сучасні моделі приймають сотні тисяч або навіть мільйон токенів. Кортить покласти туди все: усю кодову базу, всю документацію, повну історію розмови. На практиці якість падає задовго до ліміту:
- Увага нерівномірна. Моделі краще знаходять інформацію на початку й наприкінці довгого контексту, ніж у середині (Liu et al., Lost in the Middle).
- Ефективний контекст коротший за заявлений. Бенчмарки, складніші за простий «пошук голки в копиці сіна», показують падіння продуктивності зі зростанням контексту, особливо для багатокрокових міркувань (Hsieh et al., RULER).
- Відволікаючий вміст шкодить. Нерелевантний, але правдоподібний вміст збиває моделі сильніше, ніж відсутній.
- Вартість і затримка ростуть з токенами. Кожен крок агента перечитує весь контекст; див. оптимізація витрат на LLM.
Інженерна команда Anthropic описує контекст як скінченний ресурс зі спадною граничною віддачею — «бюджет уваги» (Effective context engineering for AI agents). Мета — найменший набір токенів із високим сигналом, що максимізує шанс бажаного результату.
Що конкурує за контекстне вікно
| Компонент | Типовий розмір | Примітки |
|---|---|---|
| Системний промпт | 1–5 тис. токенів | Стабільний; кешується |
| Визначення інструментів | 0,5–20 тис. токенів | Росте з кожним інструментом; див. дизайн інструментів |
| Знайдені документи | 2–50 тис. токенів | Найбільший важіль у RAG |
| Історія розмови | Росте необмежено | Потребує обрізання чи підсумовування |
| Результати інструментів | Ростуть щокроку | Часто найбільший споживач в агентах |
| Пам'ять / нотатки | 0,5–5 тис. токенів | Відібрані факти з попередньої роботи |
| Поточна задача | Мало | Ніколи не має витіснятися |
Ставтеся до цього як до бюджету пам'яті у вбудованому програмуванні: кожен компонент має ліміт, і кожен токен мусить себе виправдати.
Техніка 1: Правильний розмір системного промпту
Системні промпти помиляються у двох напрямках. Надто конкретні — довгі списки правил «якщо–то» для граничних випадків — стають крихкими й суперечливими. Надто розмиті — «будь корисним» — не дають моделі потрібних сигналів. Цільтеся в середину: чіткі принципи, кілька справді важливих жорстких правил і кілька канонічних прикладів замість вичерпного списку. Структуруйте заголовками чи XML-тегами, щоб розділи легко знаходилися. Деталі — у статті промпт-інженерія для розробників.
Техніка 2: Пошук «точно вчасно» замість попереднього завантаження
Замість завантажувати всі потенційно релевантні дані наперед, дайте агенту легкі посилання й інструменти, щоб діставати деталі, коли треба: шляхи до файлів, ідентифікатори документів, інструменти пошуку, запити до БД. Так працюють кодові агенти у великих репозиторіях: вони не читають кожен файл, а роблять grep, переглядають директорії, відкривають релевантні файли й залишають лише важливе.
Компроміси:
- Попереднє завантаження швидше під час роботи й підходить, коли релевантний набір малий і передбачуваний (профіль клієнта для чату підтримки).
- «Точно вчасно» масштабується на великі корпуси й тримає контекст чистим ціною додаткових викликів інструментів.
- Гібрид — попередньо завантажити невелике цінне ядро (інструкції, профіль користувача, файл інструкцій проєкту на кшталт
CLAUDE.md), а решту діставати на вимогу — варіант за замовчуванням, який ми радимо.
Тоді критичною стає якість пошуку; див. RAG для бізнесу і ембеддинги та чанкінг.
Техніка 3: Обрізайте й підсумовуйте результати інструментів
Результати інструментів — найшвидше зростаюча частина контексту агента. Стратегії:
- Формуйте вивід у джерелі. Інструменти мають повертати стислі результати з високим сигналом і пагінацією; це дешевше, ніж прибирати потім.
- Очищуйте застарілі результати. Коли великий вивід інструмента вже використано — прочитаний файл, результат пошуку, — він рідко має залишатися дослівно. Деякі платформи підтримують автоматичне очищення старих результатів інструментів; інакше замінюйте їх однорядковою нотаткою («прочитано config.yaml: Postgres 16, pool size 20»).
- Зберігайте великі артефакти поза контекстом. Записуйте великий вивід у файли й давайте агенту шлях.
Техніка 4: Стиснення (compaction)
Коли розмова наближається до ліміту контексту, підсумуйте її й продовжте в новому вікні з підсумком. За правильного виконання стиснення зберігає рішення, відкриті проблеми, важливі деталі (назви файлів, ідентифікатори, повідомлення про помилки) і відкидає надлишковий вивід інструментів і глухі кути.
Summarise this session for continuation. Keep:
- the task and acceptance criteria
- decisions made and why
- files changed and their current state
- unresolved errors with exact messages
- next planned steps
Drop: raw tool outputs already acted on, failed approaches (one line each).
Налаштовуйте промпт підсумку на реальних довгих сесіях: спершу максимізуйте повноту (нічого важливого не втрачено), потім скорочуйте. Кодові агенти реалізують це як автоматичне або ручне стиснення.
Техніка 5: Структуровані нотатки
Для довгих задач дайте агенту вести нотатки поза контекстним вікном — файл NOTES.md, список задач, інструмент пам'яті — і перечитувати їх за потреби. Нотатки переживають стиснення й скидання контексту і дають агенту стабільне відчуття прогресу протягом годин роботи. Це особливо добре працює для багатокрокових міграцій, дослідницьких задач і всього, що триває кілька сесій.
# NOTES.md — міграція billing на java.time
- [x] Пакет billing.invoice (12 файлів) — тести зелені
- [x] Пакет billing.tax — примітка: TaxPeriod явно використовує Europe/Kyiv
- [ ] Пакет billing.reports — 3 використання Joda Interval, потрібен адаптер
Відкрите питання: округлення в ReportTotals відрізняється від старої поведінки? (#481)
Техніка 6: Субагенти з чистим контекстом
Субагент — окремий виклик моделі чи агент із власним свіжим контекстом, якому дають сфокусовану задачу — «знайди всі місця, де ми парсимо дати в пакеті reports, і підсумуй використані формати», — і який повертає лише стислий результат. Контекст основного агента отримує кілька сотень токенів замість десятків тисяч, які спожив субагент.
Таке розділення відповідальності — одна з головних причин, чому мультиагентні архітектури перевершують одиночних агентів у широких дослідницьких задачах, ціною значної кількості токенів; див. мультиагентні системи. Кодові інструменти реалізують ту саму ідею як субагентів.
Техніка 7: Довготривала пам'ять — обережно
Пам'ять між сесіями — вподобання користувача, минулі рішення, факти про проєкт — робить агентів «розумнішими», але це також контекст, який може бути хибним, застарілим або підкинутим. Правила, яких ми дотримуємося:
- Зберігайте факти з джерелом і датою, а не сирі транскрипти.
- Діставайте пам'ять вибірково за релевантністю, як будь-який інший документ.
- Давайте користувачам бачити й видаляти, що про них запам'ятовано, — це також вимога приватності.
- Пам'ять, записану з недовіреного вмісту, вважайте недовіреною.
Порядок і кешування
Те, як ви впорядковуєте контекст, впливає і на якість, і на вартість:
- Спершу стабільний вміст: системний промпт, визначення інструментів, довгі довідкові документи. Цей префікс можна кешувати, що суттєво зменшує вартість і затримку повторних викликів.
- Далі напівстабільний: профіль користувача, нотатки проєкту.
- Динамічний — наприкінці: історія розмови, останні результати інструментів, поточне запитання.
Розміщення довгих документів перед запитанням також зазвичай покращує якість відповіді.
Як вимірювати якість контексту
Контекстну інженерію можна тестувати:
- Абляція: приберіть компонент контексту й перезапустіть evals; якщо оцінки не впали, ви платили даремно.
- Бюджет токенів на крок: відстежуйте вхідні токени на кожен крок агента протягом сесії; різке зростання вказує на роздуті результати інструментів.
- Evals на довгих сесіях: включайте задачі на 30+ кроків, щоб деградація проявлялася в тестах, а не в продакшені.
- Перегляд трас: читайте, що саме бачила модель на кроці, де вона помилилася; див. спостережуваність LLM.
FAQ
Контекстна інженерія — це просто нова назва для RAG? RAG — одна з її технік. Контекстна інженерія охоплює також інструкції, інструменти, історію, пам'ять і те, як усе це змінюється протягом багатокрокової задачі.
Чи не зроблять більші контекстні вікна це неактуальним? Ні. Більші вікна піднімають стелю, але фокус і вартість усе одно залежать від того, що ви туди кладете. Кожен опублікований бенчмарк довгого контексту показує деградацію з більшою кількістю відволікаючого вмісту.
Як вирішити, що підсумовувати? Зберігайте все, що потрібно для майбутніх рішень, — цілі, обмеження, рішення, відкриті помилки, ідентифікатори, — і відкидайте те, на що вже відреагували.
З чого почати? Виміряйте токени на крок у вашому агенті, знайдіть найбільшого споживача (зазвичай результати інструментів чи історія) і виправте спершу його.
Джерела
- Anthropic (2025). Effective context engineering for AI agents.
- Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
- Hsieh et al. (2024). RULER: What's the Real Context Size of Your Long-Context Language Models?
- Anthropic. Prompt caching.
- Anthropic. Субагенти Claude Code.
- Packer et al. (2023). MemGPT: Towards LLMs as Operating Systems.