Почему графовые нейронные сети теряют точность на живых данных
На отложенной выборке графовые нейронные сети показывают высокое качество, а в рабочем контуре точность модели на реальных данных проседает — иногда вдвое. Причина почти никогда не в архитектуре: ломается связка «данные — граф — модель».
Первое место — разметка связей. Рёбра размечены фрагментарно: подтверждённые связи есть у небольшой доли узлов, остальное достраивается эвристиками по совпадению атрибутов. Модель учится на смещённой подвыборке и уверенно ошибается там, где связь слабая, — а именно такие участки и определяют поведение графа в бою.
Второе — дрейф структуры. Состав узлов и типов рёбер меняется: появляются новые роли, часть старых связей перестаёт порождать события. Топология перестраивается постепенно, метрики сползают незаметно, и расхождение обнаруживается уже по качеству решения, а не по мониторингу.
Третье — расхождение выгрузки и потока событий. Обучение идёт по пакетному срезу с агрегатами и суточной задержкой, а в работе события приходят с опозданием и дублями. Признаки считаются по разным окнам, и граф на входе модели выглядит иначе, чем на обучении.
Поэтому подготовка графа данных — не разовый этап перед обучением, а часть цикла: сверка схемы связей, контроль доли размеченных рёбер, единые правила пересчёта признаков для обучения и рабочего контура. Разбираем, как это закрывается.
Что даёт внедрение: эффект в измеримых величинах
Графовая модель опирается не на отдельную запись, а на связи между сущностями, поэтому эффект от внедрения видно в метриках, а не в ощущениях. Пять пунктов ниже мы проверяем до старта и фиксируем после вывода в работу — на отложенной выборке и на боевом трафике.
- Время обучения и переобучения. Пересчёт идёт по затронутому подграфу, а не по всей базе: обновление после появления новых связей укладывается в минуты, полное переобучение — часы вместо суток, без окна простоя.
- Качество на редких классах. Признаки соседей дополняют малочисленные примеры, поэтому доля ложных срабатываний на редких событиях падает, а полнота растёт там, где табличные модели недобирают статистику.
- Устойчивость к новым узлам. Новая сущность получает оценку сразу по своим связям, без накопления истории и ручной разметки.
- Устранённый класс отказов. Уходит класс ошибок, который не ловился правилами: аномалии через цепочки косвенных связей, а не через один признак.
- Нагрузка на сопровождение. Часть ручных правил заменяется структурой графа — инженерных часов на поддержку и подстройку порогов становится меньше.
Эффект считаем на инфраструктуре, где графовые слои собраны на PyTorch Geometric: единый конвейер признаков для обучения и вывода, поэтому метрики сопоставимы между итерациями.
Режимы обучения и вывода: что подходит под задачу
Режим обучения выбирают не по «новизне» метода, а по тому, как часто меняется сам граф и сколько времени есть на ответ. Обучение на исторических выгрузках даёт воспроизводимый результат: один срез данных, одинаковые метрики, понятная точка отката. Дообучение на новых связях нужно там, где структура меняется ежедневно — иначе модель теряет актуальность.
Пакетный вывод считает оценки по всему срезу за раз — это удобно для регулярной отчётности. Потоковый отвечает на событие в момент его появления, но опирается только на те связи, что уже дошли до системы. Гибрид со строгими правилами закрывает участки, где ошибка модели недопустима.
| Вариант | Когда подходит | Чем ограничен |
|---|---|---|
| Обучение на исторических выгрузках | Структура связей стабильна, важна воспроизводимость | Данные стареют между пересборками |
| Дообучение на новых связях | Граф растёт ежедневно, есть разметка свежих примеров | Без контроля дрейфа ошибки переносятся в следующие версии |
| Пакетный вывод | Оценки нужны регулярно, по расписанию | Нет реакции на событие в момент его появления |
| Потоковый вывод | Решение нужно сразу, в момент события | Видит только известные связи, слабый старт по новым узлам |
| Гибрид со строгими правилами | Есть участки, где ошибка недопустима | Правила требуют сопровождения и пересмотра |
На практике режимы комбинируют: обучение идёт по выгрузке, вывод — потоком, а правила страхуют критичные решения.
Этапы работы: от аудита данных до передачи модели
Графовая модель начинается не с кода, а с инвентаризации сущностей и связей между ними. Ниже — семь этапов, которые проходит проект: от аудита источников до передачи обученной модели с воспроизводимым конвейером переобучения.
- Аудит данных. Разбираем источники: в каких таблицах, журналах и сервисах лежат сущности, а в каких — связи между ними. Фиксируем пропуски, дубли, устаревшие записи и частоту обновления.
- Проектирование схемы графа. Определяем типы узлов и рёбер, направление связей, веса и временные метки. Схему сверяем с предметной логикой: связь, которой нет в реальном процессе, в графе не появится.
- Подготовка признаков узлов и рёбер. Приводим атрибуты к единому виду, кодируем категории, нормируем числовые поля, добавляем агрегаты по соседним узлам.
- Настройка обучения. Подбираем архитектуру под задачу — классификация узлов, предсказание связей или ранжирование, — а также глубину распространения и регуляризацию.
- Проверка на отложенной выборке. Качество считаем на периоде, не участвовавшем в обучении, с разбиением по времени: случайное разбиение даёт утечку и завышенные цифры.
- Сравнение с текущим решением. Прогоняем модель и действующую логику на одном наборе данных и показываем разницу в показателях, а не только их абсолютные значения.
- Приёмка и передача. Отдаём веса, конфигурации обучения, схему графа, скрипты сборки графа и документацию; фиксируем достигнутые показатели и регламент переобучения.
Что остаётся у вас: схемы, конфигурации, регламенты
Передаём не итоговый отчёт, а рабочий комплект, по которому ваша команда сможет обучать, проверять и расширять графовую модель без нас. Каждый артефакт мы разбираем на созвоне с инженерами и прогоняем один цикл переобучения уже на вашей стороне — чтобы регламенты не остались документом, который никто не открывал.
- Описание схемы графа: типы узлов и рёбер, атрибуты, откуда приходит каждое поле, правила и частота обновления — со примерами выгрузок на реальных данных.
- Конфигурации обучения: гиперпараметры, разбиение на обучающую и отложенную выборки, фиксация случайности — прогон воспроизводится и даёт сопоставимую метрику.
- Документация на модель: что именно предсказывает, на каком периоде данных обучалась, где границы применимости и какие классы ошибок уже известны.
- Регламент переобучения: триггеры (доля изменившихся связей, сдвиг распределения признаков, падение метрики ниже порога), периодичность, кто запускает и как принимается результат.
- Регламент реагирования на деградацию: контрольные метрики, порядок отката на предыдущую версию весов, ответственный за решение и время реакции.
- Разграничение доступа: роли на чтение сырых данных графа и на одни только предсказания, журналирование обращений, порядок выдачи прав новым сотрудникам.
- Инструкция по выпуску новой версии: проверка на фиксированном наборе примеров, критерии приёмки, порядок замены модели в работающем контуре.
Всё лежит в вашем репозитории и вашем хранилище — доступы остаются у вас, мы не держим копий у себя.
Кейс: как снизили долю ложных срабатываний вдвое
Кейс внедрения — выявление скрытых связей между контрагентами: общие реквизиты, телефоны, адреса и цепочки платежей через подставные звенья. Исходная система проверяла сущности по табличным правилам и ручным порогам, каждую запись отдельно, а связи подтягивала выгрузками. Сигнал срабатывал на формальном совпадении поля, и доля ложных срабатываний доходила до 58% — аналитики вручную разбирали шесть случаев из десяти.
Что изменили
Модель данных перевели в графовую: сущности стали узлами, а операции, договоры и общие реквизиты — рёбрами с типом и временной меткой. Идентификаторы нормализовали и схлопнули дубликаты, чтобы один контрагент не распадался на несколько узлов; хранение графа собрали на Neo4j. Признаки считаем по окрестности в 2-3 перехода, а не по одной записи, поэтому в оценку риска попадают посредники и совпадения второго уровня.
Метрики до и после
| Метрика | До | После |
|---|---|---|
| Доля ложных срабатываний | 58% | 27% |
| Полнота на разметке аналитиков | 0.71 | 0.89 |
| Глубина находимых цепочек | 2 узла | 5 узлов |
| Разбор одного сигнала | часы | минуты |
Отдельный эффект дало обучение на разметке, которую аналитики накопили за время работы: часть связей модель находит сама, без прописанного правила.
Графовые модели или табличные: что выбрать под задачу?
Выбор между табличными и графовыми моделями редко упирается в качество алгоритмов. Он упирается в вопрос: зависит ли ответ по объекту от того, с кем этот объект связан, или объект достаточно описать его собственными признаками. Если связь несёт сигнал — граф даёт прирост; если нет — добавляет только стоимость сопровождения.
Табличная модель видит строку: признаки объекта с известными значениями. Графовая добавляет второй канал — рёбра, по которым на каждом слое агрегируются признаки соседей, и объект получает контекст окружения. В антифроде, рекомендациях, разборе цепочек поставок и поиске связанных контрагентов это даёт заметный выигрыш: схемы, невидимые по отдельным записям, видны как структура.
Обратная сторона — данные. Граф нужно регулярно пересобирать: схема узлов и рёбер, порядок появления связей, их качество, доли пропусков. Ошибка в рёбрах тиражируется на все слои и ухудшает результат тише, чем ошибка в признаках, а объяснить ответ сложнее — не всегда видно, какой сосед повлиял на оценку.
Практический порядок выбора такой. Сначала собираем табличную модель и добавляем в неё агрегаты по связям: число соседей, доли по категориям, средние по окружению. Такой набор часто закрывает большую часть возможного прироста при меньшей стоимости поддержки. Графовый подход берём, если остаточная ошибка системно связана со структурой — провалы сосредоточены в плотных группах связанных объектов.
Гипотезу проверяем на одном отложенном срезе, сравнивая оба подхода по целевой метрике. Решение в пользу графа принимаем только тогда, когда прирост устойчив на разных периодах и на новых узлах, а не только на тех, что были в обучении.
Технические сомнения: устойчивость, данные, поддержка
Ниже — четыре вопроса, которые чаще всего звучат на приёмке: как ведёт себя модель при появлении новых узлов, что делать при малом объёме разметки, как пережить смену схемы источника и что остаётся команде после передачи. Отвечаем про механизмы, а не про обещания.
Что происходит, когда в графе появляются новые узлы и связи?
Модель работает в индуктивном режиме: представление узла собирается из его признаков и признаков соседей, поэтому новые вершины не требуют переобучения. Представления для них считаются быстро, а полный пересчёт нужен только при сдвиге распределения связей — его ловит контроль доли новых рёбер и связности.
Хватит ли разметки, если её мало?
Структура связей сама несёт сигнал, поэтому обучение идёт с частичным наблюдением: размечаем наиболее информативные узлы, а не подряд. До старта оцениваем, какого объёма меток достаточно для целевого качества, — иначе разметка съедает сроки без отдачи.
Источник сменил схему данных — модель придётся переписывать?
Нет. Слой преобразования источника в граф отделён от модели: меняется маппинг полей, ядро остаётся. Входной контракт проверяется на схеме, поэтому несовпадение типов останавливает загрузку до выката, а не после него на проде.
Что остаётся нам после передачи проекта?
Конфигурация, схема признаков, регламент переобучения и панель контроля смещения — этого достаточно, чтобы сопровождать модель своими силами. Работаем на открытом стеке с живым сообществом, PyTorch Geometric в том числе: инженеров под такой контур на рынке найти реально, без привязки к нам.
Обсудим задачу: вернёмся с оценкой и планом работ
Чтобы оценка проекта опиралась на факты, а не на предположения, для старта достаточно описания задачи и доступа к срезу данных. Ключевое для графовых нейронных сетей — не объём таблиц, а структура: какие сущности становятся узлами, какие связи между ними значимы, есть ли разметка и как часто меняется граф. Пришлите:
- описание задачи в свободной форме — какой прогноз или ранжирование нужны на выходе, кто и как использует результат;
- схему данных — таблицы или выгрузки с тем, что считаете узлами и рёбрами, включая справочники и связи «многие-ко-многим»;
- срез реальных данных за характерный период, с пропусками и шумом, а не вычищенный образец;
- разметку, если она есть: как формировалась, сколько классов, насколько сбалансированы;
- текущий ориентир — как задача решается сейчас (правила, эвристики, ручная работа) и какую метрику считаете приемлемой;
- ограничения контура — где должно работать решение: закрытый контур, свои серверы или внешнее окружение, какие требования по доступам и журналированию.
В ответ вернёмся с оценкой проекта: реалистичный диапазон сроков, состав команды и перечень рисков с указанием, как их закрываем. Дальше — план работ по этапам с контрольными точками, предложение по пилотному запуску на вашем срезе данных и условия передачи решения: документация, воспроизводимые окружения и обучение ваших инженеров. Опишите задачу в удобном виде — остальное уточним сами.
