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

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

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

Показатель — это не объяснение

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

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

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

Пять агентов, пять задач

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

Агент обнаружения

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

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

Агент для расследования

Когда сделка превышает порог для расследования, этот агент формирует контекст вокруг нее. Он анализирует:

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

Таким образом, вместо передачи значения Рисковый балл: 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 четко разделяет эти этапы: модель обнаруживает подозрительную деятельность, детерминистический код собирает доказательства, специализированные агенты проводят расследование, а большая языковая модель лишь объясняет полученные результаты.

Связанные материалы

• Работа с удаленными сандбоксами с использованием управляемых агентов Antigravity и SDK GenAI — Управление многоэтапными агентами из скрипта: поддержание активного удаленного сандбокса Ubuntu, повторное подключение по идентификатору среды и загрузка снимка рабочей области, с двумя примерами реализации.
• Почему агенты, впечатляющие на демо-версиях, терпят неудачу в реальных условиях, и что следует создавать вместо них — точки возникновения сбоев, компромисс между использованием одного агента и нескольких, практики проектирования, такие как повторные попытки и резервные решения, а также полная картина затрат на эксплуатацию ИИ-агента помимо стоимости токенов.