从欺诈警报到受控行动：使用 TigerGraph 构建代理式欺诈调查系统
欺诈检测模型可以告诉您某笔交易看起来可疑。
它不一定会告诉调查员：
- 为什么它看起来可疑？
- 还有哪些实体与它相连？
- 证据是否足以支持行动？
- 还有哪些证据缺失？
- 系统是否应该请求更多信息？
- 政策实际上允许哪些行动？
- 谁需要批准该行动？
- 调查过程能否被记忆并在未来案件中使用？
对于 Hacker House Goa '26 任务 #4，我们构建了 HHGOA'26 — 代理式欺诈调查，这是一个基于图的调查系统，旨在回答这些问题。
核心思想很简单：
不要将欺诈警报视为结论。将其视为调查的开始。
我们的系统会接收初始欺诈信号，调查周围的图，收集并分类证据，就模式和风险进行推理，检测不确定性，在该证据实际上能够改变决策时请求额外证据，重新评估案件，最后生成符合政策的最佳后续行动。
随后，调查结果会被持久化存回 TigerGraph 作为机构记忆。
挑战
挑战数据集基于 Vesta Corporation 提供的 IEEE-CIS 欺诈检测数据集。
它大约包含：
- 590,000 笔卡交易
- 客户和身份信息
- 设备和连接信息
- 历史已闭合的调查
- 欺诈政策信息
- 已知欺诈模式
- 监管参考
- 20 个基准案例
基准故意不为每笔交易提供简单的 Is Fraud 答案。
这改变了问题。
我们不仅仅是在构建一个分类器。
我们正在构建一个 调查系统。
挑战要求代理调查案件，收集证据，识别欺诈模式，随着新证据的出现推进案件，推荐行动，并维护所需的调查记录。
提交内容还将在以下方面进行严格评估：
- 调查准确性
- 最佳后续行动
- 可解释性
- 代理式设计
- 工程实现
- 创新
- 演示质量
这促使我们采用一种架构，其中图不仅仅是可视化。
图是推理过程的一部分。
我们构建了什么
我们的调查流程如下：
重要的是，调查不必在第一次检索后结束。
如果证据不足，系统可以确定哪些额外信息会有用，以及获取这些信息是否实际上可能改变推荐的行动。
为什么选择 TigerGraph？
欺诈本质上是关系性的。
考虑一个交易：
孤立看起来正常的交易，在考虑其关系时可能会呈现出完全不同的面貌。
例如：
有趣的信号不一定位于单一行内。
它在于 关系结构。
我们的 TigerGraph 图包含八种顶点类型和十四种边类型，覆盖以下实体：
- 客户
- 卡片
- 交易
- 设备档案
- 电子邮件域
- 计费区域
- 已关闭案例
- 调查案例
调查使用 GSQL 和图检索来遍历这些关系。
例如：
- 交易历史
- 设备邻居
- 卡片活动窗口
- 交易身份信息
- 设备欺诈环关系
- 历史已关闭案例
- 之前的代理调查
- 模式和分析师笔记检索
这使得代理获得关系感知的上下文，而不是孤立的记录。
GraphRAG: 证据而非猜测
我们将 TigerGraph 用作调查证据的权威图层。
目标不是让 LLM 为可疑交易编造解释。
相反：
每个证据项都会获得一个标识符和一个声明类型。
我们使用三大类别：
观察到的事实
直接从底层数据中检索到的事实。
例如：
为该卡检索到 50 笔历史交易，平均交易金额为 109.08 美元。
推导推断
基于多个观察到的事实得出的结论。
例如：
该设备在多张卡之间共享，并与之前的确认欺诈案例相关联。
模型得分
上游欺诈模型的信号。
例如：
该交易获得了实时风险得分 0.90。
这种区分很重要，因为它可以防止推断得出的结论被当作直接观察到的事实呈现。
每个证据项还保留其来源/查询引用。
因此，调查可以回答：
"您为什么这么认为？"
如下：
"这里是图事实、产生它们的查询以及基于这些事实的推理。"
代理部分
我们刻意避免构建一种工作流，在这种工作流中，每个案例只是简单地执行完全相同的查询列表。
我们的架构使用 混合规划器。
规划器既是确定性的，又具备状态感知。
它从基线调查工具开始，随后根据未覆盖的证据空白选择额外的检索。
例如：
具体使用的工具取决于当前案例的状态。
与设备相关的证据空白可以触发设备遍历。
在线活动信号可以触发速度分析。
新区域信号可以触发区域窗口分析。
这意味着调查路径在不同案例之间可能有所不同。
每个计划都会记录在案例的计划追踪中，包括：
- 所选工具
- 证据空白
- 理由
这使得调查路径可审计。
在此架构中，LLM 是可选的。
配置后，它用于合成和叙事解释，而不是被赋予对关键工具选择或策略执行的无限制控制。
这是一种有意的设计选择。
在欺诈调查中，我们希望推理系统保持灵活，同时使关键控制保持确定性和可审计性。
风险不仅仅是一个数字
另一个设计决定是避免将欺诈概率视为一个未解释的黑箱。
我们实现了一个可解释的 Noisy-OR 风险分解。
总的欺诈概率由多个风险渠道构成。
例如：
- 交易速度
- 网络/卡关联
- 设备异常
- 地理位置距离
- 欺诈集团成员身份
- 之前的代理调查记忆
- 额外证据结果
- 历史清算信号
因此，调查员可以看到不仅仅：
Fraud Probability: 0.94
但也包括对该评估有贡献的证据渠道。
当案件处于边界情况时，这一点特别有用。
0.53 的概率不应与 0.96 的概率看起来完全相同。
周围的证据很重要。
最重要的部分：不确定性
系统最强的部分之一是不确定性循环。
自动化决策系统常见的失效模式是：
Risk score
↓
Decision
我们想要的是：
Risk
↓
Is the evidence sufficient?
↓
If not:
What information would actually change the decision?
↓
Request that evidence
↓
Reassess
↓
Decision
系统因此会评估候选证据请求。
例如：
- 客户验证
- 步进认证
- 分析师信息
- 外部监控名单信息
但它不会自动请求所有内容。
每个候选项都会根据预期决策影响进行评估。
系统会比较合理的结果并提出：
如果我们获得此信息，结果决策实际上会改变吗？
如果答案实际上是否定的，则可以抑制该请求。
这可以防止不必要的证据收集。
一个真实的例子：HHG-014
HHG-014 是不确定性重要性的一个很好的例子。
该案例涉及卡片 C13487-K1 的交易 3478561。
图形显示：
- 账户的新设备
- 匿名/代理连接
- 该设备在其他 19 张卡片之间共享
- 与该模式相关的先前案例
- 多个图形派生的证据片段
初步评估为：
Fraud Probability: 0.528
Verdict: Uncertain
Pattern: card_not_present_new_device
系统并不是简单地把图证据转化为欺诈裁决。
相反，它将customer validation视为最高价值的额外证据请求。
其信息价值的计算方式为：
1.00
替代方案的信息价值较低：
Step-up authentication: 0.45
Analyst information: 0.45
External watchlist: 0.40
基准执行中的客户响应为：
在24小时窗口内未收到任何响应。
系统随后重新评估了该案例。
最终状态仍然不确定，建议的操作也发生了变化。
初始建议包括：
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS
证据循环结束后：
MONITOR_CARD
DECLINE_TRANSACTION
对于该下降，采用了适当的批准路径。
重要的不是系统变得更加激进。
重要的观点是：
建议的改变是因为证据的状态发生了变化。
这就是我们希望从一个具代理性的调查系统中看到的行为。
一个典型的欺诈案例：HHG-006
HHG-006 展示了相反的情况。
图表显示：
- 客户报告的未授权活动
- 48 小时内的四笔在线交易
- 一台新设备
- 该设备在其他 20 张卡之间共享
- 与客户/卡相关的先前确认的欺诈案例
- 同一设备在确认的欺诈案例中出现
- 客户进一步确认这些购买不是他们所为
得到的欺诈概率为：
0.96
最终的操作集包括：
BLOCK_CARD
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS
策略引擎将高影响力的操作按照必需的审批层级进行路由。
系统还生成了所需的 SAR 记录。
这说明了以下几点之间的区别：
"the model thinks this is suspicious"
以及：
"the investigation has gathered enough independent evidence
to justify a governed action."
账户劫持：HHG-019
我们还希望系统能够超越单一预定义的欺诈模式进行推理。
HHG-019 被识别为：
account_takeover
调查发现：
- 新设备
- 多张关联卡
- 客户/卡此前的确认欺诈案例
- 在确认的欺诈案例中出现的同一设备
- 客户确认这些交易未获授权
最终欺诈概率为：
0.94
所产生的操作包括：
BLOCK_CARD
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS
该图让系统能够把当前交易与历史行为关联起来，而不是单独评估该交易。
下一步最佳行动受到管控
另一个重要的架构决策是进行分离：
AI recommendation
来自：
policy enforcement
代理可以推荐一个操作。
它不能直接执行它所推荐的任何操作。
我们的流程如下：
操作按照权限级别进行分类。
自动
用于影响较低的操作，例如：
- 创建案例
- 客户通知
- 监控
L1
需要分析师或团队负责人的授权。
例如，依据政策条件，可能包括交易拒绝和卡片封锁操作。
L2
需要更高层次的欺诈或合规授权。
例如，包括某些 SAR 报告操作。
决策制定时，会根据政策重新验证批准决策。
系统会记录诸如下列审计事件：
approval_granted
action_executed
approval_rejected
这造成了以下分离：
代理推荐的内容
和
组织允许的内容。
案例记忆
欺诈调查不应在案件结束时消失。
我们因此将完成的调查以 InvestigationCase 顶点的形式持久化存储在 TigerGraph 中。
案例与以下相关实体相连：
- 客户
- 卡片
- 交易
- 设备
未来的调查可以检索以前的代理调查。
这意味着系统具有一个记忆循环：
这在欺诈场景中特别有价值，因为重复模式经常出现在看似无关的交易中。
故障关闭图操作
我们认为重要的工程需求之一是防止 UI 声称在 TigerGraph 上进行了调查，而实际上图后端不可用。
在严格模式下：
STRICT_GRAPH_BACKEND=1
如果无法连接到权威的 TigerGraph 后端，系统会明确失败。
它不会在将调查呈现为成功时，悄悄用模拟数据替换真实的图证据。
对于竞赛演示，这一区别很重要。
图调查应当要么基于图本身，要么明确报告图不可用。
分析师指挥中心
后端仅是产品的一半。
我们构建了一个面向分析师的指挥中心，以可视化故事的形式呈现调查。
界面呈现：
- 触发上下文
- 调查进展
- 欺诈概率
- 检测到的模式
- 图拓扑
- 证据及其来源
- 不确定性
- 风险分解
- 受管控的 NBA
- 批准状态
- 案例记忆
- 基准验证
图的设计旨在以可视化方式回答一个简单的问题：
Why is this transaction connected to suspicious activity?
与其让分析师去理解原始的图谱模式名称，可视化更侧重于：
最终的视觉方案采用了受 Hacker House Goa 启发的克制深绿与米色配色，界面聚焦于调查，而非沦为活动落地页。
基准测试结果
我们参照官方的 20 案例基准测试，评估了完整的流水线。
仓库的基准报告记录如下：
系统测试
仓库的技术验证报告如下：
228 tests
228 passed
0 failed
0 skipped
测试套件涵盖以下领域：
- API 行为
- 前端/API 集成
- 图数据库后端
- GraphRAG
- LLM 层
- MCP 客户端
- 调查加固
- 策略审批
- 实时 TigerGraph 代理行为
- 证据溯源
- 数据模型
- NBA 解释
- 模式推理
- 策略引擎
我们还通过基于浏览器的端到端测试验证了应用。
测试的行为包括：
- 实时调查执行
- 调查进展
- 证据溯源
- Noisy-OR 分解
- 不确定性与重新评估
- NBA 治理
- 审批门控
- 图交互
- 节点检查
- 响应式布局
- 浏览器控制台健康状况
我们学到了什么
1. 当调查需要关系时，图最有用
单笔欺诈交易本身包含的上下文有限。
围绕它的关系可以提供更多有用的证据。
TigerGraph 让这些关系在调查过程中可直接查询。
2. 更多证据并不总是更好
不断提问的代理并不一定智能。
重要的问题是：
此证据会改变决策吗？
这促使我们实施了基于信息价值的证据请求。
3. 风险与行动应当分离
高风险分数并不自动意味着：
BLOCK CARD
该操作还取决于：
- 证据
- 不确定性
- 政策
- 暴露
- 批准要求
将风险评估与政策执行分离使得架构更易于审计。
4. 代理系统需要停止标准
调查不应永远继续。
我们在以下方面实施了停止条件：
- 足够的置信度
- 不确定性
- 证据可用性
- 信息价值
- 最大调查轮数
目标不是最大化检索。
目标是：
足够的证据以作出可辩护的决定。
5. 内存需要成为图的一部分
如果之前的调查与当前的调查脱节，系统会反复解决同一问题。
Persisting InvestigationCase back into TigerGraph allows future investigations to use previous cases as structured evidence.
6. 确定性控制在高影响工作流中很有价值
我们刻意将关键的工具规划和政策决策保持在受控状态，而不是赋予 LLM 无限制的权限。
系统可以使用 AI 进行综合和解释，而确定性组件处理：
- 证据计算
- 政策评估
- 权限路由
- 批准执行
- 持久化规则
这为我们在灵活性和控制之间提供了有用的平衡。
如果有更多时间，我们将改进的内容
当前系统是一个竞赛原型，而不是生产级的欺诈平台。
我们将在以下几个方面进行改进。
1. 更多样化的欺诈模式
基准包含有限的案例集和已记录的模式。
生产系统需要更广泛的覆盖：
- 新兴欺诈类型
- 跨账户攻击
- 骡子网络
- 合成身份
- 协调的活动
2. 更多外部证据来源
The current system focuses heavily on TigerGraph and controlled investigation evidence.
生产部署可以集成以下额外内容：
- 身份信号
- 认证遥测
- 设备情报
- 商户信息
- 威胁情报
- 外部监控名单
3. 更好的图形可视化
当前图展示了拓扑结构，但生产级分析师界面可以提供：
- 语义图布局
- 关系过滤
- 时间图回放
- 欺诈环高亮
- 路径解释
- 已保存的调查视图
4. 更高级的行动优化
当前的 NBA 系统受政策管控并经过基准测试。
未来版本可以使用以下因素来优化行动：
- 预期财务损失
- 客户摩擦
- 运营成本
- 干预成功率
- 历史行动结果
同时仍保持政策执行的独立性。
5. 生产级认证和部署
竞赛原型专注于调查工作流。
生产版本将需要：
- 身份和访问管理
- 基于角色的权限
- 审计保留
- 密钥管理
- 部署自动化
- 可观测性
- 高可用性
- 数据治理
- 合规控制
架构一览
整个系统可以概括为：
最终要点
构建此系统的最大教训是，欺诈调查不仅仅是一个分类问题。
它是在不确定性和政策约束下，基于关联证据的 推理问题。
系统需要知道：
What happened?
↓
What is connected?
↓
What evidence supports it?
↓
What is still uncertain?
↓
What information would resolve that uncertainty?
↓
How does the decision change?
↓
What action is appropriate?
↓
Is that action permitted?
↓
Who must approve it?
↓
What should the system remember?
这就是我们为 TigerGraph 设计的角色。
图提供了关联的上下文。
调查引擎决定调查什么。
证据层使推理过程可追溯。
不确定性循环决定何时更多信息有价值。
策略引擎限制行动。
审批层让人类保持对重大决策的控制。
而且 TigerGraph 不仅仅是一个数据库：它成为调查系统的持久内存和关系层。
欺诈检测会给出一个信号。
调查将该信号转化为证据。
代理推理将证据转化为决策。
治理将决策转化为受控行动。
项目
HHGOA'26 — 代理欺诈调查
任务 #4 — TigerGraph 代理欺诈调查 + 下一步最佳行动
使用以下技术构建：
- TigerGraph Savanna Cloud
- GSQL
- GraphRAG
- Python
- FastAPI
- HTML/CSS/JavaScript
- D3.js
- SQLite
- pytest
完整的实现、基准工件、架构文档、演示演练和测试套件均可在项目仓库中获取。
仓库： github.com/shaikmohammedyasin-create/HHGoa26-Agentic-Fraud-Investigation
致谢
此项目是为 Hacker House Goa '26 和 TigerGraph 代理欺诈调查挑战而构建的。
此挑战让我们有机会探索当图数据库、代理调查、证据驱动推理、不确定性处理和政策治理结合到一个工作流程时会发生什么。
结果并非旨在取代人类调查员。
它旨在为他们提供更好的调查轨迹：
关联证据、显式不确定性、受控行动和持久内存。
© 2026 SK MD Yasin. 保留所有权利。
本文及随附的 HHGOA'26 — 代理欺诈调查项目是为 Hacker House Goa '26 TigerGraph 代理欺诈调查挑战赛而创建的。除非另有注明，内容、架构图和案例均为原创作品。第三方商标（TigerGraph、IEEE‑CIS、Vesta 等）归其各自所有者所有，此处仅作描述性引用。
