EdgeQuake vs Traditional RAG
EdgeQuake vs Traditional RAG
Section titled “EdgeQuake vs Traditional RAG”Product: v0.19.0
Why Knowledge Graphs Transform Retrieval Quality
Traditional RAG (Retrieval-Augmented Generation) uses vector similarity search to find relevant document chunks. EdgeQuake adds knowledge graph construction, enabling semantic understanding of entity relationships that pure vector search misses.
Quick Comparison
Section titled “Quick Comparison”| Aspect | Traditional RAG | Graph-Enhanced RAG (EdgeQuake) |
|---|---|---|
| Retrieval | Vector similarity only | Vector + Graph traversal |
| Understanding | Semantic similarity | Entity relationships |
| Multi-hop | ❌ Single-hop | ✅ Multi-hop reasoning |
| Themes | ❌ Local only | ✅ Global themes |
| Indexing | Fast (~1s/doc) | Slower (~5–30s/doc; vision PDFs longer) |
| Query Latency | ~100-300ms | ~200-500ms |
| Storage | Vector DB only | PostgreSQL 16–18 (required) |
| PDF vision | External OCR | Built-in vision LLM pipeline |
| Cancel / progress | N/A | WebSocket + task cancel (SPEC-057) |
The Problem with Vector-Only Search
Section titled “The Problem with Vector-Only Search”Traditional RAG has fundamental limitations:
1. Lost Relationships
Section titled “1. Lost Relationships”Consider this document:
“Sarah Chen works at MIT. She authored the climate paper with Dr. James Wilson.”
Question: “What is the connection between Sarah Chen and James Wilson?”
┌─────────────────────────────────────────────────────────────────┐│ TRADITIONAL RAG PROBLEM │├─────────────────────────────────────────────────────────────────┤│ ││ Document chunks: ││ ┌────────────────────────────────────────┐ ││ │ Chunk 1: "Sarah Chen works at MIT..." │ → embedding_1 ││ └────────────────────────────────────────┘ ││ ┌────────────────────────────────────────┐ ││ │ Chunk 2: "She authored the climate..." │ → embedding_2 ││ └────────────────────────────────────────┘ ││ ││ Query: "connection between Sarah and James" ││ ││ Vector search: May find Chunk 1 (Sarah mentioned) ││ May miss Chunk 2 (if "connection" not similar) ││ ││ PROBLEM: No explicit link between Sarah and James! ││ │└─────────────────────────────────────────────────────────────────┘2. No Global Understanding
Section titled “2. No Global Understanding”Question: “What are the main themes in this 50-page document?”
Traditional RAG retrieves the most semantically similar chunks to “themes”, but this misses the document’s structure and organization.
3. No Multi-Hop Reasoning
Section titled “3. No Multi-Hop Reasoning”Question: “Who are Sarah Chen’s collaborators’ organizations?”
This requires:
- Find Sarah Chen
- Find her collaborators
- Find their organizations
Vector search cannot chain these lookups.
How Graph-Enhanced RAG Solves This
Section titled “How Graph-Enhanced RAG Solves This”EdgeQuake constructs a knowledge graph during indexing:
┌─────────────────────────────────────────────────────────────────┐│ GRAPH-ENHANCED RAG │├─────────────────────────────────────────────────────────────────┤│ ││ Document → LLM Extraction → Knowledge Graph ││ ││ ┌───────────────┐ ││ │ SARAH_CHEN │ ││ │ (PERSON) │ ││ └───────┬───────┘ ││ │ ││ ┌───────────┼───────────┐ ││ │ WORKS_AT │ CO_AUTHORED ││ ▼ ▼ ││ ┌─────┐ ┌──────────────┐ ││ │ MIT │ │ CLIMATE_PAPER│ ││ └─────┘ └──────┬───────┘ ││ │ AUTHORED_BY ││ ▼ ││ ┌──────────────┐ ││ │ JAMES_WILSON │ ││ │ (PERSON) │ ││ └──────────────┘ ││ ││ Query: "connection between Sarah and James" ││ ││ Graph traversal: SARAH_CHEN → CLIMATE_PAPER → JAMES_WILSON ││ Relationship: CO_AUTHORED ││ ││ ANSWER: "Sarah and James co-authored the climate paper" ││ │└─────────────────────────────────────────────────────────────────┘Feature Comparison
Section titled “Feature Comparison”| Feature | Traditional RAG | EdgeQuake |
|---|---|---|
| Chunk embedding | ✅ | ✅ |
| Entity extraction | ❌ | ✅ |
| Relationship extraction | ❌ | ✅ |
| Knowledge graph | ❌ | ✅ |
| Multi-hop queries | ❌ | ✅ |
| Theme detection | ❌ | ✅ |
| Entity-centric search | ❌ | ✅ |
| Global context | ❌ | ✅ |
| Source lineage | ⚠️ Basic | ✅ Full |
Query Quality Comparison
Section titled “Query Quality Comparison”Research from the LightRAG paper (arxiv:2410.05779) shows significant improvements:
| Dataset | Traditional RAG | Graph-RAG | Improvement |
|---|---|---|---|
| Agriculture | 32.4% | 67.6% | +35% |
| CS | 38.4% | 61.6% | +23% |
| Legal | 16.4% | 83.6% | +67% |
| Mix | 38.8% | 61.2% | +22% |
Metrics: Comprehensiveness, measured by LLM-as-judge evaluation
Indexing Cost Trade-off
Section titled “Indexing Cost Trade-off”Graph-enhanced RAG requires more processing at index time:
┌─────────────────────────────────────────────────────────────────┐│ INDEXING COMPARISON │├─────────────────────────────────────────────────────────────────┤│ ││ Traditional RAG: ││ ┌────────┐ ┌───────────┐ ┌─────────────┐ ││ │ Doc │ ─▶ │ Chunk │ ─▶ │ Embed │ ─▶ Done ││ │ │ │ (~10ms) │ │ (~100ms) │ ││ └────────┘ └───────────┘ └─────────────┘ ││ ││ Total: ~200ms per document ││ ││ ────────────────────────────────────────────────────────────── ││ ││ EdgeQuake: ││ ┌────────┐ ┌───────────┐ ┌─────────────┐ ││ │ Doc │ ─▶ │ Chunk │ ─▶ │ LLM Extract │ ─▶ ─┐ ││ │ │ │ (~10ms) │ │ (~2-10s) │ │ ││ └────────┘ └───────────┘ └─────────────┘ │ ││ ▼ ││ ┌─────────────┐ ││ │ Graph Merge │ ││ │ (~100ms) │ ││ └──────┬──────┘ ││ ▼ ││ ┌─────────────┐ ││ │ Embed │ ││ │ (~200ms) │ ││ └─────────────┘ ││ ││ Total: ~5-30s per document ││ │└─────────────────────────────────────────────────────────────────┘Cost-Benefit Analysis
Section titled “Cost-Benefit Analysis”| Scenario | Traditional RAG | EdgeQuake | Recommendation |
|---|---|---|---|
| 100 docs, simple queries | ✅ Fast, cheap | Overkill | Traditional |
| 100 docs, relationship queries | ❌ Poor quality | ✅ Good | EdgeQuake |
| 10K docs, mixed queries | Fast, moderate quality | Slower index, better quality | EdgeQuake |
| Real-time indexing needed | ✅ Works | ⚠️ Latency | Traditional |
When to Choose Each Approach
Section titled “When to Choose Each Approach”Choose Traditional RAG When:
Section titled “Choose Traditional RAG When:”- ✅ Documents have simple, factual content
- ✅ Queries are keyword-based lookups
- ✅ Real-time indexing is required
- ✅ LLM costs are a primary concern
- ✅ You need minimal infrastructure
Choose EdgeQuake When:
Section titled “Choose EdgeQuake When:”- ✅ Documents describe entities and relationships
- ✅ Users ask about connections and themes
- ✅ Multi-hop reasoning is needed
- ✅ Answer quality is more important than indexing speed
- ✅ Global document understanding is required
Hybrid Approach
Section titled “Hybrid Approach”EdgeQuake’s query modes let you blend both approaches:
| Mode | Strategy | Use Case |
|---|---|---|
naive |
Vector only | Simple factual queries |
local |
Vector + Entity graph | Entity-specific questions |
global |
Graph communities | Theme/overview questions |
hybrid |
All approaches | Complex queries (default) |
This means you get the best of both worlds:
- Fast vector search for simple queries
- Graph traversal for complex reasoning
- Combined context for comprehensive answers
Implementation Effort
Section titled “Implementation Effort”| Aspect | Traditional RAG | EdgeQuake |
|---|---|---|
| Setup complexity | Low | Medium |
| LLM calls per doc | 1 (embedding) | 3-10 (extraction + embedding) |
| Infrastructure | Vector DB only | PostgreSQL 16–18 (pgvector + AGE); DATABASE_URL required |
| Long-running jobs | N/A | Cancel via POST /tasks/{track_id}/cancel; multi-replica with EDGEQUAKE_REPLICAS |
| Maintenance | Simple | Moderate |
| Query tuning | Limited | 6 modes to optimize |
Summary
Section titled “Summary”┌─────────────────────────────────────────────────────────────────┐│ DECISION MATRIX │├─────────────────────────────────────────────────────────────────┤│ ││ Question Type │ Traditional │ EdgeQuake ││ ───────────────────────────────────────────────────────────── ││ "What is X?" │ ⭐⭐⭐ ⭐⭐⭐│ "How does X work?" │ ⭐⭐ ⭐⭐⭐│ "What connects X and Y?" │ ⭐ ⭐⭐⭐⭐│ "Main themes in doc?" │ ⭐ ⭐⭐⭐⭐│ "X's collaborators' orgs?" │ ❌ ⭐⭐⭐⭐││ If most queries are multi-hop or relationship-based, ││ EdgeQuake provides significantly better results. ││ │└─────────────────────────────────────────────────────────────────┘See Also
Section titled “See Also”- LightRAG Algorithm - How the algorithm works
- Graph-RAG Concepts - Understanding graph-enhanced RAG
- Query Modes - Choosing the right mode
- vs GraphRAG - Microsoft’s approach comparison