Understanding Hybrid Retrieval: Dense Retrieval + Knowledge Graph

Why dense retrieval isn't always enough

Dense retrieval maps passages to embeddings and finds neighbors by vector similarity. It is excellent at semantic paraphrase: a question and an answer that use different words but mean the same thing end up close in embedding space.

But embeddings struggle when the answer is spread across multiple documents, or when the relevant signal is a relationship — "who worked with whom on which project" — rather than a single self-contained passage. The vector space has no explicit notion of entities or edges; it only has "this text is similar to that text".

Where a knowledge graph helps

A knowledge graph stores facts as structured triples: (subject, predicate, object). That gives you:

• Explicit relationships that a similarity model can only infer.
• Multi-hop traversal — "find all documents connected to entity X through two edges".
• Entity-grounded queries, where the graph acts as a structured filter or expansion step on top of retrieval.

The graph doesn't replace embeddings. It complements them: embeddings answer "what is semantically close?", the graph answers "what is connected?".

A practical fusion pattern

A common design is to retrieve from both paths and fuse:

query
 ├──► dense retrieval (embeddings) ──► top-k candidates
 └──► graph traversal (entities)   ──► related passages
                    │
                    └────────► merge → rerank → final results

Fusion can be as simple as reciprocal rank fusion over both lists, with the reranker deciding the final order. In my experience the graph path matters most for relationship-heavy queries, while dense retrieval carries everything else.

Takeaways

• Ingestion and chunking decide retrieval quality as much as the model.
• Hybrid retrieval is a systems problem: choose the fusion and reranking with the query distribution in mind.
• Evaluate on task-aligned queries, not just off-the-shelf benchmarks.