Baseline, без которого ИИ-проект нельзя оценивать: как измерить 'как было' до старта 

93% успешных на бумаге ML-проектов показывают отрицательный ROI, если из итоговой выручки вычесть тот рост, который случился бы сам по себе.

Если у вас нет зафиксированной точки отсчета, у вас нет проекта — есть очень дорогая лабораторная работа. Тот самый baseline, без которого ИИ-проект нельзя оценивать: как измерить «как было» до старта — это не бюрократия, а единственная страховка от покупки плацебо.

«Зачем тратить время на замер 'как было'? Мы и так знаем, что операторы ошибаются, а простой конвейера стоит миллион в час. Давайте внедрять компьютерное зрение, профит посчитаем по факту».

Звучит логично, пока не приходит время защищать бюджет. ROI без бейзлайна — это фантазия, натянутая на глобус. Чтобы доказать, что модель принесла деньги, нужно зафиксировать текущие метрики процесса до того, как вы напишете первую строчку кода. Возьмем классический индустриальный ИИ: дефектоскопию на edge-устройствах. Вы не просто смотрите на процент брака. Вы вытаскиваете таймстемпы из базы. Считаете, сколько секунд человек тратит на визуальный осмотр одной детали. Какова цена ошибки первого рода (пропустили брак клиенту) и второго (выкинули годную деталь)? Сколько человеко-часов сжигается в этой рутине ежемесячно? Без этих сухих цифр любая экономия будет восприниматься бизнесом как статистическая погрешность или результат блестящей работы логистов, но никак не вашей нейросети.

«Окей, но у нас нет чистых исторических данных. Процесс менялся, ERP переписывали, логи кривые. Собрать историю невозможно, значит, едем без нее?»

Вы правы, иногда собрать ретроспективу невозможно. Но ехать вслепую — профессиональное самоубийство. Честный трейд-офф в такой ситуации — пилотный замер. Вы замораживаете процесс в его текущем виде и месяц собираете данные «как есть», закладывая это время в сроки проекта. Наш подход в MoranaLabs — отказываться от старта 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: вы строите прогноз того, как вела бы себя система без вашего ИИ с учетом текущей загрузки, износа оборудования и температуры в цехе, и сравниваете фактический результат с этим прогнозом, а не просто цифры до и после.

Бейзлайн — это не метрика ради красивого дашборда. Это железобетонная линия обороны инженера от бизнеса, который через полгода обязательно придет и спросит, куда ушли деньги.