Knowledge Graphs for Relational, Multi-Hop Reasoning

Entities and relationships, defined concretely

[GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): objective 1.7 calls for integrating knowledge graphs, and the source material defines one directly — a knowledge graph encodes entities and the relationships between them, capturing semantic relations that enable multi-hop queries and reasoning that flat, similarity-based retrieval misses. An entity is a distinct thing the graph knows about — a person, a company, a product, a location, an event. A relationship (also called an edge) connects two entities and names how they relate — "works at," "acquired," "is a supplier of," "reports to," "is located in." A knowledge graph, structurally, is nothing more exotic than a set of entities (nodes) connected by a set of labeled relationships (edges) — but that simple structure is precisely what lets a query traverse from one entity to another through explicit relationships, rather than only comparing how similar two pieces of text read.

Why this is a fundamentally different query shape than similarity search

A vector store answers "what is like this" — given a query, find stored content whose embedding is close to the query's embedding. A knowledge graph answers a structurally different question: "what is connected to this, and through what chain of relationships." Those are not two ways of phrasing the same underlying capability; they are genuinely different operations. Similarity is a distance calculation between two points in an embedding space, computed independently for each candidate against the query, with no notion of one candidate being related to another. Graph traversal is following explicit, named edges from one node to another, potentially through several intermediate nodes, where the path itself — which entities and relationships were crossed to get from the starting node to the answer — is part of what makes the answer correct and explainable.

One hop versus many

A single-hop query asks about a direct relationship: "who is Company X's CEO" traverses exactly one edge (Company X → has-CEO → Person Y) and stops. A multi-hop query requires following a chain of relationships to reach an answer that no single edge states directly: "who is the CEO of the company that acquired the company Person Y used to work at" requires traversing from Person Y, to the company they used to work at, to whichever company acquired that company, to that acquirer's current CEO — four entities and three relationship-edges chained together, where the final answer (the CEO's name) is not stored anywhere as a direct fact about Person Y at all. It only becomes derivable by walking the chain of relationships connecting Person Y to that answer.

Why flat retrieval genuinely cannot do this

[GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): the source material states this precisely — knowledge graphs enable multi-hop queries and reasoning that flat, similarity-based retrieval misses. The reason is structural, not a matter of vector search simply being "less good" at this task: a vector store has no representation of the chain connecting Person Y to the eventual CEO answer. Even if a document chunk somewhere in the corpus happens to mention both Person Y's old employer and that employer's acquirer in the same paragraph, similarity search would need the query itself to already resemble that specific paragraph's phrasing to retrieve it — and a four-entity chain spanning multiple separate facts, likely recorded in multiple separate documents written at different times by different people, is exactly the case where no single chunk contains the full answer for similarity search to match against in the first place. The knowledge graph, by contrast, never needed all four facts to appear in one place; each relationship was recorded once, as its own edge, and the traversal assembles them at query time by walking the chain — which is precisely why relational, multi-hop reasoning is the capability this lesson keeps returning to as the graph's specific, non-substitutable strength.

Constructed scenario, illustrative only. Consider a small knowledge graph an enterprise agent might maintain over its own vendor and compliance data, and a query that genuinely requires traversing it rather than looking anything up directly.

Graph (entities and relationships, illustrative):
  (Vendor: Acme Components) --supplies--> (Product: Circuit Board CB-7)
  (Vendor: Acme Components) --subcontracts--> (Vendor: Delta Fabrication)
  (Vendor: Delta Fabrication) --flagged-for--> (Compliance Issue: Q3 audit failure)
  (Product: Circuit Board CB-7) --used-in--> (Product: Sensor Unit SU-2)
  (Product: Sensor Unit SU-2) --shipped-to--> (Customer: Northwind Robotics)

Query: "Which of our customers might be affected by Delta Fabrication's
Q3 compliance issue, and through what chain of products?"

Hop 1: start at (Compliance Issue: Q3 audit failure), traverse the
  flagged-for edge backward to reach (Vendor: Delta Fabrication).

Hop 2: from Delta Fabrication, traverse the subcontracts edge backward
  to reach (Vendor: Acme Components) -- the vendor that subcontracts
  work to the flagged vendor.

Hop 3: from Acme Components, traverse the supplies edge forward to
  reach (Product: Circuit Board CB-7), then the used-in edge forward to
  reach (Product: Sensor Unit SU-2), then the shipped-to edge forward
  to reach (Customer: Northwind Robotics).

Answer: Northwind Robotics is potentially affected, via the chain
  Delta Fabrication (flagged) -> subcontracted by Acme Components ->
  Acme's Circuit Board CB-7 -> used in Sensor Unit SU-2 -> shipped to
  Northwind Robotics. Four hops across five entities.

