Привет, Хабр!

Меня зовут Ярослав, я магистрант AI Talent Hub в ИТМО. Сегодня расскажу об одной из самых интересных статей ICLR 2025 — AFlow: Automating Agentic Workflow Generation.

В ней предложен подход к автоматическому созданию мультиагентных систем для решения прикладных задач с помощью LLM и алгоритма Monte Carlo Tree Search (MCTS). Разберемся, как это работает и почему это важно.

Мультиагентные системы – что это? 

При решении прикладной задачи, с помощью создания подходящей мультиагентной системы, изначально не известен лучший набор агентов, а также связей между ними. И для получения удовлетворяющего качества, хочется получить инструмент, на вход которого подаются пары условие задания, и правильный ответ, а на выходе получается мультиагентная система (fit-predict, только модель чуть сложнее). Именно эту задачу и решают авторы статьи, при этом находя баланс между стоимостью построения мультиагентой системы и её качеством.

В статье авторы разделяют мультиагентные системы на 3 типа:

• Graph. В такой системе агенты представляют собою вершины графа, а взаимоотношения между ними - ребра.

• Neural Network. Структура, которая может представлять нелинейные взаимодействия между вершинами, позволяя получать адаптивные workflow, основываясь на входных данных и фидбеке.

• Code. Мультиагентная система представленная простой программой, в частности на Python. В этом подходе взаимодействие между агентами описывается кодом, где могут использоваться привычные конструкции контроля выполнения: for, while, if, else и т.п.

Что делает AFlow?

AFlow — это фреймворк, который сам генерирует мультиагентные системы под конкретную задачу.

На входе: пары (задание, правильный ответ).
На выходе: исходный код системы агентов, которая решает такие задачи максимально эффективно.

Цель: найти оптимальный баланс между качеством решения и стоимостью генерации (в $ и времени).

Типы мультиагентных систем

Авторы выделяют три способа описания таких систем:

1. Graph — вершины-гены, рёбра-взаимодействия;

2. Neural Network — динамическая структура с обучаемыми весами;

3. Code — обычный код (на Python), где агенты вызываются как функции, а логика описана через if, for,await и т. п.

Фокус AFlow — именно на текстовом коде: он прозрачен, интерпретируем и легче интегрируется в практические пайплайны.

Пример агента в AFlow

async def __call__(self, problem: str):
	"""
	Implementation of the graph
	"""
	solutions = []
	for _ in range(5): # Generate 5 solutions
		solution = await self.custom(
			input=problem, instruction=MATH_SOLVE_PROMPT
		)

	solutions.append(solution['response'])
	final_solution = await self.sc_ensemble(
		solutions=solutions, problem=problem
	)
	# Add a verification step using Programmer operator
	verification = await self.programmer(
		problem=problem,
		analysis=final_solution['response']
	)

	if verification['output']:
		return verification['output'], self.total_cost
	else:
		return final_solution['response'], self.total_cost

Здесь self.custom - вызов LLM с системным промптом, предающимся в аргументе instruction, self.sc_ensemble, self.programmer - вызовы LLM с зафиксированными системными промптами.

Как AFlow генерирует такие системы?

Это поисковая оптимизационная задача, в которой ищется код, максимизирующий точность решения.

Используется Monte Carlo Tree Search (MCTS). Кратко:

1. Инициализация:
   - Создание изначального состояния
   - Разделение данных на test/val.

2. Выбор состояния, который будет улучшаться.

3. Создание нового состояния, посредством улучшения выбранного состояния.

4. Оценка состояния.

5. Обновление состояния родителя.

Подробнее о каждом шаге

Инициализация

Сразу, хочется ответить на вопрос, что такое состояние? Состояние - это совокупность набора агентов и связей между ними (код программы), скор, описание неправильных ответов на задачу.

• Изначальное состояние - простейшая мультиагентная система, состоящая из одного агента, без системного промпта. В такого агента поступает только условие задачи, без каких-либо техник промптинга.

