ИИ-пилот запускают на одном узком процессе с заранее записанным критерием успеха, метриками качества через оценки качества, человеком на проверке и понятным бюджетом на токены. В конце короткого срока вы смотрите на одну цифру и принимаете решение go или kill, поэтому решение опирается на данные вместо ощущений.
Что такое пилот
ИИ-пилот — это короткая проверка одной гипотезы на одном узком процессе с заранее записанным критерием успеха. Он отвечает на единственный вопрос: даёт ли эта связка измеримую выгоду на реальных данных, чтобы вы решили продолжать или закрыть.
В работе с фаундерами я часто вижу одну и ту же историю. Собственник запускает большой проект внедрения сразу на половину команды, хотя ещё нет ни одной цифры, которая подтверждает выгоду на реальных данных. Всё это превращается в долгий проект без точки выхода, где бюджет горит, а понимание, работает ли связка, так и остаётся на уровне ощущений. Пилот решает ровно эту задачу: он отрезает узкий кусок работы, ставит на него измеримую гипотезу и даёт срок, после которого вы смотрите на результат и принимаете решение.
Пилот отличается от полноценного внедрения тремя вещами. Он узкий: один процесс, одна команда из нескольких человек, один тип задач. Он короткий: срок измеряется неделями, чаще двумя-четырьмя, точную длину сверяйте с глубиной процесса. И он заканчивается решением, вместо того чтобы плавно перетекать в постоянную работу. Каждое из этих свойств защищает деньги: узость снижает риск, короткий срок ограничивает горение бюджета, а финальная точка решения мешает связке тихо превратиться в дорогой эксперимент без отдачи.
Сразу внедрять дорого по двум причинам. Первая: пока нет цифры на реальных данных, любой план держится на вере, а вера у разных людей в команде расходится. Вторая: модель ведёт себя на ваших данных иначе, чем на демо, и узнать это можно только на узком куске работы. Пилот покупает вам знание за малые деньги, и это знание потом определяет, во что вкладывать большой бюджет.
Подготовка до запуска
Подготовка решает судьбу пилота сильнее, чем сама модель. До первого запроса к языковой модели у вас должны быть выбраны узкий процесс, записанный критерий успеха, набор метрик качества, схема контроля человеком и потолок бюджета на токены. Когда эти пять вещей зафиксированы заранее, в конце срока вы прекращаете спор об итоге пилота и просто сверяете факт с тем, что записали на старте.
| Что готовите | Как формулируете | Хороший признак |
|---|---|---|
| Узкий процесс | Один повторяющийся тип задач с понятным входом и выходом | Десятки повторений за срок пилота, дешёвая цена ошибки |
| Критерий успеха | Одна цифра и порог, записанные до старта | Например, доля черновиков, ушедших без правок, выше выбранного порога |
| Метрики качества | Что меряете на каждом прогоне через оценки качества | Точность по набору примеров, доля промахов, время на проверку |
| Человек в контуре | Кто и как проверяет результат на старте | Каждый ответ проходит через человека, промахи фиксируются |
| Бюджет на токены | Потолок расхода за срок пилота | Сумма, при которой остановка дешевле продолжения вслепую |
Критерий успеха записывают одной строкой и кладут туда одну метрику с порогом, иначе финал расплывётся на множество мнений. Хороший критерий звучит так: за срок пилота доля черновиков ответов, которые менеджер отправляет без правок, поднимается выше выбранного порога, и среднее время на один ответ падает. Цифры порога подбирайте под свой процесс честно, без гиперболы. Лучше скромный порог, который вы готовы защищать перед командой, чем красивая цель, в которую сами слабо верите.
Записанный заранее критерий лишает финал торга. Когда срок выходит, у людей появляется соблазн подвинуть планку под фактический результат: чуть ниже, если связка справилась слабее, чуть выше, если справилась лучше ожиданий. Цифра, записанная на старте и подписанная всеми участниками, держит решение честным. Вы сверяете факт с числом, и спор о выгоде заканчивается за минуту.
Пошаговый запуск
Запуск идёт по семи шагам: узкий процесс, базовая цифра, критерий, сборка связки, человек на проверке, потолок бюджета, ежедневный замер метрик. Каждый шаг закрывает один риск и приближает честную точку решения.
- Выберите один узкий процесс с понятным входом и выходом, где задача повторяется десятки раз за срок пилота и цена ошибки низкая.
- Зафиксируйте базовую цифру до старта: сколько живого времени уходит сейчас, сколько обращений в день, какая доля проходит вручную.
- Запишите критерий успеха одной строкой с одной метрикой и порогом, подпишите его со всеми участниками пилота.
- Соберите простую связку из языковой модели и сборщика сценариев такого как n8n, при нужде доступа к вашим документам добавьте поиск по документам.
- Поставьте человека на проверку каждого результата через контроль человеком и заведите журнал промахов с короткой пометкой, что пошло мимо.
- Назначьте потолок бюджета на токены и поставьте оповещение, чтобы расход был виден ежедневно и вскрывался заранее, ещё до финала.
- Каждый день снимайте метрики качества через оценки качества на одном и том же наборе примеров, чтобы динамика была видна, а финал опирался на цифры.
Базовая цифра до старта — самый недооценённый шаг. Без неё в конце пилота нечем доказать выгоду: команда чувствует, что стало легче, но числа для сравнения нет, и решение снова уходит в ощущения. Снимите базу честно, до первого запроса к модели. Тогда финальная цифра встанет рядом со стартовой, и разница между ними станет вашим главным аргументом.
Связку держат максимально простой. Цель пилота сводится к проверке гипотезы, и сборка красивой системы тут лишняя. Одна модель, один сборщик сценариев, при нужде поиск по вашим документам, и человек на выходе. Сложную архитектуру с несколькими ИИ-агентами оставляют на потом, когда узкая гипотеза уже подтвердилась цифрой. Лишняя сложность на старте удлиняет срок и размывает причину провала: вы перестаёте понимать, подвела гипотеза или подвела сборка.
Метрики и бюджет
Во время пилота вы следите за тремя вещами одновременно: качеством ответов, нагрузкой на человека-проверяющего и расходом на токены. Качество меряют через оценки качества на фиксированном наборе примеров, чтобы динамика читалась день ото дня. Нагрузку на человека держат на виду, потому что связка, которая требует править каждый ответ, экономит меньше, чем кажется. Расход на токены отслеживают ежедневно, иначе он вскроется только в конце и испортит всю экономику.
- Качество: доля ответов, которые человек принимает без правок, и доля промахов на фиксированном наборе примеров.
- Нагрузка на проверяющего: сколько минут уходит на проверку одного результата и как эта цифра меняется по неделям.
- Поведение модели: частота, с которой она выдумывает факты, и насколько такие промахи заметны проверяющему.
- Бюджет: расход на токены за день и проекция на полный масштаб, если пилот пойдёт в постоянную работу.
- Стабильность: повторяемость результата на одинаковых входах, разброс ответов на похожих задачах.
Человек в контуре на старте проверяет каждый результат, и это даёт сразу две выгоды. Первая: риск держится под контролем, промах ловят до того, как он причинит ущерб. Вторая: проверяющий копит примеры хороших и плохих ответов, и этот журнал потом превращается в материал для настройки связки. Контроль снимают постепенно, по мере роста доверия: сперва выборочно, затем только по спорным случаям. Полностью убирать человека во время пилота рано, это решение принимают уже после успешного завершения.
Бюджет на токены переводят в простую дневную цифру и держат её на виду через оповещение. Стоимость одного прогона удобно прикинуть заранее через стоимость токена, умножив её на типичный объём запроса и ответа. Точные тарифы у провайдеров меняются, поэтому актуальные числа сверяйте на их сайте. Потолок бюджета играет роль предохранителя: когда расход подходит к нему, а критерий успеха ещё далёк, это сигнал остановиться и разобраться вместо того, чтобы жечь деньги вслепую.
Если вы хотите собрать набор метрик под свой процесс и назначить честный порог критерия, принесите описание задачи на разбор, и мы вместе разложим, что мерить и при каких цифрах продолжать.
Точка решения
В конце срока вы сверяете факт с записанным критерием и принимаете одно из двух решений: go — масштабировать связку на соседние задачи, kill — закрыть пилот и зафиксировать вывод. Третий исход, продление срока, допустим один раз и только с новой гипотезой.
Точка решения — главное, чем пилот отличается от бесконечного эксперимента. Когда срок выходит, вы кладёте рядом стартовую цифру, финальную цифру и записанный критерий, и дальше возможны три исхода. Связка перешагнула порог — это go, вы расширяете её на соседние задачи с тем же рисунком работы. Связка осталась ниже порога и динамика плоская — это kill, вы закрываете пилот и фиксируете, что именно подвело. Связка близка к порогу и растёт — допустимо продлить срок один раз, но только с новой записанной гипотезой, что именно вы меняете и какого сдвига ждёте.
| Исход | Что показывают цифры | Следующий шаг |
|---|---|---|
| Go | Критерий перешагнут, человек снимает часть контроля | Расширить связку на соседние задачи, закрепить цифру, спланировать масштаб |
| Kill | Порог далёк, динамика плоская, бюджет на исходе | Закрыть пилот, записать причину провала, вернуть процесс в список позже |
| Продление один раз | Результат близок к порогу и растёт по неделям | Поменять одну переменную по новой гипотезе и задать короткий новый срок |
Решение kill — это нормальный и полезный исход без всякого привкуса провала. Закрытый пилот стоил вам малых денег и узкого среза времени, зато дал точное знание: эта гипотеза на этих данных выгоды лишена. Вы записываете причину, возвращаете процесс в список кандидатов и берётесь за следующий с холодной головой. Худший исход пилота даёт совсем другая ситуация: связка тихо живёт месяцами без решения и потихоньку жжёт бюджет, потому что закрыть её жалко, а цифры для масштаба так и остаются недостижимыми.
Удачный пилот заканчивается одной цифрой и коротким разговором: либо команда сама просит масштабировать связку, либо вы спокойно закрываете её и переходите к следующей гипотезе.