Бизнес хочет магию. Данные говорят: "Забудь"
Завод металлоконструкций в Сибири. 2025 год. Директор по производству в ярости: "Нам нужен ИИ!" Не просто нужен, а прямо сейчас. Проблема стара как мир - нормировщики тратят недели на расчёт времени изготовления деталей. Задержки в планировании, срывы сроков, постоянные переработки.
Задача звучит просто: по чертежу детали предсказать, сколько времени уйдёт на её изготовление. В теории - идеальный кандидат для машинного обучения. На практике - классический пример того, почему 95% пилотных проектов превращаются в хлам.
Ключевая ошибка №1: заказчик верит, что ИИ решит проблему автоматически. Разработчик молчит, потому что боится потерять контракт. Результат предсказуем.
Что пошло не так сразу
Команда data science'ов приступила к работе с энтузиазмом. Первый же день убил все надежды.
1 Данные? Какие данные?
Оказалось, что "база данных" - это 15 Excel-файлов в разных папках. Некоторые - на флешке у уволившегося нормировщика. Форматы: .xls, .xlsx, .csv с разделителями то запятой, то точкой с запятой. Кодировки: Windows-1251, UTF-8, CP866 (да, ещё и DOS'овская).
Столбцы в таблицах назывались по-разному: "Время", "Трудозатраты", "Часы", "Норма часа". Иногда время в минутах, иногда в часах, иногда вообще в "человеко-днях".
| Что было в данных | Что ожидалось | Реальность |
|---|---|---|
| Названия операций | Стандартизированный справочник | "Резка", "Резка металла", "Резка листа", "Порезать" |
| Единицы измерения | Минуты или часы | "2.5" (часа? дня?), "180" (минут?), "0.3" (доли дня?) |
| Характеристики деталей | Чёткие параметры | "Большая пластина", "Труба обычная", "Кронштейн" |
2 Чертежи как они есть
Чертежи хранились в AutoCAD, но версии разные: от 2005 до 2024. Некоторые - в PDF, отсканированные с бумажных копий. Распознать размеры автоматически? Забудьте. Штампы заполнены от руки, размеры наложены друг на друга, слои не разделены.
Самое смешное: в 30% случаев фактические размеры детали отличались от чертёжных. "На чертеже 10 мм, но мы всегда делаем 12 - так надёжнее", - объяснил технолог.
Ошибка в самой постановке задачи
Здесь начинается главная трагедия. Команда решила использовать регрессионные модели (XGBoost, LightGBM) для предсказания времени. Казалось логичным: много признаков - сложная нелинейная зависимость.
Но! Нормы времени на производстве - это не физический закон. Это договорённость между рабочими, нормировщиками и плановиками. Социальный конструкт, а не объективная реальность.
- Новая деталь похожа на старую? Нормировщик берёт аналогию и добавляет "на всякий случай" 20%
- Срочный заказ? Норму "упрощают" чтобы уложиться в срок
- Рабочий Петров делает быстрее Иванова? Но норма одна для всех
- Станок устарел и постоянно ломается? В норму уже заложен простой
Модель пыталась найти закономерности там, где их не было. Точнее, закономерности были, но не математические, а социально-производственные.
Ключевая ошибка №2: применение ML к задаче, которая требует экспертных систем, а не статистических моделей. Нормирование - это экспертиза, а не регрессия.
Что сработало бы (но никто не попробовал)
Через три месяца и 2.5 миллиона рублей проект закрыли. Модель давала ошибку в 40-60%, что хуже, чем опытный нормировщик (15-20%). Но решение было не в более сложных нейросетях.
Вариант А: Система поддержки принятия решений
Вместо полной автоматизации - помощь нормировщику:
- Автоматическое извлечение размеров из чертежей (да, с ручной проверкой)
- Поиск похожих деталей в истории с их нормами
- Расчёт "теоретического" времени по технологическим картам
- Подсветка отклонений от типовых норм
Нормировщик остаётся в контуре, но работает в 3-4 раза быстрее. Система не заменяет эксперта, а усиливает его. Именно такой подход сейчас доминирует в успешных цифровых проектах на заводах.
Вариант Б: Вероятностное нормирование
Вместо одного числа "6.5 часа" - распределение: "с вероятностью 70% уложимся в 6 часов, с вероятностью 90% - в 7 часов, с вероятностью 5% будет 9 часов из-за возможных проблем со станком".
Это меняет всю логику планирования. Плановик видит не только время, но и риски. Такой подход требует другого мышления, но он честнее. Кстати, именно о вероятностном мышлении для ИИ мы писали в статье про PMR-метод.
Уроки, которые стоили 2.5 миллиона
| Ошибка | Почему произошла | Как избежать |
|---|---|---|
| Не проверили данные на старте | Желание поскорее начать "крутой ML-проект" | Потратить 2 недели на аудит данных до подписания контракта |
| Решили полностью заменить людей | Заказчик хотел сократить издержки, разработчик - показать магию ИИ | Начинать с augmentation (усиления), а не automation (замены) |
| Игнорировали социальный контекст | Технари думали только о данных и моделях | Включить в команду социолога или бизнес-аналитика с опытом в промышленности |
| Не определили критерии успеха | "Будет работать" - не критерий | Конкретные метрики: сокращение времени нормирования на X%, точность не ниже Y% |
А что с современными LLM? Они спасли бы проект?
На 05.02.2026 большие языковые модели типа GPT-5, Claude 4 или отечественных аналогов стали умнее. Но проблема не в интеллекте модели, а в данных.
LLM могла бы:
- Стандартизировать описания операций ("Резка" → "Резка металла лазером")
- Извлекать параметры из неструктурированных описаний деталей
- Генерировать предположения о похожих деталях
Но! LLM не решает проблему грязных исторических данных. Не исправляет ошибки в размерах. Не знает, что станок №3 постоянно перегревается. И главное - не понимает производственных договорённостей цеха.
Типичная ошибка - пытаться решить LLM'ями проблемы данных. Получается дорогая cron-задача с красивым интерфейсом.
Когда ML в промышленности действительно работает
Не всё так печально. Есть области, где машинное обучение даёт реальную пользу:
- Прогноз поломок оборудования - данные с датчиков, чёткие метрики, физические закономерности
- Оптимизация энергопотребления - объективные измерения, математические модели
- Контроль качества - компьютерное зение для дефектов, чёткие критерии
- Планирование маршрутов - задачи оптимизации, где ML дополняет традиционные алгоритмы
Общее правило: ML работает там, где есть объективные измеримые данные и физические/статистические закономерности. Не работает там, где решения основаны на экспертизе, договорённостях и социальных факторах.
Перед любым промышленным ML-проектом задайте вопрос: "Это задача для эксперта или для статистики?" Если для эксперта - не используйте чистый ML. Стройте экспертные системы с элементами ML, а не наоборот.
Что делать, если вас всё же заставляют делать "невозможный" проект
Ситуация знакомая: руководство требует внедрить ИИ, данные - катастрофа, сроки - вчера.
- Сразу скажите о проблемах - письменно, с примерами. Не надейтесь, что "как-нибудь получится"
- Предложите пилот на маленьком сегменте - не весь завод, а один цех. Не все детали, а один тип
- Внедряйте поэтапно - сначала структурирование данных, потом помощь эксперту, только потом автоматизация
- Измеряйте промежуточные результаты - не точность модели, а время нормирования, удовлетворённость нормировщиков
- Готовьте запасной вариант - что будет, если ML не сработает? Часто оказывается, что простое правило-движок даёт 80% результата за 20% стоимости
И помните: успешный промышленный AI-проект начинается не с выбора модели, а с оценки зрелости процессов компании. Если процессы хаотичны, данные - помойка, а люди сопротивляются изменениям, никакой GPT-10 не поможет.
Будущее: ИИ, который знает, что он не знает
К 2026 году стало очевидно: следующий прорыв в промышленном ИИ - не в увеличении параметров моделей, а в создании систем, которые понимают границы своей компетенции.
Модель должна уметь сказать: "Эта деталь слишком непохожа на то, что я видел. Дай мне больше параметров или передай эксперту." А не молча выдавать число с 60% ошибкой.
Пока же мы живём в эпоху, когда ИИ преуспевает в создании картинок и текстов, но проваливается в простых промышленных задачах. Ирония в том, что генеративные модели умеют имитировать экспертов, но не могут заменить их там, где нужна реальная экспертиза.
Мораль проста: если на вашем заводе хотят внедрить ИИ для нормирования - начните с цифровизации данных. Потом стандартизируйте процессы. Потом внедрите простые правила. И только потом, возможно, добавьте немного машинного обучения. В такой последовательности есть шанс на успех. В обратной - гарантированный провал за миллионы рублей.
Как сказал один мудрый нормировщик после закрытия проекта: "ИИ научился считать, но не научился понимать, что считать".
