Context Engineering

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

Коротко

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

Что это такое

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

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

• System prompt — кто модель такая, что умеет.
• User memory — что модель уже знает о вас (ChatGPT Memory, Claude Projects).
• RAG-документы — релевантные куски из базы знаний.
• Tools — какие функции доступны (через function calling / MCP).
• History — предыдущие сообщения диалога.
• Workspace files — файлы проекта (IDE-ассистенты, Claude Code).
• Live data — поиск в интернете, API-данные, время.

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

Термин получил широкое распространение в середине 2020-х, когда разработчики стали описывать работу не с одним промптом, а со всей системой подготовки контекста.

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

Условный пайплайн AI-агента с Context Engineering:

User: "Найди счета за март и сделай отчёт"
   ↓
1. Memory loader   → достать профиль пользователя
2. RAG retriever   → найти 5 релевантных кусков из knowledge base
3. Tool selector   → отобрать 3 нужных tools из 47 доступных
4. History compressor → ужать прошлые 50 сообщений до summary
5. Context assembler → собрать всё в финальный prompt
   ↓
6. LLM → ответ или вызов tool
   ↓
7. Memory writer → записать новые факты в долгую память

Каждый шаг — отдельная инженерная задача:

Memory. Какие факты о пользователе помнить, какие забывать, как обновлять. ChatGPT Memory активно учится; Claude Projects держит документы; продвинутые системы хранят «эпизодическую» и «семантическую» память отдельно.

RAG. Не просто «найти и вставить». Нужен качественный chunking, embeddings, reranking, фильтрация по метаданным. Плохой RAG = шум в контексте = хуже ответ.

Tool selection. Если дать модели 50 функций — она запутается. Динамически выбираем 5–10 самых релевантных через embeddings от описания tool до текста запроса.

Compression. Длинная история увеличивает цену и размывает фокус. Через выбранные интервалы её сворачивают в проверяемое summary, сохраняя решения, открытые вопросы и ссылки на исходные данные.

Order matters. Модели сильнее обращают внимание на начало и конец контекста («lost in the middle» — известный эффект). Размещение важного блока в правильном месте — отдельный навык.

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

Команда делает AI-ассистента для юристов. Версия 1 (только prompt engineering):

Ты — юрист. Отвечай на вопросы по российскому праву.
Будь точным.

USER: «Что грозит за неуплату алиментов?»

Ответ: общие банальности на уровне статьи Википедии. Без ссылок на статьи закона. Может галлюцинировать суммы.

Версия 2 (с Context Engineering):

def answer_legal_question(question, user_id):
    # 1. Достать профиль пользователя
    profile = get_user_profile(user_id)  # юрист vs обыватель?

    # 2. Найти релевантные статьи закона через RAG
    relevant_articles = vector_search(
        query=question,
        filters={"source": "ГК РФ", "updated_after": policy_cutoff_date},
        top_k=5
    )

    # 3. Достать свежую судебную практику
    cases = search_court_decisions(question, last_year=True, top_k=3)

    # 4. Выбрать релевантные tools (calculator? lookup?)
    tools = select_tools(question, available_tools=ALL_TOOLS)

    # 5. Собрать финальный контекст
    context = f"""
    <profile>{profile}</profile>
    <statutes>{relevant_articles}</statutes>
    <court_practice>{cases}</court_practice>
    """

    # 6. Запрос с готовым контекстом
    return claude.messages.create(
        model="your-model-id",
        system=LEGAL_SYSTEM_PROMPT,
        messages=[{"role": "user", "content": context + question}],
        tools=tools
    )

Версия 2 даёт ответ со ссылками на конкретные статьи, найденными материалами и расчётом через калькулятор. Такой pipeline дороже «голого» запроса, зато его можно проверить по источникам. Реальный выигрыш измеряют на собственных кейсах и отдельно оценивают юридические ошибки.

В Claude Code и Cursor — система внутри них уже собирает контекст автоматически: подгружает релевантные файлы из проекта, выдаёт результаты команд, ведёт TODO-список. Это и есть Context Engineering, упакованный в продукт.

ComfyUI в этой парадигме интересен тем, что workflow-ноды это явная визуализация context-pipeline'а: каждая нода добавляет что-то в финальный латент.

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

• Context Engineering и Prompt Engineering — Prompt = текст сообщения. Context = вся информация вокруг (память, документы, инструменты, история). Context включает prompt как один из элементов.
• 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 вместе.

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

• «Чем больше контекста, тем лучше». Нет. После определённого порога модели начинают «теряться в середине», ответы хуже. Релевантность > объём.
• «200K окно — всё помещается». Помещается, но обработка дорожает квадратично (attention). И качество падает. Сжимай старое.
• «RAG это и есть Context Engineering». RAG это техника. Context Engineering — дисциплина, где RAG один из инструментов.
• «Memory заменит RAG». Не заменит. Memory — это коэффициенты пользователя; RAG — внешние данные. Они дополняют друг друга.
• «Context Engineering — это для больших команд». Минимальная версия (system prompt + RAG + хранение истории в localStorage) делается за день. Полная — да, нужна команда.

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

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

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

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

С чего начать? Минимум: system prompt + история диалога + один источник внешних данных (RAG или web search). Это уже сильно лучше «голого» LLM.

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

Сколько контекста — это много? Зависит от модели и задачи.

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

Главное

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