Пилот ИИ: как проверить результат до большого запуска

01Зачем нужен пилот

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

Хороший пилот узкий и короткий: один процесс, один канал, две-три недели наблюдений. Например, помощник отвечает на вопросы по доставке и оплате, а заявки на нестандартный расчёт сразу уходят менеджеру. Так вы получаете данные, а не впечатления.

Пилот полезен, когда у вас есть конкретное решение, которое нужно проверить: умеет ли помощник отвечать по регламентам, переносить строки счёта или раскладывать заявки. Фраза «посмотреть, что может ИИ» для пилота слишком широка. Сформулируйте вопрос так, чтобы после проверки можно было принять решение. Например: «Можно ли доверить помощнику подготовку карточки заявки, если отправка клиенту остаётся у менеджера?» Ответ зависит от реальных примеров и критериев, а не от впечатления от демонстрации.

02Тестовый набор: обычные и сложные случаи

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

Важно включить не только удобные вопросы. Добавьте письма без номера заказа, вопросы с двумя темами сразу, устаревшие условия из старых прайсов. Именно такие случаи показывают, умеет ли помощник уточнять и передавать человеку, а не додумывать.

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

• 15–20 обычных обращений: то, что приходит чаще всего.
• 10–15 сложных: неполные данные, редкие условия, смешанные вопросы.
• 5–10 спорных: случаи, где раньше ошибались даже люди.
• Для каждого примера запишите ожидаемое действие, а не только текст ответа.

Читайте также: Что подготовить по данным до начала проекта

03Критерии успеха до старта

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

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

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

04Как проверять ответы

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

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

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

05Типичные ошибки и как их читать

Частая ошибка — уверенный ответ по устаревшему документу. Помощник находит старый прайс и отвечает красиво, но неверно. Лечится порядком в источниках и датами обновления, а не уговорами системы.

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

Третья ошибка — смешивание двух тем в одном письме. Человек спрашивает про срок и возврат, а ответ покрывает только срок. В журнале такие случаи помечайте отдельно: они показывают, что нужно разбивать сложные обращения на части.

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

06Роль человека в пилоте

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

Проверяющему нужны время и полномочия. Заложите полчаса-час в день на разбор и право останавливать автоматические действия. Если человек перегружен основной работой, проверка будет формальной и ошибки уйдут дальше.

Читайте также: Как подготовить команду к проверке и работе с ИИ

07Наблюдение и откат

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

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

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

Читайте также: Что проверить руководителю по безопасности данных

08Когда расширять пилот

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

Не расширяйте пилот, пока грубые ошибки не закрыты. Больше охват при тех же ошибках даёт больше проблем, а не больше пользы. Спокойный темп здесь быстрее суетливого.

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

09Чек-лист и подготовка руководителя

Перед стартом пройдите чек-лист с владельцем процесса и подрядчиком. Убедитесь, что тестовый набор не показывали системе заранее и что проверяющий понимает свои полномочия. Это занимает час, но экономит недели споров.

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

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

• Задача пилота записана узко: процесс, канал, срок.
• Тестовый набор собран владельцем: обычные, сложные, спорные.
• Критерии успеха и границы ошибок согласованы до старта.
• Назначен проверяющий, время на проверку заложено.
• Журнал ведётся ежедневно, план отката записан.
• Решение о расширении принимается по данным журнала.

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

Источники

• NIST AI RMF Playbook — практические шаги по ролям и проверке
• NIST AI RMF: функции управления и надзора