Граф знаний для мостового крана: семантика и модель
Техническое решение: граф знаний для диагностики неисправностей мостовых кранов
Граф знаний преобразует разрозненные данные об эксплуатации и ремонте мостовых кранов — записи о неисправностях, ремонтные наряды, данные о запчастях и параметры оборудования — в структурированную семантическую сеть. Технологическая цепочка включает четыре уровня: уровень данных (ремонтные наряды / записи о неисправностях / сигналы датчиков / замена запчастей / отраслевые стандарты / документация оборудования), уровень извлечения знаний (BiLSTM+CRF для идентификации сущностей и извлечения связей, F1=91.2%), уровень хранения графа (Neo4j Enterprise 5.x, модель свойств графа, ≥500 тыс. узлов), прикладной уровень (логический вывод при диагностике неисправностей / рекомендации по ремонту / поиск аналогичных отказов / интеллектуальные ответы на вопросы). Система развёрнута во внутренней базе знаний компании Келуде, охватывает 8 типов мостовых кранов, 243 режима отказов и 1 580 записей о неисправностях.
Диагностика неисправностей мостовых кранов долгое время зависела от личного опыта инженеров по ремонту. За 15–20 лет жизненного цикла крана — от монтажа до вывода из эксплуатации — накапливаются сотни ремонтных нарядов и записей о неисправностях. Однако эти структурированные и полуструктурированные данные, распределённые по разным системам (ERP, CMMS, Excel), не превращаются в повторно используемый актив знаний. Технология графа знаний (Knowledge Graph) с помощью идентификации сущностей (NER), извлечения связей (RE) и графового хранения (Neo4j) преобразует эту разрозненную информацию в семантическую сеть взаимосвязей «оборудование — неисправность — причина — мера — запчасть». В данной статье на примере создания внутренней базы знаний о неисправностях группы компаний Келуде подробно описывается инженерная реализация — от сбора данных до графовых запросов и логического вывода. Техническое решение основано на официальной документации Neo4j (Neo4j Graph Data Science Manual v5.x, 2024), инструментарии обработки естественного языка HanLP (версия 2.1, 2023) и практическом опыте развёртывания внутреннего проекта базы знаний о неисправностях Келуде (номер проекта KL-KG-2024-001).
Граф знаний для диагностики крана: источники данных и система сущностей
Данные для графа знаний о неисправностях мостового крана поступают из четырёх источников: ① паспорт оборудования (модель / грузоподъёмность / пролёт / высота подъёма / режим работы / заводской номер / дата ввода в эксплуатацию); ② ремонтные наряды (время неисправности / номер оборудования / описание отказа / код неисправности / процесс поиска причины / ремонтные меры / заменённые запчасти / ремонтный персонал / продолжительность простоя); ③ данные датчиков (среднеквадратичное значение вибрации / температура / ток / история перегрузок); ④ отраслевые стандарты (положения о классификации неисправностей в стандартах ISO 4301 / FEM 1.001, TSG 51, FEM 1.001 и др.). После извлечения сущностей и связей определены 6 типов сущностей и 9 типов связей:
| Тип сущности | Имя метки | Пример | Порядок величины |
|---|---|---|---|
| мостовой кранОборудование | Crane | QD32t-023/ LD10t-156 | 500+ |
| Признак неисправности | Fault | Подъёмпроскальзывание груза/износ рельса крана/ТормозПосторонний шум | 243вид |
| Причина неисправности | Cause | Тормозная накладкаИзнос/Поверхность катания колесаПиттинг/МуфтаПоверхность зубаИзнос | 480+ |
| РемонтМера | Action | ЗаменаТормозная накладка/регулировкаТормозной зазор/ЗаменаМуфта | 620+ |
| ЗапчастьМатериал | Part | YWZ5-315/23Тормоз/КолесоZGY-600 | 1,200+ |
| СтандартПункт | Standard | стандарт ISO 4301 / FEM 1.001《кранПроектированиеСпецификацияТолкование ключевых пунктов:Нагрузка/Конструкция/Механизм/Электрооборудование/Пять основных систем безопасности》 5.2.3 | 80+ |
| Тип отношения | Начало-конец | Описание |
|---|---|---|
| has_fault | Crane Fault | Определённыймостовой кранВозникала определённая неисправность |
| has_symptom | Fault | Возникала определённая неисправностьAСопутствующая неисправностьBВозникает одновременно |
| caused_by | Fault Cause | Неисправность вызвана определённой причиной |
| resolved_by | Fault Action | Неисправность устраняется определённой мерой |
| uses_part | Action Part | Мера требует замены определённого элементаЗапчасть |
| ref_standard | Fault Standard | Связанный с неисправностьюСтандартПункт |
| similar_to | Fault | Возникала определённая неисправностьAС неисправностьюBСходный(Косинусное сходство＞0.8) |
| located_in | Crane Location | мостовой кранРасположен вЦех/Участок |
| occurred_at | Fault Time | Время возникновения неисправности |
Извлечение сущностей и связей: реализация BiLSTM+CRF
Извлечение знаний — ключевой этап построения графа. В системе применяется модель последовательной разметки BiLSTM+CRF (двунаправленная долгая краткосрочная память + условное случайное поле) с конвейером предобработки HanLP 2.1 (токенизация, частеречная разметка, синтаксический анализ зависимостей). Модель обучена на 2 400 вручную размеченных текстах о неисправностях мостовых кранов. Схема разметки — BIOES (Begin/Inside/Outside/End/Single), 6 классов сущностей × BIOES = 30 меток.
Хранение в графовой БД Neo4j и запросы Cypher
Извлечённые триплеты (голова-связь-хвост) сохраняются в графовой базе данных Neo4j Enterprise 5.x. Используется модель помеченного графа свойств (Labeled Property Graph): каждый узел имеет одну метку (label), связи имеют тип (type) и направление (direction). Масштаб данных: узлов ≥58 000, связей ≥126 000 (по состоянию на июнь 2026 г.).
Пример типичного Cypher-запроса:
// ЗапросQD32t-023Все исторические неисправности мостового крана и соответствующие меры по ремонту MATCH (c:Crane {id: 'QD32t-023'})-[r1:has_fault]->(f:Fault) OPTIONAL MATCH (f)-[r2:resolved_by]->(a:Action) OPTIONAL MATCH (a)-[r3:uses_part]->(p:Part) RETURN f.name AS признак неисправности, a.name AS Все исторические неисправности мостового крана и соответствующие меры по ремонту, p.name AS Замена запчастей ORDER BY f.severity DESC// Логический вывод неисправностей на основе графовых путей：Возникновение у мостового крана"Проскальзывание груза при подъеме"，Рекомендуемые направления диагностики и запчасти MATCH path = (f:Fault {name: 'Проскальзывание груза при подъеме'})-[*1..2]-(n) WHERE ANY(label IN labels(n) WHERE n:Action OR n:Part OR n:Cause) RETURN path LIMIT 30// Поиск аналогичных неисправностей（На основе общих причин+мерJaccardСходство） MATCH (f1:Fault {name: 'Посторонний шум тормоза'})-[r1]->(n) MATCH (f2:Fault)-[r2]->(n) WHERE f2 <> f1 WITH f2, COUNT(DISTINCT n) AS common, COLLECT(DISTINCT n.name) AS shared_nodes ORDER BY common DESC LIMIT 5 RETURN f2.name, common, shared_nodesСемантический вывод и интеллектуальныйВопрос-ответ
Ценность графа знаний — в возможности вывода (Reasoning). Система поддерживает три режима вывода:
①Вывод на основе правил — предопределённое дерево решений для диагностики неисправностей (набор правил IF-THEN, составленный 3 опытными инженерами по ремонту мостовых кранов; покрывает 8 классов оборудования × 243 неисправности × 480+ причин; всего 1 520 правил), реализовано через обход графа на Cypher для автоматической диагностики;
②Вывод на основе ранжирования путей — для заданного узла неисправности выполняется ранжирование кандидатов на ремонт с помощью случайного блуждания (Personalized PageRank, 20 итераций, вероятность перезапуска 0,15); точность Top-3 рекомендаций — 86,4% (валидационная выборка N=500);
③СемантическийВопрос-ответ — шаблонный NL2Cypher (преобразование естественного языка в Cypher-запрос), поддержка 12 типов шаблонов вопросов (например, ”Какие неисправности были у крана XX” → MATCH(c:Crane)…).
Сравнение традиционного подхода и графа знаний
| Сравниваемый параметр | Традиционное решение(Реляционная база данных+Поиск по ключевым словам) | Решение на основе графа знаний(Neo4j+Семантический вывод) |
|---|---|---|
| Модель данных | Двумерная таблица,Связь по внешнему ключу | Граф свойств,Узел-Связь-Свойство |
| Запрос связей неисправностей | Несколько таблицJOIN(3~5таблица),Время отклика500ms~3s | Обход графа,Время отклика＜50ms |
| Многошаговый вывод(например:Причины и меры по неисправностямЗапчасть) | требуется4разSQLЗапрос связей неисправностей+Сборка на уровне приложения | ОднократныйCypherОбход графа[1..4]шаг |
| Обнаружение схожих неисправностей | На основе сопоставления ключевых слов,Низкая точность | На основе графовой структурыJaccardКосинусное сходство+PageRank |
| Повторное использование знаний | Зависимость от личного опыта,Утрата знаний из-за текучести кадров | Постоянное хранение графа знаний,Общий доступ для команды |
| Холодный старт нового оборудования | Требуется накопление достаточных записей о неисправностях | Возможен перенос вывода на основе графовой структуры аналогичного оборудования |
| Гибкость запросов | Предопределённые отчёты,Временные запросы требуют разработки | CypherAd-hoc запрос,WebСамообслуживание через интерфейс |
Частые вопросы
В: Какой объём данных нужен для практического применения графа знаний?
О: На начальном этапе рекомендуется не менее 500 записей о неисправностях (содержащих симптом + причину + меры), что соответствует примерно 6 000–8 000 сущностей и 12 000–15 000 связей. При таком объёме точность рекомендаций Top-3 по неисправностям достигает 70% и выше. При росте данных до 2 000+ записей (текущий объём проекта) точность повышается до 86%. На этапе холодного старта можно импортировать отраслевые открытые данные о неисправностях и положения стандартов в качестве стартовой базы знаний.
В: В чём ключевое различие между Neo4j и MySQL/PostgreSQL для управления знаниями о неисправностях?
О: Ключевое различие — в эффективности многошаговых запросов к связям. Например, для запроса «меры по ремонту неисправностей, аналогичных тем, что возникали на данном мостовом кране» в MySQL потребуется 5–8 операций JOIN (отклик в секундах), а при фиксированной структуре таблиц сложно добавлять новые измерения связей. В Neo4j это выполняется одним запросом Cypher с использованием переменной длины пути `[*1..4]`, отклик — менее 50 мс. Графовая модель также естественно поддерживает горизонтальное расширение — добавление новых типов сущностей или связей не требует изменения структуры таблиц.
В: Какой объём размеченных вручную данных требуется для извлечения сущностей и связей?
О: В данном проекте используется 2 400 размеченных вручную записей (28 600 сущностей, 12 400 связей), стоимость разметки — около 147 800 ₽ (3 разметчика × 10 дней × 4 926 ₽/день). При ограниченном бюджете на разметку можно применить метод дистанционного контроля (Distant Supervision), используя существующие таблицы BOM запчастей и таблицы кодов неисправностей для автоматической генерации слабо размеченных данных с последующей ручной проверкой — это позволяет сократить объём разметки до 400–600 записей, однако F1-мера снижается с 91,2% до примерно 85%.
В: Достаточно ли 12 шаблонов для семантических запросов NL2Cypher?
О: 12 шаблонов покрывают около 85% сценариев повседневных запросов к базе знаний о неисправностях (по статистике журнала эксплуатационных запросов Келуде Тяжёлая Промышленность за 3 месяца). Шаблоны разделены на 3 функциональные категории: запросы о неисправностях (неисправность оборудования, причина неисправности, меры по устранению причины), запросы о запчастях (запчасти для конкретной меры, меры, применимые к конкретной запчасти), статистические запросы (TOP N по частоте неисправностей, оборудование с наибольшим сроком ремонта). Естественно-языковые запросы, выходящие за рамки шаблонов, в настоящее время обрабатываются с понижением до подсказок по синтаксису Cypher и ручным дополнением.
