Short answer: Graphs answer multi-hop relational questions that similarity search alone cannot traverse reliably.
Vector search finds meaning-like content but has no built-in chain of who reports to whom through intermediates. A knowledge graph stores entities and edges for explicit traversal. Combining both outperforms either alone: semantic find plus relational walk. Not every memory system needs a full graph; shallow relationships often work with denormalization. Maintaining extraction and graph consistency has real cost, so use it when multi-hop questions are core.
The previous chapter looked at representing individual relationships between entities, either through formal links or by denormalizing a connected detail directly onto a memory. Some questions demand more than a single relationship examined in isolation, they require following a whole chain of connections, sometimes several steps deep, to actually arrive at an answer. This is exactly where a dedicated knowledge graph earns its place alongside vector search rather than replacing it.
What Kind of Question Does Semantic Search Alone Genuinely Struggle to Answer?
Vector search excels at finding content whose meaning resembles a query, but it has no inherent concept of multi-step relationships between the things it retrieves. A question asking which entities connect to a specific entity through some intermediate chain, who reports to someone who in turn manages a particular project, isn’t really a question about semantic similarity at all, it’s a question about graph structure, about traversing explicit connections from one node to another. Semantic search can retrieve individual pieces mentioning each entity along that chain, but it has no native mechanism for actually following the chain itself from one link to the next.
How Does a Knowledge Graph Represent Information Differently from a Standard Collection of Searchable Objects?
A knowledge graph organizes information as nodes representing entities and edges representing the explicit relationships between them, built specifically to support traversal, following a path from one node through its connections to reach others several steps removed. This structure makes a fundamentally different kind of query fast and natural: instead of asking what content resembles a query in meaning, a graph traversal asks what’s reachable from a specific starting point by following a specific kind of relationship, potentially several hops deep, in a way vector similarity was never designed to answer directly.
Why Does Combining a Knowledge Graph with Vector Search Actually Outperform Using Either Approach Alone?
Vector search and graph traversal are strong at complementary things: vector search finds the right starting entities based on what a query is actually about, while graph traversal then follows explicit relationships outward from those starting points to surface connected context vector similarity alone would never have reached. A hybrid approach typically uses semantic search first to identify the entities most relevant to a query’s actual meaning, then hands those entities off to a graph traversal step that follows their known relationships to pull in the broader, connected context a pure similarity search would have missed entirely. This combination, sometimes called GraphRAG, extends what a memory system can actually answer well beyond what either technique manages on its own.
Does Every Memory System Actually Need a Full, Dedicated Knowledge Graph to Benefit from This Idea?
Not necessarily. A full, formally maintained knowledge graph, complete with community detection and multi-level relationship summarization, is a genuinely substantial undertaking, worthwhile when a system’s core value actually depends on answering complex, multi-hop relational questions across a large, richly interconnected body of entities. A system whose relationships stay comparatively shallow, mostly a small number of directly connected entities per memory, often gets most of the practical benefit from the simpler denormalization approach covered in the previous chapter, without needing to build and maintain a separate graph layer at all. The decision comes down to how deep and how frequent a system’s actual relational questions genuinely are.
What Does It Actually Cost to Maintain a Knowledge Graph Layer Alongside a Memory Store?
Building and maintaining a knowledge graph means running entity extraction and relationship extraction over incoming content, then keeping that graph consistent as facts get added, updated, or superseded, exactly the kind of freshness challenge covered earlier in this knowledge base but now applied to relationships rather than individual vectors. A knowledge graph that falls out of sync with the underlying memory it’s supposed to summarize becomes actively misleading, confidently asserting a connection that no longer reflects current reality. This ongoing maintenance cost is real, and it’s exactly why a knowledge graph should be reserved for the specific relational questions that genuinely justify it, rather than adopted reflexively as a default layer on top of every memory system.
How Does Weaviate Engram’s Underlying Infrastructure Support This Kind of Combined Semantic and Relational Retrieval?
Weaviate Engram runs on Weaviate’s collection and cross-reference model, which can represent explicit entity relationships that a retrieval step can follow outward from whatever entities a semantic search identifies first. Consider a private-equity firm’s deal-diligence assistant, helping analysts trace connections between companies, executives, and prior transactions while evaluating a potential acquisition:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"The target company's chief operating officer previously served as CFO at a portfolio company the firm exited eighteen months ago, and maintained close ties with two board members who also sit on the target's audit committee.",
properties={"deal_id": "deal-northbridge-acquisition", "entity_name": "target-coo"},
)
An analyst’s initial search identifies the relevant starting entity through semantic similarity, exactly the strength vector search brings to this hybrid approach:
results = client.memories.search(
query="What prior connections does the target company's leadership have to our existing portfolio?",
properties={"deal_id": "deal-northbridge-acquisition"},
)
From that starting point, an analyst genuinely needs to follow the chain further, from the chief operating officer to the prior portfolio company, and from there to the two connected board members, a multi-hop relational question semantic similarity alone would never fully trace on its own. This is exactly the kind of question a knowledge graph layer, built on top of Engram’s underlying entity relationships, is suited to answer, letting analysts uncover exactly the kind of layered, indirect connections that matter enormously during real diligence work but that a single similarity search, however well-tuned, would likely miss entirely on its own.
A knowledge graph extends what memory can answer by making relationships themselves something a system can traverse, not just something a search happens to mention. But relationships, like the facts they connect, don’t stay fixed over time, an executive changes roles, a partnership dissolves, a board seat turns over. Our next chapter, What is a temporal knowledge graph?, takes up exactly that challenge.