Что такое контекстная инженерия? Что получает модель до того, как она отвечает

Контекстная инженерия — это проектирование того, какую информацию языковая модель получает во время вывода, в какой форме, в каком порядке и на какой срок. Она шире, чем промпт-инженерия, потому что контекст модели может включать системные инструкции, сообщения пользователя, извлечённые документы, результаты работы инструментов, память, текущее состояние приложения, примеры, структурированные данные и промежуточные артефакты. Цель не в том, чтобы максимизировать количество токенов, а в том, чтобы построить минимальный полезный контекст, сохраняющий информацию, ограничения и доказательства, необходимые для текущей задачи.

Что на самом деле означает контекстная инженерия

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

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

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

Простейший пример

Представьте внутреннего ассистента поддержки. Пользователь спрашивает: «Может ли этот клиент отменить без комиссии?»

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

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

Где заканчивается простой пример

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

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

Что может попасть в контекст модели?

Контекстная инженерия против промпт-инженерии

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

Контекстная инженерия против поиска

Поиск выбирает информацию-кандидата из внешнего корпуса или источника. Контекстная инженерия решает, что происходит после и вокруг этого поиска.

Поисковик может вернуть 30 фрагментов. Реранкер может сократить их до 10. Слой контекста может выбрать четыре фрагмента, удалить дубликаты, прикрепить метаданные источника/версии, объединить их с текущим состоянием приложения и разместить после системных инструкций.

Именно поэтому RAG-система может извлечь правильный фрагмент и всё равно ответить плохо: сбой может произойти во время сборки контекста, а не во время поиска.

Контекстная инженерия против памяти

Память — это информация, сохраняемая вне непосредственного вызова модели, чтобы её можно было использовать снова позже. Контекст — это информация, фактически загруженная в текущий вызов.

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

Это различие становится критически важным для изменчивого состояния. Запомненный статус проекта или предпочтение пользователя может быть полезным, но текущее авторитетное состояние может потребоваться перечитать перед принятием значимого решения.

Контекстная инженерия против состояния приложения

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

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

Проектирование инструментов — часть контекстной инженерии

Инструменты не просто дают агентам возможности. Имена инструментов, описания, схемы и результаты становятся видимой для модели информацией, которая формирует решения.

Текущие рекомендации Anthropic по контекстной инженерии подчёркивают важность токен-эффективных инструментов и предостерегают от раздутых наборов инструментов с пересекающейся функциональностью. Каталог инструментов, который трудно различить человеку, также трудно надёжно маршрутизировать модели.

Результаты работы инструментов также требуют контекстной дисциплины. Возврат всего журнала на 20 000 строк, когда агент запросил одно условие ошибки, расходует внимание и может похоронить решающее доказательство.

Контекст точно в срок против предзагруженного контекста

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

Контекст — это бюджет, а не система хранения

Контекстное окно определяет ёмкость. Оно не гарантирует, что каждый токен будет использован одинаково хорошо. Модель должна распределять внимание между инструкциями, историей, доказательствами, инструментами и промежуточным состоянием.

Практическая цель, следовательно, не «заполнить окно». Она состоит в том, чтобы максимизировать полезность ограниченного бюджета внимания.

Anthropic формулирует аналогичный принцип как поиск наименьшего набора токенов с высоким сигналом, который максимизирует вероятность желаемого поведения. Рекомендации OpenAI по управлению контекстом также предупреждают, что неотфильтрованная история, избыточные результаты инструментов и зашумлённое извлечение могут перегрузить даже большие окна.

Почему больше контекста может быть хуже

Дополнительный контекст может вносить нерелевантную информацию, устаревшее состояние, дублирующиеся доказательства, противоречивые инструкции или конкуренцию за позицию. Он также может заставлять системы уплотнения отбрасывать детали, которые позже становятся важными.

Классическое исследование Lost in the Middle показало, что модели с длинным контекстом могут использовать информацию по-разному в зависимости от того, где появляется релевантное содержимое, причём производительность часто снижается, когда решающая информация размещается в середине длинных входных данных.

Это не означает, что длинный контекст inherently плох. Это означает, что доступность внутри окна не то же самое, что надёжное использование.

Порядок контекста должен быть намеренным

Построение контекста — это также проблема порядка. Критические инструкции, текущее состояние, решающие доказательства и ограничения, специфичные для задачи, не следует объединять произвольно.

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

Стабильный ответ, который резко меняется, когда два одинаково обоснованных фрагмента меняются местами, указывает на чувствительность к контексту, которую следует измерять, а не игнорировать.

Конфликтующий контекст требует явного приоритета

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

Контекстная инженерия должна кодировать приоритет через выбор источника, метаданные, порядок или явные инструкции: актуальное авторитетное состояние переопределяет устаревшие копии; явная текущая инструкция пользователя переопределяет более раннее выведенное предпочтение; утверждённая политика имеет приоритет над устаревшими черновиками.

Компактизация — это преобразование контекста, а не хранение без потерь

