Антроп обобщает простые и эффективные способы построения эффективного интеллекта

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

В этом посте мы поделимся своим опытом работы с клиентами и создания агентов, а также дадим разработчикам практические советы по созданию эффективных агентов.

Интеллигент/агент/агент имеет то же значение в следующем.

Что такое агент?

Понятие "агент" можно определить по-разному. Некоторые заказчики определяют агентов как полностью автономные системы, которые могут работать независимо в течение длительного времени, используя различные инструменты для выполнения сложных задач. Другие используют его для описания более предписывающих реализаций, которые следуют заранее определенным рабочим процессам. В Anthropic мы называем эти варианты в совокупности Агрегированные системыНо существует архитектурная проблема, связанная с рабочий процесс ответить пением действовать от имени кого-л., занимая ответственную должность Были проведены важные различия:

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

Ниже мы рассмотрим эти две агентированные системы более подробно. В Приложении 1 ("Агенты на практике") мы описываем две области, в которых использование этих систем клиентами было особенно ценным.

Когда (и когда) использовать прокси-серверы

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

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

Когда и как использовать рамки

Существует ряд фреймворков, облегчающих реализацию агентированных систем, в том числе:

• LangGraph Из LangChain;
• Amazon Bedrock's Структура агента искусственного интеллекта.;
• ЗаклепкиКонструктор рабочих процессов LLM - это графический интерфейс построения рабочих процессов LLM с возможностью перетаскивания;
• ВеллумЕще один инструмент с графическим интерфейсом для создания и тестирования сложных рабочих процессов.

Эти фреймворки облегчают процесс разработки, упрощая стандартные низкоуровневые задачи, такие как вызов LLM, определение и разбор инструментов, а также связывание вызовов воедино. Однако они, как правило, добавляют дополнительные уровни абстракции, которые могут скрывать основные подсказки и ответы, что затрудняет отладку. Это также может склонить чашу весов в пользу увеличения сложности, в то время как на самом деле может быть достаточно более простой настройки.

Мы рекомендуем разработчикам сначала использовать непосредственно LLM API: многие паттерны можно реализовать с помощью нескольких строк кода. Если вы используете фреймворк, убедитесь, что вы понимаете основной код. Ложные предположения о логике, лежащей в основе фреймворка, - частый источник клиентских ошибок.

Смотрите наш кулинарная книга для некоторых примеров реализации.

Строительные блоки, рабочие процессы и агенты

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

Строительные блоки: расширенный LLM

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

Расширенная программа LLM

Мы рекомендуем сосредоточиться на двух ключевых аспектах реализации: настройке этих функций под ваш конкретный случай использования и обеспечении простого в использовании и хорошо документированного интерфейса к LLM. Хотя эти усовершенствования могут быть реализованы различными способами, один из подходов заключается в использовании нашего недавно выпущенного протокола Model Context Protocol, который позволяет разработчикам интегрироваться в растущую экосистему сторонних инструментов с помощью простой реализации на стороне клиента.

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

Рабочий процесс: цепочка подсказок

Цепочка подсказок разбивает задачу на ряд шагов, причем каждый вызов Large Language Model (LLM) обрабатывает результат предыдущего шага. Вы можете добавить процедурные проверки (см. "ворота" на рисунке ниже) на любом промежуточном шаге, чтобы убедиться, что процесс все еще идет по правильному пути.

Рабочий процесс цепочки реплик

Когда использовать этот рабочий процесс:
Этот рабочий процесс идеален, когда задачи можно легко и четко разбить на фиксированные подзадачи. Основная цель - повысить точность и сократить время ожидания за счет упорядочивания каждого вызова LLM на более управляемые задачи.

Примеры применения цепочки подсказок:

• Создавайте маркетинговые копии и переводите их на разные языки.
• Составьте набросок документа, проверьте, соответствует ли он определенным критериям, а затем напишите документ на основе наброска.

Рабочий процесс: маршрутизация

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

рабочий процесс маршрутизации

Когда использовать этот рабочий процесс:
Маршрутизация рабочих процессов хорошо работает, когда сложные задачи имеют различные категории, которые нужно обрабатывать отдельно, и классификация может быть точно обработана LLM или более традиционными моделями/алгоритмами классификации.

Примеры применимости маршрутизации:

• Направляйте различные типы запросов в службу поддержки клиентов (общие вопросы, запросы на возврат средств, техническая поддержка) на различные процессы, советы и инструменты.
• Переносите простые/обычные проблемы на более мелкие модели (например. Клод 3.5 Haiku), а сложные/необычные задачи передавать более мощным моделям (например, Claude 3.5 Sonnet), чтобы оптимизировать затраты и скорость.

Рабочий процесс: распараллеливание (Распараллеливание)

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

