Что такое context engineering: контекст для ИИ

Что такое context engineering: контекст для ИИ — разберём на документах, истории и памяти. Это дисциплина отбора информации для каждого шага модели: какие инструкции, факты и результаты инструментов передать, как проверить их происхождение и что сохранить при сжатии. Ниже соберём полный рабочий набор для ответа о доставке заказа.

Промпт, контекст, история и долговременная память

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

Anthropic определяет context engineering как отбор и поддержание набора токенов, полезного для вывода модели. IBM уточняет границу: prompt engineering входит в эту дисциплину, а RAG добавляет внешние сведения, но сам по себе не решает управление инструкциями, историей и результатами остальных инструментов.

В технической документации LangChain различаются model context — содержимое вызова модели, tool context — данные, доступные инструментам, и life-cycle context — действия между вызовами. Там же state служит памяти разговора, store — сведениям между разговорами, runtime context — конфигурации текущего взаимодействия. Из этого не следует, что любое сохранённое воспоминание нужно автоматически отправлять модели.

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

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

Происхождение и дата каждого документа

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

IBM рекомендует структурировать контекст, отделяя инструкции от данных, например с помощью Markdown или JSON. В нашей карте отдельная строка RULES задаёт правила ответа, а документы POLICY и ORDER поставляют факты. Дата в имени файла помогает навигации, но её нужно сверять с содержимым и областью действия документа.

Практический порядок действий для паспортизации:

1. Соберите все входные материалы, которые планируете передать модели: правила, документы, заметки, историю, данные из CRM.
2. Присвойте каждому идентификатор вида POLICY-current, ORDER, NOTE — короткий и однозначный.
3. Проставьте дату создания или последнего обновления.
4. Укажите источник: кто автор, откуда документ пришёл.
5. Отметьте статус: действующий, заменённый, черновик, неподтверждённое сообщение.
6. Опишите область применения: к каким вопросам документ относится.

После разметки видны основания выбора. Если дата обновления не совпадает с датой вступления правила в силу, используйте поле действия правила. Если статус или область применения неясны, оставьте конфликт открытым для проверки человеком.

Выбор актуального документа при конфликте версий

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

Разберём это на учебном примере. Возьмём карту контекста для ответа сотруднику о доставке заказа Z-17. Условные входные данные выглядят так:

RULES: отвечать только по приложенным действующим документам;
       неизвестное назвать неизвестным;
       персональные сведения не включать.
POLICY-old (01.08.2026): доставка 5 рабочих дней.
POLICY-current (01.11.2026): доставка 3 рабочих дня; действие с 01.11;
       исключений в документе нет.
ORDER (10.11.2026): Z-17, город Казань, принят 10.11,
       отправка ещё не подтверждена, срок доставки в карточке не указан.
HISTORY: прошлый вопрос клиента о красном цвете упаковки;
       к текущему сроку не относится.
NOTE: менеджер устно обещал завтра, письменного подтверждения нет.
CRM-extra: личный телефон клиента; для ответа о сроке не нужен.
TASK: объясни стандартный срок и сообщи, известна ли дата прибытия Z-17.

Здесь конфликт очевиден: POLICY-old говорит о пяти рабочих днях, POLICY-current — о трёх. У текущего документа явно задано действие с 01.11.2026;01.08.2026 у старого документа — дата в учебном входе. Заказ принят 10.11.2026, то есть после вступления в силу новой редакции. Приоритет отдаётся POLICY-current, а POLICY-old помечается заменённой и в действующий набор не попадает.

Отдельно разбирается NOTE. Устное обещание менеджера не имеет письменного подтверждения, поэтому сохраняется как расхождение, но не выдаётся за факт. Это соответствует правилу из RULES: неизвестное называется неизвестным.

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

Порядок выбора при конфликте:

1. Отфильтруйте документы со статусом «заменённый».
2. Среди оставшихся сравните даты вступления в силу.
3. Проверьте, попадает ли событие задачи в период действия документа.
4. Сверьте область применения: документ должен относиться к заданному вопросу.
5. При противоречии признаков зафиксируйте неопределённость и передайте решение человеку.

