Предиктивные агенты на заводе: как это работает и что даёт

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

Что именно внедряют

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

Агентный контур встраивается поверх этого потока и делает три вещи, которые раньше делал (или не делал) инженер:

• Наблюдает непрерывно. Не раз в смену, а каждые несколько секунд по всем узлам сразу.
• Ставит диагноз в терминах, а не в цифрах. Не «вибрация 4,2 мм/с», а «износ подшипника опоры №3, оценочный ресурс — 10–14 дней».
• Действует. Создаёт заявку в системе технического обслуживания и ремонта (ТОиР), резервирует запчасть на складе, предлагает окно для остановки.

Ключевое слово — «предлагает». В нормальной реализации агент не останавливает линию сам. Он готовит решение, а нажимает кнопку человек. Об этом разграничении — отдельно ниже, потому что именно на нём ломается половина внедрений.

Из чего собран контур

Разложим на слои, чтобы было видно, где живут агенты, а где обычный код.

• Сбор данных. Датчики, промышленные контроллеры, протоколы вроде OPC UA. Это инженерия, а не ИИ, и обычно самая недооценённая по трудозатратам часть.
• Модели детекции аномалий. Классический ML: узкие модели, которые ловят отклонения по вибрации, температуре, спектру. Их не заменяет большая языковая модель — они точнее и дешевле в этой задаче.
• Агентный слой. Здесь языковая модель получает выводы детекторов, историю ремонтов, регламенты производителя оборудования (через RAG**) и собирает из этого связное объяснение и план действий.
• Интеграция с ТОиР. Заявка, склад, календарь техобслуживания. Без этого агент остаётся генератором красивых отчётов, которые никто не читает.

Датчики и заявки в ТОиР — не украшение проекта, а его половина. ИИ добавляет диагноз, но если диагноз некуда отправить, он умирает в дашборде.

Что меняется в цифрах

Честный ответ: конкретную экономию нельзя назвать в отрыве от завода. Она зависит от того, сколько стоит час простоя линии, как часто ломается оборудование и что было до внедрения — плановые ремонты по регламенту или ремонт по факту аварии. Публичных цифр по конкретному российскому внедрению, которые можно было бы процитировать с источником, у меня нет, поэтому выдумывать проценты «сокращения простоев на 37%» я не буду — такие числа в презентациях вендоров стоит проверять по вашему собственному учёту.

Что можно сказать по механике эффекта:

• Аварийная остановка дороже плановой. Внеплановый ремонт тянет за собой брак незавершённой партии, срочную доставку запчасти и переработки. Перевод части поломок из «внезапных» в «предсказанные за неделю» — и есть источник экономии.
• Отказ от избыточной профилактики. Замена узла по календарю, когда он ещё бы отработал полгода — это выброшенная запчасть и лишний простой на обслуживание.
• Меньше нагрузки на дефицитных специалистов. Опытный диагност вибрации — редкая роль. Агент не заменяет его, но снимает рутину первичного просмотра графиков.

Агент против классического мониторинга

Чтобы не было ощущения, будто это то же самое под новым названием, сравним три подхода.

Разница между второй и третьей колонкой — не в наличии ИИ ради ИИ, а в том, доводит ли система сигнал до конкретного действия и объяснения. Порог «вибрация выше X» даёт много ложных тревог и не говорит, что делать. Агент связывает сигнал с историей узла и регламентом.

Кому это пригодится, а кому нет

Где эффект вероятен

• Непрерывное производство, где час простоя стоит дорого: металлургия, химия, целлюлозно-бумажная отрасль. Там даже редкое предотвращённое ЧП окупает контур.
• Дорогое или уникальное оборудование с долгой поставкой запчастей: предсказать поломку за две недели — значит успеть заказать деталь.
• Заводы, где датчики уже стоят, но данные не используются. Здесь основная работа — не установка сенсоров, а надстройка над готовым потоком.

Где это скорее лишние траты

• Мелкосерийное производство с дешёвым простоем. Если линию можно остановить на час без последствий, дорогой предиктивный контур не окупится.
• Оборудование без датчиков. Дооснащение сенсорами всего парка — отдельный большой проект, и начинать надо с него, а не с агентов.
• Компании без выстроенного ТОиР. Если заявки на ремонт живут в мессенджере и на бумаге, агенту некуда отдавать результат. Сначала процесс, потом ИИ поверх него.

Где ломаются такие проекты

Три частые причины провала, о которых редко пишут в кейсах-победах:

1. Данных мало или они грязные. Модель деградации подшипника нужно на чём-то обучить. Если истории поломок нет, первые месяцы система учится, а не предсказывает.
2. Люди не доверяют. После нескольких ложных тревог операторы начинают игнорировать заявки агента — и пропускают настоящую. Доверие набирается только прозрачностью объяснений и настройкой чувствительности.
3. Автономность без надзора. Дать агенту право самому останавливать линию — соблазнительно и опасно. Промышленный контур строят так, чтобы финальное решение по остановке оставалось за человеком.

* Агент — программа на базе ИИ, которая не просто отвечает на запрос, а сама планирует шаги, обращается к внешним системам (датчики, база заявок, склад) и доводит задачу до действия, а не до текста.

** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает нужные документы (здесь — регламенты и историю ремонтов) и опирается на них, вместо того чтобы полагаться только на то, что запомнила при обучении.