С 2024 года в российской промышленности менялся подход к инвестициям в ИИ. Если еще недавно компании были готовы экспериментировать с цифровыми инициативами «на вырост», то теперь инвест‑бюджеты сокращены (а кое‑где просто порезаны), при этом требования к проектам стали кардинально жестче. Деньги выделяются на то, что дает измеримый эффект «здесь и сейчас» — на проекты с горизонтом более года советы директоров финансирование просто не дают. При этом направлений, где ИИ окупается за 6–12 месяцев, немного, но они есть. И эта статья — про обобщение проектного опыта команды SSP SOFT в промышленности. 

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

Итак, разберем четыре типа ИТ‑проектов, где применение ИИ действительно может окупиться в течение 6–12 месяцев. Статья получилась большая, поэтому перейти внутри статьи к каждому направлению можно по ссылке:

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

• оптимизация технологических режимов,

• автоматический контроль качества,

• анализ инцидентов и производственных отклонений на основе языковых моделей и производственных данных.

Отдельно по каждому направлению будут приведены комментарии и наблюдения из практики команды SSP SOFT — без раскрытия заказчиков, но с акцентом на реальные задачи, ограничения и полученные эффекты.

О реальности годового горизонта окупаемости ИИ‑проектов 

В самом начале статьи важно сказать следующее: горизонт окупаемости ИИ‑проектов до 1 года реалистичен при одном важном условии — на предприятии уже есть базовая ИТ‑инфраструктура. Это оцифрованные документы, работающая АСУ ТП, хотя бы минимальная шина данных. Если это все присутствует, локальный ИИ‑проект на конкретном переделе (установке, линии) можно запустить и получить ожидаемый результат в разумные сроки.

Если же инфраструктуры нет (что чаще), картина меняется кардинально. Проект, заявленный как внедрение ИИ, на деле превращается в строительство цифрового фундамента. С нуля проектируется хранилище данных, выстраивается шина сбора и обработки данных, параллельно оцифровываются бумажные документы и технологические инструкции. При этом значительная часть производственной информации — от технологических карт ТУ до сменных заданий — по‑прежнему существует только на бумаге. В таких условиях сроки и бюджет проекта становятся трудно предсказуемыми, а сам ИИ оказывается венцом стройки, до которого очередь доходит последней.

Прагматичный вывод: прежде чем запускать ИИ‑проект, следует пригласить ИТ‑подрядчика провести ИТ‑аудит и оценить зрелость инфраструктуры и внутренних процессов предприятия. Часть проектов разумнее не начинать вовсе — даже если задачи актуальны, но предприятие к цифровизации пока не готово. 

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

1. Предиктивное обслуживание оборудования в промышленности с помощью цифровых двойников

Когда говорят о цифровых двойниках в контексте быстрой окупаемости, надо уточнить масштабы проектов. Цифровой двойник целого предприятия — это многолетний проект с неочевидным «инвестиционным выхлопом» (ROI). А цифровой двойник конкретного редуктора прокатного стана или насосной группы — это именно те проекты, где посчитать экономию гораздо проще и она окупит ИТ‑проект.

К примеру, в металлургии (где у SSP SOFT хороший опыт ИТ‑проектов) типичный список таких узлов выглядит так:

• Подшипники прокатных клетей и конвейеров — работают в условиях ударных нагрузок, загрязнения, высоких температур.

• Редукторы главных приводов — дорогостоящие, с длинным сроком поставки запасных частей.

• Насосы систем охлаждения и гидравлики — отказ приводит к остановке прокатного стана.

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

Что такое «цифровой двойник узла» без тумана маркетинга

Важно правильно понимать сущность термина «цифровой двойник». Хотя в презентациях двойник обычно изображается как фотореалистичная 3D‑модель, на практике это система математических зависимостей. Эти зависимости описывают (моделируют) работу узла с целью расчета износа критических компонентов по формулам и сравнения с реальными данными с датчиков на оборудовании: 

• Физико‑математическая модель нормального поведения узла, построенная на основе его конструктивных параметров, режимов нагрузки и исторических данных по износу и отказам.

• Набор датчиков, регистрирующих вибрацию, температуру, ток, давление, акустическую эмиссию (шумность) — в зависимости от типа оборудования.

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

