Контекст-инжиниринг заменил промпт-инжиниринг

В 2023 году в вакансиях мелькала должность «prompt engineer» с зарплатой до 300 тысяч долларов в год — люди учились подбирать формулировки, чтобы GPT-3.5 или GPT-4 выдавали нужный результат. К концу 2024-го и в 2025-м акцент сместился: инженеры Anthropic и OpenAI, а также авторы популярных фреймворков вроде LangChain, всё чаще говорят не о промптах, а о контекст-инжиниринге — проектировании всего, что модель видит в контекстном окне на момент генерации ответа. Промпт остался частью этой работы, но перестал быть главной.

Причина проста: одиночная удачная формулировка не масштабируется на приложение, которое обрабатывает документы, ходит в базы данных и держит диалог из десятков реплик. Там побеждает не тот, кто красиво спросил, а тот, кто грамотно собрал контекст.

Что случилось с промпт-инжинирингом

Промпт-инжиниринг решал одну задачу: как сформулировать запрос, чтобы модель поняла его правильно. Приёмы вроде «think step by step», ролевых установок («ты опытный юрист») и few-shot-примеров реально повышали качество ответов на слабых моделях.

Две вещи подорвали эту дисциплину. Первая — модели поумнели: свежие версии GPT, Claude и Gemini понимают задачу без ритуальных заклинаний, а некоторые reasoning-модели вообще хуже работают, когда им навязывают пошаговость вручную. Вторая — приложения усложнились. Реальный продукт на LLM* редко отправляет модели один статичный текст. Он собирает запрос из системной инструкции, истории диалога, результатов поиска, данных пользователя и описаний инструментов. Формулировка одного абзаца тут — капля в море.

Контекст-инжиниринг: определение по делу

Контекст-инжиниринг — это дисциплина о том, что именно и в каком порядке попадает в контекстное окно** модели к моменту ответа, и как этим управлять на протяжении всей сессии. Термин популяризировали в 2025 году, среди прочих — Andrej Karpathy и команда Anthropic, описывая работу агентов.

Ключевая идея: контекст — это ограниченный и дорогой ресурс. Даже если окно вмещает 200 тысяч токенов, набивать его всем подряд вредно. Модель хуже находит нужное в длинном шумном контексте (эффект «потерянного в середине»), а каждый токен стоит денег и времени.

Промпт — это то, что вы говорите модели один раз. Контекст — это всё, что модель держит в голове, пока работает над вашей задачей. Управлять вторым сложнее и важнее.

Из чего состоит работа с контекстом

Практика свелась к нескольким повторяющимся приёмам, вокруг которых и строятся современные фреймворки:

• Отбор (retrieval). Подтягивать в контекст только релевантные куски документов через RAG***, а не весь корпус.
• Сжатие. Суммаризировать старую часть диалога, чтобы не тащить всю историю дословно.
• Изоляция. Разбивать задачу между несколькими агентами, у каждого — свой узкий контекст, чтобы окна не засорялись чужими данными.
• Порядок и структура. Класть инструкции и самое важное ближе к началу и концу окна, размечать блоки тегами или разделителями.
• Управление памятью. Выносить долгосрочные факты во внешнее хранилище и подгружать их выборочно, а не держать всё в окне.

Показательна открытая оценка Anthropic: в их разборах агентных систем большая часть ошибок приходилась не на «неправильный промпт», а на то, что агент получал слишком много или не тот контекст. Точные проценты зависят от конкретной системы, поэтому за цифрами стоит идти в первоисточник, а не верить круглым числам из пересказов.

Промпт-инжиниринг против контекст-инжиниринга

Важно: контекст-инжиниринг не отменяет промпт, а поглощает его. Хорошая системная инструкция по-прежнему нужна — просто теперь это один из нескольких компонентов, а не вся работа.

Кому это пригодится и кому нет

Пригодится:

• Разработчикам, которые строят агентов и чат-ботов поверх API моделей: без управления контекстом система деградирует уже на десятой-двадцатой реплике диалога.
• Командам, делающим поиск по внутренней документации (RAG-приложения): здесь качество ответа на 80% определяется тем, какие фрагменты вы подложили в контекст, а не формулировкой.
• Тем, кто считает деньги: сжатие и отбор контекста напрямую режут расходы на токены, особенно на дорогих reasoning-моделях.

Не пригодится (или не в первую очередь):

• Обычному пользователю ChatGPT или Claude в браузере — для разовых задач достаточно понятно сформулировать запрос.
• Тем, у кого простой сценарий «один вопрос — один ответ» без внешних данных и длинной истории.
• Авторам коротких текстов и картинок: там по-прежнему рулит формулировка, а не архитектура контекста.

Что делать разработчику прямо сейчас

1. Посмотрите, из чего реально собирается запрос к модели в вашем приложении. Часто там дублируется история и висит мёртвый груз, который никто не чистит.
2. Добавьте суммаризацию старой части диалога вместо того, чтобы отправлять всю историю дословно.
3. Если тянете документы — измеряйте, насколько релевантны подобранные фрагменты, а не только качество финального ответа.
4. Проверьте порядок блоков: инструкции и критичные данные лучше держать в начале и в конце окна.
5. Для сложных задач подумайте о разбиении на несколько агентов с раздельными контекстами вместо одного раздутого промпта.

* LLM (large language model) — большая языковая модель, например GPT, Claude или Gemini.

** Контекстное окно — максимальный объём текста (в токенах), который модель способна учитывать за один вызов. Всё, что в него не поместилось, модель не видит.

*** RAG (retrieval-augmented generation) — подход, при котором перед ответом система ищет релевантные документы и подкладывает их в контекст модели.