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