Context Engineering

Context Engineering — практика системно снабжать AI-модель нужным контекстом до того, как она ответит. Память о пользователе, документы через RAG, проектные файлы, инструменты через MCP и прошлые сообщения. Один удачный промпт здесь не решает всё: качество зависит от того, какая информационная среда собрана вокруг модели.

Коротко

Коротко. Context Engineering — сборка контекста для AI-модели: памяти пользователя, документов из RAG, файлов проекта, доступных инструментов и истории диалога. Здесь важна не одна удачная фраза, а весь набор материалов и правил, которые модель получает перед ответом.

Что это такое

AI-продукт состоит не только из модели и промпта. Между запросом пользователя и моделью обычно есть слой, который выбирает документы, историю, память и доступные инструменты. Управление этим слоем и называют Context Engineering.

Что входит в этот контекст:

• Системные инструкции — задача, правила ответа и ограничения.
• Память приложения — сохранённые предпочтения и факты, которые уместны в этом запросе.
• Документы — подходящие фрагменты базы знаний.
• Инструменты — описания доступных функций и их параметров.
• История — предыдущие сообщения или их краткое содержание.
• Файлы проекта — код, документация и другие материалы, нужные для задачи.
• Внешние данные — результаты поиска, ответы API, сведения о текущем состоянии системы.

Все эти источники собираются в окно контекста модели. Его размер ограничен, токены влияют на стоимость и задержку, а нерелевантные материалы могут ухудшить ответ. Отсюда отдельная инженерная задача: что добавить, что отбросить, в каком порядке расположить и как сжать.

Как это работает

Представим запрос: «Найди счета за март и сделай отчёт». Прежде чем отвечать, приложению нужно уточнить год и компанию, проверить права пользователя и получить сами счета. Старые разговоры о дизайне отчёта могут пригодиться, но пересылать всю переписку незачем.

Схематично подготовка выглядит так:

Запрос и права пользователя
        ↓
Выбор доступных документов и инструментов
        ↓
Получение данных, необходимых для задачи
        ↓
Отбор истории и сохранённых предпочтений
        ↓
Сборка контекста → ответ модели или запрос инструмента
                         ↓
                   результат инструмента
                         ↓
                   следующий вызов модели

Память. Приложение решает, что сохранить и когда обновить. Предпочтение «показывать суммы с НДС» и результат вчерашнего расчёта — разные сведения: у них разные сроки полезности. Догадку модели нельзя незаметно превращать в подтверждённый факт о пользователе.

Поиск. Недостаточно найти текст с похожими словами. Для счетов важны компания, период, статус документа и права доступа. Полнотекстовый поиск, векторный поиск и фильтры решают разные части этой задачи.

Инструменты. Модели нужны понятные описания функций. Если набор велик, приложение может выбирать подходящую часть. Но универсального правила «не больше десяти инструментов» нет: важны их различимость и качество выбора на реальных заданиях.

Сжатие истории. Краткое содержание экономит место, но может потерять исключение, имя или принятое решение. Поэтому существенные сведения сохраняют явно, со ссылкой на исходный материал, а не только в свободном пересказе.

Порядок. Расположение материалов тоже влияет на ответ. В исследовании Lost in the Middle модели хуже использовали некоторые сведения в середине длинного ввода. Это не единый закон для всех моделей и задач: подходящее расположение проверяют на своих примерах.

Пример на практике

Команда делает помощника по внутренним правилам командировок. Пользователь спрашивает: «Можно ли оплатить гостиницу сверх лимита, если рядом с выставкой нет свободных номеров?»

Одной инструкции «отвечай точно» мало. Модель может предложить правдоподобный порядок согласования, которого в компании нет. Для ответа нужны конкретные материалы:

• действующая редакция правил;
• пункт об исключениях;
• порядок согласования расходов;
• страна и даты поездки, если от них зависят условия.

В контексте эти материалы можно представить так:

Задача: объяснить порядок согласования по приложенным документам.
Если нужного правила нет, сообщить, каких сведений не хватает.

Вопрос сотрудника: можно ли превысить лимит гостиницы?

Документ 1: правила командировок, действующая редакция.
Раздел: проживание и исключения.
Текст: [фрагмент из базы компании]

Документ 2: порядок согласования дополнительных расходов.
Текст: [фрагмент из базы компании]

Формат: краткий ответ, условия, ссылки на пункты документов.

