CRM Nexus · TigerGraph × GraphRAG Inference

Stop paying for tokens your LLM doesn't need.

🧠 Smarter ⚡ Faster 💰 Cheaper

A Fastify + TigerGraph system that maps a 158M-token synthetic CRM into a knowledge graph, walks entity relationships via GSQL, and feeds the LLM only what matters — 96.7% accuracy at 86% fewer tokens than flat vector search.

158M

Tokens Processed

35,820

Entities

195,133

Graph Edges

Eval Questions

1.58×

Hackathon Min

One synthetic CRM. Three pipelines. Same Gemini 2.5 Flash brain. TigerGraph answered 87/90 — BasicRAG managed 71.1%.

Accuracy

87 / 90 questions

Fewer tokens

vs BasicRAG baseline

Faster

7,495ms vs 9,090ms

0.00

BERTScore F1

raw 0.932 · rescaled 0.599 ✓

The Problem

AI costs scale with tokens. Most RAG systems waste them.

Every query you send to an LLM is a bill. The bigger the context, the bigger the invoice. Classic RAG — vector search over a flat document store — can't tell the difference between a needle and a haystack. It grabs whatever looks similar and dumps it all in the prompt. At enterprise scale, that's thousands of wasted tokens, per query, per second, forever.

😩

Step 1 — The Problem

AI bills compound fast

You ask: "Who owns the Acme Corp deal?" Your LLM needs maybe 3 sentences of CRM data to answer. But your RAG system doesn't know that — so it retrieves chunks by similarity, burns 10,867 tokens, and costs you $0.0076 per question.

→

🔍

Step 2 — The Insight

CRM data is a graph

Every CRM entity has relationships: Deals connect to Contacts, Contacts belong to Accounts, Accounts sit in Territories. That's not a flat list — it's a knowledge graph waiting to be traversed. TigerGraph can walk those edges in milliseconds.

→

⚡

Step 3 — CRM Nexus

Graph traversal. Surgical context.

GSQL multi-hop query: Customer → Vendor → Outage → Region. Returns exactly the entity context. ~1,483 tokens. $0.000074 per question. Same LLM. Same accuracy. 86% cheaper.

Cost Per Query

Ring fill = cost proportion relative to BasicRAG's baseline spend.

₹0.125

BasicRAG

₹0.017

CRM Nexus

CRM Nexus costs 86% less per query — 1,483 input tokens via TigerGraph graph traversal vs 10,867 from flat vector search. Same Gemini 2.5 Flash output.

Section 02

Head-to-Head: 90-Question CRM Benchmark

Same LLM (Gemini 2.5 Flash). Same 90 questions. Only the retrieval layer changes.

Accuracy

Percentage of the 90 evaluation questions each pipeline answered correctly.

GraphRAG (TigerGraph)

96.7%

Basic RAG (Vector Only)

71.1%

LLM Only

3.3%

Minimum useful · 50%

GraphRAG answered 87/90 (96.7%); BasicRAG managed 71.1% — a 25-point gap on the same data, with the same LLM. Flat search can't follow relationships.

Token Usage Per Question

Prompt tokens, questions 1 → 90.

86% fewer tokens — every single question

Correct Answers

Questions each pipeline answered correctly out of 90.

87/90

GraphRAG

64/90

BasicRAG

GraphRAG correctly answered 87 of 90 questions. BasicRAG — with the same data available — answered only 64. The gap is structural: flat similarity cannot traverse entity relationships.

Latency

Average end-to-end response time across all answered questions.

9,090ms

BasicRAG · avg response time

17.5% FASTER →

0.932 BERTScore F1 (raw)

7,495ms

GraphRAG · avg response time

BERTScore — roberta-large · HuggingFace bert_score · rescale_with_baseline=True

Pipeline	F1 rescaled (bar ≥ 0.55)	F1 raw (bar ≥ 0.88)
GraphRAG	0.599 ✓	0.932 ✓
BasicRAG	0.454	0.908
LLM Only	0.089	0.846

GraphRAG clears both bonus thresholds — rescaled ≥ 0.55 ✓ and raw ≥ 0.88 ✓ — maximum accuracy bonus secured.

Section 03

AI-Factory 4-Layer Architecture

From question to verified answer — every layer is decoupled, swappable, and instrumented.

Layer 01

Graph

TigerGraph Community Edition

35,820 vertices · 195,133 edges
HNSW vector index
GSQL multi-hop traversal
Customer → Vendor → Outage → Region

retrieval

→

Layer 02

Orchestration

Node.js · Fastify

Query classification
Vector seed → 3-hop GSQL
Chunk assembly
Prompt construction

prompt

→

Layer 03

LLM

Google · Gemini 2.5 Flash

~1,483 prompt tokens / Q
Google AI API
Streaming completions
max_tokens: 300

grade

→

Layer 04

Evaluation