• Система оповещений с конкретным горизонтом — например, «через 12–18 дней вероятен прогрессирующий износ подшипника № 3, через 20–24 дня полное разрушение».

Горизонт предупреждения — ключевой параметр у моделей, описывающих цифровой двойник. Он должен быть достаточным, чтобы успеть заказать запчасть, спланировать окно обслуживания и не ломать производственный план. На практике для большинства узлов это от 7 до 30 дней — именно в этом диапазоне двойник создает реальную выгоду предприятия от предиктивного обслуживания.

Довод #1: рассчитать экономию от «условных аварий» 

Это самый яркий довод. На презентациях для советов директоров принято показывать экономический эффект от предиктивного обслуживания в первую очередь в виде стоимости условных предотвращенных аварий. К сожалению, в большинстве случаев, маркетологи интеграторов продают предприятиям не выгоду, а страх. Хотя выгоду продавать правильнее.

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

Стоимость аварийного ремонта, как правило, в 3–5 раз дороже планового из‑за срочности, ночных смен и экспресс‑доставки запчастей, стоимость попутного ущерба — простоя линии, возможного повреждения смежного оборудования, и наконец потери от брака продукции в момент аварийной остановки. 

Для крупного редуктора прокатного стана совокупная стоимость одного аварийного отказа легко достигает суммы 10+ млн рублей. Система мониторинга, выдавшая предупреждение о вероятности отказа за 7–10 дней и предотвратившая один такой инцидент за год, окупает себя полностью — даже если весь остальной год она просто «молчала и светила зеленым».

Если стоимость разработки цифрового двойника и монтажа дополнительных датчиков ниже цифры аварийного отказа на горизонте года, проект целесообразен. На практике SSP SOFT, для действительно критических узлов это соотношение оказывается в пользу внедрения с большим запасом.

Довод #2 в пользу цифровых двойников: оптимизация регламентного интервала 

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

Классический регламент обслуживания устанавливается консервативно — производитель закладывает интервал с запасом, ориентируясь на худшую статистику и условия эксплуатации. Хорошим примером служат авиационные двигатели — там детали меняют по моточасам, даже если после разборки узлов сами детали выглядят еще вполне годными. Более того, б/у детали запрещено ставить обратно или продавать для ремонта других авиадвигателей.

В промышленности, на конкретном предприятии, при конкретной нагрузке и режиме работы, реальный износ узла может накапливаться медленнее или быстрее, чем по статистике у вендора. Задача мониторинга это увидеть. Например, если датчики вибрации и температуры подшипника через 3 000 часов работы показывают, что узел находится в том же состоянии, что и через 2 500 часов по прошлому циклу — есть обоснование продления интервала, подкрепленного данными наблюдения.

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

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

Довод #3. Российская специфика: дотянуть до предела ресурса, но «не пропустить момент»

В сегодняшних условиях для российских промышленных предприятий эта логика приобретает особое значение. Проблема доступности запасных частей, фирменных смазочных материалов и эксплуатационных жидкостей стала реальным операционным ограничением. Все то, что раньше заказывалось за 2–3 недели, сегодня кратно дольше едет окружными путями, поставляется через параллельный импорт или не поставляется вовсе (последнее — отдельная болевая точка снабженцев).

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

Это именно то, для чего предиктивный мониторинг подходит лучше всего. ИИ‑система непрерывно анализирует данные от мониторинга, и пока деградация развивается в штатном темпе — узел продолжает работать. Как только тренд меняет характер и горизонт до критического состояния сокращается до заданного порога — выдается предупреждение. У предприятия есть время предупредить персонал о предстоящих ремонтных работах, организовать поставку детали и сопутствующих расходников.

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

2. Оптимизация технологических режимов с локальной LLM

Здесь важно объяснить, почему в большинстве случаев большие языковые модели (LLM) применяются на производстве локально, а не используются облачные ИИ‑сервисы. Промышленные предприятия крайне осторожно относятся к передаче технологических данных во внешние облака (включая арендованный сервер в ЦОД у внешнего провайдера). К примеру, в металлургии это параметры плавки, химический состав шихты, режимы прокатки и тому подобное — технологическое ноу‑хау не принято выносить за периметр корпоративной сети.

