Простыми словами
Context engineering - это умение правильно собрать все, что модель увидит перед ответом: инструкцию, вопрос пользователя, документы, историю диалога, данные из CRM, результаты инструментов, память агента и формат ответа.
Если prompt engineering отвечает за формулировку инструкции, то context engineering отвечает за рабочий стол модели. Что мы положили на этот стол, в каком порядке, что убрали, что сократили и что явно пометили как данные, а не как команду.
Хороший контекст помогает модели отвечать точнее. Плохой контекст путает даже сильную модель: она может опереться не на тот документ, забыть важное условие, смешать старую историю с новой задачей или уверенно ответить по неполным данным.
Почему одного промпта мало
Можно написать отличный системный промпт: “отвечай точно, используй только документы, не выдумывай”. Но если в контекст не попал нужный документ, модель все равно не узнает правильный ответ.
И наоборот: если в контекст положить пять похожих документов, устаревший регламент, длинную историю переписки и сырой JSON из CRM, модель может потеряться. Промпт будет хорошим, а вход для модели - шумным.
Поэтому качество AI-системы часто зависит не от одной красивой инструкции, а от того, какие данные система успела собрать вокруг запроса.
Что входит в контекст
Контекст - это не только вопрос пользователя. В реальном AI-продукте туда часто попадает системный промпт, краткая история диалога, найденные документы из RAG, данные из базы, результат tool calling, профиль пользователя, правила безопасности и требуемый формат ответа.
Например, клиент спрашивает: “Можно ли вернуть товар?” Чтобы ответ был полезным, модели может понадобиться не только сам вопрос, но и политика возврата, дата покупки, тип товара, регион, статус заказа и ограничение “не обещать компенсацию без подтверждения”.
Если дать только вопрос, ответ будет общим. Если дать правильный контекст, ответ станет конкретным.
Контекстное окно не решает все
У современных моделей бывают большие контекстные окна, и возникает соблазн отправлять туда все подряд. Это плохая привычка.
Большой контекст стоит дороже, обрабатывается дольше и может ухудшать качество. Важная информация теряется среди лишнего текста. Противоречивые документы спорят друг с другом. Старые сообщения мешают новой задаче.
Сильный context engineering не про “запихнуть максимум”. Он про “выбрать достаточно”. Модель должна получить ровно те данные, которые помогают ответить, и не получить то, что мешает.
Context engineering и RAG
RAG - это способ найти документы и передать их модели. Context engineering шире: он решает, какие документы искать, какие фрагменты брать, как их подписывать, как отделять факты от инструкций и что делать, если документов не хватает.
Например, RAG может найти три похожих статьи базы знаний. Но context engineering должен решить, какая из них актуальна, какие фрагменты важны, надо ли показать источник, можно ли пользователю видеть этот документ и не содержит ли текст вредную инструкцию вроде “игнорируй предыдущие правила”.
То есть RAG приносит материал. Context engineering превращает этот материал в пригодный вход для модели.
Пример из поддержки
Допустим, пользователь пишет в поддержку: “Где мой заказ? Вы обещали доставку вчера”.
Плохой контекст: вся история переписки, несколько общих статей о доставке, сырой ответ API заказа и длинная инструкция оператору.
Хороший контекст: кратко кто клиент, номер заказа, текущий статус доставки, обещанная дата, актуальная политика компенсации и правило “если компенсация не подтверждена, не обещай возврат денег”.
Во втором случае модели проще ответить спокойно и точно. Она не просто “пишет лучше”, она видит нужные факты.
Пример из AI-агента
У AI-агента контекст еще важнее, потому что агент не только отвечает, но и действует. Он может искать документы, создавать задачи, обновлять CRM или передавать кейс человеку.
Если агент не видит, какие шаги уже были выполнены, он может повторять одно и то же. Если не видит результат tool, он может принять решение вслепую. Если не видит правила approval, он может предложить опасное действие без подтверждения.
Поэтому в агентном контексте важны цель, текущий state, результаты инструментов, ограничения, история шагов и критерий завершения задачи.
Почему порядок и структура важны
Модель лучше работает, когда контекст организован. Инструкции должны быть отделены от данных, пользовательский вопрос - явно выделен, документы - подписаны как найденные фрагменты, а результаты tools - даны в понятном виде.
Если смешать все в один длинный текст, модель может принять данные за инструкцию. Это особенно опасно в RAG, где документ может содержать фразу вроде “не слушай предыдущие правила”. Для человека очевидно, что это текст документа. Для модели без правильной разметки - потенциальная инструкция.
Хорошая структура снижает такие риски и делает ответ стабильнее.
История, память и сжатие
История диалога полезна, но ее нельзя бесконечно тащить за собой. Старые сообщения могут быть уже неактуальны, содержать ошибочные предположения или просто занимать место.
Часто лучше хранить не всю переписку, а короткое резюме: текущая цель, важные решения, ограничения и открытые вопросы. То же касается памяти агента. Память должна помогать, а не превращаться в склад случайных фактов.
Сжатие контекста полезно, но его тоже надо проверять. Если при сжатии потерялась дата, сумма, исключение или важное “нельзя”, ответ может стать неправильным.
Контекст и безопасность
Контекст может быть источником риска. В него попадают пользовательские сообщения, документы, результаты инструментов, персональные данные и память. Если все это передавать модели без фильтрации, можно получить утечки или опасные действия.
Нужны простые правила: не передавать лишние персональные данные, отделять инструкции от документов, проверять права доступа, маскировать секреты, логировать важные решения и не давать найденным документам менять системные правила.
Контекст должен быть не только полезным, но и безопасным.
Как понять, что проблема в контексте
Если модель отвечает плохо, не стоит сразу менять модель или переписывать весь промпт. Сначала надо открыть trace и посмотреть, что она получила на вход.
Был ли найден нужный документ? Не попал ли устаревший фрагмент? Не слишком ли длинная история? Видела ли модель результат tool? Не смешались ли данные разных клиентов? Было ли явно сказано, что делать при нехватке данных?
Очень часто оказывается, что модель “ошиблась” потому, что ей дали плохой контекст.
Короткий вывод
Context engineering - это не модный термин, а практическая работа с входом модели. Нужно дать ей нужные факты, убрать шум, отделить инструкции от данных, сохранить безопасность и не перегрузить контекстное окно.
Хороший промпт важен, но без хорошего контекста он не спасает. Для RAG, AI-агентов, поддержки, CRM и работы с документами context engineering часто решает половину качества.
Частые вопросы
Context engineering - это то же самое, что prompt engineering?
Нет. Prompt engineering про инструкцию. Context engineering про весь вход модели: документы, историю, память, tool results, порядок блоков, фильтрацию и формат ответа.
Нужно ли это, если у модели большое контекстное окно?
Да. Большое окно позволяет передать больше текста, но не делает весь текст полезным. Лишний и противоречивый контекст может ухудшить ответ.
RAG полностью решает context engineering?
Нет. RAG помогает найти документы, но дальше надо выбрать фрагменты, проверить доступы, отделить данные от инструкций, добавить историю, tool results и правила ответа.
Что важнее: промпт или контекст?
Нужны оба. Промпт задает задачу и правила, а контекст дает материал для ответа. Хорошая инструкция без нужных данных заставляет модель угадывать.
Как улучшить контекст в первую очередь?
Начните с trace: посмотрите, что реально получает модель. Обычно первые улучшения - убрать лишнюю историю, проверить RAG-фрагменты, структурировать tool results и явно отделить данные от инструкций.