Groq · Llama 3.1 8B · bert_score roberta-large

Independent judge model
PASS / FAIL per question
BERTScore F1 raw = 0.932 ✓
90-Q benchmark, v6

// multi-hop graph traversal — the engine behind 96.7% accuracy
CREATE QUERY getRelevantContext(STRING entity_id, INT k) {
  Start = {entity_id};
  L1 = SELECT t FROM Start:s -(ANY:e)-> :t LIMIT k;
  L2 = SELECT t FROM L1:s    -(ANY:e)-> :t LIMIT k;
  PRINT L1, L2;
}
    

multi-hop GSQL traversal — the engine behind 96.7% accuracy

Section 04

The Data: Real Complexity, Real Scale

5,000 customers with health scores, ARR & renewal dates. 25,000 support tickets linked to outages and vendors. 5,000 compliance cases. 500 employees across regions. 100 outages with severity & impact data. 50 vendors with SLA tiers. 150 active projects. Every entity linked — built specifically to make flat vector search fail and graph traversal win.

⬇ Download Dataset · GitHub Release v2.0

View on GitHub

100,820 documents · 158M tokens · JSONL format, one document per line

158M

Tokens

1.58× the hackathon's 100M minimum

35,820

Vertices

across 8 entity types

195,133

Edges

12 relationship types

Eval Questions

single hop · multi hop

Entity Breakdown

Tickets

25,000

Customers

5,000

Compliance

5,000

Employees

500

Outages

100

Vendors

Every entity is a CRM-native record — not Wikipedia, not synthetic trivia. Real deal names, real employee hierarchies, real renewal dates. This is the data environment where flat vector search collapses and graph traversal wins.

Question Difficulty Distribution

Easy · 1-hop50

Medium · 2-hop27

Hard · 3-hop13

Section 05 · The Centerpiece

Try It Live

Pick one of the CRM questions below and watch all three pipelines race to answer — with TigerGraph traversing the graph in real time.

⚠️ Please stick to the pre-set questions — this demo is scoped to our synthetic CRM dataset. Out-of-context questions will return irrelevant answers. Also, we're on free-tier deployment — if an answer doesn't load, give it a few seconds and try again.

GraphRAG (TigerGraph) — ms — — tokens

Pick a question above to see live answers from all three pipelines.

Basic RAG — ms — — tokens

Waiting for query…

LLM Only — ms — — tokens

Waiting for query…

GraphRAG

—

BasicRAG

—

LLM Only

—

Live Graph Traversal at rest

Vendor Customer Outage Region Employee

Section 06

Three Reasons TigerGraph Was the Difference

It isn't just better numbers — it's a fundamentally different retrieval shape.

Multi-hop beats keyword matching

Relational questions need relational retrieval

A question like "What competitors does Acme Corp face?" requires traversing Customer → Product → Competitor. Vector search returns the 15 most similar Wikipedia chunks. TigerGraph returns 3 exact nodes via GSQL traversal.

Precision = efficiency

Targeted context, not a haystack

BasicRAG: flat similarity retrieval = ~10,867 tokens. GraphRAG: direct entity fetch = ~1,483 tokens. TigerGraph's graph structure IS the filter. 86% token reduction is a side-effect of getting retrieval right.

Relationships that flat search can't see

25-point accuracy gap — same data, same LLM

BasicRAG had the documents and still answered only 71.1%. Multi-hop questions like "which customers share a vendor and region with this outage?" require graph traversal — cosine similarity has no concept of edges. TigerGraph does.

Section 07

Where Graph Intelligence Shows

Three real benchmark questions. Same LLM. Different retrieval. Different worlds.

"What is the severity level of outage OUTAGE-001?"

GR · PASS

✓ Outage OUTAGE-001 (P3, 32 hours, REGION-FRANKFURT, VEND-01).

BR · FAIL

✗ OUTAGE-001 appears to be a P3 incident, though the exact severity could not be confirmed from the retrieved context.

OUTAGE-001→Content vertex→severity, region, vendor

"Which vendor is customer CUST-0001 primarily dependent on?"

GR · PASS

✓ Vendor VEND-01 (MedSync) is customer CUST-0001's primary vendor dependency.

BR · FAIL

✗ Based on the retrieved chunks, CUST-0001 may depend on VEND-01 but the relationship could not be confirmed — multiple vendor references were returned without a clear primary dependency.

CUST-0001→depends_on edge→VEND-01 (MedSync)

"How many outages has VEND-15 experienced?"

GR · PASS

✓ VEND-15 has experienced 2 outages — OUTAGE-015 and OUTAGE-065.

BR · FAIL

✗ The retrieved chunks mention VEND-15 in outage context but cannot aggregate a count — the relationship between vendor and outage records requires graph traversal, not similarity search.

VEND-15→experienced edge→OUTAGE-015, OUTAGE-065