Контекст-інжиніринг: нова логіка роботи з LLM

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт! Мене звати Богдан Овсієнко, я Senior AI Engineer у Levi9. Написав колонку про промпт-інжиніринг, адже останні кілька років ми спостерігаємо бум цього напряму і хочеться додати трохи ясності. Вже з’явилися гіди, курси, шаблони та різноманітні формули ефективних промптів. Тільки от коли починаєш працювати з LLM у реальних продуктах, виявляється, що проблема не завжди у запиті.

Чому промпт-інжиніринг вичерпав себе

За останні кілька років промпт-інжиніринг домінував у дискурсі навколо LLM. І це валідно, тому що промпти були головним інтерфейсом між людиною та моделлю. Можна було отримати на диво хороші результати з one-shot промптами, а потім і з few-shot. Пізніше з’явилися техніки ​​на кшталт Chain-of-Thought, або вже класичний «Act as» паттерн. Усе це допомагало підштовхнути ранні моделі до більш передбачуваної поведінки. Але досить швидко всі зрозуміли й обмеженість таких технік.

Основним недоліком промпт-інжиніринг є те, що даний підхід змушує людей комунікувати в дуже не природній і штучний спосіб. Ви не зустрінете інструкцій в стилі: «Дій як шеф із трьома зірками Мішлен. Точно дотримуйся рецепту. Не роби помилок. Починай ЗАРАЗ. Не став запитань. Роби все ШВИДКО.»

В реальному житті такі інструкції виглядатимуть простіше, типу: «Приготуй Карбонару.»

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

Ця прогалина і є проблемою: у сирому вигляді промпти передають моделі інструкцію, але майже не передають контекст. Але, частіше за все, при всьому наявному об’ємі інформації, на якій тренуються поточні SOTA (State of The Art) моделі цього не достатньо. І не вистачає саме контексту про ВАС.

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

LLM не потребують надскладних і комплексних промптів, бо їм потрібен правильний контекст. Не одноразові інструкції, а структурований блок інформації, який постійно покращується та який коригуватиме поведінку моделі, та вказуватиме на те, на що їй потрібно звернути увагу. Тобто контроль над тим, як модель буде себе поводити, та що вона використовуватиме як інформацію для генерування відповіді.

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

Промпт-інжиніринг був важливим стартом. Але коли ми почали будувати реальні системи — агентів, RAG-пайплайни, моделі з використанням інструментів і бізнес-асистентів стало ясно: основний виклик не у формулюванні промпту, а в контролі всього інформаційного простору, в якому працює модель.

Саме цей зсув дав поштовх розвитку контекстного інжинірингу. Він не замінив уже звичний промпт-інжиніринг, а радше змістив фокус і розширив наші можливості взаємодії з моделями.

Що таке контекстний інжиніринг?

Контекстний інжиніринг не є чимось новим. Сьогодні ми говоримо про контекст для агентів та LLM, але сама ідея контексту у взаємодії людини й машини з’явилася ще близько 20 років тому (детальніше про історію розвитку підходів та еволюцію контексту можна почитати тут: arxiv.org/pdf/2510.26493).

Цікаво й те, що технологічні прориви часто змушують нас переосмислювати саме поняття контексту. Сьогодні контекстний інжиніринг розглядають як логічне продовження промпт-інжинірингу (www.anthropic.com/...​engineering-for-ai-agents).

Промпт-інжиніринг виник як відповідь на обмеження ранніх LLM. Але з розвитком моделей вплив якості самого промпту на результат поступово зменшується. Натомість з’являються агентні системи, які виконують багатокрокові задачі, використовують інструменти та взаємодіють із зовнішнім світом. Для них одного промпту вже недостатньо — потрібна ціла система управління контекстом.

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

Чому контекст важливіший за промти та RAG

Ще в 2022 ChatGPT став публічним. Користувачі з усього світу почали активно тестувати нову «іграшку». Хтось вже мав досвід роботи з Великими Мовними Моделями, а для когось все це виглядало як чистого роду магія.

Тому одні підходили до тестування, дослідження та покращення системи з наукового й теоретичного боку, а інші — просто як до «чорного ящика». Але обидві групи дійшли однакового висновку:

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

Це підтверджують і дослідження: інформація, яку ми поміщаємо в контекстне вікно моделі, безпосередньо впливає на результати її роботи (arxiv.org/abs/2107.13586).

