Пилот показали в переговорной, все довольны. Через полгода система работает в лучшем случае у двух энтузиастов, а в отчёте написано «низкая зрелость технологии».
Технология тут почти ни при чём. Разрыв между работающей демонстрацией и работающей системой существовал и до языковых моделей — просто ИИ сделал первую половину пути слишком лёгкой. Собрать нечто впечатляющее за неделю теперь может любой. Именно поэтому дальше спотыкаются чаще, чем раньше: пилот перестал быть фильтром.
Ниже — места, где это происходит. Все они видны заранее, и почти все закладываются в план до начала работ.
Пилот отвечал не на тот вопрос
Демонстрация отвечает на вопрос «может ли это в принципе работать». Ответ почти всегда «да» — и почти всегда бесполезен.
Продакшен отвечает на другие вопросы. Сколько случаев система закрывает сама, без человека. Что происходит в остальных. Сколько стоит один разбор. Что будет, когда обращений станет в десять раз больше. Кто чинит, когда сломалось в субботу.
Пилот, который не пытался ответить хотя бы на первые два, не приблизил проект к запуску — он только создал ощущение, что приблизил.
Что делать. Формулировать критерий до пилота, а не после: «система закрывает сама не меньше половины обращений такого-то типа, при этом ни разу не отвечает уверенно там, где данных нет». Цифра может быть любой, важно, что она есть и согласована.
Демонстрировали на удобных примерах
Естественное человеческое желание — показать то, что получается. Для пилота берут понятные запросы, чистые документы, типичные случаи.
Продакшен состоит из другого. Из обращения, где три вопроса сразу и один не по адресу. Из скана, который сняли телефоном под углом. Из клиента, который пишет «ну это, как в прошлый раз». Из документа, который отменили полгода назад, но из папки не убрали.
Доля таких случаев в реальном потоке обычно оказывается выше, чем предполагали, — и именно она определяет, будут ли пользоваться системой.
Что делать. Набирать проверочные случаи не из головы, а из реального потока за последний месяц — вместе с теми, кто обрабатывает их руками. Специально включать туда неудобное: неполные запросы, плохие сканы, вопросы без ответа.
Не считали, сколько работы вокруг
Самая недооценённая статья. Модель и промпт — это малая часть системы; остальное занимает столько же времени или больше.
Доступ к системам компании и права. Поведение, когда интеграция вернула ошибку или отвечает дольше обычного. Журнал действий. Разграничение, кто что видит. Мониторинг и оповещения. Разбор спорных случаев. Обновление данных, чтобы система не разошлась с реальностью.
Ничего из этого не видно на демонстрации — и ничего из этого нельзя пропустить при запуске.
Что делать. Закладывать в план примерно половину срока на то, что не является моделью. Если оценка проекта состоит только из «обучить и подключить», она занижена вдвое.
Никто не отвечал за данные
ИИ-проект гораздо чаще упирается в данные, чем в алгоритмы.
Документы лежат в трёх местах в четырёх редакциях. Половина в сканах. Выгрузка из учётной системы возможна, но её делает человек, у которого нет на это времени. Справочник товаров ведут два отдела по-разному.
Пока это не разобрано, любая система будет уверенно отвечать по устаревшей редакции — и формально работать правильно.
Что делать. До начала разработки назначить со стороны заказчика человека, который отвечает за данные и имеет полномочия решать, какая редакция действующая. Без такого человека проект будет буксовать независимо от подрядчика.
Считали, что точность — это всё
Точность легко измерить, поэтому её и обсуждают. Но пользоваться системой перестают не из-за неё.
Перестают из-за того, что система уверенно ответила неправду, и это заметили. Один такой случай стоит дороже десяти правильных ответов: доверие не восстанавливается цифрами.
Поэтому отказ — часть функциональности, а не признак слабости. Система, которая честно закрывает восемь случаев из десяти и на двух говорит «не знаю, вот кому написать», полезна и живёт. Система с теми же восемью, но выдумывающая на оставшихся двух, умирает после первого разбора.
Что делать. Проверять отказы отдельным набором случаев, где правильный ответ — «данных нет». Обещать сотрудникам ровно то, что система делает, и ни словом больше.
Внедряли в вакууме
Система приходит в чужой устоявшийся процесс. У людей есть привычный способ работы, который их устраивает, и часто — обоснованное подозрение, что новое придумано, чтобы их сократить.
Если о внедрении узнали из рассылки в день запуска, дальше происходит предсказуемое: систему не используют, а на вопрос «почему» отвечают «она неудобная».
Что делать. Вовлекать тех, кто будет пользоваться, с этапа сбора проверочных случаев. Это не про мотивацию, а про качество: они единственные знают, как выглядят настоящие обращения. Побочный эффект — к запуску у системы уже есть люди, которые считают её своей.
Как выглядит пилот, который доезжает
Описанное выше легко читается как список запретов, поэтому вот обратная сторона — как выглядит работа, которая заканчивается запуском.
Одна задача, а не «внедрить ИИ». Не «автоматизировать поддержку», а «разбирать входящие заявки одного отдела и заводить их в CRM». Узкая формулировка даёт понятный ответ за три-четыре недели и не позволяет спрятать неудачу за общими словами.
Критерий на бумаге до старта. Одна-две цифры, под которыми подписались обе стороны. Не «повысить эффективность», а «закрывать без человека не меньше половины заявок такого-то типа при нуле уверенных ответов там, где данных нет».
Проверочный набор из реального потока. Несколько сотен случаев за последний месяц с тем, чем они на самом деле закончились. Собирают их те, кто делает эту работу руками, — и это же вовлекает их в проект раньше, чем он на них свалится.
Честный список того, чего система не делает. Составляется в те же сроки, что и список возможностей, и показывается пользователям вместе с ним. Ожидание, заданное точно, переживает первую ошибку; завышенное — нет.
Половина плана на всё, что не модель. Интеграции, права, журнал, поведение при отказах. Если эта часть в плане отсутствует, она всё равно случится — только за счёт срока.
Решение о продолжении по цифрам. По итогам пилота смотрят на проверочный набор и на журнал, а не на впечатление от демонстрации. Отрицательный результат здесь — нормальный исход и дешёвый: четыре недели вместо года.
Ничего из этого не относится к ИИ. Это обычная инженерная дисциплина, которая просто стала заметнее: когда прототип собирается за неделю, единственное, что отличает проект от игрушки, — то, как он устроен вокруг прототипа.
Короткий чек-лист
Прежде чем запускать пилот, стоит иметь ответы:
- Какой измеримый критерий отделяет успех от неудачи и кто его согласовал
- Откуда берутся проверочные случаи и сколько их
- Что система делает, когда данных не хватает
- Кто со стороны заказчика отвечает за данные и их актуальность
- Какие действия система выполняет сама, а какие — только с подтверждением
- Сколько времени в плане отведено на интеграции, права и журнал
- Кто пользуется результатом и когда он об этом узнает
Если на большинство есть ответ, пилот покажет то, ради чего его делают. Если ответов нет, он покажет, что технология работает, — а это и так известно.
Мы разрабатываем ИИ-агентов для рабочих процессов и агентов по документации компании: начинаем с разбора процесса и честно говорим, если задача решается без ИИ.
Связаться: Telegram @xtrueman · info@llmtech.ru · llmtech.ru