В целом, говоря о возможном использовании облачных ИИ‑сервисов, отметим, что для производственных задач не нужна облачная модель общего назначения, так как контекст задачи всегда один и специализированная модель, обученная под конкретную задачу дает более качественные результаты. При этом, вычислительных мощностей локальная LLM требует на порядки меньше. Как правило, такая модель описывается математикой и дает строго детерминированный результат без «галлюцинаций». Модели общего назначения имеют склонность к «дрейфу» результатов выдачи и галлюцинациям в силу своей универсальности.

Локальная LLM разворачивается на собственных серверах предприятия или на настольном ИИ‑суперкомпьютере в самом цеху, она работает без подключения к интернету и не передает данные за пределы локальной сети. Современные модели размером 7–14 миллиардов параметров (Mistral, LLaMA, отечественные варианты на их основе) достаточно производительны для большинства промышленных задач и при этом запускаются на оборудовании стоимостью порядка 500 тыс. рублей. Это, конечно, не облачные модели уровня Sonnet по мощности, но для узких технологических задач — более чем достаточно.

Задача LLM в оптимизации технологического процесса

LLM в контексте оптимизации техпроцесса — это, как правило, не система управления самим процессом и не замена АСУ ТП. Она не открывает задвижки на печах и не меняет режим проката стали в реальном времени. Ее роль состоит в обработке неструктурированных знаний о техпроцессах. Сюда можно отнести технологические инструкции, журналы оператора, историю брака, опыт цеховых мастеров — то есть знания, которые помогают принимать более обоснованные решения для управления техпроцессами на уровне мастера цеха или оператора оборудования.

Классическая «картина маслом» на производстве выглядит так — технологические знания хранятся в головах опытных специалистов, в бумажных журналах, в разрозненных Excel‑файлах и в бумажных технологических картах, написанных 10–15-20 лет назад. Молодой оператор, столкнувшись с нештатной ситуацией, либо идет к старшему мастеру, либо ввиду критической нехватки времени, действует по собственному разумению и зачастую ошибочно. LLM позволяет оцифровать и сделать доступным весь накопленный опыт предприятия — в виде системы, к которой можно задать вопрос на обычном языке и за секунды получить конкретный совет.

Пример: Электросталеплавильный цех, подбор режима плавки

В электродуговой печи качество плавки зависит от десятков параметров, включая состав металлолома, химию шихты, график подачи электроэнергии, режима работы электродов, продувки кислородом и так далее. Опытный сталевар держит эту зависимость в голове. Новый оператор учится 2–3 года, прежде чем начинает уверенно работать с нестандартными завалками печи.

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

Модель обучается на исторических данных плавок, желательно на выборке не менее 3–5 лет. Все параметры учитываются в режиме «параметры процесса на входе» — результат на выходе (химсостав, температура, расход электроэнергии). Параллельно в LLM загружаются все найденные технологические инструкции и журналы отклонений. Оператор перед плавкой вводит состав завалки — и получает рекомендацию по режиму, где уже будет ожидаемое время плавки, рекомендуемый график мощности, прогноз по расходу электроэнергии и флюсов.

Эффект от внедрения во многих кейсах виден сразу: снижение удельного расхода электроэнергии на 3–7% за счет оптимизации графика мощности — ИИ‑система видит наборы параметров, которые человек не удерживает в голове одновременно. В цеху с годовым потреблением 50–80 млн кВт·ч при цене 5–6 ₽/кВт·ч это выливается в 7–25 млн рублей экономии в год. Плюс сокращение времени плавки на 5–10 минут за счет более точного попадания в оптимальный режим печи.

Оценка стоимости проекта: сервер или десктоп с GPU — 500–800 тыс. руб., развертывание модели и интеграция с историческими данными — 1,5–2 млн руб., обучение персонала — 300 тыс. руб. Итого 2,5–3 млн рублей. Окупаемость при типовом проекте — порядка 4 месяцев.
Важно: эта оценка затрат дана без учета обще‑инфраструктурных расходов. Для запуска модели потребуется хранилище данных, репозитории, Kafka и иные ИТ‑ресурсы.

3. Автоматический контроль качества с локальной LLM

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

