Контекстная инженерия — что это простыми словами

Зачем это знать

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

Что такое контекстная инженерия простыми словами

Новому сотруднику в первый день дают не только задачу. Дают доступ к папке с договорами, регламент, телефон старшего, право посмотреть историю клиента. Задача звучит одинаково для всех — «разберись с обращением», а результат зависит от того, что человеку выдали на руки.

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

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

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

Сборка идёт по шагам, и каждый шаг — отдельное решение, которое кто-то принимает.

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

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

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

Компания на 40 менеджеров разбирает около 6 000 обращений в месяц. Работает ИИ-агент на базе поиска по документам: в запрос уходит инструкция, десять найденных фрагментов регламента и вся переписка целиком — порядка 14 000 входных токенов на обращение.

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

Входной объём — около 4 200 токенов. Долю обращений, где ответ пришлось править, мерили на одной выборке из 200 разборов до и после: она снизилась с 31% до 19%. Цифры расчётные, для компании такого профиля, а не отчёт по внедрению; методика повторяется на своих данных.

Что это даёт бизнесу

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

Когда без этого можно обойтись

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

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

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

Что важно проверить

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

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

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