Обслуживание мостового крана: RAG-база знаний и диагностика

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

Большие языковые модели (LLM) стремительно развиваются в последние годы. В сочетании с данными Цифрового Двойника мостового крана они обеспечивают более полный контекст для диагностики неисправностей — от универсальных чат-ботов до вертикальных отраслевых решений, технический подход уже отработан. Обслуживание мостовых кранов — идеальная сфера для внедрения LLM: область знаний относительно замкнута (пара инструкций и руководств по ремонту), закономерности отказов поддаются систематизации (типовых кодов аварийного сигнала не более 100), а ответственность за решения остаётся за человеком — ИИ лишь формирует рекомендации.

В этой статье — полное инженерное решение от развертывания до практического внедрения: локальный запуск Ollama с подключением RAG-базы знаний, и диагностика неисправностей мостового крана занимает секунды. Аппаратные затраты — 300–800 тыс. ₽, один промышленный компьютер обслуживает 20–30 терминалов ремонтного персонала, а созданная база знаний не устаревает со временем.

Архитектура системы ИИ-ассистента для кранового оборудования

Система ИИ-ассистента построена по трёхуровневой архитектуре, где каждый уровень выполняет свою задачу, а взаимодействие между уровнями осуществляется через стандартные API:

Технические детали реализации

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

2.1 Развертывание LLM: Ollama + Qwen2.5

Ollama — наиболее зрелый фреймворк для запуска локальных больших языковых моделей. Поддерживает Linux и Windows: одна команда устанавливает модель, и API сразу готов к вызовам. Рекомендуем Qwen2.5 14B (14 млрд параметров) от Alibaba — сильное понимание китайского языка, умеренные требования к железу. Квантованная 4-bit версия требует всего 8 ГБ видеопамяти для стабильной работы.

Команда развертывания:

# монтажOllama（ПоддержкаGPUАвтоматическое обнаружение） curl -fsSL https://ollama.com/install.sh | sh # ИзвлечениеQwen2.5 14B（Около8.5GB） ollama pull qwen2.5:14b # Запуск сервиса（По умолчанию127.0.0.1:11434） ollama serve

Проверка работоспособности сервиса:

curl http://localhost:11434/api/generate -d '{"model": "qwen2.5:14b","prompt": "Сообщение частотного преобразователя кранаOCВозможные причины перегрузки по току？Перечислить пять пунктов","stream": false}'

2.2 Построение базы знаний RAG

Собственных знаний модели недостаточно — Qwen2.5 понимает общую концепцию мостового крана, но не знает, как сбросить PLC конкретно вашей модели или какие запчасти менялись в прошлом году. RAG (Retrieval-Augmented Generation) решает эту задачу: документация, журналы ремонта и чертежи загружаются в векторную базу данных. При каждом запросе система сначала находит релевантные документы, добавляет их в промпт, и только затем модель формирует ответ.

Процесс построения базы знаний:

Для выбора векторной базы данных рекомендуем ChromaDB — реализована на чистом Python, не требует отдельного развёртывания, поддерживает режим в памяти, отлично подходит для промышленных компьютеров. Для эмбеддингов рекомендуем BAAI BGE-small-zh-v1.5 (384 измерения, всего 150 МБ, ~50 мс на одно вычисление на CPU), обеспечивает качественный семантический поиск по китайскому тексту при низких требованиях к аппаратному обеспечению.

2.3 Процесс генерации с дополненной выборкой (RAG)

Полный циклвопрос-ответ выглядит следующим образом:

