Почему я гоняю свои решения через спор одиннадцати ИИ, а не через одну нейросеть

Недавно я делал аудит собственного продукта и мне не понравилось то, что я увидел. ИИ-агент, которого мы поставили работать в 23 рабочих чатах, отвечал на 9% сообщений, а в 11 чатах молчал с первого дня. Две функции, обещанные на лендинге, в коде вообще отсутствовали. Вопрос "что делать дальше" я не понёс партнёру или консультанту, а прогнал через штуку, которой сам пользуюсь для своих же продуктов прежде чем предлагать её клиентам: набор из 11 ИИ-ролей, каждая со своей методикой, плюс обязательный критик, который ищет слабое место в любом решении. Через сутки вернулся документ: решение, шесть рисков, десять шагов с датами.

Хочу рассказать не про продукт, а про то, что я понял об устройстве такого разбора и о том, где он реально помогает, а где может подвести.

Обычный чат с нейросетью почти всегда соглашается с формулировкой вопроса. Спрашиваешь "почему агент не отвечает" и получаешь ответ в рамках собственной же гипотезы. У совета из 11 ролей устроено иначе: вопрос уходит всем сразу, каждая роль обязана дать тезисы и рекомендацию независимо от остальных, а потом отдельная роль критика прогоняет предположение через pre-mortem: представляет, что решение уже провалилось, и объясняет почему. Только после этого кто-то сводит все позиции в один документ и явно называет вслух то, в чём роли разошлись.

Мне важно, что никто не голосует. Голосование прячет конфликт, а тут конфликт обязан быть виден на бумаге.

Самое полезное в этом разборе было не решение, а момент, когда данные опровергли то, во что мы верили. Исходная цифра аудита была 9% ответов. Когда её пересчитали без внутреннего служебного чата, снаружи оказалось 999 сообщений и всего 53 ответа - 5,3%. Мы продавали одну цифру, а измеряли другую.

Вторая находка была дороже первой. Команда была уверена, что агент молчит там, где не заполнен контекст проекта - так было в 14 чатах из 23. Но в чате с подробно заполненным контекстом ответов оказалось ноль, а в чате с заглушкой вместо контекста - целых 11. Пять из одиннадцати ролей всё равно предложили в первую очередь заняться контекстом, и именно критик указал, что это классическое подтверждающее искажение: мы искали данные под удобную версию. Без этого замечания месяц ушёл бы на лечение симптома вместо причины.

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

А через месяц - не отчёт, а развилка с записанной датой пересмотра и заранее прописанными сценариями. Для себя я вынес простое правило: решение без записанной даты пересмотра постепенно остывает, и тридцать дней незаметно превращаются в девяносто.

Совет ошибается там же, где ошибаются люди: он принимает формулировку вопроса как данность. В моём случае восемь ролей из одиннадцати обсуждали, как чинить процесс, и ни одна не спросила вслух, платил ли за продукт хоть один посторонний человек. Это всплыло только у критика. Второе ограничение - качество входа: если в вопросе нет цифр, роли начинают спорить о гипотезах вместо фактов. И третье, самое обычное: документ с решением не выполняется сам, сроки в календарь и отчёт по метрикам всё равно переносят живые люди.

Расскажите, а вы проверяете свои гипотезы данными, прежде чем принять решение, или чаще действуете по ощущению того, что "и так понятно"? Мне интересно, у кого как это устроено.