Это схема, а не готовые правила компании. Приложение подставляет проверенные фрагменты и их источники. Если документы противоречат друг другу, полезнее показать расхождение, чем просить модель выбрать наиболее уверенно звучащую версию.

Проверка результата тоже конкретная: нашёл ли помощник исключение, назвал ли нужного согласующего, не добавил ли выдуманный срок. Сравнение с ответом без документов покажет, помогла ли подготовка контекста именно в этой задаче.

IDE-помощники решают похожую задачу, когда выбирают файлы проекта и результаты команд. Визуальная схема ComfyUI — другой тип организации вычислений: не каждую ноду в ней корректно называть частью контекста языковой модели.

С чем часто путают

• Context Engineering и Prompt Engineering — Работа над промптом сосредоточена на инструкциях и примерах; работа над контекстом включает также поиск, историю, память и результаты инструментов. Граница между практиками не строгая.
• Context Engineering и RAG — RAG это техника внутри Context Engineering, один из источников контекста.
• Context Engineering и Fine-tuning — Fine-tuning меняет веса модели. Context Engineering меняет вход модели. Сложность и расходы зависят от реализации; подготовка контекста тоже может требовать серьёзной инфраструктуры.
• Context Window и Context Engineering — Window это размер «коробки». Engineering — что в эту коробку положить.
• Context Engineering и Memory — Memory это один из компонентов. Context Engineering — это и Memory, и RAG, и Tools, и History вместе.

Частые ошибки и заблуждения

• «Чем больше контекста, тем лучше». Лишние сведения могут отвлекать или противоречить друг другу. Но слишком короткий отрывок тоже опасен: из него легко потерять исключение или условие.
• «Большое окно решает все проблемы». Вместимость не гарантирует правильного ответа. При этом стоимость API не обязана расти квадратично: вычислительная сложность внимания и тариф — разные вещи.
• «RAG и есть Context Engineering». Поиск — один из способов подготовки данных, а не вся задача.
• «Память заменит поиск». Память может содержать предпочтения или прошлые события, а поиск — находить нужное среди них и во внешних документах. Эти механизмы способны работать вместе.
• «Это нужно только большим командам». Даже один помощник с историей диалога уже требует решений о контексте. Масштаб проекта определяет сложность реализации, а не саму необходимость отбора данных.

Связанные термины

• Prompt Engineering — пишут текст одного запроса; Context Engineering работает со всеми источниками вокруг.
• RAG — техника извлечения релевантных документов в контекст.
• Context Window — допустимый объём ввода и ответа, в которой собирается контекст.
• MCP — стандарт для подключения внешних инструментов (компонент контекста).
• Function Calling — механизм вызова инструментов, ещё один компонент контекста.
• Memory — долгосрочная память пользователя.
• Embedding — числовое представление данных, полезное для поиска по смыслу.

Частые вопросы

Что заменяет prompt engineering — Context Engineering? Не заменяет, а расширяет. Prompt Engineering — это умение писать запросы. Context Engineering — умение системно собирать всё вокруг запроса. Они дополняют друг друга.

С чего начать? С вопроса: какие сведения необходимы для правильного ответа? Для пересказа абзаца хватит самого абзаца и инструкции. Для ответа по правилам компании нужны её документы. Поиск и память стоит добавлять, когда они решают конкретную нехватку данных.

Какие фреймворки? Одни библиотеки помогают искать документы, другие — вызывать инструменты или хранить состояние диалога. Для проверки важно видеть, какой контекст реально отправился модели, откуда взялись фрагменты и что изменилось после обработки.

Сколько контекста — это много? Объём уже избыточен, если дополнительные материалы увеличивают задержку и расходы, но не помогают ответить или добавляют ошибки. Это можно проверить сравнением: один и тот же набор вопросов с разным составом контекста.

Это новая профессия? Это скорее набор обязанностей, чем единая должность: проектирование контекста встречается у AI-инженеров, разработчиков поиска, аналитиков данных и авторов агентных систем.

Главное

Context Engineering — управление всем, что попадает в окно модели до ответа: системным промптом, памятью пользователя, RAG-документами, инструментами, историей и файлами проекта. Качество зависит не только от формулировки запроса, но и от отбора, порядка и свежести контекста. Поэтому RAG, память, выбор инструментов и сжатие истории удобно рассматривать как части одной инженерной задачи.

Приёмы отбора, сжатия и сохранения контекста разобраны в инженерной статье Anthropic.