Саме це й дало поштовх до гонки за збільшенням контекстного вікна. Здавалося, що якість роботи генеративних систем має зростати пропорційно:

більше контексту → кращий результат.

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

Але що станеться, коли контекстне вікно стане настільки великим, що виглядатиме як:

F(необхідний контекст + нерелевантна інформація, запит)?

Як відправну точку можна згадати GPT-1 з контекстним вікном у 512 токенів (cdn.openai.com/...​e_understanding_paper.pdf). Сьогодні ж ми дійшли до моделей на кшталт Gemini 1.5 Pro з контекстним вікном у мільйони токенів.

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

Водночас важливо розуміти: існує фундаментальна різниця між заявленою довжиною контекстного вікна та ефективною довжиною (arxiv.org/pdf/2410.18745).

Наприклад, модель із заявленим контекстом у 200 000 токенів часто починає працювати ненадійно приблизно після 130 000. І замість поступового погіршення якості відбувається різкий обвал.

Цей феномен називають деградацією контексту — коли ефективна довжина становить приблизно 60–70% від заявленої. Причому деградація зазвичай відбувається не поступово: модель зберігає високу якість роботи до певної межі, після чого точність різко падає.

Важливу роль також відіграє розташування інформації в контексті. Дані, розміщені всередині дуже довгого контексту, моделі можуть пригадувати гірше, ніж інформацію на початку або в кінці. Цю проблему називають «lost in the middle».

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

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

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

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

Це явище описують як «загнивання контексту» (context rot): зі збільшенням кількості токенів у контекстному вікні здатність моделі точно пригадувати інформацію знижується (research.trychroma.com/context-rot).

Існує багато методів оптимізації роботи з контекстом. Один із найвідоміших — RAG (Retrieval Augmented Generation). Але це лише один із підходів: контекстний інжиніринг охоплює значно ширшу систему роботи з інформацією.

Необхідний мінімум класичного промптингу

Класичний промптинг усе ще залишається валідним: використовуючи різні техніки, ми можемо покращувати і контекст, і міркування моделі (arxiv.org/pdf/2102.07350). Умовно можна виділити чотири базові підходи:

• Zero-shot prompting — без прикладів і без детального опису формулюємо простий запит (наприклад: «Опиши сонце одним словом.»).
• One-shot prompting — додаємо один приклад, на який модель має орієнтуватися (наприклад «Місяць -> ’Супутник на орбіті’. Тепер, опиши сонце короткою фразою.»).
• Few-shot prompting — додаємо кілька прикладів, щоб модель точніше «зчитала» потрібний стиль/логіку відповіді (наприклад: «Земля → ‘Планета, що підтримує життя.’ Марс → ‘Запилена, червона планета.’ Тепер опиши сонце повним реченням.»).
• Chain-of-Thought (CoT) (arxiv.org/pdf/2305.10601) — формулюємо запит так, щоб модель явно пройшла послідовність міркувань і пояснила шлях до відповіді, а не лише видала фінальний результат (наприклад: «Якщо у мене є 3 яблука і я купую ще 2, скільки у мене буде? Поясни свої міркування.»).

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

CoT — підхід, який зараз активно досліджують і використовують. У пейпері «Reasoning Models Generate Societies of Thought» (arxiv.org/abs/2601.10825) автори показують, що ефективність CoT може бути не стільки в лінійних логічних кроках, скільки в тому, що моделі імітують внутрішню мульти-агентну дискусію. Тобто замість одного прямого «монологу» модель розглядає кілька можливих точок зору, порівнює їх, інколи навіть внутрішньо «сперечається» сама з собою — і вже з цього синтезує відповідь. Це більше схоже на внутрішні дебати, і саме такий режим часто дає кращі результати для складних задач, ніж просто довгий ланцюжок міркувань.

Утім, правильний і достатній контекст — обов’язкова умова для якісної роботи будь-якого з цих підходів. А Chain-of-Thought за наявності багатого контексту інколи й справді продовжує дивувати: замість суто лінійного «крок за кроком» модель переходить до мислення, ближчого до реального — зіставляє альтернативи й перевіряє власні висновки.

Майстер-промпти: перетворення запитів на конфігурації

