Контекст инжиниринг (context engineering) — это отбор и организация информации, которую языковая модель получает для конкретной задачи. Вместе с поручением ей нужны сведения, на которые можно опереться: например, документы или предыдущая переписка. Но наличие документа в подключённой системе ещё не означает, что его содержимое передано модели. Это различие важно и в диалоге с ней, и в приложении на её основе, и в агенте, который выполняет задачу в несколько шагов.
Разберём знакомую задачу: подготовить спокойное письмо в поддержку о задержавшемся заказе и попросить подтверждённую дату доставки. Ситуация и все её подробности вымышлены для объяснения. На этом примере проследим, как выбрать нужные сведения, сохранить важные условия при продолжении работы и проверить, на чём основаны утверждения в письме. Затем ту же карту входных данных можно будет составить для своей задачи.
Что модель получает, когда вы просите её решить задачу
Между документами и ответом модели есть шаг сборки. Из доступных документов, истории разговора и сохранённых записей выбирают сведения, соединяют их с поручением и передают модели. Она получает этот набор и формирует ответ. Одно такое обращение называют вызовом, а переданный набор — входом этого вызова.
В диалоге часть материалов выбираете вы, а интерфейс определяет, как они и история попадут во вход. В приложении вход собирает программа. У агента после действия могут появиться новые сведения для следующего обращения. Это общая схема: точный состав зависит от устройства конкретной системы. Чтобы установить, что получила модель, нужна запись входа соответствующего вызова; список подключённых документов сам по себе этого не показывает.
Во вход могут также включаться описания доступных инструментов — например, средства поиска, которым модель может воспользоваться. При этом не всё, что управляет обращением к модели, является его текстом: настройки вызова могут задаваться отдельно. Такое различие между материалами для модели и окружением программы показано в документации LangChain.
Теперь зададим материалы нашего примера. По вымышленному сюжету сейчас 16 октября, 14:00. Человек ждёт настольную лампу, заказ № 4821, и хочет обратиться в поддержку. Все участники, числа, даты и сообщения придуманы для объяснения; октябрьские даты относятся к событиям этой истории.
Поручение модели: подготовить короткое спокойное письмо о задержке и попросить подтверждённую дату доставки. Посылка нужна до 18 октября. Использовать можно только переданные сведения; новую дату и причину задержки придумывать нельзя. Результат этой задачи — подготовленный текст. Его ещё предстоит отправить; сам текст не подтверждает срок у перевозчика и не означает, что посылка получена.
Доступны три записи, каждая в первой версии, которую обозначим v1:
- Карточка заказа от 10 октября: лампа, номер 4821, ожидаемая доставка 15 октября.
- Статус доставки от 16 октября, 13:00: «На складе перевозчика». Новой даты нет, доставка не состоялась.
- Переписка с поддержкой от 15 октября, 17:00: поддержка обещала уточнить срок и ответить до 12:00 16 октября. К 14:00 последующего ответа в материалах нет.
Составим два учебных набора при одном и том же поручении. Модель с ними не запускалась: пока сравниваем только сведения, которые решили передать.
Набор A содержит карточку заказа v1. Набор B содержит ту же карточку, статус доставки v1 и переписку v1. Цель письма, спокойный тон и потребность получить посылку до 18 октября заданы в общем поручении и одинаковы для обоих наборов.
Разницу удобно зафиксировать в карте. В графе источника нужен не только документ, но и место, где можно проверить сведение: конкретная запись или её поле. Такой адрес называют локатором. Здесь записи короткие, поэтому их названия, версии, время и указание нужного поля позволяют найти основание каждого утверждения.
| нужное сведение | источник и версия | что фактически передано | что проверить в ответе |
|---|---|---|---|
| Цель письма, спокойный тон, посылка нужна до 18 октября | Общее поручение: цель, тон и необходимый срок | Одинаково в A и B | Короткое спокойное письмо с просьбой подтвердить дату; нет утверждения, что письмо уже отправлено |
| Заказ № 4821, настольная лампа, исходный срок 15 октября | Карточка заказа v1 от 10 октября: номер, товар, ожидаемая доставка | В A и B | Исходный срок не назван новой подтверждённой датой |
| Текущий статус; новой даты нет, доставка не состоялась | Статус доставки v1 от 16 октября, 13:00: статус, новая дата, факт доставки | Только в B | Нахождение на складе перевозчика не представлено как получение посылки или подтверждение срока |
| Обещание ответить до 12:00 16 октября; к 14:00 ответа в материалах нет | Переписка v1 от 15 октября, 17:00: обещание поддержки и наличие последующего ответа | Только в B | Можно напомнить о прошедшем сроке ответа; нельзя назвать его сроком доставки |
Карта описывает заданные нами материалы, а не скрытые входы какого-либо сервиса. Она показывает, какие сведения есть в каждом наборе, но ещё ничего не говорит о качестве ответа. Следующий вопрос — как выбрать нужное для задачи и стоит ли передавать всё доступное сразу.
Какие сведения передать сразу, а какие найти по ходу задачи
Начать стоит с того, какие сведения нужны для желаемого результата. В нашем вымышленном примере для напоминания о прошлом обращении нужна переписка с обещанным временем ответа. Карточка заказа этого обещания не содержит, а ссылка на личный кабинет лишь указывает, где искать материалы. Пока нужное сообщение не извлечено и не передано, сослаться на него как на известный модели факт нельзя.
При отборе важно сохранить смысл каждой записи. Карточка сообщает исходный срок доставки, статус — положение дел на более поздний момент. Одна запись не отменяет другую: они отвечают на разные вопросы. По тому же принципу для рабочей задачи нужно выбирать применимые сведения. Если источник — документация, проверять следует её версию и условия применимости; дата скачивания сама по себе не делает содержание актуальным.
Материалы можно подготовить двумя способами. Первый — сразу передать нужный фрагмент вместе с поручением. Для нашего письма таким фрагментом будет сообщение поддержки. Второй — оставить указатель на источник и получить фрагмент позже, когда он понадобится. Во втором случае нужен работающий способ извлечения: один адрес документа не даёт модели его содержимого. Поиск может занять дополнительное время или пропустить важное.
Эти способы можно сочетать: необходимые условия передать сразу, дополнительные материалы получать по ходу задачи. Такой подход описан в инженерной статье Anthropic 2025 года. Это вариант организации работы со своими компромиссами, а не доказательство того, что подгрузка всегда лучше заранее собранного входа.
У входа есть и ограничение объёма — контекстное окно. Объём измеряют в токенах: единицах, которыми модель представляет текст. Но вместить материал и правильно использовать его при решении задачи — разные требования. Поэтому даже если весь архив помещается в окно, одного этого недостаточно, чтобы считать вопрос отбора решённым.
Два исследования показывают разные стороны этого ограничения. В Lost in the Middle, 2023 результаты испытанных моделей зависели от того, где во входе находился нужный фрагмент. В RULER, 2024 оценка длины, с которой модель справлялась, зависела от набора задач и принятого порога успеха. Найти отдельное значение и выполнить более сложную работу с несколькими сведениями — разные проверки. Эти результаты относятся к моделям и протоколам тех исследований. Из них нельзя вывести текущий рейтинг моделей, универсальную безопасную долю окна или правило «чем короче, тем лучше».
Для нашей карты это означает две отдельные проверки: вошли ли необходимые сведения в выбранный набор и опирается ли на них подготовленный текст. Переданный факт ещё не доказывает, что модель использует его правильно. А если подтверждённой даты в материалах нет, корректный текст должен сохранить эту неизвестность и запросить дату. Посмотрим, какие утверждения позволяют сделать уже заданные наборы A и B.
Как система выбирает подходящий текст из набора документов, мы подробно разбираем в статье о RAG. В ней один пример проходит весь путь от вопроса сотрудника до проверки ответа.
Как проверить, что ответ опирается на переданные сведения
Проверять стоит каждое утверждение: есть ли для него основание именно в переданном наборе? Из A и B можно взять номер заказа, товар и исходный срок доставки. Только B позволяет назвать текущий склад перевозчика и напомнить о прежнем обещании поддержки. То, что мы как читатели знаем всю вымышленную историю, не добавляет недостающие сведения во вход A.
Подтверждённой новой даты нет ни в одном наборе. Её нужно запросить. А цель обращения, спокойный тон и потребность получить посылку до 18 октября доступны в обоих случаях: эти условия заданы общим поручением.
Ниже — авторский учебный образец письма по материалам B, написанный для этого объяснения. Это не полученный ответ LLM и не реальная переписка:
Здравствуйте! Пишу по поводу заказа № 4821 — настольной лампы. В карточке была указана доставка 15 октября, но заказ ещё не доставлен. По статусу от 16 октября, 13:00, он находится на складе перевозчика; новой даты нет. В сообщении от 15 октября вы обещали уточнить срок и ответить до 12:00 16 октября. Сейчас 14:00, ответа пока нет. Посылка нужна мне до 18 октября. Пожалуйста, сообщите подтверждённую дату доставки.
Сверим образец с последней графой карты:
- Номер, товар и исходный срок взяты из карточки; склад и отсутствие доставки — из статуса; обещание ответить — из переписки. Для каждого утверждения есть запись в B.
- 15 октября осталось исходным сроком доставки. Обещание ответить до 12:00 16 октября не превратилось в обещание привезти посылку к этому времени.
- Новая дата запрошена, причина задержки не придумана. Потребность до 18 октября сохранена, тон обращения спокойный.
- Результат ограничен текстом: образец не подтверждает отправку письма, новую договорённость с перевозчиком или получение посылки.
Так мы проверили связь учебного текста с заданными материалами. Из этого не следует, что модель выдаст такой же ответ или что B обеспечит более высокое качество: запусков и измерения эффекта здесь нет. При реальной работе нужно сохранить фактически полученный ответ и сверить его с заранее выбранными условиями.
На этом же примере удобно различить три направления работы с LLM:
- Prompt engineering — как сформулировано поручение: какое письмо подготовить, каким тоном и что в нём запросить.
- Context engineering — какие сведения получит модель: включены ли карточка, статус и нужная переписка вместе с условиями задачи.
- Harness engineering — как организовано исполнение: получение материалов, действия и проверки результата.
Это полезное для разбора различие, а не универсальный стандарт с непроницаемыми границами. Инструкции тоже входят в контекст, а программа, организующая работу, участвует в его сборке. Поэтому уточнение формулировки поручения само по себе не доказывает, что пропущенная запись появилась во входе.
Пока мы проверяли письмо по материалам одного момента. Но поддержка может прислать новое сообщение. Тогда потребуется понять, что изменилось и какие сведения передать модели для продолжения задачи.
Как обновлять контекст между шагами и сессиями
Продолжим вымышленную историю. В 15:00 16 октября появляется новое сообщение поддержки, которое обозначим v2: «Ожидаем доставку 17 октября. Подтверждения от перевозчика пока нет». Это придуманное сообщение для учебного разбора. В исходные A и B на 14:00 оно не входило; теперь его можно включить в следующий запрос.
Следующая задача — подготовить уточнение о подтверждённой дате, сохранив условие «посылка нужна до 18 октября». В новом входе важно различить три вещи: 15 октября — исходный срок из карточки, 17 октября — новое ожидание поддержки, подтверждённая перевозчиком дата по-прежнему неизвестна. Более поздняя запись добавляет сведения, но не делает ожидание подтверждением.
Обновление можно представить так: возник уточняющий вопрос → человек или программа получили нужный материал → материал вместе с указанием источника и времени вошёл в новый запрос → ответ сверили с вопросом. В диалоге новое сообщение может приложить человек. В приложении его может добавить программа, собирающая вход. У агента получение материала через инструмент может быть частью последовательности действий. Здесь мы описываем возможную организацию работы; инструмент для нашего примера не запускался.
Чтобы проверить такой переход, нужно различать четыре момента. Описание инструмента сообщает модели, какое действие доступно. Запрос к инструменту задаёт конкретное действие. Инструмент возвращает сведения программе, и она определяет, что передать дальше. После этого отдельно проверяют ответ модели. Наличие поиска ещё не означает, что нужное сообщение найдено, а успешное выполнение поиска не подтверждает правильность письма. Даже полученный результат может требовать отбора перед следующим обращением.
Такой цикл описан в документации LangChain; конкретные продукты могут собирать входы по-разному. Поэтому для проверки важно видеть, какая часть результата действительно передана и сохранились ли её источник и условия.
Почему сохранённая память ещё не стала текущим контекстом
Продолжить текущий разговор и вернуться к сведениям после его окончания — два разных случая. В первом система поддерживает сведения в рамках одного разговора. Во втором нужен способ сохранить данные между сессиями и затем найти нужную запись. В описанном подходе LangChain этим случаям соответствуют краткосрочная память, short-term memory, и долговременная, long-term memory. Это названия в конкретном подходе, а не обещание одинаковых режимов памяти во всех чатах.
Как работают оба вида памяти на примере заказа в CRM, разобрано в статье «Краткосрочная и долговременная память ИИ-агентов».
В нашем учебном продолжении можно сохранить условие о посылке до 18 октября вместе с сообщением поддержки v2: 17 октября пока лишь ожидаемая дата без подтверждения перевозчика. При возвращении к задаче эту запись нужно выбрать и включить в новый запрос. Проверять следует последнее звено: какие именно сведения вернулись во вход? Сам факт сохранения записи не показывает, что обе оговорки доступны модели сейчас.
Память здесь отвечает за сохранение и возвращение сведений. Организация продолжения процесса относится к уже рассмотренному Harness; эти задачи могут выполняться одной программой. При этом хранение не обещает точного воспроизведения всего накопленного. Если для продолжения решено оставить только краткую запись, возникает следующий вопрос: что в ней необходимо сохранить?
От доступных материалов к входу модели
Для одного вызова из доступных документов, истории и сохранённых записей выбирают и извлекают нужные сведения. Их вместе с поручением и условиями передают модели, которая формирует ответ. При продолжении новые сведения, в том числе результаты инструмента, и нужные извлечённые записи могут пройти отбор для следующего входа. Сохраняют источник и условия; передаётся выбранная часть.
Как сохранить важное в краткой записи и передать дальше
Когда накопленную историю заменяют кратким изложением для продолжения работы, меняется содержимое следующего входа. Такое сжатие называют compaction. Оно отличается от памяти: память отвечает за сохранение и возвращение сведений, а сжатие — за то, в каком виде они останутся. Краткое изложение может храниться в памяти, но его содержание нужно проверять отдельно.
В инженерной статье Anthropic 2025 года описан риск такого сокращения: можно удалить подробность, значение которой обнаружится позднее. Поэтому стоит проверять, сохранились ли необходимые требования, исключения, решения и указания на источники. Сам размер записи не показывает, достаточно ли её для следующей задачи, и универсальной степени сжатия здесь нет.
После нового сообщения поддержки для нашего примера можно составить следующую авторскую учебную запись. Это образец для объяснения, а не резюме, полученное в запуске модели:
Задача — запросить подтверждённую дату доставки заказа № 4821; посылка нужна до 18 октября. Исходный срок — 15 октября, по полю ожидаемой доставки в карточке заказа v1. Последнее сообщение поддержки v2 от 16 октября, 15:00: доставка ожидается 17 октября, подтверждения перевозчика пока нет. Подтверждённая дата, причина задержки и фактическое получение посылки не установлены. Источники: общее поручение, карточка заказа v1 и текст сообщения поддержки v2.
Если сократить это до «доставка 17 октября», исчезнут сразу три существенные вещи: речь об ожидании, подтверждения нет, дату назвала поддержка. Для продолжения также потеряется условие о посылке до 18 октября. Это потеря смысла, которую видно при сопоставлении двух текстов; мы не наблюдали такую ошибку в ответе модели.
Рабочая запись сохраняет выбранные сведения, условия и происхождение из нашей карты. Но графу «что фактически передано» для следующего вызова нужно проверить заново: наличие хорошей записи ещё не показывает, что именно её получила модель. И сама запись не гарантирует правильного ответа — её достаточность зависит от следующей задачи.
Что должна получить другая роль или новая сессия
Теперь представим, что продолжение поручено другому исполнителю на основе модели. У него может быть свой отдельный набор сведений, без исходной истории. Такое разделение называют изоляцией контекста. В описанной Anthropic схеме отдельный агент выполняет подробную работу и возвращает сокращённый результат. Это один вариант организации, а не свойство всех агентных систем; количество исполнителей само по себе не доказывает надёжность.
Если получателю передать только «доставка 17 октября», он не узнает из этого текста об ожидании поддержки без подтверждения перевозчика. Поэтому для нашей следующей задачи стоит передать выбранную рабочую запись вместе с целью уточнить подтверждённую дату, потребностью до 18 октября и указаниями на источники. Здесь проверяется уже граница передачи: что действительно доступно получателю? Даже полное получение краткой записи не означает, что он прочитал исходные документы или правильно выполнит поручение.
Возврат из памяти, сжатие и передача могут следовать друг за другом, но проверяются разными вопросами: когда вернуть сведения, что оставить в краткой записи и что стало доступно получателю. Чтобы применить эти различия на практике, достаточно начать с одной своей задачи и проследить необходимые ей сведения.
Как проверить контекст одной своей задачи
Выберите одну задачу и сохраните её точное поручение. Отдельно запишите желаемый результат и условия, без которых он не подходит. Затем заполните уже знакомую карту с четырьмя полями. Это предложенный способ разбора задачи, а не обязательный отраслевой стандарт.
- нужное сведение — какие факты и условия нужны для результата. Включайте сюда ограничения задачи, а не только сведения из документов.
- источник и версия — где проверить каждый факт: документ или запись, применимая версия, адрес нужного фрагмента и время, если оно существенно. Дата скачивания не заменяет проверку применимости содержания.
- что фактически передано — какие из нужных сведений вошли в конкретное обращение к модели. Если состав входа виден лишь частично, прямо отметьте неизвестную часть.
- что проверить в ответе — заранее, до запуска, задайте условия проверки: какие факты должны быть верны, какие требования соблюдены, на какие источники можно опираться и где следует оставить неизвестное неизвестным.
После запуска сохраните полученный ответ и сверьте его с четвёртым полем. Проверяйте и отдельные утверждения, и выполнение поручения целиком: наличие правильного факта ещё не означает, что выполнены остальные условия.
Глубина такой проверки зависит от доступных данных. В диалоге можно сохранить своё поручение и приложенные материалы, но внутренняя сборка входа не всегда видна. Для приложения или агента стоит запросить сохранённые входы нужного вызова и возвращённые результаты инструментов, если такие записи доступны. Список подключённых систем не заменяет эти сведения; недоступную часть входа не нужно восстанавливать догадками.
Наш вымышленный пример показывает три разных предмета проверки. Чтобы напомнить об обещании поддержки, нужно включить переписку. Если подтверждённой даты нет в источниках, её следует запросить. Если из краткой записи исчезло «ожидается, не подтверждено», нужно проверить сокращение и последующую передачу. Это выводы из заданных материалов, а не наблюдавшиеся ошибки модели или доказанные способы улучшения её ответа.
Когда найден конкретный недостаток, выберите одно соответствующее изменение: добавьте пропущенное условие, замените неприменимую версию источника либо восстановите потерянное при передаче. Новый ответ проверяйте по тем же заранее выбранным критериям. Менять всё сразу для такого разбора не требуется.
Один ответ или одно сравнение не устанавливает точную причину ошибки и не доказывает устойчивого улучшения. Для такого вывода нужна отдельная проверка с подходящим планом. На этом этапе карта даёт более узкий, но проверяемый результат: какое существенное сведение или условие следует проследить от источника до ответа.
