构建 RAVEL：用 TigerGraph Cloud 与 Agentic GraphRAG 检测复杂欺诈团伙

TigerGraph Hacker House Goa — Agentic Fraud Investigation Challenge Team / Co-Authors: Nikhil Kumar Panigrahi & Sai Manohari Godavarty Live Workstation: https://ravel-u8sl.onrender.com/ GitHub Repository: https://github.com/nikhilkumarpanigrahi/Ravel Video Walkthrough: https://drive.google.com/file/d/1RPplFn7suYCryYVRs8_xCaBcBLqq7cZU/view?usp=sharing Core Architecture: TigerGraph Cloud (release_4.2.5), Compiled C++ GSQL, FastAPI, LangGraph, Cytoscape.js Quick Summary: What We Built For the TigerGraph Hacker House Goa Challenge, my teammate Sai Manohari Godavarty and I set out to tackle a problem that fraud analysts deal with every single day: coordinated payment fraud rings. In real-world fraud operations, investigators spend 30 to 45 minutes on every single suspicious transaction. They have to jump across multiple tools, cross-reference IP logs and hardware fingerprints, trace transaction histories across accounts, and draft compliance narratives. By the time someone connects the dots manually, the fraudulent funds have already moved. To fix this operational lag, we built RAVEL (Relational Active Valuation and Evidence Loop). It is an autonomous forensic investigation workstation that combines: TigerGraph Cloud (release 4.2.5) running compiled C++ GSQL queries for sub-second multi-hop graph traversals. Shannon Entropy Active Learning so the agent mathematically knows when it has enough evidence to stop investigating instead of burning LLM tokens. A 3D Pareto Counterfactual Simulator that balances loss prevention against customer friction. An Automated FinCEN SAR Generator backed by dual-key human approval (L1 Fraud Lead and L2 Risk Manager). An interactive Cytoscape.js graph canvas built directly into the analyst workstation. Key Results Across 20 IEEE Benchmark Cases Forensic Metric RAVEL Performance Standard Tabular / LLM Impact & Value Fraud Exposure Protected $4,727.17 $0.00 (Undetected) 100% ring recovery across all 20 challenge cases Policy Conformity 100.0% (8/8 Rules) ~65.0% Zero regulatory or bank policy breaches Hallucination Rate 0.0% >15.0% 100% of facts grounded in GSQL graph paths Multi-Hop Traversal Speed 0.238 seconds 24.2 seconds ~100x faster retrieval with compiled GSQL Automated Test Coverage 66 / 66 Passing N/A Full unit, graph adapter, and state machine tests The Investigation: Inside Case HHG-020 and the 125 Dollar Alert To see why graphs are necessary here, look at how standard fraud systems evaluate transactions. Take Case HHG-020 directly from the IEEE-CIS challenge pack: { "transaction_id": 3509359, "customer_id": "C12265", "card_id": "C12265-K2", "amount": 125.08, "risk_score": 0.52, "channel": "online" } Enter fullscreen mode Exit fullscreen mode If you feed this record into standard tabular models like XGBoost or a plain LLM prompt: The transaction amount is 125.08 USD (a standard everyday purchase). The real-time risk score is 0.52 (well below typical 0.70 automatic decline rules). The cardholder has not filed a dispute yet. To a tabular system, this alert looks completely normal. The Hidden Connection When we ran a 4-hop graph traversal in TigerGraph on Customer C12265, the topology showed something completely different: [Customer C12265] --> [Txn 3509359] --> [Device DEV-91024] | +-------------------+------------------+-------------------+ | | | | [Txn 3508112] [Txn 3508189] [Txn 3509001] ... 32 More | | | | [Card C8891-K1] [Card C4412-K3] [Card C9901-K1] [35 Cards Total] Enter fullscreen mode Exit fullscreen mode Caption: Case HHG-020 — Interactive TigerGraph multi-hop traversal in the RAVEL canvas uncovering the 35-card device collusion ring. That single 125 dollar purchase was part of a coordinated bot operation running across 35 compromised payment cards on the exact same physical hardware device. Traditional databases store transactions in flat rows. Flat tables have no concept of relational topology. If your retrieval mechanism cannot see connections between entities, even the largest language model in the world will miss the fraud ring. You do not need a larger model; you need a graph. Comparing the Three Investigation Approaches To understand the difference in architecture, we benchmarked three common approaches against the same 20 IEEE fraud cases: +-------------------------------------------------------------------------------------------------------------+ | THE THREE INVESTIGATION PIPELINES | +------------------------------+---------------------------------------+--------------------------------------+ | Pipeline 1: LLM-Only | Pipeline 2: Basic Vector RAG | Pipeline 3: RAVEL (TigerGraph) | | Baseline Prompting | Vector Search + Context Dump | Compiled GSQL + Active Learning | +------------------------------+---------------------------------------+--------------------------------------+ | - Relies on pre-trained bias | - Pulls text chunks by similarity | - Traverses explicit multi-hop edges | | - Zero relational awareness | - High token usage from context bloat | - 100x speedup via compiled C++ GSQL | | - Frequent hallucinations | - Misses multi-customer collusion | - Exact citation and graph paths | | - Fails on complex rings | - Slow and expensive per query | - Deterministic 14-state governance | +------------------------------+---------------------------------------+--------------------------------------+ Enter fullscreen mode Exit fullscreen mode Pipeline 1: LLM-Only Baseline Here, you pass the transaction JSON to an LLM and ask it whether the transaction is fraudulent. Without external retrieval, the model guesses based on prompt semantics. It hallucinates nonexistent card patterns and cannot legally justify freezing an account or filing a compliance report. Pipeline 2: Basic Vector RAG Here, transaction histories and customer notes are converted into text chunks and retrieved via cosine similarity. Vector search finds semantic text similarity, not relational topology. Searching for "high velocity electronics purchase" returns dozens of unrelated customers buying gadgets, but it cannot answer: "Find all payment cards used on any device linked to Customer X in the last 48 hours." The prompt gets flooded with irrelevant tokens while the actual ring goes undetected. Pipeline 3: RAVEL (TigerGraph GraphRAG) TigerGraph models entities explicitly as Customer, Card, Transaction, Device, BillingRegion, and FraudCase vertices. The agent queries compiled GSQL procedures on demand, measures hypothesis uncertainty using Shannon Entropy, and backs every finding with an auditable graph path. In 0.238 seconds, TigerGraph isolates the 35-card ring and hands structured evidence to the LLM to draft a formal FinCEN Suspicious Activity Report. Performance Comparison Matrix Evaluation Metric Pipeline 1 (LLM-Only) Pipeline 2 (Basic Vector RAG) Pipeline 3 (RAVEL / TigerGraph) Multi-Hop Ring Detection Fails (0%) Fails (Vector blindness) Verified (4 hops in 0.238s) Evidence Citation Coverage 0.0% 42.5% (Vague text chunks) 100.0% (Exact Graph Vertices) Hallucination Rate 38.0% 14.5% 0.0% (Strictly Grounded) Query Latency ~2.5s ~7.8s (Vector scan + LLM) 0.238s (Compiled C++ GSQL) Token Cost per Case Baseline (~1k tokens) High (~9.5k tokens) Controlled (~1.8k tokens) Regulatory SAR Compliance None (0%) Partial notes (30%) Fully Compliant (FinCEN 31 USC 5318g) Human-in-the-Loop Governance None None Dual-Key L1/L2 Approval Drawer System Architecture: The Active Learning Loop Instead of running an open-ended prompt chain that risks looping indefinitely, RAVEL operates an active learning loop guided by a 14-state deterministic state machine: flowchart TD subgraph IntakeStage ["1. Alert Intake and Seeding"] A["Payment Alert Event(Risk Score, Denial, Channel)"] --> B["Case Dossier Seeder(Extract Target and Entity IDs)"] B --> C["Prior Belief Baseline(Compute Initial P0 Fraud)"] end subgraph ActiveCore ["2. TigerGraph Active Intelligence Engine"] C --> D["Shannon Entropy Evaluator(Quantify Uncertainty)"] D --> E{"Is Uncertainty Settled?H(S) F["Value of Information (VoI)Rank Queries: E[Loss] - Cost"] F --> G[("TigerGraph CloudCompiled C++ GSQL Multi-Hop")] G --> H["Bayesian Belief Shift(Update Posterior Likelihood)"] H --> D end subgraph GovernanceStage ["3. Resolution and Governance"] E -- "YES: Decision Ready" --> I["3D Pareto Counterfactual Engine(Loss vs Friction vs Compliance)"] I --> J["Bank Policy Rules (R1-R8)(Determine Next-Best Action)"] J --> K{"Dual-Key GateHuman Approval Needed?"} K -- "High Impact" --> L["Analyst Approval Drawer(Human-in-the-Loop L1/L2)"] K -- "Pre-Authorized" --> M["Action Execution(BLOCK_CARD, DECLINE_TXN)"] L --> M M --> N["FinCEN SAR Synthesis(31 U.S.C. 5318g)"] N --> O[("TigerGraph Case MemoryWrite-Back FraudCase Vertex")] end The 14-State Finite State Machine In banking operations, an AI agent cannot be an unpredictable black box. RAVEL enforces strict deterministic state progression: TRIGGERED -> CASE_CREATED -> INVESTIGATING -> EVIDENCE_COLLECTED -> ASSESSING -> EVIDENCE_REQUESTED -> EVIDENCE_RECEIVED -> REASSESSING -> POLICY_EVALUATION -> ACTION_PROPOSED -> APPROVAL_PENDING -> ACTION_EXECUTED -> CASE_CLOSED -> MEMORY_UPDATED Enter fullscreen mode Exit fullscreen mode Caption: The RAVEL 14-State Autonomous Lifecycle Trace — providing deterministic finite state orchestration and an auditable transition log for every investigation. If an action involves high financial or customer impact (like freezing an enterprise card or filing a federal report), the state machine halts in APPROVAL_PENDING until an analyst signs off in the workstation drawer. How TigerGraph is Used: The 100x Speedup Story TigerGraph serves as the primary computational engine in RAVEL. Our graph is hosted on TigerGraph Cloud (release 4.2.5) using the FraudDetectionGraph schema: +----------------------------------------------------------------------------------------+ | TIGERGRAPH GRAPH SCHEMA | +-----------------------+-----------------------------+----------------------------------+ | Vertex Type | Primary Key | Key Attributes | +-----------------------+-----------------------------+----------------------------------+ | Customer | id (STRING) | name, risk_score | | Card | id (STRING) | card_type, expiration, status | | Transaction | id (STRING) | amount, timestamp, channel, score| | Device | id (STRING) | device_fingerprint, ip_address | | BillingRegion | id (STRING) | region_code, risk_multiplier | | FraudCase | id (STRING) | verdict, confidence, sar_filed | +-----------------------+-----------------------------+----------------------------------+ Enter fullscreen mode Exit fullscreen mode The Multi-Hop Latency Bottleneck When we first built our prototype on day one, we queried TigerGraph using sequential REST++ endpoint calls: Call Customer endpoint to get connected transactions (~350ms). Call Transaction endpoint for 15 individual transactions (~5,250ms). Call Device endpoint to fetch hardware fingerprints (~4,500ms). Query edges to find colluding accounts (~14,000ms). Total latency per case was 24.44 seconds. Because our agent performs three to four exploratory steps during an investigation, analyzing a single case took over two minutes. That would never work in production. Compiling GSQL into Native C++ TigerGraph's core architectural advantage is that GSQL queries can be installed directly into the Graph Processing Engine (GPE), which compiles them into native C++ shared objects: USE GRAPH FraudDetectionGraph CREATE OR REPLACE QUERY shared_devices(VERTEX cust, INT lim = 50) FOR GRAPH FraudDetectionGraph SYNTAX v2 { C = {cust}; # Hop 1: Customer -> All Historical Transactions Txns = SELECT t FROM C:c -(transaction_of_customer:e)- Transaction:t; # Hop 2: Transactions -> Hardware Device Profiles Devs = SELECT d FROM Txns:t -(transaction_uses_device:e)- Device:d; # Hop 3: Devices -> Other Connected Transactions OtherTxns = SELECT t2 FROM Devs:d -(transaction_uses_device:e)- Transaction:t2; # Hop 4: Connected Transactions -> Colluding Customers OtherCust = SELECT c2 FROM OtherTxns:t2 -(transaction_of_customer:e)- Customer:c2 WHERE c2 != cust LIMIT lim; PRINT Devs, OtherCust; } INSTALL QUERY shared_devices; Enter fullscreen mode Exit fullscreen mode Running INSTALL QUERY compiles the GSQL procedure into machine code. The latency improvement was immediate: +---------------------------------------------------------------------------------------+ | TIGERGRAPH LATENCY BENCHMARK | +------------------------------------+-----------------------+--------------------------+ | Operation | Before (REST++ Loop) | Now (Compiled C++ GSQL) | +------------------------------------+-----------------------+--------------------------+ | shared_devices (4-Hop Ring) | 24.44 seconds | 0.238 seconds (100x) | | card_window (Time-Windowed Txns) | 4.10 seconds | 0.237 seconds (17x) | | card_history (Customer Txn Stream) | 4.14 seconds | 1.207 seconds (3.5x) | | Total Case Investigation | ~166 seconds | ~39 seconds (4.2x) | +------------------------------------+-----------------------+--------------------------+ Enter fullscreen mode Exit fullscreen mode Dropping latency from 24.44 seconds down to 0.238 seconds gave our agent the throughput to perform live multi-hop forensics within real-time SLA limits. Agentic Capabilities Implemented 1. Mathematical Uncertainty: Shannon Binary Entropy Many autonomous agents run into issues because they lack a defined stopping condition. They either make premature guesses or loop indefinitely calling tools. RAVEL quantifies hypothesis uncertainty using Shannon Binary Entropy: H(S) = -p * log2(p) - (1 - p) * log2(1 - p) Enter fullscreen mode Exit fullscreen mode Where p is the posterior probability: P(Fraud | Evidence). When p = 0.50 (Complete Ambiguity): H(S) = 1.00 bit. The agent cannot decide and must collect more data. When p = 0.95 (Strong Evidence): H(S) = 0.28 bits. Confidence is high. When p >= 0.97 (Defensible Boundary): H(S) float: """Calculate Shannon binary entropy in bits.""" if p = 1.0: return 0.0 return -p * math.log2(p) - (1 - p) * math.log2(1 - p) Enter fullscreen mode Exit fullscreen mode To choose the next step, our Value of Information (VoI) optimizer ranks potential inquiries: VoI = Expected_Loss_Reduction - Inquiry_Friction_Cost Enter fullscreen mode Exit fullscreen mode The agent dispatches a query only if the expected drop in uncertainty outweighs the friction cost. Once uncertainty reaches H(S) = 90% 100.0% (20/20 cases aligned to R1-R8) Complete Pattern Consistency Rate >= 90% 100.0% (Mathematical alignment) Complete Evidence Citation Coverage >= 80% 100.0% (All findings cite graph paths) Complete Total Exposure Protected Baseline 4,727.17 USD Maximized Compiled GSQL Traversal 80% 66 / 66 Passing (100% pytest suite) Verified Caption: The RAVEL Executive Benchmark Matrix — full 20-case evaluation proving 100% policy conformity, 4,727.17 USD in fraud exposure protected, and zero hallucinations. What We Learned Topology Matters More Than Model Parameter Count: A large language model cannot deduce that 35 credit cards share a single device if the database only returns flat rows. Relational graph topology in TigerGraph is what reveals collusion; the language model is best used for reasoning over structured subgraphs, synthesizing evidence, and drafting regulatory filings. Compiled Queries are Essential for Production AI: In agentic workflows where models make sequential tool decisions, high database latency slows the whole pipeline down. Compiling GSQL queries into native C++ reduced multi-hop lookups from 24.4s to 0.238s, making real-time investigation viable. Information Theory Prevents Uncontrolled Agent Loops: Giving an LLM open-ended tool access leads to token waste and circular reasoning. Formalizing stopping boundaries with Shannon Entropy (H(S) <= 0.22 bits) ensures the agent investigates thoroughly when uncertain, but stops immediately once the evidence is clear. Human Oversight is Non-Negotiable in Banking: Financial institutions cannot deploy autonomous systems that block accounts with zero human governance. Gating high-impact interventions behind dual-key L1/L2 approval queues bridges the gap between agentic speed and regulatory accountability. What We Would Build With More Time Real-Time Kafka Streaming Ingestion: Connect TigerGraph's GSQL loading pipeline directly to an Apache Kafka transaction stream, triggering RAVEL investigations within milliseconds of an authorization request. In-Database Graph Data Science Embeddings: Run TigerGraph Graph Data Science algorithms (such as FastRP, Louvain Community Detection, and Node2Vec) directly in-database to generate dynamic risk embeddings on topology. Two-Way Cardholder Communication Webhooks: Integrate live Twilio webhooks so the agent can dispatch real-time SMS two-factor verification challenges directly to cardholders during active investigations. Distributed Celery Worker Queues: Scale investigation workloads horizontally across a distributed Kubernetes cluster to handle peak transaction spikes during high-volume shopping events. Team and Engineering Contributions Contributor Focus Area Key Architectural Deliverables Nikhil Kumar Panigrahi GitHub: nikhilkumarpanigrahi Core Engine & Graph Architecture Active Learning (Shannon Entropy stop condition), GSQL Query Compilation, Bayesian Belief Updating, 3D Pareto Counterfactual Simulator, and Bank Policy Governance (Rules R1 through R8). Sai Manohari Godavarty GitHub: saimanoharigodavarty Forensic UI & Systems Optimization Full-Stack Analyst Workstation, Cytoscape.js Interactive Graph Canvas with dynamic ring layouts, Cloud Latency Tuning, and LangGraph 14-State Machine Workflow. A big thank you to the TigerGraph team for hosting the TigerGraph Hacker House Goa, providing access to TigerGraph Cloud and Savanna, and organizing a challenging, realistic fraud problem. Tagging @TigerGraphDB on LinkedIn and X. Launchpad & Quick Links Resource Link Description Live Workstation ravel-u8sl.onrender.com 24/7 cloud deployment connected to live TigerGraph Cloud GitHub Repository nikhilkumarpanigrahi/Ravel Complete open-source codebase (MIT License) Video Walkthrough Watch on Google Drive Full end-to-end investigation and dual-approval walkthrough If you find this project interesting, please star the repository on GitHub and share your thoughts in the comments below!