Майстер-промпт — техніка, з якою мене познайомив Tiago Forte (детальніше: https://www.youtube.com/watch?v=_K_F_icxtrI&t=436s і https://www.youtube.com/watch?v=D9DpUDntQRc). Фундаментальна ідея: щоразу, ставлячи запит LLM, ми передаємо контекст і інструкції. Але часто наші питання стосуються однієї й тієї ж сфери або одного проєкту. Тож чому б не систематизувати цей контекст і набір інструкцій для повторного використання?

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

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

Якщо звести роботу з LLM до простої формули F(необхідний контекст, запит), то необхідний контекст можна представити як суму трьох рівнів:

необхідний контекст = загальний контекст (майстер-промпт) + контекст проєкту + контекст чату.

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

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

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

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

• починати структурно зверху вниз (загальний контекст → контекст проєкту → контекст чату);
• не намагатися зробити систему ідеальною з першого разу — вона змінюється ітеративно;
• поступово переносити повторюваний контекст на вищий рівень (наприклад, якщо інформація часто з’являється в чатах, її варто перенести на рівень проєкту або загального контексту);
• експериментувати з новими підходами до роботи з контекстом і AI-системами загалом.

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

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

Інструкція

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

Саме персональний контекст — те, чого практично немає в тренувальних даних моделей (якщо ви, звісно, не Ілон Маск; якщо ж ви Маск і читаєте це — hello). Тому що більше інформації про вас, тим точніше і персоналізованіше працюватимуть моделі.

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

Я створив промпт, який допомагає зібрати необхідну інформацію і сформувати персональний Master Prompt:
github.com/...​aster-prompt-generator.md

Нижче наведено приклади мого Master Prompt для ChatGPT і Claude.

Частину, що стосується вашої посади, варто розширити: додати опис компанії, деталізувати обов’язки, типові задачі, з якими ви стикаєтесь щодня, і, за потреби, описати людей, з якими ви працюєте. Якщо ви приймаєте рішення на рівні компанії, така інформація стає особливо важливою.

Retrieval (вибірка) як контекстний інжиніринг та інші методи оптимізації контекстного вікна

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

Retrieval (вибірка): що саме варто поміщати в контекстне вікно

Перед тим як оптимізовувати контекстне вікно, варто відповісти на питання: А що ж саме варто поміщати в контекстне вікно?

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

У цьому допомагає парадигма RAG (Retrieval Augmented Generation), вперше описана у 2020 році (arxiv.org/pdf/2005.11401). RAG складається з трьох основних процесів: індексування (Indexing), витяг (Retrieval) та генерація (Generation).

Індексування

Індексування починається з очищення та підготовки сирих даних. Документи у форматах PDF, HTML, Word або інших форматах із багатими текстовими стилями переводяться у звичайний текст.

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

Далі ці чанки кодуються у векторні представлення за допомогою моделі ембеддінгів і зберігаються у векторній базі даних (на схемах це зазвичай позначається як база знань).

Витяг (Retrieval)

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

Це дозволяє обчислити міру схожості між вектором запиту та векторами чанків у базі знань. Після цього система відбирає Top-K чанків із найвищою оцінкою схожості. Саме вони й передаються в контекст для подальшої генерації.

Генерація

На цьому етапі початковий промпт користувача і Top-K чанків, отриманих на попередньому етапі, передаються моделі разом як контекст, на основі якого вона формує відповідь.

Проте цей підхід зіткнувся з низкою проблем.

Наприклад:

• проблеми витягу — у Top-K можуть потрапляти документи, які насправді не є найбільш релевантними;
• проблеми генерації — модель може надавати пріоритет знанням зі свого тренування, а не контексту, який ми передали.

Щоб вирішити ці проблеми, з’явилися Advanced RAG та Modular RAG (arxiv.org/pdf/2312.10997).

Advanced RAG розширює класичну архітектуру двома додатковими процесами:
Pre-Retrieval і Post-Retrieval (pub.towardsai.net/...​ted-overview-04d193d8fec6).

Попередня обробка запиту (Pre-Retrieval) може включати доповнення запиту та редагування, або навіть переписування промпту.

Мета — покращити й уточнити запит користувача, який часто буває неповним або нечітким.

Постобробка (Post-Retrieval) може включати ранжування документів (за релевантністю, новизною тощо), узагальнення великих документів та комбінування схожих фрагментів.

Її завдання — ефективніше інтегрувати релевантну інформацію в контекст запиту.

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

Важливо, також, наголосити — RAG — це не простий пошук, а ключовий механізм інжинірингу контексту. В попередніх розділах я вже згадував про пропорційну залежність якості контексту та якості відповіді (нагадаю: чим вища якість контексту, тим вища якість відповіді). Тут ми можемо ввести ще одну змінну, а саме: якість витягу (retrieval). Тож отримаємо рівняння: «чим вище якість витягу → тим вище якісь контексту → тим вище якість відповіді».

В свою чергу, контекстний інжиніринг, не тільки про те, що ми кладемо в контекст, але й про те, що туди не попадає. І це не побічний ефект якихось з підходів, а саме дизайн рішення. В результаті витягу ми отримуємо Top-K документів, що означає, що K-загальна кількість документів ми просто відкидаємо. К в даному випадку — параметр, який ми власноруч обираємо. Отже тепер ми маємо відповідь на питання ЩО покласти в контекст, зараз будемо намагатися відповісти на питання як оптимальніше це туди покласти.

Методи оптимізації контекстного вікна

В розділі 3 ми вже згадували про проблеми, які можуть виникнути при роботі з контекстом: деградація, «загублено всередині». Для вирішення цих проблем є конкретні підходи:

Стиснення (Compression) — полягає в тому, що не всі токени однаково інформативні, тому для економії простору контекстного вікна їх можна просто видалити. Один із таких методів — LLMLingua (arxiv.org/pdf/2310.05736). Він використовує малі мовні моделі (наприклад GPT-2) для оцінки perplexity — міри того, наскільки токен є несподіваним для моделі та для кожного токена. У результаті токени з низькою інформативністю видаляються, а решта залишається. Це дозволяє отримати стиснення до 20× з мінімальною втратою якості.

Для RAG-архітектур було розроблено розширену версію — LongLLMLingua (arxiv.org/pdf/2310.06839). Вона враховує запит користувача під час стиснення та змінює порядок документів у контексті (що безпосередньо допомагає вирішити проблему «загублено всередині»). Цей підхід дозволяє збільшити точність на 21,4% (у тестах на NaturalQuestions) при використанні у 4 рази меншої кількості токенів.

Бюджетування токенів (Token Budgeting) (aclanthology.org/...​025.findings-acl.1274.pdf) — підхід, при якому ми розглядаємо вікно котекстку як певний бюджет в якому в нас є такі категорії алокації контексту: системний промпт (system prompt), контекст витягу (retrieved context), історія чату (conversation history) та резерв для виходу генерації(output reserve). Розподіл може бути як статичним (коли ми кожній з категорій задаємо певний відсоток від контексту), або динамічним (в залежності від типу запиту розподіл бюджету може сильно відрізнятися). Варто також зважати, що якщо ми в контекст на вхід закладаємо 90%, то на вихід генерації залишиться тільки 10%.

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

Отже, тут ми розібрали: RAG, який відповідає на питання ЩО саме ми маємо поміщати в контекстне вікно, та методи оптимізації, які відповідають на питання СКІЛЬКИ і ДЕ це розміщувати. Разом вони формують основу роботи з контекстом.

Агентні воркфлоу: контекст як оркестрація

Агенти як розподіл контексту

До цього моменту ми говорили про інженерію контексту для одного виклику моделі. Але з появою агентів (кожен з яких має свій системний промпт, свій контекст і свої інструменти) та мультиагентних систем (arxiv.org/pdf/2402.01680) контекстна інженерія набула нового сенсу — оркестрації руху інформації між агентами, як між вузлами складної системи.

Ефективність мультиагентних систем зумовлена саме розподілом і якісною роботою з контекстом, а не лише розподілом задач. І головне, на що тут варто звертати увагу → ізоляція контексту (context isolation). Саме такий підхід, який визначає, що саме агент не бачить, дозволяє боротися з проблемами витоку контексту (context leakage) та перехресного забруднення (context cross-contamination).

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

Self-RAG (arxiv.org/pdf/2310.11511) — модель генерує спеціальні токени самоаналізу (reflection) під час роботи. Іншими словами, вона сама вирішує: чи достатньо внутрішніх знань, чи потрібен зовнішній контекст. Якщо ж якийсь із документів, отриманих після витягу, виявляється нерелевантним, агент може просто його відкинути. Якщо раніше витяг був обов’язковим кроком, то з агентами він перетворюється на свідоме рішення системи — робити витяг чи ні.

CRAG (arxiv.org/pdf/2401.15884) — підхід, спрямований на зменшення галюцинацій моделі через перевірку документів, отриманих у результаті вибірки. Перед тим як додати документ до контексту, невелика модель оцінює його якість:

• документ коректний (тоді його можна використовувати);
• документ некоректний (тоді можна запустити онлайн пошук й використати результат як документ);
• документ неоднозначний (тоді нерелевантні частини можна відкинути, залишивши тільки корисне).

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

MCP — стандартизація контексту

Агенти можуть отримувати контекст із будь-яких джерел: баз даних, API, файлових систем, зовнішніх сервісів. Якщо ж врахувати, що різні моделі можуть мати різні механізми інтеграції, виникає проблема: існує N моделей і M джерел інформації, а отже потрібно N × M кастомних інтеграцій.

Саме для вирішення цієї проблеми наприкінці 2024 року компанія Anthropic представила MCP (Model Context Protocol) (www.anthropic.com/...​ws/model-context-protocol).

MCP — це відкритий протокол для стандартизованої інтеграції мовних моделей із зовнішніми джерелами інформації.

Протокол організовує взаємодію між трьома компонентами:

• Хостом — застосунком на основі мовних моделей, який ініціює з’єднання;
• Клієнтом — з’єднувальними блоками всередині хост-застосунку;
• Сервером — зовнішнім сервісом, який надає контекст.

Сервер може надавати клієнту:

• ресурси — дані або контекст;
• промпти — шаблони повідомлень;
• інструменти — функції, які може використовувати AI-модель.

Водночас сервер може запитувати у клієнта:

• sampling — генерацію відповіді від моделі (саме це робить MCP двонаправленим протоколом).

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

На сьогодні цей протокол підтримують OpenAI, Google, Microsoft та AWS, а у грудні 2025 року він був переданий до Linux Foundation (www.anthropic.com/...​the-agentic-ai-foundation).

Контекст виконання: Інструменти, функції та схеми

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

Виклик функцій — як контекстний механізм

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

Модель, насправді, не потребує дуже детального опису кожного інструмента, його повної функціональності, усіх способів використання чи великих інструкцій про те, коли саме ці інструменти потрібно застосовувати. Пейпер «Toolformer» (arxiv.org/pdf/2302.04761) показує, що навіть із простим описом API мовна модель може навчитися визначати, які API викликати, коли це робити, які аргументи передавати та як використовувати результати виклику інструментів для подальшої генерації.

Опис інструментів радше належить до промпт-інжинірингу — те, як саме ми опишемо функцію, визначатиме якість її виклику. Якщо опис зроблено погано, виклики API можуть почати галюцинувати (arxiv.org/pdf/2305.15334).

Варто звернути увагу на: чіткий опис призначення інструмента; типізовані параметри; приклади вхідних значень; явні обмеження на використання.

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

Тому коли ми працюємо з тисячами API, вибір правильного інструмента стає окремим завданням (arxiv.org/pdf/2307.16789). По суті, це та сама задача, що й вибірка в RAG-системах — із великого набору інформації потрібно обрати релевантне.

Тобто передати моделі саме ті інструменти, які потрібні в конкретний момент.

Структурований вивід: контекстний інжиніринг на виході

Під час інтеграції мовних моделей в існуючі системи часто виникає питання: як обробляти вивід моделі?

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

Втім, у такого підходу є і недоліки. Основний — просідання якості роботи моделі (arxiv.org/pdf/2408.02442). Тобто обмеження формату виходу може знижувати якість міркування (reasoning), і чим жорсткіші ці обмеження, тим сильніше це помітно.

Існують два підходи, які дозволяють гарантувати формат відповіді: декодування з обмеженням та валідація виходу.

При декодуванні з обмеженням модель може генерувати лише ті токени, які відповідають заданому регулярному виразу або FSM (finite state machine) (arxiv.org/pdf/2307.09702).

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

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

Тестування, налагодження та спостережуваність (Observability) контексту

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

Тестування контексту (Evals)

Коли ми вносимо зміни до промту, чи до контексту — як оцінити вплив цієї зміни на роботу системи? Можна це робити власноруч, але краще буде використати автоматизовані тести для LLM (Evals). Класичний підхід Unit тестування тут не буде доречним, адже вихід моделі не детермінований (тобто на однакових вхідних даних мовна модель видаватиме різний вихід). Регулярні вирази допоможуть тільки в якихось крайніх випадках (якщо в нас задача класифікації і нам важливо, щоб модель десь на виході вивела один з цих класів). В реальних же задачах нам потрібні більш детальні й стабільні метрики, як от: faithfulness, relevance, context precision/recall).