Notice what this traversal did not require: no single document anywhere needed to state "Northwind Robotics is affected by Delta Fabrication's compliance issue" — that fact does not exist as a written sentence anywhere in the underlying data. It exists only as the composition of five separately recorded relationships, each one individually mundane (a supply relationship, a subcontracting relationship, a shipping record), assembled at query time by walking the chain. [GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): this is the concrete shape of "relational, multi-hop reasoning that flat retrieval misses" — a similarity search over documents describing each individual relationship separately would need to somehow retrieve and then correctly chain together five separate, individually unremarkable facts, with nothing in any single document signaling how they connect, which is precisely the kind of composition graph traversal is built to do natively and vector similarity is not.

A second worked pass through the same graph shows what a vector-only system attempting the same query would actually produce, to make the contrast concrete rather than asserted:

Same query, attempted via vector similarity search only (no graph):
  Query embedding: "customers affected by Delta Fabrication's Q3
  compliance issue"

  Retrieval step: the vector store finds whichever indexed document
  chunks embed closest to that query -- most likely a chunk describing
  the Q3 audit failure itself, and perhaps a chunk mentioning Delta
  Fabrication's subcontracting relationship with Acme, IF that specific
  fact happens to appear in a document whose overall phrasing is close
  enough to the query's phrasing to rank highly.

  What is missing: nothing in the retrieved chunks states or implies
  the downstream chain through Circuit Board CB-7, Sensor Unit SU-2,
  and Northwind Robotics, because those facts live in entirely
  different documents (a bill-of-materials record, a shipping record)
  whose phrasing has no particular semantic similarity to a query about
  "compliance issues" at all -- a shipping manifest does not read as
  similar to an audit-failure query, even though it is the critical
  final link the correct answer depends on.

  Likely result: an incomplete or wrong answer, naming Delta Fabrication
  and possibly Acme Components as involved, but silently missing the
  actual affected customer, because the query never had a mechanism for
  crossing into documents that do not resemble it in wording.

The two traversals side by side make the exam's own framing concrete: this is not a case where vector search does a worse job at the same task — it is a case where the task (assemble a chain of relationships across documents with no shared vocabulary) is structurally outside what similarity search is built to do at all, regardless of how good the underlying embedding model is.

⚠️ Trap — the source material's own framing states this directly: knowledge graphs and vector search are not interchangeable; graphs shine at relational/multi-hop reasoning, vector search shines at semantic similarity, and hybrid designs use both. The reason this is a trap worth naming, rather than an obvious point, is that both mechanisms are frequently described in casual conversation as "retrieval," which invites treating them as two competing implementations of one job — when in reality they answer genuinely different question shapes, and a well-designed knowledge system typically needs both, aimed at the parts of a query each one actually serves.

Concretely: a query like "find documents discussing supply-chain resilience strategies similar to what we did during the last disruption" is a pure semantic-similarity question with no explicit entity-relationship chain to traverse — a knowledge graph offers nothing useful here, because there is no relational structure the question is actually asking about. A query like the four-hop compliance-chain example above is a pure relational question with no meaningful semantic-similarity angle — a vector store offers nothing useful here, because the correct answer depends on structure across documents with no shared vocabulary, not on which documents read similarly to the query. And a great many real queries are a mix of both: "find customers, similar in profile to Northwind Robotics, who might be affected by a compliance issue chain like Delta Fabrication's" genuinely needs a similarity pass (to find profile-similar customers) and a graph traversal (to check the compliance chain) working together — which is exactly the combined-retrieval design objective 6.3's HybridRAG material in Domain 6 develops in full detail; this lesson's job is to establish, from the architecture side, why that combination is necessary in the first place rather than one implementation simply being an upgrade over the other.

Everything discussed so far has treated the graph as already built — entities and edges sitting ready to traverse. A knowledge graph's usefulness is entirely dependent on how those entities and relationships got populated in the first place, and this is worth a direct look, because a graph populated carelessly gives you multi-hop traversal over wrong or incomplete relationships, which is arguably worse than having no graph at all — a confident-looking traversal path through bad edges produces an answer that looks exactly as verifiable as one built on correct edges, right up until someone checks it against reality.

