Инжиниринг контекста для ИИ-агентов: формирование того, что видит модель
Почему качество работы агентов снижается по мере увеличения объема контекста, в чем разница между проектированием контекста и формулировкой промптов, а также простая схема для выбора того, что будет видеть каждый вызов модели.
Искусственный интеллект-агент, который хорошо справляется с первыми несколькими шагами, а затем начинает игнорировать инструкции, повторять работу или полагаться на устаревшие данные, обычно не сталкивается с проблемами формулировок. У него проблема с контекстом: модель видит слишком много информации, неверные данные или верные данные в неправильном месте. Инжиниринг контекста — это дисциплина, направленная на точное определение того, что получает модель непосредственно перед принятием решений, то есть не только запрос, но и весь набор инструкций, истории, полученных данных и определений инструментов. В этом руководстве объясняется, почему этот набор данных становится всё более важным по мере развития агентов, какие четыре компонента находятся под вашим контролем, как выглядит минимальный процесс сборки и какие паттерны сбоев следует учитывать.
Основная идея: небольшой, релевантный фрагмент
Цель заключается не в том, чтобы дать модели всё, что только может помочь. Необходимо предоставить ей лишь ту узкую часть информации, которая действительно позволяет ей правильно ответить, оставив всё остальное без внимания.
Аналогия с человеком помогает это проиллюстрировать. Попросите нового инженера исправить баг в кодовой базе из миллиона строк, сказав ему «прочитайте код и найдите проблему», — он будет ошеломлён, ведь единственный значимый файл потерян среди тысяч других. Скажите тому же инженеру «проблема, скорее всего, в модуле оплаты, эти три файла были изменены на прошлой неделе, и вот что пытался сделать предыдущий пользователь», — и решение может быть найдено за несколько минут. Сам инженер не изменился, изменилась лишь информация, с которой он начал работу.
Модели ведут себя аналогичным образом. Инжиниринг контекста — это процесс передачи именно этих трёх файлов вместо всего репозитория.
Почему одних лишь формулировок уже недостаточно
Первоначальные рекомендации по работе с языковыми моделями касались формулировок: как составлять инструкции и какие формулировки приводят к лучшим ответам. Это и есть инжиниринг промптов, и для одного вопроса это по-прежнему имеет значение.
Однако агент не отвечает на один вопрос. Он выполняет цикл: читает что-то, вызывает инструмент, получает результат, выбирает следующее действие и повторяет процесс, иногда десятки раз. С каждой итерацией к информации, которую хранит модель, добавляется ещё больше материала. В конечном итоге накопленный контекст становится настолько обширным, что важные детали упускаются из виду, примерно как у человека, который провёл весь день на собраниях и уже не может вспомнить, что было решено на первом из них.
Anthropic рассматривает инжиниринг контекста как задачу поиска наилучшего возможного набора информации для модели в каждый конкретный момент, а не создания одной хорошей инструкции заранее. Это отражает сдвиг: инжиниринг промптов касается слов, тогда как инжиниринг контекста включает всё, что присутствует в момент ответа модели.
Инжиниринг промптов против инжиниринга контекста
Эти подходы пересекаются, но отличаются по объему, типичному применению и способам сбоев:
- Объем. Инжиниринг промптов формирует формулировку одной инструкции. Инжиниринг контекста управляет всем входным материалом: инструкциями, предыдущими диалогами, полученными фактами и доступными инструментами.
Краткий диагноз: если ваше решение заключается в замене слов, вы занимаетесь инжинирингом промптов. Если ваше решение меняет информацию, которую модель получает изначально, вы занимаетесь инжинирингом контекста. Чтобы узнать структурированный способ определения того, к какому уровню относится сбой агента, ознакомьтесь с отладкой ИИ-агентов по уровням.
Четыре компонента, которыми вы управляете
Контекст каждого агента формируется из четырех источников. У каждого из них есть свои особенности, приводящие к сбоям.
Инструкции: описание задачи
Это системный промпт, описывающий, что и как должен делать агент. Если он слишком жесткий, агент не сможет справиться ни с чем, что выходит за рамки заданного сценария. Если он слишком свободный, агент будет действовать произвольно. Стремитесь к инструкциям, достаточно конкретным для формирования поведения агента, но без попыток заранее перечислить все возможные ситуации.
Поиск информации: исследовательский ассистент
Поиск информации заключается в получении внешних данных путем поиска в документах, запросов к базе данных или чтения файлов. Некачественный поиск является основной причиной того, что системы искусственного интеллекта с уверенностью выдвигают неверные утверждения. Часто модель ничего не выдумывает; ей предоставляются неверные или нерелевантные факты, и она обоснованно полагается на них. Улучшение качества получаемой информации часто способствует повышению точности больше, чем любые изменения в запросе.
Память: блокнот
Память включает в себя то, что агент сохраняет как в рамках одного диалога, так и между сессиями. Без механизма для обобщения и удаляния старых данных память теряет свою полезность. Она постоянно растет, пока большая её часть не превращается в шум, конкурирующий с информацией, которая имеет значение в данный момент.
Инструменты: набор инструментов
Инструменты определяют действия, которые может выполнять агент, такие как поиск в интернете, выполнение кода или отправка электронных писем. Название и описание каждого инструмента также вносят свой вклад в контекст. Набор из десяти перекрывающихся, почти идентичных инструментов сбивает с толку модель так же, как десять неотличимых отверток сбили бы с толку нового сотрудника. Меньшее количество инструментов с четко определенными функциями облегчает выбор и снижает затраты.
Минимальная цепочка обработки контекста
В следующем псевдокоде показано, как эти четыре компонента объединяются для одного вызова модели. Вспомогательные функции являются заменителями для любых методов поиска, ранжирования и обобщения, которые вы используете, но структура отражает подход реальных систем к решению проблемы.
Этот процесс работает в четыре этапа. Сначала происходит широкий поиск с допуском некоторого количества ошибок, при этом ограничение составляет 50 кандидатов. Затем эти кандидаты ранжируются, и сохраняются только пять лучших. Далее история разговора сжимается в краткое резюме объемом до 500 единиц вместо полного воспроизведения. Наконец, элементы результата упорядочиваются таким образом, чтобы сначала шли инструкции, а в конце — текущий вопрос, причем результат сокращается до установленного лимита токенов.
def get_context_for_the_model(question, past_conversation, budget):
# Step 1: Cast a wide net — search broadly, don't worry about noise yet
possible_facts = search_everywhere(question, limit=50)
# Step 2: Narrow it down - keep only the genuinely relevant ones
best_facts = keep_most_relevant(possible_facts, top=5)
# Step 3: Summarize old conversation instead of keeping all of it
short_memory = summarize(past_conversation, max_length=500)
# Step 4: Put the most important things first and last, not buried in the middle
final_context = [
job_description, # instructions
short_memory, # memory
*best_facts, # retrieval
question, # what's being asked right now, last
]
return trim_to_fit(final_context, budget)
В этом примере есть две привычки, которые стоит перенять.
Сначала проводите широкий поиск, затем узкий. Широкий поиск снижает вероятность пропуска релевантного документа, а строгий ранжирование позволяет сократить объем итогового контекста. Если использовать только первый подход, модель будет перегружена, а если только второй — существует риск так и не найти подходящий материал.
Поместите важное на края. Размещайте самый важный контент в начале или в конце текста, а не посередине. Это не стилистическое предпочтение. Исследования длинных текстов неоднократно показывали, что модели менее надежно обращают внимание на информацию, находящуюся посередине длинного контекста; этот эффект часто называется «потерян в середине». Степень выраженности этого эффекта варьируется в зависимости от модели, поэтому тестируйте его с использованием вашей собственной конфигурации, но изменение порядка — это простой способ улучшить результат в любом случае.
Из той же логики следуют несколько практических рекомендаций. Заранее определите, как будет распределяться бюджет между различными компонентами, чтобы большой объем полученных результатов не мог незаметно заслонить инструкции. При сокращении списка сначала удаляйте наименее релевантные элементы, прежде чем вмешиваться в инструкции или текущий вопрос. Также фиксируйте итоговый собранный контекст для каждого запроса; если агент ведет себя неправильно, эта запись обычно показывает причину.
Что происходит, когда контекст не отбирается тщательно
Включение всего ради безопасности
Добавление каждого возможно релевантного элемента кажется ответственным подходом, но часто приводит к обратному эффекту. Чем больше нерелевантных данных должен просматривать модель, тем хуже у нее получается найти единственный важный факт. Это эквивалентно чтению столбцовой записки объемом в сто страниц перед принятием решения, занимающего пять минут.
Устаревшая информация
Если ничто не проверяет, остаётся ли полученный контент актуальным, модель будет формировать уверенный ответ на основе информации, которая уже не соответствует действительности месяцы назад. Метаданные о свежести, правила истечения срока действия или повторная верификация для временно чувствительных источников — всё это помогает.
Скрытие ключевого факта
Даже когда система поиска находит именно тот факт, его размещение в середине длинного блока увеличивает статистические шансы на его пропуск. Сам факт остаётся тем же; меняется лишь его положение, и результат становится хуже.
Слишком много похожих вариантов
Если сотрудник вашей команды не может с уверенностью сказать, какой инструмент или документ подходит в данной ситуации, модель не покажет лучших результатов. Объедините перекрывающиеся инструменты и удалите почти идентичные документы до того, как они попадут в контекст.
Частые вопросы
Заменяет ли инжиниринг контекста инжиниринг промптов?
Нет. Чёткие инструкции по-прежнему являются частью задачи. Инжиниринг контекста — это более общая задача, которая включает в себя определение того, что ещё видит модель помимо самой инструкции.
Почему больше информации может ухудшить результаты?
Внимание — ограниченный ресурс как для моделей, так и для людей. Чем больше материала должна обработать модель, тем выше вероятность того, что она пропустит единственную важную деталь, так же как человеку бывает трудно найти одну важную строку в длинном документе.
Решает ли более большое окно контекста проблему?
Оно помогает, предоставляя дополнительное пространство, но не устраняет основную проблему. Информация, находящаяся в середине длинных вводов, по-прежнему используется с меньшей надёжностью, а задержки и затраты растут по мере увеличения объёма ввода. Выбор того, что будет включено, остаётся важным даже при очень больших окнах контекста.
Основные выводы
- Рассматривайте входные данные модели как специально созданный элемент, собираемый для каждого вызова, а не как простой журнал записей.
- Сознательно управляйте всеми четырьмя компонентами: инструкциями, процессом поиска информации, памятью и инструментами — каждый из них может сработать некорректно по-своему.
- Проводите широкий поиск, строго оценивайте результаты, обобщайте историю операций и размещайте важный контент в начале или в конце.
- Когда агент начинает показывать снижение качества работы на протяжении нескольких шагов, изучите данные, которые ему были предоставлены, прежде чем переписывать полученные инструкции.
- Более большой объем данных даёт лишь дополнительное пространство, но не защиту; ключевым требованием по-прежнему остаётся передача именно трех необходимых файлов, а не всей базы кода.