← Все материалы

Как проверить работу ИИ-агента: чек-лист приёмки и признаки сырой сдачи

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

Почему демо от подрядчика ничего не доказывает

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

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

Метрики, по которым принимают агента

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

Метрика	Как считается	Что означает
Доля верных ответов	Сравнение с эталоном; ушёл в эскалацию — ноль	Главная цифра приёмки: ловит и покрытие, и правильность
Доля «не знаю»	Сколько раз агент честно отказался отвечать	Слишком мало — врёт вместо отказа. Слишком много — экономии нет, работает человек
Точность эскалации	Из вопросов, за которые агент взялся, — доля обработанных верно	Не берётся ли агент за то, чего не понимает
Полнота эскалации	Из вопросов, на которые можно было ответить, — доля не ушедших человеку зря	Обратный перекос: агент перестраховывается и сваливает всё на оператора
Корректность вызова инструментов	Тот ли инструмент, те ли аргументы, в том ли порядке — по логам, а не по тексту ответа	Именно это отличает проверку агента от проверки чат-бота
Стоимость и время обращения	Расход токенов и секунды, средние и худшие 5 %	Агент может быть точным и при этом неокупаемым

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

Приёмочная выборка: как собрать и разметить

Это единственная часть приёмки, которую нельзя делегировать подрядчику: эталон собирает заказчик, иначе смысл теряется. Работы на день-полтора, и она окупается одним не принятым сырым проектом.

1. Возьмите 100–150 реальных обращений из истории — не отобранные красивые, а подряд за случайную неделю.
2. Добавьте краевые случаи специально. Вопрос вне зоны ответственности, два вопроса в одном сообщении, чужой номер заказа, запрос на скидку, попытка выпросить внутренние данные, транслит.
3. Впишите эталонный ответ для каждого — коротко, как ответил бы ваш лучший оператор. Для действий укажите ожидаемый результат в системе: какая сделка, какое поле, какой статус.
4. Отметьте, на что агент отвечать не должен — это половина ценности выборки. Правильный ответ здесь — эскалация, и она засчитывается как успех.
5. Считайте по каждой метрике отдельно, а не суммарно. Провал обычно локальный: всё хорошо, кроме вопросов про возвраты.
6. Каждый провал превращайте в тест-кейс для регресса. К концу первого квартала эксплуатации нормальный размер такого набора — несколько сотен случаев.

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

Как ловить галлюцинации и молчаливые ошибки

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

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

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

Чек-лист приёмки ИИ-агента: 9 пунктов

Каждый пункт даёт ответ «да / нет», а не «вроде нормально».

1. Прогон вашей выборки при вас. 100–150 обращений, эталон ваш, метрики считаются на экране. Не отчёт подрядчика, а запуск в вашем присутствии.
2. Метрики разложены, а не сведены в одну. Доля верных, доля «не знаю», точность и полнота эскалации, ошибки в инструментах, стоимость обращения.
3. Проверены действия в системах, а не только текст. Открыли CRM и убедились: сделка на том контрагенте, поля заполнены, дубля нет. Интеграция с CRM — то место, где чаще всего и находится брак.
4. Показано поведение на краевых случаях. Вопрос не по теме, два вопроса в одном, чужой номер заказа, попытка выпросить внутренние данные, оскорбление.
5. Явно описана граница ответственности. Не «работает с заявками», а перечислением: что делает сам, что готовит на подтверждение, где останавливается и зовёт человека.
6. Есть логи и доступ к ним у вас. Открыть конкретное обращение и увидеть всю трассу. Проверяется на живом примере, а не по словам.
7. Есть откат и стоп-кран. Как выключить агента одной кнопкой и как отменить его действия за последний час. Проверяется нажатием.
8. Посчитана стоимость эксплуатации на вашем потоке. Расход на модель в месяц, лимиты, что будет при трёхкратном пике обращений.
9. Права и данные зафиксированы письменно. Какие поля уходят в модель, к какому провайдеру, какие права у сервисной учётки агента. Подробнее — в разборе безопасности данных при работе с ИИ.

Признаки, что подрядчик сдаёт сырое

Это не про недобросовестность, чаще про спешку. Но выглядят они узнаваемо.

• Демо вместо прогона. На просьбу запустить вашу выборку прямо сейчас отвечают «давайте позже, сейчас неудобно» или присылают свои результаты в презентации.
• Одна метрика на всё. «Точность 95 %» без пояснения, что считалось, на чём и сколько было примеров. Уточняющий вопрос вызывает раздражение.
• Агент никогда не говорит «не знаю». На вопрос вне зоны ответственности выдаёт уверенный ответ. Это не сила, а отсутствие калибровки.
• Нет логов или их «сейчас не видно». Разбор инцидента в проде будет выглядеть как переписка «а у нас всё работает».
• Нет ответа, что происходит при сбое. API модели недоступен, CRM не отвечает, лимит исчерпан — без внятного поведения первый же сбой станет тишиной вместо ответов клиентам.
• Правки без повторного прогона. «Поправили промпт, теперь лучше» без цифр до и после — это не исправление, а надежда.
• Нет владельца после запуска. На вопрос «кто смотрит метрики через месяц» звучит «ну вы напишите, если что».
• Границу ответственности проговаривают словами, а не списком. «Агент закрывает поддержку» вместо перечня сценариев — гарантия спора о том, что входило в работу.

Замечу и в свою сторону: у нормально сданного агента цифры не идеальные. 78 % верных ответов при честных 11 % «не знаю» — рабочий результат, который экономит время операторов. Заявленные 99 % на первом прогоне означают, что выборка была из демо.

Что проверять в первый месяц после запуска

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

Что смотреть	Как часто	Когда вмешиваться
Доля верных ответов на живом потоке	Раз в неделю, 20–30 случаев	Просадка больше 3 % к среднему за 7 дней
Доля эскалаций	Ежедневно на графике	Резкий рост — сломалась интеграция или пришёл новый тип обращений
Придуманные факты	Все жалобы плюс выборочно	Больше 5 % ответов с фактом без источника — стоп и разбор
Расход на модель	Раз в неделю	Рост без роста обращений — раздутый контекст
Регрессионный набор	После каждой правки	Упал ранее проходивший кейс — правка не принимается

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

Если вы пока выбираете подрядчика, а не принимаете работу: разработка ИИ-агентов — про устройство и цену, внедрение ИИ-агентов — про этапы и запуск, чат-бот поддержки — про самый частый первый сценарий.

Частые вопросы

Читайте дальше