Узнайте, как оптимизировать контекст ваших агентов для повышения их эффективности.
Делиться
Контекстная инженерия привлекла серьёзное внимание с появлением LLM, способных решать сложные задачи. Изначально большинство обсуждений в этом докладе вращалось вокруг конструирования подсказок: настройки одной подсказки для оптимизации производительности при выполнении одной задачи. Однако по мере роста возможностей LLM конструирование подсказок превратилось в контекстную инженерию: оптимизацию всех данных, которые вы загружаете в LLM, для максимальной производительности при выполнении сложных задач.
В этой статье я подробнее расскажу об агентной контекстной инженерии, которая заключается в оптимизации контекста специально для агентов. Этот подход отличается от традиционной контекстной инженерии тем, что агенты обычно выполняют последовательности задач в течение более длительного периода времени. Поскольку агентная контекстная инженерия — обширная тема, я подробнее рассмотрю перечисленные ниже темы и напишу дополнительную статью, охватывающую больше тем.
- Специальные советы по проектированию контекста
- Сокращение/обобщение контекста
- Использование инструмента
Зачем нужна агентная контекстная инженерия
Прежде чем углубляться в специфику контекстной инженерии, я расскажу, почему она так важна. Я расскажу об этом в двух частях:
- Почему мы используем агентов
- Почему агентам нужна контекстная инженерия
Почему мы используем агентов
Прежде всего, мы используем агенты, поскольку они более способны выполнять задачи, чем статические LLM-вызовы. Агенты могут получать запросы от пользователя, например:
Исправьте эту ошибку, о которой сообщил пользователь {отчет об ошибке}
Это было бы невозможно в рамках одного вызова LLM, поскольку необходимо лучше понять ошибку (возможно, спросить того, кто о ней сообщил), понять, где в коде она возникает, и, возможно, получить некоторые сообщения об ошибках. Здесь на помощь приходят агенты.
Агент может просмотреть ошибку, вызвать инструмент и задать пользователю уточняющий вопрос, например: «Где в приложении возникает эта ошибка?». Затем агент может найти это место в кодовой базе, запустить сам код для чтения журналов ошибок и применить исправление. Всё это требует серии вызовов LLM и инструментов, прежде чем проблема будет решена.
Почему агентам нужна контекстная инженерия
Итак, теперь мы знаем, зачем нам нужны агенты, но зачем агентам контекстная инженерия? Главная причина заключается в том, что LLM всегда работают лучше, когда их контекст содержит больше релевантной информации и меньше шума (нерелевантной информации). Более того, контекст агентов быстро накапливается, когда они выполняют серию вызовов инструментов, например, извлекают журналы ошибок при возникновении ошибки. Это приводит к раздуванию контекста, когда контекст LLM содержит много нерелевантной информации. Нам необходимо удалить эту шумную информацию из контекста LLM, а также обеспечить наличие всей релевантной информации в контексте LLM.
Специальные советы по проектированию контекста
Агентная разработка контекста основана на традиционной разработке контекста. Поэтому я включаю несколько важных моментов для улучшения вашего контекста.
- Обучение за несколько попыток
- Структурированные подсказки
- Пошаговое рассуждение
Это три широко используемых метода в контекстной инженерии, которые часто повышают успеваемость LLM.
Обучение за несколько попыток
Обучение с малым количеством попыток — это распространённый подход, при котором перед передачей агенту задачи, которую он должен выполнить, вы включаете примеры похожей задачи. Это помогает модели лучше понять задачу, что обычно повышает её производительность.
Ниже представлены два примера подсказок. В первом примере показана подсказка с нулевым результатом, где мы напрямую задаём вопрос LLM. Учитывая, что это простая задача, LLM, скорее всего, даст правильный ответ; однако обучение с небольшим количеством попыток будет более эффективным в более сложных задачах. Во втором примере я привожу несколько примеров выполнения математических вычислений, которые также заключены в XML-теги. Это не только помогает модели понять, какую задачу она выполняет, но и обеспечивает единообразный формат ответа, поскольку модель часто будет отвечать в том же формате, что и в примерах с небольшим количеством попыток.
# подсказка с нулевым числом = «Сколько будет 123+150?» # подсказка с несколькими числами = «»»
Структурированные подсказки
Структурированные подсказки также невероятно важны при проектировании контекста. В приведённых выше примерах кода вы можете видеть, как я использую XML-теги с
Вы можете использовать специальные инструменты, например, оптимизатор подсказок Anthropic, но также можете просто загрузить неструктурированную подсказку в ChatGPT и попросить её улучшить. Более того, вы получите ещё более качественные подсказки, если опишите ситуации, в которых ваша текущая подсказка вызывает проблемы.
Например, если у вас есть математический агент, который хорошо справляется со сложением, вычитанием и делением, но испытывает трудности с умножением, вам следует добавить эту информацию в оптимизатор подсказок.
Пошаговое рассуждение
Пошаговое обоснование — ещё один мощный подход к построению контекста. Вы побуждаете магистра права (LLM) шаг за шагом обдумывать, как решить проблему, прежде чем приступить к её решению. Для ещё более эффективного построения контекста можно объединить все три подхода, описанные в этом разделе, как показано в примере ниже:
# несколько примеров + структурированный + пошаговый пример рассуждения prompt = «»»
Это поможет модели еще лучше понимать примеры, что зачастую еще больше повышает ее производительность.
Сокращение контекста
После того, как ваш агент выполнил несколько шагов, например, запросил ввод данных пользователем, получил информацию и т. д., вы можете столкнуться с переполнением контекста LLM. Прежде чем достичь лимита и потерять все токены, превышающие этот лимит, следует сократить контекст.
Резюмирование — отличный способ сократить контекст, однако иногда оно может вырезать важные фрагменты. Первая половина контекста может не содержать никакой полезной информации, в то время как вторая половина включает несколько необходимых абзацев. Это одна из причин сложности агентной разработки контекста.
Для сокращения контекста обычно используется другая степень магистра права (LLM), которую я буду называть «сокращением LLM». Эта степень магистра права (LLM) получает контекст и возвращает его сокращённую версию. Простейшая версия «сокращения LLM» просто суммирует контекст и возвращает его. Однако для улучшения сокращения можно использовать следующие приёмы:
- Определите, можно ли вырезать целые части контекста (конкретные документы, предыдущие вызовы инструментов и т. д.)
- Настроенная на подсказки программа обучения сокращению LLM, оптимизированная для анализа поставленной задачи, содержит всю необходимую информацию и возвращает только ту информацию, которая будет иметь отношение к решению задачи.
Определите, можно ли вырезать целые части.
Первое, что следует сделать при попытке сократить контекст, — это найти те его части, которые можно полностью вырезать.
Например, если LLM ранее извлёк документ, использованный для решения предыдущей задачи, в котором у вас есть результаты этой задачи. Это означает, что документ больше не актуален и его следует удалить из контекста. Это также может произойти, если LLM извлёк другую информацию, например, через поиск по ключевым словам, и сам обобщил результаты поиска. В этом случае следует удалить старые результаты из поиска по ключевым словам.
Простое удаление таких целых частей контекста может значительно сократить его продолжительность. Однако следует помнить, что удаление контекста, который может быть полезен для последующих задач, может негативно сказаться на производительности агента.
Таким образом, как отмечает Anthropic в своей статье о контекстной инженерии, сначала следует оптимизировать полноту, гарантируя, что LLM-сокращенер никогда не удалит контекст, который будет актуален в будущем. Добившись практически идеальной полноты, можно начать работать над точностью, удаляя всё больше и больше контекста, который больше не важен для решения текущей задачи.
Быстрое сокращение LLM
Я также рекомендую создать LLM-программу сокращения, настроенную на подсказки. Для этого сначала необходимо создать тестовый набор контекстов и желаемый сокращённый контекст, исходя из поставленной задачи. Желательно, чтобы эти примеры были взяты из реальных взаимодействий пользователей с вашим агентом.
Продолжая, вы можете оптимизировать (или даже подстроить) сокращение LLM для задачи резюмирования контекста LLM, чтобы сохранить важные части контекста, удалив другие части контекста, которые больше не актуальны.
Инструменты
Одним из основных отличий агентов от разовых вызовов LLM является использование ими инструментов. Обычно мы предоставляем агентам набор инструментов, которые они могут использовать для повышения своей способности решать задачи. Примеры таких инструментов:
- Выполнить поиск по ключевым словам в корпусе документов
- Получить информацию о пользователе по его адресу электронной почты
- Калькулятор для сложения чисел
Эти инструменты упрощают задачу, которую должен решить агент. Агент может выполнить поиск по ключевым словам для получения дополнительной (часто необходимой) информации или использовать калькулятор для сложения чисел, что гораздо более последовательно, чем сложение чисел с использованием прогнозирования следующего токена.
Вот несколько приемов, которые следует иметь в виду, чтобы обеспечить правильное использование инструментов при предоставлении инструментов в контексте агента:
- Хорошо описанные инструменты (может ли человек это понять?)
- Создайте специальные инструменты
- Избегайте вздутия живота
- Показывать только релевантные инструменты
- Информативная обработка ошибок
Хорошо описанные агентские инструменты
Первое и, пожалуй, самое важное замечание — наличие хорошо описанных инструментов в вашей системе. Определяемые вами инструменты должны иметь аннотации типов для всех входных параметров и возвращаемого типа. Также должно быть хорошее имя функции и описание в строке документации. Ниже представлен пример плохого и хорошего определения инструмента:
# плохое определение инструмента def calculator(a, b): return a+b # хорошее определение инструмента def add_numbers(a: float, b: float) -> float: «»»Функция для сложения двух чисел. Должна использоваться в любое время, когда нужно сложить два числа. Принимает параметры: a: float b: float Возвращает float «»» return a+b
Вторая функция в приведённом выше коде гораздо проще для понимания агентом. Правильное описание инструментов поможет агенту лучше понимать, когда использовать тот или иной инструмент, а когда лучше использовать другие подходы.
Ориентировочный показатель хорошо описанного инструмента:
Может ли человек, никогда раньше не видевший этих инструментов, понять их, просто взглянув на функции и их определения?
Специальные инструменты
Также старайтесь, чтобы ваши инструменты были максимально конкретными. Если вы описываете инструменты расплывчато, магистрам права сложно понять, когда их использовать, и убедиться, что они используют их правильно.
Например, вместо определения универсального инструмента, с помощью которого агент будет извлекать информацию из базы данных, следует предоставить специальные инструменты для извлечения определенной информации.
Плохой инструмент:
- Извлечь информацию из базы данных
- Вход
- Столбцы для извлечения
- Индекс базы данных для поиска информации
Лучшие инструменты:
- Извлечь информацию обо всех пользователях из базы данных (без входных параметров)
- Получить отсортированный список документов по дате, относящийся к указанному идентификатору клиента.
- Получите сводный список всех пользователей и действий, которые они совершили за последние 24 часа.
Затем, когда возникнет необходимость, вы сможете определить более конкретные инструменты. Это упростит агенту извлечение релевантной информации из контекста.
Избегайте вздутия живота
Также следует избегать раздувания любой ценой. Существует два основных подхода к достижению этой цели с помощью функций:
- Функции должны возвращать структурированные выходные данные и, при необходимости, возвращать только подмножество результатов.
- Избегайте нерелевантных инструментов
Для первого пункта я снова приведу пример поиска по ключевым словам. При поиске по ключевым словам, например, в AWS Elastic Search, вы получите много информации, иногда не очень структурированной.
# плохая функция return def keyword_search(search_term: str) -> str: # выполнить поиск по ключевым словам # результаты: {«id»: …, «content»: …, «createdAt»: …, …}, {…}, {…}] return str(results) # хорошая функция return def _organize_keyword_output(results: list[dict], max_results: int) -> str: output_string = «» num_results = len(results) for i, res in enumerate(results[:max_results]): # max return max_results output_string += f»Номер документа {i}/{num_results}. ID: {res[«id»]}, content: {res[«content»]}, created at: {res[«createdAt»]}» return output_string def keyword_search(search_term: str, max_results: int) -> str: # выполнить поиск по ключевым словам # результаты: {«id»: …, «content»: …, «createdAt»: …, …}, {…}, {…}] организованные_результаты = _organize_keyword_output(results, max_results) вернуть организованные_результаты
В неудачном примере мы просто преобразуем в строку необработанный список словарей, возвращаемый поиском по ключевым словам. Более удачный подход — использовать отдельную вспомогательную функцию для структурирования результатов в структурированную строку.
Также следует убедиться, что модель может возвращать только подмножество результатов, как показано с помощью параметра max_results. Это очень помогает модели, особенно при работе с такими функциями, как поиск по ключевым словам, которые потенциально могут возвращать сотни результатов, мгновенно заполняя контекст LLM.
Источник: towardsdatascience.com
