Цена наивной автоматизации в промышленных масштабах
Внедрять облачный ChatGPT для ремонта тяжелой техники — это надежный способ гарантированно угробить оборудование за свои же деньги, причем в рекордно короткие сроки. Руководители сервисных направлений свято верят, что могут скормить пару PDF-мануалов в опенсорсную обертку, выдать инженерам планшеты и получить чудо. На бумаге это всегда выглядит как прорывной ИИ для сервисных инженеров. На деле, когда вам нужен ИИ-ассистент техподдержки и сервисных инженеров on-prem: подсказка по оборудованию и регламентам прямо у станка обязана работать там, где нет ни вайфая, ни малейшего права на галлюцинацию. Иначе полевой специалист просто выругается, закроет планшет и пойдет звонить Петровичу — единственному живому носителю знаний на всем заводе.
Я помню один конкретный пост-мортем, который наглядно показал всю пропасть между хайпом и инженерией. Крупный подрядчик по обслуживанию промышленных компрессоров решил радикально снизить зависимость от двух-трех ветеранов, которые держали в голове всю историю ремонтов по филиалам. Они закупили SaaS-решение на базе популярной LLM, загнали туда тысячу страниц регламентов и отправили молодняк «в поле». Ожидалось, что время восстановления работоспособности (MTTR) рухнет вниз. Вместо этого они получили коллапс на первой же серьезной аварии в насосной станции.
Станция находилась на минус втором уровне бетонного бункера. Мертвая зона. Инженер, стоя перед разобранным узлом, пытается загрузить фото сломанного клапана в облачный ассистент техподдержки по оборудованию. Система ловит таймаут. Он поднимается на поверхность, ловит слабый сигнал, пропихивает запрос. Бот радостно выдает стандартную процедуру из мануала 2018 года. Но бот не знал, что конкретно этот серийный номер прошел кастомную модернизацию в 2021 году, потому что база CRM и история ремонтов не были интегрированы в векторный поиск из-за паранойи безопасников по поводу облаков. Инженер спускается вниз, выполняет инструкцию бота, срывает пломбу и необратимо повреждает узел. Итог: ожидание новой детали, простой линии на 48 часов и повторный выезд целой бригады.
Почему ванильный RAG ломается о чертежи и права доступа
Общий чат-бот абсолютно бесполезен без вашей специфической базы и жесткого разграничения прав доступа. Поддержка B2B-оборудования — это не клиентский саппорт, где можно бесконечно извиняться за задержку доставки. Это строгий on-prem RAG на ваших данных. Вы не можете просто нарезать руководства по эксплуатации стандартным чанкером и бросить их в базу. Инженер подрядчика «А» не должен иметь технической возможности получить доступ к регламентам и сметам объекта «Б».
Более того, ванильный поисковый алгоритм захлебывается на таблицах допусков и разрывает связность электрических схем. Вырванный из контекста кусок текста на 45-й странице может быть фатально неполным без предупреждения, напечатанного мелким шрифтом на 46-й. ИИ для сервисных инженеров должен уметь извлекать факты из истории ремонтов конкретной единицы оборудования, сопоставляя серийный номер с логами прошлых смен, а не просто пересказывать обобщенную документацию вендора. Это классический трейд-офф: вы либо платите за глубокий парсинг вашей неструктурированной макулатуры, либо платите простоями производства.
Мультимодальность, грязь на объекте и железобетонный край сети
Давайте посмотрим правде в глаза: сервисный инженер не печатает на клавиатуре. У него руки в масле, на них толстые перчатки, а вокруг ревет турбина. Ему нужна мультимодальность и голос. Он наводит камеру промышленного смартфона на разорванный патрубок и кричит в микрофон: «Какая здесь резьба и как это снять?». Система должна распознать деталь по фото, перевести скомканную матерную речь в четкий текстовый запрос, найти этот узел в локальной базе и выдать голосовую подсказку по шагам. И все это должно произойти без обращения к внешним серверам.
Год назад, когда мы в MoranaLabs катили локальную модель для обслуживания тяжелых конвейерных лент на горно-обогатительном комбинате, стало кристально ясно: система, зависящая от стабильного 4G, умирает в первый же день. Вычисления нужно переносить на край сети. Inference должен происходить на защищенном ноутбуке самого инженера или на локальном сервере цеха, замкнутом в изолированный контур. Мы разворачивали квантованные модели машинного зрения, которые способны работать на мобильных GPU, и локальные speech-to-text движки, игнорирующие фоновый шум завода.
Именно в таком оффлайн-режиме мультимодальность начинает приносить реальные деньги. Главная боль директоров по сервису — это bus factor. Зависимость от носителей знаний, которые могут уволиться, заболеть или просто не взять трубку. Когда джуниор с помощью локального ассистента может идентифицировать поломку по фото, мгновенно получить срез прошлых проблем конкретно этой машины и пошаговый план действий прямо в ухо, он начинает выдавать результат на уровне миддла. Резко сокращается количество повторных выездов, когда бригада прибыла на объект без нужного инструмента или запчасти просто потому, что неверно диагностировала проблему по телефону. Снижение времени ремонта перестает быть красивой метрикой из презентации и становится фактом, зафиксированным в ERP-системе предприятия.
Математика внедрения без розовых очков
Самое большое заблуждение рынка — это вера в то, что локальный индустриальный ИИ стоит космических денег. Построить рабочий инструмент можно без закупки кластеров по миллиону долларов. Morana собирает сервисного ИИ-ассистента on-prem от 700 000 рублей. В эту сумму не входят философские беседы о сингулярности, но входит разворачивание строгой локальной архитектуры, которая сможет прожевать ваши регламенты и запустить связку RAG-плюс-зрение в вашем изолированном периметре. Платить нужно за инженерию и адаптацию моделей под ваше грязное, шумное и лишенное интернета производство. Все остальное — это игрушки для конференций, которые ломаются при первом столкновении с реальностью у станка.