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

Почему промышленное ИИ-решение нельзя начинать с выбора модели

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

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

От результатов аудита к концепции решения

Архитектурная работа начинается не с перечня технологий, а с последовательного ответа на пять вопросов:

1. Какое производственное событие или пользовательский запрос запускает сценарий?

2. Какой контекст необходим для принятия решения: телеметрия, партия, заказ, история ремонтов, инструкции, изображения или лабораторные данные?

3. Какие аналитические операции нужно выполнить: найти знания, выявить аномалию, спрогнозировать, классифицировать, сопоставить или сформировать объяснение?

4. Какие ограничения и проверки обязательны до выдачи рекомендации или выполнения действия?

5. Кто принимает окончательное решение, где фиксируется действие и как результат возвращается в контур обучения и мониторинга?

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

Особенности промышленного контекста

• Сочетание IT- и OT-контуров. Производственные данные могут поступать из MES, SCADA, исторических архивов, АСУ ТП и датчиков, а бизнес-контекст — из ERP, EAM/ТОиР, QMS, LIMS и документооборота.

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

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

• Редкие, но критические случаи. Исторических примеров аварий и нестандартных режимов мало, поэтому нельзя строить контроль только на статистической модели.

• Необходимость объяснимости и прослеживаемости. Пользователь должен понимать источник рекомендации, исходные данные, примененные правила и степень уверенности.

• Ограниченная автономность. На ранних этапах система чаще должна работать в offline, shadow или рекомендательном режиме, не воздействуя непосредственно на оборудование.

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

Что означает гибридное ИИ-решение

Гибридное решение — это композиция нескольких типов компонентов, связанных единым пользовательским и процессным сценарием. Компоненты не являются взаимоисключающими: ассистент может использовать RAG, RAG — реранкер, workflow — специализированную ML-модель, а агентная функция — обращаться к разрешенным инструментам внутри заданных ограничений.

Функциональная модель промышленного ИИ-сценария

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

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

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

Структурированные и сигнальные данные обрабатываются специализированными алгоритмами: выявляются аномалии, строится прогноз, классифицируется событие или анализируется изображение. Параллельно RAG-контур извлекает релевантные инструкции, стандарты и исторические случаи. Реранкер полезен, когда первичный поиск возвращает много формально похожих, но контекстно слабых фрагментов.

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

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

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

Подтвержденное действие передается в систему исполнения: создается задание в EAM, запись в QMS, комментарий к производственному заказу или задача на дополнительную проверку. Факт выполнения и итоговый результат возвращаются в контур мониторинга, создавая данные для оценки качества, обновления правил и последующего обучения.

Референсная архитектура гибридного решения

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

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

Workflow управляет предсказуемой последовательностью шагов. Ограниченная агентная функция допустима там, где следующий шаг зависит от контекста, но пространство действий заранее определено. Здесь же реализуются маршрутизация исключений, human-in-the-loop, управление контекстом, журналирование и контроль состояния сценария.

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

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

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

Когда нужны RAG и реранкер

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

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

1) фильтрацию по метаданным: предприятие, цех, агрегат, операция, версия документа, тип продукции;

2) сочетание полнотекстового и векторного поиска;

3) первичное извлечение более широкого набора кандидатов;

4) реранжирование кандидатов более точной моделью;

5) формирование ограниченного контекста и сохранение ссылок на источники;

6) проверку того, что итоговый ответ подтверждается найденными материалами.

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

Workflow или агентный сценарий

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

Как определить минимальный состав пилота

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

• Выбрать один тип оборудования, участок, продукт или ограниченный класс событий.

• Начать с исторических данных и offline-оценки, если цена ошибки высока.

• Перейти к shadow mode: система формирует результат, но не влияет на действия пользователя.

• После проверки качества использовать рекомендательный режим с подтверждением человека.

• Интегрировать только те системы, без которых невозможно проверить сквозной сценарий.

• Зафиксировать эталонные случаи, критерии правильности и причины отклонения рекомендаций.

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

Заключение

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

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