Context Graphs for Faster, More Predictable Retrieval

Video segment: 08:39–10:21 (watch from 08:39)

The idea in plain language

An agent often fails before it writes or executes anything. It may not know which service matters, who owns it, which other services it depends on, or where the most useful documentation lives. It must spend several retrieval steps discovering the shape of the problem.

Uber describes a context graph as a connected map of engineering and organizational information. The graph connects service locations, dependencies, ownership, patterns, code, data, documents, work items, and incidents. The important feature is not simply that all this information is stored in one place. The important feature is that the relationships between the pieces are represented.

For example, the graph can preserve links around a service:

service
  ├── is located in → a repository or code location
  ├── depends on → other services or components
  ├── is owned by → a team
  ├── follows → an engineering pattern
  ├── is described by → documents and work items
  └── is associated with → incidents

This is a teaching reconstruction of the relationship idea. It is not a claim about the graph's internal schema or retrieval algorithm.

Why relationships are the useful part

A flat search system can find items that contain a word. It may still leave the agent to infer how those items fit together. A graph adds structure to the search space. It can help the retrieval process follow relevant connections instead of treating every matching file, document, or record as an unrelated candidate.

The difference is easiest to see with an unfamiliar service. An agent that must modify the service needs more than the service's source files. It may need to find the service's location, its dependencies, its owner, the patterns used by similar code, and relevant operational history. A context graph can shorten this discovery path because those relationships are already represented.

The graph is therefore a map to context, not a replacement for context. The underlying code, documents, data, work items, and incident records remain the authoritative material to inspect. The graph helps the agent locate and connect the material that matters.

A useful distinction

Without relationship-aware retrieval	With a context graph helping retrieval
Search returns separate matches.	Search can use links between related entities.
The agent must reconstruct ownership and dependencies from results.	Ownership and dependency relationships can guide discovery.
More exploratory calls may be needed before useful context is assembled.	Relevant context may be assembled through fewer retrieval branches.
A result can look relevant because it shares a keyword.	A result can be relevant because it is connected to the task's entity.

The right-hand column describes the intended benefit. It does not mean that graph-assisted retrieval is always correct or always faster.

What Uber reports about the graph's scale

The speakers report 150 node and edge types and 40 million entries. A node represents an entity, such as a service or document. An edge represents a relationship between entities. “Node and edge types” means the graph distinguishes many kinds of entities and connections; it does not mean there are only 150 total nodes or edges.

The size claim explains why a managed retrieval layer is useful. A large engineering organization has too many possible pieces of context for an agent to load everything into one prompt. Selective retrieval becomes necessary. The graph gives that selection more structure than a list of independent search results.

Teaching example: finding context for one service

Imagine an agent must modify an unfamiliar service in a large monorepo. This is a teaching example built from the chapter's use case, not a claim about a particular Uber service.

1. The task identifies the service that must change.
2. Graph relationships help locate the service and connect it to its repository location, dependencies, owner, patterns, and related records.
3. The agent follows the most relevant links to gather the underlying code and supporting material.
4. The agent can begin the change with a more focused view of the system.

The graph does not make the code or documents unnecessary. It reduces the work of discovering which sources should be read first. That is why the relationship layer can improve predictability: the agent has a structured path for assembling context instead of relying only on repeated guesses.

Source example: graph-assisted SQL generation

The speakers also show a data question in natural language: How many mobility trips in India are cash trips?

To answer it with SQL, a system must connect ordinary language to technical data concepts. It must identify what “mobility trips,” “India,” and “cash trips” refer to in the available data, then map those concepts to the relevant structures and fields. SQL is the language used to express the resulting structured query.

A context graph can help with the semantic bridge:

natural-language question
          ↓
related business concepts and relationships
          ↓
relevant data structures and fields
          ↓
SQL representation of the question

This diagram explains the role of graph context. It does not specify the underlying schema, the generated SQL, or the answer to the question. The graph helps connect meaning to data structure; it is not itself proof that the final query is correct.

Why fewer retrieval branches can matter

The later source visual compares the same query with graph assistance and without graph assistance. The comparison shows speed, cost, and tool-call figures. The speakers describe graph-assisted use cases as improving tokens, turns, and latency.

These terms describe different kinds of efficiency:

• Tokens measure how much model context and output are consumed.
• Turns count exchanges in the retrieval or tool-use process.
• Latency is the elapsed time before useful work or an answer is available.

The causal idea is straightforward. If a graph points retrieval toward relevant sources, the agent may need fewer exploratory branches. Fewer branches can mean fewer tool calls, less context, and less waiting. That can reduce cost and latency for the workload being tested.

The comparison must be read narrowly. It compares the same query under two retrieval approaches. It does not establish that every graph is faster, that every query needs a graph, or that lower token use guarantees a better answer. Retrieval quality, graph coverage, and task shape still matter.

Freshness is part of the design

Relationships can become stale. A service can move. Ownership can change. A dependency can be replaced. A document can stop describing the current behavior. An incident record can remain useful as history while no longer describing the present system.

This creates a platform responsibility: a context graph must be kept sufficiently fresh for the tasks that depend on it. The chapter establishes the need for freshness, but it does not specify Uber's ingestion jobs, update schedule, consistency guarantees, or correction process.

This is also why the graph should guide inspection rather than silently replace source evidence. A graph edge can tell an agent where to look. The agent still needs to verify important facts against the current authoritative source.

Source visuals

At 09:18, the source shows a Service node connected to organizational and engineering entities. The typed neighborhood makes the idea of relationship-aware retrieval concrete.

At 10:09, the source compares graph-assisted and non-graph retrieval. The visible speed, cost, and tool-call figures ground the reported comparison without making it a universal benchmark.

Prerequisites

• A graph node represents an entity. An edge represents a relationship.
• Context retrieval selects information needed for a task.
• SQL is a language for querying structured data.

Key points

• Relationships are the graph's main value, not merely central storage.
• The graph helps locate authoritative sources; it does not replace them.
• Fewer retrieval branches can improve tokens, turns, and latency for some workloads.
• A large graph creates a continuing freshness and quality responsibility.
• The speakers report 150 node and edge types and 40 million entries, but the visible comparison is workload-specific.

Scope note

The source supports Uber's context-graph concept, its connected categories of information, the reported scale, and the reported improvements for graph-assisted use cases. It does not provide the exact graph schema, update pipeline, retrieval algorithm, query schema, generated SQL, comparison values, or answer to the mobility question. Those details are intentionally not inferred here.

Takeaway

A context graph makes relationships available as retrieval guidance. Instead of asking an agent to search a large organization as if every artifact were unrelated, it can help the agent move from a task to connected services, owners, dependencies, patterns, data, and records. The graph's value is not that it replaces the underlying evidence. Its value is that it can make the path to relevant evidence shorter and more predictable—provided the relationships remain fresh and the final sources are still checked.