7 этапов разработки ИИ-системы для производства

Перед тем как строить модели, мы проводим глубокий анализ. Цель — не просто выслушать ТЗ, а понять контекст: что происходит на производстве, какие процессы страдают, где копятся потери.

На одном из предприятий по производству графитовых изделий руководство сообщило: «Хотим внедрить ИИ для контроля качества». Но уже через первые встречи стало ясно: главная проблема — не качество готовой продукции, а невозможность диагностики состояния печи.

Из-за этого оборудование останавливалось аварийно, терялись миллионы рублей, а срок службы печи сокращался вдвое. Тогда фокус сместился: вместо внешнего контроля мы начали работать над внутренним мониторингом.

Была поставлена чёткая цель: система должна предсказывать износ футеровки за 7–10 дней до критического состояния. Результат измерялся не абстрактным «качеством», а конкретной экономией: количество часов простоя, затраты на ремонт, продление срока эксплуатации.

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

Следующий шаг — проверка, есть ли у предприятия то, на чём может работать ИИ: данные и доступ к ним.

Часто оказывается, что данные есть, но они:

• хранятся в разных системах (ERP, SCADA, Excel);
• не синхронизированы;
• обновляются с задержкой;
• недоступны для внешних систем.

Аудит — один из важнейших этапов. Он показывает, можно ли вообще реализовать задуманное, или сначала нужно доработать инфраструктуру?

Даже если данные есть, их нельзя сразу использовать. Сначала — подготовка. Это самый трудоёмкий этап. До 70% времени в проекте уходит именно на него. Потому что данные редко бывают чистыми.

Часто встречаются пропуски, ошибки, противоречия, разные форматы. Например, при работе с историей брака на комбинате по производству руды мы обнаружили, что традиционные способы контроля (ручной отбор, лабораторные исследования) не всегда дают объективные данные. Чтобы решить эту проблемы, мы внедрили компьютерное зрение и спектральный анализ сырья. 

В результате мы объединили все варианты, создали справочник, привязали к нему показания датчиков и только после этого начали обучение модели.

Если данных мало — используем другие подходы:

• симуляции (например, генерация изображений дефектов);
• transfer learning (обучение на похожих процессах);
• параллельный сбор данных во время разработки.

Главное — не ждать идеальных условий. Лучше начать с того, что есть, и улучшать по ходу.

Теперь переходим к ядру — выбору и обучению модели. Здесь важно понимать: не существует универсального ИИ. Для каждой задачи нужен свой тип алгоритма.

Если нужно распознавать дефекты на фото — подходит компьютерное зрение. Если предсказывать отказ оборудования — модели временных рядов. Если классифицировать тип брака — нейросети с обучением на размеченных данных.

На уже упомянутом проекте по диагностике печи мы использовали комбинацию:

• анализ вибраций;
• температурные профили;
• давление в системе охлаждения.

Модель обучалась на исторических данных, где были зафиксированы случаи аварийных остановок. Мы скорректировали порог чувствительности и добавили весовые коэффициенты для ключевых параметров.

Обученная модель — еще не решение. Она должна пройти проверку в реальной среде.

Мы никогда не запускаем ИИ сразу на весь цех. Сначала — пилот: один станок, одна линия, один тип оборудования. На этом этапе важно сравнивать работу системы с текущими практиками. Например, на участке контроля качества мы параллельно запускали ручную проверку и анализ ИИ.

Спустя время стало ясно: система находила микротрещины, которые человек пропускал, но иногда «видела» дефекты на чистых образцах. Мы собрали эти случаи, перепроверили, дообучили модель — и повторили тест. Уже на третьем цикле расхождение с экспертной оценкой снизилось.

Пилот — это не демонстрация, а диагностика. Он помогает найти слабые места, адаптировать интерфейс, объяснить сотрудникам, как взаимодействовать с системой.

Когда модель работает стабильно, начинается интеграция.
ИИ должен быть частью экосистемы: подключаться к ERP, SCADA, MES, отправлять уведомления в чаты, обновлять статусы в учетных системах.

На одном из проектов мы настроили, чтобы при обнаружении дефекта:
— оператор получал оповещение на планшет,
— в CRM создавалась заявка на корректировку режима,
— в ERP фиксировался брак с указанием причины.

Такая связка превращает ИИ из «умной камеры» в элемент управления процессом.

Особое внимание — интерфейсу. Оператор не должен разбираться в нейросетях.
Ему нужно видеть: что произошло, что делать, куда нажать. Поэтому мы делаем интерфейсы максимально простыми: крупные кнопки, цветовые индикаторы, минимум текста.

И обязательно — возможность ручного вмешательства. Автоматизация не заменяет человека, она его дополняет.

Финальный этап — не конец, а начало. После запуска система продолжает учиться.

Производственные условия меняются: сырьё, климат, режимы работы. Модель нужно дообучать, чтобы она не теряла точность.

Мы настраиваем регулярный мониторинг:

• как часто происходят ложные срабатывания;
• какие параметры выходят за границы;
• как пользователи взаимодействуют с интерфейсом.

На основе этого собираем обратную связь и выпускаем обновления.

Также обеспечиваем техническую поддержку: помощь в случае сбоев, консультации по новым сценариям, обучение новых сотрудников. Мы всегда передаем документацию, исходные коды и план развития. Потому что ИИ-система — это не разовый продукт. Это долгосрочный инструмент, который должен расти вместе с производством.

Разработка ИИ-системы — это поэтапный процесс, в котором каждый шаг зависит от предыдущего. От анализа проблемы до постоянного сопровождения — всё должно быть системным. И самое важное: в этом процессе должны участвовать и бизнес, и технологи, и операторы.