hack-3bb6f822-ghost-in-the-shell

Hackathon team repository for Ghost in the Shell

Ghost in the Shell Hackathon Solution

Граф денег: роли, кластеры, приоритеты

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

Все правила детерминированные (без ML/LLM) — результат воспроизводим.

Быстрый запуск (одна команда для пайплайна)

pip install -r requirements.txt
python pipeline.py

На выходе в текущей папке появятся: nodes_roles.csv, clusters.csv, top_nodes.csv. Время выполнения на предоставленном объёме (2248 узлов / 3119 рёбер) — менее минуты.

Интерфейс просмотра

streamlit run app.py

Откроется локально (localhost:8501). Вкладки:

• Поиск по gid — вводишь gid, видишь роль, обоснование и интерактивную схему связей узла (входящие/исходящие, до 3 шагов вглубь);
• Топ-лист приоритетов — таблица с сортировкой;
• Кластеры — состав каждого кластера + гипотеза, с визуализацией;
• Вся сеть — общая схема с подсветкой ролей (ограничена по числу узлов для читаемости).

Структура репозитория

data/ -------- исходные .parquet (описание полей — data/README.md)
pipeline.py -- весь расчёт: роли, кластеры, приоритеты → 3 CSV
app.py -------- экран просмотра (Streamlit)
requirements.txt

Роли узлов — критерии и пороги

Правила применяются сверху вниз, срабатывает первое подходящее:

Роль	Правило
coordinator	Узел-мост: betweenness centrality в топ-10% по сети, при этом ≥3 входящих и ≥3 исходящих связей
transit	Отдаёт почти всё полученное дальше: out/in от 0.8 до 1.2, и с момента первого входящего до первого исходящего перевода проходит ≤3 дней
consolidator	Получает от ≥3 разных плательщиков (или от ≥3 независимых seed-цепочек), и заметно удерживает средства (out/in < 0.6, либо нет исходящих вовсе)
distributor	≥5 исходящих связей и ≤2 входящих — веерная раздача без накопления
terminal	Есть входящие, исходящих в графе нет. Если узел на 4-м колене — уверенность снижена (0.45 вместо 0.85): это может быть не реальный конечный получатель, а артефакт обрыва обхода на максимальной глубине
peripheral	Не подошёл ни под одно правило выше — недостаточно сигналов

role_score (0–1) — эвристическая уверенность в присвоенной роли, не вероятность в статистическом смысле. priority_score — взвешенная комбинация: вес роли × уверенность + число независимых seed-цепочек, доходящих до узла + степень узла (кол-во связей) + бонус, если узел сам является seed.

Почему transit проверяется раньше consolidator

Условие consolidator (≥3 плательщика) само по себе широкое и без дополнительной проверки поймало бы и узлы, которые просто быстро пропускают деньги дальше от нескольких источников (чистый транзит). Чтобы не путать накопление с транзитом, transit проверяется первым, а в consolidator добавлена проверка удержания средств (ratio < 0.6).

Обоснование для аналитика (evidence / why)

Каждая строка в nodes_roles.csv и top_nodes.csv содержит текстовое объяснение на естественном языке — конкретные цифры (кол-во контрагентов, суммы, задержки), а не абстрактный скор. Формулировки намеренно осторожные («кандидат», «признаки», «требует проверки») — это гипотезы для дальнейшей проверки аналитиком, а не утверждения о причастности.

Ограничения подхода

• Обрыв на 4-м колене. 444 узла с depth=4 и без исходящих связей — это в значительной части артефакт глубины обхода (граф просто не прослеживался дальше), а не доказательство того, что деньги там осели. Учтено понижением role_score для таких узлов в роли terminal.
• Только исходящие переводы. Входящие потоки на узлы вне выборки не видны — полный баланс узла посчитать нельзя, работаем только с тем, что видно внутри графа.
• У seed-клиентов входящие занижены — граф собран от них, а не к ним; соотношение «отдал/получил» для seed интерпретировать буквально нельзя.
• Порог 5 000 KZT. Дробление переводов ниже порога в данных не видно — возможна намеренная фрагментация транзакций, скрытая от графа.
• Сеть не монолитна — 16 слабосвязных компонент, часть узлов вне главной компоненты; кластеризация (Louvain) не объединяет их искусственно.
• Нет ground truth и атрибутов клиента. Оценка идёт по обоснованности критериев, а не по accuracy; никакие данные о личности клиентов не используются и не восстанавливаются.

Масштабирование до ~1 млн узлов

При росте графа на два-три порядка текущий подход потребует изменений:

• Betweenness centrality считается точно за O(V·E) — на 1 млн узлов это неприемлемо долго. Нужна аппроксимация (например, k-sampling в networkx/igraph) или переход на приближённые меры центральности.
• Louvain на всём графе в памяти упрётся в лимиты pandas/networkx — нужно либо переходить на графовую БД с инкрементальной кластеризацией (Neo4j GDS, igraph на диске), либо партиционировать граф по слабосвязным компонентам и кластеризовать каждую отдельно.
• upstream_seeds (счётчик независимых seed-цепочек) считается за один проход по рёбрам, отсортированным по depth — остаётся линейным по числу рёбер и масштабируется нормально, но при 1 млн узлов данные стоит хранить не в parquet-файлах целиком в памяти, а в графовой БД с индексами по src/dst.
• Интерфейс. Полная отрисовка сети в pyvis нежизнеспособна на миллионах узлов — уже сейчас app.py ограничивает схему топ-N узлами по приоритету; при росте графа этот подход остаётся единственным рабочим — рендерить только релевантный подграф вокруг искомого gid, а не всю сеть целиком.

Данные

Repository: https://github.com/BAITC-Hacks/hack-3bb6f822-ghost-in-the-shell

Presentation: [https://docs.google.com/presentation/d/1PCglSGLlLyTean3qFoHPjy5VmfYUaGBy/edit?usp=sharing&ouid=115657269000839204838&rtpof=true&sd=true]

Demo: локальный запуск через streamlit run app.py Описание полей и параметров сбора графа — в data/README.md.