跪拜 Guibai
← All articles
GitHub · Vue.js · Frontend

Vector-Graph-RAG: Dual-Engine Recall for Enterprise Q&A That Pure Vector Search Can't Handle

By 徐小夕 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Teams with existing Milvus-based knowledge bases can step up to graph-enhanced RAG without re-architecting or running a heavy graph database; the main cost is entity extraction and ongoing graph curation, not infrastructure.

Summary

Pure vector RAG crumbles on questions that need cross-document links and multi-hop reasoning: 'Which vendors worked with Zhang San?', 'What caused similar equipment failures in Q3?' Testing shows accuracy drops to 50-60% on such questions, with hallucinations and entity confusion as the main culprits. vector-graph-rag addresses this by adding a knowledge graph layer to the existing Milvus pipeline, so retrieval happens along both semantic similarity and entity-relation paths.

The architecture is a five-layer design: document preprocessing, entity/relation extraction with normalization, dual-index storage (Milvus for vectors, a lightweight graph index for entities and edges), hybrid recall that fuses both paths, and answer generation with evidence-chain validation. A six-step workflow from ingestion to answer includes human-editable entity normalization, which alone lifts complex-question accuracy by over 15% in the evaluation's tests. The project is deliberately incremental: existing vector knowledge bases can add the graph layer without a rebuild, and small-to-medium deployments don't need a separate graph database.

Takeaways
— Pure vector RAG accuracy falls to 50-60% on multi-hop and cross-entity questions, from a 70-80% baseline on simple ones.
— Entity normalization alone lifted complex-question accuracy by over 15% in the evaluation's tests.
— Dual-engine recall raised accuracy on entity-relation and multi-hop questions by 20-30%.
— The system supports alias mapping, rule-based merging, and human calibration for entity disambiguation.
— It runs on Milvus and does not require a separate graph database for small-to-medium projects.
— Existing vector knowledge bases can add graph extraction and storage layers incrementally without a full rebuild.
— Recommended for manufacturing, legal, HR, medical/finance, and large enterprise KBs; not for small FAQ-only or unstructured-content KBs.
Conclusions

Entity normalization is the highest-leverage step in this architecture, not the graph traversal itself; the evaluation attributes a 15% accuracy gain to normalization alone, and many GraphRAG implementations skip it.

The incremental upgrade path and lack of a graph DB requirement make this a pitch to system integrators and small teams, not just large enterprises; it trades graph depth for lower operational cost.

The claimed accuracy gains (20-30% on complex questions) stem from the evaluation's own tests, not published benchmarks; extraction quality still depends on the underlying LLM, so results will vary by domain and model.

Concepts & terms
GraphRAG
An approach to retrieval-augmented generation that adds a knowledge graph of entities and relationships to the vector index, so retrieval can follow explicit relation paths instead of only text similarity.
Entity normalization
The process of merging aliases, abbreviations, and alternative names for the same real-world entity into a single canonical node, often via rules, models, and human review.
Multi-hop reasoning
Answering a question that requires chaining multiple relationships across entities, such as going from a product to its supplier to that supplier's delivery records.
Hybrid recall
A retrieval strategy that combines vector similarity search (for semantic breadth) with graph-based traversal (for precise relations), fusing both result sets before generation.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