Skip to content

PATTERN Cited by 2 sources

Precomputed relevance graph

Precomputed relevance graph is the pattern of building a cross-source knowledge graph + ranking model offline — before any query arrives — so that at query time the retrieval system returns a pre-ranked slice that is already filtered for relevance to the querier. The agent never sees raw multi-source fan-out; it sees a small, ordered list the graph has decided is most useful.

Intent

Agents are penalised twice for irrelevant retrieval results: once in token cost (every irrelevant hit eats budget) and once in reasoning quality (irrelevant content is a distractor that degrades decisions). Pushing the relevance filter upstream of retrieval — to an offline graph builder — means runtime retrieval is fast, lean, and already high-SNR.

Mechanism (Dash's realization)

(Source: sources/2025-11-17-dropbox-how-dash-uses-context-engineering-for-smarter-ai)

  1. Unified index. Combine data from every source (Dropbox content, Confluence, Google Docs, Jira, …) into one index. This is the substrate for a unified retrieval tool (patterns/unified-retrieval-tool).
  2. Layer a knowledge graph on top. Connect people, activity, and content across sources as nodes and edges. "Maps relationships between these sources so the system can understand how different pieces of information are connected."
  3. Precompute relevance signals offline. Graph edges + per-user activity + per-team context + per-org structure all feed into a ranker that produces a user-conditional relevance score for each candidate.
  4. At query time, retrieve only pre-ranked top-K. The agent's context receives "content our platform has already determined to be relevant" — not a semantic-nearest-N list that happens to include some useful items.

Why precompute?

  • Runtime simplicity. No per-query graph traversal, no per-query aggregation across sources. Retrieval is a read from a prepared slice.
  • Cache-efficient. Unified-index + graph persist; per-query cost is O(K) not O(sources × per-source-retrieval).
  • Eval-tractable. You can eval the graph + ranker in isolation, independently of the agent that consumes its output.
  • Privacy / ACL enforcement. ACL-aware edge computation is easier to audit when done in a known offline pipeline than re-derived per query.

Why a graph specifically?

Non-graph rankers (TF-IDF, dense retrieval, BM25) answer "what looks like this?". That's necessary but insufficient for agents — a retrieved doc that matches text but isn't connected to the user's work is a distractor. Graph edges let the ranker answer the richer question "what is connected to this user's context right now, and how?" (concepts/knowledge-graph for the entity-modeling side; this pattern is the production side — building and using it).

Tradeoffs

  • Offline pipeline complexity. Ingestion + edge computation + ranker training + freshness management are a real investment — this is a search-infra product, not a feature.
  • Staleness windows. Edges can lag events; the system has to expose or paper over "your doc was edited 30 seconds ago but the graph hasn't learned about it yet."
  • Cross-tenant risk. Bad ACL enforcement in the graph builder leaks between users; the unified surface means leaks are global not per-integration.
  • Ranker-quality is life-or-death. One ranker owns every agent-driven query; a regression is a product-wide quality drop.

Relationship to RAG

A classical RAG pipeline embeds chunks and retrieves by vector similarity at query time. Precomputed relevance graph treats retrieval as an application of a prepared artifact, not a per-query computation:

Axis Classical RAG Precomputed relevance graph
When relevance is computed At query time, per query Offline, continuously
Signal used Semantic similarity Semantic similarity + relationship edges + per-user context
Agent sees Top-K semantic matches Top-K user-conditional ranked matches
Best at "Find docs about X" "What should I work on next?" / "What's the status of project Y for me?"

Production systems typically do both — graph-ranked after a semantic candidate set. Dash's post describes the combination explicitly.

Seen in

  • sources/2025-11-17-dropbox-how-dash-uses-context-engineering-for-smarter-ai — Dash's unified universal-search index with a knowledge graph layered on top, as the runtime-lean / offline-heavy context source for the Dash agent.
  • sources/2026-01-28-dropbox-knowledge-graphs-mcp-dspy-dash — companion talk adds the crucial implementation detail: the precomputed graph is not queried as a graph at runtime. Dash experimented with graph databases and rejected them (latency, query-pattern mismatch, hybrid-retrieval integration). Instead, graph-derived signals are flattened into "knowledge bundles" — per-entity or per-query-class summary digests — and re-ingested through the same hybrid-index pipeline as documents (concepts/hybrid-retrieval-bm25-vectors). At query time, the agent sees top-K bundles + docs from a single fused ranker; there is no separate graph query path. This is the production shape of "precompute relevance offline" — not "query a graph fast," but "pre-materialize the graph's contribution as regular retrievable content." Also quantifies NDCG wins from the canonical-ID people resolution layer that sits behind the graph (patterns/canonical-entity-id).
Last updated · 200 distilled / 1,178 read