五个负责调查欺诈警报的智能体，而不仅仅是对其进行评分。
了解由五个智能体构成的欺诈检测系统如何将XGBoost评分与确定性证据收集、登录日志关联分析，以及从不修改评分值的Gemini解释机制相结合。
来源: FraudLens AI: Building AI Agents That Investigate Fraud Like a Human Analyst
欺诈检测模型擅长一件事：告诉你某笔交易存在异常。但对于分析人员为结案所需解答的问题，它的表现就差得多。这里发生了什么？为何会显得可疑？现在应该采取什么措施？
FraudLens AI是2026年Google Cloud黑客松的一个项目，正是围绕后一类问题设计的。它并不试图生成更精确的欺诈评分，而是将现有的评分通过五个协同工作的模块来展开调查：这些模块负责收集行为证据、整理认证记录、撰写案件总结，同时让分析人员能够用通俗的语言查询数据。
评分并非解释
许多欺诈检测系统在 0.87 这样的数值时就停止了分析。虽然其背后的模型在识别异常行为方面可能非常出色，但查看该数值的调查人员仍然无法了解究竟发生了什么，或是模型为何会如此反应。
如今有人填补了这一空白。他们打开账户，浏览交易记录，检查该设备是否曾出现过，阅读认证日志，将近期活动与历史模式进行对比，最后撰写案例说明以解释决策依据。
所有这些工作既缓慢又重复，而且当警报数量激增时就会陷入混乱。FraudLens 的理念就是保持欺诈检测模型的原有状态，自动处理模型发出警报后的调查工作。
五种智能体，五种职能
该平台将风险评分与调查任务分配给五个处理节点，每个节点负责的范围都很有限，就像欺诈处理团队中的各专业人员分工协作一样。
检测节点
评分工作由XGBoost分类器完成。该模型在公开的Kaggle信用卡欺诈检测数据集上进行了验证，该数据集包含284,807笔交易记录以及492起已确认的欺诈案件。验证结果如下：
| 指标 | 数值 | 通俗解释 |
|---|---|---|
| ROC-AUC | 0.985 | 几乎总能将欺诈行为识别为异常 |
| 欺诈检测精确度 | 82.8% | 大约每6次警报中有1次是误报 |
| 欺诈检测召回率 | 82.1% | 大约5起欺诈行为中有4起能被识别 |
| 欺诈检测F1值 | 82.5% | 上述两项指标的平衡值 |
那个真实世界的数据集仅用于验证检测模型，这一区别在下方会再次提及。
调查代理
当某笔交易达到调查阈值时，该代理会围绕该交易构建相关背景信息。它会查看以下内容：
- 账户行为及交易历史
- 与账户特征不符的金额
- 所在国家的行为特征及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 从不设置欺诈评分。这一设计能够解释确定性代码已经产生的结果，从而确保核心决策的可靠性，同时避免幻觉影响支付是否被标记的判定。
查询代理
分析人员可以输入诸如“显示来自尼日利亚的关键交易”之类的查询语句。该模型不允许运行任意代码或原始 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
数据检索过程安全、可预测，且易于审计。
架构与数据
整个系统以Docker中的Flask应用形式提供，实际演示在Render平台上运行，其容器架构同样可在Google Cloud Run上运行。
我们有意将性能测试结果与演示功能分开处理。Kaggle上的数据仅用于验证检测效果，这也是0.985的ROC-AUC数值的来源。实际调查流程则使用合成企业数据，因为匿名化的测试数据不包含设备历史、登录记录或账户关联等关系型字段。
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ 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 │
└───────────────────────────────────────┘
端到端流程
当分析师开始调查时，整个流程会按顺序执行：检测代理会对交易进行评分，调查代理会收集行为证据，日志分析代理会补充身份验证相关信息，解释代理则会撰写调查报告，最终结果会显示在案件仪表板上，供查询代理进一步分析。
设计为可优雅处理故障
AI API可能会遇到速率限制和网络错误。为避免这些问题导致应用崩溃，Gemini叙事服务与确定性处理流程是完全分离的。
如果未进行分离处理而导致双子座调用失败，页面就会因500错误而崩溃。而通过分离处理后，应用仍能返回所有核心风险指标、设备标识、行为偏差及日志详情，同时还会给出一条非阻塞提示，说明解释内容暂时无法提供。在最糟糕的情况下，依然会显示正常的调查控制面板，其功能仍可正常使用。
开发过程中的经验教训
- 数据方面要透明公开。将基准测试验证与模拟演示分开，能够赢得技术审核人员的信任，否则他们会对每一个数据数值产生质疑。
- 在代码中收集证据，并利用大语言模型进行推理。规则与数据聚合应体现在确定性代码中，而模型的任务则是将这些输出转化为自然的解释。
后续计划
- 使用 Google Cloud Pub/Sub 和 Dataflow 进行流式数据摄取，而非批量处理
- 利用 Google Cloud 中的 BigQuery 和 Firestore 实现原生数据持久化
- 运用图神经网络识别跨多个账户分布的欺诈团伙
- 整合多模态证据，将争议相关的 PDF 文件、身份证明文件及聊天记录输入 Gemini 的上下文之中
其背后的原理
模型输出分数并不意味着欺诈检测工作就此结束。关键在于确定哪些证据能解释该警报，以及分析师接下来应采取什么行动。FraudLens将这一流程清晰地划分开来：模型负责检测，确定性代码负责收集证据，专业人员负责调查，而大语言模型仅负责提供解释。
相关阅读
- 利用Antigravity管理型代理与GenAI SDK构建有状态远程沙箱 — 通过脚本驱动多轮交互式代理：保持远程Ubuntu沙箱运行状态，通过环境ID重新连接并下载工作区快照，附有两个实际案例。