• Изначальные данные делятся в соотношении 80% на test, 20% на val. На валидационном датасете 5 раз запускается изначальная система и по результатам запусков считаются метрики (в 4 шаге подробнее расскажу про метрики). После чего по порогу отбираются данные, которые имеют большую дисперсию по метрикам, они и будут использоваться в основной части алгоритма.

Выбор состояния

У каждого состояния есть свой скор - численная оценка качества системы. Авторы предлагают вариант выбора, при котором поддерживается баланс exploration vs exploitation, то есть алгоритм не полностью фокусируется на улучшении лучшего (по скору) состояния, но также со случайной вероятностью может выбрать состояние, с меньшим качеством, с целью получать разнообразные мультиагентные системы. Здесь P(i) - вероятность выбрать i-ое состояние, sj - скор j-ого состояния, smax - максимальный скор среди всех состояний, n - количество всех состояний, - коэффициент баланса exploration vs exploitation, - коэффициент влияния скоров. Таким образом, первая часть суммы отвечает за exploration, вторая за exploitation.

Шаг оптимизации

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

Что такое операторы?

Готовые блоки агентов с логикой. Например, Multi-Agent Debate: трое агентов спорят, четвёртый — судья. Это ускоряет генерацию сложных систем.

Оценка состояния

Для оценки состояния авторы запускают workflow на валидационном датасете 5 раз, после чего считают метрики и усредняют их. Они пишут что такая оценка увеличивает стоимость каждой итерации, однако это позволяет получить более точные значения, что в конечном счете позволяет снизить число итераций. Однако не для всех задач имеются готовые способы подсчета метрик, поэтому авторы статьи предлагают свой вариант оценки для open-ended задач. Для этого они используют LLM модель (а могли бы мультиагентную систему), которую просят оценить генерацию по четырем критериям числом от 1 до 5: Content Relevance, Content Quality, Coherence and Structure, Reference Comparison. Для каждого критерия авторы описывают условия для получения соответствующей оценки.

Обновление состояния родителя

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

Повторение итераций

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

Результаты

Датасеты

Авторы статьи проверяют свой подход на 6 различных публичных бенчмарках: GSM8K (8500 задач по математике уровня начальной школы), HumanEval (164 задачи на программирование с заданным описанием функции, требуется написать реализацию), MBPP (1000 crowd-sourced задач на Python, рассчитанных на начинающих программистов).

Из датасетов HotpotQA (question answering), DROP (question answering) авторы берут 1000 случайных семплов. Для датасета MATH авторы используют 617 задач из четырех тем: Комбинаторика и Теория вероятности, Теория чисел, Основы алгебры, Основы математического анализа. 

Метрики

AFlow сравнивали с прямым вызовом LLM, Chain-of-thought, Chain-of-thought + 5 shot self-consistency, MedPrompt, MultiPersona, Self Refine, ADAS. На каждом датасете авторам удалось получить SoTA результат.

Стоимость подхода

Авторы замеряли стоимость различных подходов, и по результатам их экспериментов, AFlow позволяет находить мультиагентные системы, позволяющие дешевым моделям (напр. gpt-4o-mini) получать результаты, лучше, чем при использовании более дорогих моделей (напр. claude-3.5-sonnet).

Значимость операторов

Во время генерации мультиагентных систем на датасете GSM8K авторы экспериментировали с отказом от использования набора заранее заданных операторов. По результатам этого эксперимента, solve rate снизился с 93.5% до 93.1%. Однако даже такой результат является SoTA на этом датасете, уступая только подходу с операторами.

Вывод

AFlow — это шаг к автоматизации мультиагентных LLM-систем. Вместо ручного промпт-инжиниринга и сложного дизайна — достаточно пары примеров задачи, и модель сгенерирует эффективный pipeline сама.

• Работает даже с недорогими LLM.

• Достигает SoTA на классических бенчмарках.

• Подходит для практических open-ended задач.

Статью подготовил магистрант AI Talent Hub ИТМО Коробко Ярослав.