Генеративный ИИ в техническом сервисе: ответ есть, доверия ещё нет

На простых задачах экономия настоящая

Пока задача простая, общий ИИ действительно очень эффективен. Справка: какой насос установлен. Процедура: как проверить давление. Краткое объяснение: как устроен узел.

Такой ответ проверить легко. Открыл каталог, открыл руководство, сверил схему, сверил число — и можно работать. На этом уровне ощущение «он отвечает нормально» обычно справедливо.

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

Чем глубже задача, тем дороже проверка

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

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

Пределом применения генеративного ИИ становится не способность модели ответить, а способность организации проверить её ответ. Чем глубже задача, тем острее это ограничение — вплоть до случая, когда эксперта для полной проверки просто нет.

Ошибка в сервисе дороже ошибки в тексте

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

В сервисе мало, чтобы текст «звучал по-заводски». Нужно видеть, из какого документа взят вывод, для какой модификации и для какой машины. NIST (National Institute of Standards and Technology — Национальный институт стандартов и технологий США) в профиле рисков генеративного ИИ отдельно выделяет confabulation (конфабуляцию): когда модель уверенно выдаёт ложное или ошибочное содержание так, будто это проверенный факт. Отдельно там же разбирают риск, что человек слишком доверяет системе и перестаёт перепроверять. На практике это выглядит просто: механик больше не открывает каталог, потому что ответ читается уверенно и связно — гладкий текст без пробелов и сомнений, даже когда под ним нет надёжного основания.

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

Почему техника это чувствует раньше офиса

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

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

Для такой работы нужны не «более мощная модель», а четыре опоры:

1. Документация производителя, а не интернет вообще.
2. Структура этой документации: модели, модификации, узлы, детали, процедуры и связи.
3. Контекст конкретной машины, а не только название модели.
4. История эксплуатации: что уже проверяли, что меняли, что помогло.

Без этого модель отвечает «вообще про такие машины». Инженер отвечает за эту.

Где появляется «Спроси механика»

«Спроси механика» не спорит, какая модель лучше отвечает на вопрос механика. Она отвечает на другой вопрос: как сократить время, которое специалист тратит на проверку ответа, и при этом не снять с него подпись за решение.

Сначала документация производителя перерабатывается в структурированный корпус. К нему добавляются конкретная машина, история работ и результаты проверок. Только после этого формируется вывод. Сравнивать такую систему с GPT по одному вопросу почти бессмысленно: на «какой насос установлен?» ответы могут совпасть. Разница видна на цепочке работы — эта машина, симптом, что уже делали, что показал осмотр или замер, какой вывод можно подписать и что из этого вышло по факту.

Пример: дефектовочная ведомость

После разборки двигателя нужно собрать ведомость: что менять, что оставлять, что заказывать. Общий ИИ без технической базы быстро выдаёт длинный текст. Формально он даже полезен: проверьте постели, гильзы, толкатели, маховик, крепёж. Заказать по такому документу нельзя ничего. Объём проверки не сузился — он вырос.

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

Нужен не ещё один чат, а работа вокруг ответа. Не только строка в ведомости, но и вывод, который меняет смету. Если крышка коренного подшипника обрабатывается в сборе с блоком, сломанная крышка — это не «заказать крышку», а работа с блоком как с узлом. Такой вывод либо уже есть в технической базе как связь узла, применяемости и технологии ремонта, либо его нет. Один гладкий текст эту связь не создаёт.

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

Мы не утверждаем, что специализированный ИИ делает любой ответ правильным. Он должен уменьшить объём работы, которую человеку всё равно нужно сделать, прежде чем подписать решение.

Следующий вопрос уже не про модель

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

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

Не «ИИ вместо механика» и не «ответ, которому можно верить без человека». Человек по‑прежнему подписывает решение. ИИ должен уменьшить объём работы, которую этому человеку приходится делать вслепую.

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