93% успешных на бумаге ML-проектов показывают отрицательный ROI, если из итоговой выручки вычесть тот рост, который случился бы сам по себе.
Если у вас нет зафиксированной точки отсчёта, у вас нет проекта — есть очень дорогая лабораторная работа. Тот самый baseline, без которого ИИ-проект нельзя оценивать: как измерить «как было» до старта — это не бюрократия, а единственная страховка от покупки плацебо.
«Зачем тратить время на замер 'как было'? Мы и так знаем, что операторы ошибаются, а простой конвейера стоит миллион в час. Давайте внедрять компьютерное зрение, профит посчитаем по факту».
Звучит логично, пока не приходит время защищать бюджет. ROI без бейзлайна — это фантазия, натянутая на глобус. Чтобы доказать, что модель принесла деньги, нужно зафиксировать текущие метрики процесса до того, как вы напишете первую строчку кода. Возьмём классический индустриальный ИИ: дефектоскопию на edge-устройствах. Вы не просто смотрите на процент брака. Вы вытаскиваете таймстемпы из базы. Считаете, сколько секунд человек тратит на визуальный осмотр одной детали. Какова цена ошибки первого рода (пропустили брак клиенту) и второго (выкинули годную деталь)? Сколько человеко-часов сжигается в этой рутине ежемесячно? Без этих сухих цифр любая экономия будет восприниматься бизнесом как статистическая погрешность или результат блестящей работы логистов, но никак не вашей нейросети.
«Окей, но у нас нет чистых исторических данных. Процесс менялся, ERP переписывали, логи кривые. Собрать историю невозможно, значит, едем без неё?»
Вы правы, иногда собрать ретроспективу невозможно. Но ехать вслепую — профессиональное самоубийство. Честный трейд-офф в такой ситуации — пилотный замер. Вы замораживаете процесс в его текущем виде и месяц собираете данные «как есть», закладывая это время в сроки проекта. Наш подход в Morana Labs — отказываться от старта ML-разработки, пока этот этап не пройден. Рынок часто продаёт нейросети с порога, мы же предпочитаем сначала измерить температуру по палате, чтобы потом не нести ответственность за чужие управленческие ошибки, скрытые в хаосе процессов. Выделяете контрольный участок, ставите камеры, собираете телеметрию без инференса — просто пишете сырые данные. Да, это сдвигает релиз. Да, заказчик будет недоволен. Но только так вы получите реальную картину.
Эвристика как baseline, без которого ИИ-проект нельзя оценивать
«Ну хорошо, мы замерили. Точность текущего ручного процесса — 70%. Наша новая предиктивная аналитика даёт 85%. Мы победили?»
А вот тут начинается самое интересное. Нейросеть должна соревноваться не с нулём и не с уставшим человеком. Она должна соревноваться с самым простым алгоритмом, который инженер может написать за вечер. Простой baseline — это эвристика, набор жестких правил или SQL-запрос.
# Если простая эвристика бьёт модель по ROI, модель идёт в корзину
def heuristic_baseline(sensor_data):
# Тупое правило: если температура > 90 и давление растёт 3 тика подряд — будет сбой
if sensor_data['temp'] > 90 and sensor_data['pressure_trend'] == 'up':
return True
return False
# Baseline: Precision 0.82, Recall 0.75, Latency 0.1ms, Cost $0
# ML Model: Precision 0.85, Recall 0.81, Latency 45ms, Cost $15k/monthРазница между эвристикой и сложным ИИ в этом примере — жалкие 3% точности. Это и есть та дельта, за которую вы реально платите пятнадцать тысяч долларов в месяц за сервера с GPU и поддержку. Если тупой `if/else` решает 80% проблемы бесплатно и работает на любом микроконтроллере, то тянуть тяжелую нейросеть для оставшихся 20% — это инженерия ради красивых докладов на конференциях, а не ради бизнеса. Модель обязана с запасом побить базовое правило, компенсировав затраты на свой инференс, иначе она не нужна.
«Допустим. Мы внедрили модель, замерили 'после'. Конверсия выросла на 15%, брак упал на 5%. Разве это не доказательство?»
Только если вы обеспечили идентичные условия замера и исключили искажения. Я видел ритейл-проекты, где алгоритмы рекомендаций триумфально «увеличивали» выручку просто потому, что их запуск совпал с сезонными распродажами. И видел производства, где падение брака было связано с новой качественной партией сырья от другого поставщика, а не с внедрением компьютерного зрения на edge-узлах.
Корректный замер до/после требует жесткой изоляции:
- А/В-тестирование в физическом мире: если у вас пять линий, ставьте камеры на одну, а остальные четыре оставляйте как есть. Это ваш контрольный пул.
- Теневое развёртывание: модель крутится на реальных данных в фоне, её решения логируются, но не влияют на конвейер. Спустя месяц вы сравниваете логи модели с реальными решениями операторов за тот же самый период, минута в минуту.
- Изоляция факторов через predictive-analytics: вы строите прогноз того, как вела бы себя система без вашего ИИ с учётом текущей загрузки, износа оборудования и температуры в цехе, и сравниваете фактический результат с этим прогнозом, а не просто цифры до и после.
Бейзлайн — это не метрика ради красивого дашборда. Это железобетонная линия обороны инженера от бизнеса, который через полгода обязательно придёт и спросит, куда ушли деньги.