GNN для соцграфов: боты, сообщества, предсказание связей

GNN социальный граф: где ломается предсказание связей

Модель на социальном графе ошибается не случайно: провалы группируются на конкретных участках. Качество связей там падает предсказуемо — по степени узла, темпу роста сообщества и давности разметки. Поэтому усреднённая метрика по всему массиву ничего не говорит о том, как решение поведёт себя на новых пользователях.

Редкие связи — первый провал. У узла со степенью один-два агрегация соседей превращает шум в основу предсказания: сигнала меньше, чем вариативности. Такие пары модель либо недооценивает, либо тянет к среднему по популяции — а именно они чаще всего и оказываются целевыми.

Второй участок — разметка ботов. Автоматизированные аккаунты создают плотные клики с почти одинаковыми признаками, и модель быстро выучивает их как сильный сигнал связи. Дальше предсказание связей воспроизводит активность ботов как норму, а живые слабые связи уходят вниз по ранжированию.

Поиск сообществ ломается на быстром росте: за пару недель состав группы меняется настолько, что выученные представления описывают уже несуществующую структуру. К этому добавляется устаревшая разметка — связи, помеченные значимыми, давно распались, а новые никто не отмечал.

Мы разбираем граф по этим зонам по отдельности, а не одной цифрой по всему массиву: шум в социальном графе нужно сначала локализовать, иначе любая дообученная модель просто переносит ошибку на другой участок. Ниже — как это устроено.

Что меняется после внедрения: качество, скорость, отказы

Средняя точность по графу обманчива: она держится на популярных узлах, а решения принимаются по редким связям. Поэтому метрику качества считаем отдельно на хвосте распределения — доля верных предсказаний для пар с одной-двумя общими связями, и именно там модель даёт основной прирост. Обучение ведём на графовых сетях в PyTorch Geometric: сигнал от соседей второго и третьего порядка работает там, где частотные признаки молчат.

Свежесть связей — вторая метрика. Вместо полного пересчёта эмбеддингов по всему графу считаем инкрементально: обновляем затронутые узлы и их окружение, а полный прогон оставляем по расписанию, чтобы вычищать накопленный дрейф. Новое ребро попадает в модель в пределах короткого окна, а не к следующей выгрузке.

Накрутку ловим на структуре, а не на счётчиках: плотные клики свежих аккаунтов, аномальный прирост степени, совпадающие шаблоны связей. Массовая подписка меняет числа, но искажает локальную топологию — это видно до того, как схема успела сработать.

Модель отдаёт оценку уверенности, а не ярлык, поэтому в ручную проверку уходит только пограничная зона — доля разборов сокращается, спорные случаи остаются у аналитика. Разметка из проверок возвращается в обучение, и следующий пересчёт снимает часть нагрузки с людей.

Ушёл отдельный класс отказов, когда граф строился по снимку и модель решала на вчерашних связях: контроль дрейфа показывает деградацию полноты и точности до того, как она дойдёт до решений.

Сравнение подходов: правила, эмбеддинги, модели на связях

Выбор между подходами — не про «самое сильное» решение, а про то, что даёт приемлемую точность на ваших данных и переживает следующее изменение поведения аудитории. На старте задачу почти всегда пробуют закрыть правилами: активность за окно, доля общих соседей, порог по числу сообщений. Правила и эвристики читаемы, объяснимы и работают без разметки — но каждое новое правило конфликтует с предыдущим, а пороги приходится переподбирать при каждом сдвиге в активности.

Статистические признаки и векторные представления узлов занимают середину: первые дёшевы и предсказуемы, вторые дают сравнение однотипных участников, но обе схемы смотрят на узел отдельно от графа. Модель на связях читает окружение целиком и потому лучше работает там, где важен сам характер связей. На практике выбор подхода чаще всего оказывается каскадом: правила отсекают очевидные случаи, векторные представления дают кандидатов, модель на связях ранжирует их по вероятности.

Кластеризация сообществ добавляет уровень группы — бот-ферма видна не по отдельному узлу, а по плотной связности между кластерами, которые должны быть почти не связаны.

Как мы строим модель: этапы инженерной работы

