У меня был промпт на 40 строк. Системный промпт для контент-генератора: роль, стиль, ограничения, примеры. Работал нормально. Иногда. А иногда модель игнорировала половину инструкций, выдумывала факты и писала текст, который я бы никогда не опубликовал. Я переписывал промпт, добавлял «ВАЖНО:», выделял капсом, и результат менялся процентов на десять. Контекст инжиниринг начался для меня с простого осознания: проблема не в промпте. Проблема в том, что промпт — это только один слой из пяти.
Летом 2025-го Тоби Лютке (CEO Shopify) написал в Твиттере: «prompt engineering is dead, context engineering is here.» Андрей Карпати подхватил аналогию: LLM это процессор, контекстное окно — оперативная память, а контекст инжиниринг — управление этой памятью. Gartner в июле 2025-го выпустил отчёт со словами «context engineering is in, prompt engineering is out.» Звучит как хайп. Но на практике разница реальная, и я это проверил.
Что такое контекст инжиниринг и почему промпт — это не строка
Контекстная инженерия — это проектирование системы, которая даёт модели правильную информацию, в правильном формате, в правильное время. Определение Филиппа Шмида из Hugging Face, и оно точное. Ключевое слово тут «система». Не одна строка текста, а набор компонентов, которые работают вместе.
Промпт-инжиниринг — это «как написать хороший запрос». Контекст инжиниринг — это «как спроектировать всё окружение, в котором модель принимает решения». Разница примерно как между «написать хорошее ТЗ» и «выстроить процесс в команде». ТЗ важно, но без процесса оно не спасёт. Мне потребовалось полгода работы с моим контент-генератором, чтобы это дошло.
В исследовании Microsoft по AI-агентам показали: правильный контекст инжиниринг даёт +26% завершённых задач и минус 65% ошибок. Не потому что промпт стал длиннее, а потому что модель получает нужную информацию, когда она ей нужна.
Из чего состоит контекст: 5 слоёв системного промпта
Филипп Шмид выделяет семь компонентов контекста. Я сгруппировал их в пять слоёв — так проще думать на практике.
Первый слой, инструкции, это то, что большинство людей считают «промптом». Системный промпт: роль, стиль, ограничения, формат ответа. Как правильно составить системный промпт? Коротко: роль + задача + формат + ограничения. Длинно зависит от задачи. Для моего контент-генератора системный промпт занимает 200 строк. И это нормально.
Второй — знания. RAG, документы, базы знаний. Всё, что модель не знает из обучения, но должна знать для конкретной задачи. Я подгружаю опубликованные статьи, стилевые гайды, антипаттерны. Без этого слоя модель выдумывает факты. С ним — ссылается на конкретные источники.
Третий слой — память. История диалога, долговременная память, заметки из прошлых сессий. Тут есть классный пример: агент Manus перезаписывает todo.md файл после каждого шага, и модель «помнит», что уже сделано и что осталось. Простая манипуляция вниманием, а работает.
Четвёртый — инструменты. Описания функций, которые модель может вызвать: поиск в интернете, запись в базу данных, генерация картинок, вызов API. Модель не просто генерирует текст, она решает, какой инструмент использовать и когда. Я разбирал, как это работает на практике, в посте про gstack и AI-агенты в Claude Code, где skills и slash-команды формируют контекст агента.
И пятый — формат вывода. JSON-схема, XML-шаблон, markdown-структура. То, что задаёт форму ответа. Про XML-структуры в промптах я писал отдельно, и честно, это один из самых недооценённых приёмов контекстной инженерии.
Инфо
Что входит в контекст LLM кроме промпта? Всё перечисленное: RAG-документы, история диалога, описания инструментов, формат вывода, долговременная память. Промпт — только первый слой из пяти.
Промпт-инжиниринг vs контекст-инжиниринг: разница на практике
Покажу на примере. Задача: AI-ассистент для техподдержки.
Промпт-инжиниринг: «Ты — оператор техподдержки. Отвечай вежливо и по делу. Если не знаешь ответ — скажи, что передашь вопрос специалисту.»
Модель отвечает вежливо. Иногда по делу. Часто выдумывает ответы, потому что не знает ваш продукт. Не помнит, что клиент написал вчера. Не может проверить статус заказа.
Контекст-инжиниринг: системный промпт + RAG с базой знаний продукта + история переписки с клиентом + инструменты (проверка заказа, создание тикета) + JSON-формат ответа для фронтенда.
Та же модель, тот же API. Результат другой. Модель не выдумывает, а ищет ответ в базе. Помнит контекст. Может сама проверить статус заказа и ответить в формате, который фронтенд распарсит.
Промпт-инжиниринг не умер. Он стал одним слоем из пяти. Как HTML не умер с появлением фронтенд-фреймворков, он просто перестал быть единственным, о чём надо думать.
Почему контекст LLM ломается: 4 паттерна отказа
Дрю Бройниг описал четыре способа, которыми контекст портит результат. Я с каждым сталкивался.
Context Poisoning — в контексте есть неверная информация, и модель ей верит. У меня это было, когда в RAG попал устаревший гайд. Модель уверенно советовала API-endpoint, который удалили два месяца назад. Причём советовала с полной уверенностью, со ссылками и примерами кода.
Второй паттерн, Context Distraction, коварнее. Слишком много информации. Модель «тонет» в контексте. Chroma называет это context rot: производительность деградирует с ростом контекста не обрывом, а градиентом. Добавляешь документы, качество падает по чуть-чуть, пока не замечаешь, что ответы стали заметно хуже. Бесит, потому что ты ведь вроде бы помогаешь модели, даёшь ей больше данных. А на деле мешаешь.
Context Confusion — это когда инструкции противоречат друг другу. Системный промпт говорит одно, документ из RAG — другое. Модель выбирает случайно. А Context Clash проще всего: контекст из разных задач смешивается в одном окне. Типичная история длинных диалогов, когда ты забыл начать новый чат.
Внимание
Больше контекста не всегда лучше. Кэшированные токены в Claude стоят $0.30 за миллион, некэшированные $3.00. Разница в 10 раз. Но даже не в деньгах дело: лишний контекст снижает качество ответов. LangChain выделяет четыре стратегии управления: Write (сохранить за пределами окна), Select (подтянуть нужное), Compress (сжать), Isolate (разделить между агентами). Не всё нужно запихивать в один запрос.
Чеклист: переводим промпт из строки в систему
Вот что я делаю с каждым промптом, который использую больше одного раза.
1. Отделить инструкции от знаний. Роль и правила идут в системный промпт. Факты, документы, примеры — в отдельный блок. Не мешать в кучу. Это самый простой шаг и самый заметный по эффекту.
2. Добавить формат вывода. Если результат идёт в код или другую систему, задайте JSON/XML-схему. Если для человека — задайте структуру: заголовки, длину, стиль.
3. Подключить память. Хотя бы историю диалога. В идеале — долговременную память между сессиями. Даже простой лог «что уже обсуждали» меняет качество ответов.
4. Описать инструменты, если модель должна что-то делать кроме генерации текста. Поиск, API-вызовы, запись в файл, работа с базой данных.
5. Почистить. Убрать устаревшее. Убрать дублирование. Убрать то, что модель и так знает. Если инструкция не влияет на результат, она только мешает.
Не обязательно делать все пять за один подход. Начните с первого, разделите инструкции и знания. Уже это даёт заметную разницу.
Совет
Практический тест: если ваш промпт длиннее 20 строк и всё лежит в одном блоке, пора разделять. Вынесите факты в отдельный раздел, добавьте формат вывода, опишите ограничения отдельно от роли. Один промпт — не одна строка, а пять блоков с разной функцией.
Когда контекстной инженерии недостаточно
Контекст инжиниринг решает большинство задач. Но не все. Если модель упорно не понимает вашу терминологию, путает специфичные паттерны или не держит стиль после сотен примеров в контексте, возможно, нужен fine-tuning. Я разбирал дообучение модели под свои задачи через Unsloth — это следующий шаг, когда контекста объективно не хватает. Но в 90% случаев проблема не в модели, а в том, что ей подали.
Промпт-инжиниринг техники 2026 года — это уже не про «напиши хороший промпт». Это про систему. Про пять слоёв, каждый из которых делает свою работу. Контекст-инженеры не заменят промпт-инженеров, они и есть промпт-инженеры, которые перестали думать строками и начали думать системами.
Откройте свой последний промпт. Посмотрите: там одна каша или пять разделённых блоков? Если каша, берите чеклист выше. Мне хватило вечера, чтобы перестроить свой основной промпт, и разница в качестве ответов была видна сразу.
