Контекст-инжиниринг: это практика решения о том, что видит языковая модель, когда отвечает. Не только вопрос, который вы вводите, но и инструкции вокруг него, вставленные документы и результаты инструментов, сохранённая память о пользователе и разговор до этого момента. Всё это делит одно контекстное окно, и модель отвечает по этому тексту и ничему больше. Термин распространился в 2025 году, когда всё больше ИИ-продуктов стали агентами, которые собирают большую часть контекста автоматически.
Промпт-инжиниринг в основном про то, как сформулировать запрос. Контекст-инжиниринг про то, что должно быть перед моделью при каждом вызове и в каком порядке.
От промпта к контексту
В чат-приложении большую часть контекста вы пишете сами: приложение добавляет системный промпт и историю, а остальное добавляете вы. В приложении баланс переворачивается. Пользователь вводит одно предложение, а код вокруг модели добавляет инструкции, профиль пользователя, три справочные статьи, найденные поиском, список доступных инструментов и вывод последнего вызова инструмента. Предложение пользователя может оказаться малой долей того, что читает модель.
Когда такая система отвечает плохо, дело редко в формулировке. Обычная причина в том, что у модели был не тот материал: недостающий факт, устаревший результат инструмента, нерелевантный документ, который поиску показался релевантным.
Что попадает в контекстное окно
Типичный вызов в ИИ-приложении содержит некоторые или все из этих частей, примерно в таком порядке:
- Системные инструкции: роль, правила и формат вывода, обычно одинаковые для всего приложения. См. системный промпт.
- Описания инструментов: названия, описания и параметры инструментов, которые модель может вызывать.
- Примеры: несколько образцов входа и выхода, показывающих ожидаемое поведение.
- Память: факты, сохранённые из прошлых сессий, например тариф, язык или предпочтения пользователя.
- Найденные документы: фрагменты, найденные поиском по базе знаний для этого вопроса (retrieval-augmented generation, или RAG).
- История диалога: предыдущие реплики, дословно или в сжатом виде.
- Результаты инструментов: вывод поисков, запусков кода или вызовов API, сделанных в ходе этой задачи, как в цикле ReAct.
- Текущее сообщение: то, что пользователь только что спросил.
Блок ниже: один собранный контекст для ассистента поддержки. Отключайте части по одной. Без части с контекстом модель не может знать тариф клиента; без части с входными данными у неё нет фактов о продукте, и ограничения велят ей сказать об этом, а не угадывать.
Здравствуйте, Дана! Офлайн-режим входит в тариф Pro, а ваш аккаунт сейчас на тарифе Free, поэтому пока он вам недоступен. С Pro заметки, созданные во время полёта, синхронизируются автоматически, когда телефон снова подключится к сети. Одно ограничение, о котором стоит знать: вложения больше 20 МБ офлайн недоступны.
Обратите внимание: правильный ответ зависит от соединения двух источников, памяти (тариф Free) и документа (офлайн-режим только в Pro). Ни одного по отдельности недостаточно, и это типично. Большая часть контекст-инжиниринга: следить, чтобы части, которые нужны друг другу, приходили вместе.
Четыре способа испортить контекст
- Недостающая информация. Модель заполняет пробелы правдоподобными догадками, и отсюда берутся многие галлюцинации. Добавьте факт или скажите модели, что делать, когда факта нет.
- Слишком много материала. Каждый нерелевантный абзац стоит токенов и борется за внимание. Liu et al. 2023, «Lost in the Middle: How Language Models Use Long Contexts», обнаружили, что протестированные ими модели надёжнее использовали информацию в начале или в конце длинного входа, чем в середине. Новые модели справляются с длинными входами лучше, но отправить несколько фрагментов, которые отвечают на вопрос, всё равно дешевле и удобнее для модели, чем вставить всё руководство.
- Устаревшая информация. Результат инструмента десятишаговой давности может описывать файл или баланс, которые с тех пор изменились. Если модель видит обе версии, она может воспользоваться старой.
- Конфликты. Два документа расходятся, или память говорит одно, а пользователь другое. Скажите модели, какой источник главнее, например «последнее сообщение пользователя важнее сохранённой памяти».
Порядок контекста
Порядок влияет и на результат, и на стоимость.
- Стабильные части первыми. Системные инструкции, описания инструментов и постоянные справочные материалы редко меняются между вызовами. Несколько провайдеров API предлагают кеширование промптов, которое переиспользует обработку одинакового начала входных данных, так что неизменный префикс делает повторные вызовы дешевле и быстрее.
- Длинный материал перед вопросом. Для длинного документа или большого набора фрагментов ставьте материал первым, а вопрос и итоговые инструкции после него. Руководство Anthropic по промптингу, например, рекомендует такой порядок для длинных входов, с вопросом прямо перед тем местом, где модель начинает писать.
- Подписывайте каждую часть. Оборачивайте каждый источник в теги вроде
<document>,<memory>или<tool_result>с названием источника. Подписи позволяют модели отличать данные от инструкций и позволяют вам просить её указывать, откуда взят ответ. Форматы описаны на странице разделители и XML-теги.
Как сократить длинный контекст
Каждая реплика в чате отправляет заново всю историю, поэтому длинные сессии растут, пока чем-то не придётся пожертвовать. В зависимости от приложения оно может сжать или отбросить старые сообщения или предложить начать новый чат. Результаты лучше, если сокращать осознанно.
- Держите последние несколько реплик дословно, а более старые замените кратким изложением.
- Когда результат инструмента использован, замените его однострочной заметкой о том, что он показал.
- Сохраняйте точные идентификаторы в каждом изложении: имена файлов, имена функций, ID, сообщения об ошибках и числа. Изложение, где сказано «файл конфигурации», а в истории был
settings.prod.yaml, теряет единственную важную деталь. - В чат-приложении, когда разговор уходит в сторону, начните новый чат с запиской для передачи дел. Промпт ниже такую записку пишет.
Цель: заменить написанные вручную проверки формы регистрации одной общей схемой валидации, которую используют и браузер, и сервер.
Решения
- Один файл схемы,
signupSchema.ts, который импортируютSignupForm.tsxиapi/signup.ts, чтобы два набора правил не могли разойтись. - Тексты ошибок остаются дословно такими же, потому что их цитирует справочный центр.
Текущее состояние
- Валидация в браузере использует схему, и
SignupForm.test.tsxпроходит. - Сервер всё ещё вызывает старую
validateSignup()вapi/signup.ts.
Точные детали: пароль не короче 8 символов и с хотя бы одной цифрой. Текст ошибки для почты: "Please enter a valid email address."
Следующий шаг: заменить validateSignup() схемой и запустить тесты API.
Открытый вопрос: уже зарегистрированная почта должна возвращать 409 или 400?
Память между сессиями
Память: это контекст, который переживает разговор. Факты, записанные в хранилище в конце одной сессии и загруженные в следующую. В чат-приложениях есть свои версии этого, например сохранённые воспоминания или инструкции проекта, которые добавляются в каждый чат проекта. В вашем собственном приложении память: это таблица или файл заметок, который ваш код читает и вставляет. Два правила делают её полезной: храните факты, которые остаются верными (тариф, язык, предпочитаемый стек), а не стенограммы; и загружайте только то, что относится к текущей задаче, потому что память конкурирует за то же место, что и всё остальное.
Сборка контекста в коде
В приложении контекст-инжиниринг: это обычный код. Этот набросок на Python SDK от Anthropic кладёт постоянные правила и память в системный промпт, оставляет только недавнюю историю и ставит подписанные документы перед вопросом.
import anthropic
client = anthropic.Anthropic()
MODEL = "your-model-id" # e.g. from your provider's model list
def build_context(question, docs, history, memory, max_messages=6):
documents = "\n".join(
f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
)
system = (
"You are the support assistant for Acme Notes. Answer only from the documents. "
"If they do not cover the question, say so.\n"
f"<memory>\n{memory}\n</memory>"
)
# history holds complete user/assistant pairs, so an even slice starts with a user turn
recent = history[-max_messages:]
user = f"<documents>\n{documents}\n</documents>\n\n{question}"
return system, recent + [{"role": "user", "content": user}]
# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)
Каждое решение в этой функции (какие документы, сколько сообщений, куда идёт память): это выбор в области контекст-инжиниринга, и каждое стоит проверять на реальных вопросах так же, как вы проверяли бы изменение формулировки.
Часто задаваемые вопросы
Что такое контекст-инжиниринг?
Контекст-инжиниринг: это работа по выбору, упорядочиванию и сокращению всего, что языковая модель получает при вызове: системных инструкций, примеров, найденных документов, описаний и результатов инструментов, сохранённой памяти, истории диалога и сообщения пользователя. Модель отвечает только по этому тексту, поэтому то, что в нём есть и чего в нём нет, определяет качество ответа.
Чем контекст-инжиниринг отличается от промпт-инжиниринга?
Промпт-инжиниринг в основном про формулировку инструкций. Контекст-инжиниринг охватывает весь вход, большую часть которого собирает код, а не печатает человек: какие документы найти, какие результаты инструментов оставить, сколько истории включить и в каком порядке. В чате большую часть контекста вы пишете сами; в приложении или агенте большую часть выбирает система вокруг модели.
Больше контекста: всегда лучше?
Нет. Нерелевантный или устаревший материал конкурирует с важными частями, стоит токенов и может противоречить текущему состоянию. Исследования длинных входных данных показали, что модели могут упускать информацию, расположенную в середине длинного контекста. Включайте то, что нужно задаче, подписывайте это и убирайте то, что больше не нужно.
Почему длинный чат со временем становится хуже?
Весь разговор отправляется заново при каждой реплике, поэтому старые ошибки, брошенные идеи и устаревший код остаются в контексте и продолжают влиять на ответы. Когда чат перерастает контекстное окно, приложению приходится отбрасывать или сжимать старые сообщения. Начать новый чат с кратким изложением решений и текущего состояния часто лучше, чем продолжать.
Что такое RAG в контекст-инжиниринге?
RAG (retrieval-augmented generation, генерация с дополнением найденными данными) означает поиск в ваших документах фрагментов, относящихся к вопросу, и их вставку в контекст до ответа модели. Это один из главных инструментов контекст-инжиниринга: модель получает актуальные конкретные факты, которых не могла знать из обучения, и вы можете велеть ей отвечать только по этим фрагментам.
