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