Рассмотрим типичную картину на прокатном стане: система технического зрения фиксирует поверхностный дефект на полосе и останавливает линию. Оператор смотрит на монитор, видит классификацию дефекта как «риска» или «закат» — и дальше начинается ручная работа по поиску причины и метода устранения. Это листать инструкции, позвонить опытному технологу (порой уже ушедшему на пенсию), принимать решение о судьбе рулона. Именно на этой временной задержке между обнаружением дефекта и принятием решения теряются деньги.

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

Как работает архитектура решения на примере

Практическая архитектура такой системы в металлопрокате выглядит следующим образом. Существующая оптическая/тепловизионная инспекционная система фиксирует отклонение геометрии рулона и передает его параметры LLM‑ассистенту. Одновременно туда поступает контекст по параметрам плавки, из которой вышел металл, режимы прокатки на данном рулоне, история аналогичных дефектов, действующие нормативные документы (ГОСТы, ТУ, технические условия заказчика, внутренние стандарты).

LLM анализирует информацию и выдает оператору прокатного стана и инспектору ОТК структурированное заключение при выявлении брака. Здесь предполагаемая причина дефекта, классификация по нормативным документам, рекомендация по дальнейшему использованию продукции (можно отгрузить заказчику, перевести в другой сорт, списать в брак и отправить на переплавку), ссылка на конкретный пункт ТУ или ГОСТа, которым обоснован акт выбраковки. 

Подпись под актом о браке или переводе в другой сорт по‑прежнему ставит сотрудник ОТК. Но вместо получаса и более на поиск по документации и звонки, это занимает считанные минуты.

Теперь перейдем к конкретному примеру. Крупный листопрокатный цех выпускает металлопрокат для нескольких групп потребителей с разными требованиями. Это металлоконструкции для гражданской стройки, трубная заготовка, автолист. У каждого заказчика — свои технические условия (ТУ), часть из которых допускает определенные типы дефектов, другие — нет (например для автолиста качество поверхности критично). Работники ОТК обязаны знать все эти нюансы и принимать решения очень быстро, не задерживая работу прокатного стана.

На практике, даже опытный инспектор ОТК держит в голове требования 5–7 ключевых заказчиков, остальные ищет в документах. При нестандартном дефекте или нестандартном заказчике — неизбежная задержка. По статистике таких предприятий до 15% решений по спорным рулонам принимаются консервативно «в сторону брака» именно из‑за неуверенности в нормативной базе, так как лучше списать, чем отправить на склад продукцию, не соответствующую ТУ заказчика

При появлении спорного рулона оператор описывает дефект (в идеале система технического зрения должна передает параметры автоматически) — и получает сортировку по всем текущим заказам в плане поставок, то есть для каких заказчиков этот металлопрокат еще соответствует требованиям, для каких — нет.

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

Расчет экономии. В кейсе цех производит 400 000 тонн листового проката в год. По статистике 3.5% продукции проходит через процедуру спорной классификации. Из них при ручной работе 17.5% уходит в брак «перестраховочно» — то есть реально соответствует требованиям какого‑то заказчика, но работник ОТК не уверен в своем вердикте или просто не успевает проверить рулон, а его должностная инструкция запрещает задерживать стан надолго.

Это 400 000 × 0,035 × 0,175 = примерно 2 450 тонн в год, переведенных в брак без достаточного основания. При разнице в цене между прокатом и ломом 15 000–25 000 ₽/тонна в зависимости от марки металла — это 37–60 млн рублей упущенной выручки ежегодно.

Даже если LLM позволит вернуть в товарный поток треть этого объема — получается экономия 12–20 млн рублей в год. Стоимость проекта включает сервер и развертывание модели — порядка 4 млн руб., загрузка и структурирование нормативной базы — 1–1,5 млн руб., интеграция с системой технического зрения и учетной системой — 1–1,5 млн руб. Итого 6–7 млн рублей, окупаемость — 4–6 месяцев.

Новые физические принципы контроля плавки: LLM и СВЧ‑радиометр открывают возможности за пределами видеокамер и тепловизоров

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

Метод радиометрического измерения температуры основан на том, что любое нагретое тело испускает электромагнитное излучение не только в ИК‑диапазоне и видимом свете, но и в других диапазонах волн, включая СВЧ.

