П’ять агентів, які розслідують попередження про шахрайство, а не просто ставлять їм оцінки.

Модель виявлення шахрайств добре справляється з одним: вона попереджає про те, що транзакція виглядає підозріло. Проте вона значно гірше справляється з відповідями на запитання, які насправді потрібні аналітику для закриття справи. Що тут сталося? Чому це виглядає підозріло? Що слід робити прямо зараз?

FraudLens AI — проект хакатону для Google Cloud Hackathon 2026 — створений саме для відповіді на ці запитання. Він не намагається створити кращий показник шахрайства. Натомість він обгортає існуючий показник п’ятьма взаємодіючими агентами, які проводять розслідування: вони збирають поведінкові докази, узгоджують події автентифікації, складають короткий огляд справи та дозволяють аналітикам запитувати дані простою англійською мовою.

Показник — це не пояснення

Багато систем боротьби з шахрайством зупиняються на такій цифрі, як 0.87. Модель, що стоїть за ними, може бути чудовою у виявленні підозрілої поведінки, але слідчий, який дивиться на цю цифру, все одно не розуміє, що саме сталося та чому модель це зафіксувала.

Сьогодні цю прогалину заповнює людина. Вона відкриває рахунок, проглядає історію транзакцій, перевіряє, чи з’являвся пристрій раніше, читає журнали автентифікації, порівнює нещодавню діяльність із попередніми моделями та нарешті складає звіт, який обґрунтовує прийняте рішення.

Усе це є повільним та повторюваним процесом, і воно припиняє працювати, коли кількість сповіщень різко зростає. Ідея FraudLens полягає у тому, щоб залишити модель боротьби з шахрайством без змін та автоматизувати розслідування, яке починається після того, як модель видає сповіщення.

П’ять агентів, п’ять завдань

Платформа розподіляє оцінку ризиків та розслідування між п’ятьма агентами. Кожен з них має вузькі обов’язки, подібно до спеціалістів, які ділять роботу в команді з боротьби з шахрайством.

Агент виявлення

Оцінка здійснюється за допомогою класифікатора XGBoost. Його було перевірено на публічному наборі даних Kaggle Credit Card Fraud Detection, який містить 284 807 транзакцій та 492 підтверджені випадки шахрайства. Результати перевірки:

Цей набір даних з реального світу використовується лише для перевірки моделі виявлення, що є важливою відмінністю, яка знову згадується нижче.

Агент розслідування

Коли транзакція перевищує поріг для розслідування, цей агент створює контекст навколо неї. Він аналізує:

• поведінку рахунку та історію транзакцій
• суми, які не відповідають характеристикам рахунку
• поведінку країни та контекст IP-адреси
• які пристрої прив’язані до яких рахунків
• відхилення від історичних закономірностей

Тож замість передачі значення Risk Score: 0.92 система формулює висновки, на основі яких можна вжити дій, наприклад „ця сума значно перевищує середнє значення за історію рахунку“ або „цей пристрій використовувався кількома різними рахунками“. Ці висновки збираються у структурований файл справи, який використовують наступні агенти.

Агент аналізу журналів

Активність входу є часто найсильнішим доказом, який у вас є, особливо коли існує ризик захоплення облікового запису. Проєкт використовує синтетичний журнал автентифікації з такими подіями, як LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED та PASSWORD_RESET, і цей агент порівнює ці події з підозрілими транзакціями.

LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION

Така послідовність повідомляє набагато більше, ніж сама транзакція. Вона виявляє сигнали про можливе захоплення облікового запису, які модель, що аналізує лише оплати, ніколи б не побачила.

Де підходить Gemini, а де — ні

Агент пояснень

Google Gemini втручається лише на цьому етапі. Агенти виявлення та розслідування спочатку створюють структуровані докази, а агент пояснень передає ці докази Gemini для перетворення їх на зрозумілий опис, щось на кшталт: ця транзакція позначена як КРИТИЧНА, тому що вона значно виходить за межі звичайної поведінки облікового запису та узгоджується з незвичайною діяльністю пристрою та процесом входу, тож її потрібно негайно перевірити.

Важливим елементом дизайну є те, що Gemini ніколи не встановлює оцінку ризику шахрайства. Це пояснює наявність доказів того, що детерміністичний код вже виконав свою роботу. Це забезпечує надійність основного рішення та запобігає ситуаціям, коли галюцинації можуть змінити рішення щодо позначення платежу як підозрілого.

Агент запитів

Аналітики можуть вводити запити на кшталт "покажіть мені критичні транзакції з Нігерії". Моделі не дозволяється виконувати довільний код чи сирі SQL-запити. Натомість функції виклику Gemini визначають мету запиту та перетворюють її на перевірені параметри, які потім використовуються звичайним кодом для отримання даних.

Natural Language Request
       │
       ▼
Gemini Function Calling (Intent Extraction)
       │
       ▼