Three broad approaches populate a knowledge graph's content, and they are not mutually exclusive within one system. Manual or curated construction has a domain expert or a data team explicitly define entities and relationships — an enterprise's org chart, its supplier registry, its product bill-of-materials — where accuracy matters enough that human review of each edge is worth the cost. Extraction from structured sources builds edges automatically from data that is already relational in its original form — a CRM's account-to-contact records, a procurement system's vendor-to-purchase-order records — where the relationship already exists as a database foreign key or a join, and populating the graph is largely a matter of exporting that existing structure into graph form rather than inferring anything new. Extraction from unstructured text uses an LLM or a dedicated information-extraction pipeline to read free text (contracts, emails, reports) and propose candidate entities and relationships that were only ever stated in prose — "Acme Components' Q3 filing mentions a subcontracting arrangement with Delta Fabrication" becomes a candidate edge, subject to whatever confidence threshold and review process the pipeline applies before that candidate edge is actually committed to the graph.

The third approach is the one worth treating with the most caution, because it inherits every reliability problem that comes with asking a model to extract structured facts from unstructured prose — a model can miss a relationship that was stated ambiguously, hallucinate a relationship that was never actually stated, or extract a relationship correctly but attach the wrong entity to it (linking the compliance flag to the wrong subsidiary of a company with a similar name, for instance). This is precisely why a graph built primarily from unstructured-text extraction benefits from an explicit confidence or provenance field on each edge — recording not just "Acme subcontracts to Delta" but also where that claim came from and how confident the extraction pipeline was — so that a downstream multi-hop traversal can distinguish a well-supported edge from a shakier inferred one, rather than treating every edge in the graph as equally certain regardless of its origin. A traversal that silently chains together one confidently-sourced edge and one shakily-extracted edge produces an answer whose overall reliability is really bounded by its weakest link, and a graph architecture that has no way to represent that difference has no way to warn a consumer of the traversal's output that the weak link exists at all.

M1-05 established that long-term memory is whatever a system deliberately builds to survive past a session, with three typical implementations: databases, knowledge graphs, and vector embeddings. A knowledge graph earns its place on that list specifically because relational facts — this customer's account is linked to that support ticket, which is linked to that product defect, which is linked to that vendor — are exactly the kind of information a database's exact-key lookup and a vector store's similarity search both handle awkwardly, but that a graph's native structure holds naturally.

The connection back to memory is worth making explicit rather than leaving implicit: an agent's long-term memory is not only "facts it needs to recall later" — it is frequently "relationships between things it needs to recall later," and a memory architecture that only supports key-based lookup and semantic similarity has no clean way to answer a multi-hop relational question about its own stored history at all. An agent tracking a multi-year customer relationship, where the customer's account is linked to multiple past interactions, each linked to a specific product, each linked to a specific support outcome, is accumulating exactly the kind of relational memory a knowledge graph is built to hold — and choosing not to back that memory with a graph does not make the relational structure go away, it just makes every future multi-hop question about that structure unanswerable without a manual, ad hoc reconstruction the agent has no native way to perform.

⭐ THE EARNED INSIGHT "Which retrieval method is better, graphs or vectors" is not actually a comparable question, because the two are not competing answers to the same question — they are correct answers to two different questions, and the exam's own trap list exists specifically to catch anyone who has not separated those two questions in their own head. The tell for which question a scenario is actually asking is whether the correct answer depends on a chain of explicit relationships (reach for a graph) or on what reads as similar in meaning (reach for vector search) — and a scenario carefully built to require both, like the compliance-chain-plus-customer-profile example above, is testing whether you reach for the combination rather than forcing the whole query through whichever single mechanism you happen to have already built.

A property this lesson has mentioned in passing but not yet given full weight is worth isolating on its own, because it is a genuine, distinct advantage a knowledge graph offers beyond raw capability at multi-hop queries: the traversal path itself is inspectable. When a graph traversal produces the answer "Northwind Robotics" to the compliance-chain query in the worked example above, the specific sequence of edges it crossed to get there — flagged-for, subcontracts, supplies, used-in, shipped-to — is available as a concrete, checkable artifact, not merely an assertion the system is asking you to trust.

This matters for a reason that goes beyond correctness in the narrow sense. A vector-similarity result comes with a similarity score, which tells you how close the retrieved content's embedding was to the query's embedding — a useful signal, but not an explanation of why the retrieved content is actually the right answer to the question asked, because similarity is a statement about vector-space distance, not about logical connection. A graph traversal's path, by contrast, is a literal chain of named, verifiable facts: someone auditing the compliance-chain answer can check each of the five edges independently — is Delta Fabrication actually flagged, does Acme actually subcontract to Delta, does Acme actually supply Circuit Board CB-7, and so on — and confirm or refute the answer edge by edge, rather than having to trust an opaque similarity ranking's judgment that some retrieved passage was "close enough" to the query to be relevant.

