IF-MAP находит, каких агентов улучшать: вдвое больший прирост точности

Исследователи предложили IF-MAP — метод, который отвечает на практичный вопрос: какого агента в мультиагентной LLM-системе стоит улучшать первым, если бюджета хватит не на всех. На шести воркфлоу (генерация кода, ответы на вопросы, математические рассуждения) оптимизация промптов у выбранных агентов дала средний прирост 3,81 процентного пункта против 1,85 при равномерном выборе. Замена модели на более сильную в тех же узлах принесла 7,62–16,42 п.п. против 3,81–8,62.

Кто виноват и кого чинить — разные вопросы

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

Обычный инструмент здесь — атрибуция сбоев: разобрать неудачные прогоны и понять, какой агент ошибся. Авторы IF-MAP указывают на слабое место такого подхода. Ответственность за провалы не говорит, сколько выиграет система, если агента улучшить. Агент, которого чаще всего находят в точке сбоя, может упираться в сложность задачи. А малозаметный узел в середине цепочки может оказаться главным рычагом.

Как IF-MAP измеряет чувствительность без доступа к весам

Название отсылает к influence functions, классическому способу оценивать влияние элемента на итог обучения. Здесь идею применили к агентам. Для каждого из них метод вносит контролируемые семантические возмущения в промпт и смотрит, как меняется сквозной loss всей системы. Затем в низкоразмерном подпространстве эмбеддингов промпта строится регуляризованная локальная модель отклика. Норма её оценки и становится приоритетом агента: чем сильнее система реагирует на сдвиг в этом узле, тем больше потенциал улучшения.

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

Ключевые цифры из экспериментов:

• Шесть мультиагентных воркфлоу: генерация кода, QA, математика.
• Оптимизация промптов у выбранных агентов: +3,81 п.п. (macro-average) против +1,85 при равномерном выборе.
• Апгрейд выбранных агентов на пяти целевых моделях: +7,62–16,42 п.п. против +3,81–8,62.
• Qwen3-8B: на 74,2% меньше токенов, чем при оптимизации всех агентов.
• DeepSeek-V3.2: на 35,2% меньше токенов по той же базе.
• Апгрейд моделей: на 63,6–64,9% меньше токенов целевой модели, чем при замене всех агентов.

Пробинг стоит токенов, но окупается

У метода есть собственная цена: нужно прогнать систему с возмущёнными промптами. Авторы это признают и всё равно считают итог в токенах. Даже с учётом пробинга сокращение расходов получается заметным, от 35,2% до 74,2% при оптимизации промптов. Для апгрейда экономия ещё стабильнее: дорогая модель ставится только на узлы с высоким приоритетом, и расход её токенов падает почти на две трети.

Прирост качества при этом примерно вдвое выше, чем при равномерном распределении усилий. Для низа диапазона апгрейда это ровно двукратная разница: 7,62 против 3,81.

Как это применять в проде

Для команд, которые строят агентные пайплайны, вывод приземлённый. Прежде чем переводить всю цепочку на дорогую модель или запускать оптимизацию промптов везде, имеет смысл замерить чувствительность каждого узла и вложиться в верхушку рейтинга. Это особенно актуально для систем на открытых моделях вроде Qwen3-8B и DeepSeek-V3.2, где разница в токенах быстро превращается в разницу в счёте за инференс.

Ограничения тоже стоит учитывать. Отклик оценивается локально, то есть вблизи текущих промптов, и результаты даны как macro-average по шести воркфлоу. Приоритеты нужно пересчитывать после существенных изменений в архитектуре системы, набора ролей или базовой модели. Но как дешёвая замена интуиции вроде «давайте усилим планировщика» подход выглядит убедительно: он даёт измеримый ориентир там, где раньше был выбор наугад.