Промышленная компания запустила пилот с ИИ и потратила на него пару миллионов рублей за квартал. Модель работает, метрики устраивают, комитет дает зеленый свет на масштабирование в производственный контур. Через год бюджет вырастает на порядок, и никто в компании не может внятно объяснить, откуда взялась разница. Разница не появилась внезапно. Она была заложена в момент, когда компания посчитала стоимость операции и назвала это стоимостью решения. Почему TCO ИИ-контура считают по жизненному циклу, рассказывает Станислав Ежов, директор по развитию ИИ в ПАО «Группа Астра».
На пилоте
Пилот измеряет узкий срез: подписку на модель, часы подрядчика, время команды на настройку. Для проверки гипотезы этого достаточно. Для решения о масштабе этого мало. Полную стоимость владения видно только на всем жизненном цикле продукта, от запуска до списания контура. На пилотном этапе большая часть этого цикла еще не началась, поэтому и считать ее нечем.
Шесть статей, которые пилот не видит, весят по-разному. Крупнее прочих обычно оказываются интеграция и контроль, ведь они включаются в момент подключения к боевым системам, а не растут постепенно вместе с нагрузкой, как вычисления. Обучение растет вместе с числом задействованных сотрудников. Поддержка растет вместе с числом сценариев в проде. Оба процесса набирают вес постепенно, поэтому их проще всего забыть в бюджете. Простои зависят от масштаба нагрузки и от цены каждой конкретной ошибки, поэтому их чаще всего оценивают неверно: то дешево, то дорого.
Цена инференса на пилоте предсказуема, потому что нагрузка укладывается в тестовый лимит. На проде нагрузка колеблется по часам и дням, и вычисления начинают стоить по пиковому спросу, а не по среднему.
Пилот обычно живет в изоляции от основных систем, поэтому интеграция на этом этапе незаметна. В контуре все иначе: модель нужно состыковать с учетными системами, очередями данных, регламентами доступа, и тут появляется работа, которую на этапе гипотезы никто не считал.
На пилоте модель работает с отобранной выборкой, а не с реальным потоком данных. Когда поток становится реальным, данные дрейфуют, качество ответов меняется, и стабильность приходится держать постоянно, а не один раз при внедрении.
Лучше один раз увидеть
Требования к контролю не берутся из ниоткуда — чем шире контур ответственности, тем строже аудит решений и объяснимость. На пилоте с одним ограниченным сценарием эти требования можно пропустить, особенно если речь не идет о критической инфраструктуре или госсекторе.
Проще один раз показать людям интерфейс на демо, чем перестроить процесс для всей смены. Пилот останавливается на демо, контур идет дальше, в перестройку процесса. Меняются роли, часть сотрудников сопротивляется, пока не пройдет собственную адаптацию, и это время редко попадает в исходную смету.
Простой на пилоте обходится в ноль, потому что от него ничего не зависит. Когда контур становится частью операционного процесса, та же ошибка модели останавливает работу компании, и цену остановки трудно оценить заранее, потому что до внедрения в контур она равнялась нулю.
Почему перелом происходит скачком
Стоимость не растет равномерно при переходе от пилота к промышленному контуру. Несколько статей включаются одновременно, потому что их запускает одно и то же событие. Интеграция с боевыми системами открывает контуру доступ к реальным операциям, и этот доступ сразу поднимает требования к контролю и создает риск простоя.
Три статьи растут из одного и того же шага, а обучение и поддержка продолжают набирать вес медленно и незаметно. Кажется, что стоимость выросла внезапно, а на деле компания впервые увидела расходы, которые были в проекте с самого начала.
Мощность растет быстрее, чем способность компании превращать ее в управляемый результат. Каждая непосчитанная статья TCO забирает часть этой мощности на разбор долга, который заметили слишком поздно. До прибыли эта часть уже не доходит.
Стандарт расчета до пилота
Перед запуском пилота от команды необходим предварительный расчет TCO по всем шести статьям на весь срок промышленной эксплуатации, а не только смета самого пилота. За вычисления и интеграцию отвечает техническая команда. За контроль и обучение отвечает бизнес-подразделение, которое работает с контуром. Все шесть статей в одну цифру сводит финансовая служба. Без этого расчета не стоит выносить инициативу на комитет.
Цифра пилота отвечает на вопрос, стоит ли проверять гипотезу. Вопрос о масштабировании требует другого расчета. Смешивая эти два расчета, компания узнает реальную стоимость контура постфактум, когда цена ошибки уже включена в бюджет.
Читайте также: