Почему пилот отработал, а в прод не поехал
Я давно перестал радоваться фразе «демо всем понравилось». У меня это слишком часто оказывалось последним хорошим событием в проекте. Заказчик кивает и говорит, что берёт в прод. Дальше почти всегда один и тот же сюжет. Пауза, бюджет уезжает в следующий квартал, заказчик перестаёт отвечать по этой теме, хотя по остальным отвечает нормально. Система при этом работает ровно так, как её показывали. Ошибка случилась раньше — в тот день, когда мы записали, что считается успехом пилота.
Пилот и прод спрашивают разное
В пилотах, которые я видел, успех обычно мерили впечатлением. Показали набор случаев, заказчик сказал, что убедительно. Более дисциплинированный вариант — точность на тестовой выборке, и собирает её, как правило, та же команда, которая делает пилот, из случаев, которые сама понимает.
Прод спрашивает другое. Сколько стоит один полезный результат и что с этой цифрой будет при росте объёма? Как система ведёт себя в плохой день, когда провайдер деградировал, а на вход пришёл мусор? Ещё прод спрашивает, изменилась ли работа людей, которым теперь с этой системой жить. Эти вопросы на пилоте обычно никто не задаёт.
По отчёту MIT GenAI Divide положительный экономический эффект за первый год получает примерно одна организация из двадцати. Из чего состоят остальные девятнадцать, отчёт не разбирает. По тому, что вижу я, значительная часть там — системы, которые технически работают, отвечают осмысленно и при этом никому не сэкономили ни часа. Когда мы разбирали наш фреймворк «AI КОМП-АС», самым недооценённым этапом я называл скейлинг на проде — а причины провала чаще всего нахожу на входе в пилот.
Пилот живёт в тепличных условиях
Данные для пилота, как правило, проходят через чьи-то руки. Кто-то выгрузил срез, свёл справочники и отобрал документы, которые читаются. Без этого идею не проверить. Но эту работу обычно нигде не записали как этап проекта и не посчитали в часах, а в оценку промышленного контура она не попала. В эксплуатации поток приходит как есть: сканы сняты под углом, а одного контрагента в справочнике пишут пятью способами. Качество ответов проседает, хотя ни модель, ни промпт не трогали. Изменился вход.
Есть и второй способ подогнать пилот под себя, менее заметный. Пока команда доводит демо, промпт правится под конкретные примеры: одну инструкцию добавили, потому что на очередном документе ответ поехал, другую — потому что заказчик показал свой случай. Это переобучение руками, и надёжнее всего оно проверяется отложенной выборкой, которую при настройке никто не видел. Без неё вы знаете только, что на своих примерах система работает.
Поэтому если на пилоте руками чистили данные или подкручивали промпт, я прошу записать, что делали и сколько часов ушло. Из списка получаются требования к пайплайну, из часов — строка сметы. Иначе эту работу кто-то оплатит позже и вне договора.
Тот же разрыв виден на хвосте запросов: обращения с тремя задачами сразу, жаргон отдела. Каждый такой случай редкий, а вместе они перестают быть исключением, и средняя метрика пользователю ничего не обещает.
Кто отвечает за систему после сдачи
У пилота есть спонсор — он нашёл бюджет и хотел проверить гипотезу. Отвечать за систему в эксплуатации будет другой человек, которого на демо, как правило, не зову ни я, ни заказчик. В крупных компаниях приёмку делают ещё и третьи люди: информационная безопасность, служба эксплуатации, поддержка. Приходят они, когда решение уже выбрано, и приносят требования, которых не было в ТЗ. Чаще всего пилот и эксплуатация живут в разных бюджетах, и перевод денег между ними идёт отдельным согласованием на несколько месяцев.
Вопрос «кто чинит в субботу» я задаю на каждой встрече. Если ответа нет, значит, нет и понимания, что AI-система ломается иначе, чем обычный сервис. Тихо, без падения — сервис продолжает отвечать, просто неправильно, и мониторинг доступности такое не покажет. Человека, который это поймает, назначают заранее, и он знает процедуру: кто имеет право остановить систему и на какой ручной процесс откатываются на время разбора.
Критерий, который что-то предсказывает
Хороший критерий пилота проверяется без нас. Если для демонстрации нужен человек из команды, который знает, что вводить и куда не нажимать, мы показали квалификацию этого человека. Что я стараюсь записать до старта:
- Выборку для проверки собирает заказчик по своему правилу. Всё, что пришло в отдел за неделю, вместе с дублями и мусором.
- Считаем, сколько обращений прошло сценарий целиком, без ручного подхвата. Доля правильных ответов характеризует модель. В прод едет способность довести обращение до конца.
- Стоимость одного полезного результата известна хотя бы порядком. Считаю её по LCOAI — приведённой стоимости, по аналогии с LCOE в энергетике.
- Условие остановки написали заранее. Пилот, для которого не сформулировали «при таком результате мы дальше не идём», признать неудавшимся уже нечем.
- У качества в проде есть владелец с фамилией. Если на вопрос «кто будет смотреть на метрики после сдачи» отвечают названием отдела, ответа нет.
Даже с честным критерием система ломается на другом. Пока открыты две дороги, при первой ошибке человек, скорее всего, вернётся на старую. И его можно понять. У старого способа отказы привычны, и понятно, кто за них отвечает, а новый выглядит как личный риск сотрудника ради экономии, которая достаётся компании. Процесс не поменялся, если старый шаг остался в регламенте и выключенную на неделю систему никто не хватится.
Пилот стоит начинать только тогда, когда заранее известно, чью ручную работу он отменяет и с какого дня.
Где этот взгляд не работает
Исследовательский пилот под это не подходит. Если вопрос стоит как «возможно ли это в принципе на наших данных», процессного критерия с него требовать рано. Ему нужен отдельный бюджет и договорённость, чем он заканчивается. Проблема начинается там, где такой пилот продают под видом первого шага внедрения, хотя обе стороны видят, что второго шага в плане нет.
Плохо ложится формулировка «люди перестанут делать руками» и туда, где человек в контуре остаётся навсегда — персональные данные или требование регулятора. Там я спрашиваю, сколько времени уходит на один случай при сохранённом контроле. В малом бизнесе эта механика часто избыточна: спонсор, владелец и дежурный обычно один и тот же человек.
Чего я не стал бы делать — превращать это в обязательное условие на первой встрече. Заказчик, который ещё не видел ничего работающего, от анкеты про дежурства рискует уйти к тому, кто пообещает прототип без лишних вопросов. От сделки я не отказываюсь и тогда, когда владелец не назначен. Бывает, что его рождает сам пилот, и не раз будущим владельцем оказывался тот, кто громче всех спорил на демо. Я называю риск вслух и записываю срок, к которому имя должно появиться.
Демо я больше не считаю вехой проекта. Веха наступает позже, в первую неделю, когда система отработала без нас и никто из моей команды в неё не заходил. Поэтому разговор о новом пилоте я начинаю с вопроса, кто перестанет делать что-то руками и у кого есть полномочия отменить старый порядок. Мне проще потерять часть сделки на входе, чем через год объяснять, почему исправная система никому не пригодилась.