Инженерия контекста: чем она заменила инженерию промптов
Долгое время «работать с ИИ» означало одно: удачно сформулировать промпт. В 2025-2026 этого уже недостаточно. Модели ходят в tools, тянут документы через RAG, держат память сессии и работают в связках агентов. Решает не красота формулировки, а инженерия контекста - дисциплина, которая проектирует, что именно модель видит на каждом шаге: инструкции, факты, историю, права и ограничения. Ниже - чем она заменила классическую инженерию промптов и как внедрять подход в продуктах и внутренних процессах.
- Промпт - текст инструкции; контекст - весь вход модели на шаге
- Сдвиг - от «придумай магическую фразу» к «собери правильный пакет данных»
- Слои - system, retrieval, память, tools, состояние задачи, политики
- Цель - стабильность, меньше галлюцинаций, контроль стоимости токенов
- Практика - узкий релевантный контекст лучше «всё подряд в окно»
- Для бизнеса - процесс и архитектура важнее одного удачного чата в ChatGPT
Что такое инженерия промптов - и где она упёрлась
Инженерия промптов (prompt engineering) - умение формулировать запросы к LLM так, чтобы получить нужный стиль, формат и поведение: роли («ты старший аналитик»), few-shot примеры, chain-of-thought, жёсткие шаблоны ответа.
Она отлично работает для:
- разовых задач в чате;
- генерации черновиков;
- обучения команды «как спрашивать у модели»;
- прототипов без доступа к внутренним данным.
Предел виден быстро:
| Ситуация | Почему одного промпта мало |
|---|---|
| Нужны актуальные цены и регламенты | Модель не знает ваш прайс без retrieval |
| Длинный диалог / агент с tools | Окно забивается шумом, фокус теряется |
| Несколько ролей и систем | Один «универсальный» system prompt размывается |
| Контроль риска и compliance | Политики и маскирование данных - не «красивая фраза» |
| Стоимость API | Лишние токены в каждом ходе = прямой убыток |
Промпт остаётся частью системы. Но он перестал быть главным рычагом качества.
Что такое инженерия контекста
Инженерия контекста (context engineering) - проектирование полного входного пакета для модели на каждом вызове: что положить в system, что подтянуть из базы, что взять из памяти, какие tool-результаты показать, что выкинуть и что запретить.
Если промпт - это «как попросить», то контекст - это «в каком информационном окружении модель отвечает».
Типичные слои контекста:
- Инструкции и роль - системный промпт, политику ответа, формат JSON/Markdown.
- Задача пользователя - текущий запрос и минимально нужная история.
- Retrieved knowledge - фрагменты из wiki, CRM, кода, FAQ через поиск/RAG.
- Состояние - этап воронки, id сделки, версия документа, результат прошлого шага.
- Tool observations - ответы API, SQL, браузера, MCP-инструментов.
- Ограничения - «не обещай скидку», «не цитируй PII», «эскалируй человеку».
Инженер контекста думает как проектировщик пайплайна, а не как копирайтер удачных формулировок.
Чем контекст заменил «магию промпта»
| Было (фокус на промпте) | Стало (фокус на контексте) |
|---|---|
| Длинный system prompt «на все случаи» | Узкий prompt + динамическая сборка входа |
| Вставить PDF целиком в чат | Retrieval: только релевантные чанки |
| «Помни всё из диалога» | Сжатие, суммаризация, выборочная память |
| Одна модель - один чат | Агенты, оркестратор + субагенты, разные окна |
| Качество = искусство формулировки | Качество = релевантность, свежесть, порядок слоёв |
| Отладка текста промпта | Отладка источника: retrieval miss, tool fail, overflow |
Смена парадигмы не означает, что промпты «умерли». Они стали одним слоем рядом с retrieval, памятью, tools и политиками - как SQL-запрос рядом со схемой БД и индексами.
Почему сдвиг ускорился в 2025-2026
Несколько факторов совпали:
- Агенты и tools - модель действует, а не только отвечает текстом; контекст должен включать результаты инструментов.
- Длинные окна - можно положить больше, но «больше» без отбора = шум и дороже.
- Корпоративные данные - без RAG и контроля версий документов ответы бесполезны для бизнеса.
- Мультиагентность - каждому субагенту нужен свой узкий бриф, а не общий лог.
- Стоимость и задержка - инженер контекста оптимизирует token budget так же, как бэкенд-оптимизирует payload.
Поэтому вакансии и практики сместились: от «prompt engineer» к platform/ML eng и product, которые собирают контекстные конвейеры.
Практика: как собрать контекст на одном шаге
Рабочий чек-лист перед вызовом LLM:
- Цель шага - что должно получиться на выходе (JSON, решение, черновик).
- Минимум инструкций - без дублирования того, что уже в инструментах и данных.
- Retrieval - top-k фрагментов с метаданными (источник, дата, версия).
- История - только релевантные реплики или краткое summary, не весь тред.
- Tool-выходы - сырые, но усечённые; без секретов и лишних полей.
- Бюджет токенов - жёсткий лимит; при overflow - приоритет: инструкция → задача → facts → история.
- Политики - что модель не имеет права утверждать без человека.
Пример для поддержки:
[system] роль + запреты + формат
[retrieved] 3 чанка из базы знаний (с датой)
[state] номер тикета, тариф клиента, язык
[user] текущий вопрос
Не так:
[system] 4 страницы «будь полезным...»
[history] 80 сообщений целиком
[files] весь Notion-пространством
[user] вопрос
Контекст vs промпт: что править при плохом ответе
| Симптом | Часто чинят промптом | Часто чинят контекстом |
|---|---|---|
| Не тот тон / формат | Да: уточнить инструкцию | Редко |
| Выдуманные факты | «Не выдумывай» помогает слабо | Retrieval + запрет отвечать без источника |
| Устарело | Добавить дату в prompt | Версии документов и фильтр по актуальности |
| Модель «забыла» задачу | Повторить в конце | Держать goal/state отдельным блоком |
| Дорого и медленно | Сократить вежливость | Урезать историю и шум retrieval |
| Опасное действие | «Будь осторожен» | Убрать tool / требовать human-in-the-loop |
Правило отладки: сначала данные и отбор, потом формулировки.
Что это значит для бизнеса
Если вы внедряете ИИ в CRM, поддержку, внутренний поиск или код-агентов:
- Бюджет уходит не на «курс промпт-инженерии для менеджеров», а на качество корпуса, индексацию, логирование и политики доступа.
- KPI качества: hit-rate retrieval, доля ответов «с источником», стоимость на сценарий, эскалации человеку.
- Промпт-плейбуки всё ещё полезны сотрудникам для ручных чатов - но product-grade ИИ строится как конвейер контекста.
- Выбор между длинным контекстом, RAG и fine-tuning - отдельное архитектурное решение; см. разбор вариантов.
Для собственника короткий тест зрелости: можно ли объяснить, из каких источников модель собрала ответ на вчерашний кейс клиента. Если нет - у вас пока инженерия промптов в чате, а не инженерия контекста в системе.
Частые ошибки
- Скармливать модели «всё, что есть» в надежде на длинное окно.
- Держать один гигантский system prompt вместо динамической сборки.
- Не версионировать документы в RAG - уверенные, но устаревшие ответы.
- Передавать субагенту полный лог оркестратора вместо краткого брифа.
- Прятать секреты и PII в контексте «потому что модели так удобнее».
- Путать улучшение формулировки с исправлением дыры в данных.
Итог
Инженерия промптов научила нас разговаривать с моделями. Инженерия контекста научила строить системы, где модель получает ровно ту информацию, инструменты и ограничения, которые нужны для шага - не больше и не меньше. В 2026 году качество корпоративного ИИ определяется не «волшебной фразой», а конвейером: отбор фактов, память, tools, политики и бюджет токенов. Промпт остаётся частью этого конвейера - но больше не главный герой.
Часто задаваемые вопросы
Чем инженерия контекста отличается от инженерии промптов?
Инженерия промптов фокусируется на тексте инструкции. Инженерия контекста - на всём входе модели: инструкции + retrieved-факты + история + состояние + результаты tools + запреты. Промпт - слой; контекст - система сборки этого слоя и остальных.
Нужен ли ещё prompt engineering в 2026 году?
Да, как навык и как слой. Чёткие инструкции, форматы и few-shot по-прежнему важны. Но для продуктов и агентов без отбора данных, памяти и политик один «идеальный промпт» не стабилизирует качество.
Это то же самое, что RAG?
Нет, шире. RAG - один из способов наполнить контекст знаниями из корпуса. Контекст также включает память диалога, state workflow, tool-выходы, роли и safety-политики. RAG - типичный и важный компонент, но не вся дисциплина.
С чего начать внедрение в компании?
Выберите один сценарий (поддержка, поиск по регламентам, ассистент менеджера). Зафиксируйте источники правды, сделайте retrieval с датами версий, сократите историю до summary, добавьте логи «что положили в контекст». Промпт доработайте после того, как данные перестанут врать.
Как понять, что проблема в контексте, а не в модели?
Если смена модели (GPT → Claude → Gemini) почти не меняет ошибку, а замена документа / top-k / обрезка истории - меняет, проблема в сборке входа. Менять провайдера имеет смысл после того, как контекстный конвейер прозрачен и измеряем.