Use a graph when relationships carry the answer
How to study this lesson
Read one section, trace the worked example, and try the knowledge check. Bookmark saves a shortcut; notes appear in My notebook. Mark lesson complete is your own assessment and does not mark its lab passed.
By the end, you can
- Distinguish entity graphs, ontologies, and graph-based retrieval.
- Trace bounded retrieval over typed relations.
- Identify extraction, entity-resolution, and inference failure modes.
Some questions require connections
A passage retriever is well suited to locating text about one concept. A graph becomes useful when the answer depends on connections distributed across sources. For example, which teams own services that depend on a deprecated library? One document maps services to libraries, another maps services to teams, and a third identifies the deprecated version. A graph can represent the join explicitly rather than hoping one retrieved paragraph already contains the complete answer.
Represent nodes with stable entity IDs and edges with typed relationships plus provenance. checkout depends_on lib-Q differs from team-red owns checkout; direction matters. Keep names as labels rather than identities. Two services called gateway in different environments should not merge simply because their display text matches. Entity resolution is part of the correctness boundary, not an optional cleanup step after graph construction.
An ontology constrains interpretation
An ontology specifies classes, relationships, and their intended meaning. OWL provides formal language for expressing such knowledge; its reasoning semantics are richer than a Python type-check dictionary. In particular, absence of a statement does not generally mean that the statement is false under open-world reasoning. A course graph validator can instead use explicitly documented closed-world assumptions for a bounded dataset.
Define Service, Library, and Team classes. Let depends_on connect Service to Library, and owned_by connect Service to Team. These constraints catch a malformed edge that claims a library is owned_by a service under this local schema. They do not prove that a well-typed edge is true. Keep structural validation separate from source verification, just as a valid tool schema does not establish that a business claim is correct.
A worked relational retrieval
Suppose checkout depends on library Q and search depends on library R. Checkout is owned by team red; search is owned by team blue. A deprecation record concerns Q. Start at Q, follow the inverse depends_on relation to checkout, then follow owned_by to team red. Return the supporting source IDs for both edges and the deprecation record so the answer is inspectable.
A generic breadth-first traversal might wander into unrelated ownership or deployment edges. Restrict relation types, direction, hop count, and candidate count according to the question. A shorter path is not automatically more relevant, and a path's existence does not establish a causal relationship. The graph is a structured retrieval index whose edges remain claims. The answer still needs the original evidence and the appropriate interpretation of each relation.
Local and global graph retrieval solve different needs
The GraphRAG paper explores graph-based indexing and community summaries for query-focused summarization, including questions requiring information across a collection. This differs from a simple entity-neighborhood lookup. A local question may need a small set of adjacent facts; a global question may need aggregated themes across communities. Choose the retrieval mode based on the question rather than assuming one traversal pattern covers both.
Community summaries introduce another derived artifact with source dependencies. If an extraction error enters the graph and is repeated in a summary, later retrieval can amplify it. Store links from summaries to the underlying nodes, edges, and passages. Rebuild affected summaries when source claims change. A graph-based system inherits the memory lifecycle and provenance requirements from the preceding modules; it does not escape them by using a different index.
Validate the graph and the answer separately
Test entity resolution with ambiguous names, renamed services, and environment-specific identifiers. Test relation extraction with negation and historical statements. Test traversal with cycles, disconnected nodes, and high-degree hubs. Then test whether the returned evidence supports the final answer. A graph can pass every structural check while containing a false edge extracted from a speculative incident note.
The code implements a tiny closed-world relation validator using an explicit type map. It is not an RDF parser, OWL reasoner, or trained graph extractor. The mini project adds time and evidence-path retrieval. A strong portfolio comparison should include questions where graphs help and questions where ordinary passage retrieval is sufficient, because graph construction and maintenance add costs that should be justified by the relationships the task actually requires.
Work through the code
A local relation schema checks source and target types. The last edge violates the defined owned_by direction. This is a closed-world Python simulation; it does not implement OWL inference or verify the truth of otherwise well-typed edges.
entity_types = {"checkout": "Service", "lib-Q": "Library", "team-red": "Team"}
relations = {"depends_on": ("Service", "Library"), "owned_by": ("Service", "Team")}
edges = [
("checkout", "depends_on", "lib-Q"),
("checkout", "owned_by", "team-red"),
("lib-Q", "owned_by", "checkout"),
]
def valid(edge):
source, relation, target = edge
if relation not in relations:
return False
expected_source, expected_target = relations[relation]
return (entity_types.get(source) == expected_source
and entity_types.get(target) == expected_target)
for edge in edges:
print(edge[1], valid(edge))
depends_on True owned_by True owned_by False
Run Python snippets locally with the prerequisites named above. The module coding lab runs directly in your browser.
Pause and reason
Two services named gateway exist in production and staging. A graph extractor merges them and returns a team owner from the wrong environment. What needs repair?
Check your understanding
A graph contains a well-typed depends_on edge. What has been established?
Your notes
Explain the mechanism in your own words. Add a failure you want to test.