Технологическая задача состоит в том, чтобы иметь непрерывную информацию о температуре в печи. Оптика и ИК не работают внутри печи. Чтобы понять ценность радиометрического подхода, достаточно представить условия внутри электродуговой или мартеновской печи. Над зеркалом расплава — плотное облако дыма, металлической пыли и продуктов горения. Инфракрасный тепловизор в этих условиях практически слеп, так как испускаемое инфракрасное излучение фиксируется от плотного облака поверх зеркала расплавленного металла. Оптическая камера — тем более бесполезна.

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

Радиометр для металлургии решает эту проблему принципиально иначе. Радиометр работает в диапазоне 75–110 ГГц — миллиметровые радиоволны в этом диапазоне проникают сквозь дым и пыль там, где оптика и ИК бессильны. Прибор обеспечивает бесконтактное пассивное непрерывное измерение температуры расплава до 2200°C. При этом он интегрируется в промышленную инфраструктуру через сетевые протоколы Ethernet или через беспроводную сеть (Wi‑Fi, сотовые модемы и др.) и может передавать данные напрямую в АСУ ТП в формате, пригодном для дальнейшей обработки c помощью LLM.

При всех преимуществах СВЧ‑радиометрии само по себе физическое измерение температуры — это лишь половина задачи. Реальный процесс плавки не является идеальным объектом наблюдения, так как поверхность расплава нестабильна, на ней регулярно появляется пена, брызги. Зона наблюдения антенны может частично перекрываться. 

Коэффициент радио‑излучательной способности расплава также меняется в зависимости от состава металла и стадии плавки. Изменение толщины шлака на зеркале металла дает специфическую картину изменения сигнала. Нестабильная поверхность при интенсивном кипении расплава — другую. Частичное перекрытие зоны наблюдения — третью. В таких условиях прямой расчет температуры по радиометрическому сигналу начинает давать высокую погрешность — и оператор уже не может рассчитывать свои действия, полагаясь на прямой сигнал от радиометра.

Именно здесь ИИ‑модуль превращает измерительный прибор в интеллектуальную систему контроля состояния расплава. Алгоритм анализирует временной ряд сигнала целиком — и обучается на распознавании характерных паттернов, соответствующих разным состояниям процесса. 

Система LLM на основе таких паттернов способна выдавать оператору не просто численное значение температуры, а измерение с оценкой достоверности: «температура 1 547°C, уровень доверия высокий» или «температура 1 523°C, перекрытие зоны наблюдения облаком феррочастиц, рекомендуется проверка термопарой». Это качественно другой уровень информации по сравнению с тем, что дает прибор без ИИ‑интерпретации.

Дополнительное и практически важное применение — прогнозирование поведения температуры на коротком горизонте времени. ИИ‑модуль, наблюдающий непрерывный температурный тренд, способен оценивать, как будет развиваться процесс в ближайшие 3–10 минут. Это дает оператору или интеллектуальной АСУ ТП возможность действовать на опережение, а не реагировать на уже произошедшее отклонение.

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

Именно эта связка — новый физический принцип измерения плюс ИИ‑интерпретация — открывает в промышленном контроле качества возможности, которые еще 5–7 лет назад были доступны только в исследовательских лабораториях. И что особенно важно в контексте задачи быстрой окупаемости,такие системы внедряются точечно, на конкретном переделе, без реструктуризации всего производства — и дают измеримый результат в течение первого года работы.

Дополнительный эффект от LLM при работе с рекламациями

Отдельная и часто недооцениваемая предприятиями область — разбор рекламаций от заказчиков. Когда покупатель возвращает металл и предъявляет претензию к возврату стоимости, нужно быстро установить первопричину. Дефект м.б. производственным или возникшим при транспортировке, или даже переработке у заказчика, и главное — выяснить, соответствовал ли металл ТУ на момент отгрузки.

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

На предприятии с 50–80 рекламациями в год это высвобождает 200–600 часов работы технологов и юристов — и ускоряет разрешение споров, что само по себе влияет на отношения с заказчиками. 

Обоснованный ответ на рекламацию, а не отписка, очень ценится в деловых отношениях. Даже после брака, заказчик с большой вероятностью продолжит закупки, так как видит работу предприятия‑поставщика по контролю качества продукции.

4. Анализ производственных инцидентов на основе LLM