from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings import requests embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5") db = Chroma(persist_directory="./crane_kb", embedding_function=embeddings) question = "Сообщение частотного преобразователя кранаOUКак устранить неисправность по перенапряжению？" docs = db.similarity_search(question, k=4) context = "\\\\n\\\\n".join([d.page_content for d in docs]) prompt = f"""Ответить на вопрос пользователя на основе следующего руководства по ремонту мостового крана。 Если в руководстве отсутствует，Указать"В руководстве не найдено соответствующее содержание"。 Содержание руководства： {context} Ответить на вопрос пользователя на основе следующего руководства по ремонту мостового крана：{question}""" resp = requests.post( "http://localhost:11434/api/generate", json={"model": "qwen2.5:14b", "prompt": prompt, "stream": False}) print(resp.json()["response"])

Ключевой элемент этого процесса — сборка промпта. Эффективность RAG зависит не столько от большой языковой модели (Qwen2.5 достаточно), сколько от того, насколько релевантны извлечённые документы. Рекомендуется при тестировании вручную оценивать каждый типовой запрос (по точности попадания и точности ответа); если результат ниже 80% — следует скорректировать стратегию разбиения текста или модель эмбеддингов.

Рекомендуемый оценочный скрипт:

def evaluate_rag(test_qs, db, llm_url): results = [] for q, expected in test_qs: docs = db.similarity_search(q, k=4) hit = any(expected in d.page_content for d in docs) results.append({"q": q, "hit": hit}) rate = sum(1 for r in results if r["hit"]) / len(results) print(f"Retrieval hit rate: {rate:.1%}") return results

Типовые сценарии применения

3.1 Диагностика неисправностей (наиболее частый сценарий)

Ремонтник вводит симптомы неисправности на телефоне или планшете, ИИ выдаёт возможные причины и порядок действий. На примере ошибки перегрузки по току OC преобразователя частоты:

3.2 Инструкция по ремонту (с пошаговыми действиями)

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

Пользователь спрашивает：Как заменить фрикционные накладки тормоза мостового крана？ AIОтвет：Ниже приведены шаги по замене—— 1. Отключить питание и вывесить табличку，Убедиться, что тормоз находится в расторможенном состоянии 2. Демонтировать крепежные болты пылезащитного кожуха（M8 x 4） 3. Сжать тормозную пружину специальным инструментом 4. Извлечь установочный штифт фрикционной накладки 5. Извлечь старую фрикционную накладку（Обратить внимание на правильное положение (лицевая/обратная сторона)） 6. Установить новую фрикционную накладку（Убедиться в одинаковой толщине） 7. Освободить пружину，Восстановить пылезащитный кожух 8. Отрегулировать тормозной зазор（нормативное значение0.5~1.0mm） 9. Подать питание и провести испытание：Подъем в толчковом режиме3раз(а)，Убедиться в отсутствии постороннего шума

3.3 Анализ истории неисправностей и тенденций

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

Выбор модели: ключевые технические параметры

5. Ключевые аспекты внедрения

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

2. Шаблоны промптов требуют итеративной настройки. На один и тот же вопрос ответ без системного промпта и ответ с тщательно проработанным промптом отличаются на два уровня качества. Рекомендуемый формат: системный промпт для ИИ-ассистента мостового крана должен включать определение роли («Вы — инженер по ремонту мостовых кранов с 15-летним стажем») + регламент ответа («Сначала укажите наиболее вероятную причину, затем перечислите шаги проверки с указанием времени на каждый») + дисклеймер («Вышеуказанное — рекомендация ИИ, финальные ремонтные работы должны выполняться аттестованным персоналом»).

3. Локальное развёртывание не так дорого, как кажется. Многие полагают, что для больших языковых моделей обязательны видеокарты A100, однако квантованная модель Qwen2.5 7B стабильно работает на RTX 3060, а один промышленный компьютер легко обеспечивает одновременную работу 20–30 терминалов. Если требования к конфиденциальности на предприятии не слишком строгие, можно рассмотреть облачный вариант — Qwen через API Alibaba Cloud или DeepSeek API с оплатой за токены. Но для промышленных сценариев я всё же рекомендую локальное развёртывание: данные не покидают сеть, а задержка стабильно держится в пределах 1–3 секунд.

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

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

Заключение

ИИ в обслуживании мостовых кранов — не дань моде. Когда ремонтник фотографирует сигнализацию преобразователя частоты прямо у места неисправности и через 30 секунд получает от ИИ причину отказа и порядок действий, ценность такой системы не требует пояснений. Мы провели пилотное внедрение в двух цехах в течение трёх месяцев: среднее время локализации неисправности сократилось с 40 до 15 минут, а по типовым отказам преобразователя частоты отклик практически мгновенный.

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

Часто задаваемые вопросы