Ragas (arxiv.org/pdf/2309.15217) показує, як такі метрики можна перекласти на RAG системи, а також, умовно розділяє тестування на дві площини — якість витягу («Чи ті документи ми надали?») та якість генерації («Чи правильно було використано наданий контекст?»). Підхід LLM-як-Суддя (arxiv.org/pdf/2311.09476) допомагає «побороти» недетермінованість мовних моделей при тестуванні. Ідея така — навіщо нам створювати якісь жорсткі правила для оцінки (які очікують детермінований вхід), якщо в нас є мовна модель, яка чудово працює з недетермінованим входом. Навчивши мовну модель на синтетичному наборі даних, її можна досить успішно використовувати як «Суддю», який оцінюватиме роботу іншої мовної моделі.

Налагодження та спостережуваність контексту

Часи, коли модель була основним bottleneck точності роботи AI системи минули — зараз же шальки терезів нахилені в сторону контексту. Якщо ваша модель працює незадовільно, то скоріш за все це про проблеми з контекстом. Щоб розібрати, що ж пішло не так з контекстом допомагає Tracing. Відслідкувавши повний шлях (від запиту, через витяг, виклики інструментів і до фінальної відповіді) можна перевіряти «правильність» кожного з кроків. Що важливо моніторити: скільки токенів було використано на кожному з кроків, які інструменти викликаються, як документи потрапили в вікно, як розташована релевантна інформація у вікні. Кілька інструментів, які виконують ці завдання: LangSmith (www.langchain.com/langsmith/evaluation), LangFuse (langfuse.com/?tab=annotations) — дозволяють відслідковувати комплексні LLM пайплайни, Brainrust (www.braintrust.dev) observability платформа. LangFuse моя персональна рекомендація — одна платформа покриває всі потреби тестування, дебагу, спостереження.