Запись, выбор, сжатие и изоляция контекста

LangChain группирует стратегии в четыре категории: запись, выбор, сжатие и изоляция. Запись сохраняет сведения вне окна; выбор возвращает нужное в текущий вызов; сжатие уменьшает объём; изоляция разделяет контекст между частями системы. В том же разборе scratchpad показан как файл или поле состояния. Документация LangChain описывает цикл агента через вызов модели и исполнение запрошенных инструментов.

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

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

Условия и неизвестное при сжатии

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

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

• дату актуальности правила;
• стандартный срок — 3 рабочих дня по POLICY-current;
• факт неподтверждённой отправки;
• идентификаторы POLICY-current и ORDER.

Замена «3 рабочих дня» на «завтра» из NOTE считается ошибкой сжатия: устное обещание менеджера не имеет письменного подтверждения и не может подменять действующий регламент. Точно так же потеря фразы о неподтверждённой отправке превращает честное «дата прибытия неизвестна» в ложное утверждение о конкретном сроке.

Проверка сжатия строится на сравнении с ручным эталоном. Ручной эталон для этого примера: стандарт — 3 рабочих дня по POLICY-current; точная дата прибытия заказа Z-17 неизвестна, поскольку отправка не подтверждена. Любая сжатая заметка, из которой нельзя восстановить оба этих утверждения, не проходит проверку.

Порядок работы со сжатием:

1. Сформулируйте, какие утверждения обязаны выжить: числа, даты, идентификаторы, статусы неопределённости.
2. Напишите промпт сжатия так, чтобы он сначала захватывал всё значимое.
3. Прогоните сжатие на полном входе.
4. Сравните результат с ручным эталоном по каждому обязательному элементу.
5. Уберите лишнее, повторяя проверку после каждого прохода.

Для воспроизведения сжатия используйте инструкцию:

Составь заметку для ответа о Z-17. Сохрани ID источников, срок действующего правила и дату его действия, статус отправки и неизвестность даты прибытия. Отдельно пометь неподтверждённое обещание. Исключи нерелевантную историю и личный телефон. Не вычисляй календарную дату по отсутствующим условиям.

Ручная заметка-эталон:

POLICY-current: доставка 3 рабочих дня, действие с 01.11.2026. ORDER от 10.11.2026: заказ Z-17 принят, отправка не подтверждена; точная дата прибытия неизвестна. NOTE: обещание завтра письменно не подтверждено.

Пробелы и стиль могут отличаться, но источники, числа и статусы должны сохраняться.

Сравнение с ручным эталоном на полном входе

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

Для примера с заказом Z-17 полный вход включает восемь маркированных блоков: RULES, POLICY-old, POLICY-current, ORDER, HISTORY, NOTE, CRM-extra, TASK. Вопрос уже записан в TASK. Ручной эталон ответа: стандартный срок доставки — 3 рабочих дня по действующему регламенту; точная дата прибытия заказа неизвестна, поскольку отправка не подтверждена.

Сравнение идёт по трём осям. Первая — факты: совпадают ли числа и даты с эталоном. Вторая — статусы: помечено ли неизвестное как неизвестное, отделено ли неподтверждённое от подтверждённого. Третья — состав: не попали ли в ответ элементы, которые в эталоне отсутствуют.

Карта решения по каждому блоку должна быть заполнена до ответа:

Здесь NOTE не становится ещё одним правилом доставки. Его задача — объяснить расхождение между устным обещанием и тем, что можно установить по документам. В коротком ответе клиенту достаточно указать стандарт и неизвестность даты; в рабочем журнале менеджера полезно оставить необходимость проверить обещание. Для разных адресатов состав заметки может отличаться при тех же фактах.

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

1. Выпишите эталонные утверждения до того, как смотреть на результат.
2. Сверьте числа и даты.
3. Проверьте, названо ли неизвестное неизвестным.
4. Найдите в результате элементы, которых нет в эталоне.
5. Зафиксируйте расхождения и вернитесь к шагу отбора.

