Отделение логики от поиска помогает масштабировать ИИ-агентов, разграничивая основные процессы от способов их реализации.
Переход от прототипов на базе генеративного ИИ к полноценным агентам для производства сталкивается с проблемой надёжности. Модели вроде LLM работают стохастически: промт, который сработал один раз, может провалиться при повторной попытке. Чтобы справиться, команды часто оборачивают бизнес-логику в сложные циклы обработки ошибок, повторные запуски и разветвлённые пути.
Такая тактика приводит к сложностям с обслуживанием. Код, описывающий, что должен делать агент, смешивается с кодом, управляющим непредсказуемостью модели. Новый фреймворк от специалистов Asari AI, MIT CSAIL и Caltech предлагает иной подход к архитектуре, подходящий для роста агентных рабочих процессов в компаниях.
Авторы представили модель программирования Probabilistic Angelic Nondeterminism (PAN) и её реализацию на Python — ENCOMPASS. С ней разработчики описывают идеальный сценарий работы агента, а стратегии на этапе вывода вроде beam search или backtracking передают отдельному движку. Такое разграничение снижает техдолг и повышает эффективность автоматизированных задач.
Проблема запутанности в проектировании агентов
Сейчас в программировании агентов часто смешивают два разных аспекта. Первый — это основная логика процесса, последовательность шагов для выполнения задачи. Второй — стратегия на этапе вывода, которая помогает преодолевать неопределённость, например, генерируя несколько вариантов или проверяя результаты по критериям.
При объединении код становится хрупким. Чтобы применить стратегию вроде "best-of-N" сэмплинга, приходится оборачивать всю функцию агента в цикл. Переход к более сложным методам, таким как tree search или refinement, требует полной перестройки кода.
По мнению исследователей, такая запутанность тормозит эксперименты. Если команда хочет заменить простой сэмплинг на beam search для точности, приходится перестраивать управление потоком в приложении. Из-за высоких затрат разработчики часто выбирают менее эффективные способы обеспечения надёжности, чтобы сэкономить время.
Разделение логики и поиска для масштабирования ИИ-агентов
Фреймворк ENCOMPASS решает задачу, позволяя разработчикам отмечать "точки неопределённости" с помощью примитива branchpoint().
Эти метки показывают места вызовов LLM и возможные разветвления. Код пишется так, будто всё пройдёт гладко. На этапе выполнения фреймворк строит дерево поиска по этим точкам.
Такая схема создаёт агенты типа "program-in-control". В отличие от систем "LLM-in-control", где модель сама решает последовательность действий, здесь код задаёт весь процесс. LLM вызывается только для конкретных подзадач. В компаниях такой подход ценят за предсказуемость и возможность аудита по сравнению с полностью автономными агентами.
Стратегии вывода трактуются как поиск по путям выполнения, что позволяет менять алгоритмы — от depth-first search и beam search до Monte Carlo tree search — без правок бизнес-логики.
Влияние на миграцию legacy-кода и перевод программ
Подход полезен в сложных процессах вроде миграции legacy-кода. Исследователи применили его к агенту для перевода Java в Python. Процесс включал перевод репозитория файл за файлом, генерацию входных данных и проверку через выполнение.
В обычной реализации на Python добавление поиска требовало создания конечного автомата. Это затмевало бизнес-логику и усложняло чтение или линтинг кода. Для beam search приходилось разбивать процесс на шаги и вручную управлять состоянием через словарь переменных.
С новым фреймворком для масштабирования ИИ-агентов те же стратегии ввели простыми вставками branchpoint() перед вызовами LLM. Основная логика осталась линейной и понятной. Эксперименты показали: beam search на уровне файлов и методов работает лучше простого сэмплинга.
Данные подтверждают улучшение масштабируемости. Производительность росла линейно с логарифмом затрат на вывод. Самый эффективный метод — детализированный beam search — оказался сложнейшим для традиционной реализации.
Экономия затрат и рост производительности
Контроль расходов на вывод — ключевой вопрос для руководителей ИИ-проектов. Исследование показывает: продвинутые алгоритмы поиска дают лучшие результаты дешевле, чем умножение циклов обратной связи.
В кейсе с паттерном "Reflexion" (LLM критикует свой вывод) сравнили рост циклов refinement с best-first search. Поисковый метод достиг той же производительности, но с меньшими затратами на задачу.
Выбор стратегии вывода напрямую влияет на оптимизацию бюджета. Вынос её за пределы логики позволяет балансировать между вычислениями и точностью без переписывания кода. Для внутренних инструментов подойдёт дешёвый greedy search, для клиентских приложений — тщательный поиск, на одной базе.
Фреймворк дополняет библиотеки вроде LangChain, управляя потоком управления, а не промтами или интерфейсами инструментов.
Но вызовы остаются. Поиск упрощает код, но не автоматизирует дизайн агента. Разработчики сами находят места для branchpoint и определяют метрики успеха.
Успех поиска зависит от оценки путей. В переводе кода помогали unit-тесты. В субъективных задачах вроде суммаризации или генерации креатива создание надёжной функции оценки — всё ещё узкое место.
Кроме того, система копирует состояние программы на ветвлениях. Фреймворк берёт на себя scoping и память, но разработчики должны контролировать побочные эффекты вроде записей в БД или API-вызовов, чтобы избежать дубликатов.
Последствия для масштабируемости ИИ-агентов
PAN и ENCOMPASS следуют принципам модульности в разработке ПО. По мере роста роли агентных процессов обслуживание потребует тех же стандартов, что и обычное ПО.
Жёсткая привязка вероятностной логики к бизнес-приложениям накапливает техдолг. Системы становятся сложными для тестов, аудита и обновлений. Разделение стратегии вывода от логики позволяет оптимизировать их отдельно.
Это упрощает управление. Если стратегия поиска вызывает галлюцинации или ошибки, её меняют глобально, без разбора каждого агента. Упрощается версионирование поведения ИИ, что важно для регулируемых отраслей, где важен не только результат, но и процесс.
Исследование подчёркивает: с ростом вычислений на выводе сложность путей выполнения возрастёт. Архитектуры, изолирующие эту сложность, окажутся устойчивее тех, где она проникает в приложения.