GNN соціальний граф: де ламається передбачення зв'язків
Модель на соціальному графі помиляється не випадково: провали групуються на конкретних ділянках. Якість зв'язків там падає передбачувано — за ступенем вузла, темпом зростання спільноти й давністю розмітки.
Тому усереднена метрика по всьому масиву нічого не говорить про те, як рішення поводитиметься на нових користувачах.
Рідкісні зв'язки — перший провал. У вузла зі ступенем один-два агрегація сусідів перетворює шум на основу передбачення: сигналу менше, ніж варіативності. Такі пари модель або недооцінює, або тягне до середнього по популяції — а саме вони найчастіше й виявляються цільовими.
Друга ділянка — розмітка ботів. Автоматизовані акаунти створюють щільні кліки з майже однаковими ознаками, і модель швидко вивчає їх як сильний сигнал зв'язку. Далі передбачення зв'язків відтворює активність ботів як норму, а живі слабкі зв'язки йдуть униз за ранжуванням.
Пошук спільнот ламається на швидкому зростанні: за пару тижнів склад групи змінюється настільки, що вивчені представлення описують уже неіснуючу структуру. До цього додається застаріла розмітка — зв'язки, позначені значущими, давно розпалися, а нові ніхто не позначав.
Ми розбираємо граф за цими зонами окремо, а не однією цифрою по всьому масиву: шум у соціальному графі потрібно спочатку локалізувати, інакше будь-яка донавчена модель просто переносить помилку на іншу ділянку. Нижче — як це влаштовано.
Що змінюється після впровадження: якість, швидкість, відмови
Середня точність по графу оманлива: вона тримається на популярних вузлах, а рішення ухвалюються за рідкісними зв'язками.
Тому метрику якості вважаємо окремо на хвості розподілу — частка правильних передбачень для пар з одним-двома спільними зв'язками, і саме там модель дає основний приріст.
Навчання ведемо на графових мережах у PyTorch Geometric: сигнал від сусідів другого й третього порядку працює там, де частотні ознаки мовчать.
Свіжість зв'язків — друга метрика. Замість повного перерахунку ембедингів по всьому графу вважаємо інкрементально: оновлюємо зачеплені вузли та їхнє оточення, а повний прогін залишаємо за розкладом, щоб вичищати накопичений дрейф. Нове ребро потрапляє в модель у межах короткого вікна, а не до наступного вивантаження.
Накрутку ловимо на структурі, а не на лічильниках: щільні кліки свіжих акаунтів, аномальний приріст ступеня, збіжні шаблони зв'язків. Масова підписка змінює числа, але викривляє локальну топологію — це видно до того, як схема встигла спрацювати.
Модель віддає оцінку впевненості, а не ярлик, тому в ручну перевірку йде тільки прикордонна зона — частка розборів скорочується, спірні випадки залишаються в аналітика. Розмітка з перевірок повертається в навчання, і наступний перерахунок знімає частину навантаження з людей.
Пішов окремий клас відмов, коли граф будувався за знімком і модель вирішувала на вчорашніх зв'язках: контроль дрейфу показує деградацію повноти й точності до того, як вона дійде до рішень.
Порівняння підходів: правила, ембединги, моделі на зв'язках
Вибір між підходами — не про «найсильніше» рішення, а про те, що дає прийнятну точність на ваших даних і переживає наступну зміну поведінки аудиторії.
На старті задачу майже завжди пробують закрити правилами: активність за вікно, частка спільних сусідів, поріг за кількістю повідомлень.
Правила та евристики читаються, пояснюються й працюють без розмітки — але кожне нове правило конфліктує з попереднім, а пороги доводиться переналагоджувати при кожному зсуві в активності.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Жорсткі правила та евристики | Потрібен швидкий пояснюваний результат, розмітки немає | Кількість правил зростає швидше за точність, хибні спрацювання накопичуються |
| Статистичні ознаки вузла | Є агрегати за профілем: активність, склад зв'язків | Ігнорує структуру — оцінка вузла не залежить від оточення |
| Векторні представлення вузлів | Потрібно порівнювати вузли й шукати схожих | Згортає контекст: представлення не змінюється разом із сусідами |
| Модель на зв'язках | Важливі шляхи, спільноти та передбачення зв'язків | Потрібні дані й розмітка, дорожче в підтримці та поясненні рішення |
Статистичні ознаки та векторні представлення вузлів займають середину: перші дешеві й передбачувані, другі дають порівняння однотипних учасників, але обидві схеми дивляться на вузол окремо від графа.
Модель на зв'язках читає оточення цілком і тому краще працює там, де важливий сам характер зв'язків.
На практиці вибір підходу найчастіше виявляється каскадом: правила відсікають очевидні випадки, векторні представлення дають кандидатів, модель на зв'язках ранжує їх за ймовірністю.
Кластеризація спільнот додає рівень групи — бот-ферма видна не за окремим вузлом, а за щільною зв'язністю між кластерами, які мають бути майже не пов'язані.
Як ми будуємо модель: етапи інженерної роботи
Розробку графової нейромережі (GNN) на соціальному графі ведемо як ланцюжок кроків, де кожен спирається на зафіксований результат попереднього.
Порядок принциповий: якщо ознаки та розбиття даних зібрані «на око», модель показує гарні метрики на навчанні й розвалюється на живих даних. Тому схему та правила фіксуємо до запуску навчання.
- Аудит даних. Дивимося, які зв'язки та атрибути є в графі: підписки, історія взаємодій, мітки ботів і спільнот. Перевіряємо дублі, пропуски та межу, з якої дані придатні для навчання.
- Схема ознак. Описуємо, що подаємо на вузол і ребро: ступінь, вік акаунта, перетин оточень, активність у спільнотах. Схема визначає, які дані збирати далі.
- Складання навчального набору. Ділимо історію за часом, а не випадково, інакше модель підгляне майбутнє. Мітки фіксуємо на момент розбиття, негативні приклади беремо з пар без зв'язку.
- Налаштування моделі. Підбираємо глибину обходу сусідів, частку відкиданих зв'язків і правила для рідкісних вузлів. Окремо перевіряємо, чи немає перенавчання на найактивніших учасниках.
- Валідація на відкладеному періоді. Вважаємо частку правильних передбачень зв'язків, повноту за ботами та стійкість за спільнотами на відрізку, якого модель не бачила.
- Передача рішення. Віддаємо модель, код підготовки ознак, зафіксовану схему та інструкцію з перерахунку — команда замовника запускає все сама.
- Регламент оновлення. Соцграф змінюється щодня: задаємо період перенавчання, контрольні метрики та правила відкату на попередню версію.
Артефакти впровадження: схеми, конфігурації, регламенти
Після впровадження у замовника залишаються не лише робоча модель, а й інженерні артефакти: за ними рішення розвивається власними силами або передається іншій команді без зворотного проєктування. Кожен документ прив'язаний до конкретного кроку обробки графа й оновлюється разом із моделлю.
- Схеми обробки даних. Шлях від джерел до графа: як формуються вершини та ребра, де нормалізуються ідентифікатори й відсікаються дублі, які атрибути йдуть в ознаки. Підключення нового джерела — правка одного вузла схеми.
- Конфігурації моделі. Шари агрегації за сусідами, розмір околиці, ваги класів, розбиття вибірки за часом. Випадкове розбиття на графі з часовими зв'язками завищує метрики й не переноситься в роботу.
- Правила розмітки. Що вважається ботом, а що активним учасником, як позначаються підозрілі зв'язки та спільноти, як перевіряється узгодженість розмітників. Інакше модель навчається на суперечностях.
- Політики доступу. Кому доступний повний граф, кому лише агрегати, які поля знеособлюються на вході, хто може вивантажувати підграф. Журнал запитів закриває питання служби безпеки.
- Регламент перенавчання. Тригери — дрейф структури графа, падіння метрик нижче порогу, поява нового типу зв'язків; періодичність, перевірка на відкладеному періоді, порядок відкату до попередньої версії.
- Документація та відтворюваність. Карта ознак, словник метрик із цільовими значеннями, інструкції із запуску навчання та виведення передбачень. Процес відтворюється з нуля на чистих даних.
Кейс: розмітка ботів у спільноті, метрики до та після
Як було
Спільнота в Discord виросла до десятків тисяч акаунтів, і ручна розмітка перестала встигати: два модератори перевіряли скарги по одному профілю, а боти приходили зв'язками. Поки розбирали одного, з'являлося ще кілька — черга зростала швидше, ніж її розбирали.
Точність на рідкісних зв'язках просідала: одиночний бот майже не відрізняється від новачка, а зв'язка видає себе структурою. Блокували активних — ядро зв'язки залишалося й відновлювало мережу за кілька днів.
Що змінили
Ми перевели розмітку з окремих акаунтів на граф взаємодій: вузли — профілі та канали, ребра — відповіді, реакції та спільні появи в гілках. Модель на зв'язках поширює ознаки по околиці й розмічає кластер цілком, тому слабкі сигнали одного профілю підсилюються сигналами сусідів. Рідкісним, але повторюваним парам дали окрему вагу.
Точність розмітки зросла з 0,62 до 0,89, повнота на рідкісних зв'язках — з 0,41 до 0,78. Частка зв'язок, знайдених цілком до спалаху, піднялася з третини до 85%, а черга ручної перевірки скоротилася вчетверо: модератор підтверджує рішення за кластером, а не за кожним профілем.
Динаміка спільнот змінилася: частка перереєстрацій після блокування впала приблизно втричі — разом з активними йде ядро зв'язки. Модель лише ранжує кандидатів, фінальне рішення залишається за модератором, тому відкат до ручної розмітки не ламає процес.
Що робити, якщо граф уже побудований, а якість зв'язків низька
Погана якість на GNN рідко пояснюється архітектурою — у більшості випадків причина в даних. Перш ніж міняти глибину агрегації, виключають три речі: витік цільових ребер в ознаки, шум у розмітці та розсинхрон навчальної й перевірної вибірок за часом.
Діагностика йде від симптому до причини:
| Симптом | Імовірна причина | Перший крок перевірки |
|---|---|---|
| На навчанні метрики зростають, на перевірці падають | Перенавчання на структурі | Урізати глибину обходу, додати регуляризацію ребер |
| Якість плавно деградує з часом | Зсув розподілу | Дивитися дрейф ознак і нові типи зв'язків за вікнами |
| Нові учасники передбачаються гірше за старих | Холодний старт вузлів | Вважати частку вузлів зі ступенем менше двох |
| Модель упевнено помиляється | Шум у розмітці | Переперевірити спірні ребра та згоду розмітників |
Порядок діагностики зворотний до звичного — від даних до моделі. Спочатку перевірка розмітки на підвибірці зв'язків і згода між розмітниками, потім метрики в розрізі часових вікон, і тільки потім архітектура: глибина агрегації, ваги класів, відбір негативних прикладів.
Бібліотеки на кшталт PyTorch Geometric дають готові шари та завантажувачі графів, але послідовність перевірок залишається за інженером.
Холодний старт закривається окремо. Для вузлів зі ступенем менше двох ознаки беруться з профілю, а не з оточення, і такі вузли маскуються у функції втрат, щоб не розмивати градієнт.
Зсув розподілу ловиться ковзним вікном перенавчання — при виході частки нових типів зв'язків за поріг модель навчається заново, а не доналагоджується на застарілих даних.
Ознака, що порядок спрацював: розрив між навчанням і перевіркою перестає зростати, а якість на вузлах-новачках підтягується до середнього по графу.
Сумніви щодо впровадження: масштаб, розмітка, приватність
Сумніви на вході майже завжди одні й ті самі: даних мало або багато, розмітка дорога, приватність під питанням, а результат потрібен не відразу. Розберемо п'ять технічних питань, від яких залежить план робіт.
Скільки зв'язків доведеться розмічати вручну?
Менше, ніж здається: основний сигнал модель бере зі структури графа, а не з ручних міток. Вручну розмічаємо лише валідаційну вибірку та спірні випадки — сотні зв'язків, збалансованих за типами вузлів.
Що буде, коли граф виросте на порядок?
Навчання йде не на всьому графі, а на околицях вузлів: зростає обсяг даних, а не час розрахунку. Модель донавчається інкрементально, а зберігання відокремлено від розрахунку.
Як це поєднується з приватністю?
Модель бачить знеособлені ідентифікатори та топологію зв'язків, персональні атрибути в навчання не потрапляють. Агрегати за потреби рахуються всередині вашого контуру, назовні йде результат.
Чи можна впроваджувати поетапно?
Так, і це бажаний шлях. Спочатку перевірка на накопиченій історії, потім тіньовий режим — прогнози рахуються, але рішення ухвалює поточна логіка, — і тільки потім обмежений контур.
Як переконатися, що прогнозам можна довіряти?
Дивимося не лише метрики якості, а й калібрування впевненості, спірні зв'язки перевіряємо вручну. Поріг ставимо так, щоб на неоднозначних зв'язках модель мовчала, а відкат до правил залишався в одну команду.
Обговоримо задачу: що надіслати для стартової оцінки
Щоб повернутися з оцінкою строків і планом робіт, а не із загальними словами, достатньо кількох вихідних даних. Готувати повне технічне завдання на цьому етапі не потрібно — обсяг робіт оцінюється за описом сценарію та одним реальним фрагментом графа.
- Сценарій застосування: хто отримує результат і яке рішення ухвалює — блокування бота, рекомендація зв'язку або модерація спільноти.
- Приклад вивантаження: знеособлений фрагмент графа — вершини, ребра, типи зв'язків і атрибути, обсяг і період спостереження.
- Поточні правила: евристики та пороги, за якими рішення ухвалюється зараз, і де вони помиляються.
- Метрика якості: що вважається правильною відповіддю і за якою часткою правильних спрацювань ви оцінюєте поточне рішення.
- Розмітка: чи є підтверджені приклади — відомі боти, підтверджені зв'язки, розмічені спільноти.
- Обмеження: вимоги до приватності, строків зберігання, доступів і знеособлення даних.
- Очікуваний ефект: що має змінитися після впровадження і в яких числах ви це вимірюєте.
З цього набору складається постановка задачі: вибираємо ознаки для вершин і зв'язків, плануємо перевірку на відкладеному періоді й фіксуємо метрику приймання. Опишіть сценарій у вільній формі — повернемося з оцінкою строків і планом робіт за етапами.
