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

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

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