This verifiability property is precisely why graph-based retrieval led on correctness in the comparison NVIDIA's own material references, and it connects directly to why an agent's audit trail (a concern this cert returns to repeatedly in later domains around safety and oversight) benefits from a graph-backed answer wherever the underlying question is genuinely relational: a reviewer, an auditor, or a compliance officer checking an agent's compliance-chain answer after the fact has an actual reasoning chain to inspect, rather than a similarity score to take on faith. An architecture that only supports vector retrieval for a fundamentally relational, audit-sensitive question is not just missing a capability — it is producing answers that are structurally harder to verify after the fact, independent of whether those answers happen to be correct in a given instance.

Knowledge-graph integration is objective 1.7 within Agent Architecture and Design, a domain tied for the heaviest weight in the entire blueprint at 15%. [GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): the domain's scope note frames this exam as testing why a given architectural choice fits a scenario, and the graph-versus-vector distinction is one of the cleanest instances of that framing this domain contains, precisely because it is a comparison with a genuinely correct, non-arbitrary answer for any given query shape rather than a matter of preference.

Expect two recurring question shapes. The first names a query requiring relational, multi-hop reasoning — described the way the compliance-chain worked example above is described, as a chain of connected facts spread across separate records — and asks which retrieval mechanism fits, with vector search or "just use a bigger embedding model" offered as plausible-sounding wrong answers. The second is a direct trap item built from the source material's own flagged misconception: an answer choice presenting knowledge graphs and vector search as competing, either-or options, which is wrong precisely because the domain's own material states they are complementary and names hybrid designs as the pattern that uses both.

Not natively, and recognizing this limitation is as important as recognizing the graph's strength. A knowledge graph's traversal mechanism finds entities connected by explicit, named relationships — it has no built-in notion of "this unstructured passage of text means roughly the same thing as this other passage," because meaning-based similarity between free text was never what the graph's edges were built to represent. A query like "find write-ups with a similar tone and argument structure to this one" has no relational structure for a graph to traverse at all; there is no entity-relationship chain connecting two passages purely because they read similarly. This is precisely the mirror image of vector search's blind spot for multi-hop relational chains, and it is why the source material's framing names both limitations rather than treating either mechanism as generally superior.

There is no fixed entity or edge count named in the source material as a threshold, and treating this as a scale question at all somewhat misses the actual decision criterion. ⚠️ UNVERIFIED: no specific minimum size is stated anywhere in the ground-truth material as a rule of thumb for when a knowledge graph becomes worthwhile, so any specific number offered here would be an invented threshold rather than a sourced fact. The more reliable way to decide is the query-shape test this lesson has used throughout: if the questions an agent genuinely needs to answer are multi-hop and relational — as in the compliance-chain example — a graph earns its cost even at a genuinely small scale, because the five-entity example above already demonstrates a real capability gap no amount of vector-store tuning closes. Conversely, an agent whose real questions are entirely semantic-similarity in shape gains nothing from a graph regardless of how large a graph the underlying data could support, because the graph's specific strength — chain traversal — is simply not what those questions need. Size is the wrong axis to reason from; query shape is the right one, and it is the axis every worked example and comparison in this lesson has consistently returned to.

• A knowledge graph encodes entities and the relationships between them, enabling relational, multi-hop reasoning that flat, similarity-based retrieval structurally cannot perform, regardless of embedding quality.
• A multi-hop query composes a chain of several relationships into one answer that is not stated directly anywhere in the underlying data — the compliance-chain worked example walked a four-hop, five-entity case end to end.
• Knowledge graphs and vector search are not either-or alternatives: graphs win at relational, multi-hop reasoning, vector search wins at semantic similarity, and hybrid designs use both for the parts of a query each one actually serves.
• A knowledge graph is one of the three typical implementations of long-term memory named in M1-05, chosen specifically when the information that needs to persist is fundamentally relational rather than a flat fact or free text.
• The graph-versus-vector question is not a matter of preference or which technology is more advanced — it is a matter of matching the query's actual shape (chain-of-relationships versus meaning-based similarity) to the mechanism built for that shape.
• Recognizing a mixed query — part relational chain, part semantic similarity — and reaching for both mechanisms together is the scenario-question skill this domain is testing, not memorizing that "graphs are for relationships" in isolation.

Everything in this module so far has been about how an agent perceives, structures its reasoning, remembers, and grounds itself relationally — the internal architecture of a single agent's cognition. The one piece still missing is how a human actually reaches into that architecture: how oversight, feedback, and intervention get designed into the system rather than assumed to happen automatically once the agent is capable enough.

Next: M1-07 — designing the human-agent interface as the oversight surface, the module's closing lesson, and why UI design belongs inside the architecture domain rather than being treated as a downstream product concern.