• Секционирование: Декомпозиция задач на независимые подзадачи, которые могут выполняться параллельно.
• Голосование: Запустите одно и то же задание несколько раз, чтобы получить разные результаты.

Распараллеленные рабочие процессы

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

Примеры применения параллелизма:

• Секционирование:
  • Реализуйте защиту, когда один экземпляр модели обрабатывает запросы пользователей, а другой проверяет их на наличие неприемлемого содержимого или запросов. Это обычно лучше, чем если бы один и тот же вызов LLM обрабатывал и охранные запросы, и ответ ядра.
  • Автоматизированная оценка производительности LLM, где каждый вызов LLM оценивает различные аспекты производительности модели на заданном сигнале.
• Голосование:
  • Проверка кода на наличие уязвимостей, многократная проверка кода с помощью различных подсказок и пометка найденных проблем.
  • Оценка контента на предмет неуместности, использование нескольких подсказок для оценки различных аспектов или требование различных порогов опроса для баланса ложных срабатываний и пропусков.

Рабочий процесс: Оркестранты-рабочие

В рабочем процессе координатор-работник центральный LLM динамически декомпозирует задачи, делегирует их рабочим LLM и синтезирует их результаты.

Рабочий процесс координатора и работника

Когда использовать этот рабочий процесс:
Этот рабочий процесс очень удобен, когда задача сложна и необходимые подзадачи невозможно предугадать (например, при кодировании, когда количество файлов, которые нужно изменить, и характер изменений в каждом файле могут зависеть от конкретной задачи). Аналогичен параллельным рабочим процессам, но ключевым отличием является его гибкость - подзадачи не предопределены, а определяются координатором на основе конкретных исходных данных.

Примеры применения координатора-работника:

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

Рабочий процесс: оценщик-оптимизатор

В рабочем процессе "оценщик-оптимизатор" один вызов Большой языковой модели (LLM) генерирует ответ, а другой обеспечивает оценку и обратную связь, образуя цикл.

Рабочий процесс оценщика-оптимизатора

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

Примеры применения оценщика-оптимизатора:

• Литературные переводы, в которых переводчик LLM может изначально не уловить всех нюансов, но оценщик LLM может дать полезную критику.
• Сложные поисковые задачи, требующие нескольких раундов поиска и анализа для сбора полной информации, при этом эксперт принимает решение о необходимости дальнейших поисков.

Intelligentsia/Agents

Агенты (Agents) постепенно появляются в производстве по мере развития ключевых возможностей LLM, таких как понимание сложных входных данных, рассуждения и планирование, надежное использование инструментов и восстановление после ошибок. Агенты начинают свою работу либо с инструкций от человека, либо в ходе интерактивных обсуждений. Когда задача ясна, агент планирует и действует самостоятельно, возможно, возвращаясь к человеку для получения дополнительной информации или вынесения решения. Во время выполнения агент должен получать "реальную информацию" из окружающей среды (например, результаты вызовов инструментов или выполнения кода) на каждом шаге, чтобы оценить свой прогресс. Агент может останавливаться в контрольных точках или при столкновении с препятствиями, чтобы получить обратную связь от человека. Задачи обычно завершаются по окончании, но часто включают условия остановки (например, максимальное количество итераций) для поддержания контроля.

Агенты могут решать сложные задачи, но их реализация обычно относительно проста. Зачастую это просто большие языковые модели, основанные на обратной связи с окружающей средой для использования инструмента. Поэтому разработка инструментария и документации к нему должна быть четкой и хорошо продуманной. О лучших практиках разработки инструментов мы рассказываем в Приложении 2 ("Разработка подсказок для инструментов").

Автономные агенты

Когда использовать прокси-серверы: Агенты могут использоваться для решения открытых задач, где невозможно предсказать количество необходимых шагов и где нельзя жестко закодировать фиксированные пути. LLM может потребовать выполнения нескольких раундов операций, поэтому вы должны в некоторой степени доверять его способности принимать решения. Автономность агента делает его хорошо подходящим для масштабирования задач в доверенной среде.

Автономность агента подразумевает более высокие затраты и потенциальный риск накопления ошибок. Мы рекомендуем проводить всестороннее тестирование в среде "песочницы" с соответствующими мерами безопасности.

Пример применения прокси-сервера:

Следующие примеры взяты из наших реальных реализаций:

• Кодирующий агент для решения задач SWE-bench, включающих редактирование нескольких файлов в соответствии с описанием задачи;
• наш Реализация ссылки "Использование компьютера"В этом случае Клод использовал компьютер для выполнения задания.

Высокоуровневый процесс кодирования агентов

Комбинирование и адаптация этих моделей

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

рефераты

