TECHNIQUE
Retrieval & Grounding
Structured & graph RAG is deployed as an enterprise context layer by Dropbox and LinkedIn; Amazon has announced a graph-augmented recommendation system, while Grab’s pool evidence does not show this technique.
Build a domain knowledge graph as part of the retrieval context backbone, rather than relying only on unstructured document retrieval.
2 of 3 deployed operators; Amazon is announced-status evidence and not counted, and Grab has no cited structured/graph RAG evidence in this pool.Pair graph context with indexed retrieval stores, including vector indexes and, for Dropbox, lexical BM25 plus dense vectors.
2 of 3 deployed operators.Normalize or enrich source data into LLM-usable structured context before retrieval.
2 of 3 deployed operators.Use LLM-mediated query planning or query generation to turn user requests into retrieval actions over indexes, graphs, or APIs.
2 of 3 deployed operators.Expose graph-grounded retrieval through product, API, or tool interfaces instead of leaving it as a back-end-only capability.
2 of 3 deployed operators.Add ranking, evaluation, or testing around retrieved context and answers.
2 of 3 deployed operators.Among deployed operators with structured/graph RAG evidence, the graph is used alongside search or indexing infrastructure rather than as a standalone graph lookup.
Among deployed operators with evidence, the graph represents proprietary operational context: Dropbox models work content, people, activity, and sources; LinkedIn models security assets and relationships.
Graph construction differs by data source and validation workflow.
APPROACH 01
Connector-led enterprise content graph: crawl third-party apps, normalize files, enrich content, model information as a graph, and create knowledge bundles.
APPROACH 02
Security asset graph: prepare raw data from diverse databases into structured context and use a Security Knowledge Graph of digital assets and relationships.
Runtime retrieval surfaces differ.
APPROACH 01
Single universal search tool plus agent delegation: a planning agent decides when search is needed, a specialized search agent constructs retrieval queries, and Dash retrieval is exposed through an MCP server with one tool.
APPROACH 02
GraphQL/Cypher routing: the LLM generates Cypher queries, and query routing directs requests to a knowledge graph or GraphQL backend.
Retrieval signal mix differs.
APPROACH 01
Hybrid enterprise search: BM25 lexical index, dense vectors, embeddings, chunks, and contextual graph representations.
APPROACH 02
Security graph plus vector index and semantic search refinement.
Context quality and retrieval accuracy remain active concerns: Dropbox says precision in what is fed to the model is critical and highlights trimming context; LinkedIn describes semantic search refinement when inaccuracies arise and uses an accuracy testing framework.
Multi-source context is a recurring source of complexity: Dropbox describes work content spread across apps and Dash consulting sources such as Confluence, Google Docs, and Jira; LinkedIn describes context generation from diverse databases.
| Name | Kind | When | Maturity |
|---|---|---|---|
| Neo4j with vector index | service | entity-relationship questions over a maintained knowledge graph | established |
| GraphRAG (community summarization) | pattern | corpus-wide thematic questions flat chunk retrieval cannot answer | emerging |
| Text-to-Cypher generation | pattern | natural-language access to an existing graph schema | emerging |