Разработку графовой нейросети (GNN) на социальном графе ведём как цепочку шагов, где каждый опирается на зафиксированный результат предыдущего. Порядок принципиален: если признаки и разбиение данных собраны «на глаз», модель показывает красивые метрики на обучении и разваливается на живых данных. Поэтому схему и правила фиксируем до запуска обучения.

1. Аудит данных. Смотрим, какие связи и атрибуты есть в графе: подписки, история взаимодействий, метки ботов и сообществ. Проверяем дубли, пропуски и границу, с которой данные пригодны для обучения.
2. Схема признаков. Описываем, что подаём на узел и ребро: степень, возраст аккаунта, пересечение окружений, активность в сообществах. Схема определяет, какие данные собирать дальше.
3. Сборка обучающего набора. Делим историю по времени, а не случайно, иначе модель подсмотрит будущее. Метки фиксируем на момент разбиения, отрицательные примеры берём из пар без связи.
4. Настройка модели. Подбираем глубину обхода соседей, долю отбрасываемых связей и правила для редких узлов. Отдельно проверяем, нет ли переобучения на самых активных участниках.
5. Валидация на отложенном периоде. Считаем долю верных предсказаний связей, полноту по ботам и устойчивость по сообществам на отрезке, которого модель не видела.
6. Передача решения. Отдаём модель, код подготовки признаков, зафиксированную схему и инструкцию по пересчёту — команда заказчика запускает всё сама.
7. Регламент обновления. Соцграф меняется ежедневно: задаём период переобучения, контрольные метрики и правила отката на предыдущую версию.

Артефакты внедрения: схемы, конфигурации, регламенты

После внедрения у заказчика остаются не только работающая модель, но и инженерные артефакты: по ним решение развивается своими силами или передаётся другой команде без обратного проектирования. Каждый документ привязан к конкретному шагу обработки графа и обновляется вместе с моделью.

• Схемы обработки данных. Путь от источников до графа: как формируются вершины и рёбра, где нормализуются идентификаторы и отсекаются дубли, какие атрибуты идут в признаки. Подключение нового источника — правка одного узла схемы.
• Конфигурации модели. Слои агрегации по соседям, размер окрестности, веса классов, разбиение выборки по времени. Случайное разбиение на графе с временными связями завышает метрики и не переносится в работу.
• Правила разметки. Что считается ботом, а что активным участником, как помечаются подозрительные связи и сообщества, как проверяется согласованность разметчиков. Иначе модель учится на противоречиях.
• Политики доступа. Кому доступен полный граф, кому только агрегаты, какие поля обезличиваются на входе, кто может выгружать подграф. Журнал запросов закрывает вопросы службы безопасности.
• Регламент переобучения. Триггеры — дрейф структуры графа, падение метрик ниже порога, появление нового типа связей; периодичность, проверка на отложенном периоде, порядок отката к предыдущей версии.
• Документация и воспроизводимость. Карта признаков, словарь метрик с целевыми значениями, инструкции по запуску обучения и выводу предсказаний. Процесс воспроизводится с нуля на чистых данных.

Кейс: разметка ботов в сообществе, метрики до и после

Как было

Сообщество в Discord выросло до десятков тысяч аккаунтов, и ручная разметка перестала успевать: два модератора проверяли жалобы по одному профилю, а боты приходили связками. Пока разбирали одного, появлялось ещё несколько — очередь росла быстрее, чем её разбирали.

Точность на редких связях проседала: одиночный бот почти неотличим от новичка, а связка выдаёт себя структурой. Блокировали активных — ядро связки оставалось и восстанавливало сеть за несколько дней.

Что изменили

Мы перевели разметку с отдельных аккаунтов на граф взаимодействий: узлы — профили и каналы, рёбра — ответы, реакции и совместные появления в ветках. Модель на связях распространяет признаки по окрестности и размечает кластер целиком, поэтому слабые сигналы одного профиля усиливаются сигналами соседей. Редким, но повторяющимся парам дали отдельный вес.

