model = Sequential([
Conv2D(32, (3,3), activation='relu', input_shape=(256, 256, 1)),
MaxPooling2D(2, 2),
Flatten(),
Dense(128, activation='relu'),
Dense(2, activation='softmax') # [0: Норма, 1: Дефект 21.1]
])
model.compile(loss='binary_crossentropy', metrics=['accuracy'])Вот так выглядит скрипт, который рано или поздно отправит грузовой состав под откос. Наивная сверточная нейросеть, бинарная кросс-энтропия и метрика accuracy. В реальном путевом хозяйстве опасных дефектов — меньше десятой доли процента от общего километража. Сеть моментально находит глобальный минимум: если на каждый миллиметр пути предсказывать «Норма», точность составит 99.9%. Прекрасный отчет для менеджмента. И гарантированная уголовная статья для главного инженера.
Компьютерное зрение в диагностике рельсов сегодня — это не модные дашборды для инвесторов. Это единственный способ не угробить людей и железо, когда дефектоскопист под конец смены смотрит в монитор немигающим взглядом и физически не способен заметить поперечный излом головки рельса по коду 21.1 или 21.2. Тысячи В-сканов с тележек «Авикон» или «УДС-Авикон» сливаются в сплошную серую кашу. Человеческий фактор ломается под монотонной нагрузкой. Западные вендоры машинного зрения ушли, использовать публичные облака для телеметрии запрещает 152-ФЗ и корпоративная безопасность. Нужен полностью свой изолированный контур на отечественном железе и софте из реестра Минцифры.
Сразу отделим мухи от котлет. У нас два принципиально разных пайплайна, которые дилетанты обожают пихать в одну архитектуру. Первый — анализ УЗ-дефектограмм. B-скан — это акустический сигнал, амплитуда и время прихода эхо-импульса. Это не фотография. Распознавание дефектов рельсов нейросетью здесь — это задача поиска аномалий в 1D/2D-сигнале. Второй пайплайн — контроль габарита подвижного состава ИИ и визуального состояния скреплений с видеопотока. Это чистая оптика. Разная физика, разные датчики, разные парадигмы обучения.
Чтобы анализ дефектограмм через машинное обучение работал в проде, академическую классику нужно выкидывать. Обычный CNN тонет в дисбалансе. Нужен Focal Loss, который штрафует сеть за уверенность на простых примерах и заставляет фокусироваться на редких изломах. Нужен жесткий oversampling миноритарных классов, а еще лучше — anomaly detection через автоэнкодеры. Мы учим сеть идеально восстанавливать паттерны здорового рельса, а любое акустическое отклонение, которое сеть восстановить не смогла, маркируем как подозрение на дефект. Только так можно вытянуть редкий класс, не утонув в вале ложных срабатываний.
С оптикой свои развлечения. Обычно негабаритный груз или выход за габарит ловят глазами на КПП. Мы ставим камеры и перекладываем это на кремний. Трекинг вагонов идет через ByteTrack, дальше алгоритм считает выход за статичную габаритную рамку в миллиметрах. Звучит просто, пока не наступает реальность: ночь, метель в объектив, засветка от маневровых прожекторов. Калибровка камер сбивается от вибрации проходящего в двух метрах многотонного товарняка. Приходится на лету пересчитывать матрицу гомографии, цепляясь за статичные реперные точки на самих путях.
И всё это обязано работать на ребре (edge). Путеизмеритель или дрезина уезжает на перегон, где нет даже голосовой связи, не говоря уже про 4G. Стримить гигабайты видео и сырой акустики на удаленный сервер физически невозможно. Инференс крутится жестко локально — на Jetson Orin или его промышленных аналогах. При этом троттлинг недопустим: пропуск кадров или задержка вычислений на скорости 60 км/ч означает, что мы пропустили десятки метров пути. Когда мы в Morana Labs катили трекинг габарита на тепловозах для одного ГОКа, быстро выяснили, что постоянная вибрация и минус сорок за бортом убивают консьюмерские железки быстрее, чем заканчивается смена. Выживает только безвентиляторный индастриал в гермобоксах с жесткой фиксацией разъемов.
Компьютерное зрение в диагностике рельсов: метрики и ответственность
Теперь о главном. О тюрьме. Кто несет ответственность, если алгоритм даст зеленый свет сломанному участку? В регламентах РЖД и промышленного транспорта (ППЖТ) ответ кристально ясен: автопринятие решений ИИ по дефектам пути недопустимо.
Никакой полностью автономной диагностики не существует. Подход human-in-the-loop — это не опция, а обязательный слой безопасности движения. Компьютерное зрение выступает исключительно как умный фильтр и суфлер. Нейросеть просеивает терабайты мусора, подсвечивает красным подозрительные пики на дефектограмме и заставляет дефектоскописта либо подтвердить дефект, либо снять отметку руками.
Из этого вытекает единственная бизнес-логика, которую готов обсуждать главный инженер. Ему абсолютно плевать на ваши F1-score, Precision или ROC-AUC. Он купит систему только если вы докажете две цифры:
- Recall по опасным дефектам. Должен стремиться к 100%. Мы обязаны поймать каждый излом 21.1/21.2. Пропуск — это сход.
- FP на километр (False Positives). Количество ложных срабатываний на километр пути.
Если алгоритм орет «излом!» на каждый болтовой стык по десять раз на километр, обходчик просто заклеит экран дисплея непрозрачным скотчем, потому что такая система мешает работать. Найти баланс между параноидальным Recall и терпимым уровнем FP/km — вот в чем заключается инженерия. Все остальное — красивые презентации. Не верьте метрикам в вакууме. Поднимайте ваши архивы дефектограмм, берите видео с перегонов. Мы развернем локальный контур, прогоним данные и замерим чистый recall по опасным дефектам и FP на километр. Только после этого станет понятно: можно ли ставить алгоритм в подсказку оператору, или его место на свалке.