CRM Nexus   ·   TigerGraph × GraphRAG Inference

Stop paying for tokens your LLM doesn't need.

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

2.69M
Tokens Processed
21,318
Entities
48,201
Graph Edges
36
Eval Questions
2.7×
Hackathon Min
TigerGraph Community Edition

One synthetic CRM. Three pipelines. Same Llama 70B brain. TigerGraph answered 35/36 — BasicRAG failed on 22.

0%
Accuracy
35 / 36 questions
0%
Fewer tokens
vs BasicRAG baseline
0%
Faster
9,896ms vs 78,485ms
0.00
BERTScore F1
target was 0.55 ✓
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 15 random chunks, burns 2,124 tokens, and costs you $0.00149 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: Contact → Deal → Account → Territory. Returns exactly the 3 relevant chunks. 584 tokens. $0.00058 per question. Same LLM. Same accuracy. 72.5% cheaper.

Cost Per Query

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

₹0.125
BasicRAG
₹0.049
CRM Nexus

CRM Nexus costs 61% less per query — 584 input tokens via TigerGraph graph traversal vs 2,124 from flat vector search. Same Llama 3.3 70B output.

Section 02

Head-to-Head: 36-Question CRM Benchmark

Same LLM (Llama 3.3 70B via Groq). Same 36 questions. Only the retrieval layer changes.

Accuracy

Percentage of the 36 evaluation questions each pipeline answered correctly.

GraphRAG (TigerGraph)
97.2%
Basic RAG (Vector Only)
38.9%
LLM Only
8.3%
Minimum useful · 50%

BasicRAG only answered 14/36 questions; pass rate on those was 77.8%, yielding 38.9% effective.

Token Usage Per Question

Prompt tokens, questions 1 → 36.

72.5% fewer tokens — every single question

Pipeline Coverage

Questions each pipeline was able to answer at all.

35/36
GraphRAG
14/36
BasicRAG

BasicRAG's vector store is Wikipedia. CRM entities like 'Acme Corp' don't exist in Wikipedia. GraphRAG stores everything in TigerGraph.

Latency

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

78,485ms
BasicRAG · avg response time
87.4% FASTER →
0.94 BERTScore F1
9,896ms
GraphRAG · avg response time
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
  • 21,318 vertices · 48,201 edges
  • HNSW vector index
  • GSQL multi-hop traversal
  • Customer → Product → Competitor
retrieval
→
Layer 02
Orchestration
Node.js · Fastify
  • Query classification
  • Vector seed → 3-hop GSQL
  • Chunk assembly
  • Prompt construction
prompt
→
Layer 03
LLM
Groq · Llama 3.3 70B Versatile
  • ~560 prompt tokens / Q
  • 4 dedicated API keys
  • 3 s rate-limit queue
  • max_tokens: 300
grade
→
Layer 04
Evaluation
Llama 4 Scout 17B · BERTScore
  • Independent judge model
  • PASS / FAIL per question
  • BERTScore F1 = 0.94
  • 36-Q benchmark, v5
// 3-hop graph traversal — the engine behind 97.2% 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; }

3-hop GSQL traversal — the engine behind 97.2% accuracy

Section 04

The Data: Real Complexity, Real Scale

7,500 deals with stages, values & owners. 6,000 customers with health scores, NPS & renewal dates. 4,318 employees across 5 departments. 5 products with competitors and pricing. Every entity linked — built specifically to make flat vector search fail and graph traversal win.

Download Dataset JSON · 2 KB
2.69M
Tokens
2.7× the hackathon's 1M minimum
21,318
Vertices
across 5 entity types
48,201
Edges
7 relationship types
36
Eval Questions
1–3 hops · simple → synthesis

Entity Breakdown

Deals
7,500
Customers
6,000
Employees
4,318
Departments
5
Products
5
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
Simple · 1-hop14
Multi-hop · 2–3 hops14
Synthesis8
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
Customer Product Employee Department Deal
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: 15 chunks × 1,200 chars = ~2,100 tokens. GraphRAG: 3 chunks × 800 chars = ~560 tokens. TigerGraph's graph structure IS the filter. 72.5% token reduction is a side-effect of getting retrieval right.

Coverage where vector fails

22 questions BasicRAG couldn't answer

CRM entities don't exist in Wikipedia. BasicRAG failed on 22/36 questions — not wrong answers, zero answers. TigerGraph ingested every entity on day 1. No question left behind.

Section 07

Where Graph Intelligence Shows

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

"What competitors does CRM Enterprise face, and which customers use it?"
GR · PASS
✓ CRM Enterprise competes with HubSpot, Salesforce, and Zoho. Current customers include GlobalTech Solutions and Meridian Solutions.
BR · FAIL
✗ Returned Wikipedia text about the general CRM software market.
Product→COMPETES_WITH→Competitor Customer→USES→Product
"Which department has the larger budget — Sales or Engineering?"
GR · PASS
✓ Sales has a budget of $2,771,107 vs Engineering's $2,502,988 — Sales has the larger budget.
BR · FAIL
✗ No CRM department data exists in Wikipedia vector store.
Department:Sales→budget Department:Engineering→budget
"Pinnacle Enterprises is at risk. What products do they use and what are the NPS scores?"
GR · PASS
✓ Pinnacle uses CRM Enterprise (NPS 47) and Analytics Pro (NPS 62). Combined NPS-weighted churn risk: moderate.
BR · FAIL
✗ Entity 'Pinnacle Enterprises' not found in vector store.
Customer→USES→Product→NPS