Точность разметки выросла с 0,62 до 0,89, полнота на редких связях — с 0,41 до 0,78. Доля связок, найденных целиком до всплеска, поднялась с трети до 85%, а очередь ручной проверки сократилась вчетверо: модератор подтверждает решение по кластеру, а не по каждому профилю.

Динамика сообществ изменилась: доля перерегистраций после блокировки упала примерно втрое — вместе с активными уходит ядро связки. Модель только ранжирует кандидатов, финальное решение остаётся за модератором, поэтому откат к ручной разметке не ломает процесс.

Что делать, если граф уже построен, а качество связей низкое

Плохое качество на GNN редко объясняется архитектурой — в большинстве случаев причина в данных. Прежде чем менять глубину агрегации, исключают три вещи: утечку целевых рёбер в признаки, шум в разметке и рассинхрон обучающей и проверочной выборок по времени.

Диагностика идёт от симптома к причине:

Порядок диагностики обратный привычному — от данных к модели. Сначала проверка разметки на подвыборке связей и согласие между разметчиками, затем метрики в разрезе временных окон, и только потом архитектура: глубина агрегации, веса классов, отбор отрицательных примеров. Библиотеки вроде PyTorch Geometric дают готовые слои и загрузчики графов, но последовательность проверок остаётся за инженером.

Холодный старт закрывается отдельно. Для узлов со степенью меньше двух признаки берутся из профиля, а не из окружения, и такие узлы маскируются в функции потерь, чтобы не размывать градиент. Сдвиг распределения ловится скользящим окном переобучения — при выходе доли новых типов связей за порог модель обучается заново, а не донастраивается на устаревших данных.

Признак, что порядок сработал: разрыв между обучением и проверкой перестаёт расти, а качество на узлах-новичках подтягивается к среднему по графу.

Сомнения по внедрению: масштаб, разметка, приватность

Сомнения на входе почти всегда одни и те же: данных мало или много, разметка дорогая, приватность под вопросом, а результат нужен не сразу. Разберём пять технических вопросов, от которых зависит план работ.

Что будет, когда граф вырастет на порядок?

Обучение идёт не на всём графе, а на окрестностях узлов: растёт объём данных, а не время расчёта. Модель дообучается инкрементально, а хранение отделено от расчёта.

Как это сочетается с приватностью?

Модель видит обезличенные идентификаторы и топологию связей, персональные атрибуты в обучение не попадают. Агрегаты при необходимости считаются внутри вашего контура, наружу уходит результат.

Можно ли внедрять поэтапно?

Да, и это предпочтительный путь. Сначала проверка на накопленной истории, затем теневой режим — прогнозы считаются, но решения принимает текущая логика, — и только потом ограниченный контур.

Как убедиться, что прогнозам можно доверять?

Смотрим не только метрики качества, но и калибровку уверенности, спорные связи проверяем вручную. Порог ставим так, чтобы на неоднозначных связях модель молчала, а откат к правилам оставался в одну команду.

Обсудим задачу: что прислать для стартовой оценки

Чтобы вернуться с оценкой сроков и планом работ, а не с общими словами, достаточно нескольких исходных данных. Готовить полное техническое задание на этом этапе не нужно — объём работ оценивается по описанию сценария и одному реальному фрагменту графа.

• Сценарий применения: кто получает результат и какое решение принимает — блокировка бота, рекомендация связи или модерация сообщества.
• Пример выгрузки: обезличенный фрагмент графа — вершины, рёбра, типы связей и атрибуты, объём и период наблюдения.
• Текущие правила: эвристики и пороги, по которым решение принимается сейчас, и где они ошибаются.
• Метрика качества: что считается верным ответом и по какой доле верных срабатываний вы оцениваете текущее решение.
• Разметка: есть ли подтверждённые примеры — известные боты, подтверждённые связи, размеченные сообщества.
• Ограничения: требования к приватности, срокам хранения, доступам и обезличиванию данных.
• Ожидаемый эффект: что должно измениться после внедрения и в каких числах вы это измеряете.

Из этого набора складывается постановка задачи: выбираем признаки для вершин и связей, планируем проверку на отложенном периоде и фиксируем метрику приёмки. Опишите сценарий в свободной форме — вернёмся с оценкой сроков и планом работ по этапам.