Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt

Use this file to discover all available pages before exploring further.

Session 33 (Season 2, Episode 6 — February 2025) takes a step back from construction and focuses on retrieval: once you have a well-structured knowledge graph in Neo4j, how do you best retrieve the right context for a RAG query? This session runs a systematic, side-by-side comparison of four major retrieval strategies — vector similarity search, keyword (full-text) search, graph traversal, and hybrid combinations — evaluating them on both answer quality and response latency against the same knowledge graph and the same set of questions.

Watch the Recording

Full live-stream replay on YouTube

Session Materials

Session slide deck (PDF)

​
Why Retrieval Strategy Matters

The ontology-guided KG construction pipeline from the preceding sessions produces a graph with two distinct types of content:
  1. Structured entities and relationships — typed nodes with ontology-defined properties connected by semantically labelled relationships
  2. Text chunks — document fragments stored as Chunk nodes, linked to the structured entities they mention, and embedded as vectors
These two data types call for different retrieval strategies. The optimal approach for a factual lookup (“What is the effective date of contract X?”) differs from the optimal approach for a conceptual question (“What are the key obligations of party Y?”).

​
The Four Retrieval Strategies

Vector search identifies the most semantically similar text chunks to the query by comparing embedding vectors in the Neo4j vector index. It is the default starting point for most RAG systems. 
CALL db.index.vector.queryNodes('chunk_embeddings', 5, $query_embedding)
YIELD node, score
RETURN node.text AS content, score
ORDER BY score DESC
Strengths: Captures semantic similarity even when keywords differ. Works well for conceptual questions. Weaknesses: Returns chunks, not graph-structured facts. Can miss precise entity lookups.

​
2. Full-Text (Keyword) Search

Full-text search uses a Lucene-based index over node text properties. It excels at precise term matching — names, identifiers, dates — that vector search can miss. 
CALL db.index.fulltext.queryNodes('ft', $search_term)
YIELD node, score
RETURN node.text AS content, score
ORDER BY score DESC
Strengths: Deterministic. Extremely fast. Reliable for exact-match lookups. Weaknesses: No semantic flexibility — a synonym or paraphrase produces no results.

​
3. Graph Traversal

Graph traversal uses the structured entity–relationship layer of the KG to answer questions directly, without relying on text chunks at all. The ontology-defined relationships become the retrieval paths. 
MATCH (e:Entity {name: $entity_name})-[r]->(related)
RETURN type(r) AS relationship,
       labels(related)[0] AS type,
       related.name AS name,
       related.description AS description
Strengths: Returns precise, structured facts. Exploits the full value of the KG construction investment. Naturally handles multi-hop queries. Weaknesses: Requires the entity to be correctly extracted and stored. Fails for questions about content not captured in the structured layer.

​
4. Hybrid Retrieval

Hybrid retrieval combines two or more of the above strategies, merging the result sets and optionally re-ranking by score. The most effective hybrid for knowledge graphs pairs vector search (for broad semantic coverage) with graph traversal (for structured fact grounding). 
// Vector search for candidate chunks
CALL db.index.vector.queryNodes('chunk_embeddings', 10, $query_embedding)
YIELD node AS chunk, score AS vector_score
// Traverse from chunks to their linked structured entities
MATCH (chunk)<-[:MENTIONS]-(entity)
OPTIONAL MATCH (entity)-[r]->(related)
RETURN chunk.text AS chunk_text,
       entity.name AS entity,
       collect(type(r) + ' -> ' + related.name) AS graph_context,
       vector_score
ORDER BY vector_score DESC
LIMIT 5
The MENTIONS relationship is created during KG construction — each Chunk node is linked to the structured entities extracted from it. This bidirectional link is what makes hybrid retrieval possible.

​
Benchmarking Dimensions

The session evaluates each strategy across two primary dimensions:

Answer Quality

Measured by faithfulness (is the answer grounded in retrieved content?), relevance (does it address the question?), and completeness (does it cover all relevant facts?).

Latency

Wall-clock time from query submission to LLM response. Vector search is typically fastest; multi-hop graph traversal adds index lookup and traversal costs.

​
Summary of Trade-offs

StrategyBest ForQualityLatency
Vector SearchConceptual/semantic questionsHigh for open questionsLow
Full-Text SearchExact name/identifier lookupsHigh for precise matchesVery Low
Graph TraversalStructured fact retrieval, multi-hopHighest for factual questionsMedium
HybridGeneral-purpose RAG over KGsHighest overallMedium–High
The ontology matters for retrieval too: a well-designed class and relationship hierarchy gives traversal-based retrieval more paths to follow, improving recall for complex questions. Sessions 28–32 cover how to design and populate that ontology-driven graph.

​
Practical Recommendations

1

Start with vector search

Vector search is the easiest baseline and performs well for most general questions. If your answers are already satisfactory, stop here.
2

Add full-text search for entity lookups

If your questions frequently involve specific names, identifiers, or dates, add a full-text index and route those queries to keyword search.
3

Enable graph traversal for structured facts

Once your KG has sufficient entity and relationship coverage, graph traversal retrieval significantly improves factual precision — especially for questions that span multiple hops.
4

Combine with hybrid re-ranking

For production systems, a hybrid approach that merges vector and graph results and re-ranks by a combined score delivers the best overall quality. Accept the modest latency increase.
Session 34 takes retrieval a step further by making the choice of retrieval strategy itself dynamic — the LLM selects which tool (and thus which retrieval method) to invoke based on the question.

Build docs developers (and LLMs) love

Get started for freeTalk to us