Успех в области моделирования больших языков (LLM) заключается не в создании самой сложной системы, а в создании системы, которая наилучшим образом отвечает вашим потребностям. Начните с простых подсказок, оптимизируйте их путем тщательной оценки и добавляйте многоступенчатые агентные системы только тогда, когда простые решения не удовлетворяют вашим потребностям.

При внедрении прокси мы придерживаемся трех основных принципов:

1. Сохранение разработанных агентами простота .
2. Расставьте приоритеты в планировании, четко продемонстрировав, что агент прозрачность .
3. С помощью подробных инструментов Документация и тестирование Тщательно продумайте интерфейс агент-компьютер (ACI).

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

благодарственная записка

Эта статья была написана Эриком Шлунцем и Барри Чжаном. Эта работа основана на наших работах в Антропология Мы высоко ценим опыт строительных агентов и ценные идеи, которыми делятся наши клиенты.

Приложение 1: Практическое применение прокси-серверов

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

A. Поддержка клиентов

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

• Поддерживайте взаимодействия, которые естественным образом следуют диалоговому потоку, но при этом требуют доступа к внешней информации и выполнения действий;
• Можно интегрировать инструменты для извлечения данных о клиентах, истории заказов и статей базы знаний;
• Операции (например, выдача возмещений или обновление рабочих заказов) могут выполняться программно;
• Успех может быть четко измерен с помощью решений, определяемых пользователями.

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

B. Агенты-программисты

Сфера разработки программного обеспечения продемонстрировала значительный потенциал функциональности LLM, развиваясь от завершения кода до автономного решения проблем. Агенты особенно эффективны, потому что:

• Кодовые решения могут быть проверены с помощью автоматизированных тестов;
• Агенты могут использовать результаты тестирования в качестве обратной связи для итерации решения;
• Проблемные зоны четко определены и структурированы;
• Качество продукции можно объективно оценить.

В нашей реализации прокси смог индивидуально разрешить описания запросов на привлечение, основываясь на SWE-bench Проверено Актуальные проблемы GitHub в бенчмарках. Однако, несмотря на то, что автоматизированное тестирование может помочь в проверке функциональности, ручная проверка все еще жизненно важна для того, чтобы убедиться, что решение соответствует более широким системным требованиям.

Приложение 2: Проект подсказки

Независимо от того, какую систему агентов вы создаете, инструменты, вероятно, являются важной частью вашего агента. Инструменты позволяют Claude взаимодействовать с внешними сервисами и API, задавая их точную структуру и определения. При ответе Claude, если он планирует вызвать инструмент, он включит в ответ API-файл блок использования инструмента . Определения и спецификации инструментов должны быть подвержены проектированию подсказок в той же степени, что и общие подсказки. В этом приложении мы кратко опишем, как можно разработать подсказки для инструментов.

Обычно существует несколько способов указать одну и ту же операцию. Например, вы можете указать редактирование файла, написав diff, или переписать весь файл. Для структурированного вывода можно вернуть код в формате markdown или код в JSON. В программной инженерии эти различия носят косметический характер и могут быть преобразованы друг в друга без потерь. Однако некоторые форматы для LLM сложнее, чем другие. Например, для написания diff требуется знать, сколько строк в заголовке блока изменяется, прежде чем будет написан новый код. Написание кода в JSON (в отличие от markdown) требует дополнительного экранирования переносов строк и кавычек.

Рекомендации по формату инструмента приведены ниже:

• Дайте модели достаточно Жетоны "Думайте", чтобы не застрять в рутине.
• Форматирование должно быть приближено к тексту, который модель могла бы увидеть в Интернете.
• Убедитесь, что на формат не возлагается "дополнительное бремя", например, необходимость точно вычислять тысячи строк кода или экранировать любой код, который он пишет.

Как правило, следует учитывать, сколько усилий прилагается к созданию интерфейса "человек-компьютер" (HCI), а также планировать создание хорошего действовать от имени кого-л., занимая ответственную должность -Не меньшие усилия прилагаются к компьютерному интерфейсу (ACI). Ниже приведены некоторые предложения:

• Думайте в терминах моделей. Очевидно ли использовать этот инструмент, исходя из его описания и параметров? Если это требует тщательного обдумывания, то, вероятно, и для модели это так. Хорошее определение инструмента обычно включает примеры использования, граничные случаи, требования к формату входных данных и четкие границы с другими инструментами.
• Как изменить название или описание параметра, чтобы сделать его более очевидным? Думайте об этом как о написании отличной документации (docstring) для младших разработчиков в вашей команде. Это особенно важно при использовании множества похожих инструментов.
• Проверьте, как модель использует ваши инструменты: запустите множество примеров входных данных на нашем верстаке, посмотрите, какие ошибки допускает модель, и проведите итерации.
• Poka-yoke Ваши инструменты. Измените параметры, чтобы было сложнее ошибиться.

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