Пилот прошёл, всем понравилось, дальше ничего не произошло. Со стороны это выглядит как потеря интереса, а на самом деле почти всегда упирается в один разговор: заказчик спрашивает «когда запускаем на всех», подрядчик называет сумму, сопоставимую со всем пилотом или больше, и проект замирает. Обе стороны считают друг друга неправыми, и обе неправы одинаково.
Причина в том, что пилот и эксплуатация — разные инженерные задачи. Пилот отвечает на вопрос «справляется ли технология с нашими данными», и для этого достаточно загрузить выборку файлом и посмотреть на результат. Эксплуатация должна работать без человека, который загружает файл, переживать недоступность модели, объяснять свои решения задним числом и не показывать одному клиенту данные другого. Каждый из этих пунктов — отдельная строка сметы, и в пилоте её нет.
Ошибку при этом совершают в самом начале — в техническом задании на пилот, где нет ни одной строки про объём. Ранний признак виден за минуту: откройте ТЗ и поищите месячный поток обращений и число запросов к модели на одно обращение. Если их там нет, вы покупаете демонстрацию, а не проверку, и разговор про 368 000 ₽ у вас впереди.
Что физически меняется между 50 обращениями и 6 000
Модельный случай, на котором дальше всё считается: ИИ-ассистент поддержки. Пилот — 50 обращений, загруженных выгрузкой, результаты смотрят глазами. Эксплуатация — 6 000 обращений в месяц, то есть примерно 200 в сутки и до 30 в час в пиковые часы.
| Что сравниваем | Пилот, 50 обращений | Эксплуатация, 6 000 в месяц |
|---|---|---|
| Откуда приходят данные | Файл выгрузки, загруженный инженером один раз | Постоянный поток из CRM, почты и мессенджера, без участия человека |
| Что происходит, если модель недоступна | Инженер подождёт и запустит ещё раз | Обращения копятся; нужны очередь, повторы и понятное поведение при отказе |
| Цена запросов к модели | Десятки рублей за весь пилот, строки в смете нет | Отдельная статья бюджета: 2–4 запроса на одно обращение клиента |
| Кто отвечает за неверный ответ | Никто: результаты никуда не уходят | Компания перед клиентом; нужен журнал, кто и на каком основании ответил |
| Разграничение доступа | Все данные видит инженер, это выборка | Один клиент не должен видеть данные другого, сотрудник — не все поля |
| Как узнают, что качество упало | Никак, пилот закончился | Еженедельная выборочная проверка диалогов и месячный отчёт по трём числам |
Ни один из этих пунктов не является придиркой или способом продать больше. Все шесть — следствие того, что у эксплуатации есть свойство, которого у пилота нет: она работает в момент, когда на неё никто не смотрит. Именно за это и берут деньги.
Сравнение в две колонки: «Пилот, 50 обращений» и «Эксплуатация, 6 000 в месяц». Шесть строк: источник данных (файл — постоянный поток), поведение при недоступности модели (подождать — очередь и повторы), цена запросов (десятки рублей — 2–4 запроса на обращение), ответственность за ошибку (никто — компания перед клиентом), разграничение доступа (не нужно — обязательно), контроль качества (нет — 70 диалогов в неделю). Внизу подпись: «Эксплуатация работает тогда, когда на неё никто не смотрит». Чертёжный стиль, подписи по-русски.
Подмена: демонстрация вместо проверки
Вторая половина проблемы — в том, на чём пилот показывали. Подрядчик приносит двадцать диалогов, и все двадцать хорошие. Злого умысла тут обычно нет: инженер настраивал систему именно на этих примерах, они «выучены», и других он и не собирался показывать. Проверкой это не является, потому что проверка — это встреча с данными, которых система не видела.
Случайную выборку можно собрать самому за двадцать минут, и это стоит сделать до того, как подрядчик покажет своё демо. Выгрузите обращения за последние три месяца, отсортируйте по дате и возьмите каждое двадцатое. В выборку обязаны попасть ночные и выходные обращения, обращения с вложениями и хотя бы десяток тех, что закончились жалобой или возвратом. Именно на них и ломается система, которая на «нормальных» диалогах выглядит безупречно.
Разница в модельном примере: 88 % приемлемых ответов на подобранных пятидесяти обращениях и 62 % на случайных трёхстах. Порог, который заранее записали в критерий приёмки, — 75 %. Ни одна из двух цифр его не берёт: первая берёт с запасом, но ничего не значит, вторая значит, но не берёт. Правило про финальный замер на выборке, которую при настройке не показывали, мы подробно разбирали в материале про разницу между MVP и пилотом.
Диаграмма из двух столбцов с горизонтальной линией порога. Первый столбец — «Подобранная выборка, 50 обращений: 88 % приемлемых ответов». Второй — «Случайная выборка, 300 обращений: 62 %». Горизонтальная штриховая линия на отметке 75 % подписана «порог приёмки, записанный до старта». Первый столбец линию превышает, второй не достаёт. Под диаграммой подпись: «Обе цифры честные, значение имеет только вторая». Ось Y — доля приемлемых ответов в процентах.
Пять требований, после которых пилот может стать системой
Разница между пилотом, который умирает на демонстрации, и пилотом, из которого выходят в работу, — это пять пунктов в его техническом задании. Все пять пишутся до старта и стоят одного разговора, а не денег.
- 1Реальные данные случайной выборкой
Не «типичные примеры», а каждое N-е обращение из живого потока за три месяца, включая ночные, с вложениями и конфликтные. Размер — от 200–300 штук: на пятидесяти доля ошибок скачет от случайности и ничего не показывает.
- 2Метрика приёмки, объявленная до старта
Одно число и способ его измерения: например, доля обращений, закрытых без оператора, на контрольной выборке. Метрика, придуманная после того, как увидели результат, — не метрика, а объяснение результата.
- 3Посчитанная стоимость запроса
Сколько обращений к модели приходится на одно обращение клиента и во сколько это обходится при вашем месячном потоке. В пилоте эта строка равна нулю, в эксплуатации она становится постоянным расходом, и её надо увидеть заранее, а не в первом счёте.
- 4Поведение при отказе
Что система делает, когда модель недоступна, отвечает слишком долго или сама не уверена. Правильный ответ — молча передаёт диалог человеку и записывает это в журнал. Неправильный — отвечает наугад, и именно так выглядит большинство пилотов.
- 5Названный ответственный со стороны заказчика
Человек, который смотрит результаты, принимает решение о выходе и потом отвечает за базу знаний. Без него пилот заканчивается письмом «спасибо, интересно», и на этом всё. Роль стоит 4–6 часов в неделю и не может быть отдана подрядчику.
Смета перехода: почему это не «ещё чуть-чуть»
Дальше — то, из чего складывается сумма, которая обычно и останавливает проект. Пилот в модельном примере стоил 180 000 ₽. Ниже — что добавляется, чтобы то же самое работало на потоке 6 000 обращений в месяц без инженера рядом.
Вторая часть, которую замечают ещё позже, — месячный бюджет. В пилоте его не было вовсе: пятьдесят обращений стоят десятки рублей, и никто их не считает. На потоке 6 000 обращений появляется постоянная строка, и её величина зависит не от числа клиентов, а от того, сколько раз система обращается к модели на одно обращение: классификация, поиск по базе знаний, генерация ответа, иногда проверка. Множитель 2–4, и он полностью определяется архитектурой.
Эти 9–15 ₽ и есть тот аргумент, ради которого всё считалось. Обращение, обработанное оператором за 6 минут по полной ставке 700 ₽/час, стоит компании 70 ₽. Разница в четыре-семь раз объясняет и смету перехода, и то, почему её стоит платить. Но признавать экономию деньгами можно только двумя способами — несостоявшимся наймом или ростом объёма без него; как считается признанная, а не потенциальная экономия, мы разбирали отдельно. Норму выборочной проверки в 70 диалогов в неделю и её цену мы тоже считали в отдельном материале.
Сравнение в две колонки. Слева «Пилот — 180 000 ₽» с тремя короткими строками: выборка и разметка, настройка модели, разбор результатов глазами. Справа «Переход в эксплуатацию — 368 000 ₽» с семью строками и суммами: интеграция 120 000 ₽, отказоустойчивость 92 000 ₽, журнал решений 48 000 ₽, права и роли 36 000 ₽, выборочный контроль 24 000 ₽, обучение 30 000 ₽, нагрузка и стоимость запроса 18 000 ₽. Внизу через всю ширину полоса «плюс месячно 54 270–87 580 ₽ — строки, которой в пилоте не было вовсе».
Правило выхода: число, срок и решение
Последнее, что превращает пилот в проект, — записанное заранее правило выхода. Оно состоит из трёх частей, и вычёркивают обычно третью.
- 1Число. Порог на контрольной выборке: не ниже 75 % приемлемых ответов при нуле ошибок в зоне, где ошибаться нельзя, — цены, сроки, формулировки обязательств.
- 2Срок наблюдения. Не «когда посмотрим», а конкретные две-три недели работы на реальном потоке после последней настройки.
- 3Решение при недостижении. Что именно происходит, если порог не взят: проект закрывается без штрафа, заказчик забирает размеченную выборку и отчёт по ошибкам. Без этой строки отрицательный результат каждый раз превращается в предложение продлить проверку ещё на месяц.
Это самый частый способ потратить бюджет полного внедрения, ничего не внедрив. Каждое продление выглядит разумно — «мы почти дотянули, дайте ещё две недели», — и каждое стоит денег и календаря. Порог, придуманный после результата, тоже не работает: он всегда оказывается ровно там, где результат уже есть. Признаки того, что проект пора останавливать, а не продлевать, лучше прочитать заранее, а не на третьем продлении.
Отрицательный результат — нормальный исход, за который уже заплачено, и забрать при нём нужно три вещи: размеченную выборку, перечень типов ошибок и замер текущего процесса. Первые две пригодятся с другим подрядчиком и другой моделью, третья — вообще при любом следующем проекте; почему без базового замера эффект потом не доказать, мы разбирали в соседней статье.
Когда пилот не нужен вовсе
Пилот стоит денег и времени, и в четырёх случаях его правильно пропустить — либо потому, что проверять нечего, либо потому, что проверка дороже самой задачи.
- Задача решается правилами, а не моделью. Разложить обращения по десяти категориям по ключевым словам, проставить статус, отправить уведомление — здесь ИИ добавляет стоимость и непредсказуемость, ничего не добавляя к результату.
- Объём меньше 500 обращений в месяц. Смета перехода в эксплуатацию одинакова при 500 и при 6 000, а экономия отличается в двенадцать раз. Ниже этого порога честный ответ — нанять человека.
- Данных для базы знаний нет. Если ответы на типовые вопросы существуют только в головах троих сотрудников, пилот покажет ровно это, и его результат будет известен заранее. Сначала база знаний, потом проверка технологии.
- Внедрение обязательное, а не окупаемое. Когда требование внешнее и альтернативы нет, проверять надо не «стоит ли», а «каким способом» — и это уже не пилот, а сравнение вариантов.
Во всех остальных случаях полезно помнить главную арифметику этой статьи: пилот — это примерно треть денег, которые уйдут на работающую систему. Если бюджета хватает ровно на пилот, разумнее не начинать: вы получите красивую демонстрацию и разговор, который уже описан в первом абзаце. Более широкий разбор того, почему ИИ-проекты останавливаются на семи разных причинах, мы вынесли в отдельный материал.