Переходим к последней теме применений LLM для экономии ресурсов на предприятиях. Тут важно отметить, что ИИ‑системы анализа инцидентов должны внедряться после предиктивного обслуживания, помощи в техпроцессах и анализа брака. Разбор инцидентов часто воспринимается как похожая задача — все три предыдущие работают с данными и направлены на снижение потерь. Но это принципиально разные инструменты, отвечающие на разные вопросы, и смешивать их — значит неправильно ставить задачу и не получить результат от проекта внедрения.

• Предиктивное обслуживание отвечает на вопрос «когда сломается?». 

• Помощь в оптимизации техпроцессов помогает ускорить и/или удешевить выпуск продукции за единицу времени (смену, месяц, квартал — в терминах «год к году»).

• Анализ брака отвечает на вопрос «почему продукт не соответствует требованиям?». Временно́й акцент направлен в настоящее, то есть что делать с этой продукцией прямо сейчас.

Разбор техногенных инцидентов отвечает на вопрос «Почему все‑таки произошла поломка оборудования и как не допустить повторения?» Это ретроспективная задача, направленная в прошлое. И именно здесь LLM раскрывает потенциал — так как разбор инцидента требует работы с разнородными, плохо структурированными данными из множества источников одновременно. 

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

На большинстве промышленных предприятий разбор производственных инцидентов устроен примерно одинаково. Собирается совещание: технолог, механик, электрик по памяти восстанавливают картину событий. Обычный итог такого совещания — всем дается день‑другой на подготовку отчета по своему направлению. Через пару‑тройку дней формулируется причина — и нередко та, которая на поверхности и которую проще всего обосновать. Выпускается приказ с мероприятиями.

Корень проблемы в том, что информация об инциденте была распределена по десяткам источников, которые человеку физически сложно проанализировать одновременно: параметры АСУ ТП за последние N‑часов перед остановом, записи в журнале оператора, данные о последнем ТО оборудования, история аналогичных остановов на данном предприятии, известные похожие инциденты на других заводах, наряды на ремонт, показания с видеокамер. LLM способна работать со всем этим одновременно.

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

Пример: доменный цех, расследование нарушений хода печи

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

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

LLM выстраивает полную временну́ю шкалу событий перед инцидентом — по всем источникам доступных данных. Снижение давления дутья за 6 часов до инцидента, изменение влажности кокса по лабораторным данным за 2 суток, предыдущий ремонт холодильников за 4 дня, незафиксированное в журнале изменение режима загрузки, которое видно только в данных АСУ ТП. 

Кроме того, система сопоставляет текущий инцидент с базой исторических инцидентов — не только данного предприятия, но и (если предприятие участвует в отраслевом обмене знаниями внутри холдинга) других доменных производств. Это позволяет находить нетривиальные причинно‑следственные связи, которые на одной печи могут встречаться раз во много лет или не произойти никогда вовсе.

Расчет экономии будет таков: доменная печь объемом 2 000–3 000 м³ производит 3 000–4 500 тонн чугуна в сутки. Один серьезный инцидент с нарушением хода — это снижение производительности на 20–40% в течение 3–7 суток, плюс перерасход кокса. Потери одного инцидента — несколько млн. рублей в зависимости от тяжести. Если система позволяет предотвратить или существенно сократить последствия инцидента в календарный год за счет более быстрого и точного выявления причины — это те же самые 15–20 млн рублей экономии.

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

Подведем итоги: системный эффект от LLM и накопление машинных данных

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

Каждый разобранный инцидент, каждое решение по спорному качеству образца продукции, каждая установленная причина отклонения — все это попадает обратно в базу знаний системы. Через год‑два предприятие накапливает технологическую институциональную память. Это не бумажные акты расследований, которые уходят в архив и их не читают от инцидента к инциденту, а цифровая база знаний, к которой LLM‑система обращается при каждом новом запросе.

Это особенно ценно в контексте российских реалий — кадровой проблемы набора квалифицированного персонала, необходимости быстро вводить в курс дела новых технологов. Знания, которые раньше уходили на пенсию вместе с опытным мастером, теперь остаются в системе.

Интересно внедрение перечисленных ИИ‑систем для технологических процессов на вашем предприятии? Обращайтесь к нам в SSP SOFT ?.