Метод Карпаті: чому контекст — це RAM
Андрій Карпаті — співзасновник OpenAI та людина, що популяризувала «vibe coding» — запропонував аналогію, яка змінює те, як ми працюємо з AI: мовна модель — це процесор, а контекстне вікно — оперативна пам'ять. Звідси випливає ціла дисципліна «context engineering» і практичні правила, як не палити токени даремно.
LLM — це CPU, а контекст — RAM
Карпаті описує сучасні мовні моделі як новий тип операційної системи. У цій аналогії:
- Модель (ваги) — це процесор і «вшита» назавжди памʼять (ROM): незмінне ядро, отримане під час навчання.
- Контекстне вікно — це оперативна памʼять (RAM): робочий простір, обмежений і «дорогий».
- Файли, бази, історія, документи — це диск: величезне сховище, пасивне, доки ви явно не завантажите потрібне в RAM.
Чому RAM не можна забивати «про запас»
Інтуїція підказує: дам моделі більше контексту — отримаю кращу відповідь. Насправді навпаки.
- Якість важливіша за обсяг. Більше токенів ≠ розумніша відповідь.
- Контекст деградує з наповненням. За дослідженням Chroma (2025) усі 18 перевірених фронтир-моделей втрачають точність поступово — з першого токена, а не лише на межі ліміту.
Чотири споживачі оперативної памʼяті
На кожному кроці в контекст потрапляють чотири категорії, що конкурують за місце в «RAM». Розуміння цього — половина справи:
- Інструкції — системні правила, памʼять, описи інструментів.
- Історія діалогу — усі попередні репліки сесії.
- Вивід інструментів — відповіді сервісів, результати команд, JSON.
- Підвантажені дані — файли, документи, фрагменти з пошуку.
Як це застосувати на практиці
Метод Карпаті — це не теорія, а набір звичок під час роботи з AI-агентами:
- Тонкі інструкції. У постійних правилах — лише суть і навігація; деталі тримайте у файлах, які агент читає за потреби.
- Керування історією. Нову незвʼязану задачу починайте з чистого контексту; довгу тему перед продовженням стискайте у короткий підсумок.
- Точкові запити до інструментів. Просіть конкретне з фільтрами, а не «вивантаж усе» — інакше дамп даних забиває памʼять.
- Диск замість RAM. Стан і знання — у файли; великий документ не вставляйте цілком, діставайте лише релевантні фрагменти (RAG / семантичний пошук).
- Ізоляція важких підзадач. Масивний ресерч чи обробку делегуйте окремому контексту, а в головний повертайте лише підсумок.
Context engineering проти промпт-інженерії
Чи означає це, що промпти більше не потрібні? Ні. Промпт-інженерія — це «що ви кажете» моделі. Context engineering — це «все інше, що бачить модель»: памʼять, приклади, дані з інструментів, історія, стан.
У парадигмі Карпаті (він називає її Software 3.0) промптинг — це фактично програмування, а контекст — памʼять, у якій виконується ваша «програма». Хто навчиться керувати цією памʼяттю, той отримує дешевших, швидших і точніших агентів.
Часті питання
Це дисципліна керування тим, що потрапляє в контекстне вікно моделі. За аналогією Карпаті, контекст — це оперативна памʼять (RAM), і завдання інженера — завантажити в неї саме те, що потрібно для наступного кроку, без зайвого.
Бо якість контексту важливіша за обсяг, а точність моделі падає в міру наповнення вікна — за даними Chroma (2025), з першого токена. Переповнений контекст дає гірші відповіді й коштує більше токенів.
Промпт-інженерія — це формулювання конкретного запиту («що ви кажете»). Context engineering ширша: вона керує всім, що бачить модель — памʼяттю, прикладами, даними з інструментів, історією та станом.
Контекст — це RAM. Завантажуйте в нього лише потрібне.
Якість контексту важливіша за обсяг: менше зайвого — точніші, швидші й дешевші відповіді AI.