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

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

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

Такой подход создает проблему сопровождения. Код, определяющий действия агента, неразрывно смешивается с кодом, определяющим обработку непредсказуемости модели. Новая структура, предложенная исследователями из... ИИ Асари, MIT CSAIL, и Калтех предполагает, что для масштабирования необходим другой архитектурный стандарт. агентные рабочие процессы на предприятии.

В исследовании представлена ​​модель программирования, называемая Вероятностный ангельский недетерминизм (PAN) и реализация на Python под названием КОМПАСЭтот метод позволяет разработчикам писать «оптимальный сценарий» рабочего процесса агента, вынося стратегии вывода (например, поиск по лучу или возврат) в отдельную среду выполнения. Такое разделение задач открывает потенциальный путь к сокращению технического долга и повышению производительности автоматизированных задач.

Проблема запутанности в проектировании агентов

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

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

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

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

Разделение логики и поиска для повышения масштабируемости ИИ-агента

Фреймворк ENCOMPASS решает эту проблему, позволяя программистам отмечать «места повышенной надежности» в своем коде, используя примитив, называемый branchpoint().

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

Эта архитектура позволяет реализовать то, что авторы называют Агенты «программного управления»В отличие от систем с управлением на уровне модели (LLM-in-control), где модель определяет всю последовательность операций, агенты с управлением на уровне программы работают в рамках рабочего процесса, определяемого кодом. Модель LLM вызывается только для выполнения конкретных подзадач. Такая структура, как правило, предпочтительна в корпоративных средах из-за более высокой предсказуемости и возможности аудита по сравнению с полностью автономными агентами.

Рассматривая стратегии вывода как поиск по путям выполнения, фреймворк позволяет разработчикам применять различные алгоритмы, такие как: поиск в глубину, поиск луча, или поиск деревьев в Монте-Карло – без изменения базовой бизнес-логики.

Влияние на миграцию устаревших систем и перевод кода.

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

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

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

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

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

Экономическая эффективность и масштабируемость производительности

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

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

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

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

Инженерные проблемы и соображения

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

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

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

Последствия для масштабируемости агентов ИИ

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

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

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

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