Разберём ответы на том же входе. Плохой ответ:

Z-17 приедет завтра: менеджер уже подтвердил доставку.

Здесь два нарушения: NOTE превращён в подтверждение, а точная дата придумана. Исправить только слово «завтра» недостаточно: фраза «менеджер подтвердил» тоже не имеет опоры.

Другой плохой ответ:

Стандарт — 5 рабочих дней, телефон клиента можно уточнить в CRM.

Он использует заменённый POLICY-old и добавляет нерелевантные личные сведения. Красивое оформление и ссылка на ORDER этих ошибок не исправляют: ORDER не задаёт стандартный срок и не подтверждает телефон как нужную часть ответа.

Корректный ручной вариант:

По POLICY-current, действующему с 01.11.2026, стандартный срок доставки составляет 3 рабочих дня. Для Z-17 точная дата прибытия неизвестна: в ORDER от 10.11.2026 отправка ещё не подтверждена.

Это редакционный эталон по условному входу. Генерация моделью не выполнялась.

Отдельная проверка календаря: принятие заказа 10.11 не означает начало отсчёта доставки. В регламенте примера не задано событие, с которого считают срок, и в карточке нет подтверждённой отправки. Поэтому вычисление даты прибытия потребовало бы дополнительных правил и фактов. Их нельзя получить простым сложением числа рабочих дней с датой принятия.

Если ответ называет только стандарт, но пропускает неизвестную дату, он закрывает лишь часть TASK. Если сообщает только «неизвестно», он теряет доступный стандарт из POLICY-current. Ручной эталон требует обе части; проверка по одному ключевому слову не обнаружит неполноту.

Ограничения автоматического извлечения и памяти

Anthropic рассматривает окно как ограниченный ресурс и описывает снижение точности извлечения при росте контекста. LangChain перечисляет poisoning, distraction, confusion и clash: неверные сведения могут попасть в контекст, отвлечь модель или столкнуться с другими данными. Эти описания не задают измеренную вероятность ошибки для Z-17.

В нашем примере поиск должен вернуть применимый POLICY-current и ORDER. Если он найдёт только старый регламент, последующая аккуратная формулировка всё равно будет опираться на неправильный вход. Проверяйте не только ответ, но и набор документов до генерации. Если отсутствует нужная редакция, результат отбора следует пометить неполным и запросить документ.

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

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

Сжатая заметка — производный материал. Если после её чтения возник новый вопрос об исключениях, вернитесь к полному регламенту. Отсутствие исключения в резюме не доказывает, что его не было в документе. В нашем условном POLICY-current отсутствие исключений задано явно; переносить это условие на чужие правила нельзя.

Отделяйте проверку доступа от проверки релевантности. Доступный пользователю документ может быть не нужен для ответа; нужный документ может требовать разрешения. В примере CRM-extra исключён по задаче независимо от технической возможности прочитать телефон. В рабочем процессе отбор должен учитывать оба ограничения, а журналу достаточно зафиксировать причину исключения без копирования личных данных.

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

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

Чем context engineering отличается от промпт-инжиниринга?

Инструкции составляют часть контекста. Context engineering также управляет внешними данными, историей и результатами инструментов; IBM включает prompt engineering в эту более широкую дисциплину.

Что такое context engineering skill?

В этом материале речь о навыке: собрать подходящие сведения, проверить их происхождение и сохранить существенные условия при сжатии. Для заказа Z-17 результатом навыка служат заполненная карта отбора и проверенный ответ.

Как context engineering связан с Claude?

Anthropic использует Claude Code как пример работы с контекстом: загрузку сведений по указателям, заметки и компакцию длинного разговора. Конкретные механизмы и настройки продукта следует сверять с его действующей документацией.

Какие четыре стратегии работы с контекстом выделяют?

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

Почему длинный контекст ухудшает ответы?

Anthropic описывает снижение точности извлечения при росте контекста. Для конкретной задачи качество нужно проверять: в примере сверяются выбранные документы, срок и неизвестность даты прибытия.