**Суть метода** Исследование системно оценивает компромисс между производительностью и ресурсоемкостью многоагентных LLM-систем в задачах программной инженерии. Авторы сравнили конфигурации от простых одиночных запросов до сложных многоагентных рабочих процессов по точности, задержке и энергопотреблению. Главный вывод: усложнение архитектуры до нескольких агентов увеличивает расход энергии в среднем в 6.36 раза, а время выполнения — в 6.07 раза, при этом прирост точности минимален и наблюдается только в специфичных задачах. Легковесные решения безагентного или одноагентного типа доминируют в соотношении цена/качество. **Как это работает** Авторы протестировали 4 уровня агентности на 5 задачах (генерация кода, поиск техдолга, детекция уязвимостей, парсинг и анализ логов): 1. **NA (Non-Agentic)**: Прямой zero-shot или few-shot запрос к модели без сохранения состояния. 2. **SA (Single Agent)**: Один автономный агент, выполняющий задачу. 3. **DA (Dual Agent)**: Два агента (например, Исполнитель и Критик), где второй проверяет и улучшает результат первого. 4. **MA (Multi-Agent)**: Координируемый workflow из 4+ агентов с разделением ролей. Оценка проводилась на открытых моделях (Gemma, Qwen, DeepSeek-Coder) с прямым замером точности, времени отклика и энергопотребления (включая оценку CO₂). **Пример применения** *Задача*: Анализ кода на наличие уязвимостей. - **Неэффективный путь**: Запуск Multi-Agent системы (Code Author + Security Analyst + Reviewer + Manager). Результат: задержка выросла в 10 раз, энергопотребление скакнуло, а точность улучшилась лишь незначительно. - **Оптимальный путь**: Использование Dual-Agent (Исполнитель + Критик) с few-shot промптом (3 примера). Результат: точность на уровне MA, но затраты вычислительных ресурсов в 5–6 раз ниже. Для парсинга логов достаточно NA с грамотно составленным few-shot промптом. **Шаблон для копирования: Чек-лист выбора LLM-конфигурации** ```text [ ] 1. Определите задачу: генерация кода, парсинг, техдолг или уязвимости? [ ] 2. Для генерации кода, парсинга логов и поиска техдолга: используйте NA или SA. [ ] 3. Для поиска уязвимостей: рассмотрите DA или MA, только если критична каждая доля процента точности. [ ] 4. Настройте промпт: для парсинга и анализа логов добавление 3 примеров (few-shot) может повысить точность с 3.4% до 54.3%. [ ] 5. Оцените железо: для тяжелых MA-конфигураций сервер ускорит работу в 3.4 раза по сравнению с рабочей станцией. ``` **Границы применимости** - **Полезно**: Когда задача требует глубокого рассуждения и перекрестной проверки (например, детекция сложных уязвимостей), и у проекта есть избыточные вычислительные ресурсы. - **Бесполезно или вредно**: Слепое добавление агентов для рутинных задач. В худших сценариях (зависит от пары задача-железо) это дает замедление до 160× без какого-либо улучшения качества результата. **Ключевые выводы из экспериментов** - Multi-Agent тратит в **6.36×** больше энергии и работает в **6.07×** дольше, чем базовый запрос. - Из 66 Парето-оптимальных конфигураций **59 (89%)** — это легковесные NA или SA. Только одна конфигурация была многоагентной. - Энергия и задержка коррелируют почти идеально (**r = 0.987**): оптимизируя время отклика, вы автоматически снижаете энергопотребление. - Не существует глобально лучшей модели или промпта: их эффективность кардинально меняется в зависимости от конкретной задачи. Номер исследования: 2610.03010 Поддержать проект донатом: Сбер 2202 2084 9881 5282. Заранее спасибо.