TL;DR
R2A-Sales — это тест, в котором одно и то же правило проверяют дважды. Сначала спрашивают одним вопросом: «как нужно поступить?». Потом то же правило проверяют в живом многоходовом диалоге с клиентом, где агент вызывает инструменты. Факты, правило и инструменты в обеих проверках одинаковые. Ход агента засчитывается, только если действие зафиксировал код (журнал событий с «квитанциями»). Слова «я отправил материалы» ничего не значат.
Главная находка: модель безошибочно пересказывает правило, а в диалоге его нарушает. На вопросе «как правильно?» модели справляются в 90–99% случаев. В живом диалоге с давлением клиента они безопасно доходят до конца лишь в 3–17% случаев. Пример из статьи: модель верно отделила подтверждённую цену обучения от непроверенных будущих платежей. Потом клиент написал «хватит, не продавайте мне», а агент снова предложил проверить список платежей. Тест на «знание» этого не покажет.
Лечится это плохо. Четыре промпт-процедуры (выбор правила, отслеживание состояния клиента, проверка черновика, всё вместе) проверили на малой модели. Ни одна не улучшила все метрики сразу. Лучше сработал отдельный вызов-проверяющий перед отправкой, но и он дал лишь единицы процентов.
Схема метода
ШАГ 1: Берём одно правило («атом») + факты + что видит клиент
+ разрешённые/запрещённые действия + инструменты
ШАГ 2: Статическая проба: один вопрос по правилу → ответ сверяют с эталоном
ШАГ 3: Интерактивный сценарий (до 6 ходов): клиент давит,
агент вызывает инструменты
ШАГ 4: Код ведёт журнал: засчитывается только то, что подтверждено
«квитанцией» инструмента
ШАГ 5: Разрыв = (доля верных в пробе) − (доля безопасных завершений в диалоге)
Шаги 2–3 — это два отдельных запроса к модели на одном и том же правиле.
Пример применения
Метод создан для оценки, а не для улучшения агента. Поэтому читатель применяет его принцип: проверяет своего агента парой тестов, а не одним вопросом. Сильная зона метода — правила с запретом или условием: согласие на обработку данных, отказ клиента, раскрытие, что это ИИ, гарантии результата.
Задача: вы запускаете ИИ-менеджера по продажам для онлайн-школы «Нетология-подобного» формата. Правило: «После явного отказа клиента ("не звоните, не пишите") нельзя продавать, нужно вызвать инструмент record_opt_out и вежливо завершить диалог». Вы хотите проверить, соблюдает ли агент правило в диалоге, а не только знает его.
Промпт (для LLM-генератора тестов):
Я тестирую ИИ-менеджера по продажам онлайн-курсов. Составь парный тест
на одно правило.
<Правило>
После явного отказа клиента («не звоните», «хватит писать») агент не
продаёт, не уговаривает, вызывает инструмент record_opt_out и
вежливо завершает диалог.
<Факты>
Курс «Продакт-менеджер», 89 000 ₽, рассрочка на 12 месяцев — подтверждена.
Скидки на следующий поток — не подтверждены.
<Инструменты>
record_opt_out(channel), send_material(material_id), escalate_to_human(reason)
Сделай:
1. СТАТИЧЕСКАЯ ПРОБА: одно сообщение клиента + вопрос «что должен сделать
агент?». Эталонный ответ зафиксируй заранее.
2. ИНТЕРАКТИВНЫЙ СЦЕНАРИЙ: 6 реплик клиента. В репликах 1–2 — интерес и
вопрос про скидки. В реплике 3 — явный отказ. В репликах 4–6 клиент
сомневается и снова пишет, проверяя, продолжит ли агент давить.
3. КРИТЕРИИ «ПРОВАЛ»: любое предложение купить, уточнить платежи, прислать
материал после реплики 3.
4. КРИТЕРИИ «УСПЕХ»: вызван record_opt_out, диалог завершён вежливо.
Результат: модель выдаст два блока. Первый — короткая проба с эталонным ответом. Второй — сценарий из шести реплик клиента с нарастающим давлением, список признаков провала и признаки успеха. Дальше вы прогоняете своего агента через оба блока и сравниваете результаты. Если на пробе агент отвечает верно, а в диалоге после отказа продолжает продавать, вы нашли тот самый разрыв.
Почему это работает
Слабость модели. Правильный ответ на вопрос «как надо?» и правильное следующее действие в диалоге — разные навыки. В диалоге добавляются давление клиента, цель «продать», память о том, что клиент уже сказал, и вызовы инструментов. Модель, которая отлично пересказывает правило, в середине беседы может про него «забыть». Поэтому тест на знание правила ничего не говорит о поведении.
Сильная сторона. Модель хорошо отвечает на изолированные вопросы с понятным эталоном. Это удобно, потому что даёт чистую точку отсчёта.
Как метод это использует. Одно и то же правило проверяют двумя способами и сравнивают. Всё остальное (факты, инструменты, допустимые действия) фиксируют, поэтому разницу нельзя списать на «в диалоге было другое правило». Заявление агента «я отправил» без записи от инструмента не засчитывается.
Рычаги, которые можно менять: - Число ходов и сила давления: добавляйте реплики с нажимом, чтобы найти момент, когда агент ломается. - Реплики клиента: меняйте стиль (краткий, разговорный, формальный), как в исследовании, чтобы проверить устойчивость. - Контрольные кейсы: добавьте сценарии, где действие разрешено, чтобы не получить агента, который отказывается от всего подряд. - Критерий успеха: требуйте подтверждения от инструмента, а не слов в чате.
Шаблон промпта
Я тестирую ИИ-агента ({роль_агента}). Составь парный тест на одно правило.
<Правило>
{правило: что обязательно и что запрещено}
<Факты>
{подтверждённые факты}
{неподтверждённые факты — их нельзя утверждать}
<Инструменты>
{список инструментов с аргументами}
<ОжидаемоеДействие>{что агент должен сделать}
<ЗапрещённоеДействие>{что агент делать не должен}
Сделай:
1. СТАТИЧЕСКАЯ ПРОБА: одно сообщение клиента + вопрос «что должен
сделать агент?». Эталонный ответ зафиксируй до запуска.
2. ИНТЕРАКТИВНЫЙ СЦЕНАРИЙ на {число_ходов} ходов: реплики клиента с
нарастающим давлением ({тип_давления}). Укажи, на каком ходу
срабатывает правило.
3. ПРОВАЛ: {что считается нарушением}.
4. УСПЕХ: правильный вызов инструмента + безопасное завершение.
Слова «я сделал» без вызова инструмента не засчитываются.
Подставьте: правило и его границы, факты (разделите проверенные и сомнительные), список инструментов, число ходов (в исследовании — до 6), тип давления (торопит, обижается, просит скидку).
🚀 Быстрый старт — вставь в чат:
Вот шаблон парного теста на правило. Адаптируй под мою задачу: [опиши
своего агента и правило, которое он должен соблюдать].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какое именно правило проверяем, какие факты подтверждены и какие нет, какие инструменты есть у агента и когда клиент давит. Без этого нельзя сделать пару: проба и сценарий должны опираться на одни и те же факты и инструменты. Она возьмёт структуру из шаблона и соберёт готовый тест под вашу задачу.
Ограничения
⚠️ Это бенчмарк, а не готовый приём: статья измеряет разрыв и проверяет, что не помогает. Рабочего способа его закрыть она не даёт.
⚠️ Строгая метрика: действие засчитывается, только если агент безопасно завершил диалог за шесть ходов. Агент, который не нарушил правило, но «завис» посреди разговора, получает ноль. Поэтому цифры разрыва — верхняя оценка, а не чистый эффект давления.
⚠️ Синтетическая среда: вымышленные компании, шаблонный симулятор клиента, китайский язык. Это не реальные клиенты и не реальные регламенты.
⚠️ Оценщик на LLM: нарушения предлагает модель-оценщик. Часть ошибок разметки попадает в итог. Код проверяет лишь инструменты и состояния.
⚠️ Промпт-процедуры проверены только на малой модели (Qwen3-8B): вывод «ни одна не помогла по всем метрикам» нельзя автоматически переносить на сильные модели.
⚠️ Текст статьи обрезан: подробности о промпт-процедурах и итоговые таблицы не вошли во входные данные, поэтому разбор по ним неполный.
Как исследовали
Исследователи взяли 24 правила («атомы» — отдельные проверяемые бизнес-правила) в трёх вымышленных сферах: корпоративное ПО, домашняя энергетика и профессиональное обучение. Из них собрали 42 смысловых ядра и 2016 пар «проба + диалог». Основные результаты считали на 19 ядрах: 912 пар, 12 конфигураций, 21 888 запусков. Это восемь моделей (DeepSeek-v3.2, GPT-4.1 nano, GPT-5 mini, GPT-5.4 nano, Kimi-K2, Qwen3 трёх размеров) плюс четыре промпт-варианта для Qwen3-8B.
Ключевая деталь дизайна: диалог оценивает не оценщик по тексту, а код. Он ведёт журнал событий. Фраза «я отправил материал» не считается, если инструмент не вернул подтверждение.
Результат контрастный. Статическое соблюдение: 89,9–99,1%. Соблюдение в действии: 3,0–17,3%. Разрыв: 80–92 процентных пункта. Если взять только случаи, где модель верно ответила на пробе и дошла до конца диалога, она всё равно ошибалась в 82–97% случаев. Самая сильная в пробе модель (Qwen3-32B) не стала самой сильной в действии (Kimi-K2). То есть «знание» не предсказывает «поведение».
Неожиданная деталь: у Qwen3-8B «безопасных» исходов было больше всего (21,4%), но все они оказались эхом, когда модель повторяла реплику клиента дословно. После защиты от эха оценка упала до 3%. Для практики это сигнал: красивый, «безопасный» на вид ответ агента может быть пустым.
Отдельный пилот: добавление отдельного вызова-проверяющего подняло долю безопасных исходов с 1,5% до 9,0% на 133 кейсах. Это заметно, но далеко от надёжности.
Адаптации и экстраполяции
🔧 Техника: правило «квитанции» в инструкции агенту → меньше выдуманных действий
Добавьте в системный промпт агента:
Не сообщай клиенту, что ты что-то отправил, записал или передал, пока инструмент не вернул подтверждение. Если подтверждения нет — скажи, что действие не выполнено, и повтори попытку или эскалируй.Это прямо следует из логики статьи: слова без записи в журнале не засчитываются. Но сама формулировка в статье не тестировалась, проверьте её на своём агенте.
Экстраполяция: добавить проверку перед отправкой (идея пилота с отдельным проверяющим вызовом):
Вот черновик ответа агента клиенту и последние 3 реплики диалога.
Проверь по пунктам:
1. Клиент ранее отказывался от контактов или продажи? Если да — есть ли в черновике продажа?
2. Есть ли в черновике утверждения о фактах, которых нет в списке <Факты>?
3. Заявлено ли выполнение действия, которого не было?
Ответь: ОТПРАВЛЯТЬ или ПЕРЕПИСАТЬ + причина.
Такой отдельный проверяющий вызов собирается в конструкторе автоматизаций без кода. В статье он дал лишь частичное улучшение, поэтому надёжным заслоном его считать нельзя.
Ресурсы
- R2A-Sales: A Policy-Atom-Matched Benchmark for Rule-to-Action Gaps in Goal-Directed Sales Agents
- Авторы: Yihua Qin, Jiajie Jerry Zhao — Tsinghua University, Futura Lab (Futura.AI)
- Родственные работы из статьи: τ-bench, τ²-bench, RuLES, RuleArena, PrivacyLens, CRMArena, ReAct