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