TL;DR
IF-MAP — способ выбрать одного агента в многоагентной системе, улучшение которого даст максимальный прирост. Для каждого агента делают до 10 слегка изменённых версий промпта (роль и формат вывода те же), прогоняют всю систему целиком и смотрят, как меняется итоговая ошибка. Из этих замеров считают оценку «чувствительности» агента. Чем сильнее итог реагирует на изменения в промпте агента, тем выше его приоритет.
Главная находка: «кто чаще всех виноват в провалах» и «кого выгоднее улучшать» — разные вопросы. Агент может часто ошибаться, но улучшать там нечего. Другой агент ошибается редко, но небольшая правка в его работе заметно поднимает результат всей цепочки. Если улучшать всех подряд или того, на кого указал разбор ошибок, деньги и токены уходят впустую. Иногда правка не в том месте даже ухудшает итог.
Метод работает в пять шагов, и его считает код: эмбеддинги промптов и регрессия. Читателю-практику не нужно воспроизводить математику, но сам принцип переносится: сначала зондируй агентов возмущениями, потом вкладывайся в самого чувствительного. По результатам, дорогой апгрейд модели только у выбранных агентов даёт примерно вдвое больше пользы, чем апгрейд случайного агента. Токенов при этом уходит на ~64% меньше, чем при апгрейде всех.
Схема метода
ШАГ 1: Берёшь рабочую систему + пробный набор задач с оценкой → базовая ошибка L0
ШАГ 2: Для агента i делаешь до 10 вариантов промпта
(роль и формат вывода те же, меняется формулировка) → промпты p_i^(1..10)
ШАГ 3: Меняешь промпт ТОЛЬКО у агента i, остальное не трогаешь,
прогоняешь всю систему → ошибка L_i^(m) и сдвиг ∆ = L0 − L_i^(m)
ШАГ 4: Эмбеддинги промптов → «направление» и «размер» изменения →
ridge-регрессия в малом подпространстве → вектор реакции g_i
→ приоритет S_i = ‖g_i‖
ШАГ 5: Ранжируешь агентов по S_i → улучшаешь топ-1
(правка промпта / модель посильнее / дообучение)
Шаги 1–3 и 5 отдельные прогоны системы. Шаг 4 — расчёт на коде.
Пример применения
Сильная зона метода: цепочка из нескольких агентов, есть набор типовых задач и понятная оценка итога (верно / неверно, балл).
Задача: Ты делаешь ИИ-помощника для поддержки продавцов на маркетплейсе (в духе Ozon или Wildberries). В цепочке четыре агента:
- Классификатор обращений.
- Поисковик по базе правил.
- Автор ответа.
- Проверяющий тон и политику.
Бюджет ограничен: апгрейдить все четыре на дорогую модель нельзя. Сначала нужно понять, кого именно.
Промпт (шаг 2, генерация вариантов промпта для одного агента; другой чат или модель):
Ниже промпт одного агента из цепочки поддержки продавцов маркетплейса.
Агент: «Поисковик по базе правил». Его вход: категория обращения и текст.
Его выход: JSON {"rules": [id1, id2, id3]}.
Исходный промпт:
"""
Ты — поисковик по базе правил маркетплейса. Получи категорию обращения
и текст продавца. Верни ровно 3 id правил, наиболее релевантных вопросу.
Ответ — только JSON: {"rules": [id1, id2, id3]}.
"""
Сделай 10 вариантов этого промпта. Требования:
— роль агента остаётся прежней;
— формат вывода остаётся ровно таким же;
— варианты должны заметно отличаться друг от друга по формулировке,
структуре и порядку инструкций;
— 3 варианта — лёгкие перефразировки, 4 — перестановка структуры
(блоки, нумерация, порядок), 3 — добавление конкретного уточнения
по критерию релевантности;
— не добавляй новых задач, не удаляй требований формата.
Выведи каждый вариант в отдельном блоке с номером.
Дальше для каждого варианта ты подменяешь промпт только у этого агента. Прогоняешь, например, 50 типовых обращений и записываешь долю верных финальных ответов. Повторяешь для всех четырёх агентов.
Результат: Модель выдаст 10 пронумерованных вариантов с тем же ролью и JSON-форматом. Всего у тебя будет примерно 40 прогонов набора, по 10 на агента, и таблица «агент → как менялся итоговый балл». Агента, у которого итог сильно «гуляет» при разных формулировках, считаешь приоритетным для улучшения. Остальных не трогаешь. В оригинале эту оценку считает регрессия, но в ручном режиме можно ориентироваться на разброс и направление сдвигов.
Почему это работает
Слабость: в цепочке ошибка одного агента растекается по остальным. Поэтому по логам провала плохо видно, где улучшение окупится. Виновник провала не обязательно тот, чья правка что-то изменит. Правка промпта агента-«склейщика» иногда ничего не даёт или ухудшает итог.
Сильная сторона: модель реагирует на изменения промпта предсказуемо, и итоговый результат можно измерить. Если слегка поменять формулировку у агента, а итог сильно сдвинулся, значит, этот узел «нагружен». Здесь есть куда расти.
Как метод это использует: он не гадает по логам, а ставит маленькие контролируемые эксперименты на каждом агенте. Изменение нормируется на «размер» правки, чтобы большие и малые правки были сопоставимы. Затем модель-регрессия собирает много точечных замеров в один устойчивый показатель.
Рычаги: - Число вариантов (в оригинале до 10): меньше — дешевле, но шумнее; больше — стабильнее оценка. - Что сохраняется неизменным (роль и формат вывода): так ты меняешь формулировку, а не задачу агента. Иначе сломается совместимость с соседями. - Что делаешь с победителем: переписать промпт, поменять модель, дообучить. Один и тот же рейтинг работал и для промптов, и для апгрейда модели. - Размер пробного набора: чем он больше, тем меньше случайных скачков в оценке.
Шаблон промпта
В тексте статьи готовых промптов нет (полные протоколы в приложениях, их не видно). Ниже мой шаблон шага 2: генерация вариантов, по описанию «роль и формат сохраняются, дубликаты и неработающие отбрасываются». Это не копия авторского промпта.
Ниже промпт одного агента из многоагентной цепочки.
Агент: «{имя_агента}».
Вход агента: {вход}.
Выход агента (строгий формат): {формат_вывода}.
Исходный промпт:
"""
{исходный_промпт}
"""
Сделай {N} вариантов этого промпта для проверки чувствительности системы.
Требования:
— роль агента остаётся прежней;
— формат вывода остаётся ровно таким же: {формат_вывода};
— варианты заметно отличаются друг от друга (не дубли);
— распределение: {k1} — перефразировки, {k2} — перестановка структуры
(блоки, порядок, нумерация), {k3} — добавление уточнения по {критерий};
— не добавляй новых задач и не удаляй обязательных требований.
Для каждого варианта выведи: номер, тип изменения, полный текст промпта.
Если вариант нарушает формат вывода или дублирует другой — замени его.
Что подставлять:
- {имя_агента}, {вход}, {формат_вывода}, {исходный_промпт}: из твоей цепочки.
- {N}: 5–10 вариантов. Статья берёт до 10.
- {k1}, {k2}, {k3}: доли типов изменений, в сумме N.
- {критерий}: что агент должен делать лучше (точность, полнота, тон).
🚀 Быстрый старт — вставь в чат:
Вот шаблон генерации вариантов промпта для проверки чувствительности агента (метод IF-MAP).
Адаптируй под мою цепочку: [опиши свою цепочку агентов и какой у них итоговый результат].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про агента, его вход и выход, исходный промпт и критерий оценки итога. Это нужно, чтобы варианты сохраняли роль и формат: иначе сломается стыковка с соседними агентами. Она возьмёт паттерн из шаблона и подготовит набор вариантов под твою задачу.
Ограничения
⚠️ Нужна инженерия: оригинальный расчёт требует эмбеддингов промптов, SVD и ridge-регрессии. В обычном чате его не повторить, нужен скрипт.
⚠️ Нужны пробный набор и оценка итога: без набора типовых задач и понятной метрики (верно/неверно, балл) замерять нечего. Для творческих задач без критерия метод не годится.
⚠️ Цена зондирования: каждый вариант промпта означает полный прогон всей системы на наборе. Экономия окупается только когда сама правка или апгрейд дороже зондирования.
⚠️ Один агент за раз: метод выбирает, кого улучшать следующим, а не как несколько агентов взаимодействуют при совместной правке.
⚠️ Проверка узкая: эксперименты на шести задачах из бенчмарков (код, вопросы-ответы, математика). Рабочая цепочка выполнялась в основном небольшой моделью Qwen3-8B. Абсолютные приросты скромные, несколько процентных пунктов. Сколько метод даст в твоём продакшене, неизвестно.
⚠️ Локальная оценка: метод показывает реакцию на небольшие изменения промпта. Это не гарантия, что кардинальная переделка даст пропорциональный прирост.
⚠️ Текст статьи неполный: в предоставленном фрагменте нет приложений, полных таблиц и деталей протокола возмущений.
Как исследовали
Идея простая: проверить, предсказывает ли оценка чувствительности реальную пользу от улучшения. Команда взяла шесть многоагентных цепочек из фреймворка AFlow: две на код (HumanEval, MBPP), три на вопросы-ответы (NQ, HotpotQA, DROP) и одну на математику (MATH). Для каждого агента посчитали приоритет. Затем реально улучшили каждого агента по очереди и сравнили: тот ли агент оказался лучшим, на которого указал рейтинг.
Улучшения проверяли двумя способами: автоматической переписью промпта по обратной связи и заменой модели на более сильную (пять моделей, включая Qwen3-235B, DeepSeek-V3.2 и GPT-5 nano). Сравнивали с шестью методами «поиска виновника» (Who&When, A2P, AgentRx, CHIEF, FAMAS, Locator) и со случайным выбором.
Результаты: при оптимизации промпта выбранный агент дал в среднем +3,81 п.п. против +1,85 п.п. при случайном выборе. Лучший из конкурентов (FAMAS) отстал на 0,51 п.п. При апгрейде модели выигрыш был +7,62–16,42 п.п. против +3,81–8,62 п.п. Согласованность рейтинга с реальными приростами (Kendall τb) составила около 0,74.
Неожиданный вывод: методы «найди виновного» проигрывают методу «замерь чувствительность», хотя их цель — тоже помочь выбрать, что чинить. Для практики это значит, что разбор логов — хорошая диагностика, но плохой навигатор для вложений.
Адаптации и экстраполяции
🔧 Техника: ручная проверка чувствительности без регрессии → быстрый выбор агента
Это моё упрощение: авторы так не проверяли. Для каждого агента сделай 3–5 вариантов промпта по шаблону выше. Прогони каждый на 30–50 типовых задачах и посчитай итоговый балл. Выбери агента, у которого итог сильнее всего отклоняется от базового (в обе стороны). Именно его есть смысл улучшать или апгрейдить первым. Без эмбеддингов и регрессии оценка грубее, но принцип «сначала зонд, потом вложения» тот же.
🔧 Техника: апгрейд модели только у выбранного агента → экономия токенов
Не переводи всю цепочку на дорогую модель. Подними модель только у агента с высоким приоритетом, промпт оставь прежним. В статье так сделали, и расход токенов упал примерно на 64% против апгрейда всех.
Ресурсы
- Работа: IF-MAP: Influence-Function-Inspired Agent Prioritization in Multi-Agent Systems (препринт).
- Код: https://github.com/s1412/IF-MAS
- Авторы: Jie Mao, Pingchen Lu, Zikun Qu, Jiahang Sun, Xiangyi Wang, Zhiwei Shang, Zhiyong Wang, Guojun Xiong, Zhongxiang Dai.
- Университеты: The Chinese University of Hong Kong, Shenzhen; Harbin Institute of Technology; Harvard SEAS.
- Отсылки: Koh & Liang (2017, influence functions); Who&When (Zhang et al., 2025b); AFlow (Zhang et al., 2025a).