Кейс: как мы выбирали модель для ИИ-продавца и почему автотест ошибся

У нас в CRM работает ИИ-агент, который отвечает клиентам в переписке: закрывает вопросы по услугам, уточняет задачу, переводит разговор в удобный мессенджер и передаёт менеджеру всё, что требует человека. Перед тем как поставить в него новую модель, мы сравнили четыре и получили результат, который стоит знать всем, кто собирается запускать похожего агента: автоматический тест выбрал не ту модель.

Задача

Нам нужна была не модель, которая красиво отвечает на один вопрос, а модель, способная работать внутри процесса продаж. Это значит: читать историю переписки, отвечать на все вопросы клиента сразу, брать факты из проверенной базы ответов, не выдумывать цены, отличать услугу от выбранного канала связи, вызывать нужный инструмент CRM, молчать там, где ответ не требуется, и отдавать менеджеру сложные и негативные диалоги.

Сравнивали четыре модели на одной и той же конфигурации агента: одинаковая системная инструкция, один каталог услуг, одна база проверенных ответов, одни и те же инструменты.

Этап первый: короткие сценарии

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

LongCat отсеялась сразу: пустой ответ на выбор канала, пропуск прямого вопроса о цене, преждевременный переход к договору и реквизитам, отсутствие реакции на ссылку. Дальше пошли три модели.

Этап второй: настоящие переписки

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

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

Где сломался формальный лидер

• Три вопроса в одном сообщении: как записаться, когда начать, сколько стоит. MiniMax ответила только про цену и снова попросила выбрать направление. Два вопроса остались без ответа, притом что формально ответ был верным.
• Присланная ссылка на профиль: модель написала, что изучит аккаунт, но не вызвала инструмент и не поставила задачу менеджеру. Обещание без действия это отдельный класс ошибки, автотест его не ловит.
• Запрос двух аудитов сразу: вместо ответа модель начала продавать ведение рекламы и перечислять состав пакета, а вторая половина вопроса потерялась.
• Слово «телеграм» как выбор канала связи модель приняла за название услуги и стала спрашивать, есть ли у клиента канал. Смысловая ошибка на ровном месте.
• В длинных переписках MiniMax чаще добавляла лишние вопросы, из-за чего ответ выглядел анкетой, а не разговором.

При этом на коротких тестах эта же модель набрала 30 баллов из 30. Разница объясняется просто: в синтетическом сценарии модель получает чистый вопрос без предыстории, а в реальном чате ей нужно одновременно держать в голове несколько предыдущих вопросов, названный бизнес клиента, выбранный мессенджер, старые ответы менеджера, факты из каталога и ограничения инструментов.

Сколько это стоит

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

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

Что выбрали и почему

• Основная модель: MiMo v2.5 Pro. Лучше всех использует базу проверенных ответов и инструменты, не теряет части составного вопроса, корректно работает со ссылками и переходами в мессенджеры.
• Резерв: DeepSeek V4 Pro. Содержательные ответы и аккуратное молчание после вызова инструментов, но реже обращается к базе и дороже на длинных диалогах.
• MiniMax M3 в роли основной модели не подошла, несмотря на лучший автоматический балл и лучшую цену.
• Поверх модели работает смысловой контролёр, который включается не на каждое сообщение, а только в опасных составных ситуациях: когда часть ответа известна, а часть ждёт менеджера.

Что нельзя доверять модели

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

1. чтение свежей истории перед отправкой и отмена устаревшего черновика;
2. защита от повторной отправки и от серии сообщений без ответа клиента;
3. молчание при явном негативе и передача диалога менеджеру;
4. фиксированный ответ после получения ссылки на изучение;
5. проверка номера перед отправкой сообщения в мессенджер;
6. запрет раскрывать клиенту внутреннюю переписку сотрудников;
7. финальная нормализация текста: замена тире, удаление эмодзи, если это задано настройками.

Ошибка, которую нашли в самом тесте

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

Что забрать себе, если запускаете ИИ-агента

• Автоматический балл без ручного просмотра диалогов вводит в заблуждение. Формальные проверки ловят факты и запрещённые слова, но не видят пропущенный вопрос.
• Тестируйте на настоящих длинных переписках, а не на чистых вопросах. Модель ломается именно на контексте.
• Обещание без вызова инструмента это отдельный класс ошибки, и его нужно проверять специально.
• База проверенных ответов работает только тогда, когда модель действительно её вызывает. Смотрите не на текст ответа, а на то, обращалась ли модель к источнику.
• Разница в цене между моделями почти всегда меньше, чем стоимость вмешательства менеджера. Дешёвая модель с ошибками обходится дороже.
• Формат и безопасность закрепляйте кодом, а не просьбами в промпте. Промпт модель может нарушить, движок нет.

Как мы внедряем таких агентов, описано в разделе ИИ-агент для заявок.