Пилотный проект — короткая проверка конкретной гипотезы об эффекте ИИ на узком сценарии и реальных данных, с критериями успеха, зафиксированными до старта. Пилот отвечает на вопрос «стоит ли вкладывать в полное внедрение», а не на вопрос «работает ли ИИ вообще».
Разница между пилотом и демонстрацией — в последствиях. Демонстрацию показывают и забывают; после пилота принимают решение о деньгах. Если решение о деньгах не принимается, это не пилот, а отчёт за бюджет.
Гипотеза вместо цели «сделать ИИ»
Гипотеза фальсифицируема или её нет. Формулировка «внедрить ИИ в поддержку» — не гипотеза: любой результат можно объявить успехом. Рабочая формулировка: «если ассистент закрывает без оператора не меньше 60% обращений о статусе заказа, время первого ответа падает с 12 минут до 1 минуты, а доля ошибочных ответов не выше 2%». В гипотезе есть метрика, её текущее значение, целевое значение и сценарий.
Гипотеза включает базовое значение. «Снизить время обработки заявки втрое» бессмысленно, пока неизвестно текущее время. Базлайн замеряется до старта пилота — по журналам систем, хронометражу или выборке обращений за последний месяц. После внедрения замерить «как было» уже нельзя.
Одна гипотеза — один пилот. Если проверяются три сценария сразу, результат каждого смазывается: непонятно, что именно не взлетело. Несколько гипотез — либо несколько пилотов, либо явная приоритизация и честная фиксация, что проверяется только первая.
Критерии успеха до старта
Критерии фиксируются письменно до первого эксперимента. После — это подгонка: человек верит в успех пилота и двигает порог, пока результат не станет «успешным». Формально: одностраничный документ с метриками, порогами и условиями замера, подписанный обеими сторонами.
Три уровня критериев. Качество системы — метрики на проверочном наборе: точность, полнота, доля корректных отказов. Процесс — доля обращений, закрытых без человека, время обработки. Эффект — часы, высвобожденные у сотрудников, стоимость обработки обращения. Пилот считается успешным при выполнении всех трёх уровней: высокое качество при нулевой доле автоматических ответов — это хорошая технология без эффекта.
Проверочный набор — часть критерия. Порог «точность не ниже 90%» без указания, на каком наборе и как собранном, неисполним: на лёгких вопросах набор даст 95%, на боевых — 70%. Как собрать набор, чтобы он отражал реальные обращения, — в статье про проверочный набор и бенчмарк.
Заранее опишите, что считается провалом. Честный пилот фиксирует не только порог успеха, но и зону провала: «точность ниже 75% на боевых вопросах — сценарий закрываем». Серая зона между порогами — доработка с указанием причины и срока.
Состав пилота
Узкий сценарий. Один класс обращений, один тип документов, один процесс. Ширина расширяется после успеха, не до него: система, закрывающая один класс обращений на 80%, полезнее системы, трогающей пять классов по 20% — вторая не даёт ни эффекта, ни выводов.
Реальные данные. Обезличенные, но настоящие: выгрузка реальных обращений, настоящие документы, настоящий шум — опечатки, неполные вопросы, устаревшие версии. Пилот на синтетических данных меряет не систему, а фантазию о данных; метрики с синтетики на боевые обращения не переносятся.
Срок 2–6 недель. Короче двух недель не хватает на сбор данных и набор; дольше шести — это уже не проверка гипотезы, а внедрение без обязательств. Если пилот тянется третий месяц, проблема обычно в доступах и отсутствии владельца, а не в технологии.
Владелец со стороны заказчика. Человек, который за 24–48 часов даёт доступы, отвечает на вопросы экспертов и принимает решения по границам сценария. Без него пилот останавливается на первом же согласовании выгрузки. Владелец отвечает за процесс, который автоматизируется, а не за «инновации» — у последнего нет полномочий дать данные.
Результат пилота — измерение, а не система. Главный артефакт — числа: метрики на наборе, базлайн и замер после, список ошибок с причинами. Рабочая система — побочный продукт, который ещё нельзя нести в прод.
Где уместно и когда пилот не нужен
Пилот уместен, когда эффект недоказан. Сценарий новый для компании, данных достаточно, но неизвестно, какая доля обращений реально покрывается, — здесь пилот дешевле ошибки полного внедрения.
Пилот не нужен на типовых сценариях. Бот по базе знаний на чистых внутренних документах — сотни внедрений по рынку; здесь честнее сразу минимальный продукт с проверочным набором, а пилот превратится в оплату изучения известного.
Пилот не заменяет наведение порядка в данных. Если данных нет или они не машиночитаемы, пилот проверит не систему, а качество выгрузки — начните с готовности данных.
Пилот ради отчёта — анти-паттерн. Если задача — «показать совету директоров, что мы в ИИ», любой результат будет объявлен успехом, и деньги потрачены на демонстрацию. Это законная цель, но называйте её демонстрацией и не покупайте на неё шесть недель инженерного времени.
Из пилота в прод и честный провал
Что выносится без переделки. Проверочный набор, методика оценки, промпты и параметры, пайплайн предобработки, журнал ошибок с классификацией причин. Это и есть капитал пилота: даже при провале набор и методика пригодятся следующей итерации.
Что переписывается. Прототипные интеграции «для демонстрации», доступы под логином подрядчика, отсутствие журналирования и обработки сбоев. Доля кода пилота, доживающая до прода без переделки, обычно невелика — 30–50%; закладывайте это в оценку внедрения, а не надейтесь на «осталось только прикрутить».
Порог выхода в прод — не метрика качества, а готовность эксплуатации. Мониторинг, версионирование промптов и набора, план отката, владелец на стороне заказчика. Что именно сопровождает систему в эксплуатации — в статье про MLOps.
Провал — это невыполнение порога при выполнении условий. Данные даны, набор репрезентативный, сценарий не менялся — метрика не достигнута. Такой провал информативен: вы не потратили бюджет полного внедрения.
Классифицируйте причину провала. «Данных недостаточно», «качество базы знаний не выдерживает», «сценарий требует решений, которых нет в документах», «стоимость обработки выше ручной» — это разные выводы: первый ведёт к работе с данными, второй — к чистке базы, третий — к смене сценария, четвёртый — к закрытию темы.
Испорченный пилот — не провал, а не проведённый пилот. Данные дали на третьей неделе, владелец не отвечал, сценарий расширили посередине — результат такого пилота не говорит ничего ни про технологию, ни про сценарий. Честно фиксировать: «проверка не состоялась», и не делать из неё вывод «ИИ у нас не работает».
Анти-паттерны
Критерии после пилота. Механизм: результат известен, порог подбирается под него задним числом. Лечится только письменной фиксацией до старта.
Пилот на вылизанных данных. Эксперты отобрали 50 красивых вопросов — метрика 95% не переносится на поток, где половина обращений с опечатками и смешанными темами. Набор собирается из журналов обращений, а не сочиняется.
Пилот без владельца у заказчика. Подрядчик не может сам себе выдать доступы к CRM; без владельца шесть недель превращаются в три месяца ожиданий. Наличие владельца с полномочиями — условие старта, а не пожелание.
Пилот как первое звено продажи. Если для подрядчика пилот — способ продать большое внедрение, результат пилота будет «успешен, но требует развития» при любом раскладе. Защита — критерии с зоной провала и право заказчика остановиться.
Частые вопросы
Сколько стоит пилот?
Ориентир — 10–20% от оценки полного внедрения: дешевле обычно означает проверку на скорую руку без набора, дороже — внедрение, названное пилотом. По рынку это диапазон от нескольких сотен тысяч рублей за один узкий сценарий до 1,5–3 миллионов при интеграции с внутренними системами. Фикс-цена честна, когда критерии успеха зафиксированы письменно.
Сколько длится пилот?
2–6 недель: неделя на данные и набор, 2–3 недели на итерации, неделя на замеры и выводы. Дольше шести недель — останавливайтесь и разбирайте: обычно выясняется, что пилот держится на согласованиях, а не на инженерии.
Чем пилот отличается от MVP?
Пилот проверяет гипотезу и по определению заканчивается решением — сворачивать или продолжать. MVP — минимальная версия продукта, которая живёт в реальной эксплуатации и развивается. Пилот может перерасти в MVP, но у MVP другое качество инженерии: мониторинг, обработка сбоев, поддержка — то, что пилоту не обязательно.
Метрика на границе порога — успех или провал?
Смотрите распределение, а не среднее: если 80% вопросов система закрывает уверенно, а 20% валят стабильно одного типа — сценарий сужается на эти 80%, и это успех с оговоркой. Если ошибки размазаны по всем типам равномерно — проблема системная, и порог честно не достигнут.
Кто со стороны заказчика должен владеть пилотом?
Руководитель процесса, который автоматизируется: он знает данные, может выделить экспертов на разметку и отвечает за результат. Делегирование «директору по развитию» без полномочий давать доступы — типовая причина зависших пилотов.
Можно ли провести пилот своими силами?
На типовых инструментах — да, и это разумно для проверки простых гипотез. Требования те же: гипотеза, набор, пороги, базлайн до старта. Пилот без проверочного набора, сделанный внутри, доказывает столько же, сколько пилот без набора у подрядчика — ничего.