Structured Filters (risk_tier = CRITICAL, country = Nigeria)
       │
       ▼
Application Parameter Validation
       │
       ▼
Controlled Pandas Filtering Layer
       │
       ▼
Filtered Transaction Results

Отримання даних залишається безпечним, прогнозованим та легким для аудиту.

Архітектура та дані

Весь проект постачається як додаток Flask у форматі Docker, який розміщений на Render для живої демонстрації; крім того, існує версія з контейнерною архітектурою, яка працює також на Google Cloud Run.

Одним із свідомих рішень було розділення тверджень щодо показників продуктивності та можливостей демонстрації. Дані з Kaggle використовуються лише для перевірки ефективності системи виявлення, звідки й походить показник ROC-AUC 0.985. Живі процеси аналізу відбуваються на синтетичних корпоративних даних, оскільки анонімізовані зразки не містять відносних полів, таких як історія використання пристрою, журнали входу чи посилання між обліковими записами.

┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│           REAL KAGGLE DATA            │      │        SYNTHETIC ENTERPRISE           │
│         284,807 Transactions          │      │     50,000 Transactions + Logs        │
└───────────────────┬───────────────────┘      └───────────────────┬───────────────────┘
                    │                                              │
                    ▼                                              ▼
┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│          XGBoost Validation           │      │          Live Investigation           │
│ ROC-AUC 0.985 | Precision/Recall 82%  │      │  Accounts + Devices + Auth Logs       │
└───────────────────────────────────────┘      └───────────────────┬───────────────────┘
                                                                   │
                                                                   ▼
                                               ┌───────────────────────────────────────┐
                                               │         Interactive Dashboard         │
                                               │      Evidence + Gemini Narrative      │
                                               └───────────────────────────────────────┘

Повний цикл обробки

Коли аналітик розпочинає розслідування, процес виконується по порядку: агент виявлення оцінює транзакцію, агент розслідування збирає докази поведінки, агент аналізу журналів додає контекст автентифікації, агент пояснень складає опис подій, а результат потрапляє на панель керування справою, де агент запитів може продовжити дослідження.

Розроблено для безперебійної роботи у разі проблем

API штучного інтелекту стикаються з обмеженнями кількості запитів та мережевими помилками. Щоб це не призводило до зупинки додатку, сервіс описів Gemini повністю відокремлений від детерміністичного процесу обробки.

Якщо дзвінок через Gemini зазнає невдачі без такого розділення, сторінка завершує роботу з помилкою 500. З таким розділенням додаток все одно повертає кожен показник основних ризиків, позначки пристрою, відхилення в поведінці та деталі журналу, а також повідомлення, яке не блокує роботу, про те, що пояснення тимчасово недоступні. У найгіршому випадку ви отримуєте звичайну панель для розслідувань, яка все одно виконує свої функції.

Уроки з процесу розробки

• Будьте відверті щодо даних. Розділення перевірки базових показників від синтетичної демонстрації здобуває довіру технічних експертів, які інакше поставили б під сумнів кожну цифру.
• Збирайте докази в коді, спілкуйтесь з LLM. Правила та агрегація мають знаходитися в детерміністичному коді. Завданням моделі є перетворення цього результату на природне пояснення.
• Перевірте ті компоненти, які не потребують роботи з живим API. У наборі є 53 тести, спрямовані на детерміністичну обробку даних, що забезпечує високу надійність без необхідності використання API-токенів під час кожної обробки.

Що буде далі

• стрімова обробка даних за допомогою Google Cloud Pub/Sub та Dataflow замість пакетної обробки
• нативне зберігання даних у Google Cloud за допомогою BigQuery та Firestore
• графові нейронні мережі для виявлення схем шахрайства, що поширюються між багатьма обліковими записами
• багатомодальні докази: включення PDF-документів зі скаргами, документів, що підтверджують особу, та транскрипцій чатів у контекст Gemini

Принцип, який стоїть за цим

Робота зі виявленням шахрайств не закінчується тим, що модель виводить оцінку. Важливо визначити, які докази пояснюють попередження та що має зробити аналітик далі. FraudLens чітко розділяє ці завдання: модель виявляє аномалії, детерміністичний код збирає докази, спеціалізовані агенти проводять розслідування, а LLM лише пояснює результати.

Пов’язані матеріали

• Stateful Remote Sandboxes With Antigravity Managed Agents and the GenAI SDK — Керування багатокроковими агентами зі скриптів: підтримка роботи віддаленої сандбокс-середовища Ubuntu, повторне підключення за ідентифікатором середовища та завантаження знімка робочого простору, із двома прикладами реалізації.
• Чому агенти, які вражають у демо-версіях, зазнають невдач у реальних умовах, та що слід створювати замість них — причини невдач, компроміс між одиночним та багатоагентним підходом, практики проектування, такі як повторні спроби та альтернативні рішення, а також повна картина витрат на експлуатацію AI-агента, окрім плати за токени.