TL;DR
Исследование показывает, что точность ответов модели — плохой пропуск в продакшн. Если агент или команда агентов действуют на основе своих догадок (о партнёре, клиенте, задаче), решать «брать или нет» нужно по трём вещам. Первая — сколько стоит ошибка в вашем процессе. Вторая — как ошибки взаимодействуют: перекрываются потери или складываются. Третья — как часто копии ошибаются вместе. Авторы собрали из этого проверку Blind-Spot Gate (шлюз слепых зон). Она считается по повторам с искусственно внесёнными ошибками, без запуска модуля в бою.
Главная находка: копии одной модели ошибаются на одном и том же. Три «независимых» проверяющих выглядят как страховка, но если у модели есть слепое пятно, все три промахиваются вместе. Для моделей разных поколений в эксперименте ошибка на конкретном партнёре падала с 32% до 11%. Шанс, что все три копии ошиблись на одном партнёре, падал только с 16% до 9%. При независимых ошибках было бы с 3,4% до 0,15%. Модель умнеет, а слепые пятна остаются общими. Поэтому «три прогона, голосуем» даёт намного меньше защиты, чем кажется.
Суть метода: точность не отвечает на вопрос «стоит ли внедрять». Нужно задать три вопроса. Сколько стоит промах в моём процессе? Что происходит, если ошибутся сразу два звена: потери сливаются (хуже не станет) или усугубляются (станет сильно хуже)? Как часто ошибки совпадают? Только после этого решаем, внедрять ли агента.
Схема метода
ШАГ 1: Цена ошибки → порог точности зависит от того, сколько стоит неверное действие
(дорогая ошибка → порог выше; ошибки, которые до «дорогого канала» не доходят, порог не двигают)
ШАГ 2: Структура потерь → как ошибки взаимодействуют?
• Потеря при ЛЮБОЙ ошибке (цепочка): общие ошибки ПОМОГАЮТ (потери перекрываются)
• Потеря только при ошибке ВСЕХ (дублирование): общие ошибки ВРЕДЯТ (потери складываются)
ШАГ 3: Измерить совместные ошибки → как часто все наблюдатели ошибаются на одном объекте
ШАГ 4: Решение → внедрять/нет по совокупности (цена + взаимодействия + зависимость),
а не по «точность выше N%»
Оригинальный Gate считается на симуляторе, который принимает внесённые ошибки. Читатель в чате повторяет логику, но не расчёты (см. шаблон).
Пример применения
Задача: Вы руководите поддержкой на маркетплейсе уровня Wildberries. Хотите, чтобы три копии одной модели голосовали «2 из 3» и сами одобряли возвраты до 5 000 ₽. Тесты показывают «точность 91%», и все довольны.
Промпт:
Ты — аудитор внедрения ИИ-агентов. Мне нужно решить, можно ли запускать автоодобрение возвратов.
Контекст:
- Три копии одной модели независимо читают обращение и голосуют «одобрить / отказать / эскалировать». Решение по большинству.
- Тест на 300 обращениях: точность одной копии 91%, большинства 94%.
- Ошибочное одобрение возврата: в среднем −3 200 ₽ (иногда мошенничество, до 15 000 ₽).
- Ошибочный отказ: жалоба + 15 минут оператора, ≈ 400 ₽.
- Ошибочная эскалация: 3 минуты оператора, ≈ 60 ₽.
Проведи аудит по трём вопросам:
1. ЦЕНА ОШИБКИ. Какие ошибки доходят до «дорогого канала» (деньги уходят безвозвратно), а какие нет? Какая точность нужна именно для дорогого типа ошибки? Достаточно ли 94% общей точности?
2. СТРУКТУРА ПОТЕРЬ. Для каждой пары ошибок скажи: потери перекрываются (достаточно одной ошибки, чтобы потерять) или складываются (теряем только когда ошиблись все)? Приведи примеры из моего процесса. Как этому влияет голосование «2 из 3»?
3. СОВМЕСТНЫЕ ОШИБКИ. Три копии ОДНОЙ модели ошибаются на одних и тех же обращениях. Сколько «независимых» проверяющих они реально стоят: ближе к 1 или к 3? Предложи, как мне измерить долю обращений, на которых ошиблись все три копии, на моих 300 примерах. Предложи, чем заменить копии: другая модель, другой формат вопроса, человек на дорогих случаях.
Итог: внедрять / не внедрять / внедрять с ограничениями. Назови порог суммы возврата для автоодобрения и список обращений, которые всегда уходят человеку.
Результат: Модель разберёт цену каждого типа ошибки отдельно. Покажет, что общая точность скрывает редкие, но дорогие промахи. Объяснит, что голосование трёх копий одной модели почти не защищает от общего слепого пятна, например от обращений с «мошенническим» шаблоном. Предложит измерить долю случаев, где ошиблись все три копии. Предложит разделить решения по сумме и подключить вторую модель или человека для дорогих случаев. В финале будет вердикт с ограничениями.
Почему это работает
Слабость «в лоб». Мы привыкли думать: точность 94% — значит, модель надёжна. Но точность усредняет все ошибки, как будто они стоят одинаково и случаются независимо. В реальности модель редко ошибается дорого, но когда ошибается, ошибается у всех копий сразу. Общая точность этого не видит.
Что модель умеет хорошо. LLM хорошо разбирает структуру процесса: где потеря наступает при любой ошибке, а где только при ошибке всех звеньев. Она помогает перебрать сценарии, посчитать стоимость промахов и придумать, как измерить совпадения ошибок на ваших примерах.
Как метод обходит слабость. Он переносит вопрос с «насколько модель точна» на «что будет с моим процессом, когда она ошибётся». Знак зависимости тоже важен. В цепочке, где хватает одной ошибки, общие ошибки помогают, потому что промахи накладываются друг на друга. В схеме с дублированием они вредят, потому что дублирование перестаёт работать. Две проверки по 80%: потеря «при любой ошибке» — 36% при независимых ошибках и 20% при общих. Потеря «только при обеих» — 4% против 20%.
Рычаги управления: - Цена ошибки → задай разные веса для разных типов ошибок. Это сильнее всего двигает вердикт. - Количество копий → мало смысла наращивать копии одной модели, лучше менять модели. - Структура → перепиши процесс так, чтобы дорогая потеря требовала ошибки сразу нескольких независимых звеньев. - Граница по сумме/риску → вынеси дорогие случаи из автоматизации.
Шаблон промпта
Это перенос логики Gate в чат. Оригинал считает по симулятору, здесь вы получаете качественный аудит.
Ты — аудитор внедрения ИИ-агентов. Реши, можно ли запускать {что_запускаем}.
Контекст:
- Как работает схема: {описание_схемы_и_сколько_копий_или_моделей}
- Измеренная точность: {точность_и_на_какой_выборке}
- Стоимость ошибок по типам:
• {тип_ошибки_1}: {стоимость_1}
• {тип_ошибки_2}: {стоимость_2}
• {тип_ошибки_3}: {стоимость_3}
Проведи аудит по трём шагам.
ШАГ 1. ЦЕНА ОШИБКИ.
Какие ошибки доходят до «дорогого канала» (необратимый ущерб), а какие нет?
Какая точность нужна именно по дорогим ошибкам? Достаточно ли общей точности?
ШАГ 2. СТРУКТУРА ПОТЕРЬ.
Для каждой пары ошибок определи:
- потери ПЕРЕКРЫВАЮТСЯ (достаточно одной ошибки, чтобы потерять) → общие ошибки скорее помогают;
- потери СКЛАДЫВАЮТСЯ (теряем только когда ошиблись все звенья, то есть дублирование) → общие ошибки вредят.
Приведи примеры из моего процесса.
ШАГ 3. СОВМЕСТНЫЕ ОШИБКИ.
Сколько независимых проверяющих реально стоят мои копии/модели: ближе к 1 или к {число_копий}?
Как на {выборка} измерить долю случаев, где ошиблись ВСЕ копии? Чем заменить копии: другая модель, другой формат вопроса, человек?
ИТОГ: внедрять / не внедрять / внедрять с ограничениями.
Укажи порог и список случаев, которые всегда уходят человеку.
Что подставлять:
- {что_запускаем} — процесс, который хотите автоматизировать
- {описание_схемы...} — как устроена цепочка, сколько копий или разных моделей
- {точность...} — ваши результаты тестов, если есть
- {тип_ошибки...}, {стоимость...} — какие бывают промахи и сколько каждый стоит в рублях, времени или репутации
- {число_копий}, {выборка} — сколько проверяющих и на каком наборе примеров можно измерить совпадения
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита внедрения агентов. Адаптируй под мою задачу: [опиши процесс, который хочешь автоматизировать].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про стоимость каждого типа ошибки и про устройство вашей схемы (сколько копий, одна модель или несколько). Эти данные нужны, чтобы порог и структура потерь считались от вашего процесса, а не от общих слов.
Ограничения
⚠️ Нужен симулятор: оригинальный Gate считается на повторах с внесёнными ошибками. Без такого стенда в чате остаётся качественный аудит, а не расчёт. Авторы сами называют Gate оценкой, а не гарантией.
⚠️ Игровые среды: основные тесты проводились на назначении задач, Level-Based Foraging и Hanabi. Прямого переноса на ваш процесс нет, и числа из статьи брать нельзя.
⚠️ Не всё подтвердилось: из 73 заранее заявленных предсказаний 48 сбылись, 3 сбылись частично, 21 не сбылось. Например, для случая «одна жизнь в Hanabi» два эффекта взаимно погасились. Часть выводов по GPT и по людям — исследовательский анализ, а не заранее заявленная проверка.
⚠️ Много общих ошибок: если на эпизод приходится в среднем больше четырёх взаимосвязанных ошибок, Gate склоняется к осторожности, и лучше измерять напрямую.
⚠️ Нет «рецепта по разнообразию»: теория говорит, что смешанная команда моделей падает не чаще среднего геометрического «клонов». Но готового рецепта «возьми модель X и Y» в статье нет.
Как исследовали
Идея была простой: если ToM-модуль («модель чужих намерений») оценивают по точности, проверим, насколько точность вообще предсказывает пользу. Авторы взяли три мира. В первом координатор раздаёт задачи 12 работникам со скрытыми правилами. Во втором, Level-Based Foraging, координатор собирает коалиции из агентов. Третий — карточная игра Hanabi, где игроки подсказывают друг другу на «диалектах». В каждом искусственно портили убеждения до заданной точности, независимо или «одинаково у всех наблюдателей», и смотрели, как падает или растёт результат.
Затем подключили настоящие модули: обученные классификаторы, байесовский модуль и пять языковых моделей (четыре Claude и GPT-5.4-mini). Модели читали транскрипт первых двух раундов 250 игр Hanabi и угадывали «диалект» каждого игрока. Сравнивали три состава: «клоны» (разные семплы одной модели), «публичная» команда (все видят один и тот же вывод), «смешанная» (разные модели).
Результат оказался двусторонним. В Hanabi, где ошибки складываются, точность одобряет вредные внедрения. В назначении задач дорогие ошибки редки, и точность отбраковывает полезные внедрения (в 33 из 35 комбинаций модуля и вреда). Неожиданнее всего оказалось другое: у языковых моделей точность растёт, а избыточность почти нет. Практический вывод: «ещё одна копия той же модели» — слабая страховка, нужна разнородность.
Тесты проверяли на отложенных данных. На тех модулях, на которых Gate разрабатывали, он не дал значимых ложных одобрений в 20 разбиениях, а точность давала по 3,2 на разбиение. На новых модулях Gate снижал «сожаление» (потери от неверного решения) с 0,479 до 0,004 на семи классификаторах. На байесовском модуле он поймал вредное внедрение, которое точность одобряла в 17 из 20 разбиений, а Gate — в 1.
Адаптации и экстраполяции
🔧 Техника: добавить «красную команду» → найти слепое пятно вместо подтверждения
Вместо вопроса «сколько копий нужно» поручите второй модели искать типы обращений, на которых первая стабильно ошибается:
Ты — вторая модель-аудитор. Вот правило, которым пользуется первая: {правило_или_промпт}.
Найди 10 типов обращений, где оно, вероятнее всего, даст одну и ту же ошибку у ЛЮБОЙ копии. Не те, где ошибки случайны, а те, где сам механизм ведёт к одинаковому промаху.
Это не метод из статьи, а применение её вывода о «общих слепых пятнах». Проверять результат придётся на ваших данных.
🔧 Техника: переписать процесс, чтобы дорогая потеря требовала ошибки нескольких звеньев
Просите не «добавь ещё проверяющих», а «разнеси ответственность»: деньги уходят, только если не согласились две разные модели или модель и правило на суммах.
Ресурсы
- Smart Alone, Blind Together: Why Accuracy Fails to Certify Theory of Mind in Multi-Agent Teams — Will Beaumaster, Paul Schrater, University of Minnesota (Миннеаполис, США).
- Код и данные упоминаются в приложении к статье (
code_data/SCORECARD.md). - Среды: Jumanji Level-Based Foraging, Hanabi Learning Environment.
- Связанные идеи: «алгоритмическая монокультура», коррелированные ошибки LLM, теорема Кондорсе о присяжных.