Долго работающие системы в конечном итоге нуждаются в обрезке, суммировании или компактизации истории. Компактизация создаёт новое представление предыдущего контекста, чтобы агент мог продолжить, не воспроизводя каждый токен.

Примеры управления контекстом OpenAI используют обрезку и сжатие для длительных сессий. Anthropic описывает компактизацию как основной приём для поддержания связности, когда взаимодействие приближается к лимиту контекста.

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

Сохраняйте границы действительности

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

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

Контекстная инженерия — это также граница безопасности

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

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

Выводы инструментов также могут содержать недоверенные инструкции или враждебный контент. Контекстная инженерия должна сохранять различие между инструкциями приложения и внешними данными, чтобы извлечённый текст не мог незаметно получить авторитет инструкции.

Практическая архитектура контекстной инженерии

Сборщик контекста концептуально важен, даже если ни один модуль не носит такого точного названия. В небольшом приложении это может быть обычный код приложения. В крупной агентной платформе он может объединять управление сессиями, извлечение, память, middleware инструментов, компактификацию и применение политик.

Практическая политика построения контекста

Как оценивать контекстную инженерию

Сборка контекста — отдельный слой сбоев RAG

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

Именно поэтому трассировки извлечения следует сравнивать с фактическим контекстом, отправленным модели. Без такого сравнения сбои контекста легко ошибочно диагностировать как сбои эмбеддингов или модели.

Доказательства оригинальной реализации

Source of Truth Research Engine: ограниченное исследование вместо неограниченного контекста

Source of Truth Research Engine разделяет обнаружение, получение, извлечение, верификацию, анализ противоречий и синтез на ограниченные исследовательские этапы вместо отправки одной огромной исследовательской задачи и всего накопленного материала в один вызов модели.

Его модель доказательств хранит Sources, Artifacts, Claims, Relations, Contradictions и происхождение вне контекста модели. Модель может получать подмножество, необходимое для текущего исследовательского шага, пока долговременные доказательства остаются во внешнем хранилище.

Это конкретный паттерн контекстной инженерии: долговременное исследовательское состояние живёт вне окна модели; активный контекст модели реконструируется для текущего этапа.

Aaasaasa AI Client: среда выполнения, разрешения и контекст — это отдельные concerns

Aaasaasa AI Client разделяет выбор провайдера/модели, местоположение среды выполнения, разрешения рабочего пространства, локальные ресурсы и доступ к инструментам. Это предотвращает ситуацию, когда контекст модели становится владельцем авторизации или состояния приложения.

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

Доказательством реализации здесь является архитектурное разделение, а не утверждение, что каждая продвинутая техника управления контекстом, описанная в этой статье, уже реализована.

Распространённые режимы отказа контекстной инженерии

Распространённые заблуждения

Практическая последовательность контекстной инженерии

Контрольный список контекстной инженерии

Краевые случаи и ограничения

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

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

Некоторую информацию никогда не следует суммировать перед использованием. Точные контракты, код, криптографический материал, числовые записи и нормативный текст могут требовать дословного или структурированного извлечения, где сжатие могло бы изменить смысл.

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

Модель всё ещё может игнорировать или неверно интерпретировать превосходный контекст. Контекстная инженерия улучшает информационную среду; она не гарантирует корректность рассуждений.

Что могло бы изменить этот ответ?

Будущие модели могут стать более устойчивыми к длинному контексту, позиционным эффектам и противоречивой информации. Это могло бы уменьшить объём ручной курации, необходимой сейчас.

Архитектурное различие всё равно останется полезным, потому что разрешения, актуальность, персистентность памяти, авторитетность источника и состояние внешнего приложения существуют вне модели независимо от размера контекстного окна.

Рекомендуемый баланс между предзагруженным и контекстом, загружаемым по требованию, также меняется в зависимости от требований к задержке, надёжности инструментов, размера корпуса, стоимости модели и того, насколько динамична лежащая в основе информация.

Связанные канонические знания

Контекстная инженерия находится между поиском и генерацией. RAG объясняет, как извлекаются внешние знания; R01 разделяет эмбеддинги, векторный поиск и реранжирование; контекстная инженерия объясняет, что в конечном итоге доходит до модели.

Архитектура источника истины отвечает на другой вопрос: не какая информация присутствует в контексте, а какой источник уполномочен подтверждать утверждение.

Существующая статья «Почему больше контекста может ухудшить ответы ИИ» является диагностическим дополнением к этому каноническому определению. Она сосредоточена на загрязнении контекста, позиционных эффектах, росте top-k, потерях при компактификации и деградации ответов, а не на переопределении самой контекстной инженерии.

Часто задаваемые вопросы

Глоссарий

Заключение

Контекстная инженерия — это слой, который решает, что модель увидит перед тем, как ответить. Это делает её шире промптинга и ниже по потоку от поиска, при этом она остаётся отличной от долговременной памяти и авторитетного состояния приложения.

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

Практическая цель, следовательно, не максимальный контекст. Это минимально достаточный, высокосигнальный, корректно авторизованный и сохраняющий валидность контекст для следующего решения модели.

Первоисточники и актуальные рекомендации

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