Дорожня карта практичного впровадження

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

З чого почати

Я пропоную Maturity Model, яка допоможе зрозуміти, на якому рівні майстерності контекстного інжинірингу ви перебуваєте і як зробити level-up.

Рівень 0: ви пишете одноразові запити в модель.

Рівень 1: ви не просто пишете запити в модель, а перевикористовуєте та структуруєте промпти.

Рівень 2: ви використовуєте витяг (retrieval) — тепер у вас є не тільки система промптів, а й корисний контекст.

Рівень 3: ви інтегруєте інструменти, використовуєте схеми — тут ви вже справді розширюєте можливості одного агента.

Рівень 4: ви використовуєте мультиагентні системи, розділяєте і керуєте контекстом — тут ваші можливості вже не обмежуються одним агентом.

Рівень 5: ви тестуєте, моніторите та дебажите контекст — тут з’являються evals і observability-інструменти.

Кожен наступний рівень спирається на попередній.

Практичні принципи

Визначивши, на якому рівні ви знаходитеся, скористайтеся кількома принципами, які допоможуть зробити level-up:

• приділяйте більше уваги контексту, а не вибору моделі;
• концентруйтеся на якості контексту, а не на його кількості — кожен зайвий токен може додати шум;
• коли покращуєте контекст, використовуйте evals;
• плануйте бюджет контексту заздалегідь;
• документація, документація, документація — фіксуйте, що і чому ви включили або виключили з контексту.

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

Висновок

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

Контекстна інженерія — це обширна і комплексна дисципліна, яка не обмежується тільки набором інструментів. «Інженерія» тут не просто метафора, адже як і в розробці програмного забезпечення, використовуються схожі практики: тестування, версіонування, моніторинг, архітектурні рішення. Моделі змінюються кожного дня, анонсують щось «революційне» — гонка за кращу модель триває і вдень і вночі, але принципи роботи з контекстом залишаються. Саме це робить контекстну інженерія навичкою не прив’язаною до конкретної моделі чи провайдера. Стандартизація (MCP), автоматизація Evals, розширення можливостей інструментів — тренди, які формують дисципліну саме зараз. Визначте свій рівень в Maturity Model і почніть покращуватися.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.