Почему все демо-боты умнее реальных

Коротко для руководителя. На демонстрации ИИ-бот выглядит умным, а в проде глупеет — это не случайность и не «забыли что-то настроить». Демо ведут люди, которые знают, как устроена система, и бессознательно ей помогают: спрашивают понятно, по одной теме, не сбиваются. Реальный клиент так почти никогда не делает. Поэтому разрыв «демо ↔ прод» закономерен, и закрывается он не доработкой промпта, а проверкой бота на людях, которые ему не помогают.

Сценарий повторяется из проекта в проект. На демонстрации ИИ-бот отвечает точно, ведёт диалог гладко, заказчик доволен. Через месяц после запуска приходят жалобы: бот «тупит», не понимает, переспрашивает, теряет нить. Команда лезет в логи, ждёт увидеть поломку — и не находит её. Бот работает ровно как на демо. Изменился не бот. Изменился собеседник.

Гипотеза: демо умнее прода, потому что тестировщик кооперативен, а клиент — нет

Когда систему показывает человек, который её построил, он ведёт диалог идеально для бота, сам того не замечая. Формулирует чётко. Держится одной темы. Не противоречит сам себе. Даёт данные в том порядке, которого бот ждёт. Не уходит на полпути и не возвращается через двадцать минут с «а, и ещё вопрос». Каждая из этих привычек — подарок боту: он создавался под такой ввод, потому что под такой ввод его и проверяли.

Реальный пользователь не кооперативен — не со зла, а по природе живого диалога. Он спрашивает три вещи в одном сообщении. Он не знает терминов, которыми мыслит система. Он перебивает себя, вспоминает, тревожится, передумывает. Он даёт неполные и иногда неверные данные. Демо-бот и прод-бот — это один и тот же код, поставленный перед двумя разными мирами: миром, который ему помогает, и миром, которому всё равно.

Проблема: разрыв «демо ↔ прод» воспринимают как баг, а это класс ошибки

Самое дорогое в этой истории — не сам разрыв, а его неверный диагноз. Команда видит «на демо работало, в проде нет» и читает это как баг: где-то что-то недокрутили, сейчас поправим промпт. Но чинить нечего — поведение бота не изменилось, изменилось распределение входных данных. Это не дефект реализации, а дефект метода проверки: систему оценивали в условиях, которые не встречаются в проде.

Пока разрыв считают багом, его «чинят» бесконечно: подкручивают формулировки, добавляют примеры, расширяют сценарии — и каждый раз снова проверяют на кооперативном вводе, снова получают зелёное демо, снова удивляются проду. Это тот же перекос на зелёный результат, только на уровне всей демонстрации: показываем систему там, где она не может не справиться, и принимаем это за доказательство, что она справится везде.

Хуже того, разрыв подрывает доверие к самому направлению. Заказчик, которому показали умного бота, а получил он беспомощного, делает вывод не «нас неправильно проверили», а «ИИ не работает». Один неверно поданный демо-результат портит отношение к следующему, уже честному проекту.

Почему обычные подходы не работают

«Сделать демо ближе к реальности» звучит правильно, но на деле почти не помогает: тот, кто ведёт демо, всё равно знает систему и всё равно ей подыгрывает. Даже стараясь спрашивать «как обычный пользователь», он остаётся внутри модели бота — задаёт вопросы, на которые тот точно ответит, и обходит зоны, в которых не уверен. Кооперативность тут не выбор, а слепое пятно: невозможно одновременно знать, как устроена система, и спрашивать так, будто не знаешь.

«Добавить больше тестов» не закрывает разрыв по той же причине: тесты пишут те же люди в той же логике, и они несут тот же перекос. Сто зелёных тестов в кооперативных условиях не дают ни одного факта о том, что будет в некооперативных. «Спросить бота, как он поведёт себя со сложным клиентом» бесполезно — он опишет идеальный сценарий, которого в живом диалоге не будет. Корень один: проверку ведёт сторона, которая хочет и умеет, чтобы бот прошёл.

Инженерная модель: проверять бота тем, кто ему не помогает

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

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

Это не теоретическая конструкция, а смена того, что считать доказательством готовности. Зелёное демо доказывает, что бот справляется, когда ему помогают. Проверка на способность довести до результата в некооперативном диалоге доказывает, что он справится, когда не помогают, — а в проде не помогает никто.

Практический вывод для бизнеса

Не принимайте решение по демо. Демонстрация показывает потолок системы в идеальных условиях, а вам нужно знать её пол — как она ведёт себя в худших, но обычных. Перед запуском требуйте не «покажите, как работает», а «покажите, где ломается и на чём именно».

Что спросить на приёмке. Кто проверял бота — та же команда, что его делала, или независимая сторона? На каких диалогах — придуманных или реальных? Был ли заинтересован в провале хоть кто-нибудь? Если на все три вопроса ответ неудобный, у вас есть красивое демо и нет данных о проде.

Чего не делать. Не путайте гладкое демо с готовностью к клиентам — это разные вещи. Не списывайте «ИИ у нас не сработал» по боту, которого проверяли в тепличных условиях: почти всегда сломалась проверка, а не идея. И не доверяйте оценку только авторам бота — нужен тот, кому платят за найденные дыры, а не за зелёный отчёт.

Посмотреть, как ваш бот поведёт себя с некооперативным клиентом, — обсудить с инженером → .

Открытые вопросы

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

Если ваш бот блестит на демо, но вы не уверены в нём на реальных людях, — это и есть разрыв «демо ↔ прод», а не недоработка промпта. Обсудить задачу → — проверим бота на тех диалогах, которые ему никто не подыгрывает, и покажем, где он теряет клиента. Смежные кейсы — в разделе кейсов.